You can use the auxiliary property (aux attribute) of the <subtransform> DTL element to pass the index of the group to process to the subtransform, passing the entire source message as source object.

Hadn’t used it since Ensemble 2009 ;-), to provide custom html output displayed by the management portal when viewing a message of a class extending Ens.MessageBody, you can override the %GetContentType() and %ShowContents() methods of Ens.Util.MessageBodyMethods in your message class.
Here is a small example :

Class dc.sample.msg.Message Extends Ens.MessageBody
{

Property Name As %String [ InitialExpression = "you" ];

// returns MIME content type
Method %GetContentType() As %String
{
    return "text/html"
}

// output content
Method %ShowContents()
{
    &html<<p>Hello,&nbsp;#(..Name)#</p>>
}


Storage Default
{
<Data name="MessageDefaultData">
<Subscript>"Message"</Subscript>
<Value name="1">
<Value>Name</Value>
</Value>
</Data>
<DefaultData>MessageDefaultData</DefaultData>
<Type>%Storage.Persistent</Type>
}

}

In the management portal message viewer, the message gets displayed as :

What is the class of config item ‘TEST_ROUTER’ ?

Maybe not EnsLib.HL7.MsgRouter.RoutingEngine, which exposes the HL7 property.

The curly brace syntax "source.{PID:12}" is not supported in code action as the block is included as is in the class code generated at compile time. Use GetValueAt() to achieve the same effect :
 

Set country = source.GetValueAt("PID:12")

You can use $classmethod to invoke any class method, including %New, e.g. 

set cls = "MyPackage.MyClass"
set obj = $classmethod(cls,"%New")

Hi,
To summarize the documentation :

• ReplyCodeActions settings of HL7 operations is a comma-separated list of specifiers in the form <code>=<actions>, where <code> is an expression matching error condition(s) and <actions> is a string of one letter action codes.
• All codes where <actions> consists of only 'W' (for 'log a Warning') will be evaluated, and a warning will be generated for each matching <code>.
• Other <code> values will be evaluated in left-to-right order, executing the first matching <code> that has a non-warning <actions> value. As noted in the details for the 'W' flag, an error that only triggers 'W' <actions> will be treated as Completed OK.
• if ReplyCodeActions is empty, a default setting is used. For HL7 operations, it is : 

  • :?R=RF,:?E=S,:~=S,:?A=C,:*=S,:I?=W,:T?=C

To match the application reject code in the HL7 ACK^O01 message in the example, and suspend all matching messages, use the following specifier, that matches all ACKs with MSA:1 = "AR" and suspend message, while retaining default behavior for other error conditions : 

:?R=S,:?E=S,:~=S,:?A=C,:*=S,:I?=W,:T?=C

As Enrico mentions, HL7 v2 message grammars, segment structures and data type syntaxes are available in IRIS schemas. Complete specifications and semantics are detailed in the normative documents available  on HL7.org web site.

EnsLib.HL7.Service.HTTPService may suit your needs : it implements reading HL7 message from incoming HTTP request.

To clean pending messages and other suspended production data, you can use Ens.Director.CleanProduction() method, as explained in the documentation. Caution though, this will delete current production state, including removing message headers (Ens.MessageHeader instances) from queues.
 

Hi,

Using out-of-the-box classes in the EnsLib.HL7 package, you can either completely ignore responses, either process them synchronously. More complex scenarios involving multiple responses (ack/nack) are supported (see Important HL7 Scenarios | Routing HL7 Version 2 Messages in Productions | InterSystems IRIS for Health 2023.1
), but I think they do not match your supplier requirements.
According to the standard, when sending multiple HL7 v2.x messages over MLLP/TCP, the sender (initiating module) must wait for a response before sending the next message. This is described in  "Health Level Seven Implementation Support Guide", Appendix C, section  C.6.4, item 5. : 
It is assumed that an initiating module may connect and perform more than one message transaction before disconnecting, but it may not have more than one outstanding message waiting for a response.  In other words, the initiating task must wait for the response to a given message before sending another message.
This vendor requirement to receive multiple messages before sending responses is thus non-standard. It would require the sender to keep track of sent messages with a pending response, handle asynchronous replies and retry errored messages.
While this is possible by writing custom adapter/operation extending the out-of-the-box classes in EnsLib.HL7 package, it would add a lot of complexity and has IMHO, little added value compared to the usual synchronous implementation.