Biztalk Pipeline Interview Questions And Answers

BizTalk Server provides a few out of the box pipeline components. For instance the S/MIME components for encrypting or decrypting messages. In case you need to do some pre or post processing on a message and the functionality is not offered through the provided pipeline components you will need to built your own custom pipeline component. The pipeline component(s) can then be used within a custom pipeline.

The receive pipeline consists of four stages
Decode Stage: This stage is used for components that decode or decrypt the message.
☛ Disassemble Stage: This stage is used for components that parse or disassemble the message.
☛ Validate Stage: This stage is used for components that validate the message format.
☛ Resolve Party Stage: This stage is a placeholder for the Party Resolution Pipeline Component.

Regarding to the send pipelines, they consist of three stages:
☛ Pre-assemble Stage: This stage is a placeholder for custom components that should perform some action on the message before the message is serialized.
☛ Assemble Stage: Components in this stage are responsible for assembling or serializing the message and converting it to or from XML.
☛ Encode Stage: This stage is used for components that encode or encrypt the message.

A runtime schema discovery will be attempted, Biztalk Server attempts to determine the correct flat file schema to assemble the message with, based on the namespace and the root node of the message.

☛ IBaseComponent,
☛ IComponentUI,
☛ IAssemblerComponent,
☛ IPersistPropertyBag

An XML schema defines the structure of a class of XML instance messages. Because this type of schema uses XML Schema definition (XSD) language to define the structure of an XML instance message, and this is the intended purpose of XSD, such schemas use XSD in a straightforward way.

A document schema is used to define a message. It is a definition on an Xml message with optional extensions for flat files, EDI file etc. that enable the parsers to convert the native format into Xml.
A property schema is used to define message context properties. These can be of type MessageDataPropertyBase (the property value is promoted or demoted from/to the message itself) or MessageContextPropertyBase(property value only exists within the message context and can be set by adapters, pipelines or within orchestrations).
If you wish to promote a field from a message into the message context then you need to define a document schema and property schema. In the document schema you promote the required field using the property schema to define the property type that will be used in the message context.

A send port is the combination of a send pipeline and a send adapter. A send port group is a collection of send ports and works much like an e-mail distribution list. A message sent to a send port group will be sent to all send ports in that group. The send pipeline is used to prepare a message coming from BizTalk Server for transmission to another service. The send adapter is responsible for actually sending the message using a specific protocol such as SOAP, or FTP.

Biztalk provides you with a really smart routing feature that allows the engine to decide where to send which message. For example, If you receive a message with the EmployeePaySlip schema, and it has the approved flag to true, it should be redirected to the Finance system Orchestration for making the payments and to the HR system Orchestration for keeping the records. This built in intelligence for the Biztalk engine allows it to route the messages simply based on some content within the messages.
In order to achieve this, the Biztalk engine obviously needs to understand the fields based on which the routing decisions can be taken. To simplify and optimize this working, Biztalk has introduced the notion of “promoted properties”. The Biztalk engine can get easy access to the promoted properties without knowing the entire message and hence it can save loads of time and complexity when dealing with routing. To route a message, the Biztalk engine simply reads its promoted properties and does not care about other contents in the message.

An envelope schema is a special type of XML schema. Envelope schemas are used to define the structure of XML envelopes, which are used to wrap one or more XML business documents into a single XML instance message. When you define an XML schema to be an envelope schema, a couple of additional property settings are required, depending on such factors as whether there is more than one root record defined in the envelope schema

A flat file schema defines the structure of a class of instance messages that use a flat file format, either delimited or positional or some combination thereof. Because the native semantic capabilities of XSD do not accommodate all of the requirements for defining the structure of flat file instance messages—such as the various types of delimiters that might be used for different records and fields within the flat file—BizTalk Server uses the annotation capabilities of XSD to store this extra information within an XSD schema. BizTalk Server defines a rich set of specific annotation tags that can be used to store all of the required additional information.

Yes, a schema (XSD) can have multiple root nodes. In case you have a schema with multiple root nodes you will end up with multiple message types declared in BizTalk, one for every root node. So when you want to create a message you will need to specify exactly which message type you are going to use.

