You can also just call:

set jsoninput = {}.%FromJSON(dir)

where dir is a filename.

Interoperability (ex. Ensemble) can be used to both import data into InterSystems Data Platforms and push it to external systems.

^%ZSTART for terminal login.

Check this article. You'll need either HTTP Debugging proxy or Packet analyzer to debug this.

You probably have a mismatched brackets somewhere.

You can also try

[].%FromJSON

instead of

{}.%FromJSON

Your code has a bracket at the end:

You might have erased it accidentally?

If you're sure that there's only one object in response array, replace:

Set tSC = pResponse.%JSONImport(tHttpResponse.Data.Read())

with:

Set tSC = pResponse.%JSONImport({}.%FromJSON(tHttpResponse.Data).%Get(0)) 

It would parse your JSON stream into a dynamic JSON array (via {}.%FromJSON(tHttpResponse.Data)), get zeroth element from it (via %Get(0)), and pass it for JSON import (via pResponse.%JSONImport).

If you're sure that there's only one object in response, replace:

Set tSC = pResponse.%JSONImport(tHttpResponse.Data.Read())

with:

Set tSC = pResponse.%JSONImport({}.%FromJSON(tHttpResponse.Data).%Get(0)) 

If you want to parse an entire array, you'll need another class:

Class CDSM.ProviderAPI.Responses Extends (%Persistent, %JSON.Adaptor) {

Property Responses As List Of CDSM.ProviderAPI.ProviderInfo;

}

And in this case replace this code:

Set pResponse=##class(CDSM.ProviderAPI.Response).%New()
Set tSC = pResponse.%JSONImport(tHttpResponse.Data.Read())

With:

Set pResponse=##class(CDSM.ProviderAPI.Responses).%New()
Set tSC = pResponse.%JSONImport(tHttpResponse.Data)

and update the method signature too.

Why would be better or recommended to use %CSP.REST directly, instead of EnsLib.REST.Service?

To start with using %CSP.REST is the recommended way to use REST with productions.

Are there any improvements if we use %CSP.REST?

It's easier to develop, there are more examples available, you can have a combined production/non-production REST services easily.

The first, but not the last one, so still not getting the idea of having this intermediate upgrade point.

Sure, but you can start freezing on 2016.2. There's no point in freezing if you jump to latest version from pre 2016.2

Sorry, on which topic? Everyone knows that Cache/IRIS never runs on an unsupported OS.

Upgrade path between Cache/IRIS versions where OS for old and new Cache/IRIS versions must be different.

Yes, check my other reply, I get the zeroth element from the JSON array with %Get(0).

Also both [] and {} are valid JSON.

Check out GetStored and other useful auto-generated methods in this article.

I would recommend using plain %CSP.REST and calling BP/BO from it. Here's how. You'll need to replace async call with a sync one to get response back, but the rest of the logic would be the same.

Cache 2015 is a very old release. You should update to a latest version at least, preferably to InterSystems IRIS.

InterSystems IRIS natively supports WebSockets protocol as a client (your case) and as a server.

Consider upgrading.

upgrade to 2016.2

What is the reason of this step?

This is a first version with Frozen Plans. If this feature is not needed then upgrade to 2018.1 directly (provided OS compatibility - you're absolutely right about it).

Cache 2017.2 (our App's supported version) turned to be incompatible with Ubuntu 18, which was chosen as on OS for IRIS.

What's the official way to upgrade in that case? I usually just power down an instance, remove it from autostart, upgrade OS to the version supported by a new release, upgrade instance to a new version.

This way Cache/IRIS never runs on unsupported OS. Do you have a case with WRC on this topic?

Yeah I've merged intersystemscommunity org into intersystemsdc recently.

Great to see it used!