HOME

BOOKS

TECHNICAL ARTICLES

WHITE PAPERS

WHITE PAPERS (ACCL.)

E-LEARNING

VIRTUAL LABS

WEBCASTS

MSDN TV EPISODES

VIDEOS

BLOGS

LATEST DOCUMENTATION

CERTIFICATION

SAMPLES, TUTORIALS

COMMON TASKS

USEFUL TOOLS

PROD INFO, TRIAL SOFTWARE

SERVICE PACKS

USER GROUPS

NEWS GROUPS

WIKI

MVP'S

MAGAZINE

Contact US

|

BizTalk Server 2006 Exam (70-235) Preparation Diary

There are different opinions about writing exams. There will always be one set of people complaining, the exams are too theoretical and they normally don’t reflect real world experience. But I'll say that's just an excuse. I'll agree to large extend most of the time the exams are very theoretical, but preparing for the exam gives you an opportunity to read the breadth of the product. In most of the real world cases, you'll be purely focusing on one or two key aspects of the product. Being a BizTalk person myself for the past 5+ years, most of my day job work was revolving around messaging and occasionally few Orchestrations. I never had any chance to use BRE, BAM, BAS, Trading Partner management (Role Links) etc in my real world projects. Preparing for the exam at least gave me some insight on what they are doing, and how they fit together. BAM is a classic example, after preparing for the exam, now I got some ideas in my mind, which I can implement in some of our projects.

This diary is my real experience preparing for the exam MCTS BizTalk 2006. I did the exam on the 11th day and scored 871/1000. I'm happy with the result, I lost some marks in BRE and BAM, and I can say that's because of lack of real experience. The general tip I can give is spend reasonable time to read the questions and all the answers properly. Don't just jump into an answer directly after reading half way through the question.

I hope this material will be helpful for people preparing for the exam MCTS BizTalk 2006. Any one who wants to brush up all their BizTalk memories for an interview. or in general a quick reference point.

Now, preparing for the exam: Once you have decided to take the exam, first thing to do is go and book the exam, decide on the date based on your experience. For someone with 2-3 year BizTalk server experience ideal time will be 10 days assuming you can spend 3-4 hours each day. I've documented my notes for the exam here as a 10 day program.

Disclaimer / Credits: The content of this article is collected from various places like MSDN, many BizTalk Books, lots of Blogs, Web Casts and Product documentation. I tried to put references wherever possible, if in case references are missing please contact me via the "Contact US" link, and let me know.

---

Day 1:

I started my preparation by taking the free Self assessment exam by Microsoft, which gives you 30 random questions from BizTalk Server 2006 to find out where I'm standing without any preparation. At end of the exam it just gives you the score percentage and gives some suggestions for reading (sadly you won't be able to see the answers). In my first attempt I scored 71% (21 out of 30).

What's New in BizTalk Server 2006?

Reference: What's New in BizTalk Server 2006?
Reference: BizTalk Server 2006 Runtime Improvements
Reference: BizTalk Server 2006 Developer Tools Improvements
Reference: BizTalk Server 2006 Setup and Migration

To recollect all the new stuff in BizTalk 2006, I started with this article what's New in BizTalk Server 2006? Following is the short summary of things from the article:

Setup and Migration

• Automatic installation of redistributable components,
• Simplified setup experience for first-time users,
• Flexible setup experience for advanced users,
• Seamless upgrade experience.

Management, Operations and Deployment

• Application concept and Application packaging
• Powerful administration console,
• Server health monitoring: Using the BizTalk Administration Console's Group Hub page.

Business Activity Monitoring

• Enhanced BAM Portal
• BAM Alerts through integration with SQL Server Notification Service
• BAM Web Service: Can be used by custom applications to expose BAM functionalities within their user interface.

Developer Tools Enhancement

• Flat file wizard,
• Orchestration Zooming,
• POP3 Adapter: Allows both sending and receiving message with attachments from any POP3 compliant mail server,
• WSS adapter,
• MQ Series adapter.

