I'm confused, it seems that the error you have posted it's not from the Business Operation with the setting posted.

The error says that the "Reply Code Action" is ':?R=RF,:?E=S,:~=S,?A=C,*=S,:I?=W' while in your screenshot is E=F.

What was the "Reply Code Action" setting when the error occurred?

In addition, the two traces looks different, the first has a sync incoming request, the second async.

Is the Business Operation the same component/host?

I'm puzzled by the fact that the two $$$LOGINFO() are present in the trace when an exception should have raised BEFORE the $$$LOGINFO().

The code posted is not the code that generated that trace. And this is very confusing.

Maybe the code was modified without restarting the Business Operation?

..Adapter.Credentials.Username and ..Adapter.Credentials.Password

Credentials property of EnsLib.FTP.InboundAdapter is %String, so I expect an <INVALID OREF> error.

In general, I'd suggest to put your code inside a Try/Catch, something like:

	Set sc=$$$OK
	Try {
	    
	    ; your code here
	    
	} Catch CatchError {
		#dim CatchError as %Exception.SystemException
		Set sc=CatchError.AsStatus()
	}
	Quit sc

Using your code (simplified by me) from terminal it works fine using a sample CCDA from here.

set ccdaStream = ##class(%Stream.FileBinary).%OpenId("c:\temp\CCDA_CCD_b1_Ambulatory_v2.xml")
write "Size of CCDA Stream: ", ccdaStream.Size,!
set xsltTransform = "SDA3/CCDA-to-SDA.xsl"
set tTransformer = ##class(HS.Util.XSLTTransformer).%New()
set tSC = tTransformer.Transform(ccdaStream, xsltTransform, .sdaStream)
if 'tSC write "Transformation to SDA3 failed with error ",$system.Status.GetErrorText(tSC),!
set fhirStream = ##class(%Stream.TmpBinary).%New()
set SDA3ToFHIRObject = ##class(HS.FHIR.DTL.Util.API.Transform.SDA3ToFHIR).TransformStream(sdaStream, "HS.SDA3.Container", "R4")
if '$isobject(SDA3ToFHIRObject.bundle) write "Failed to transform SDA3 to FHIR",!
do SDA3ToFHIRObject.bundle.%ToJSON()

