Reputation: 380
I'm new in mirth so sorry if my question may seems naive. I've a mirth channel that recives hl7 messages, and this is fine, also I've some filters and transformers both in Source and Destination.
When all is fine at the end of destination I send an ACK with a message, for this for this purpose I've made this function in code Templates:
function getAck(success, detailMessage, statusMessage) {
if (!detailMessage)
detailMessage = success ? "Operation completed successfully" : "Some error occours";
if(!statusMessage)
statusMessage = detailMessage;
if (success) {
ack = ACKGenerator.generateAckResponse(connectorMessage.getRawData(), "AA", detailMessage);
resp = new Response(com.mirth.connect.userutil.Status.SENT, ack, statusMessage);
} else {
ack = ACKGenerator.generateAckResponse(connectorMessage.getRawData(), "AE", detailMessage);
resp = new Response(com.mirth.connect.userutil.Status.ERROR, ack, statusMessage, detailMessage);
}
return resp;
}
So I use ACKGenerator.generateAckResponse for creating an Ack and Response for send response at client. This work but only in destination and that's my problem. If I get an error before destination (e.g. in filters, transformer, ...) I don't be able to stop execution and send an NACK with an explaination of the error and this is what I would like to do. Am I wrong doing things in this way?
Upvotes: 2
Views: 2900
Reputation: 11
There are filter and transformer in the "Source" tab. If your expecting an error there or on other destinations, you could try:
Note: You'll need to disable the default response in your original channel since you have the other channel that'll forward the ACK/NACK. You'll also need to consider if the client's machine expects a valid ACK/NACK immediately when they sent the HL7 message, depends on their setup.
Upvotes: 1
Reputation: 1729
You can store a Response in the responseMap in any filters or transformers. Once you define a key in the responseMap, it should be available as a selection in the response drop down on the source tab of your channel (instead of picking a destination.)
Your current connector should stop processing a message with an ERROR status if you manually throw
an exception after setting the desired value in the responseMap. If you are in a filter, you could also filter the message instead of throwing the exception.
If you are worried about an uncaught exception, you could initialize the responseMap variable with an "Unknown Error" message at the first point in the channel where your custom code is defined that affects messages directly (likely the source filter from your description, but could possibly be the pre-processor or attachment handler if you use those.) The expectation is that this would be replaced with a more descriptive error or a success if the message makes it all the way through to the end, but the channel will always have something to return.
Upvotes: 1