BizTalk Messaging Engine enhancements (Reference BizTalk Server 2006 Runtime Improvements)

• Recoverable interchange:
• Failed message routing: When a new receive port is created, a property can be set called "Generate error report for failed message". When this property is checked, failed messages will not be suspended. Instead, they will be sent to the message box, and the following additional properties will be set:
  • ErrorReport.ErrorType
  • ErrorReport.FailureCode
  • ErrorReport.MessageType
  • ReceivePortName
  • SendPortName
  • InboundTransportLocation
  • OutboundTransportLocation
  By taking advantage of these additional context properties you can now create end-point filters, on an orchestration or sent port, that subscribe to these failed messages.
• Message resume: Receive side message resume: Nearly all receive-side messages (new in 2006, in 2004 only send side resume was possible) can be resumed. In the case of messages that require in-order delivery (that is, MSMQ, MQSeries, and so on) message resume may not be possible, as the order integrity needs to be preserved. Additionally the tools for resuming messages have changed. Message monitoring is no longer a function of HAT, though message tracking remains in HAT. Instead, the new BizTalk Administration Console contains new "hub" pages that give an administrator visibility into messaging active within BizTalk.
• In-order message delivery:
• Large message transformation: When message size is smaller than a specified threshold the in-memory transformation will be used. If message size exceeds the threshold then the large message transformation engine is used. The threshold is configurable using the registry
  • DWORD 'TransformThreshold'
  • 'HKLM\\Software\\Microsoft\\BizTalk Server\\3.0\\Administration'.
  (By default it is set to 1 megabyte (MB))

Setup and Migration

Reference: BizTalk Server 2006 Setup and Migration

Following is the highlights from the document.

• Pre-requisite: Windows, VS 2005, SQL 2000/2005.
• Redistributable Components required: SQLXML 3.0, MSXML 3.0, MDAC 2.8 and OWC11
• CAB file contains all the required redistributable components. Can be downloaded online or can be pointed to previously downloaded CAB file.
• Developer and First-Time User Experience: Single database server name and Username/Password for all BizTalk services.
• Advanced installation allow import/export configuration.

BizTalk Server Upgrade: There is no supported side-by-side installation of BizTalk Server 2004, and as such, the computer will be upgraded to BizTalk Server 2006. Additionally, the upgrade process is not reversible without recovering from your computer and database backup. Customers wanting to upgrade their databases from SQL Server 2000 to SQL Server 2005 should complete the database upgrade after they have successfully upgraded BizTalk Server 2004 to BizTalk Server 2006. Also note that all BizTalk Servers within a single group should be upgraded to BizTalk Server 2006. Interoperability between BizTalk Server 2004 and BizTalk Server 2006 is not supported because of database changes.

Silent Installation Parameters: From my BizTalk 2004 exam experience I remember getting questions from installation parameters, so here is the full list:

Day 1 Summary: 25 minutes for the assessment exam, 1 hour for what's new and some other related papers like runtime improvements, 2 hours for Installation/Setup

---

Day 2:

Transformation using MAPS

Reference: There are tons of resources available for maps, I took the notes from BizTalk Server Unleashed, BizTalk 2006 Recipes, and
Reference: BizTalk 2006 Code samples: http://msdn2.microsoft.com/en-us/biztalk/aa937647.aspx

BizTalk server mapping is another area where you don't use all the available functoid in your day to day job. Most of my map implementations are quite straight forward, rarely used advanced functoids like "Value Mapping" and "Scripting". So, I decided to spend the whole Saturday for doing some samples and tutorials to understand all the available functoids at least conceptually. Following is the quick reference for most of the functoids available in BizTalk Server 2006:

Organizing Maps:

BizTalk server provides two main features to aid in the readability and maintainability of maps.

1. Grid Pages: You can segment groups of links onto different grid pages.
2. Link Labels: By default, a functoid will show XPath designation if linked directly or name of the previous functoid if it's linked from another functoid. However, if the input links to a functoid are labeled, then the Label property of the link will be shown (easy to read).

Value Mapping Functoid:

