Try:

set st = ##class(%ZEN.Auxiliary.jsonProvider).%ConvertJSONToObject(responseStream,,.obj,1)

obj would become %ZEN.proxyObject. You can also create a class and parse json into object of that class.

In my opinion schema-less data (NoSQL, dynamic objects, globals) does not particularly exist. All that happens when you create schema-less data structures is that data validation and enforcing schema becomes someone else problem. Usually that means application programmer. That's why if  possible, consider using strict schemas - the more assumptions about the data you can guarantee, the less validation client application need to do. Also process of data cleansing, reporting and so on become much easier.

That said there are some use cases where using schema-less data is the way to go:

• For new applications/mock-up/PoC, when schema is unknown
• When schema is very extensive and changes often
• When speed is very important and data is retrieved by key (no complex queries)

To sum up, don't use schema if creating it and maintaining it would be a considerably more time-consuming affair than creating and maintaining application/reporting level data validation.

That said I see dynamic objects available in Caché mainly as a means to convert data from/to JSON.

With InterSystems IRIS we introduced DocDB - document database, based on dynamic objects, check it out.

Also mentioning @Stefan Wittmann.

Is

1POST /test/ HTTP/1.1 

actually a part of the request body?

If so, it's invalid json and you need to remove it from request body. What does

do httpRequest.EntityBody.OutputToDevice()

shows right before  sending the request?

Other thought, iin property should be passed as string, not as number. To do that:

1. Create a class

Class MyApp.Request Extends %RegisteredObject {

Property iin As %String;

... other properties ...

}

2. After that instead of %ZEN.proxyObject use this object as a request body.

Note that %ZEN.Auxiliary.jsonProvider:%WriteJSONStreamFromObject method has a pFormat argument, which defaults to aceloqtw in %ObjectToJSON method. One of the flags, q  means  output numeric values unquoted even when they come from a non-numeric property and you don't need that.

So your code should look something like this:

Set Object = ##class(MyApp.Request).%New()
Set Object.iin="123132132"
Set Object.firstName=name
Set Object.lastName=surname
Set Object.middleName=middlename
Set Object.birthDate=birthDate
Set Object.contractType="Z001"
Set sc = ##class(%ZEN.Auxiliary.jsonProvider).%WriteJSONStreamFromObject(httpRequest.EntityBody, Object, , , , "aelotw")
Set sc = httpRequest.Post("", 2)

Can you show the request itself via:

Set sc = httpRequest.Post("", 1) 

I don't have a %request.

Checked again and my suggested approach only works on production start, not host start, sorry.

I have a function which actually run "write $USERNAME" and if I run it from Studio returns the username!

$username returns current user, which for Ensemble job is correctly _Ensemble. You can try to query audit database for that info I guess.

As I said

they are not as reliable as audit database.

First one may not work at all, try safe get: $g(^CacheTemp.EnsUsername($job)).

Second one wouldn't work outside of CSP/ZEN context. Check that %request exists and is an object before calling GetCookie method.

Audit database contains correct username:

You can also get Username by these two ways:

• write ^CacheTemp.EnsUsername($job)
• write %request.GetCookie("Username")

But they are not as reliable as audit database.

$get works as fast as global could be read. Some ideas:

1. You can use ^PERFMON to see how these two globals are read - from disk or from memory. To do that collect 2 reports - with only ListGlobal load and only StringGlobal load and compare Physical reads.
2. Are both globals the same size?
3. How's globals size relative to global buffer?