Oops, this must be the longest and worst blog post title you have ever seen. Let’s quickly make clear what I mean:
Recently I needed to update multiple elements using a single rule in the Business Rule Engine (BRE). To most BizTalkers this is nothing special. The thing that complicated this particular scenario was that the […]
I’ve spent a few minutes last night reading this “how to” guideline from IBM, I have to admit that for a while I was affraid that somebody was going to come up with this idea but I really thought that we, as a community, were pass this stage of understanding…(read more)
I know I’m going to forget how to cluster the ESSO Master Secret Server, so I’m including a link to this technical article for Microsoft Host Integration Server 2004 which gives the most succinct version of the instructions to this non-trivial task I have found so far – see ‘5.4 Clustering the Master Secret Server’ […]
The BizTalk 2006 R2 Management Pack is a rewrite from the original pack for Microsoft Operations Manager 2005 (MOM). It is designed around all of the new features of BizTalk 2006 R2 including RFID and EDI. The pack ties into SCOM very nicely and once it has been imported into SCOM, it can automatically scan […]
If you store BizTalk application settings in Enterprise SSO database and adapt continuous integration you’ll find this MS Build task useful. DeploySSOConfigStore task reads settings from XML configuration file and saves them to the SSO database. The XML can be created (exported) using Richard Seroter’s SSO tool which I modified to support this operation. So, if you change your configuration settings, just update XML file in the source control and build process will pick it up and propagate changes to your target environment.Using this task is very simple, it accepts just one parameter -location of the XML settings file:
<UsingTask AssemblyFile="CustomMSBuildTasks.BizTalk.dll" TaskName="CustomMSBuildTasks.BizTalk.DeploySSOConfigStore"/> <Target Name="DeploySSOConfigStore" DependsOnTargets="BizTalkDeploy"> <CustomMSBuildTasks.BizTalk.DeploySSOConfigStore XmlConfigurationUrl="$(SolutionRoot)\$(BuildBranch)\Source\BizTalkSettings\BizTalk.Configuration.xml"/> </Target>
I also added another useful task for publishing WCF services: PublishBizTalkWcfServices. It’s very simple but does all that stuff:setting upvirtual directories (if needed), publishing contracts, creating receive locations. It has comprehensive logging thathelps tracking down deployment issues quickly.
public class PublishBizTalkWcfServices : Task { private string serviceDescriptionUrl; /// <summary> /// The URL to the description file. /// </summary> [Required] public string ServiceDescriptionUrl { get { return serviceDescriptionUrl; } set { serviceDescriptionUrl = value; } } /// <summary> /// Publishes BizTalk schemas as WCF services. /// </summary> /// <returns></returns> public override bool Execute() { WcfServiceDescription description = WcfServiceDescription.LoadXml(ServiceDescriptionUrl); Publisher publisher = new Publisher(); publisher.BackgroundWorker = new System.ComponentModel.BackgroundWorker(); publisher.BackgroundWorker.WorkerReportsProgress = true; publisher.BackgroundWorker.ProgressChanged += new System.ComponentModel.ProgressChangedEventHandler(BackgroundWorker_ProgressChanged); try { PublishingResults results = publisher.Publish(description); Log.LogMessage(results.Message); } catch (Exception ex) { Log.LogError(ex.ToString(), null); return false; } return true; } public void BackgroundWorker_ProgressChanged(object sender, System.ComponentModel.ProgressChangedEventArgs e) { Log.LogMessage(e.UserState.ToString(), null); } }
Complete Visual Studio project is available here.
Well I didn’t have any time to blog during Teched (by the end of my last talk I was completely exhausted and I still had to work at the booth with my friend Clemens Vasters ) but I survived. I really wanted to thank to all the folks who attended my sessions…(read more)
What a week! TechEd is always one of my favorite shows. Not just for learning, but also for the connection to developers- the heart that keeps the blood pumping. Just wanted to do a quick post to wrap up the show this week and a brief glance toward this week’s activities.
For me, one of the most exciting things this week was providing additional insight into Oslo. In Gates’ Tuesday keynote he highlighted (excerpt here) our investments in a new modeling platform, which will help take model-driven programming mainstream. He talked about a world in which models describe bits and pieces of the application design to a world where models are connected across the end to end lifecycle and where they are the application. You heard Bill correctly- we will deliver a CTP of Oslo technologies at PDC this year, as mentioned at the SOA & BP conference last year. Stay tuned for the PDC!
I’m particularly passionate about this subject, so let me take a minute and dive into this a bit deeper. Over the last several years, the world has become increasingly model-driven. As referenced in the press release, Oslo delivers core technologies and tools to help manage the model–driven world. This platform will help further inspire collaboration between all the necessary roles of the application lifecycle, as well as enable applications to be more easily managed, deployed, and evolved. Oslo will add new advancements within the areas of visual modeling and composition tools, a foundational repository for managing application metadata, and a new, declarative modeling language to enable interoperability of models between tools and domain specific modeling notations.
Separate, but related to Oslo I have really been thinking about the convergence of model-driven programming with other important trends including Saas, SOA and ’cloud’ virtualization. See my post from yesterday for additional context. There will be a video on the topic published later this week.
This week at TechEd IT Pro, Greg Leake will be doing a demo of his .NET StockTrader 2.0 sample application (see my earlier post) during Bob Muglia’s keynote. Greg will be showcasing the interoperable capabilities of Windows Communication Foundation and will also be joined with partner, WS02, on stage who also worked with Greg on making the app interoperable on the Apache platform. OH by the way.did I mention the .NET StockTrader 2.0 and Configuration Services 2.0 download is now available? Congrats Greg- really impressive work. Also, there be an Interop panel next Tuesday, June 10 at 2-3 pm ET with WS02, Sun and TIBCO to discuss how interoperability is important today and the role it plays for customers in the future.
I’m sitting in the Vancouver airport reflecting on a very successful and interesting 2 day deep dive training course that we ran for our west coast partners. This was the first time that we ran the course over two days, and it allowed us to get a lot deeper into the code than we normally would in a one day session. Because of this, we received a lot of great questions from the developers who attended. While I’m waiting for my flight, I thought I’d blog about a couple of them.
Those of you familiar with the concept of Off-Ramps in the Microsoft ESB Guidance for BizTalk server will know that they are implemented using Dynamic BizTalk send ports. Dynamic ports have the ability to configure themselves at runtime based on contextual data stored within a message. The message itself is able to tell the dynamic port how to function, what transport protocol to use, what endpoint to point towards etc. The ESB guidance contains an adapter provider mechanism and a resolver mechanism which allows you to store this configuration data in external data stores like a UDDI server, SQL Server, a rules engine etc. The ESB resolver mechanism looks up this information from this remote data store and feeds it into an adapter provider. The adapter provider then converts this data into a format that a BizTalk dynamic port can use to configure itself.
BizTalk also has the concept of static ports which do not load configuration data at runtime but instead require an administrator to hard code configuration data right into the port. Static ports are not as flexible as dynamic ports and are therefore not as effective when implementing an ESB pattern. However, they do have a number of interesting features that aren’t seen in dynamic ports. One of these features is the ability to define a retry interval and a set number of retries. If the port fails to transmit a message successfully the first time, it will shut down and then retry the message after a set period of time. The port will continue to try and resend the message until it reaches a maximum number of retries. A BizTalk administrator can set the length of the retry interval and the number of retries for a static port directly in the BizTalk administration console. However, when you create a dynamic port in the admin console, these configuration options do not show up. The question that one attendee asked was
"Since the ESB guidance is heavily dependant on dynamic ports , is it unable to support retries"?
Fortunately the answer is definite "NO". The ESB guidance with its adapter providers is able to support retries. To do this, you need to tweak the adapter providers classes to tell them to set this property for us.
The adapter providers effectively work like a dynamic runtime level BizTalk administrator, they provide a complete set of configuration information to the dynamic port. The adapter providers pull this information from the resolver mechanism which is able to connect to the UDDI server, database server etc. In the basic guidance, the adapter providers pull down a small subset of configuration information from the resolver mechanism. We can modify this to pull additional information such as retry settings.
I’ve outlined the steps below that you need to follow in order to implement retry functionality. For this walk-through, I’m going to use the UDDI server to store our information. I’m also going to be working with the WCF-basicHTTP adapter provider that allows us to implement SOAP 1.1 messaging
1) The first step is to modify the service entry in the UDDI server so that it contains the retry settings. Open up the service entry in the ESB that you want to implement retries for. Add a new binding to this service call called "RetryCount" and give it a value of "5" (i.e. the adapter will retry 5 times). Create a second new binding called "RetryInterval" and set this equal to "1" (this means retry every 1 minute).
2) We don’t need to modify the resolver mechanism as it is already built to automatically pull down any and all information from the UDDI registry. As long as we put the data in there, it will pull it down and given it to the adapter provider, which we’ll do next.
3) Open up the Microsoft.Practices.ESB.sln solution file and open the ESB.Adapter.WCF-basicHTTP project. Inside this project, open the AdapterProvider.cs class. If you scroll down to lines 82 and 83, you’ll see where the adapter provider takes the settings retrieved from the resolver and attaches them to the outgoing message as adapter properties. You will need to add the following 2 lines in the section.
pipelineContext.Write(BTS.RetryCount,"http://schemas.microsoft.com/BizTalk/2003" , ResolverDictionary["Resolver.RetryCount"] );
pipelineContext.Write(BTS.RetryInterval, "http://schemas.microsoft.com/BizTalk/2003", ResolverDictionary["Resolver.RetryInterval"] );
This code will retrieve the settings we made in UDDI and will attach them to the outgoing message context. The dynamic adapter will then use these settings when it attempts to send the message.
4) Build and deploy the new version of the adapter provider project.
5) Restart the BizTalk host instance and the IIS service instance
That’s it, you’ve implemented retry capabilities in ESB guidance for the WCF-basicHTTP OffRamp.
Cheers and keep on BizTalking
This week I’m going to embark on a dark and mysterious journey, fraught with great danger, both real and imagined. I’m about to begin development of a BizTalk Accelerator for RosettaNet (BTARN 3.5) project with the assistance of Microsoft Consulting Services. For those of you experienced in BizTalk development, you’ll understand my trepidation. For those of you familiar with RosettaNet (RNIF), you’ll understand my sheer terror!
If I survive this ordeal, I promise to post about my experiences, so that future generations of BizTalk developers don’t make the same mistakes, don’t fall into the same traps and don’t lose what little is left of their rapidly graying hair!
Stay tuned!
I’ve got a couple of fun talks coming up this month. First, I’m going to be doing an MSDN webcast on Windows Workflow Foundation – Communication in Depth. I’m going to dive into the core communication architecture, discuss how some of the OOB activities use it, and how you can build your own activities to take advantage of it. We’ll cover one way communication between the host and the workflow, but we’ll also look at how to do two-way communication to get a response back from the workflow.
The talk information can be found at this link:
Windows Workflow Communication in Depth
This talk is also part of a series where you can find other talks from my friends Jon Flanders and Jesus Rodriguez on other .NET 3.5 topics. The link for the series is here:
http://www.microsoft.com/events/series/msdnnetframework35.aspx?tab=webcasts&id=liveall
I’m also doing a local talk this month at the Microsoft office if you are in the Minneapolis area. I’ll be talking about building connected systems with WF and WCF for developers and architects. This will be a good talk if you are interested in these technologies and want to learn more about how to use them to build real applications.
Event information and registration
I had a great time at Tech Ed and I’m looking forward to the conferences coming up this fall (Minnesota Developers Conference where I’ll be doing talks on LINQ and ADO.NET Data Services and Heartland Developers Conference where I’ll be talking about BizTalk Services and the “Internet Service Bus”).