New post
AllAccepted answers
Jeffrey Drumm · May 19, 2019

The only reason I can think of doing it the way it was done is that there was no expectation by the original author of the code that the JSON object would be larger than 32KB. It's also possible that he/she was unfamiliar with the types of objects that %FromJSON() works with and always assumed it was a simple string ... which is what the ReadLine() method returns.

Here's the documentation for for the %FromJSON() method.

Jeffrey Drumm · Apr 16, 2019

Probably something like this (I'm not sure of the full name of the osuwmc.PatientBilling... class, and you probably want to do some sort of exception handling or at least error checking):

       set callrequest = ##class(osuwmc.PatientBilling.DataStructures.SelectResearchID).%New()

       set callresponse = ##class(EnsLib.SQL.Snapshot).%New()

       set callrequest.ResearchID = context.RschMRN

       do process.SendRequestSync("PatientBillingDBPoll", callrequest, .callresponse)

       set context.ClarityRS = callresponse

The default behavior of SendRequestSync is to never timeout, but you can always include a -1 as the 4th parameter to be a bit more descriptive.

Jeffrey Drumm · Apr 12, 2019

Hi Scott,

I've accomplished this in the past by calling the SQL Operation with the SendRequestSync() method in a <code> action rather than using the <call> action. The default is to wait until the response is received.

This will be problematic if you must maintain FIFO (thus setting the Pool Size to 1), since the BPL will stop processing until the response is received. And increasing the pool size could have undesirable side effects other than loss of FIFO ... so you're likely to see horrible message latency at times given the metrics you're reporting.

EDIT: Stelios of course beat me to it ... I stepped away from the keyboard before hitting the Publish button and only realized it some hours later laugh

Jeffrey Drumm · Apr 12, 2019

If each Encounter element in the document contains all of the data necessary to create your individual HL7 messages, you could potentially use the EnsLib.XML.Object.Service.FileService (or FTPService) class for a Business Service that will "chunk" the document into individual Encounter documents. Those would then be mapped to HL7 via a routing rule and DTL ... no BPL required. You'll need to create an Encounter class that matches the Encounter element structure; this will be used subsequently for creating routing rules and DTLs.

Jeffrey Drumm · Apr 9, 2019

I guess it's worth trying, but I have a gut feeling that it won't work. If it doesn't ...

You could accomplish this in a BPL, but you would have to build the response logic from the BO along with the filtering/routing logic.

You could alternately create a custom BO that simply generates NACKs and set the send target in your otherwise to that ... just override the OnMessage() method:

Class HICG.HL7.Operation.NackFactory Extends Ens.BusinessOperation
{

Parameter INVOCATION = "Queue";

Method OnMessage(pRequest As EnsLib.HL7.Message, Output pResponse As EnsLib.HL7.Message) As %Status
{
    Set pResponse = ##class(EnsLib.HL7.Message).%New()
    Set pResponse.DocType = "2.3.1:ACK"
    Do pResponse.SetValueAt(pRequest.GetValueAt("MSH"),"MSH")
    Do pResponse.SetValueAt("ACK","MSH:9")
    Do pResponse.SetValueAt("MSA|AE|"_pRequest.GetValueAt("MSH:10")_"|No Destination","MSA")
    Do pResponse.%Save()
    Quit $$$OK
}

This is obviously not robust code, but it does generate a NACK as a response object for every message sent to it, and if the BP is configured to forward responses from the Production BO created based on this, you'll get what you're looking for.

Jeffrey Drumm · Mar 28, 2019

Eduard, are you referring to the Priority property of the Ens.MessageHeader class? That seems to be used exclusively for marking the message for Async vs. Synchronous delivery.

The need for message prioritization within a single message flow (one that would otherwise be FIFO) is valid and has been addressed in other integration products. One healthcare use case that I've encountered in multiple implementations is that the downstream system uses a session-oriented connection ("always on" MLLP) and receives both ADT and lab orders over the same connection. As the patient demographic data and "stat" lab orders should always be prioritized over routine order messages, a "high" priority value would be set for those messages during in-engine routing/transformation processing and would be a primary selection criteria for the process (eWay/Connection Point/Communication Client) to deliver it to the receiving system.

Given modern hardware and software, latency caused by the integration engine itself is rarely an issue. However, not all applications can receive messages as fast as integration engines can send them ...

Jeffrey Drumm · Mar 27, 2019

I created a new user with the %Developer role and verified that the class could be debugged successfully. I then added the %SecureBreak role to that user and encountered an issue similar, but not identical to the one reported by @Rueben Van Mol and @Donna.Goodall:

<COMMAND>zDebugStub+30^%Debugger.System.1
Invalid debugger target: ##class(Blue.App.Handler.Absolut).TestConnection()
Target has exited debugger

Jeffrey Drumm · Mar 27, 2019

I've copied your class into my local environment and am not getting any errors using the Studio debugger.

Cache for Windows (x86-64) 2018.1.2 (Build 309U) Mon Mar 4 2019 15:05:44 EST [HealthShare Modules:Core:15.032.9020 + Linkage Engine:15.032.9020]

Class Blue.App.Handler.Absolut Extends %RegisteredObject
{

ClassMethod TestConnection()
{
    w "ok"
    q
}

}

Debugger executing '##class(Blue.App.Handler.Absolut).TestConnection()'
Executing ##class(Blue.App.Handler.Absolut).TestConnection()
ok
Program has terminated.
Target has exited debugger

Jeffrey Drumm · Mar 21, 2019

Scott,

The challenge here is defining what is "long enough enough for a response." One option is to wait forever, but that will have the effect of processing no further messages until the call completes. That can lead to resource contention and race conditions that could be unacceptable in a healthcare setting.

Better to set a timeout and then take some action when the operation fails to complete. Here's a COS example that could be used in a <code> activity in place of a <call>:

set callrequest.ResearchID = context.RschMRN
do process.SendRequestSync("PatientBillingDBPoll", callrequest, .callresponse, 60)
if ('$ISOBJECT(callresponse)) {
   // handle the timeout in here; suspend the message, perhaps?
} else {
   set context.ClarityRs = callresponse
}

This will wait 60 seconds for a response, and if none is received perform the actions in the 'if' consequence.

Jeffrey Drumm · Mar 13, 2019

No, you can't use operands for date math with the "stock" file business service.

I'm assuming that you want to guarantee that only completed txt files are picked up by the business service. In that case, you'll probably want to use the EnsLib.RecordMap.Operation.BatchFileOperation Business Operation class, and update your Record Map to include (and generate) an "empty" batch class.

You can then specify an intermediate file path in the operation's config that will hold the current day's records until the rollover schedule criteria is met. At the scheduled time, the accumulated records in the intermediate file path will be moved to the destination file path and name specified in the config.

Batch class definition:

Sample configuration for EnsLib.RecordMap.Operation.BatchFileOperation, with additional settings required to enable batch rollover:

Jeffrey Drumm · Mar 12, 2019

I actually gave  you half of the answer in my previous comment, but it was easy to miss ... laugh

The Target variable of the DTL will contain the value to which you'll set the callrequest property of the <call> activity:

EDIT: You don't really need to use the request builder for this. Just click on the "+" after Request Actions,  select "set", then select the property and value from their respective drop-down lists.

Jeffrey Drumm · Mar 12, 2019

Yes, it makes sense to set the request class to EnsLib.HL7.Message. However, the response class as Ens.Response is fine since you don't need to create anything to send back to the source business service. Here's a sample Context configuration for the BPL:

To get the segment count for the DG1s, you'd use the GetValueAt() method of the EnsLib.HL7.Message class, and assign it to a context variable. For this you would use the same notation as you would use in the DTL editor to get the segment count:

In COS, a non-zero value is treated as true, so you can use the variable to which you've assigned the count of DG1 segments as the condition for the <if>:

Finally, the context.DG1rec variable from the BPL's Context tab screenshot above was assigned to the record map class used to define the delimited structure. This variable is later used as the Target for the DTL and the value to which the <call> activity's callrequest was set.

I used the same record map class in the Business Operation (BO defined as class type EnsLib.RecordMap.Operation.FileOperation) for the RecordMap field:

This BO will roll over to a new file at midnight each night.