As you noted, fromDao is in the HS.FHIRModel classes, but in the code you pasted you're actually using a class under HS.FHIR:

Set cls = $CLASSMETHOD("HS.FHIR.DTL.vR4.Model.Resource.Patient","fromDao",dao)

I think you want to do this instead:

Set cls = $CLASSMETHOD("HS.FHIRModel.R4.Patient","fromDao",dao)

https://docs.intersystems.com/irisforhealth20241/csp/documatic/%25CSP.Do...

How confident are you that nothing has changed in the NACKs being returned by the remote system? Is it possible that the value in MSA:1 used to be something other than AE? Is it possible that previous NACKs didn't have an MSA segment?

In the HL7 code table for MSA:1, "AE" indicates an error, so IRIS considers that an error and triggers the rule "E=F".

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

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

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.