DevCon – Stott Creations ESB Blog

Standardized Method for handing Request/Responses in the ESB

Oct 212014

“I have a web service that I need to connect to in this process, try how do I do it using the ESB?”

We at Stott Creations spent probably the most time on this topic.

Our first inclination was to use a request response off-ramp.

We quickly discovered that the whole off-ramp was designed with the (misguided) understanding that the web service you were connecting to was going to pass back all of the data you needed along the bus.

I have never seen this to be the case. An shipping verification hosted by UPS does not have the capability to handle the data flowing on the ESB, vialis 40mg nor do I really want that data going out to a third party web service.

We have a standardized way of calling request-response end points, even one-way endpoints.

I drop a Itinerary Service onto the Itinerary Surface and name it Call External WS

Set the Service Name to StottCreations.ESB.Orchestration.Send

I set the following:

Tracking Enabled: True – I want to see the status of this step in the Portal

Storage: True – I want to see the the entire payload stored in the BAM Activity

Reprocessing Behavior: Stop – If an exception happens, what should I do?

Stop: Stop processing and wait for resubmission to continue
Continue: Mark it as an error, but don’t stop processing, continue on (another blog post will explain further)
Reset: The standard approach for the ESB Toolkit: if an exception happens, start the itinerary from the beginning when the issue that caused it to fail is fixed

There are two to three resolvers that need to be added.

Map to create the request message
End point settings
(optional) Merge map that takes the response and merges it back to the message flowing on the bus

So let’s create a resolver called Make Request, use the static resolver, and choose InternalInterface.CanonicalToExternalWS

Now lets add a new resolver for defining the end point.

I follow the same steps to define the endpoint as documented in the ESB Hints post

The next (optional) step is to create a merge map.

Essentially, I am going to take the response from the web service and merge it into the original message that was on the bus.

I create a temp orchestration and define my two messages:

OriginalMsg
ResponseMsg

I create a transform shape and define it to take the OriginalMsg and the ResponseMsg creating the OriginalMsg

I open the map and create the mapping:

Delete the orchestration, and deploy the map.

Now point to the map in the last resolver (called Merge Response)

Saving the payload

BAM, DevCon, ESB Vision 3 Responses »

Oct 212014

“During development, stuff I want to see what the data looks like at every step along the way, is there a way to do that?”

In most extensions with the ESB Vision product, there is a Payload property.

Samples include:

Logging Messaging Extender

Reprocessing Orchestration Extender

Orchestration Broker

Messaging Broker

Logging Orchestration Extender

Payload Orchestration Extender

Reprocessing Orchestration Extender

To disable all logging, simply open up the esb.config change this entry to false

To see the data, simply look up in the BAM AllRelationships View

Message Logging

BAM, DevCon, ESB Vision No Responses »

Oct 212014

“How do I log data as it flows through the ESB? If I look at the data that is stored in the BAM Activities that come out of the box with the ESB, all I see is GUIDs. Yes, I can tell which itineraries run, when they start and finish, but that information doesn’t help me at all, I need to have some data attached to the message to be able to track.”

This is the first question we encountered when we first demonstrated our ESB Vision to United Healthcare.

This entry is the first of two regarding logging. We are going to drop an Itinerary Service shape on the Itinerary Design surface, and name it Log Information. I am going to choose the Logging Messaging Extender

If there are other things that need to specify:

If I am planning on logging additional information, I want to enable Continuation
In the Service Name I choose the On-Ramp

In the Service Name I choose the Messaging Logger

I want this step to be logged in the default Itinerary Tracking activity, so I choose to Enable Tracking
If I want to store the actual payload of the message within this BAM activity, I choose True on Storage

This allows me a point in the flow to store data, however we haven’t defined what actual data we are going to store. I can add an infinite number of items. Let’s add two, the last name and the original file name.

Create a resolver and choose the Context Logger Resolver Extension

I specify the BAM Type as NVARCHAR[50]

But let’s change the length by pressing the + sign, and give it a friendly name, this is the column header that is going to show up in the portal

Now we need to choose the context property, I simply drop the context property for the Context Properties:

Now lets add another resolver and choose XPath Logger Resolver Extension

I fill in the rest,

