BizTalk Server Technical interview Questions and Answers :-
1. What is BizTalk?
BizTalk is a middleware that sits in the middle of any two softwares who wish to communicate with each other and agree on some specified communication pattern. It uses SQL Server as back end database.
2. What is a BizTalk Application?
A BizTalk application is a logical grouping of the items, called “artifacts”, used in a BizTalk Server business solution. Artifacts include the following:
1. BizTalk assemblies and the BizTalk-specific resources that they contain – orchestrations, pipelines, schemas, and maps
2. .NET assemblies that do not contain BizTalk-specific resources
4. Send ports, send port groups, receive locations, and receive ports
5. Other items that are used by the solution, such as certificates, COM components, and scripts
3. What is a Message Type (i.e. BTS.MessageType) and how is it used in BizTalk?
Message Type is a BizTalk System property that is promoted inside a Pipeline. It is made up of Document Name Space Root # Node Name.
4. What is the lifecycle of a Message in BizTalk server?
A message is received through a receive location defined in a given receive port. This message is processed by the pipeline associated with the receive location, and if there are any inbound maps associated with the receive port they are executed. The resulting message is then published to the MessageBox database. The MessageBox evaluates active subscriptions and routes the message to those orchestrations, and send ports with matching subscriptions. Orchestrations may process the message and publish messages through the MessageBox to a send port where it is pushed out to its final destination.
5. What is BAM used for?
BAM is used to monitor business milestones and key metrics in near real-time throughout a process in BizTalk.
6. What is the Rules Engine?
Rules are used to provide highly efficient, easily changeable business rules evaluation to Business Processes. This allows rules to be changed without rebuilding and redeploying .net assemblies. The Business Rules Engine (BRE) can also be called from any .net component through the API’s.
7. What are different types of BizTalk Schemas?
1. XML schema: 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.
2. Flat file 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.
3. Envelope schema: 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 are more than one root record defined in the envelope schema.
4. Property schema: A property schema is used with one of the two mechanisms that exist within BizTalk Server for what is known as property promotion. Property promotion is the process of copying specific values from deep within an instance message to the message context. From the message context, these values are more easily accessed by various BizTalk Server components. These components use the values to perform actions such as message routing. Promoted property values can also be copied in the other direction, from the more easily accessible message context back into the depths of the instance message, just before the instance message is sent to its destination. A property schema is a simple version of a BizTalk schema that plays a role in the process of copying promoted properties back and forth between the instance message and the message context.
8. What is the difference between a Document Schema and a Property Schema?
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.
9. What is the difference between a Distinguished field and a Promoted Property?
• Distinguished fields are light weight and can only be used inside an Orchestration.
• Promoted Properties are defined inside a property schema, are tracking in SQL, can be tracked in HAT, and can be used for content based routing.
10. What is Property Promotion and why is it required?
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.
11. Can an envelope schema consist of more than one schema type?
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 documentswould not qualify as well-formed XML.
12. What are different types of binding modes in BizTalk Server?
BizTalk offers four binding models, each with different characteristics. Each model is really a set of higher level abstractions of the basic BizTalk subscription mechanisms. One of these models is called ‘Direct Binding’. The term ‘direct binding’ is used to suggest that the techniques involved are all about binding one orchestration port directly to another. In fact, this is just one possibility when using this model. I find the term confusing, myself, as other binding models are used to ‘directly’ bind orchestration ports to messaging Send ports. Binding models are really differentiated by the following characteristics:
• support for external binding configuration
• use of static and dynamic messaging Send ports. NB., Receive ports do not support a dynamic model.
• auto-generation of configured messaging ports at deployment time
The four models are:
• ‘Direct’ binding
In this model, orchestration ports do not automatically use or exploit BTS.SPID, BTS.ReceivePortID or other related properties. BizTalk therefore does not manage the binding of orchestration ports to messaging Receive and Send ports. Instead, it is entirely up to developers to control subscriptions and message context in order to route messages.
Developers are free, if they wish, to route messages to other orchestration ports. External binding configuration cannot be used with directly bound orchestration ports. Direct binding is the most flexible model, but at a cost. You cannot configure your orchestration ports using binding files, and you generally need to do more programming in order to fully exploit the flexibility on offer.
• ‘Specify later’ binding
In this model, orchestration ports are bound to messaging ports using BTS.SPID, BTS.ReceivePortID or other related properties. Outgoing messages are always routed through
static Send ports. Binding configuration can be managed in deployed solutions using binding files or by writing WMI/ExplorerOM code. This is probably the most common model, but is significantly less flexible than direct binding. You have much less control over subscription and ‘promoted’ properties, and can only use this approach to bind orchestration ports to messaging ports.
• ‘Specify now’ binding
This model is similar to the ‘Specify later’ model. However, BizTalk collects transport information at design time, together with pipeline information, and uses this to auto-generate messaging Receive and static Send ports at deployment time. Orchestration ports are then bound to these ports. Binding files can be used, if required, to amend binding configuration on a live system.
• ‘Dynamic’ binding
This model has similarities to the ‘Specify now’ model in that BizTalk collects pipeline information at design time and auto-generates messaging Send ports. Receive ports are not generated, as there is no concept of a ‘dynamic’ Receive port. However, transport information is not configured in the same way. Instead, developers create expressions in orchestrations to assign transport location URIs using the ‘address’ property of orchestration ports. The auto-generated messaging Send ports are dynamic, rather than static.
Messages passing from an orchestration through dynamic Send and Send-Receive ports are routed solely on the basis of the orchestration port’s address property which is used to create BTS.OutboundTransportType and BTS.OutboundTransportLocation ‘promoted’ context properties. When a dynamic messaging Send port is enlisted, it creates a set of subscriptions, with one subscription for each adapter. Each subscription tests that the BTS.OutboundTransportLocation property exists, and that the BTS.OutboundTransportType property contains a value identifying the adapter. Hence, not only can dynamic binding route messages to any location based on the address, but also via any registered adapter.
13. What is the difference between static, dynamic and direct binding?
Static binding specifies particular port address,
Dynamic gives address of the port at runtime,
Direct binding sends messages to messagebox.
14. What are different Transaction types in BizTalk Server?
The classical definition of a transaction is – an atomic unit of work which results in moving the system from one consistent state to a new consistent and durable state. A transaction can either be “committed” or “rolled back” depending on various conditions. Note that a transaction which cannot be rolled back needs to be “compensated”. This means that if an operation ‘f(x)’ has been performed on some data, in order to revert it back we need to perform an operation ‘f(y)’, which essentially performs an undo operation, this is known as “compensation” in simple terms.
A non-transactional orchestration cannot have ‘scope’ shapes set to either “Atomic” or “Long Running”.
If an orchestration’s transaction type is set to “Atomic”, then the orchestration cannot have any other transactions within its ‘scope’ shapes.
Atomic transactions cannot contain nested transactions or catch exception blocks. However, they can have compensation blocks.
Long running transactions cannot be isolated from other transactions. However they can contain other atomic transactions and can have catch exception and compensation blocks.
Batch: A boolean value that determines if this transaction can be batched with other transactions across multiple instances of the orchestration. The default value is “true”. It may
improve performance with the possibility of losing isolation data.
Isolation level: This property defines the degree of isolation between the state changes performed by different atomic transactions. This is not applicable for Long-Running transactions. BizTalk supports three isolation levels. These are ‘Read Committed’, ‘Repeatable Read’ and ‘Serializable’. The last one being the default value.
Retry: A boolean value which specifies that the atomic transaction can be retried in the event of a failure. Perform the following for Retry-”throw an instance of Microsoft.XLANGs.BaseTypes.RetryTransactionException” within the transaction boundary.
15. What is atomic Transaction?
It follows full ACID properties Atomicity, Consistency, Isolation and Durability. If you require full ACID properties on the data—for example, when the data must be isolated from other transactions—you must use atomic transactions exclusively.
When an atomic transaction fails, all states are reset as if the orchestration instance never entered the scope.
16. What is long running transaction?
Long running transaction support CD properties of ACID. It is not practical to lock transaction for a long time. This transaction can run indefinitely and can be dehydrated also.
17 .Does BizTalk support synchronous communication?
BizTalk Server architecture is asynchronous for scalability reasons. However, the architecture of the BizTalk Messaging Engine enables exposing a synchronous message exchange pattern on top of these asynchronous exchanges. To do this, the engine handles the complex task of correlating the request and response messages across a scaled-out architecture by linking together a number of asynchronous message exchanges to expose a synchronous interface.
18. What is meant by Virtual Directory? Why do we use?
I assume that we are talking about publishing schemas or orchestration as web service or WCF service. The publishing wizard publishes service at IIS (isolated host) in the virtual directory (the directory at which schema reference is given and config file for this). this is also called as service end point where we receive messages.
19. What is correlation?
An Orchestration can have more than one instance running simultaneously. Even though each of those multiple instances perform the same action, it does it on different data contained within a message. Correlation is a process of associating an incoming message with the appropriate instance of an orchestration. For Example: If your orchestration issues a purchase order, receives an invoice, and sends a payment, the developer must make certain that the invoice message is received by the orchestration instance which corresponds to the orchestration that sent the Purchase Order. Without correlation, it would be possible to send out an invoice for thousands of items even though the purchase order is for one.
20. What is Dehydration?
When an orchestration has been idle for a while, the orchestration engine will save the state information of the instance and free up memory resources.
21. What is Rehydration?
When a message is received, or else when a timeout has expired, the orchestration engine can be automatically triggered to rehydrate the instance – it is at this point that the orchestration engine loads the saved instance of the orchestration into memory, restores the state, and runs its from the point it left off.
22. What are the execution modes in a pipeline Stage?
A stage in a pipeline has an execution mode of either “All” or “First Match”, which controls the components that get executed if more than one component is added to a stage.
For stages with a mode of “All”, each component is called to process the message in the order in which they are configured in the stage.
For stages with a mode of “First Match”, each component is polled to indicate that it is the right component until a match is found, at which point the component that matches is executed, while the remaining components do not get executed.
23. Which Interfaces do you need to implement in a disassembling custom pipeline component?
A disassembling pipeline component receives one message on input and produces zero or more messages on output. Disassembling components are used to split interchanges of messages into individual documents. Disassembler components must implement the following interfaces:
24. What is a link in a Map?
A link specifies the basic function of copying data from an element or attribute in an input instance message to an element or attribute in an output instance. You create links between records and fields in the source and destination schemas at design time. This drives the creation, at run time, of an output instance message conforming to the destination schema from an input instance message conforming to the source schema.
25. How to route binary data?
To route binary data you can use pass-through pipelines on the receive location and send port. BizTalk will route (copy) the data from the source (receive location) to the destination (send port). If you want to route the binary data based on some information in the binary data then you write a custom Disassembler to promote the properties you need from the incoming message to route the binary data.
26. How do you call a Non-Serializable .Net helper class inside an Expression Shape?
• Add a reference to that class.
• Make sure your Orchestration is Long Running transactional.
• Add an Atomic scope.
• Create an Orchestration variable of that class inside the scope.
• Create an instance on that object inside the scope.
• Call the method.
• Bonus: Mention the class must be strongly signed and in the GAC.
27. How do you achieve First-In-First-Out message processing of messages received from multiple sources using an Orchestration?
• Use a Sequential Convoy to process the messages in the order they are received into the Message Box.
• Make sure Ordered Delivery is set to True inside the Orchestration Receive Port.
28. When working with Schemas, Maps, Pipelines, and Orchestrations, how should the projects be structured?
• Schemas and Maps in its own project
• Or Schemas and Maps together in its own project
• Orchestrations in its own project
• Pipelines in it own project
29. What are Persistence Points and what causes them?
• Persistence is when the state of a running Orchestration is stored into SQL.
• It is good enough to know various shape and actions cause persistence. More specifically, it occurs: end of a transactional scope, at a send shape, at a start Orchestration shape, during dehydration, if the system shuts down expectedly or unexpectedly, or the business process suspends or ends.
30. What group does a user need to belong to in order to submit messages to the message box?
The user needs to be a member of the hot group or isolated host group (assuming a default installation).
31. What user rights do you need to perform most actions in HAT?
BizTalk Server Administrator
32. When installing Biztalk in a multi-server configuration with a remote SQL and Analysis Services, what SQL components do you need on the Biztalk Server?
SQL Analysis Services Client Tools
33. When installing Biztalk and SQL on a Windows XP SP2 Desktop, what pre-requests are required?
I always referrer to the most current updated installation guide from Microsoft.
34. Can an Envelope schema consist of more than one schema type?
Yes. Technically it is possible.
35. Can a flat file message be processed without a pipeline?
A Pipeline’s job is to convert any external format into XML, be it a flat file or EDI or anything else.
36. Can multiple messages be processed or batched without an envelope schema?
It is possible to process multiple messages, without an envelope.
37. What is property promotion, why is it required?
When a property is Promoted, it is exposed to the orchestration/send port filters etc.
38. In which scenarios would use a “promoted property” vs “distinguished fields”?
The rule here is, if you dont want the schema element to appear in send port filters/debugging information then make it a distinguished field.
39. What are un-typed messages, how does one create them?
A message created in BizTalk Orchestration is bound to a schema, this is a typed message. In un-typed messages, the message is bound to System.Xml.XmlDocument instead of a schema.
40. How does one enable subscriptions in BizTalk?
A filter on the Send Port is the first step to enable subscriptions in BizTalk.
41. What is the difference between a delay shape vs a listen shape?
A ‘Delay’ is very much similar to a sleep on the current thread. A ‘Listen’ shape is used to wait for an incoming resource, with a timeout period.
42. When you use Call Orchestration shape vs Start Orchestration shape?
A Call Orchestration returns the control back to the caller. A Start Ochestration shape starts the orchestration in a non-deterministic way.
43. What is the difference between a “Message Assignment” shape and an “Expression” shape?
A “Message Assignment” shape is used to create a new message and assign values to it. A Expression shape is used to assign values to variables and also write ‘if’ conditions.
44. Does BizTalk Orchestrations support recursion?
An Orchestration does NOT support recursion.
45. What is the purpose of the property “Activate” in a Receive shape?
It is used to invoke a new instance of an Orchestration.
46. Can an orchestration Start without an Activatable receive?
A Nested Orchestration can be started without an Activatable receive
47. Is it necessary for all .NET components being called from an Orchestration be Serializable?
Yes it is necessary. There are cases where a .NET component need not be Serializable.
48. When do we need set the property “Synchronized” = true for a scope?
This needs to be set, when a variable is shared across the branches of a parallel shape.
49. How does one enable Correlations in BizTalk?
First create a Correlation type and then create an instance of it.
50. In an Orchestration design, Orchestration “A” calls another Orchestration “B”, and vice versa. Is it possible to implement this design?
It is NOT possible, since it forms a cyclic dependency.
51. List out the three important things to consider while designing a BizTalk orchestration!
The Incoming data format, The Business process and The Outgoing data format.
52. What are Host and Host Instance? Did you deploy BizTalk more than one machine?
Host is nothing but the logical container of host instance. from which we can create host instance. Host instance is a Win-NT service.
A BizTalk Server Host is a logical set of zero or more BizTalk Server run-time processes in which you deploy items such as adapter handlers, receive locations (including pipelines), and orchestrations.
A host instance is the process where the message processing, receiving, and transmitting occurs You install a host instance on each server running BizTalk Server 2006 that has one
or more hosts mapped to that server.
53. What is Message routing and Content routing?
When A message is passed through biztalk without being processed then it is called Message Routing. When A message is passed based on certain field value of schema, it is called content routing.
54. What are the security groups created by BizTalk?
SSO Affiliate Administrators
BizTalk Server Administrators
BizTalk Server Operators
BizTalk Application Users
BizTalk Isolated Host Users
55. What is the difference between Windows Workflow and BizTalk server? Explain the scenarios.
I want to put a definition around BizTalk to make it easier to compare to Windows Workflow. BizTalk Server is an enterprise level workflow and message processing environment. This environment is tried and tested (extremely rigorously over the last many years). BizTalk also includes many adapters to connect to a variety of back end system. Out of the box, BizTalk provides scalability, manageability, tracking, logging & administration tools.
Windows Workflow is an SDK for creating workflow based applications. The tools are there to build a host and to render a graphical workflow environment. Scalability is possible with Windows Workflow but it is up to the developer to create a truly scalable solution. In addition, there are administrative functions through runtime and tracking visibility but there is not an out of the box administration tool as this is also up to the host developer to create.
The message that I tell people is to use BizTalk when you want to target users/clients that want to span multiple applications whereas Windows Workflow would be used when you want to target users/clients that want workflow within an application.
So, to summarize, Windows Workflow is great for workflow within an application whereas BizTalk is great for workflow across applications.
56. Why do we need convoy?
When a group of correlated messages could potentially be received at the same time, a race condition could occur in which a correlation set in a particular orchestration instance must be initialized by one of the messages before the other messages can be correlated to that orchestration instance. To ensure that all of the correlated messages will be received by the same orchestration instance, BizTalk detects the potential for such a race condition and treats these messages as a convoy.
Convoy is a term which we use to describe a class of application protocols, specifically it is a set of application protocols which have a race condition as described above. Let’s take an example. Say you are a hospital and want to have a service which handles all information about each patient. For a given patient you have three types of messages, an admittance message, status messages, and a discharge message. If you look at your protocol, you will have built a service which just receives. Now let’s think about what could happen. Let’s say you send the patient admittance message and it goes through the system using maybe a synchronous protocol like HTTP. That means when you get the 202 back, you know the message has been delivered. But what if the BizTalkServer host which is actually supposed to process the message hasn’t started yet (ie the nt service is stopped). Maybe you had a power outage, maybe some intern decided to “hit this button”, who knows. So the orchestration instance which is supposed to handle all messages for patient X has not physically started. The message is in the database (MessageBox) and if you look in HAT you will see the orchestration is marked as ready to run, but it can’t start cause there is no where for it to start.
57. What are the challenges you have faced using Soap Adapter?
Twenty minutes timeout issue. You have to host webservices in the same machine. There is a way I heard but I didn’t do much reading on it.
58. Where and how did you use WebServices in Orchestration?
We can use webservices where we need to get data from multiple sources in one go. For e.g. getting price quote from 10 different vendors. You make one orchestration and use WS inside it.
59. What are the draw-backs of BizTalk?
Not a very good support with legacy system. Like we faced tons of issue which we had to solve it someway or the other but Microsoft could not come up with a very good answer.
60.What has been your most difficult challenge in implementing Biztalk applications in the real world?
I think with biztalk things were not THAT challenging but with legacy systems things were. Like calling a webservice from oracle, or getting a LARGE object from orchestration into a oracle. And things like that.