A host is a logical representation of a Microsoft Windows process that executes BizTalk Server artifacts such as send ports and orchestrations. A host instance is the physical representation of a host on a specific server. A host can be either an in-process host, which means it is owned and managed by BizTalk Server, or an isolated host, which means that the BizTalk Server code is running in a process that is not controlled by BizTalk Server. A good example of an isolated host is Internet Information Services (IIS), which hosts the receive functionality of the HTTP and SOAP adapters. Hosts are defined for an entire BizTalk Server group; a collection of BizTalk Servers that share configuration, MessageBoxes, ports, and so on.

A BizTalk application is a logical grouping of the items, called "artifacts", used in a BizTalk Server business solution. Artifacts include the following:

☛ a) Schemas
☛ b) Maps
☛ c) Pipeline
☛ d) Adapters
☛ e) Orchestrations
☛ f) Policies
☛ g) Receive Locations
☛ h) Send Ports
☛ i) Certificate
☛ j) Com Component and scripting

To indicate that the component is a custom pipeline component and in which stage it can be used, couple of attributes are added to the class.

[ComponentCategory(CategoryTypes.CATID_PipelineComponent)] -- This attribute tells that the component is cutom pipeline component

[ComponentCategory(CategoryTypes.CATID_Any)] -- This attribute tells that the component can be used at any stage
OR

[ComponentCategory(CategoryTypes.CATID_DisassemblingParser)] -- This attribute tells that the component can be used only on Disassemble stage

Filters are used to create subscription when orchestrations are not part of the scenario.

When you create a new application, the default pipelines are created and deployed by default and appear in the Microsoft.BizTalk.DefaultPipelines assembly in the References folder for every BizTalk project. The default pipelines cannot be modified in Pipeline Designer. These pipelines can be selected when configuring a send port or receive location in BizTalk Explorer.

Pipelines and pipeline components present out of the box can do most of the tasks for you. But sometime specific message processing or messaging requirements encourage developers to develop custom pipeline components. You can create three types of pipeline components: general, assembling, and disassembling. Each of the three types can additionally implement probing functionality. Each type of pipeline component has an associated interface that must be implemented for the component to be plugged into the BizTalk Messaging Engine; the pipeline interfaces that distinguish the types of components are IComponent, IAssemblerComponent, and IDisassemblerComponent. A custom pipeline component is just a plain .NET class that implements several BizTalk interfaces.

A receive port is a collection of one or more receive locations that define specific entry points into BizTalk Server. 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. Examples include the File adapter and SOAP adapter, each of which receives messages from different types of sources. The receive pipeline is responsible for preparing the message for publishing into the MessageBox. A pipeline is a series of components that are executed in sequence, each providing specific processing to a message such as decryption/encryption, parsing, or validation.

This depends on infrastructure specifications (CPU, Memory, Disk) and on specific (possible) bottlenecks in your Microsoft BizTalk Server system. While BizTalk Server imposes no restriction on message size, practical limits and dependencies might require you to minimize the size of your messages because large messages require more processing resources

No Flat file assembler pipeline component do not validates the incoming XML message

To implement pipeline we have to use the API in the Microsoft. BizTalk. Component. Interop namespace.

Just adding assembly is not sufficient, it needs to be added to component dll at location : C:Program FilesMicrosoft BizTalk Server
2010PipelineComponents and then reset the toolbox, it will be visible and ready to use.

Yes. XML envelopes serve two purposes within XML instance messages sent and received by Microsoft BizTalk Server:

XML envelopes can contain data that supplements the data within the XMLdocuments. This data can be promoted into the message context by the XML disassembler to provide easier access from a variety of BizTalk Server components. For outbound XML instance messages, the XML assembler can demote values from the message context into an envelope for inclusion in the instance message transmission.
XML envelopes can be used to combine multiple XML documents into a single, valid XML instance message. Without an envelope to wrap multiple documents within a single root tag, an XML instance message containing multiple documents would not qualify as well-formed XML.

IProbeMessage interfaces are used in developing a custom Probing components

Setting the Document Schema property is required, all other properties are optional.

.btp file is a BizTalk Server pipeline file.