Data Type: NVARCHAR[50]
Friendly Name: Name
Part Number: 0 (for multi-part messages you can change the index, we have a client using this for HL7)
Xpath: /*[local-name()=’Order’ and namespace-uri()=’http://ExternalInterface.Definition’]/*[local-name()=’Name’ and namespace-uri()=”]

Here is what it looks like in the portal

and

Orchestration Logging

BAM, DevCon, ESB Vision No Responses »

Oct 212014

This is part 2 of the logging features. If I want to log data mid itinerary, buy cialis I want to use the Orchestration Logging Step

I drag the Itinerary Service onto the Itinerary Design surface and choose Logging Orchestration Extender

Since I am not going to log anything after this I am not enabling the Continuation

I want the step to show up on the portal, decease so I choose to have Tracking Enabled, and I for at least development, I want to see what data is being passed through the bus at this step so I set Storage to True

I connect the other shapes, and part of the product is the ability to create the Activities:

I choose one of the following Exporters:

If I choose the XML Itinerary Exporter, it places a series of defaults, to be discussed further in a later post

However, what I am most interested in is the BAM Activity XML file. This is the name of the Itinerary saved in your Documents folder.

If I choose Database Itinerary Exporter I have a few additional settings.

Activity Overwrite: should it remove the currently deployed activity and re-deploy
BAM Primary Import Database: the default BAM Primary Import DB

Here is the completed Itinerary

If I export the Tracking File Exporter, I get the itinerary and all of the items for caching, but I also get the Activity for me to deploy to other environments

System Exceptions in the ESB

DevCon, ESB Vision No Responses »

Oct 202014

“What happens when one of our end-points are unavailable?”

This is a very common scenario, sick there is another similar regarding bulk resubmission.

I am going to turn off one of the web services and submit a message.

I click on the Fault and see the following:

I turn the app pool back on and press Resubmit, dosage notice the status has changed from Red to Yellow

Once I press OK, case this is what I see:

Bad Messages passing through the ESB

DevCon, ESB Vision No Responses »

Oct 202014

“What happens when bad data is passed through the ESB, dosage can I correct it? How can I correct it? When it is put back on the bus, case where does it resume?”

I submitted a message and it shows up as a red X.

I click on the details and notice what I can see:

What step it failed
When the step failed
The message that was on the bus when it failed

If I look at the fault, dosage I can get more details of what happened:

Notice that the message on the bus is different from the Request. I can’t change the actual Request, I need to go and change the message on the bus: that Order Number needs to be numeric. As I go and make modifications to the message, it shows what fields I have touched.

I press Save

And Resubmit

Oops, got a different fault: notice that it handles standard and custom faults in a standard way:

Let me fix that and resubmit. Notice is shows when it was resubmitted, who did it, and when.

I can click on each of the faults and see the actual Faults, but I can’t resubmit it.

If I wanted to modify or look at the XML that was on the bus directly, I click on the Raw button:

Bulk Resubmission

DevCon, ESB Vision 1 Response »

Oct 202014

“How do you handle a mass issue, check what if a web service is down and I generally have thousands of messages that are suspended, purchase since the ESB exception handling process takes the message out of the msgbox, decease how do I resubmit all of the messages?”

Here I turned off one of the web services and submitted a bunch of messages (in this case 30).

If I go and choose the check mark on the black line

And press the Resubmt button, this is what you see:

If you go into any of the details on any of them and see that it was me that resubmitted it, and that it completed successfully

Discarding messages in the ESB

DevCon, ESB Vision No Responses »

Oct 202014

“What happens if you want to ignore a message?”

This is generally a big ask, buy the situation is where a bad message comes in. It shows up as a Red X and alerts have gone out. After researching, ed instead of fixing the issue, click a completely new message is submitted.

This is easy done. We will submit a bad message:

Now the message was resubmitted, but I don’t want anyone to accidently resubmit the message that failed:

So I go into the flow that failed, and click on the Info button

Which turns it to Blue (notice you can’t resubmit it, and it marks it as me as the person who touched it):

Also from the main screen:

I could revert and resubmit it.

Orchestration Broker Service

DevCon, ESB Vision No Responses »

Oct 202014

“Can an itinerary to be able to make a decision in the middle of the flow?”

I have an itinerary, that processes requisitions, there are two requirements:

Must archive the message after it goes through the two web services
Depending on the requisition amount go down one path or the other: if it is a high requisition, it applies a discount

Using out-of-the-box features, this is VERY challenging, however, using the Orchestration Broker Service, the itinerary looks like this:

We are going to concentrate on the Orchestration Broker section (the brown shape) (the other pieces are covered in other posts).

So I dropped the Broker Service shape onto the itinerary surface and chose Orchestration Broker Service (Stott Creations)

So there are two broker resolvers, the payload and the context: so I can create two types of filters: based on the data in the message, or based on the context.

The first one I create is the payload, I want to be able to send data based on data in the payload: to the high or low, so I add a new resolver and call it Payload, because there could be multiple parts to a message, you can specify which part number we want to interrogate. By default it is part 0, if you don’t deal with multi-part messages, leaving it at 0 is fine.

I also want to send data based on the Context, so I add another resolver and choose Orchestration Context Resolver Extension. Notice that there are no other settings (no multi-part requirements)

Okay, now for the fun part.

I want to create a filter so that it will archive the data (regardless of anything else). I add a filter name it Archive Filter, choose the out-of-the-box XPath Filter, and paste the following statement stating: look at all of the context properties and if you find that the Property is called ServiceName with the itinerary system properties and that value is set to StottCreations.ESB.Orchestration.Broker this filter will be true (which it always will because it is in an Orchestration Broker service step):

/ContextProperties/Property[@name=’ServiceName’ and @namespace=’http://schemas.microsoft.biztalk.practices.esb.com/itinerary/system-properties’] = “StottCreations.ESB.Orchestration.Broker”

I add two more filters based on payload:

Name: High Priority

Filter Implementation: XPath

Expression: /*[local-name()=’Information’ and namespace-uri()=’http://InternalInterface.Canonical’]/*[local-name()=’OrderNumber’ and namespace-uri()=”] > 853

Name: Low Priority

Filter Implementation: XPath

Expression: /*[local-name()=’Information’ and namespace-uri()=’http://InternalInterface.Canonical’]/*[local-name()=’OrderNumber’ and namespace-uri()=”] < 853

Now I drop three Itinerary Broker Outports to the edge of the Orchestration Broker Step, this marries the resolvers to the filters:

With the other two I choose the Payload Resolver, and the appropriate Filter

Here is what it looks like:

I connect the outputs and the input.

So when I run a high message through: (order number > 853) this is what the flow looks like in the Portal:

Here is the low flow