We have a BizTalk 2010 solution where we receive an HL7v2 message over MLLP using a request/response receive port. An orchestration processes the message, calls a web service and returns a custom ACK to the client. Seems to work well.
In testing, I created 2 scenario:
An error would occur when generating the ACK
An error would occur when sending the ACK to the client via the send pipeline of the request/response receive port. I did this by incorrectly setting a configuration parameter on the send pipeline.
My orchestration contains scope and catch blocks so that I don't end up with suspended messages in the messagebox. Essentially if there are errors, we just want to log them, there's nothing we can do to remediate so suspended messages are unnecessary and clutter the messagebox. In my testing scenarios, if errors occur then the ACK does not get sent to the client, and althouth the orchestration completes, there is still a running service instance for the receive port. I imagine that is because the send pipeline is still subscribing to the ACK and waiting for it. Is there a way to avoid this or terminate the service instance somehow through the orchestration?
I'd suggest adding a fault message to the operation on the port and throwing a fault message out from your catch block.
Related
I have an orchestration that processes incoming messages that make a data call. If data is returned, a new message is created and sent back to the receive port via a "mover" BizTalk application. The original message is no longer needed, so I've been sending it to a discard folder. Is there a requirement in BizTalk that requires a message coming in to be sent out?
Each message that comes into BizTalk needs to be routed somewhere yes, otherwise it will suspend with a routing failure.
However as you are using an Orchestration, once it has consumed the message, and you don't need to send the original message anywhere from the Orchestration if you don't need it, when the Orchestration ends, that message will be gone
In message only scenarios, where you don't have an orchestration your options are
A file send port to a folder, where you have a script to clean them up
A null adapter on a send port, a null adapter is a custom adapter that takes the message from the message box and just discards it.
I've set-up two applications, one with FILE Receive Port and the other with a Send Port subscribing to that Receive Port with filter set as BTS.ReceivePortName == {ReceivePortNameHere}. I'm using BizTalk 2013 R2.
In the Receive Port, I'm using the pipeline 'BTAHL72XReceivePipeline'. And, in the Send Port, I'm using the pipeline 'BTAHL72XSendPipeline'.
When I drop a HL7 message into the Receive Port file location, it produces the error:
The Messaging engine failed to process a message submitted by
adapter:FILE Source URL:E:\InboundToBizTalk\*.hl7. Details:The
published message could not be routed because no subscribers were
found. This error occurs if the subscribing orchestration or send port
has not been enlisted, or if some of the message properties necessary
for subscription evaluation have not been promoted. Please use the
Biztalk Administration console to troubleshoot this failure.
However, I do have a subscription set. Why is this error occurring? Is there an issue with the pipeline component or the way I am using it?
On the Group Overview page search for "Subscriptions" and filter based on your Send port name.
Verify that you see an activation Subscription and confirm that the filter conditions on the subscription are correct.
The by far most likely causes:
A typo between the Receive Port Name and the value in the Filter.
The Send Port is not Enlisted or Started.
Do not use quotes in the filter property.
Turned out to be ACK which could not be routed therefore causing the whole flow to error. For an MLLP transport type, it is two way thus the ACK can be routed. For a FILE transport type, it is one way therefore ACK needs to be accounted for separately.
To get around this, another port was created which would subscribe to the ACK.
In my scenario, a client sends HL7 via MLLP to my BizTalk two way receive port. BizTalk makes a web service call to an external service, receives the response, translates it to an HL7 ACK and returns it to the client, all in a synchronous transaction.
To make this happen, I have an orchestration that is directly bound to the message box, and the BTAHL7 party configuration is set to not route the ACK to the send pipeline on request-response receive ports. Basically I'm turning off the default ACK generation and generating a custom ACK from my orchestration. I have also added an additional filter to my orchestrations receive shape BTAHL7Schemas.ParseError == false so that the orchestration does not receive bad messages, in the event received messages don't match the schema.
Everything works great. In my testing, I am purposely sending bad HL7 messages. In this case, I get a suspending routing error report because no subscribers were found.
The reason for this behavior is pretty clear - I am not subscribing to messages that have parse errors. In the event of a parse error, I want the error ACK to go back to the client. I could allow my orchestration to subscribe to messages with parse errors, and just formulate an error ACK, but I don't have any way to return the actual parse errors in the ACK.
Normally, in an asynchronous architecture, I would turn on the "Route ACK to send pipeline on request-response receive port" and let the BTAHL72X receive/send pipelines handle it. Then the client would get the error ACK containing the error details.
So my question is, is there any way to get the receive pipelines original ACK and return it from my orchestration?
Yes, what you what you want is certainly doable. I don't have an HL7 project in front of my right now so my memory may not be exact but something like:
Uncheck "Reoute ACK to send pipeline..."
You will need a custom pipeline component to Promote BTS.InterchangeID on the disassembler output.
In your Orchestration, implement a Convoy correlated on BTS.InterchageID.
The Orchestration will then pick up the HL7 Message and the auto generated ACK.
Do you normal processing.
Decide which ACK to return, yours or the generated.
Return ACK to the TwoWay port.
*Non custom pipeline solution: *
In BTAHL7 Configuration Explorer Acknowledgement tab:
Set Acknowledgement type to Enhanced
Set MSH15 (Accept Acknowledgement Type) to NE.
Set MSH16 (Application Acknowledgement Type to ER
Turn on Route ACK to send pipeline on request-response,
It appears to get the behavior I want. Success ACKs won't be generated by the pipeline, letting my orchestration handle it, but application ACK errors will be generated (AR - Application Rejection), and routed to the send pipeline.
I have an orchestration that takes a message. The target namespace is "http://microsoft.com/HealthCare/HL7/2X" and the root element is "ORU_R01_23_GLO_DEF"
In the orchestration, I map the message to an intermediate message type in a construct shape. The target namespace is "http://mycompany.com/myapplication" and the root element is "MyMessage". The "MyMessage" message is then further mapped and then sent to a web service using a logical send port in the orchestration. A WCF send port is then bound to the orchestration and everything works fine. Everything works as expected.
Without altering the orchestration, I want to create a send port that subscribes to the intermediate "MyMessage" message and writes it to a file. To do this, I have created a send port with a filter of BTS.MessageType = http://mycompany.com/myapplication#MyMessage.
Even though messages are flowing through the orchestration, my send port isn't picking up the message. Is this the incorrect filter to use?
Are you trying to subscribe to the 'MyMessage' message, or the same message that is sent to the logical Send Port bound to the physical WCF Send Port?
You have stated that:
The "MyMessage" message is then further mapped and then sent to a web service using a logical send port in the orchestration. A WCF send port is then bound to the orchestration and everything works fine.
Message not Published to MsgBox
From what you have described, I would suggest that you do not have a Send Shape/Logical Send Port combination in your orchestration for the 'MyMessage' message, which is why you can't manually subscribe to this message type in a Send Port filter. The fact that you have not mentioned a 'Failed Routing Report' message further suggests that this is the case - this message type is generated when no subscriotion can be found for a message that is to be published to the MsgBox.
Capture a Message's 'MessageType'
If however you need to capture a copy of the message your are sending over the WCF Send Port, you will need to determine its MessageType and use that in your second Send Port subscription that writes the message out to file.
If you are unsure as to what MessageType to use, there is a simple trick to determine this information:
Stop (not Unenlist) the WCF Send Port
Send a message through your orchestration as normal - the message will be marked as 'Suspended Resumable' in the BizTalk Admin Console on the WCF Send Port.
Open the message in the BizTalk Admin Console and view its 'Message Context'; in the Message Context you will see its 'MessageType' property which you can then use to understand which subscription filter to use.
Start the WCF Send Port to flush the message.
Alternatively, if you don't want to change your orchestration, you could try archiving your message as it passes through the Send Pipeline in the (original) WCF Send Port - either write your own archiving component or use an existing commercial component. By using an archiving component in this manner, you will save yourself the expense of an extra subscription and the associated Send Port maintenance.
Update:
It sounds very much like the OP is not sending the intermediate message to the Message Box from their Orchestration (see comments). Message subscription will only work when a message is published to the Message Box - in this case, the message in question ('Message B') is an intermediate message that only lives within the context & lifetime of the orchestration. The OP needs to Send the message to a Direct Bound port within the Orchestration to allow the message to be subscribed to via a Send Port.
Verify the pipelines of the Send Port. Should by XML, not Passthrougth.
I am trying to implement Reliable WCF Service with MSMQ based on this architecture (http://www.devx.com/enterprise/Article/39015)
A message may be lost if queue is not available (even cluster doesn't provide zero downtime)
Take a look at the simple order processing workflow
A user enters credit card details and makes a payment
Application receives a success result from payment gateway
Application send a message as “fire and forget”/”one way” call to a backend service by WCF MSMQ binding
The user will be redirected on the “success” page
Message is stored in a REMOTE transactional queue (windows cluster)
The backend service dequeue and process the message, completes complex order processing workflow and, as a result, sends an as email confirmation to the user
Everything looks fine as excepted.
What I cannot understand how can we guarantee that all “one way” calls will be delivered in the queue?
Duplex communication is not a case due to the user should be redirected at the result web page ASAP.
Imagine the case when a user received “success” page with language “… Your payment was made, order has been starting to process, and you will email notifications later…” but the message itself is lost.
How durability can be implemented for step 3?
One of the possible solutions that I can see is
3a. Create a database record with a transaction details marked as uncompleted, just to have any record about the transaction. This record may be used as a start point to process the lost message in case of the message will not be saved in the queue.
I read this post
The main thing to understand about transactional MSMQ is that there
are three distinct transactions involved in a transactional send to a
remote queue.
The sender writes the message to a local queue.
The queue manager on the senders machine transmits the message across the wire to the queue manager on the recipient machine
The receiver service processes the queue message and then removes the message from the queue.
But it doesn’t solve described issue - as I know WCF netMsmqBinding doesn’t use local queue to send messages to remote one.
But it doesn’t solve described issue - as I know WCF netMsmqBinding
doesn’t use local queue to send messages to remote one.
Actually this is not correct. MSMQ always sends to a remote queue via local queue, regardless of whether you are using WCF or not.
If you send a message to a remote queue then look in Message Queuing in Server Management you will see in Outbound queues that a queue has been created with the address of the remote queue. This is a temporary queue which is automatically created for you. If the remote queue was for some reason unavailable, the message would sit in the local queue until it became available, and then it would be transmitted.
So durability is provided because of the three-phase commit:
transactionally write message locally
transactionally transmit message
transactionally receive and process message
There are instances where you may drop messages, for example, if your message processing happens outside the scope of the dequeue transaction, and also instances where it is not possible to know if the processing was successful (eg back-end web service call times out), and of course you could have a badly formed message which will never succeed processing, but in all cases it should be possible to design for these.
If you're using public queues on a clustered environment then I think there may be more scope for failure as clustering msmq introduces complexity (I have not really used so I don't know) so try to avoid if possible.