DEV Community: Irene Mykhailova

Transferring Files via REST to Store in a Property, Part 2

Irene Mykhailova — Fri, 04 Jun 2021 17:34:12 +0000

In the first installment of this article series, we discussed how to read a “big” chunk of data from the raw body of an HTTP POST method and save it to a database as a stream property of a class. Now let’s look at how to save such data and metadata in JSON format.

Unfortunately, Advanced REST Client doesn’t let you compose JSON objects with binary data as a value of a key (or maybe I simply haven’t figured out how to do it), so I decided to write a simple client in ObjectScript to send data to the server.

I created a new class called RestTransfer.Client and added to it parameters Server = "localhost" and Port = 52773 to describe my web server. And I created a GetLink class method in which I create a new instance of class %Net.HttpRequest and set its properties to the aforementioned parameters.

To actually send the POST request to a server, I created a class method SendFileDirect, which reads the file I wish to send to the server and writes its contents to my request’s EntityBody property.

After this, I call method Post("/RestTransfer/file") and, if it completes successfully, the response will be in the HttpResponse property.

To see the result returned by the server, I call the response’s OutputToDevice method.

Here’s the class method:

Class RestTransfer.Client
{
  Parameter Server = "localhost";
  Parameter Port = 52773;
  Parameter Https = 0;

  ClassMethod GetLink() As %Net.HttpRequest
  {
      set request = ##class(%Net.HttpRequest).%New()       
      set request.Server = ..#Server
      set request.Port = ..#Port
      set request.ContentType = "application/octet-stream" 
      quit request
  }

  ClassMethod SendFileDirect(aFileName) As %Status
  {
    set sc = $$$OK 
    set request = ..GetLink() 
    set s = ##class(%Stream.FileBinary).%New()
    set s.Filename = aFileName
    While 's.AtEnd 
    {
      do request.EntityBody.Write(s.Read(.len, .sc))
      Quit:$System.Status.IsError(sc)
    }
    Quit:$System.Status.IsError(sc)

    set sc = request.Post("/RestTransfer/file")                            
    Quit:$System.Status.IsError(sc)
    set response=request.HttpResponse
    do response.OutputToDevice()
    Quit sc
  }
}

We can call this method to transfer the same files used in the previous article:

 do ##class(RestTransfer.Client).SendFileDirect("D:\Downloads \2020_1012_114732_020.JPG")
 do ##class(RestTransfer.Client).SendFileDirect("D:\Downloads\Archive.xml")
 do ##class(RestTransfer.Client).SendFileDirect("D:\Downloads\arc-setup.exe")

We’ll see the responses from the server for each file:

HTTP/1.1 200 OK
CACHE-CONTROL: no-cache
CONTENT-LENGTH: 15
CONTENT-TYPE: text/html; charset=utf-8
DATE: Thu, 05 Nov 2020 15:13:23 GMT
EXPIRES: Thu, 29 Oct 1998 17:04:19 GMT
PRAGMA: no-cache
SERVER: Apache
{"Status":"OK"}

And we’ll have the same data in globals as before:

This means our client works and we can now expand it to send JSON to the server.

Getting to Know JSON

JSON is a lightweight format for storing and transporting data where the data is in name/value pairs separated by commas. In this case, the JSON will look something like this:

{
  "Name": "test.txt",
  "File": "Hello, world!"
}

IRIS has several classes that let you work with JSON. I’m going to use the following:

%JSON.Adaptor provides a way to serialize a JSON enabled object as a JSON document and vice versa.
%Library.DynamicObject provides a way to dynamically assemble data that can be conveniently passed between a web client and a server.

You can find more about these and other classes that let you work with JSON in the Class Reference section of the documentation and Application Development Guides.

The main advantage of these classes is that they give you an easy way to create JSON from an IRIS object or create an object from JSON.

I’ll show two approaches of how you can work with JSON to send/receive files, namely one that uses %Library.DynamicObject to create an object on the client side and serialize it to a JSON document and %JSON.Adaptor to deserialize it back to RestTransfer.FileDesc on the server side, and another where I manually form a string to send to and parse on the server side. To make it more readable, I’ll create two different methods on the server for each approach.

For now, let’s concentrate on the first one.

Creating JSON with IRIS

To start, let’s inherit the RestTransfer.FileDesc class from %JSON.Adaptor. This lets us use instance method %JSONImport() to deserialize a JSON document directly into an object. Now, this class will look as follows:

