Microsoft has asked Stott Creations to create a few ESB samples for the release of BizTalk 2013. We are finalizing those samples right now.
One thing I hate about the current samples that come out of the box with the ESB Toolkit, pharm is that they rely on other samples being created. If I want to learn how to do something, dosage there are steps on how to get the sample I care about working. The problem is that each first step states that another sample needs to be completed before you can start working on this one. I go to the that sample, and that example states that it relies on another sample being created first. All told, I have to create 4 different samples to get to the one that really want to work on. With each sample I incur a compound set of exponential opportunities to make a mistake. It generally means that I never get to the actual sample I want to work on.
That rant drove these samples to be completely self contained, so if you want to learn each of these, they rely on nothing else being done.
Dynamic Endpoint
We will be showing how to use a purchase order to send to various end points. Our sample will be a messaging based solution where we will use a static itinerary resolver. The itinerary that it walks through will use the BRE to resolve both the map and the backend system it is going to. We will be showing that it can be sent to the following endpoints:
- SQL: New PO processing Interface
- File: Old PO Processing Interface
- SMTP: Email to operations that this purchase order does not belong to this department
Defining Business Processes
We will be showing the following flow within the Itinerary Flow Designer:
- Receive Purchase Order
- Create Advanced Shipment Notification
- Warehouse Notification
- Email confirmation
We will show, using the BRE, how this same flow can orders, and how the end points, even though they are for the same flow, based on the data, will go to two different warehouses. The two different areas are defined in this map:
Once we show that is working, we are going to add another warehouse to the mix based on some new criteria, which means we add a new rule to the policy and it is now able to handle this new warehouse:
Agility
We will show a member verification process as part of an order process. This process will have the following steps:
- State Verification
- Item Verification
When, we will show that there is a new service that is brought online, and we will change the itinerary to add this new step, and watch the new flow without breaking any logic. We will deploy a new map, and add the additional step into the flow, deploy the new itinerary. The new flow will be:
- State Verification
- Member Id Verification
- Item Verification
Exception Handling
We are going to step outside of ‘ESB World’ and show a standard orchestration that fails, and that orchestration has been setup to send data to the exception handling mechanism. This means that the management console remains ‘empty’ and that the Exception Portal being configured for notifications that an email will be sent out notifying of the failure. The failure will be a mis-configured send port that is bound to the orchestration. We will show that you can resubmit the message back for the orchestration to reprocess it after the send port was corrected.
Repair and resubmit will also be shown, where you can modify the message (as the order will have 0 orders bought, which throws a separate error).
After resubmission, you see the process complete. Again, the best part of this that instead of suspended messages in the message box (I am sure you have never seen this in a production environment before), the messages go to the ExceptionDb and can be handled separately without clogging up the message box.
