Size 201 181 181, all unit tests passed (including undefined argument, and additional .Type("abc,de","de,abc") --> Unsorted)
Thanks Eduard, I missed the extraneous quotes (my mind is still not entirely purged of strongly typed languages habits 😅)

ClassMethod Type(a...) As %String
{
 f i=$i(r):1:$g(a){f j=1:1:$l(a(i),","){s l=$l($tr($p(a(i),",",j)," ")),c=$g(c,l),r=$s(l=c:r,r<3*l>c:2,r#2*c>l:3,1:4),c=l} k c} q $p("Constant1Increasing1Decreasing1Unsorted",1,r)
}

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

Yes, ^SPOOL is the simplest way to achieve this. If you need a string rather than a global, you can just get all lines from ^SPOOL, for example :

ClassMethod ZWriteToString() As %String
{
 #Dim result as %String
 #Dim i,lineCount as %Integer
 
 kill ^SPOOL($j)
 open 2:$j
 use 2
 zwrite
 s result=""
 s lineCount=$select($data(var):$za-1,1:$za-2)
 close 2
 for i=1:1:lineCount s result=result_^SPOOL($j,i)	
 return result
}

You can pass the value to the DTL using the transformation auxiliary parameter, as described in the documentation : Working with Rules | Developing Business Rules | InterSystems IRIS for Health 2023.3.

To pass the source configuration name : 

After enabling case-sensitivity in Windows, it is indeed possible to keep the original storage names.

Unfortunately,  enabling the flag has no impact on the behaviour of Windows versions of git or vscode, they continue to use case-insensitive comparisons for file names. For example, it is impossible to stage / commit changes to the git repository, as file names differing only case are considered as a single file.

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.

Hi Evgeny,

If the operation class is using the mechanism in Ens.BusinessOperation to route incoming requests to the OnMessage() method, you can use the XData content to get a list of supported request (just as the Portal testing dialog does). If the operation class implements it’s own custom OnMessage(), there is no simple way to tell what request classes are supported. The XData is described in the documentation.

For responses, there is a RESPONSECLASSNAME parameter defined in classes extending Ens.Request. I believe this used by the BPL editor. This is somewhat limited however, since the operation can as well respond with any %RegisteredObject object and accept any kind of request (via OnMessage), e.g. any class extending %RegisteredObject if it is marked as "in process".

Anyways, as Robert C. points out, documenting what the operation intent is and it's interface, especially if they are not trivial, helps a lot and IMHO is best practice.