Value mapping functoid requires two input parameters: a Boolean value and the node that is to be mapped. If the Boolean value is "true", the value will be mapped; otherwise, it will not be mapped. If the Value Mapping functoid does not map a value, an empty destination node will be created. You'll need to use additional functoids or scripting to change this behavior.

Mass Copy Functoid:

The Mass Copy functoid allows source records and containing elements and attributes to be copied and mapped across to the destination schema. This in turn, allows large structure to be mapped quickly in design time, without the need of performing 1:1 detailed mapping on all subsequent schema nodes. Other approaches to recursively copy XML

Recursive mapping: This is achieved by holding down the Shift key and mapping from a source to destination record element. This approach implements 1:1 XSLT template matches on all source and destination elements.

Straight-through mapping: This is achieved by manually linking all sources and associated destination elements.

Database Lookup Functoid:

BizTalk provides the Database Lookup Functoid, which can retrieve a recordset from any ODBC compliant data source. The Database Lookup Functoid requires four parameters as inputs (inbound node, connection string, table name, column name used for search) and it outputs an ADO recordset. Recordset returns only the first row of the data that matches the specific criteria provided to the Database Lookup functoid. In addition to input parameters, Database Lookup functoid requires two helper functoids for the optimal use:

Error Return Functoid, which returns SQL, related errors. It takes Database lookup functoid as input and a link to an output node in the target schema.

Value Extractor functoid, which retrieves a specific column from the returned recordset.

Looping Functoid:

Looping functoid combines multiple records or fields in the source schema into a single record in the destination schema. The structure of a message from a source system you are integrating with contains multiple repeating record types. You must map each of these record types into one record type in the destination system. Example: The source schema has one or more PersonnelSurvey and one or more ExternalSurvey records. Each contains complete Address data. Your internal schema simply needs the Address data as a complete record irrespective of whether it came from a PersonnelSurvey or an ExternalSurvey. The Looping Functoid can be used to achive this.(the PersonnelSurvey and ExternalSurvey nodes would serve as Inputs to the Looping Functoid, with the output connected to the Parent node of the Address records in the destination).

Conditional Looping: You can add conditions to Looping functoid by linking the output of a Looping functoid and Logical functoid to the same destination node. Destination node is only created when logical condition is met.

Iteration Functoid:

Iteration functoid outputs the index of the current record in a looping structure, beginning at 1 for the first record, 2 for the second record and so on.

Date and Time Functoid:

Date and Time functoid simply outputs the current date and time, it requires no input values. There are two more derivatives Date functoid and Time functoid separately, which outputs just Date and just Time respectively. Add Days functoid accepts two input parameters a date or date time value and a numeric value indicating the number of days to add (can also put negative number to subtract days), it outputs the new date time applying the numeric value.

Scripting Functoid:

Calling Compiled Assemblies: Scripting functoid can be used to call external .NET assemblies (you need to add reference and the assembly must also be placed in the GAC). The number of input and output parameters is dependent on the logic contained within calling function. Care should be taken with regard to data types passed into and out of the external assemblies. For example, if a source document element having a data type of xs: int is used as an input parameter for a method contained in an external assembly, it will be passed as an integer.

Using inline C#, Jscript .NET and VB .NET: Instead of using external assemblies you can use inline functions written either in C#, VB .NET or Jscript .NET. Inline scripts got some drawbacks like you can't reuse the script in any other maps, you won't get rich debugging support and also the main thing since inline script is saved in the XSLT of the map, only those libraries available for XSLT scripts may be leveraged. The following are available namespaces:

Using inline XSLT/XSLT Template:

Table Looping & Table Extractor Functoid:

I found this quick tutorial useful to understand the concept http://download.microsoft.com/download/b/1/d/b1d9ddf9-88c6-4d4e-abea-4787fdc85bec/tableloopingfunctoid.exe

Schemas: This just came out of the blue; I'll put a note here, before I forget to include it somewhere.

Import/Include/Redefine

