BizTalk Latest Adapter List and Visual Studio Compatibilities
A handy couple of articles that have been updated for Biztalk 2009, full article attached
at the bottom.
Enjoy
BizTalk_Server_2009_Adapter_Datasheet.pdf
>
Microsoft StreamInsight
SQL Server 2008 R2 August CTP has just been released on MSDN and will be publically available on Wednesday. One little point grabbed my attention. The forthcoming CEP engine, formally known as ‘Orinoco’ (this codename was never meant to be used outside the company, but nevertheless made its way into the public domain) now has a proper name – ’StreamInsight’ to be precise.
Microsoft SteamInsight isn’t included in the SQL Server CTP. However, a separate CTP is due to be released in the next few weeks.
Sending XML messages to BizTalk using the WCF Channel Model
It is quite a common requirement to have a generic receive location in BizTalk to accept any XML file. Richard Seroter has listed a few options already on how to do this.
I looked into how BizTalk exposes its WCF receive locations and how they could be consumed by using the WCF channel model, without […]
MGrammar – Tokenizing
I’m currently working on an EDI grammar, I came across some unexcited behavior upon tokenizing the input.
UNA:+.? '
UNB+UNOC:3+123456789:ZZ+987654321:ZZ+090804:0758+491944'
UNH+464009+APERAK:D:07B:UN:2.0b'
BGM+313+464009'
DTM+137:200908040758:203'
RFF+ACE:100048193285'
DTM+171:200908040606:203'
NAD+MS+123456789::ZZ'
NAD+MR+987654321::ZZ'
ERC+Z06'
FTX+ABO+++9904383000003'
RFF+ACE:100048193285'
UNT+11+464009'
UNZ+1+491944'
The above sample is an APERAK message. I won’t go into any details about the structure other then that there are a number of Segments such as (UNH, BGM, DTM etc). Each segment is separated by “’”. Every segment has elements separated by “+”, which in turn can have a number of component data elements separated by “:”. Some of the elements are optional and some are mandatory.
My problem occurred when elements are optional. Have a look at the sample grammar below:
syntax Main = a:A? del? b:B? del? c:C? =>{A=>a,B=>b,C=>c} ;
token del = ",";
token A = ("A".."Z" | "a".."z" | "0".."9")+;
token B = ("A".."Z" | "a".."z" | "0".."9")+;
token C = ("A".."Z" | "a".."z" | "0".."9")+;
The syntax above states that there are three tokens (A, B and C), and they are all optional.
Given the input: a,b,c the output will be:
{
A => "a",
B => "b",
C => "c"
}
However, given the input of only a,b the output comes out:
{
A => null,
B => "a",
C => "b"
}
This was somewhat unexpected for me. I would have expected the tokens to be filled from the left, leaving the “C” element empty. To solve this you need to complement the syntax with all possible combinations:
syntax Main = a:A del b:B del c:C? =>{A=>a,B=>b,C=>c}
| a:A del? b:B?=>{A=>a,B=>b}
| a:A=>{A=>a} ;
Which gives the following output:
{
A => "a",
B => "b"
}
WSCF.blue – Updates
So there’s been a few things happening on the WSCF.blue front. We’ve had some excellent feedback and also some feature suggestions, so all that has been rolled up into the install package. It’s still Beta-1, but the MSI has been updated to v1.0.2.
The main changes are
(1) the option to format the soapActions when setting the […]
Itinerary Broker Services: The Feature We Do Not Speak Of
I was on the MSDN Forums for the ESB Toolkit this morning, and came across a question from fellow BizTalk developer Barry Woods. He was asking about routing decisions in itineraries, so I threw in my two cents on the topic. Then I stepped back for a second and realized that there is a fantastic feature of the ESB Toolkit 2.0 that no one talks about.
This enigmatic feature stealthily crept into the Toolbox in Visual Studio, when you weren't looking. It takes up two slots in the toolbox, because two are necessary to compose its awesomeness. I'm referring to the "Itinerary Broker Service" and the "Itinerary Broker Output"; together they make up the feature that is the Broker Service. So what does it even do, and why do I need it? Well to get to that, first we need to take a step back and talk about how version 1.0 of the ESB Guidance handled itineraries, and how version 2.0 handles them. If you would rather not hear that discussion, click here to skip the fluff.
<implementationDetails>
In version 1.0 if the ESB Guidance, itineraries, represented as xml, were read as a sequential list of steps that needed to be executed. These steps were numbered sequentially just like items in an array. The Itinerary designer can serialize your model into this format, and will do so when you set the Export Mode of your itinerary model to Default.
However, if you switch this Export Mode to Strict, you will notice a few things change in the XML output. I would recommend you keep this XML output up in a separate tab as you're reading through the next section.
First of all, each messaging-based step (termed an Itinerary Service in ESB Toolkit lingo) has a stage attribute defined that correlates to the Container property of the model element in the designer.
Every step also has a businessName attribute associated with it which corresponds to the Name property of the model element in the designer. This name will be used in BAM tracking of itinerary execution.
Next you will notice that itinerary services can now have a PropertyBag associated with them that can be configured at design time for a different experience in each itinerary. This also means that you do not have to create a custom resolver each time you have an orchestration service that needs some business specific metadata that isn't related to what resolvers can already return.
Finally you will notice that each step has an id attribute, and a nextId attribute (with one exception that we will note later). This means that the services are no longer executed in a positional/sequential fashion, but instead are represented as a linked list that can be modified at runtime.
</implementationDetails>
Thus, we are brought back to the Itinerary Broker Service. This is the only service that allows us to select the next link in the chain, and thus change the entire path of execution that the itinerary takes. Right now the Itinerary Broker Service is only available within the pipeline, though designer support has already been built for you if you decide to create a custom orchestration-based broker service.
With minimal effort you will be able to have an itinerary that looks like this.
In order to begin using the Itinerary Broker Service, go ahead drag one on to your design surface, and then give it a unique name. Since this can only execute within the pipeline, you are either going to have an On-Ramp shape that connects into it, an Off-Ramp shape that connects into it (on the receive side of a two-way off-ramp), or another messaging service shape that connects into it. Make whatever connection makes sense for your scenario.
Now you will need to decide how many possible paths there will be through your itinerary. You don't have to account for every path a message will take to its destination, but rather which steps it will take to get there. For example, if you have two instances in which a message will have to be transformed once and then routed, that can be taken care of with a single path that includes a transform step and a routing step with a more dynamic resolver (e.g., the BRE resolver). If you have then another instance in which a message would have to be transformed twice before being routed, this would constitute another path through your itinerary. Once you decide how many paths you will need, drag an Itinerary Broker Outport on top of the Itinerary Broker Service you just added.
This will create smaller model elements that can be used to attach to other services. Which means that these allow this element to branch out just like you might have a decide shape branch in a BizTalk Orchestration. Go ahead and set the Name property on these to describe the path through your itinerary to which they will connect.
Next you will want to add a Resolver to the broker service, just like you would with any other Itinerary Service. In this case you will want to set the Resolver Implementation property to CONTEXT. This will return the context of the message being processed formatted like this. That's another tab you will want to keep open as we continue this discussion.
Normally resolvers are used for runtime resolution of endpoints, or transformations. Each resolver is given a configuration string, and returns a dictionary of key/value pairs as the result of its execution. Itinerary Services can then use the information in whichever way they please. In this case the Broker Service will use the very first key in the resolver dictionary (whatever it may be) as a value to switch on.
Put on your C# hat for a second and consider the following code:
string item = "spoon";
switch (item)
{
case "bowl":
bowl.Declare("too small");
bowl.Dump();
break;
case "spoon":
spoon.Declare("too big");
bowl.Dump();
break;
default:
break;
}
Now this is a silly example, but here we see that we are making a routing decision based on the value of item. The string named item in this example corresponds to the role of the Resolver in the broker service. The next thing we need to add is our cases. This corresponds to the Filters. So, go ahead and add a filter for each path you would like to take.
Name these filters according to the path that they will follow, or the condition on which they will be filtering. Next set the Filter Implementation property to XPATH. XPATH is the only filter that comes with the toolkit. Notice the Expression property of the filter. This expression will be evaluated against the first item returned by the resolver. In the case of the CONTEXT resolver, it will be this (which you should have open on another tab). So we could configure an expression that considers the inbound transport type for example:
//Property[@name='InboundTransportType']='FILE'
This will evaluate true for all messages that sent through a receive location with a file adapter. For those of you out there looking to build an orchestration-based broker service, filters will be serialized as properties in the property bag for the broker service itinerary step.
After you have configured your filters, you will have to return to your outports to configure which Resolver and Filter they are comparing by selecting them in the Filter and Resolver properties of the outport. Now there is a possibility, depending on the expressions you use, for two outports to be associated with a filter that will return true. In this case you can set the Order property of the outports to determine which one has precedence.
At this point, you will simply need to wire up your broker service outports to the proper services that should follow, and you will be good to go.
I have created a super simple sample itinerary that will switch based on the transport type, and route the message to a different location. You can find that sample here. Also be sure to check out our BizTalk screencasts and ESB screencasts.
The end for now.
Issue 7 of BizTalk HotRod Magazine is out
Just saw on Rahul’s blog that the latest edition of the BIzTalk HotRod magazine is out, with some great articles on:
Azure
Testing maps and schemas
Richard Seroter’s "SOA Patterns With BizTalk Server 2009" book review
Throwing typed faults from orchestrations exposed as a WCF service
Integrating BizTalk with Dynamics AX
Managing BizTalk with WMI and C#
BizTalk resources list
Download it […]
ESB Toolkit How To Video #7: A SharePoint Adapter Provider
Welcome to #7 in my series of ESB Toolkit How To Videos. If you have not seen the previous videos, I encourage you to do so. The previous ones can be found here
1) Basic Itinerary Routing and UDDI Integration
2) Composite Itinerary and Dynamic Mapping
3) Itinerary Resolution in the Bus
4) Dynamic Itinerary Resolution in the Bus
5) Including Custom Orchestrations in the Itinerary Designer
6) Performance Metrics using Built in BAM
One very common thing that people will want the ESB to do is to route message to SharePoint where they can potentially kick off human based workflow. However, the base ESB Toolkit does not have an adapter provider for Windows SharePoint Services. BizTalk does have an “Adapter” for WSS, however the ESB toolkit does not have an “Adapter provider” for WSS. The Adapter Providers in the ESBT bridge between the new ESBT code and the traditional BizTalk components.
Now fortunately, the ESBT can be extended very quickly and we can add in our own adapter providers without the need for very much code at all. This past week, I was working with the guys over at QuickLearn to build out a WSS adapter provider that they planned to use in an upcoming BizTalk/ESBT demo. In this video, I’ll show you how we created the adapter provider (using only a few lines of code) and how we registered it so that the design time tools and the runtime engine could use it. Now, while creating the adapter doesn’t require much effort, I will admit that I had a hell of a time trying to get it registered properly and all of the associated configuration files aligned correctly. The ESBT relies heavily on reflection to load components at runtime, so if you don’t name your component properly or register it correctly in the config files, then the ESBT engine won’t be able to load the provider properly and you’ll have a fun time trying to debug just exactly what you did wrong.
In order to make it easier for you, I’ve included my code and configuration files for download so that you don’t have to rebuild everything that I show in the video.
I need to credit Nick Hauenstein over at QuickLearn (http://www.quicklearn.com/) for doing most of the initial leg work on building this out.
You can access the video here
You can download the project here
Cheers and keep on BizTalking
Peter
PrintMonitor – A C# print spooler monitor
Recently, a colleague of mine had a requirement of getting information on the number of pages being printed by users. Monitoring a printer is done by calling FindFirstPrinterChangeNotification, waiting for the returned WaitHandle to be signaled and then calling
FindNextPrinterChangeNotification to see why the handle got signaled and act accordingly. Sadly, there don’t seem to be any samples of this in C# out there, so I created one in my spare time. The attached application monitors all printer notification fields possible. It still has some issues like not disposing things correctly, but that’s left as an exercise to the reader, as I don’t have more time to spent.
Upon starting the application, the Load event of the main form hooks up the event and handles (it currently takes the first printer it can find):
printerWaitHandle = new ManualResetEvent(false); PRINTER_INFO_2[] printers = enumPrinters(PrinterEnumFlags.PRINTER_ENUM_NAME); string printerName = printers[0].pPrinterName; OpenPrinter(printerName, out printerHandle, 0); printerChangeHandle = FindFirstPrinterChangeNotification(printerHandle, (int)PRINTER_CHANGES.PRINTER_CHANGE_DELETE_JOB, 0, notifyOptions); printerWaitHandle.SafeWaitHandle = new SafeWaitHandle(printerChangeHandle, true); printerChangeNotificationHandle = ThreadPool.RegisterWaitForSingleObject(
printerWaitHandle,new WaitOrTimerCallback(PrinterNotifyWaitCallback), printerWaitHandle, -1, true);
The callback method (PrinterNotifyWaitCallback) interprets the change:
public void PrinterNotifyWaitCallback(object state, bool timedOut) { // BUG: if we Thread.Sleep here for the amount of time it takes to spool the print job, we only get the right notification for number of pages. int changeReason = 0; IntPtr pNotifyInfo = IntPtr.Zero; bool nxt = FindNextPrinterChangeNotification(printerChangeHandle, out changeReason, null, out pNotifyInfo);
...
}
This works quite well. There is a bug in there somewhere which causes the following behavior: the total number of pages is first set to 0 when spooling the print job and only on the *subsequent* print job being printed is the correct number of pages signaled. If you put a Thread.Sleep (don’t ;-)) in the callback for the amount of time it takes the spooler to spool the print job, the correct number of printed pages is displayed directly (without the ’0’ entry and within the actual print job it belongs to). If anyone can find the bug, please let me know!
Sourcecode attached, as always, no warranties of any kind, express, implied, etc.
Sourcecode
Outlook Add-in: Replying to people who voted
Recently, I asked my colleagues if they were interested in beta testing some software I’m building for internal use. I used voting buttons to enable easy tracking of replies. When I wanted to reply to all people who voted “Yes” on my request, I discovered there’s no real way of just replying to a set of people who voted a certain way. Meet “ReplyToVoteTrackingType” (what’s in a name?); it’s an add-in which allows you to easily reply to anyone who casted a certain vote by selecting that vote:
The code for the add-in is pretty straight-forward, when loading the Ribbon we fill the dropdown menu with the items from the original vote and hookup the same event handler (we don’t discriminate) to each added button:
// Retrieve the MailItem we're currently viewing. currentItem = ((InspectorClass)this.Context).CurrentItem as MailItem; // Retrieve all possible voting options from when we sent out the e-mail. string[] votingOptions = currentItem.VotingOptions.Split(new char[] { ';' }); // Set up a button for each of the options, labeled <option> ('yes', 'no', etc.). foreach (string votingOption in votingOptions) { RibbonButton btn = new RibbonButton() { Label = votingOption, SuperTip = string.Format(Resources.SuperTip, votingOption) }; btn.Click += clickEventHandler; mnuReplyToTracking.Items.Add(btn); }
Then, when the end user clicks on any of the voting options (e.g. “Yes” as the picture above shows), we check who responded in this fashion and add them to a newly created e-mail:
StringBuilder recipients = new StringBuilder(); // For each recipient, foreach (Recipient recipient in currentItem.Recipients) { // if they responded, and the response is what the users choose for a target audience, if (recipient.AutoResponse != null && string.Compare(recipient.AutoResponse, ((RibbonButton)sender).Label, true, CultureInfo.InvariantCulture) == 0) { // add the recipient to the addressee list. recipients.AppendFormat("{0};", recipient.Name); } } // Set up a new e-mail to the addressees. MailItem mail = ((InspectorClass)this.Context).Application.CreateItem(OlItemType.olMailItem) as MailItem; mail.To = recipients.ToString(); // Convenience: set the mail subject to be "RE: <subject of voting e-mail>". mail.Subject = string.Format(Resources.ReplyToVoteEmail, currentItem.Subject); // Display the e-mail, non-modal. mail.Display(false);
That’s all; now, when the end users wants to reach his/her audience given a certain vote, it’s as easy as click the right voting reply!
Source code is attached, as is an installer. As always, NO WARRANTIES.
Source code
Installer