BizTalk Bizzare

BizTalk Bizarre………………………………….by Vikash Kumar…………………….

1. Active property made true invokes a new instance of an orchestration. Only a nested Orchestration can be started without an active receive. BizTalk Server has no built in mechanism for controlling the number of instances of a given orchestration. If we have to control the number of instances of Orch A then we have to create some rule or Orch which will allow/restrict it to activate one more instance.

2. Static Global variables can be stored in Configuration files or SQL tables in order to share them across all the instances of the Orchestration.

3. Zombie is a message which is discarded when the instance of the Orchestration ends with “Completed with Discarded Message”. It typically occurs when an extra message is routed after control flow in the executing orchestration has passed the receive shape with the matching subscription or due to a time out on a LR transaction or a time out of a delay branch on a listen shape or in a loop that consists a receive shape that exits before consuming all the routed messages.

4. “Delivered Not Consumed” this is the status of the message when it is in the BTS internal work queue. It might be in this state because the engine is busy with other messages or because the destination is processing more slow than expected.

5. Curious case of Serialization in orchestration:
The XLANG compiler requires all its variables in an orchestration to be serializable since when the orchestration dehydrates and rehydrates then it serializes and deserializes those variables.
A non serializable object can only be declared and used in an atomic scope.
An interface cannot be marked as a serializable because we are never sure about their implementation. So Non Serializable objects must run inside atomic scopes.

6. For an Atomic Scope, if Retry is set to true only two exceptions “Persistence Exception” and “RetryTransactionExcepion” will make the atomic transaction retry work.

7. Orchestration supports parallel activation only in following conditions:
a. If one of the tasks of a parallel activation has an active Receive as the first shape, all of the tasks of that parallel activation must have an active Receive as the first shape, and all of those Receive shapes must initialize at least one correlation.
b. If a particular correlation is initialized on more than one task of a parallel activation by a Receive shape, each of the concerned activating Receive shapes must initialize exactly the same correlation.

8. Difference between Start Orchestration and Call Orchestration:
a. Call Orchestration is a synchronous call and it returns the control back to the caller.
b. Start orchestration is an Asynchronous call and hence it starts the orchestration in a non deterministic way. In this case some time what we expect that the new orchestration will start in time to create the necessary subscriptions to receive the messages that will be sent to it but quite often it doesn’t happen so. In this case it gives” could not find subscription error".

9. Persistence points in Orchestration:
The orchestration engine saves the entire state of an orchestration instance at various persistence points to allow rehydration of the orchestration instance. The engine stores state at the following persistence points:
• End of a transactional scope (atomic or long running)
• At debugging breakpoints
• At the execution of other orchestrations through the Start Orchestration shape
• At the Send shape (except in an atomic transaction)
• When an Orchestration Instance is suspended
• When the system shutdowns in a controlled manner
• When the engine determines it wants to dehydrate
• When an orchestration instance is finished

10. BizTalk Server upgrade: BizTalk 2004 and BizTalk 2006 cannot reside on the same machine and so as SQL Server 2000 and 2005. So while upgrading BTS2004 to 2006 database also needs to upgraded from 2000 to 2005.
Note: Within a single group in case of multiple BizTalk servers if one server is upgrade then all the servers need to be upgraded because interoperability between BTS2004 and BTS 2006 is not supported due because of DB changes.

11. Business Rule Engine:
a. Rule: A single executable statement which is made up of a condition and an action.
b. Policies: Logical group of rules.
c. Vocabulary: Friendly name given to a field.
How does rule engine works:
Business Rule Composer is used for developing business policies, vocabulary definitions, publish the policies. Inside the BRC when we want to test the policy for a .Net component we need to create a Fact creator wrapper around the .Net Component implementing the interface IFactCreator. Create Facts is the method called by the rule engine. Rule engine deployment wizard deploy/export/import the policies and vocabularies. Rule engine evaluates the condition based on fact. When a policy is executed, the facts are brought into memory. After execution all the facts submitted to the rule engine are retracted from the working memory of the rule engine.
Important: When we test a policy that uses database facts with the DataConnection binding in the Business Rule Composer, a DataConnection object is automatically built. However, when we call the same policy from an orchestration by using the Call Rules shape, no DataConnection object is passed to the policy automatically. We should create a DataConnection object in the orchestration and pass it as a parameter or create a fact retriever component that asserts the DataConnection object, and configure the policy to use the fact retriever component.
How to call Rules from:
a. Orchestration: We can call rules from orchestration using Call Rule shape. Also we can use .Net API inside the expression shape to call the policies.
i. Create the object of the samplepolicy we created in BRC.
Policy = new Microsoft.RuleEngine.Policy(“SamplePolicy”,1,0);

