The ORC group is repeating, and all of it's child segments are optional, so you can iterate through the ORC group in order to get at the OBRs that it contains.

But... you can also just set the DTL create mode to "copy" and all of the segments will get copied over automatically without needing to iterate through each ORC.

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

There are some open source tools that can convert from XLSX to CSV. You could call out to these from your ObjectScript code:
https://csvkit.readthedocs.io/en/latest/tutorial/1_getting_started.html#...
https://stackoverflow.com/questions/10557360/convert-xlsx-to-csv-in-linu...

Here's information on the Python library for working with .zip files:

https://docs.python.org/3/library/zipfile.html#zipfile.ZipFile.open

"#" 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)