Yes, pretty sure, that is what is taught in the ISC training courses and what the documentation says:

Description ($PROPERTY)
Property names are case-sensitive

Selecting Fields
Field names in a SELECT statement are not case-sensitive. SqlFieldName names and property names are case-sensitive.

Rules for Class Member Names
Note that the system preserves the case that you use when you define classes, and you must exactly match the case as given in the class definition. However, two class members cannot have names that differ only in case. For example, the identifiers id1 and ID1 are considered identical for purposes of (uniqueness.)

REST code write the response to the current device.

An idea (to be tested) could be to intercept the calls in early stages, save the current device and change the current device to "some other device" (to be defined), then, after the code has finished, save the output to your log and switch to the "old" current device and write the output.

I think it can be done, it surely have some performance impact but...maybe feasible.

It has been very interesting and, as usual, keeping in touch with old fellows as well meeting new ones is the most valuable think of the conference.

And, HEY! only 10 month to the next conference!
Washington DC from 27th to 29th of April!

Please note that next conference will start with the Welcome Reception on Monday (usually Sunday).

I'm looking forward to meet you all in DC! 😊

Please provide more context and details when you post questions.

To get the request submitted body (if any) you can use the Content property of the %CSP.Request object (i.e. %request).

For the response it's not possible, the response is "sent to the browser" (via Web Gateway....) immediately, there is no buffer or anything.

If you want to capture YOUR response, put it in a buffer and when you are done, send it from your buffer "to the browser"

Hi @Benjamin De Boe, this is GREAT news, it's going to be EXTREMELY useful in many environments I'm working with. I fully agree with you that most of the times exporting statistics from a development environment to a production environment is not advisable, so much so that I've created an entry in the Ideas Portal to give us the option to disable exporting statistics (i.e. use /exportselectivity=0 qualifier) when exporting production component.
Note that at the moment is not possible to export without including statistics when exporting a Production or Production components and this a pity, therefore I created the Idea:

Do not include table statistics when exporting Production for deployment

I encourage anyone that agree or is interested to vote for ti! 😊

No, it doesn't.

If the variable String contains a Base 64 encoded HL7 message, then:

    Set HL7MessageResponse=##class(EnsLib.HL7.Message).ImportFromString($system.Encryption.Base64Decode(String),.sc)
    ; handle sc error here
    Set DocType=##class(EnsLib.HL7.Schema).ResolveSchemaTypeToDocType(HL7MessageResponse.TypeVersion,HL7MessageResponse.Name)
    Set sc=HL7MessageResponse.PokeDocType(DocType)
    ; handle sc error here

After that, the variable HL7MessageResponse is an instance (OREF, object reference) of an Ens.HL7.Message with proper DocType, Name, etc. that you can use as HL7 response back to your HL7 BP Router.

What's the datatype of the HL7 message in SendMessageRespose?

I assume that the HL7 message in SendMessageRespose is a %String.

String variable contains the HL7 message, then:

    Set HL7MessageResponse=##class(EnsLib.HL7.Message).ImportFromString(String,.sc)
    ; handle sc error here
    Set DocType=##class(EnsLib.HL7.Schema).ResolveSchemaTypeToDocType(HL7MessageResponse.TypeVersion,HL7MessageResponse.Name)
    Set sc=HL7MessageResponse.PokeDocType(DocType)
    ; handle sc error here

From the ISCSOAP log it's evident that the the content of encodedMessage property/tag is not the encoded HL7 raw message but it was assigned with an oref (object reference, an object instance) of the osuwmc.Nutrition.OSU.CBOARDNetMenuRequest.SendMessageRequest class.

This is not what the code you posted is doing, so I guess the actual code is different or the encodedMessage property is set to an oref after the code you posted.

It looks like somewhere after that code there is a:

Set CBORDRequest.encodedMessage=CBORDRequest

Beside that, my curiosity:

set a = $SYSTEM.Encryption.Base64Encode((pMsgOut.RawContent))
Why two parenthesis?

set CBORDRequest.encodedMessage = $Get(a)
Why using $Get for a variable that is indeed/for sure defined?