• Import works only when the two schemas have different Target Namespace attributes.
• Include is available only when both schemas share the exact same Target Namespace. Also, Include only works when the two schemas do not have any of the same top level element names, attributes, or data types. This is because Include acts essentially like a copy and paste from the original.
• While Redefine might work as well, it is primarily for situations where an alteration to the source schema elements/attributes is needed.

Deploying a BizTalk Application:

Reference: BizTalk Server 2006 Application Deployment and Management
Reference: Deploying and Managing BizTalk Applications

A BizTalk application is a logical container for application artifacts, allowing you to bucket related components. A developer can specify an application to deploy to by editing the "Application Name" property of a Visual Studio project. And an IT Pro, can use Administrative MMC console to configure and start an entire application. Once running, the application concept allows IT Pro to manage and troubleshoot selectively at the application level.

Naturally, the application container contains BizTalk Server assemblies which are deployed to it. Further, users can manually add BizTalk Server assemblies to the application, or move BizTalk Server assemblies from other applications. Likewise, they can also add non-BizTalk Server assemblies to the application. The application may also contain receive ports, receive locations, send ports, property tracking settings, and role links, to name a few. Implicitly, the application also contains all of the bindings that are represented by their current settings. And other BizTalk Server artifacts can also be added to applications, such as BRE (rules) policies and BAM definition files. Scripts are also a welcome type of resource which can be chosen to run during different application deployment operations.

Tools:

1. BizTalk Administration Console,
2. BTSTask command-line tool
3. Scripting and Programmability API's (WMI) and BizTalk Explorer Object model.
4. Visual Studio 2005.

Working with MSI's

Users have the option to exporting an application to an MSI file, which serializes all of the application artifacts into this package. Thereafter, the MSI can be imported in the target environment. Importing MSI's in BizTalk server is a 2 step process

1. IMPORT: This is a group level deploy (Once per group). This step will deploy all the BizTalk server assemblies to the management database, run scripts specified at import time.
2. INSTALLATION: This is a per box deployment (every single machine in the group). This GAC's all BizTalk server assemblies and dependency assemblies required at runtime in each machine. This operation can also create IIS virtual directories, which might be part of the solution.

Progress of MSI installation can be viewed at (a) BizTalk Event Log (Doc and Setting\user\Application Data\Microsoft BizTalk Server\Deployment), (b) Local Event Log and (c) Windows Installer Log (If /log option is used with msiexec)

Using Scripts with MSI's

You can add scripts to run as pre-processing or post –processing scripts. Example: Pre-creating MSMQ queues, creating FILE drop folder structures and permissions etc.

Environment to Environment binding files:

Every application contains a "Resources" node which contains all the resources within the application. One of the resource types is called "BiztalkBinding", which allows users to add additional binding files to the MSI. For each binding file that is added, the user must specify the environment name (text field) to which the binding should be applied to. Then on import operation, the user will be asked to choose the environment name from a drop down list, which picks up the corresponding binding file for the environment. This functionality allows us to use the same MSI file in different environments with different binding files seamlessly.

Application Upgrade strategies:

Once the application is deployed, at some point they'll probably need to be upgraded. There is various reasons why we need to upgrade an existing application, things like bug fixes, newly added partner schemas, modified orchestration etc.

Simple Upgrade: This scenario involves no downtime, no code changes; it's more of configuration changes like

1. Adding a new send port with new subscription,
2. Changing the URL of the HTTP Send port,
3. A Business Rule change etc.

Patching Scenario: In "Patching Scenario" in which existing application binaries in production must be edited and swapped with updated ones. Examples: Updating new orchestration, new maps etc. In this case, customers must meet the following conditions:

1. Scheduled downtime can be agreed
2. Currently no long running orchestration active
3. Dehydrated and Suspended instances can be either manually resumed and completed or terminated.

To deploy updated binaries:

1. Publication of new messages must be stopped by disabling endpoints (Receive Locations)
2. Stop and Unenlist any running service instances (you need to manually resume and complete or terminate, dehydrated and suspended instances)
3. New binaries will be deployed to management database using the "Overwrite" flag.
4. Each and every server in the group must be updated by GACing new binaries.
5. All BizTalk host instances should be restarted.
6. Enable message publication.

