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
Related
I have orchestration like on screenshot below.
And I want to have additional logic executed when service connected to wsp is failing or unavailable (timeout,service crash, server unavailable, etc).
It looks like I will not be able to catch this in orchestration in Scope_1.
How can I add logic to orchestration if service crashed ?
I think you want the pattern described in this article or some variation:
BizTalk Server: Suspend and Resume an Orchestration on Two Way Port Error
This pattern captures the Port error, and puts the Orchestration in a Suspended/Resumable state.
You should still properly configure the Port Retries.
We have an upcoming deploy for a system that processes a lot of messages through BizTalk. Since those messages are cumulative updates they need to be queued up during the deployment outage then processed in order when the deploy is finished. Since there may be a large number of them it’s difficult to do this manually.
One possible solution is to leave the send port stopped and let the messages suspend. We can then resume them in order when the deployment is completed.
Is it possible to run a SQL script (or a tool) against the BizTalk messagebox database that will resume suspended messages, for a specific port, in order of receipt?
If you have an ordered requirement (you either do or don't), then the Send Port should be marked for Ordered Delivery.
If so, then when you Start a Stopped Send Port, the messages will be processed in the same order they were submitted.
If you stop the port (but leave it subscribed) and start it again afterwards it should resume the message itself, or if not it is simple enough to go into the Administration Console and batch resume them.
However if the response messages of the send port are subscribed too by running Orchestrations you will not be able to un-deploy the Orchestrations until they have all completed, so stopping the send port would not work in this scenario.
Sometimes one option is if the initiating port is a one way receive, is to stop the receive location and let everything complete. You can then stop the application and redeploy and restart it and the send port will pick up all the waiting message to process.
If the above is not possible you may want to look at doing a side by side deployment where you increment the version numbers of all the assemblies in the solution so you can have both versions deployed at the same time and you can then allow the old version to finish running but have the new version processing any new messages.
The better option is to send messages to msmq, usually there is no extra coding required for this. You can just route messages to msmq using MSMQ adapter and then after deployment receive them in order as MSMQ adapter allows to receive in order. Just make sure you do a small test in yr QA environment before doing it in production.
I have to develop an orchestration which uses a start orchestration shape followed by send port.
Scenario: If a "Sendport4" failed to send the message, I don't have to execute "Starting Orchestration Shape".
But in my case, when "sendport4" is getting failed, It is calling "Start Orchestraton Shape".
To handle this schenario, I tried to put the exception handling, But didn't worked.
Can any one please help, what can do handle this?
Set Delivery Notification to Transmitted on the Send Port shape in the Orchestration.
One of our Biztalk customers asks us automatically resend failed and suspended messages every 5 hours.
And problem is that developed orchestrations intensively uses Suspend shape so as far as I understand
messages became suspended immediately without standard Biztalk retrial.
I'm going to write simple app that will resume suspended messages via WMI Biztalk object .
Is this a good approach?
Does anybody has such application or did you find another resolution for this problem ?
Replace the suspend shape in the Orchestration with a delay shape configured to 5 hours.
Another options is to set the retry interval to 300 minutes and multiple retries on the send 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.