ii. Create the input parameter for the policy
typedXmlDoc = new MS.RE.TypedXmlDocument(“inputXML”,inmputmessgae);
iii. Execute the policy and then dispose.
Policy.Execute(typedXmlDoc);
Policy.dispose();

b. C# code:
Same as above. Only difference is that we need to create the facts object array to hold the input params for the policy as objects[] facts = new object[1];
Facts[0] = typedXmlDoc;
Policy.Execute(facts);

Advanced Concepts:
a. Forward chaining: One rule invokes the other rule.
b. Short term vs. long term fact:
i. Short-term facts are facts loaded into memory by rule engine and are available for only one execution cycle of the rule engine, after the execution facts are retracted back from memory. Long term facts are available for multiple execution cycles of rule engine.
ii. Short term facts are passed to rule engine as array of objects, whereas long term facts are passed as typed Data Table which has typed Data Rows to rule engine.

12. Transactions in Orchestration:
a. Atomic Transaction: Either completely successful or completely rollbacked.
i. Cannot contain nested Atomic transaction or LR transaction or a exception handler however can contain a compensation block.
ii. We cannot construct an atomic transaction with a request response pair of actions, nor we can have send and receive shape that uses the same correlation set.
iii. When a message is received in an atomic transaction, it is delivered to the orchestration but not removed from the message box until the transaction commits.
b. LR Transaction: A transaction which executes for several hours, days or even weeks and contains several atomic transactions. These smaller atomic transactions which are completed/committed, cannot be rolled back and hence need to be compensated.
COMPENSATION: Undo operation
Exception block does not roll back the transaction but just throws the error.

13. When many long-running business processes are running at the same time, memory and performance are potential issues. The orchestration engine addresses these issues by "dehydrating" and "rehydrating" orchestration instances.
Dehydration is the process of serializing the state of an orchestration into a SQL Server database. Rehydration is the reverse of this process: deserializing the last running state of an orchestration from the database. Dehydration is used to minimize the use of system resources by reducing the number of orchestrations that have to be instantiated in memory at one time.

14. Correlation is used to map a message to its corresponding Orchestration instance A correlation set is a collection of promoted message property values that we use to route an incoming message to an executing instance. The message is evaluated for the message type and every property in the set in order to correctly route it to the instance. Correlation is achieved with the help of "Initialize Correlation Set" and "Follow up Correlation Set" properties in the Send and Receive shapes.

15. Deployment: After build phase of the BizTalk project when we need to migrate the work from our work environment to test environment first we need to export the .msi files. Remenber that configuration values what we have made in BTSNTSvc.exe.config file are not exported. Patches(only added\modified file) can also be exported. Export bindings and plocies.
After exporting import the .msi and binding files in the test environment.

16. Binding Model in BizTalk:
a. Direct Binding(Most Flexible): In this Model, orchestration ports do not automatically use BTS.SPID or BTS.RecievePortId. Rather filter expressions or self correlating or message context property can be used. Can be used to send message to other orchestration. Drawback is that we cannot configure our orchestration port using binding files. We need to do more programming in order to fully exploit the flexibility.
b. Specify later: Less flexible but most common. BTS.SPID, BTS.RecieverId
c. Specify now: BizTalk collects transport and pipeline info at design time.
d. Dynamic Binding: In expressions we have to give URLs that can be picked from config file.

