by community-syndication | Jan 2, 2007 | BizTalk Community Blogs via Syndication
Next Thursday, 1/11/07 will be my last day at Microsoft. I’ve decided to take an “Architect” position with one of my customers in the Los Angeles area. It was a tough choice to leave my great colleagues and customers, but I’m fairly jazzed about the new opportunities I now have.
So, much like Han Solo in The Empire Strikes Back, this particular blog will be frozen. Next week it will get locked from any future usage. My new employer has indicated support for my blogging habit, so, I’ve set up a new blog at http://seroter.wordpress.com. I plan on continuing to do the same things on that blog that I do on the current one. So, look out for more code snippets, walkthroughs, demos, reviews, pointers to cool resources and more. I just posted an article on the new BizTalk blog about “considerations for resuming suspended orchestrations“. Thrilling stuff.
I’ve really appreciated all the great feedback and questions resulting from the 160+ posts on this blog, and hope you’ll continue participating in the new one.
Technorati Tags: BizTalk
by community-syndication | Jan 2, 2007 | BizTalk Community Blogs via Syndication
Some of you may have heard by now that we are in the process of releasing the Microsoft Enterprise Service Bus (ESB) guidance. This guidance contains pre-built components, use cases, documentation and sales material that our Business Process Integration partners can use to rapidly deploy ESBs on top of BizTalk, Windows, SharePoint and SQL Servers. Over the holidays I spent some time digging into the code and thought I’d share a bit of what I’ve been seen.
I thought that I’d first talk about the standard ESB concept of “EndPoint Resolution” and how our guidance allows you to achieve this. Endpoint resolution is core requirement in any ESB as a Service may not always reside at the same address or endpoint. Therefore we need to be able to locate our services at runtime (wherever they may be). The Microsoft ESB guidance comes prebuilt with this capability, so I thought I post a small “How-To” blurb about how you can do it.
The Task
The basic task I thought I’d tackle is to submit a generic message from a basic client application into the ESB and have it routed it to a Service based on a entry in a local UDDI server. The following image show the Services that exist in my UDDI server.
The service that I’ll wanted to submit the message to is “ENDPOINT: PostOrderMessage”. You can see from the screen image that this Service has been setup with a File Folder as its endpoint. “C:\projects\Microsoft BizTalk ESB\Tests\Common\Filedrop\Output\Order %MessageID%.xml” If the solution works properly, I should be able to find my messages sitting in this folder.
ESB Concept: The “On Ramp”
As you dig into the guidance you’ll quickly learn that one of the key components within it is the “On Ramp”. The On Ramp acts as a central entry point into the ESB engine and it allows client applications to submit generic messages that contain processing, routing and transformation instructions. The On Ramp is a key concept to understand in order use the ESB guidance and if you’re planning on using it, you’ll need to have a good understanding it.
To keep things simple, the On Ramp is a Web Service that applications can use to submit XML based messages into BizTalk. On top of this, the On Ramp allow us to specify a number of processing, routing and transformation instructions that the BizTalk will follow when processing the message. To send these processing instructions, we use specific SOAP headers that are attached to our message when we submit to the On Ramp . If you’ve got the ESB guidance already, you can view all of the possible headers by opening the “EsbEnvGeneric.xsd” property schema file in the Microsoft.BizTalk.Esb.Schema project. This XSD file is a standard BizTalk property schema and denotes the properties that our SOAP headers will eventually be promoted into. For those of you that don’t have the guidance, here a quick list of the parameters you can use when submitting your messages.
- ProcessingInstruction
- Itinerary
- MapRulesPolicy
- MapSelAssemblyName
- MapSelMethodCall
- MapSelTypeName
- MapType
- MapUddiLabel
- MapXPath
- EndpointAddress
- EndpointConfigurationString
- EndpointConfigurationRulesPolicy
- EndpointConfigurationUddiLabel
- EndpointConfigurationXPath
- EndpointDeliveryAgent
- EndpointMessagePattern
- EndpointRulesPolicy
- EndpointSelectAssembly
- EndpointSelectMethod
- EndpointSelectType
- EndpointUddiLabel
- EndpointXpath
For most projects, you’ll ending have to work with most these headers in order to achieve full ESB capabilities, but for our simple task we’ll just need to use three:
- EndPointUddiLabel – We use this to tell the ESB the name of the Service to lookup in the UDDI
- ProcessingInstruction – We use this to tell the ESB that the message needs to be routed.
- Itinerary – Where we’ll tell the ESB that this message needs to following a routing itinerary
Building the Solution
The first thing I did was to deploy and configure the ESB guidance as per the installation instructions it ships with. I won’t cover those steps here, so I’ll just jump to what I did once that process was complete.
The first thing I did was to build out a client app that I could use to submit my messages to the ESB. I used a very basic Windows Forms application as my client. All I needed was a form that would let me to define my message and specify the name of the Service I wanted to route the message to.
Once I had my basic form built out, the next step I needed to take was to add a web reference to the ESB On Ramp.
Once I’d added the web reference, I had everything I needed to submit messages into the ESB. For my project, I created a function to handle all interaction with the On Ramp web service. It creates my message, assigns the three SOAP headers I need and submits the message it to the On Ramp Web Service. Here’s the code:
/// <summary>
/// This function prepares a message and submits it to the ESB on ramp
/// </summary>
/// <param name=”strMessageBody”>The core content of the message</param>
/// <param name=”strServiceName”>The name of the service in the UDDI that we want to send the message to</param>
private string SubmitMessage(string strMessageBody, string strServiceName)
{
// Get an instance of the On Ramp Service
ESB.OnRamp ramp = new ESB.OnRamp();
// Assign security credentials
ramp.Credentials = new System.Net.NetworkCredential(“username”, “password”);
// Assign values to the headers we need to perform the UDDI based routing
ramp.EsbSoapHeadersValue = new ESB.EsbSoapHeaders();
ramp.EsbSoapHeadersValue.EndpointUddiLabel = strServiceName;
ramp.EsbSoapHeadersValue.ProcessingInstruction = “ROUTE”;
ramp.EsbSoapHeadersValue.Itinerary = “ROUTE”;
// Get the message to send
XmlDocument doc = new XmlDocument();
doc.LoadXml(strMessageBody);
try
{
//Send the message and return the result
ramp.Receive(doc);
return “Message Submitted Successfully.”;
}
catch (System.Exception ex)
{
return “Error: ” + ex.Message;
}
}
As you can see, the ESB class that was created when we added our Web Reference, contains a 2 classes. The “ESB.OnRamp” class which is our proxy to the actual Web Service and the “ESB.EsbSoapHeadersValue” class. This second class contains all of the properties that relate to SOAP headers that the ESB On Ramp will use.
I setup the OnClick event of my Submit button to call this function and I passed in the values of my two textboxes. As easy as that, I had built an application that was able to send a message into my ESB architecture. Once I’d done that, the ESB engine took care of everything else. It only took me ~10 minutes to build out my app and start routing my messages to Services. Its really is pretty simple and easy to get going with this. I’ve included a screen cam video at the end of this entry that shows me running the solution. (Its set for 1024×768 resolution)
Now that you’ve seen how to route message using UDDI, some of you might wonder what exactly is going on under the BizTalk covers. So lets take a look.
The Inner Workings
The first thing to look at is obviously the On Ramp. The On Ramp is essentially a Web Service and a BizTalk receive port. The receive location within the port uses the SOAP adapter to interact with the Web Service and also uses a custom pipeline “ReceiveForESBGeneric”.
The SOAP adapter is configured to use the same Web Service that we made a web reference to in our client application. The custom pipeline is responsible for promoting the SOAP headers into BizTalk message properties so that other elements within BizTalk can access our instructions. Once the receive location processes the incoming message, the message (along with its promoted properties) is published into the standard BizTalk MessageBox and the On Ramp is done its work.
At this point, another BizTalk artifact takes over, the “Generic.odx” orchestration. This orchestration comes as part of the guidance and can be found int the Microsoft.BizTalk.ESB.Agents.Delivery project. The messages received from our On Ramp receive port are sent to this orchestration using BizTalk’s standard publish/subscribe mechanism. This orchestration handles all incoming messages that need to be routed.
The orchestration has a direct bound receive port based on specific filter expressions. The receive shape that has a filter setup to receive all messages that have their “ProcessingInstruction” property set to “ROUTE”. Hence why I had to set that that SOAP header to use a value of “ROUTE” in my client application.
Once receiving the message, the orchestration checks to see if an proper endpoint has already been assigned to this message. If it hasn’t, then the orchestration will begin the process of resolving it. This is done in the “Call Resolution Class” expression box in the “Resolve EndPoint” scope. In this expression box, a call is made to a function call “Microsoft.BizTalk.ESB.Helpers.Resolver.Resolve”. This function is a part of a custom library that ships with the ESB guidance and it handles the lower level steps required to resolve the endpoint.
In our example, we specified a UDDI service name in the EndPointUddiLabelField SOAP header. Because we did this, the Resolve function will attempt to resolve the endpoint by making a call to the UDDI server. If it finds the requested service in the directory, then the endpoint is returned (as a string) to the orchestration.
This endpoint is then used to configure the “GenericDeliveryAgentSend” dynamic port . The configuration of the port is done in the “Set Endpoint” expression shape.
Once configured, the port is able to transmits our message to the Service endpoint.
As you can see, the orchestration also contains number of exception handling steps which all tie into the central exception management framework that the guidance contains. The orchestration also contains a number of “Tracing” steps which allow for easier debugging of the process.
More than just UDDI and more than just Routing
I’ve quickly shown how to submit a message to the ESB engine that ends up being routed based on a UDDI entry. However I must add that you aren’t limited to UDDI lookups for your address resolution. Using the SOAP headers, you can tell the ESB engine to use the Business Rules Engine or you can pass in the End Point directly with your message and there are also options for using XPath. The code contained in the guidance is incredibly flexible with regards to how you want to handle your endpoint resolution.
Also, message Routing is just one feature of the guidance. It also provides some great capabilities around dynamic message transformation, centralized exception management for services, linked itineraries and more. There are more than a few projects I’ve worked on where I wish I had this functionality prebuilt for me!
Cheers and Keep on BizTalking…
by community-syndication | Jan 1, 2007 | BizTalk Community Blogs via Syndication
Since I am going back to work tomorrow I thought I would lead with a holiday style post.
I have listened to a couple of books over the break… yup listened (not read), with a young baby I find it much easier to check audio books out of the Microsoft library and listen to them on my phone while walking the baby along the beach or around the park rather than lie in the sun and read. Anyone will know that #1 babies leave you with little time to yourself to read and #2 this summer in NZ there is little sun to be had anywhere!
What were the books? #1 The Long Tail and #2 The Art of Innovation.
There were lots of great take-aways from both of these books and I was especially happy to see shoutweb.com mentioned in relation to the early days of My Chemical Romance in “The Long Tail”.
One of things I became present to is that I am (due to the nature of my job and my interests) probably living today like most mainstream consumers will be in the short to medium term.
I have wireless Internet at home… Via WiFi I have high speed (esentially free) broadband on my phone when I am at home, around the house or in range of an open wifi connection. Yes this is particularly useful for things such as voip phone services but I am finding more and more uses for this technology since I have it available.
I normally listen to Internet Radio on my phone while mowing the lawns. I don’t normally listen to broadcast radio as it is irrelevant to me I like few hits and I like to discover my own music (before the web I used to do this via word of mouth and friends that I trusted the opinions of… I remember bus rides to school with my walkman and listening to tapes from my friends older brother that worked in a record store), some of my favourite bands Modest Mouse, The Shins, Mercury Rev, Barrington Levy, Flaming Lips, Cat Power spend little time on radio hitlists. It was for this reason that I was particluarly happy to be put onto pandora and even happier to see msn radio has licensed this technology. But I digress… Last week I saw TVNZ advertising free streaming of the ASB classic tennis through the web… this is of little use to me at home as I have a PVR (Windows Vista) connected to my TV and can time-shift broadcast TV (something that I have been using excessively with the cricket of late). I thought the TVNZ streaming would be useful for people living outside of NZ, or following the tennis at work but of little use elsewhere… then i remembered the fact that the 3 cellular network in Australia broadcasts the cricket live to it’s mobile customers on a subscription model. Also Vodafone has a deal with prime to stream prime news at 5:30pm live to vodafone live mobile devices. I thought I would experiment watching the tennis on my phone outside at home at 128kpbs, through WiFi the result a “GREAT” experience! I used to have a small battery powered TV that I took to cricket matches, the beach and out boating when I was a teenager and this certainly brought back memories of that. I might be wrong but I’m not aware of any phones that have a TV Tuner card built in ( I wonder why not?). Can TV follow radio and make its place on the Internet with broadcast technology for any device any place any time or do they also need to open up their back catelogue and make it available to you via recommendation on subscription and on demand?
With “free” broadband, an ok quality camera/ camcorder, an mp3 player, web browsing, voice recognition, IM, push email and a 2GB mini SD card in a late model phone the convergance of devices promised in the late 90’s is alive and real… I can that this is going to get better and better in the next few years until it reaches a point where you may ask yourself why you would carry anything else! Check out this video/ photos I shot from my phone while snowboarding with my sister last year… I even saw a cell phone video of the Sadam Hussain execution on TV1 news last night!
All of this said the current devices do still have their limitations. My phone for example has quite a low maximum volume when listening with standard headphones (or unamplified speakers) this may be by design to protect your hearing or as a limitation of the built in amplifier related to battery power I’m not sure. I had a problem today when I was trying to listen to an audio book while mowing the lawn, for some reason these books seem to come at a lower normalised volume than music.
I’ve been prototyping a bit recently and i finally made the connection between this and old skool childhood discovery. As a kid I spent weekends building tree houses, making home movies that stared my soft toys and pets and turning rubbish bin lids and monkey apples in shields and missiles.
They say a picture is worth a thousand words and I have found recently that by building mock-ups of Windows Sidebar Gadgets, Crazy pointless WPF applications (to learn) and MacGyver style mashups that a prototype is worth a thousand pictures!
So how did I solve my problem today with a prototype? Well I have talked to many people that rave about their “noise cancelling” head phones these things sell for a fortune and many executive travellers can be spotted wearing them in first class on airaplanes. Me I have a pair of basic Sony neck headphones with no amplifier and no noise cancelling. Today I took a drive to the hardware store and brought an 8$ pair of earmuffs. I found that by wearing these over my headphones I can hear my audio books while mowing the lawn remove external noise and protect my hearing by not needing to increase the volume on my phone. One of the strengths of NZers is that on mass we apply this #8 wire behaviour to everything we do including business, and I can’t help but think that taking yourself out of your familiar surroundings you can identify opportunities and improve business process and products when you come back to face a fresh new year, relaxed and buzzing from your recently completed holiday.
Enjoy the new year at work, Nigel.
by community-syndication | Jan 1, 2007 | BizTalk Community Blogs via Syndication
Thanks to Adrian, I’ve worked native wss adapter of Biztalk 2006 to talk to MOSS2007. From his experience, I started to test his workaround on my own.
There’s only few differences and problems I found.
—
An alternative is to configure the adapter web service manually. I haven’t tried
this approach but it should work. In this case you need to create a virtual
folder on the IIS site hosting SharePoint and name that virtual folder
BTSharePointAdapterWS. The virtual folder should point to C:\Program
Files\Microsoft BizTalk Server 2006\Business Activity
Services\BTSharePointAdapterWS folder. This virtual folder must run in its own
application pool and this app pool needs to be a copy of the SharePoint app pool
(app pool used by _layouts virtual folder). You also need to update the
web.config file like below
—
—>
No, the virtual folder doesn’t have to point to C:\Program
Files\Microsoft BizTalk Server 2006\Business Activity
Services\BTSharePointAdapterWS folder.
—>
If you don’t have a Biztalk 2006 on your MOSS 2007 Server. You need to copy these two files from Biztalk CD to MOSS Server and GAC them.
Microsoft.Biztalk.KwTpm.OfficeImporters2.dll
Microsoft.Biztalk.Tracing.dll
I’ll attach webservice you need to copy and detailed workaround you need.
Hope it helps.