Class RestTransfer.FileDesc Extends (%Persistent, %JSON.Adaptor)
{
  Property File As %Stream.GlobalBinary;
  Property Name As %String;
}

Let’s add a new route to UrlMap in the class broker:

<Route Url="/jsons" Method="POST" Call="InsertJSONSmall"/>

This specifies that, when the service receives a POST command with URL /RestTransfer/jsons, it should call the InsertJSONSmall class method.

This method expects to receive JSON-formatted text with two key-value pairs where the contents of the file will be less than the maximum length of a string. I’ll set the Name and File properties of the object, save it to the database, and return the status and a JSON-formatted message indicating either success or an error.

Here’s the class method.

ClassMethod InsertJSONSmall() As %Status
{
  Set result={}
  Set st=0 

  set f = ##class(RestTransfer.FileDesc).%New()  
  if (f = $$$NULLOREF) {    
   do result.%Set("Message", "Couldn't create an instance of class") 
  } else {  
     set st = f.%JSONImport(%request.Content) 
     If $$$ISOK(st) {
        set st = f.%Save()
        If $$$ISOK(st) {      
           do result.%Set("Status","OK")        
        } else {           
           do result.%Set("Message",$system.Status.GetOneErrorText(st)) 
        }
     } else {         
        do result.%Set("Message",$system.Status.GetOneErrorText(st)) 
     }
  } 
  write result.%ToJSON()
  Quit st
}

What does this method do? It gets the Content property of the %request object and, using method %JSONImport inherited from the class %JSON.Adaptor, converts it to a RestTransfer.FileDesc object.

If there are problems during conversion, we form a JSON with the error description:

{"Message",$system.Status.GetOneErrorText(st)}

Otherwise we save the object. If it saves without problems, we create a JSON {"Status","OK"} message. If not, a JSON message with the error description.

Finally, we write the JSON to a response and return status st.

On the client side I added a new class method SendFile to send files to the server. The code is very similar to that of SendFileDirect but, instead of writing file contents directly to the EntityBody property, I create a new instance of the class %Library.DynamicObject, set its property Name equal to the name of the file, and encode and copy the contents of the file into property File.

To encode the contents of the file I use the method Base64EncodeStream() proposed by Vitaliy Serdtsev.

Next, using method %ToJSON of class %Library.DynamicObject, I serialize my object to a JSON document, write it into the body of the request, and call method Post("/RestTransfer/jsons").

Here’s the class method:

ClassMethod SendFile(aFileName) As %Status
{
  Set sc = $$$OK
  Set request = ..GetLink() 
  set s = ##class(%Stream.FileBinary).%New()
  set s.Filename = aFileName
  set p = {}
  set p.Name = s.Filename 
  set sc = ..Base64EncodeStream(s, .t)
  Quit:$System.Status.IsError(sc)

  While 't.AtEnd { 
    set p.File = p.File_t.Read(.len, .sc)
    Quit:$System.Status.IsError(sc)
  }  
  do p.%ToJSON(request.EntityBody)
  Quit:$System.Status.IsError(sc)

  set sc = request.Post("/RestTransfer/jsons")                                    
  Quit:$System.Status.IsError(sc)

  Set response=request.HttpResponse
  do response.OutputToDevice()
  Quit sc
}

We call this method and method SendFileDirect to transfer several small files:

 do ##class(RestTransfer.Client).SendFile("D:\Downloads\Outline Template.pdf")      
 do class(RestTransfer.Client).SendFileDirect("D:\Downloads\Outline Template.pdf")    
 do ##class(RestTransfer.Client).SendFile("D:\Downloads\pic3.png")         
 do ##class(RestTransfer.Client).SendFileDirect("D:\Downloads\pic3.png")         
 do ##class(RestTransfer.Client).SendFile("D:\Downloads\Archive (1).xml")      
 do ##class(RestTransfer.Client).SendFileDirect("D:\Downloads\Archive (1).xml")

We’ll get the following results:

As you can see, the lengths are the same and, if we save those files to a hard drive, we’ll see that they’re unchanged.

Forming JSON Manually

Now let’s concentrate on the second approach, which is to form the JSON manually. To do this, let’s add a new route to UrlMap in the class broker:

<Route Url="/json" Method="POST" Call="InsertJSON"/>

This specifies that when the service receives a POST command with URL /RestTransfer/json, it should call the InsertJSON class method. In this method, I expect to receive the same JSON, but I don’t impose any limits on the length of the file. Here’s the class method:

ClassMethod InsertJSON() As %Status
{
  Set result={}
  Set st=0 

  set t = ##class(%Stream.TmpBinary).%New()
  While '%request.Content.AtEnd 
  {        
    set len = 32000
    set temp = %request.Content.Read(.len, .sc)
    set:len<32000 temp = $extract(temp,1,*-2)  
    set st = t.Write($ZCONVERT(temp, "I", "RAW"))                                                
  }
  do t.Rewind()

  set f = ##class(RestTransfer.FileDesc).%New()  
  if (f = $$$NULLOREF) 
  {     
    do result.%Set("Message", "Couldn't create an instance of class") 
  } else {
    set str = t.Read()
    set pos = $LOCATE(str,""",")
    set f.Name = $extract(str, 10, pos-1)
    do f.File.Write($extract(str, pos+11, *))
    While 't.AtEnd {       
      do f.File.Write(t.Read(.len, .sc))
    }

    If $$$ISOK(st) 
    {
      set st = f.%Save()
      If $$$ISOK(st) 
      {         
        do result.%Set("Status","OK")         
      } else {                      
        do result.%Set("Message",$system.Status.GetOneErrorText(st)) 
      }
    } else {         
       do result.%Set("Message",$system.Status.GetOneErrorText(st)) 
    }    
  }
  write result.%ToJSON()
  Quit st
}

What does this method do? First, I create a new instance of a temporary stream, %Stream.TmpBinary, and copy into it the contents of the request.

Because I’m going to work with it as a string, I need to get rid of a trailing quote mark (") and a curly brace (}). To do this, in the last chunk of the stream I leave out the last two characters: $extract(temp,1,*-2).

At the same time, I convert my string using the "RAW" translation table: $ZCONVERT(temp, "I", "RAW").

Then I create a new instance of my class RestTransfer.FileDesc and do the same checks as in the other methods. I know the structure of my string, so I extract the name of the file and the file itself and set them to corresponding properties.

On the client side, I modified my class method SendFile and, before forming the JSON, I check the length of the file. If it’s less than the 2,000,000 bytes (apparent limit for the %JSONImport method), I call Post("/RestTransfer/jsons"). Otherwise I call Post("/RestTransfer/json").

Now the method looks like this:

ClassMethod SendFile(aFileName) As %Status
{
  Set sc = $$$OK
  Set request = ..GetLink()
  set s = ##class(%Stream.FileBinary).%New()
  set s.Filename = aFileName
  if s.Size > 2000000 //3641144 max length of the string in IRIS
  {   
    do request.EntityBody.Write("{""Name"":"""_s.Filename_""", ""File"":""")      
    While 's.AtEnd 
    {       
      set temp = s.Read(.len, .sc)
      do request.EntityBody.Write($ZCONVERT(temp, "O", "RAW"))   
      Quit:$System.Status.IsError(sc)
    }

    do request.EntityBody.Write("""}")  
    set sc = request.Post("/RestTransfer/json")                           
  } else {
    set p = {}
    set p.Name = s.Filename
    set sc = ..Base64EncodeStream(s, .t)
    Quit:$System.Status.IsError(sc)
    While 't.AtEnd {
        set p.File = p.File_t.Read(.len, .sc)
        Quit:$System.Status.IsError(sc)
    } 
    do p.%ToJSON(request.EntityBody)
    Quit:$System.Status.IsError(sc)
    set sc = request.Post("/RestTransfer/jsons")                                      
  }

  Quit:$System.Status.IsError(sc)
  Set response=request.HttpResponse
  do response.OutputToDevice()
  Quit sc
}

To call the second method, I create the string with JSON manually. And to transfer the file itself, on the client side I also convert the contents using the “RAW” translation table: ($ZCONVERT(temp, "O", "RAW").

Now we call this method and method SendFileDirect to transfer several files of different sizes:

 do ##class(RestTransfer.Client).SendFile(“D:\Downloads\pic3.png”)         
 do ##class(RestTransfer.Client).SendFileDirect(“D:\Downloads\pic3.png”)         
 do ##class(RestTransfer.Client).SendFile(“D:\Downloads\Archive (1).xml”)      
 do ##class(RestTransfer.Client).SendFileDirect(“D:\Downloads\Archive (1).xml”)    
 do ##class(RestTransfer.Client).SendFile(“D:\Downloads\Imagine Dragons-Thunder.mp3”)         
 do ##class(RestTransfer.Client).SendFileDirect(“D:\Downloads\Imagine Dragons-Thunder.mp3”)
 do ##class(RestTransfer.Client).SendFile(“D:\Downloads\ffmpeg-win-2.2.2.exe”)   
 do ##class(RestTransfer.Client).SendFileDirect(“D:\Downloads\ffmpeg-win-2.2.2.exe”)

We’ll get the following results:

We can see that the lengths are the same so everything works as it’s supposed to.

Wrapping Up

Again, you can read more about creating REST services in the documentation. The example code for both approaches is on GitHub and InterSystems Open Exchange.

As for transferring results of the TWAIN module discussed in the first article of this series, it depends on the size of data you’ll be receiving. If the maximum resolution will be limited and the files will be small, you can use system classes %JSON.Adaptor and %Library.DynamicObject. But to be on the safe side, it’s better to either send a file directly in the body of a POST command or to form the JSON manually. Also it may be a good idea to use range requests and divide big files into several parts, send them separately and consolidate back into one file on the server side.

In any case, if you have any questions or suggestions, please don’t hesitate to write them in the comments section.

Transferring Files via REST to Store in a Property, Part 1

Irene Mykhailova — Fri, 04 Jun 2021 17:33:58 +0000

A question came up in the InterSystems developer community concerning the possibility of creating a TWAIN interface to a Caché application. There were several great suggestions on how to get data from an imaging device on a web client to a server, then store this data in a database.

However, in order to implement any of these suggestions, you need to be able to transfer data from a web client to a database server and store the received data in a class property (or a table cell, as was the case in the question). This technique can be useful not only for transferring imaging data received from a TWAIN device, but also for other tasks such as organizing a file archive, an image share, and so forth.

Thus, the main objective of this article is to show how to write a RESTful service to get data from the body of an HTTP POST command either in a raw state or wrapped in a JSON structure.

REST Basics

Before getting to the specifics, let’s start with a few words about REST in general and how RESTful services are created in IRIS.

Representational state transfer (REST) is an architectural style for distributed hypermedia systems. The key abstraction of information in REST is a resource which has its proper identifier and can be represented in a JSON, XML, or other format known to both server and client.

Usually, HTTP is used to transfer data between client and server. Each CRUD (create, read, update, delete) operation has its own HTTP method (POST, GET, PUT, DELETE), while each resource or collection of resources has its own URI.

In this article, I’ll be using only the POST method to insert a new value into the database, so I need to know its constraints.

POST doesn’t have any limit on the size of data stored in its body according to the IETF RFC7231 4.3.3 Post specification. But different web servers and browsers impose their own limits, typically from 1MB to 2GB. For example, Apache allows a maximum of 2GB. In any case, if you need to send a 2GB file, you might want to rethink your approach.

Requirements for a RESTful Service in IRS

In IRIS, in order to implement a RESTful service, you have to:

Create a class broker that extends the abstract class %CSP.REST. This, in turn, extends %CSP.Page, and this makes it possible to access different useful methods, parameters, and objects, in particular %request).
Specify UrlMap to define routes.
Optionally set the UseSession parameter to specify whether each REST call is executed in its own web session or shares a single session with other REST calls.
Provide class methods to perform operations defined in routes.
Define the CSP web application and specify its security on the web application page (System Administration > Security > Applications > Web Applications), where the Dispatch class should hold the name of the user class and Name, the first part of the URL for the REST call.

In general, there are several ways to send big chunks of data (files) and their metadata from client to server, such as:

Base64-encode the file and the metadata and add processing overhead to both the server and the client for encoding/decoding.
Send the file first and return an ID to the client, which then sends the metadata with the ID. The server reassociates the file and the metadata.
Send the metadata first and return an ID to the client, which then sends the file with the ID, and the server reassociates the file and the metadata.

In this first article, I’m going to basically take the second approach, but without returning ID to the client and adding the metadata (the filename to store as another property) because there’s nothing exceptional about this task. In a second article, I’ll use the first approach, but I’ll package my file and metadata (the filename) in a JSON structure before sending it to the server.

Implementing the RESTFul Service

Now let’s get to the specifics. First, let’s define the class, properties of which we’ll be setting:

Class RestTransfer.FileDesc Extends %Persistent
{
  Property File As %Stream.GlobalBinary;
  Property Name As %String;
}

Of course, you’ll usually have more metadata to go with the file, but this should suffice for our purposes.

Next, we need to create a class broker, which we’ll expand later with routes and methods:

Class RestTransfer.Broker Extends %CSP.REST
{
  XData UrlMap
  {
    <Routes>
    </Routes>
  }
}

And lastly, for the preliminary setup we need to specify this application in a list of web applications:

Now that the preliminary setup is done, we can write methods to save a file received from a REST client (I’ll use the Advanced REST Client) into a database as a File property of an instance of class RestTransfer.FileDesc.

We’ll start by working with information stored as raw data in the body of POST method. First, let’s add a new route to UrlMap:

This route specifies that when the service receives a POST command with URL /RestTransfer/file, it should call the InsertFileContents class method. To make things easier, inside this method I’ll create a new instance of a class RestTransfer.FileDesc and set its File property to the received data. This returns the status and a JSON-formatted message indicating either success or error. Here’s the class method:

ClassMethod InsertFileContents() As %Status
{
  Set result={}
  Set st=0    
  set f = ##class(RestTransfer.FileDesc).%New()
  if (f = $$$NULLOREF) {
    do result.%Set("Message","Couldn't create an instance of the class")
  } else {
    set st = f.File.CopyFrom(%request.Content)
    If $$$ISOK(st) {
      set st = f.%Save()
      If $$$ISOK(st) {
        do result.%Set("Status","OK")
      } else {
        do result.%Set("Message",$system.Status.GetOneErrorText(st))
      }
    } else {
      do result.%Set("Message",$system.Status.GetOneErrorText(st))
    }
  }
  write result.%ToJSON()
  Quit st
}

First, it creates a new instance of class RestTransfer.FileDesc and checks that it was created successfully and we have an OREF. If the object couldn’t be created, we form a JSON structure:

{"Message", "Couldn't create an instance of class"}

If the object was created, the contents of the request are copied into the property File. If copying was not successful, we form a JSON structure with a description of the error:

{"Message",$system.Status.GetOneErrorText(st)}

If the contents were copied, we save the object, and if the save is successful, we form a JSON {"Status","OK"}. If not, the JSON returns an error description.

Finally, we write the JSON to a response and return status st.

Here’s an example of transferring an image:

How it’s saved in the database:

We can save this stream to a file and see that it was transferred without change:

set f = ##class(RestTransfer.FileDesc).%OpenId(4)
set s = ##class(%Stream.FileBinary).%New()
set s.Filename = "D:\Downloads\test1.jpg"
do s.CopyFromAndSave(f.File)

The same can be done with a text file:

This will also be visible in globals:

And we can store executables or any other type of data:

We can check the size in globals, and it’s correct:

Now that this part works as it should, let’s take a look at the second approach — getting the contents of the file and its metadata (the filename) stored in JSON format and transferred in the body of a POST method.

You can read more about creating REST services in the InterSystems documentation.

The example code for the both approaches is on GitHub and InterSystems Open Exchange. If you have any questions or suggestions pertaining to either, please don’t hesitate to write them in the comments section.

Accessing data via ECP with eXTreme for .NET

Irene Mykhailova — Wed, 04 Nov 2020 18:37:33 +0000

Some readers of my previous article, Caché eXTreme for .NET - direct access to globals from C#, wondered if you could access information not just from the same instance in which you’re working, but also from another instance on the same computer, or from an instance located on another computer in the same local network. Some theorized, correctly, that this would be possible using the Enterprise Cache Protocol (ECP). In this article I’m going to show how it can be done.

The last I heard, eXTreme for .NET still uses an in-memory connection and runs in the same process as the IRIS instance, though at least one comment suggested the possibility of moving away from in-memory to TCP/IP.

But, even if you can’t use TCP/IP to connect to an instance on another computer, you can use ECP to connect your local database instance to another instance on a different computer in a local network and work with this remote database as if it’s the local one. ECP is a distributed data caching architecture that manages the distribution of data and locks among a heterogeneous network of server systems. In this article, I’m going to take advantage of this architecture to store my data to another instance.

The general idea is that I have a database with my data in one instance of IRIS and this will be my data server. I’m going to call this instance IRIS. I’ll also need another instance to which I’ll connect from my eXTreme application, and this will be my application server. I’ll call this instance IRIST. In this case, both instances are located on the same computer. (I have only one computer with 64-bit anything, in my case Windows). But this doesn’t change the result—I still need to connect the two different instances in order to access the database of one from the other.

Before doing anything in Visual Studio, however, we need to set up the ECP on both IRIS instances.

First, we’ll enable the ECP service on both the data (IRIS) and application (IRIST) servers. To do this, go to Management Portal > System Administration > Security > Services. In the list of services, select %Service.ECP and on the Edit Service page, click the Service Enabled checkbox, as shown below. Don’t forget to click the Save button.

Next, we’ll configure the data server, incrementing the number of allowed application servers from the default of 1. Again, go to Management Portal > System Administration > Configuration > Connectivity > ECP Settings and in the pane on the right, “This System as an ECP Data Server,” change the “Maximum number of application servers” to 2 (or one more than whatever you have in use already). Then click Save and restart the instance for the change to take effect.

Because I’m lazy and this is just an example, I’ll use the USER database, but you can create a new one or use any database you have on hand (that you won’t worry about if it becomes unreadable).

Next, we’ll configure our application server. The first step is to connect the application server to our data server. Go to Management Portal > System Administration > Configuration > Connectivity > ECP Settings > Data Servers.

Then click the Add Server button and fill in the information about your data server. In my case, when I was setting up my data server, I didn’t choose the option Enabled or Required from the radiogroup “ECP SSL/TLS support,” so I don’t check “Use SSL/TLS.”

If you’re using another computer, you need to provide its name or IP address in the Server Name field.

Click Save and you’ll see a new entry in the list of ECP data servers. In my case, the Status is Normal, which means that the connection is operating as it should. You can read more on ECP Connection States in the documentation.

If you’re connecting instances on different computers on the (local) network, you need to make sure your port (51773, in my case) is open. Check your configuration of firewalls, antivirus, and so forth.

Once the link is established, we need to map our remote database (USER, from IRIS) to our local application server (IRIST). To do this, we need to create a new database, so go to Management Portal > System Administration > Configuration > System Configuration > Namespaces and click the Create New Namespace button. Give the namespace a name and select “Remote Database” for the options, indicating the default database for Globals and for Routines.

Now you need to create this remote database. To do so, click the “Create New Database…” button. Choose the remote server you created in the previous step from the dropdown list.

Then choose the directory of that instance.

And come up with a new Database Name.

Click Finish and don’t forget to choose the same database for Routines. Clear the checkbox “Enable namespace for interoperability productions,” click Save at the top of the page, and you’re all set.

Before we start working with our globals from C#, let’s check that everything is working and that we have access to the data stored in another instance. To do this, you can, for example, open a terminal on the application server (IRIST), switch the current namespace to the one you created, and set the value of some global.

Then, in a terminal on the data server, you should be able to read this value.

We get the correct value, which means we can proceed with a test application in C# and use eXTreme technology to work with data stored in our data server while having an in-memory connection to our application server.

First, let me remind you about the adjustments that need to be made for it all to work. To start, environmental variables for Windows must be set:

GLOBALS_HOME should contain the full path to the directory where you put the DBMS. In my case, this is C:\InterSystems\IRIST.
PATH must contain the full path to the Bin directory. In my case, this is C:\InterSystems\IRIST\Bin.

With both of my instances on the same computer, I have to set the path to my application server instance in the environmental variables, because nowhere in my application code am I directly specifying the instance I’ll be working with.

By the way, if you just set the variables, you’ll need to log into your Windows user instance again for the changes to take effect.

Now let’s open the existing eXTreme application from my previous article. To make sure it will work, check that your license allows such connections. Also, see if the version of .NET you chose for your project is the same as the version referenced in your eXTreme library.

Before switching to the remote database, I decided to check if my program still works.

And it works perfectly. I can see my globals in the database. For now, they’re in the local database of the IRIST instance.

Now all I need to do to switch to my remote database is change the namespace when I’m connecting to the local instance, IRIST.

So instead of using the following code:

Connection myConn = ConnectionContext.GetConnection();
myConn.Connect("USER", "_SYSTEM", "SYS");

I’ll use:

Connection myConn = ConnectionContext.GetConnection();
myConn.Connect("IRIS_USER", "_SYSTEM", "SYS");

Thus, I’ll be accessing the namespace IRIS_USER from local application server instance IRIST, which is mapped to a remote database of the data server instance IRIS. The output is the same:

And we can see this global in the IRIS instance:

And through ECP:

Mission accomplished! You can use the InterSystems.CacheExtreme.dll library, which you can find in ..\bin\debug\ folder of the example, to connect to IRIS. And you can use ECP to connect to a remote database from an eXTreme application.

You can read more about setting up the ECP environment in First Look: Scaling Systems for User Volume with InterSystems Distributed Caching. The sample project in this article is the same as in the previous one and is on GitHub.