Introduction
When for example a send port fails in BizTalk, both the message and the service instance show up in the BizTalk Administration Console as being suspended. When the destination is wrong you can change it and resume the message but when the ESB Management Portal is used to monitor the behavior of applications, you cannot resume a message because you can only resubmit a message to an on-ramp. The resubmitted message does not contain any of the context properties of the original message. But is it possible to change the ESB Management Portal a bit so failed messages can be resumed from the ESB Portal?
The following endpoints are suitable for resubmission:
- WCF On-Ramp. This endpoint is the ESB Itinerary Services WCF on-ramp and is available only for XML files. The portal Web.config file defines the URL for this on-ramp.
- SOAP On-Ramp. This endpoint is the ESB Itinerary Services ASMX on-ramp and is available only for XML files. The portal Web.config file defines the URL for this on-ramp.
- Any receive location using the BizTalk HTTP adapter. This option is available for XML files and flat files.
The ESB.ItineraryServices ASMX on-ramp expects an ESB itinerary in the SOAP header. In order to test if the ASMX on-ramp accepts also a partially processed itinerary I used the Itinerary Test Client to submit a message and a partially processed itinerary to this on-ramp.
Steps
First I’ve created an itinerary with 2 messaging services. The Transform Service transforms the incoming message but he Routing Service has a resolver that has a wrong destination folder.
The state of the services in the itinerary are all “Pending” when the itinerary is exported to a file.
The created itinerary can be tested with the Itinerary Test Client that is located in the ESB Toolkit sample applications.
The Esb.Itinerary.Test.exe tool is located in \Source\Samples\Itinerary\Source\ESB.Itinerary.Test\bin\Debug
When the “Enable routing for failed messages” check box in the Send Port is selected, the failed message is picked up by the ESB Management Portal.
The failed itinerary is saved in the “ItineraryHeader” context property off the message.
All the context properties of a failed message are saved in the ContextProperty table in the EsbExceptionDb database. I’ve extracted the itinerary from the database and saved it to a .XML file.
The error occurred in the send port and because a send port is also a service in an itinerary, the attributes in the ServiceInstance element are set to the “DynamicPort” send port.
To make it work I had to change the attributes in the ServiceInstance element and set it to the ESB.Services.Routing service because Dynamic Send Ports do not contain a fixed destination address, only a pipeline.
When the altered itinerary is send to the ESB.ItineraryServices ASMX on-ramp with Itinerary Test Client, the ESB.Services.Routing service is skipped because his state is already “Complete”
Conclusion
So it is possible to resubmit a processed itinerary to an Onramp! You only have to change the ESB Management Portal a bit to make it work,. ( –;
Happy Coding!