The result/output is a pretty long JSON FHIR bundle with CCDA data (I didn't check the content!)

Does your code works with that sample CCDA?

If not, then maybe there is something wrong in your CCDA.

For my test I used: IRIS for Windows (x86-64) 2024.1 (Build 267_2U) Tue Apr 30 2024 16:35:10 EDT

To my knowledge and (more importantly 😁) according to the documentation, it's not possible.

The types of the arguments in the subclass method must be consistent with the types of the arguments in the original method. Specifically, any given argument must be either the same as the original type or a subclass of the original type. 

The method in the subclass can have more arguments than the method in the superclass.

Note that in your case the problem is not the number of parameters/arguments, it's the type of the arguments that does not match the superclass %OnNew() (implemented in %Exception.AbstractException) arguments type:

Method %OnNew(pName As %String = "", pCode As %String = "", pLocation As %String = "", pData As %String = "", pInnerException As %Exception.AbstractException = {$$$NULLOREF}) As %Status [ Private ]

One option could be:

Class test.Foo Extends %Exception.AbstractException
{

Method %OnNew(arg1 As %String, arg2 As %String, arg3 As %String, arg4 As %String, pInnerException As %Exception.AbstractException = {$$$NULLOREF}, arg5 As %String) As %Status
{
        quit ##super("some message")
}

}

Each DTL calls “ConstructClone” to make a copy of the message before making any changes to it. There will be hundreds of cloned-objects in case of hundreds of DTLs

Keep in mind that when you create a clone of an HL7 message using %ConstructClone() the segments ARE NOT CLONED.

Only modified segments will be replaced with the new modified segment content.
The storage of unmodified segments will be "shared" between the original HL7 message and the cloned message.

A little test do demonstrate it:

; open an existing message and see the storage
Set hl7msg=##class(EnsLib.HL7.Message).%OpenId(33)
zw ^EnsLib.H.MessageD(33)

^EnsLib.H.MessageD(33)=$lb("","","Demo.HL7.MsgRouter.Schema:ORM_O01",0,"2024-03-24 01:44:43.142","Demo.HL7.MsgRouter.Schema","C:\temp\hl7\in\XYZ1.txt"_$c(13,10)_" Document# 2, level 1, @Line 11","","",0)
^EnsLib.H.MessageD(33,"segs")=9
^EnsLib.H.MessageD(33,"segs",1)="8480,161"
^EnsLib.H.MessageD(33,"segs",2)="8480,162"
^EnsLib.H.MessageD(33,"segs",3)="8480,163"
^EnsLib.H.MessageD(33,"segs",4)="8480,164"
^EnsLib.H.MessageD(33,"segs",5)="8480,165"
^EnsLib.H.MessageD(33,"segs",6)="8480,166"
^EnsLib.H.MessageD(33,"segs",7)="8480,167"
^EnsLib.H.MessageD(33,"segs",8)="8480,168"
^EnsLib.H.MessageD(33,"segs",9)="8480,169"


; create a clone, save it and see the storage
Set hl7msgClone=hl7msg.%ConstructClone()
Write hl7msgClone.%Save()
Set CloneId=hl7msgClone.%Id()
zw ^EnsLib.H.MessageD(CloneId)

^EnsLib.H.MessageD(37)=$lb("","","Demo.HL7.MsgRouter.Schema:ORM_O01",1,"2024-03-24 01:44:43.142","Demo.HL7.MsgRouter.Schema","C:\temp\hl7\in\XYZ1.txt"_$c(13,10)_" Document# 2, level 1, @Line 11","","",0)
^EnsLib.H.MessageD(37,"segs")=9
^EnsLib.H.MessageD(37,"segs",1)="8480,161"
^EnsLib.H.MessageD(37,"segs",2)="8480,162"
^EnsLib.H.MessageD(37,"segs",3)="8480,163"
^EnsLib.H.MessageD(37,"segs",4)="8480,164"
^EnsLib.H.MessageD(37,"segs",5)="8480,165"
^EnsLib.H.MessageD(37,"segs",6)="8480,166"
^EnsLib.H.MessageD(37,"segs",7)="8480,167"
^EnsLib.H.MessageD(37,"segs",8)="8480,168"
^EnsLib.H.MessageD(37,"segs",9)="8480,169"

; as you can see the new cloned message shares exactly the same segments of the original HL7 message

; modify a segment in the cloned HL7 message, save it and see the storage

Write hl7msgClone.SetValueAt("NEWVALUE","MSH:3.1")
Write hl7msgClone.%Save()
zw ^EnsLib.H.MessageD(CloneId)

^EnsLib.H.MessageD(37)=$lb("","","Demo.HL7.MsgRouter.Schema:ORM_O01",1,"2024-03-24 01:44:43.142","Demo.HL7.MsgRouter.Schema","C:\temp\hl7\in\XYZ1.txt"_$c(13,10)_" Document# 2, level 1, @Line 11","","",0)
^EnsLib.H.MessageD(37,"UserValues")=""
^EnsLib.H.MessageD(37,"segs")=9
^EnsLib.H.MessageD(37,"segs",1)="8992,2"
^EnsLib.H.MessageD(37,"segs",2)="8480,162"
^EnsLib.H.MessageD(37,"segs",3)="8480,163"
^EnsLib.H.MessageD(37,"segs",4)="8480,164"
^EnsLib.H.MessageD(37,"segs",5)="8480,165"
^EnsLib.H.MessageD(37,"segs",6)="8480,166"
^EnsLib.H.MessageD(37,"segs",7)="8480,167"
^EnsLib.H.MessageD(37,"segs",8)="8480,168"
^EnsLib.H.MessageD(37,"segs",9)="8480,169"

; as you can see now the first segment is different, all other segments use the same storage as the original message

The storage and I/O overhead of the cloning performed by DTL is minimal and limited the the strictly necessary modifications.
Of course if you change all the segments content, then all segment will be replaced, there is no options, but more often than not, DTL modify a limited number of segments.

ISO 8601 date format is not an accepted format for the SQL DATEPART function.

You can check the supported formats in the DATAPART SQL Documentation.

If I remove the trailing Z (for Zulu / UTC time) and leave the T, DatePart works fine

I'm afraid it does not woks fine:

select 'YEAR: '||DATEPART(YEAR,'2024-06-23T06:03:00') 

result:

YEAR: 1900

Try:

select 'YEAR: '||DATEPART(YEAR,$TRANSLATE('2024-06-23T06:03:00Z','TZ',' '))

In my opinion, if you need to encode a file/stream "as is", without any conversion, so that the counterpart receiver get EXACTLY what your source file/stream is/was, then use %Stream.FileBinary.

If you need some character conversion (say, Unicode/UTF8 or others), then use %Stream.FileCharacter (with appropriate parameters...) that can handle the conversion.