Dublin Sessions from the BizTalk Users Group in Sweden on Channel 9

by community-syndication | Jun 18, 2009 | BizTalk Community Blogs via Syndication

I was asked to present at the BizTalk Users Group in Sweden on June 4th. I presented on the new enhancements to the Windows Application Server role known as Dublin.

The two sessions are now online on Channel 9. The first session is a walk-through of the value proposition of Dublin and Workflow Services. The second session is a little deeper dive into tracking and monitoring.

Details on each session are below.

Session 1: Inside the Windows Application Server Enhancements known as Dublin (1/2)

Abstract: In this session we will review the features of the Windows Application Server Enhancements code named Dublin. This session will show how to use new and enhanced concepts in the .Net 4.0 framework to empower Services hosted in Windows allowing users insight into service health and activity.

Session 2: Inside the Windows Application Server Enhancements known as Dublin (2/2)

Abstract: This session takes a deeper dive into Windows Application Server Enhancements by looking in detail at the hosting of a Workflow Service. This will cover reviewing a web service aggregator Workflow Service, setting up custom tracking, monitoring running services, and import and export of applications.

One of the top question I receive is when can I get the code for Dublin? Microsoft stated at TechEd US 2009 they planned for a public beta of Dublin around the PDC 09 timeframe.

Enjoy and please post any comments or questions.

BizTalk R2 WCF Authorization

by community-syndication | Jun 18, 2009 | BizTalk Community Blogs via Syndication

Let me share a quick story. We’ve been using BizTalk Server 2006 for a couple of years now at my company. We recently upgraded to R2, and I was excited to get the opportunity to work with WCF… so a few months ago I created my first WCF service. Things worked about like what I […]

Call orchestration with ref parameter in a loop

by community-syndication | Jun 18, 2009 | BizTalk Community Blogs via Syndication

Sometime back I worked on a case where the spool would go very high and I have been thinking to blog this for some time now and today I decided I will process this awaiting queued item in my mind.

I had a customer who was seeing a surge in the spool count whenever an orchestration instance started and spool would go back to its original count only once this instance get completed. As we all know, the high count of spool impact Biztalk processing, the customer was too worried about it.

Looking into the orchestration, they have got a loop shape which could loop up to 40K times or even more. In this loop, they were calling an orchestration with Biztalk message being passed as ref parameter.

We found that with REF we need to keep messages around until the orchestration completes, so that is why the spool count keeps growing till the loop completes and once the orchestration instance completes, Biztalk jobs would clean up messages from spool. This is by design.

To demonstrate this, we got a simple orchestration with a loop inside. This will loop for 50 times only.

Inside the loop, we are making a call to another orchestration and passing Biztalk messages as REF parameter.

If we test it, and monitor the spool count in perfmon, we will see that spool keeps growing until the loop completes and once the orchestration instance completes, Biztalk jobs are quick to clear the spool.

As a workaround for REF parameter, if we pass a message as IN parameter and have one more OUT parameter of the same type in the called orchestration to return the result, I see that spool growth is lower than while using REF parameter, but still for very large loops spool count can grow substantially.

Also, if possible we can try using variables instead – which can be reused as opposed to message.

So moral of the story is we have to avoid large loops with call orchestration shape passing ref parameter. We would suggest using smaller loop, or removing the call structure by using expression Shape or custom object etc.

Random File Message Creator Component for LoadGen

by community-syndication | Jun 18, 2009 | BizTalk Community Blogs via Syndication

LoadGen is my favorite tool to perform automatic testing in BizTalk. It is easy to configure and extensible.
When I want to mimic the characteristics of the BizTalk production environment in a test lab as close as possible, LoadGen is the way to go. The load, in terms of number of messages per time unit, […]

What is a BizTalk Application?

by community-syndication | Jun 18, 2009 | BizTalk Community Blogs via Syndication

The absence of guidelines and discussions on this topic puzzles me. As I’ve asked myself this question many times, without coming up with a one-size-fits-all solution. Is it a “Process”, a “System” or perhaps a “Unit of deployment”?

The BizTalk Documentation doesn’t shine much light on the subject:

“The BizTalk application is a feature of BizTalk Server that makes it quicker and easier to deploy, manage, and troubleshoot BizTalk Server business solutions. A BizTalk application is a logical grouping of the items, called "artifacts," used in a BizTalk Server business solution”

All that is of course true, but what does a BizTalk Application resemble? It often comes down to if you think of your BizTalk investment as a Service Bus or an Integration Platform. In relation to my own experience, I’ve tried to list pros and cons, using the BizTalk Application as a “Process”, a “System” or a “Unit of Deployment”.

if (BizTalk.Application == “Process”)

