What is a BizTalk Application?

Listen with webReader
Published 18 June 09 03:00 PM | wmmihaa

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…


# wmmihaa said on June 21, 2009 09:57 AM:

I go for "unit of deployment, functionality and management", there is the Admin perspective...

Start / stop an application

What applications are running?

What application caused an error?

Somewhat similar to applications in IIS...

It gives you a lot of fredom to structure the deployment, but the definition is not really fixed.

(The licenceing team really messed it up when the std edition of 2004 had a limit of 5 (or 10) "Applications". I guess that the applications concept got pulled from 2004 at the last minute, and they didn change the licence (can you think of a better reason?) I heard a number of very strange definitions of what an application was in 2004 (mostly form MS people), and customers were thinking you could only have 5 orchestrations deployed, or 5 dlls, or only connect to 5 systems, i think some of this confusion still remains....)

# Richard Hallgren said on June 28, 2009 07:19 PM:

Nice post! Really liked it! It is also an area where I've debated with myself for a while so it nice to see such a well thought out and written post.

I agree with Alan that "unit of deployment and manageability" is the way I thought and defined applications in the past. It's also the way that has worked for me even in larger environments (50 + applications).

I usually structure my deployment frameworks so that I can tear down an entire application and rebuild it when deploying without having to worry about "side effects" . This approach usually works best with really small applications and that don't have lots of dependencies to other applications.

Another principle I try and work by is that one Visual Studio solution should map to one BizTalk applications. This makes it easier to find, build and re-/deploy an application.    

Having lots of small separate applications I found also simplifies multiple people working in the same environment without "stepping on each other toes".

# Changi Kudi said on October 17, 2009 03:02 PM:

Is there a way to find out the names of applications that have status other than 'Started'?  I searched the WMI classes for BizTalk, but they do not seem to provide this information...

The BizTalk Management DB has it in the bts_application table (found this info from an MSDN forum), but it just lists the apps that are started.  It doesn't give the apps that have status other than 'started'.


# wmmihaa said on October 17, 2009 09:10 PM:

I'd recommend to use ExplorerOM:

BtsCatalogExplorer explorer = new BtsCatalogExplorer();

explorer.ConnectionString = string.Format(ConfigurationManager.ConnectionStrings["BizTalkMgmtDatabase"].ConnectionString, server, database);





# Be Logical - writings by Johan Hedberg said on October 5, 2010 10:53 PM:

Before I uninstall BizTalk Server 2010 Standard Edition and go back to Developer I thought I’d run one

# E. said on March 8, 2011 03:23 AM:

Thanks Mikael: great article.

This Blog


    MVP - Microsoft Most Valuable Professional BizTalk User Group Sweden BizTalk blogdoc

    Follow me on Twitter Meet me at TechEd


    Locations of visitors to this page


    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.