My first contributions on TechNet Wiki in 2013: “BizTalk Server: Glossary” and “BizTalk Server: Presentations Gallery”

My first contributions on TechNet Wiki in 2013: “BizTalk Server: Glossary” and “BizTalk Server: Presentations Gallery”

Due to lot of work and a presentations mainly on BizTalk Innovation day events, I still had not managed to create new articles on TechNet Wiki this year, despite having lots of ideas and ongoing projects. Unfortunately, with the weather not inviting outdoor activities in Portugal, a lot of rain, I got some free time […]
Blog Post by: Sandro Pereira

ESB Itineraries: Resume at point of failure using ESB Management Portal

ESB Itineraries: Resume at point of failure using ESB Management Portal

In my experience, the two most commonly used components of the ESB Toolkit are the Management Portal and Itineraries.  First thing I must remind everyone of is that the Management Portal is a SAMPLE application.  This means it is not production readybut you do have all of the source code.  If you want the functionality the portal provides, I recommend you extract the code into your organization’s source control system, and own the solution going forward.  I’ll cover my list of “things you must do to make the portal production ready” in another post.

Now to the main event.  When using Itinerary-based processing for your BizTalk solutions, you get some great features out of the box, with little to no effort.  One of these is the ability to continue processing an instance of an itinerary from the step at which it failed.  First, you must have the ESB Exception Management solution deployed.  This provides the EsbExceptionDb repository for storing exception and instance data of failed messages, as well as an out-of-the-box Send Port for populating the database when failures occur.  Second, you must both enable Failed Message Routing on all itinerary-used Send and Receive Ports and use the prescribed ESB exception handling in all itinerary-used orchestrations.

image

Once these steps are completed, you will see failed itinerary instances in the ESB Management Portal, along with the Itinerary XML in the message context.

image

 

At this point, enough information is available to submit the failed message to the out-of-the-box ESB On-Rampsyou just have to make a small tweak to the ESB Management Portal source code.  The following is a snippet of code from the out-of-box MessageViewer.ascx.cs file, located in the ESB.Portal\Faults folder.  The ResubmitMessage method is where all the magic happens.

MessageViewer.ascx.cs (Original)

image

 

As you can see, depending on what the user does, the message could be resubmitted via a SOAP or WCF endpoint.  Both use a helper library called MessageResubmitter.  Looking at that library, you can see that both resubmission options do not include the Itinerary in the service request, even though it is available!

MessageResubmitter.cs (Original)

image

 

These services can each handle the itinerary being includedwe just have to add it to this client proxy code.  here is what it looks like post-modification:

MessageViewer.ascx.cs (Modified)

image

 

MessageResubmitter.cs (Modified)

image

 

What is great is to understand that this will automatically start processing the itinerary from the point at which it failed.  Looking at an example Itinerary XML attached to a failed instance, you can see that the next step in the itinerary is already set, since the Itinerary engine manages this as it processes. The <ServiceInstance> tag identifies the next itinerary step to be executed, and you can see the state of both the step and the overall Itinerary are both “Pending”.

image

 

Once submitted, the remaining steps of the itinerary are executed, while any steps that executed successfully the previous time are not re-executed.

image

 

Such a simple change, but adds compelling exception handling capabilities.  The solution described above is a Manual Intervention scenario.  If you needed an automated mechanism for resubmission, simply adding a component, such as an orchestration, which processes exception messages before they reach the ALL.Exceptions Send Port, would allow you to configure automated resume with whatever retries, delays you needed.

Nextleveraging out of the box Itinerary BAM tracking with out of the box ESB exception information to produce a full view into itinerary processing

 

Ciao,

Dan

Error: Party ‘PartyName’ enlisted under role ‘Provider(Codit.MyRoleLinkType)’ has not bound all the operations of role link port types.

Small post on troubleshooting the error “Party ‘PartyName’ enlisted under role ‘Provider(Codit.MyRoleLinkType)’ has not bound all the operations of role link port types”. It seems you need to remove the assembly and thus also the binding to get rid of this error.

Starting Back Up

I’ve used other blogs in the past and was never real good at blogging consistently.  I’m now on a mission to get some posts up here on a consistent basis.

 

Coming soon will be a little series of ESB Toolkit How To’s, consisting of concepts and solutions I’ve used on real BizTalk Server projects for customers.  Please let me know if you have any particular requests and I’ll get them queued up.

 

Ciao,

Dan

TechNet Wiki Article: List of BizTalk Errors and Warnings, Causes and Solutions

TechNet Wiki Article: List of BizTalk Errors and Warnings, Causes and Solutions

I know that in the past I already wrote about this article but I just love it The “List of BizTalk Errors and Warnings, Causes and Solutions” article is intended to be a knowledge base of all Errors and Warnings, Causes and Solutions documented in all stages/components of BizTalk: different stages of development, deployment, adapters, […]
Blog Post by: Sandro Pereira

Restoring BizTalk Server 2010 databases

When you look at Microsoft’s documentation about restoring your BizTalk databases they always talk about restoring your databases by using log shipping. Most of my client have various reasons (unfamiliarity with the technique, requires extra servers and licenses, etc.) for not wanting to use log shipping. Alternatively you can manually restore the BizTalk databases.

The Evolution of BizTalk Server

Last week Microsoft announced the release of BizTalk Server 2013 RTM, there are enough materials out there showcasing the new capabilities that’s been added to the product. We blogged in detail about the core licensing changes here. This is the 8th (2000, 2002, 2004, 2006, 2006 R2, 2009, 2010, 2013) major release of BizTalk Server. […]

The post The Evolution of BizTalk Server appeared first on BizTalk360 Blog.

Blog Post by: Saravana Kumar