You could very well use the notion of a BizTalk Application as a Process such as “Order Processing” or “Payroll Processing”, deploying all the artifacts, related to that process, to the appropriate BizTalk Application. This works best if the Processes are well defined in the organization, and not made up as you go along developing your BizTalk solutions. I sometimes find it difficult to scope a “Process”, as Processes tend to overlap each other.It can therefore be a good idea to limit the number of Applications to reflect only the main processes (<~20), as you might otherwise run into trouble with lots of references between your Processes and reusable sub-processes.       

figure1. Both the send and the receive port are implemented in the “Order Process” Application.

As working with Processes might work fine from a developing perspective, if can turn out to be a nightmare from a maintenance point of view. If one or more systems has to shut down for maintenance, how would you know what ports to stop or disable? You could solve this reflecting the name of the system in the port name, E.g. Rcv_SAP_OrderConfirmation or Snd_Navision_SalesStatistics. But you’d have to use Applications.<All Artefacts> to find the ports, which can be painful having 100+ ports. 

If you are using BizTalk as an ESB, it’s difficult to fit On- and Off-ramps to anything but processes, as it would otherwise prohibit reuse of those services. For example, say you have a receive port providing contact information to anyone who cares to call it. The service in it self would in this case be a composite service (orchestration), made up of several calls to CRM and HR systems in order to return all contact related information about a person. Deploying that port a “Process Application”, would promote it to be a reusable port for anyone to consume, given, of course, that they are privileged.

else if (BizTalk.Application == “System”)

Grouping your ports and orchestrations by Systems, might come natural as services most often “belong” to a System. If your organization has identified “System owners”, it’d easy to find the responsible person for a particular end point.

figure 2. Ports are implemented in different applications, resembling the systems from where the message is received and sent to.

The flip-side, of course, is the lack of Process orientation. As the business side of the organization tends to talk in terms of Processes, you might find it challenging to find the relation between services and business processes. However, these processes are often implemented as orchestrations which makes things much easier.

In relation to the ESB context as mentioned above, – Reusable services are difficult to govern! If your organization finance the BizTalk platform based on how it’s utilized by its consumers, how would you know how many times the service has been called by each consumer? If you think of a BizTalk Application as a System you’d reuse on the level of orchestrations. Each new consumer would need its own service, which could have its own SLA. 

The only problem is that, having orchestrations with port bindings across Application boundaries causes circular references. This is because, in order to bind a port to an orchestration, the port has to belong to the same application or a referenced one. I still struggle to understand the purpose of the “Application reference”, but it will eventually put you in a situation where you can’t bind the port because it belongs to an Application that is already referencing the Application your orchestration belongs to. You could of course get around this by using “Direct bound” ports in your orchestration, which often is a general recommendation.        

else if (BizTalk.Application == “Unit of Deployment”)

Using the BizTalk Application as a “Unit of Deployment” means you’d group all your projects that can be deployed and undeployed together, into a single solution and deploy the whole package to a “Solution Application”. The downside in this case would be reusability, since you have to make sure there are no project or binary references to projects that is not part of the solution. – If there are, undeployment will get messy!

This is similar to “Application == Process” in all but the size of the “Process”. In my opinion, this works best for smaller BizTalk implementations, as this could otherwise cause any number of Applications.

In all fairness, you can create isolated, deployable  solutions for both the “Process” and “System” approaches as  described above. It would require more work and structure. But it can be done, as I’ve described in this article.

else if (BizTalk.Application == “BizTalk Application 1”) // ONE Application rules them all!

I don’t like this at all, but it does comes with some advantages as; no issues with Application references, easy deployment and of course the fact that you could disregard everything said above. But the lack of structure, not to mention size of the beloved combo boxes to select schemas and mapping from, would cause me to advise against this approach   

else // let’s be pragmatic

As developers are often found in the crossfire between the business and the maintenance, we are forced to take sides. But perhaps we could make a compromise. We could go with the “Application == System” approach, for all our proprietary ports and send ports, exposing system specific schemas. -But deploy our orchestrations and ports with canonical contracts to “Process Applications”. To solve the issue of governance, we could use Party resolution to monitor the usage of these “generic” services.

This would work from an deployment perspective as well, as we wouldn’t have to worry about Application references since “Process Applications” would never have to reference other “Process Applications”.

figure 3. All send ports and receive ports exposing proprietary schemas and protocols are deployed to “System Application” whereas public reusable receive ports are deployed as part of a “Process Application”.

BTW, I know I should have used a switch statement

New Webcast showing the latest bits of Dublin!

by community-syndication | Jun 17, 2009 | BizTalk Community Blogs via Syndication

We were honored to have Stephen W. Thomas visiting Stockholm, to do two much appreciated sessions on Dublin. If you’re curious about the Windows Application Server Enhancements (known as Dublin), don’t miss these webcasts showing the very latest bits!

