I've seen Zen reports used extensively for Chinese content, so they can definitely handle the far reaches of the Unicode realm.

What happens if you do this?

write !,"<PostInfo>My GE: "_$c(8805)_"</PostInfo>"

or this?

write !,"<PostInfo>My GE: "_$zcvt($c(8805),"O","UTF8")_"</PostInfo>"

Some other things to check:

Hopefully this can save you some work. It uses a much larger chunk size (which is a multiple of 57) and works with or without CR/LFs (set the argument pAddCRLF):

Class Example.B64.Util Extends %RegisteredObject
{

/// Be cautious if changing CHUNKSIZE. Incorrect values could cause the resulting encoded data to be invalid.
/// It should always be a multiple of 57 and needs to be less than ~2.4MB when MAXSTRING is 3641144
Parameter CHUNKSIZE = 2097144;

ClassMethod B64EncodeStream(pStream As %Stream.Object, pAddCRLF As %Boolean = 0) As %Stream.Object
{
    set tEncodedStream=##class(%Stream.GlobalCharacter).%New()
    
    do pStream.Rewind()
    
    while ('pStream.AtEnd) {
        set tReadLen=..#CHUNKSIZE
        set tChunk=pStream.Read(.tReadLen)
        
        do tEncodedStream.Write($System.Encryption.Base64Encode(tChunk,'pAddCRLF))
        if (pAddCRLF && 'pStream.AtEnd) {
            do tEncodedStream.Write($c(13,10))
        }
    }
    
    do tEncodedStream.Rewind()
    
    quit tEncodedStream
}

}

My experience with Zebras was quite a few years ago, so this may or may not still apply... Using Zen reports at the time, the print server would end up rendering the label as a bitmap and sending that over to the Zebra. ZPL code to print an equivalent label was much smaller than a bitmap, so ZPL labels tended to print faster than those rendered by a report.

Ok, so the flow would look roughly like this:

  • The GenericService accepts an inbound REST request, populates a GenericMessage, and sends it to your business process
  • Business process extracts the JSON payload from the GenericMessage, and pulls out any relevant details needed for the call to Athena
  • Business process creates a new GenericMessage, populates any items needed by Athena, uses %SYS.OAuth2 (and the OAuth client profile you created) to request an OAuth token and adds it to the GenericMessage, and passes the new GenericMessage to the business operation.
  • Business operation makes the outbound REST call to Athena, and returns a new GenericMessage containing the response to your business process.
  • Business process extracts JSON payload from the GenericMessage, uses a transformation to create the payload required by your internal REST client.
  • Business process creates a new GenericMessage, populates it with the response payload, and returns it to the GenericService
  • GenericService returns response to REST client

What Response From does is control which responses from a call to an operation (or another component) are returned to the business service that called the router. By default the router won't return the response to the service, but setting Response From will enable responses to be returned from specific operations (or * for all operations). This is how you can control which response gets sent back to the service in a case when a router calls multiple operations. If multiple responses match the Response From setting, then only the first response will be returned to the service.

Response Target Config Names allows you to specify additional components (beyond the service that called the router) that should receive a copy of the response that came back from the operation. So you could send a copy of an ACK or other response to another operation for some reason.

All of this is probably moot, because I'm guessing your service doesn't need to receive a response.

In terms of the NULL responses, these shouldn't become orphans -- the fact that they appear in the message trace tells us that the production knows which session they belong to so they should get deleted along with the rest of the session.

Absolutely. You can do this with two assign actions:

First assign action moves the stream pointer to the end of the stream content:

The second assign action writes our new content to the end of the stream:

And an extra note of explanation: what we're actually doing with these assigns is calling a method in the request class, which returns a status code, and assigning that status code to a temporary variable. It would be best to check this status code to see if there was an error, but I haven't added that here to keep things simple.