Side By Side (SxS) deployment: This allows two versions of the same artifact to run side-by-side. The .NET run time inherently allows for same named but different versioned assemblies to be deployed and running. BizTalk server also allows for this.

Maps (SxS): Maps are chosen by fully-qualified strong name, or FQSN, which means the bindings are mindful of the version used. Making a code changes to the map, upping the version number, compiling, and deploying the additional assembly to the group (and all machines) would allow users to simply select the new map for inbound or outbound mapping. (Calling a map within Orchestration will require code change and redeploying)

Orchestration (SxS): If you have short-lived orchestrations, then the "Patching Scenario", previously described, may be sufficient. But, if you have long running orchestrations or cannot terminate existing once then SxS deployment is the only choice. The customer has the option to create new receive ports and locations for the new version or use existing ports. If the former is chosen, simply binding to the new ports and enlisting/starting the new artifacts will probably be sufficient. If the latter is chosen, some additional steps apply. The customer will have to (a) bind the new version of the orchestration to existing ports, (b) unenlist (but do not stop) the old orchestration version, and (c) enlist and start the new orchestration version. The documentation includes a script which help you to do steps (b) and (c) in one transaction so that messages are not missing subscriptions in between manual clicking. The end result is that future message publications will be directed to the new orchestration version, and already running orchestration instances will complete on the older version.

Pipelines (SxS): The simple solution is to simply choose the newly deployed pipeline version in the send port or receive location. This will replace the old pipeline with the new one. However, if true side-by-side functionality is required for backwards-compatibility purposes, then new send ports and receive locations will have to be created and bound to with the new pipeline version specified.

Schemas (SxS): Side-by-side versioning is absolutely allowed, but the schema resolution behavior for the pipeline (XML disassemble) should be examined closely. Read the article for more information Schema Resolution in Pipeline Components. In certain cases hard-code references in the pipeline disassembler properties to specific versions of the schemas to avoid the dynamic resolution behavior, will allow for more "pure" side-by-side scenarios. Changes to schema assembly might need changes to maps and other schema assemblies.

Upgrade Considerations:

1. If you are undeploying an artifact on which another artifact depends, the dependent artifact must be undeployed first.
2. If a BizTalk assembly in an existing application is updated, you may need to restart host instances for the changes to take effect.
3. If you use Visual Studio to deploy and "Restart Host Instances" is set to true, all host instances will restart when you deploy the application, including those that are not associated with this application.
4. When you revise an assembly containing an orchestration, schema, or map, you must update the global assembly cache (GAC) with the assembly containing the new version.
5. The use of .NET policy files is not supported in BizTalk Server 2006. Because BizTalk Server often accesses assemblies and artifact data from a cache or the BizTalk Management database.
6. Undeploying a schema causes the previous version of the schema, if available, to become active.
7. The highest version of a policy that is in a deployed state is used by the BizTalk Server runtime.

Dependencies and Application Deployment:

When one artifact needs to use another artifact in order to function properly, it is said to be dependent on another artifact. Example: Orchestration depending on schema for messages. Most type of artifacts must be unique in a BizTalk group; you cannot have the same artifact in two different applications in the same group, even if both applications contains artifacts that depend on the same artifact.

When this happens, you can add the needed artifact to one application and then add reference to that application from any other applications containing artifacts that depend on it. When you add a reference to an application, artifacts in the application can use any artifacts in the application that it references.

Start and Stop BizTalk Applications:

To start an application all the Orchestrations binding must be fully configured inside the application. When you stop an application you will get the following options:

Partial Stop – Allow running instances to continue: This option disables receive locations, but leaves all other artifacts in their previous state.

Partial Stop – Suspend running instances: This option disables receive locations, STOPS (does not UNENLIST or UNDEPLOY) all orchestrations and send ports in the application.

Full Stop – Terminate instances: This option disables receive locations, STOPS and UNENLIST all orchestrations and send ports. It will also terminate any running instances.