http://channel9.msdn.com/posts/johanlindfors/Inside-the-Windows-Application-Server-Enhancements-known-as-Dublin-12/

The second webcast is being published as we speak.

Learning by example with 4

by community-syndication | Jun 17, 2009 | BizTalk Community Blogs via Syndication

We feel that learning by example is one of the easiest ways to get started with Windows Workflow Foundation (WF) and Windows Communication Foundation (WCF).  In fact, we find that we often use code samples internally to get people from different feature teams all on the same page.  Therefore, it seemed only natural to think that others outside of Microsoft would benefit from the same types of samples.  We took these existing samples, cleaned them up and added more to fill in gaps to cover as much of the product as we could.  The result was our current sample set: downloadable here and documented here.

With beta1, the product unit authored and shipped 88 new samples for WCF and WF 4.  The samples themselves have been organized by type: Basic, Scenario and Application for WF and Basic, Scenario and Extensibility for WCF.  Basic samples are samples that demonstrate basic usage of a specific feature.  Think of these samples as the hello world of each feature.  Scenario samples show the usage of a set of features used in tandem.  They show specific use cases of our product and apply basic features to demonstrate common patterns.  The extensibility section for WCF exists to conform to the 3.0 WCF sample layout in MSDN Library.  Think of these samples as demonstrating ways to extend WCF beyond its built-in feature set.  Application samples show how many patterns can be used together to provide an end-to-end solution to a common problem.

We see each type of sample fulfilling the needs of different learning and usage styles.  For example, basic samples can be used to quickly familiarize yourself with specific features.  Scenario samples can be used to see what we feel are common patterns for WF and WCF.  These were common enough patterns that several scenario samples actually started as product code that was later move to a sample for one reason or another.  Of the scenario samples, I’d like to specifically call out the WF Activity Library.  This provides a number of activities that were not built into the product but we felt to could be used in many different applications (for example, there’s a SendMail activity, a Regex activity, a For Activity, and many more).

The WCF sample set, like the product changes, are additive.  This means that most of the pre-4 WCF samples are still relevant.  However, the samples currently shipped in the download linked to above are just for new features in Beta1.  In Beta2, the samples download will also include most of these samples shipped with 3.0-3.5sp1.  The new WCF samples include, Discovery, Event Tracing for Windows, Routing services, and more.

Look them over, let us know what you think by commenting on this post and responding to the WF and WCF code sample survey.  We do take your feedback seriously.  Need help with a particular scenario but couldn’t find a sample that demonstrated a similar pattern?  Others are probably in the same boat – letting us know can help us make learning WF and WCF easier for you and others moving forward.

ESB Toolkit How To Video #4: Dynamic Itinerary Resolution

by community-syndication | Jun 17, 2009 | BizTalk Community Blogs via Syndication

Welcome to #4 in my series of ESB Toolkit How To Videos. Each of these videos has built up from the one before it, so if you have seen the previous videos, I encourage you to do so. In video #3 (found here), I showed you how to use the toolkits new “Itinerary Resolution” feature.  In that video, I showed you how to use the Static Itinerary Resolver within a BizTalk receive port to load up an itinerary from the itinerary database and attach it to an incoming message. To do this, we added a resolver configuration string to the pipeline such as “ITINERARY:\\name=DemoService;” (where DemoService was the itinerary that we wanted to load) One shortcoming of that solution is that had multiple itineraries you would need a different receive port for each one.  In a real world solution, you might want to assign an itinerary to a message based on the message’s schema, or some piece of data found within the message or based on who sent it and you would want to do all of this with as few receive ports as possible.  Therefore, the ESB really needs to be able to dynamically and intelligently figure out what itinerary an incoming message needed with us having to hard code the name.

Fortunately, the ESB Toolkit provides us a flexible and intelligent way to resolve itineraries and this is the Business Rules Engine resolver. This allows us to the use the BizTalk Rules Engine to make a decision about what itinerary should be used. We can create rules to look at Context properties associate with the message (such as the message type, the sender etc) or we can look at the content within the message to make our decision on which itinerary to use. In this video, I’ll show you how to create an BRE policy to resolve itineraries and I’ll show you how to setup your BizTalk receive ports to use this policy. I’ll show you how to implement context and content based itinerary resolution.

Here’s the link to the video

Cheers and keep on BizTalking…

Peter

How-To: Clone or Copy a VirtualBox Virtual Disk

by community-syndication | Jun 17, 2009 | BizTalk Community Blogs via Syndication

Originally posted by Nick Heppleston at: http://www.modhul.com/2009/06/17/how-to-clone-or-copy-a-virtualbox-virtual-disk/
As a virtual machine environment user, I regularly create ‘base’ images of machines that I can reuse – a base Windows Server 2003 environment, or SQL Server 2005 environment for example. That way, when I need a new machine, I can simply create a copy of the virtual disk […]