17. Delivery Notification in BizTalk: If an Orchestration port is marked with Delivery Notification = Transmitted, and the Send shape in the Orchestration is in a synchronized scope, the Orchestration will wait until it either receives an ACK or a NACK for the message that was transmitted. In the case that the message was successfully transmitted, the engine will publish an ACK ensuring that it is routed back to that Orchestration instance, once the Orchestration receives the ACK it will leave the scope and continue processing. If however the transmission failed and the message was suspended, the engine will publish a NACK which again will be routed back to the Orchestration instance, the Orchestration will throw a DeliveryFailureException which can of course be caught and handled as appropriate in the Orchestration.

18. Dynamic Mapping: Dynamic mapping is the concept of specifying the map to be used for a transform at runtime inside the orchestration. That means no Transform Shape is used to specify the map or input and output schemas.
Example: We are receiving a standard invoice from multiple locations for the same vendor. The schema is exactly the same but the mapping of the vendor data to the base schema (date formats, currency conversion, etc.) is slightly different based on the vendor location.

Why not map on the Receive Port? This is the most common solution to this type of scenario. This uses document normalization to transform all your messages into the same type before it hits our business process. This is a great solution but what about exceptions?

Exceptions in maps on the Receive Port can be hard to react to and even harder to orchestrate a retry or recovery process. That is when mapping inside an Orchestration and Dynamic Maps come into play.

With dynamic maps, the map name can be stored inside an attribute in the message, read from the SSO, or read from some other custom component. Then, it is as simple as creating a System.Type with the strong fully qualified map name.

This would look something like this:

Suppose SubscriberInformation is the node in input xml which contains the recipients info then we will take it in a variable.
SubscriberInformation = Generic_In(DynamicMaps.PropertySchema.SubscriberInfo );
then we will take the maptype in another variable of System.Type like this
tMap = System.Type.GetType("DynamicMaps.Map_ABC,DynamicMaps, Version=1.0.0.0, Culture=neutral,PublicKeyToken=f85be9e4dd36fb1d");

then in a message assignment shape we can construct the out message as follows:
transform (Message_Out) = tMap(Generic_In);

Alternatively we can do it in an expression shape using the construct keyword as below:
construct Message_Out
{
transform (Message_Out) = tMap(Generic_In);
}



19. BizTalk Server can accommodate two or more schema with the same root node as long as the schemas have unique namespace designations.
20. Message context includes all the instance specific and exchange specific data fields, and essentially is the metadata that the messaging engine of BizTalk Server uses to process messages. While duplicating a message it should be noted that Only MessageDataPropertyBase gets copied not the MessageContextProperty Base. So to copy the message context property of message 2 into the message context of message 1
Message1(*) = Message2(*);

21. Distinguish fields are used opposed to promoted fields to enhance the performance.
a) Distinguish fields are available only within a single orchestration and they are not available to other BizTalk Server objects such as receive locations, send ports, send port groups and tracking utilities.
b) Distinguish fields can be of any length; promoted properties have a maximum length of 255 characters.
c) Distinguished fields have less of a performance impact than promoted properties as they are not persisted to the Message Box database. Instead they are XPath aliases which simply point to the appropriate XML data field.
d) Distinguish fields are accessed in following fashion: MessageName.RecordName.Childname while Promoted fields are accessed in this way MessageName(PropertySchemaName.PromotedPropertyName)
22. To hide promoted properties from the tools like HAT and BAM, set the promoted property’s Sensitive Information property to True.

23. It is also possible to create message context properties that do not exist in the message by just adding a node to the property schema and setting its Property Schema base property to MessageContextProperty Base.

24. To process a message that contains multiple records in a batch fashion we need to create envelopes. Nesting of Envelopes is also possible to ensure a flexible way of transferring message batches that have complex structure or relationship.
a. Set Envelop property to YES.
b. Body Xpath property need to be set.

25. We can put validation on the input data as in the case of phone numbers, ip address as they should come in a specific format. So we can define formats for them by setting Derived By property to Restriction and specifying the required pattern for that particular field.