BTSTask command-line tool:

You can use BTSTask to perform many application deployment tasks from the command line, as follows:

Usage: BTSTask.exe <Command> [[<Parameter>] ...]

Commands:

Day 2 Summary: I planned my exam with 2 weekends in mind. This is the first weekend so I decided to utilize maximum out of it. I've spend 3 hours for the maps and 3 hours for Application Deployment topic.

---

Day 3:

Business Rules Engine

References: http://support.microsoft.com/default.aspx/kb/838412 Just listen to this 2hr long webcast you'll know everything about BRE after the webcast. This is one of the oldest web cast recorded in April 2004. There are couple more new ones, but I feel this covers BRE from A-Z. It's one of the easy going webcast; concepts are easy to take and don't requires too much concentration. I referred to Chapter 11 of "BizTalk unleashed 2004" as well to get some of the definitions.

Most of the time the business process remain the same but business logic changes, for example in a typical Loan processing example interest rate will change every day, discount will change, promotions may be given etc. Business processes may be affected by these changes. Business rules abstract business rules from procedural code. Some of the key concept we need to be aware of

Important Definitions:

Rule: A rule is a single executable statement which is made up of a Condition and an Action. Condition always evaluate to "true" or "false". If a condition evaluate to "true" the Action will be execute. Conditions are created with help of "facts". For example, in the statement (condition) "cost > 500", we have 2 facts "cost" and the constant "500", and a predicate ">". Logical operators AND, OR and NOT are available to combine conditions. A fact can be (a) a field in the XML document, (b) a property in a .NET object or (c) the value of a column in a row of relational data. An action can be something like updating a field in the XML message, calling a method in the .NET object or updating a field in the database table.

Policies: Policies are logical grouping of rules.

Vocabulary: A vocabulary is a set of associated name pairs. Each pair consists of a friendly name a business analyst might use, such as "Cost" or "Age". Without vocabularies, a typical condition could read

Consulting.Rates.RateName is equal to RFPEstimateXml.RulesRFP:/RFP/Service

With vocabularies, the condition can become

ServiceName is equal to Service

While defining vocabularies you can make it select "Set" or "Get" operation based on your requirement whether to just read it or read and write as well.

<<Sample Screen>>

Rule Engine: Evaluates conditions based on fact, if conditions evaluate to true executes action. The process by which rules are executed is radically different from what you are used to in procedural code. When a policy is executed, the facts are brought into memory, a process called assertion. Facts may be loaded into memory prior to execution, or new instances of facts may be asserted as an action in a rule. Rule-based system the one BizTalk implements, is a forward-chaining inference engine.

Rule Store: Repository for rules and policies, BizTalk server uses SQL server as rule store.

Rules engine update service: Monitors the rules store to detect changes to published policies, to ensure that the latest version is always loaded into memory for execution unless the host application explicitly specifies otherwise. The host applications uses .NET API's from the Rules Framework to load and execute policies.

Host Applications: Host applications can be any executable or assembly that can load and execute policies and submit facts. Orchestrations are host applications, "Business Rules Composer" application also acts as a host application when you test a policy. You can also build a standalone .NET application as a host application.

Tools for business rules

• Business Rule Composer: It's is used for developing business policies, vocabulary definitions, publish/test policies and vocabularies. <<Sample Screen>>
• Rule engine deployment wizard: Deploy/Exporting/Importing policies and vocabularies.
• Health Activity and Tracking (HAT): Tracking configuration, Policy execution monitoring.
• Visual Studio:

Calling rules from Orchestration: You can call policies via the "Call Rules" shape, which will ALWAYS pick up the latest version of the policy deployed, or you can use .NET API inside the expression shape to call the policies by this method you'll get the option to call specific version of the policy. The client applications can access only the deployed policies. If a client application invokes a policy that is not deployed, the rule engine generates a RuleEngineDeploymentNotDeployedException exception. A policy cannot be modified after it is published. The Call Rules shape reconstructs the message, as if using a Construct Message shape, which in turn may cause context properties of the message to be lost. The following code snipped shows how you can execute policies programmatically (ex: expression shape in Orchestration):

