What is different between dehydrated and rehydrated activities for BizTalk messages process?
And when I can get dehydrated messages to suspended and resume instance?
Any one can get explained with examples that will be appreciate!
A message & orchestration will dehydrate if they are generally either waiting for a response. It will rehydrate once the response is received.
A message will suspend if it times out or receives a error condition.
Related
I am working on a biztalk project where I am using msmq.
The problem here is the queue messages are getting lost before receiving by the biztalk..
I can't use transaction in biztalk as it will decrease the performance.
Can anyone suggest me why I am facing this issue and a solution for this?
Thanks in advance!
When messages are sent to a non transaction queue, they will be lost if queuing service restart or some unexpected event happens. For this not to happen, you can use Recoverable property of message when sending message. This is also documented here MSDN. This property is also supported by BizTalk MSMQ send port if you are sending messages from BizTalk to queue.
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.
I am sending a message to BizTalk receive location and it is stuck somewhere. Querying the Tracked Message events gives me following:
And when i query all in-progress service instances, i finding my orchestration in state "Ready to run":
The Service details tells me that the message was queued and awaits processing:
In a topic here was suggested that "The message is in an ordered delivery scenario when the preceding message is being retried by the ordered delivery send port."
The problem is that i don't have ordered delivery in my applications.
Thank you for any advice!
The Orchestration will be configured against a Host - check that the Host has a Host Instance that is in the running/started state.
First of all, I don't know if this is the right place for this kind of question. Please tell me if it is not.
For a demo of a monitoring application. I want to force some sendports
and orchestrations to get an instance with suspended and dehydrated
messages
How can I do this in BizTalk 2013?
To get a suspended message:
Just create a receive port and a receive location without a send port that matches the subscription. This will create 2 suspended messages: your actual message and a routing failure.
To get a dehydrated orchestration, create an orchestration with a delay shape that waits for example 1 hour. It will not stay active, instead it will dehydrate.
Hope this helps!
Pieter
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.