FIX: BizTalk 2013 and Windows 10 Upgrade - Error: MMC could not create the snap-in

I recently upgraded my machine from Windows 8.1 pre-installed with Microsoft BizTalk Server 2013 to Windows 10. To my surprise almost everything else was working fine except BizTalk Administration Console.

Following was the error thrown MMC could not create the snap-in as soon as I tried to run btsmmclauncher.exe 

The fix is pretty easy, all you need to do is repair your installation. You don't even have to reconfigure it again. To repair the installation, follow the steps below:

• Run the BizTalk Server installer and Click on Install Microsoft BizTalk Server 2013.

• In the next screen select Repair and click on Next.

• Wait for the repair to complete, it will automatically re-create the registries for MMC and will fix the issue. Click on Next.

• Once the Repair is complete, try relaunching the BizTalk Admin Console, the problem should be gone!

In case you face any issues, feel free to drop comments and I'll be more than happy to help :)

Enjoy the new Windows 10 and Happy Integrating!

BizTalk Artefacts - Send Port Groups, Send Ports and Send Pipelines

Send Ports and Send Port Groups are subscribers of BizTalk's Message Box. They constantly look for messages intended for them in the message box.

Send Port Groups are named collection of Send Ports that BizTalk server can use to send data to multiple destination systems or locations by using one/single send port group configuration. 

Send port groups have filters (Filter 'X' in below image) which do the job of filtering messages, to allow messages whose context properties matches with the filter 'X' to go though send ports associated with it. It is optional to have a send port group in a BizTalk solution.

Send Port is the location from where BizTalk server can send (or receive in case of two way ports) data to destination system (System "B"). The Send port have a Send Adapter which takes care of the communication and transport with the destination system. Before sending the message Send Port processes the message through Send Pipeline which performs a set of operations on BizTalk message and make it ready to be sent to destination system. Send Pipeline takes one message and produces one message as output.

Just like send port groups, send ports can also have filters (Filter 'Y' in below image). Only the messages whose context properties matches with the filter 'Y' of send port, goes through it, rest of them are not picked up from Message Box.

These filters (X and Y) are static subscriptions on message box database. Subscriptions can be generated on runtime as well. When an orchestration is sending a request via two way send port and expecting a response in return. In that scenario, BizTalk internally correlates each request and its corresponding response by creating dynamic subscriptions on message box. It creates a GUID (or correlation id generated internally) while sending the message to send port and creates a subscription on runtime so that the response from that send port can be correlated and sent to the same orchestration instance which intiated that request.

What if we have a send port associated with a send port group and both of them have filters?

There can be the following there scenarios where the message in message box satisfies the filter conditions of:

1. Send Port Group Only:  The message will be picked up by send port group from message box and will be sent to all the send port associated with it irrespective of the filter conditions on send ports.
2. Send Port Only: The message will be picked by the send port whose filter condition matches.
3. Send Port and Send Port Group Both: Two copies of the message will be sent as their will be two subscriptions.

Send Port Groups, Send Ports and Send Pipelines

Send Pipeline have the following three stages:

1. Pre-assemble: This stage can contain custom components that can do any preprocessing if required before the message is serialized. This stage can have 0-255 components and they all are executed.
2. Assemble: This stage is responsible for assembling or serializing the message to XMLs. This stage can have 0-1 component and they are all executed.
3. Encode: This stage can host MIME/SMIME components or custom components which encodes or encrypts the message before sending it to send adapter. This stage is optional and is only used encryption is required. This stage can have 0-255 components and they all are executed.

Please provide your valuable comments below and help me in improving this article.

BizTalk Artefacts - Receive Ports and Receive Locations

A receive port is a LOGICAL collection of one or more receive locations that define specific entry points into BizTalk Server. Receive port also specifies Maps which automatically gets executed when receive locations publishes message which matches the input type of Maps. A receive location is the configuration of a single endpoint (URL) to receive messages. The location contains configuration information for both a receive adapter and a receive pipeline. The adapter is responsible for the transport and communications part of receiving a message. For examples File adapter knows how to read a file from a folder/shared drive. The receive pipeline is responsible for converting this message into BizTalk's message so that it can be published into the MessageBox. This receive pipeline is a series of components that are executed in sequence, each providing specific processing to a message such as decoding, disassembling, parsing or validation and party resolution.