C# Code

Policy expecting Multiple Facts

Advanced Concepts:

Forward Chaining: When the available facts exist to evaluate a rule's condition and it evaluates to true, the rule is fired. As rules fire, new facts are asserted into memory. For example, firing a rule might cause a field to be set in a message. This becomes a new fact in memory, which may cause another rule to fire. This continues until no more rules can fire or a specific number of passes through the rule base have occurred. The later restriction avoids endless execution of the rules engine. This process is called forward chaining. The slide below shows an example:

From developers perspective important thing is updating the facts using "Update" command (right click on "Action" and select "Update"). Update action will updates the facts in memory and asks rules engine to reevaluate the conditions.

Short-term vs. Long-term facts: 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. Long term facts can come from a data store like SQL and you need to use a Fact Retriever to use long term facts. Short term facts are passed to rule engine as array of objects, whereas long term facts are passed as typed DataTable which has typed DataRows to rule engine. To implement a fact retriever you need to implement the interface IFactRetriever, which allows you to wrap around your data from data source (you can bring data from any data source) and brings it into memory. Fact retriever is associated with a policy version and an UpdateFacts method is called by the rules engine. Facts are inserted into the rule engine via a DataConnection, it is a wrapper class to wrap SqlConnection, Database and Table. Example:

Fact Creator: Inside the Business rules composer when you want to test the policy for a .NET component (when you want to use it as actions), you can't just "Add Instance" (like adding an XML file for Xml facts and database instances for Database facts). Instead you need to create a Fact Creator wrapper around your .NET component implementing the interface IFactCreator for testing the policies using .NET objects. CreateFacts method is called by the rules engine.

Walkthrough Labs:

If you haven't worked with Business rules at all, it's worth going through this walkthroughs. Walkthroughs are present in the BizTalk 2006 CHM documentation; use the search tab to get to the topics

1. Walkthrough: Creating a Simple Business Policy
2. Walkthrough: Testing the Policy
3. Walkthrough: Invoking the Policy from an Orchestration
4. Walkthrough: Creating and Using a Vocabulary in the Policy
5. Walkthrough: Adding a Rule to the Policy
6. Walkthrough: Modifying the Policy
7. Walkthrough: Tracking Policy Execution
8. Walkthrough: Deploying the Policy
9. Walkthrough: Executing the Policy Programmatically
10. Walkthrough: Creating a Fact Creator
11. Walkthrough: Using Database and .NET Facts

You can prioritize execution of rules by specifying the Priority property on rules in Business Rule Composer. The rule with highest priority number will get highest priory.

Policy Execution:

The rule engine uses the three-stage Condition Evaluation-Conflict Resolution-Action Execution algorithm to execute policies. In the Condition Evaluation stage, the rule engine evaluates the conditions in all the rules in the policy and adds the rules whose conditions evaluate to true to the agenda. In the second stage, the Conflict Resolution Criteria stage, the rules whose conditions evaluate to true are added to the agenda in order based on their priority. In the last stage, the Action Execution stage, the rule engine starts executing the actions in the rule.

After execution all the facts submitted (Example: Purchase Order) to the rule engine and the child facts created by the rule engine based on XPath selectors (Example: \PurchaseOrder and \PurchaseOrder\Item) are retracted (removed) from the working memory of the rule engine.

When you test a policy that uses database facts with the DataConnection binding in the Business Rule Composer, a DataConnection object is automatically built for you. However, when you call the same policy from an orchestration by using the Call Rules shape, no DataConnection object is passed to the policy automatically. You 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.

Important things to remember:

