I'm reasonably confident this will fix the issue without any side effects ...

TIE> Set ^Ens.Queue("ClinicomMsgRouter",0,"count")=0
TIE> Set ^Ens.Queue("PathologyRouter",0,"count")=0

Hi Ed,

If you have the Show Query option enabled in Message Viewer, you can build your criteria for extracting the message data there, then click the button to see the SQL it generates. The default EnsLib.HL7.SearchTable indexes the Patient ID, but it includes PID:2.1, PID:3.1 (all iterations) and PID:4.1 (all iterations). If you're searching for specific IDs or ranges you may get unintended duplicates.

You don't need a custom SearchTable to filter the messages, but it sure helps.

If you don't have it enabled, you can turn it on for your production's namespace:

USER > zn "PROD"
PROD > set ^Ens.Debug("UtilEnsMessages","sql")=1

The Message Viewer is a powerful tool and gives you access for query and display of every HL7 field. The SQL it generates should put you on the right track.

So when you select the queue in the Queues page, it shows no messages in the Queue Contents column?

The "N" parameter always creates a new file. If you want to open a file (optionally creating it if it doesn't exist), use "E" instead,  and if you intend to Append to it, include the "A" parameter: open file:("EWA"):1. You don't need the "R" parameter unless you intend to read from it using the same device.

Depending on your Cache configuration, you may not even need the "E" parameter. The default behavior in my Windows installation is to create the file if it doesn't exist, with or without the "E" parameter (the documentation refers to "E" as  "UNIX-only", FYI).

Adding categories will  have no direct impact on message processing. As you noted, there may be a tiny incremental increase in overhead temporarily if you query for them, and you may see a slight delay in the drop-down list ... but only if  you're talking about multiple hundreds of them.

If the intent is to better document your interfaces, though, take a look at the Business Partner configuration. It's an often-overlooked option to keep details regarding the vendor, its contacts, and other information associated with each interface. This may help make the number of categories more manageable.

As @Eduard.Lebedyukpointed out, the method should return a status as indicated by its signature, so at the very minimum you should have a "Return $$$OK" at the end of the method.

That said, %FromJSON() throws an exception when it fails, and the generic error you'll get in the Event Log won't tell you (or your support team) much. You may want to wrap a try/catch around the call to %FromJSON() so that you can return a status that provides a little more insight:

    ...

    Try {
        set tJSON = {}.%FromJSON(pInput)
    } Catch {
        Return $$$ERROR($$$GeneralError,"Badly formed JSON")
    }

...

    Return $$$OK
 }

The ReadLine() method of %FileCharacterStream defaults to a length of 32K.

Have you tried simply passing the stream object, pInput, as the argument to %FromJSON()?

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

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.

Ah, I see. For some reason I assumed you were attempting to NACK based on un-routed messages.

Did you configure the Response From value in the Business Process to specify the Business Operation from which you want the NACKs relayed?

Are you attempting to do this with a routing rule, a BPL, or some other custom BP type? I don't believe you can do what you want directly with a routing rule.

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.

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:

W $ASCII("•")

8226 

W $CHAR(8226)

•