I am using the SFTP adapter and want to get ACK/NACK in the orchestration. I have implemented all the required steps mentioned in the blog Acknowledgments and Negative Acknowledgments (Part 1)
I am getting the ACKs, but in case of failure I do not get any NACK. Does anyone know how to get it?
I think you said you are using NONE for the transaction type? If that is the case I believe that you have to set the Transaction Type of the Scope to "Long Running" for the Delivery of the NACK to occur.
Related
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.
Let's say we have
Client node with HTTP gateway outbound service
Server node with HTTP gateway inbound service
I consider situation where MSMQ itself stops from some reason on the client node. In current implementation Rebus HTTP gateway will catch the exception.
What do you think about idea that instead of just catching, the MessageQueueException exception could be also sent to server node and put on error queue? (name of error queue could be gathered from headers)
So without additional infrastructure server would know that client has a problem so someone could react.
UPDATE:
I guessed problems described in the answer would be raised. I should have explained my scenario deeper :) Sorry about it. Here it is:
I'm going to modify HTTP gateway in the way that InboundService would be able to do both - Send and Receive messages. So the OutboundService would be the only one who initiate the connection(periodically e.g. once per 5 minutes) in order to get new messages from server and send its messages to server. That is because client node is not considered as a server but as a one of many clients which are behind the NAT.
Indeed, server itself is not interested in client health but I though that instead of creating separate alerting service on client side which would use HTTP gateway HTTP gateway code, the HTTP gateway itelf could do this since it's quite in business of HTTP gateway to have both sides running.
What if the client can't reach the server at all?
Since MSMQ would be dead I thought about using in-process standalone persistent queue object like that http://ayende.com/blog/4540/building-a-managed-persistent-transactional-queue
(just an example implementation, I'm not sure what kind of license it has)
to aggregate exceptions on client side until server is reachable.
And how often will the client notify the server that is has experienced an error?
I'm not sure about that part - I thought it could be related to scheduled time of message synchronization like once per 5 minutes but what in case there would be no scheduled time just like in current implementation (while(true) loop)? Maybe it could be just set by config?
I like to have a consistent strategy about handling errors which usually involves plain old NLog logging
Since client nodes will be in the Internet behind the NAT standard monitoring techniques won't work. I thought about using queue as NLog transport but since MSMQ would be dead it wouldn't work.
I also thought about using HTTP as NLog transport but on the server side it would require queue (not really, but I would like to store it in queue) so we are back to sbus and HTTP gateway...that kind of NLog transport would be de facto clone of HTTP gateway.
UPDATE2: HTTP as NLog transport (by transport I mean target) would also require client side queue like I described in "What if the client can't reach the server at all?" section. It would be clone of HTTP gateway embedded into NLog. Madness :)
All the thing is that client is unreliable so I want to have all the information about client on the server side and log it in there.
UPDATE3
Alternative solution could be creating separate service, which would however be part of HTTP gateway (e.g. OutboundAlertService). Then three goals would be fulfilled:
shared sending loop code
no additional server infrastructure required
no negative impact on OutboundService (no complexity of adding in-process queue to it)
It wouldn't take exceptions from OutboundService but instead it would check MSMQ perodically itself.
Yet other alternative solution would be simply using other than MSMQ queue as NLog target but that's ugly overkill.
Regarding your scenario, my initial thought is that it should never be the server's problem that a client has a problem, so I probably wouldn't send a message to the server when the client fails.
As I see it, there would be multiple problems/obstacles/challenges with that approach because, e.g. what if the client can't reach the server at all? And how often will the client notify the server that is has experienced an error?
Of course I don't know the details of your setup, so it's hard to give specific advice, but in general I like to have a consistent strategy about handling errors which usually involves plain old NLog logging and configuring WARN and ERROR levels to go the Windows Event Log.
This allows for setting up various tools (like e.g. Service Center Operations Manager or similar) to monitor all of your machines' event logs to raise error flags when someting goes wrong.
I hope I've said something you can use :)
UPDATE
After thinking about it some more, I think I'm beginning to understand your problem, and I think that I would prefer a solution where the client lets the HTTP listener in the other end know that it's having a problem, and then the HTTP listener in the other end could (maybe?) log that as an error.
Another option is that the HTTP listener in the other end could have an event, ReceivedClientError or something, that one could attach to and then do whatever is right in the given situation.
In your case, you might put a message in an error queue. I would just avoid putting anything in the error queue as a general solution because I think it confuses the purpose of the error queue - the "thing" in the error queue wouldn't be a message, and as such it would not be retryable etc.
I am having problems testing the MQSC Adapter in BizTalk to communicate with a Queue on Z/OS Host.
The test senario: While sending messages though Biztalk I (Force)stop and start the Host channel, to mimic a HOST IPL.
In this scenario I experienced the following outcomes:
Sometimes there are messages left uncomitted on the Host MQ.
Even after the channel are started again. This way I don't know if the messages have been processed by Biztalk.
Question Is there a way to make sure that messages are always committed on the Host MQ or still available on the MQ if not committed
Once I experienced duplicate messages and once that messages was lost
Since these things happened only once each. I hope to find problems in my test applications / procedure.
Not really a question, but if others have experienced the same errors I would like to know.
The test Setup
Biztalk 2009 on 2 nodes
WebSphere MQ client 7.5.0.2 (Transactions supported)
MSDTC - XA Transactions are enabled (Edited to reflect comments)
MS Biztalk Adapters for Host Systems 2.0
Port Configuration
Receive Location
Send Port
If you are using MQ transactions, that is just MQPMO_SYNCPOINT and MQCMIT, then the disconnection (either explicitly or implicitly due to STOP CHANNEL(chl-name) MODE(FORCE)) will cause any outstanding transaction to be completed (committed on an explicit disconnection, rolled-back on an implicit one).
If you are using 2-PC transactions with a Transaction Manager (TM), then the transaction will need to be dealt with by the TM, depending on how far through it is, is it prepared already for example.
I have the same problem as described here:
I am using two orchestrations. First orchestration calls the second using direct binding through a two-way send port. Second orchestrion has a two-way receive port to send the result back to the first. Every thing is working as it should but I am getting the following exception.
A response message for two-way receive port "Unknown " is being suspended as the messaging engine could not correlate the response to an existing request message. This usually happens when the host process has been recycled.
And the suggested solution works as well (set the BTS.EpmRRCorrelationToken value to a random value, new GUID in my case, in the first orchestration before send to the direct binding port and then in the secod orchestration i copy the value from the inputMessage to the outputMessage, so the value remains the same. With this method BizTalk knows how to correlate the response back to the caller). But I can't understand why this works and if this a good way to solve the problem. The BTS.EpmRRCorrelationToken flow is the following:
When I don't change the BTS.EpmRRCorrelationToken property, it is the same in all messages which flow in the process, but why on Earth doesn't BizTalk change it instead if it can't correctly correlate the messages?
Changing this property is certanly OK in your case.
The problem is direct binding. When you use it, you actually going more "low-level" way and have to deal with how BTS publish-subscribe mechanism works.
Send-Receive port subscribes to receive a message with a specific BTS.EpmRRCorrelationToken. So when you post receive message again in the Message box (for second orch), receive port grabs it too and unsubscribes then. When you finally try to send a response - there is noone waiting for it. So you have to change that property until you sending response back to the port.
How can I resume a dehydrated orchestration ?
the orchestration in question should have been retrieving messages from a MSMQ queue
but the userid permission wasn't set on the queue, so the BizTalk box wasn't able to read from the queue
Corrected the permissions, but the only options are teminate and suspend ?
If the orchestration attempted to start and failed on the MSMQ receive, it's essentially hung and has not removed a message from the queue. I'd terminate it. The orchestration should clear and pickup the new messages. Does your orchestration implement a singleton pattern or are you using ordered delivery on the receive? This makes things a little more complicated.
Shouldn't you be restarting the biztalk service instance for MSMQ?
Dehydrated means the orchestration is still waiting for something. I guess in your case, you must be waiting for a corelated message from MQ. If you restart receive host service instance, it will try to reconnect all connections (MSMQ, SQL, etc that managed by the service instance). Then all messages will be flow through to orchestrations.
update 1:
Check the relevant receive location. Maybe it got disabled by biztalk due to the permission problem. You will have to enable it manually.
update 0:
Your don't have to resume dehydrated orchestration. It's not the orchestration that read from the queue, but the msmq adapter. When a msmq message arrive the receive location will route it into the message box. If the said orchestration have a subscription ( receive port ) that match the msmq message then it will be resumed by the biztalk engine.
Can you suspend, then resume?
It's been a couple years since I did BizTalk. Quirks like this were annoying. Even worse when it's 250k dehydrated and you need to script to restart them. ugh
I feel for you.
BizTalk's ability to resume depends on the place and way it failed, and whether it can replay any part of the operatio; in most cases, when failing in an orchestration, some coding pattern need to be used to allow it to resume.