• After you save the vocabulary, you can still modify it. After you publish the vocabulary, you cannot modify it. Only published vocabularies can be used in policies.
• A published policy cannot be modified. You must create a new version of the policy to modify it. Similarly, a published vocabulary cannot be modified. You must create a new version of the vocabulary to modify it.
• The orchestration invoking a policy by using the Call Rules shape uses the latest deployed version of the policy. For example, if you have versions 1.0, 1.1, 1.2, and 1.3 of the policy deployed, the orchestration uses version 1.3. If version 1.3 is not deployed and version 1.2 is deployed, the orchestration uses version 1.2. Therefore if you want to switch back to using version 1.2, you just need to undeploy version 1.3, and make sure that version 1.2 is deployed.
• A policy can use different versions of the vocabulary (Example: version 1.0 and version 1.1) If you export the policy (which contains a mixture of vocabulary versions) to an XML file, and import it to create the policy on a different computer, the import process will look for all versions of the vocabulary used in the policy. Therefore you need to export all the versions of the vocabulary used by the policy and import them before importing the policy that uses different versions of the vocabulary.
• To test a policy that uses non-static methods of a .NET class by using the Business Rule Composer, you must create a fact creator component.
• As soon as you add a schema file (.xsd) to XML fact, make sure you change the "DocumentType" property to <Project Name>.<SchemaName> as shown in the below figure. If you don't change this value you won't be able to set the message parameter (facts) for policy from the Orchestration (Project)

• The actions of a rule will be executed in the order specified, so make sure they are in right order by moving up or down (from context menu).

Tracking Policy Execution

In BizTalk administration console, expand Application->Policies and select "Add Policy". Add appropriate policy version from the tree view displayed, and then you can right-click on the policy and select "Tracking" from context menu. "Policy Tracking Options" window allow you to enable tracking for the following rule items

• Fact activity
• Condition Evaluation,
• Rule Findings
• Agenda Updates

At runtime open "Health and Activity Monitoring", click on the Orchestration and select "Message Flow" and select "Follow this link to view the Policy execution details for this orchestration instance", Selecting PolicyID will show the tracing details we selected before. The details are similar to the one we saw in Business Rule Composer, test policy Output screen.

Day 3 Summary: I spend around 5-6 hours in total to complete BRE, which includes 2 hours of Web Casts, 2 hours of Study and 2 hours working out the samples and reading some stuff here and there.

---

Day 4: It's good to take a break.

---

Day 5 and Day 6:

Orchestrations:

Reference: BizTalk 2004 Unleashed (Chapter 10 and Chapters 12)
Reference: http://msdn2.microsoft.com/en-us/library/ms942198.aspx
Reference: http://msdn2.microsoft.com/en-US/library/ms935219.aspx

Transactions inside BizTalk:

BizTalk supports two kinds of transaction: atomic and Long-running. Atomic transactions are very similar to classic database transactions. Long running transactions lack the formalism of atomic transaction and as the name suggest it's supposed to run for a long duration of time.

Atomic Transactions:

Restrictions:

Atomic transactions are the most powerful form of transactions BizTalk orchestration offers, but they impose the most restrictions.

1. You cannot nest a long-running transaction within an atomic transaction. Because atomic transaction offer the strongest guarantees for correctness, specifically isolation and atomicity.
2. Besides banning long-running transactions, atomic transactions cannot contain other atomic transactions.
3. Atomic transaction cannot have an exception handler. Such transactions do not need exception handlers, though, because a fault will result in either a retry or an automatic rollback.
4. You cannot construct an atomic transaction with a request-response pair of actions, nor can you have Send and Receive shapes that use the same correlation set.
5. The actions taken by Send, Receive, and Start Orchestration shape within an atomic transaction will not take place until the transaction commits. When a message is received in an atomic transaction, it is delivered to the orchestration but not removed from the MessageBox until the transaction commits.

Creating an Atomic transaction:

1. Right-Click the design surface of the Orchestrations as whole and select properties. Set the "Transaction Type" property to "Long Running".
2. Add a Scope shape to the orchestration, set the "Transaction Type" to Atomic.
3. Now you have to select a value for isolation-level property. Default Serializable. (other choices: Read Committed, Repeatable Read)

The value of the last property becomes especially important when you want to go further and make your atomic transaction a full-fledged DTC style transaction. There are 2 rules you must satisfy

1. All components used within the transaction must be deriv