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:

• Check if the TTF file for the font you're using contains that glyph.
• Make sure your report is set to use UTF-8 encoding:
  • https://docs.intersystems.com/ens201815/csp/docbook/DocBook.UI.Page.cls?...
• Look at the intermediary files (the .xml which contains the data in particular) that Zen generates to see if/how that item was output:
  • https://docs.intersystems.com/ens201815/csp/docbook/DocBook.UI.Page.cls?...
  • https://docs.intersystems.com/ens201815/csp/docbook/DocBook.UI.Page.cls?...
• Check to see if FOP is reporting any errors:
  • https://docs.intersystems.com/ens201815/csp/docbook/DocBook.UI.Page.cls?...

Have you looked into tuning the JVM heap settings? It's possible the JVM is running out of heap space.

https://www.baeldung.com/jvm-parameters

"#" is for referring to a parameter defined in the class. Parameters are similar to static variables in Java.

https://docs.intersystems.com/irisforhealth20221/csp/docbook/DocBook.UI....

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 happens if you try this?

w $zdateh(x,1) > $zdateh(y,1)

Fortunately it's a simple issue. In your CALL action, you need to add a "Request Action" and set callrequest to the object you want to send to the BO. It looks like you're just modifying the inbound request so you could just set callrequest to request.

You can put something similar to Jeffrey's logic directly in the Value of the Set action. Instead of using $E ($EXTRACT) you would use DTL's built-in SubString function:

..SubString("123456789",1,3)_"-"_..SubString("123456789",4,5)_"-"_..SubString("123456789",6,9)

Since this is a new design you should use persistent classes (SQL tables/objects) instead of writing directly to globals. A Data Transformation can use any persistent class as it's target, so this is also easier than storing directly in globals.

https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI...