Biztalk Helper Class Interview Questions And Answers

.NET (helper) classes can be used inside an orchestration.

Yes. Right click the project, go to properties and select Build Events
And add following in the Post-Build event command line:

"C:Program filesMicrosoft Visual Studio 8SDKv2.0BinGacUtil.exe" -u $(TargetName)

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.

Static binding specifies port address,

Dynamic gives address of the port at runtime,

Direct binding sends messages to messagebox.

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.

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.

A .net helper class with the context of BizTalk is a class (library) that can support an orchestration with extra functionality. It can enhance an orchestration in tracing, error handling, caching, and serialization/deserialization

Below are the steps:
☛ Add Reference
☛ Make Orchestration as Long running
☛ Add Atomic Scope
☛ Add Expression shape
☛ Orchestration variable of class inside scope
☛ Instance of object inside the scope
☛ Call method

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.

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.

Yes, it can used in orchestration but in an atomic scope only.

Because resources are meant to hold only BizTalk resources.

When creating an assembly that will be used by BizTalk, it is appropriate to mark all classes as serializable. Since BizTalk is stateless and makes use of persistence points, which details are stored in BizTalk SQL Server databases by serializing all the data. Therefore non-serializable Classes or Types cannot be used directly in Orchestrations.

Yes it is possible, in this case the variable will need to be instantiated in an Expression shape through the new keyword.

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.

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 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.

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.

No, it is added to GAC on the machine where it is used.

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.

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.

With the use of gacutil.exe and following command:

gacutil /i assemblypath

"Copy Local" property indicates whether the assembly referenced should be copied into the local bin directory when a project is built.

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.

The Global Assembly Cache tool allows you to view and manipulate the contents of the global assembly cache and download cache.

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.