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.

Have a look at the IO-Redirect application in Open Exchange.

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',' '))

Why do you say the stream is typically a binary stream?

Because a Charecter Stream may introduce additional character set conversion.
In your case it seems your stream is a MS Word docx document file, that's a binary file (it's a zip file) and no character set conversion is needed nor wanted, you just take the "raw" content (i.e. binary content) and encode it in base64 when included in JSON/Dynamic Object.

Please note that the code:
Do obj.%Set("data",pStream,"stream>base64")

already encode the pStream content to base64! If you pass a base64 encoded stream, you'll end up with double base64 encoding!

Its' my understanding that all you need is to load a docx file into json/dynamiy object, then all you need is:

Set obj = {}
Set pFile = "/ICS/jira/wgetDATA1343.docx"
Set pStream = ##class(%Stream.FileBinary).%OpenId(pFile)
Do obj.%Set("data",pStream,"stream>base64")

The base64 encoding is performed using the "stream>base64" type parameter, here is the class reference documentation for the %Set() method.
This is much more efficient and easier to read.

Well...I did not read the AI answer with attention, there are a few mistakes in the answer.

Base64Stream should be a stream (typically a binary stream), not a string as in the AI sample, let alone the fact that in the sample code Base64Stream is NOT base64 encoded.

But.....almost correct. 😊

Community AI is on spot!

👏👏👏👏

I'm afraid there are no Python wheel in WRC OnlineDistribution (where is it supposed to be? Not in Components...), but is indeed in the dev/python directory after you install IRIS.

So, I believe that to get the latest wheel, you need to install the latest IRIS and go to the  dev/python directory  of your IRIS installation.

As @Jon Willeke wrote in his post:

2023.1.2 shipped with the 3.2.0 and 4.1.0 wheels in the dev/python directory

It's in the dev/python directory of your IRIS installation. It's in your system.

Yes, I think it is, that's why I proposed to change the DEFAULT view to list view.

THIS causes the ![CDATA[ in a string field!

This causes the CDATA in the visualization of a string field in the Management Portal.
The string field does not contain any CDATA (unless assigned in the string property content).

I don't understand your problem, in fact, are you having a problem or you just think there is a problem?

The purpose is to avoid the huge amount of source-target DTL processes while working with several hundreds of Rules 

First, rules do not modify messages, only DTL may modify a message.
Did you measured and verified this supposed "huge amount" or you think/guess this is actually happening? 

Please note that HL7 storage is complex/advanced and very efficient, only changed segments are actually duplicated in storage, even from different HL7 messages.
Did you actually checked what is actually stored in your scenario?

I feel and believe that you are looking for a solution to a non existent problem.

Sorry but, again, you are missing important context and details.
With some imagination, fantasy and creativity I can guess the missing info....

What class does your AthenaChangeDataSubscription class exstends?
I guess Ens.Request or %Persistent and %XML.Adaptor and possibly others, this is crucial info.

Where do you see the ![CDATA[ ? (I asked, you did not answer)
I guess from the picture you post you see it in the Contents viewer in Visual Trace, again, this is crucial info.

Now, to your original question:
What causes the ![CDATA[ in a string field?

The CDATA is not in your string property, it is only in the visualization in the portal of the content of your class/property.

Here is a sample request that, I imagine, is similar to your class:

Class Community.msg.AthenaChangeDataSubscription Extends Ens.Request
{
Property QueryParameters As %String;
}

Here is what the IRIS Interoperability portal is using to display the content:

EPTEST>Set msg=##class(Community.msg.AthenaChangeDataSubscription).%New()
 
EPTEST>Set msg.QueryParameters="showportalonly=1&leaveunprocessed=0&limit=5000"
 
EPTEST>Set sc=##class(EnsPortal.MessageContents).writewithoutNonXMLChars(,msg)
<AthenaChangeDataSubscription xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><QueryParameters><![CDATA[showportalonly=1&leaveunprocessed=0&limit=5000]]></QueryParameters></AthenaChangeDataSubscription>
EPTEST>w msg.QueryParameters
showportalonly=1&leaveunprocessed=0&limit=5000
EPTEST>

As you can see the ACTUAL CONTENT of your QueryParameters property does not have any CDATA, the XML VISUALIZATION of your property content does have CDATA, and that's because it is required by XML to properly display the real/actual content.
The IRIS interoperability portal display the XML representation of your class and does it in the proper/correct XML representation.

If your property contains simple text that can be properly (correctly) "rendered" in XML without CDATA, then:

EPTEST>Set msg=##class(Community.msg.AthenaChangeDataSubscription).%New()
 
EPTEST>Set msg.QueryParameters="this is a simple content"
 
EPTEST>Set sc=##class(EnsPortal.MessageContents).writewithoutNonXMLChars(,msg)
<AthenaChangeDataSubscription xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><QueryParameters>this is a simple content</QueryParameters></AthenaChangeDataSubscription>

As you can see there is no CDATA.

Please, please, in the future, provide details of the context.
Imagination, fantasy and creativity should not be a requirement to understand a question.