I suspect that some of the binary bytes are getting converted to UTF-8, and this is what the "u" option in the sixth argument of %WriteJSONStreamFromObject specifies.

You can try removing the "u" and see if that helps, but even if it does I believe you will find other problems because JSON isn't meant to carry raw binary data. Generally binary data is base 64 encoded when putting it in JSON.

One example of the problem with binary data is that the value of binario needs to be enclosed in quotes "". But the binary data could include a byte which is the same code as a quote, which would cause the JSON recipient to think that the value of binario has ended.

My suggestion is to base 64 encode the binary data.

You were on the right track with %WriteJSONFromObject(), but you'll want to use %WriteJSONStreamFromObject() instead. I don't see what purpose the Body property in your request class serves. You can just create a stream object variable instead.

set myTempStream=##class(%Stream.GlobalCharacter).%New()
set tSC=##class("%ZEN.Auxiliary.altJSONProvider").%WriteJSONStreamFromObject(.myTempStream, pRequest)
if $$$ISERR(tSC) {
    quit tSC

...then later:

Set tSC=..Adapter.PostURL(tURL,.tHttpResponse, , myTempStream)

A pool size of 1 is the recommendation when you need to maintain FIFO (process all messages strictly in the sequence that they arrived). Going above 1 is fine if FIFO isn't required.

Each additional pool job will result in an additional OS-level process, which adds a little bit of memory usage. How much CPU is used by each process depends on how much work the operation is doing. Essentially, changing pool size from 1 to 2 has the same resource impact as adding another identical business operation.

The max possible pool size depends on lots of factors. I would suggest starting small (2? 4?), see how that affects the queue, and increase accordingly. Having a pool size of 10, for instance, isn't likely to cause performance or resource problems unless your operation is doing something crazy. If you start getting into a pool size of dozens you might want to take a closer look with the WRC. One of your main limitations might be how many concurrent connections System A allows you to make.

It looks like the ENSDEMO namespace doesn't have an example for XML v-docs.

The basic steps are:
- Import an XSD (XML schema) for the document format you need to work with:

- In your DTL, select XML as the Source Type and for Source Document Type select the schema that you just imported

- The DTL editor will use the imported schema to display a document structure that you can use to visually build your mappings

At this point you can paste into the testing tool a sample XML that follows the XSD.

If you just want to do a quick test to see how this works, you can find a simple XSD online and import that. I found this sample which includes an XSD and sample XML that follows the XSD's structure:

That's an HL7 vdoc (EnsLib.HL7.Message) and that sample is HL7 code (though with strange delimiters).

So yes, if your input message is HL7 (EnsLib.HL7.Message) then you can just paste a raw HL7 message into the testing tool.

If your input message is XML (EnsLib.EDI.XML.Document) then you can just paste raw XML into the testing tool.

If your input message is an EnsLib.EDI.XML.Document and the message content is HL7 there's going to be a problem :)