Receive Port, Receive Pipeline and its components

Their are four stages of a receive pipeline. They are executed in a defined sequence as shown in above figure. Each of the components in each stage process the message and hand-overs its output to the other component.

1. Decode:  This is the first stage which takes the incoming message from receive adapter and decodes or decrypts it. The MIME/SMIME Decoder Pipeline component or custom decoding component should be placed in this stage if the incoming message is to be decoded from one format to another. After decoding the message is handed over to Disassemble stage.
2. Disassemble: The components of this stage checks the message to see if the format is recognised. The first component in this stage whose format matches the message format is executed. If none of the components are able to recognise the format, message processing fails. The components disassembles the message into individual messages if the message is a batch (or envelop). XmlDisassembler component can be used to debatch and promote MessageType into the message context.
3. Validate: This stage is executed for each message the disassemble stage produces. It validates the message produced by disassemble stage against a schema. Only schema compliant message are processed.
4. Resolve Party: This stage does the job of party resolution, where the Party Resolution pipeline component maps the sender certificate to the corresponding configured in BizTalk Server party. Party Resolution component takes the WindowsUser (populated by adaper or custom pipeline component) and SignatureCertificate (populated by adapter or decoder component) from message context. By using these promote properties the component tries to get the party to which the message belong. So that the message sender can be validated. For more information on Party Resolution please check this article.

Each of the pipeline stages can have 0-255 components with or without custom code as per need.

BizTalk Architecture

BizTalk Architecture Level-2 DFD

In continuation to my previous post which explains BizTalk Server from a very high altitude. This post gives a more drill down view of the BizTalk's core architecture. I have tried to use the same colours and shapes to make it easy to correlate with the previous article.

BizTalk as an integration platform provides flexibility and customizability at every level to make sure that the requirements are met easily. BizTalk provides a variety of artefacts to achieve this. I'll be explaining all the artefacts in the above image in more detail. However, First I would like you to go through the following brief description of the lifecycle of a message in BizTalk Server:

Everything in BizTalk starts with an incoming message from Receiving System (System "A"). This message can be anything ranging from an XmlDocument, Flat File (CSVs or Delimited) or even a SOAP request!

As soon as a message is sent to BizTalk it is taken up by Receive Port which is a group of Receive Locations each pointing to a particular path or URL. Receive location knows which particular Receive Adapter understands the message received. This receive adapter then handles the transport and communication with System "A" and changes the message into a format (most of the time into XMLs) that is understood by Receive Pipeline. The receive pipeline then takes the responsibility of converting this message into BizTalk's message. After Receive Pipeline, Maps if available are executed. They transform the message into a different format as per requirement and then the message is dropped into Message Box.

Orchestrations, Send Ports and Send Port Groups subscribe to message box and constantly checks if the message they are seeking is available in the message box or not. As soon as anyone of them gets the message they pick it up and process it. Orchestrations are optional (most of the time they are available and contains all the complex logic), if they are present they are then executed, if their subscription matches the message in message box. After their execution is complete, they publish their output to message box. Send Ports or Send Port Groups then picks up the message, executes any Map if available in the send port, it then transforms and transmits the message to the Send Pipeline. The pipeline then performs a set of operations and transforms the message into the format that Send Adapter understands. Finally, the send adapter sends the message to the System "B" by using the protocol which System "B" understands.

What is Microsoft BizTalk Server!!!

Microsoft BizTalk Server or BizTalk is an integration server from Microsoft. It enables integration of disparate systems.

Integration is achieved by using different types of adapters which comes with BizTalk (you can make your own as well!) which understands a particular type of system. Adapters are of two types:

1. Receive Adapters: They are used to receive data from other systems.
2. Send Adapters: They are used to send data to other systems.

Broadly, these adapters transform data from different systems into XMLs (eXtensible Markup Language). These XMLs are then processed by BizTalk Server.

The reason behind using XML is that they are understood by almost every system and hence every system provides its own ways to convert its data into XML (and also the other way round).

The below flow diagrams shows a basic interpretation of BizTalk integration model.

Level -0 Data Flow Diagram

Level -1 Data Flow Diagram