Biztalk interview questions 2004/2006/2010 Part :4 (Differences in biztalk terminology)

1. How many type of transaction BizTalk supports.
2. Difference between Atomic and Long Running transaction.

BizTalk orchestration provides a transactional programming model that includes support for exception handling and recovery from failed transactions.

You can define two types of transactions when creating an orchestration:

• Atomic transaction. Enables a transaction to automatically role back to a previous state in case the transaction does not successfully complete.
• Long running transaction. Can span days, weeks, and longer time durations, contain nested transactions, and use custom exception handling to recover from error scenarios.

As a result, orchestrations provide you the flexibility to define the course of action in the event of a business process failure.

2. Difference between Dehydration and Rehydration in Orchestration.

When many business processes run at the same time, memory and performance can be compromised. The BizTalk Orchestration Engine solves this problem by dehydrating and rehydrating orchestration instances. Dehydration is the process of saving the state of an active orchestration instance to the MessageBox database and then removing that instance from memory. This can happen when the orchestration engine determines that an instance has been idle for a period of time. Dehydrating the instance frees up the resources that were being used by the instance.

Dehydration

The orchestration engine calculates thresholds to determine how long an orchestration will wait for various actions to take place, and if those thresholds are exceeded, it dehydrates the instance. This can occur under the following circumstances:

• When the orchestration is waiting to receive a message and the wait is longer than a threshold determined by the engine.
• When the orchestration is waiting for a subscribed message.
• When a delay in the orchestration is longer than a threshold determined by the engine.
• Between the retries of an atomic transaction.

The orchestration engine saves the entire state of a running orchestration instance to persistent storage at various points so that the instance can later be completely restored in memory. The dehydration of orchestration instances enables the orchestration engine to have more "in-flight" instances than the physical resources of the computer running BizTalk Server would normally allow. Dehydration is automatically controlled by the orchestration engine; however, you can control the dehydration threshold by changing specific BizTalk Server configuration properties.

Rehydration

Rehydration is the reverse of dehydration. It is the process of de-serializing the last running state of an orchestration from the database or restoring the saved state of an orchestration instance from disk back to memory. The orchestration engine is triggered to rehydrate an orchestration instance when it either receives a message or when a time-out expires. It then loads the saved orchestration instance into memory, restores its state, and runs it from the point where it left off.

An orchestration can be configured to run on more than one server. After an orchestration instance has been dehydrated, it can be rehydrated on any of these servers. If one server goes down, the engine continues to run the orchestration on a different server, continuing from its previous state. The engine also takes advantage of this feature to implement load balancing across servers.

3. 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. An Expression shape is used to assign values to variables and also write 'if' conditions.

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

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

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

7.Difference between Distinguished Fields and Promoting Properties 

·         Distinguished fields are available only within a single orchestration instance, and they are not available to other BizTalk Server objects, such as receive locations, send ports, send port groups, and tracking utilities.

 

·         Distinguished fields can be of any length; 

      promoted properties have a maximum length of 255 characters.

·         Distinguished fields have less of a performance impact than promoted properties, as they are not persisted to the MessageBox database. Instead, they are essentially XPath aliases, which simply point to the appropriate XML data field. Additionally, adding the DistinguishedField attribute to a field on a .NET class allows it to be exposed as a distinguished field.

·         Distinguished fields are accessed through a reference to the name of the message, the name of the record structure containing the distinguished field (which could include multiple levels of child records), and the name of the distinguished field, with each named item separated by periods: MessageName.RecordName.ChildRecordName.DistinguishedFieldName. 

 

      Promoted properties, on the other hand, are accessed through a reference to the name of the message, the name of the property schema, and a name of the promoted property, via the following format:

MessageName(PropertySchemaName.PromotedPropertyName).