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

POSTERS

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 derived from System.EnterpriseServices.ServicedComponents, and
2. The isolation-level set for the components must agree and must be compatible with the isolation level of the transaction.

Calling non-serializable .NET Components: Atomic transactions have another use unrelated to ordinary transactional concerns. It can be used to call .NET components that are not serializable, you can use them safely within an atomic transaction.

Long-Running Transactions:

Creating Long-running transaction:

1. Make the orchestration as a whole Transactional
2. Add a Scope shape and set its Transaction Type property to Long Running.
3. Set the Timeout value if required. Timeout property evaluates to a UTC time, so you can use TimeSpan object to set appropriate Timeout value.

Because Long-running transactions are less restrictive than atomic counterparts, you can nest long-running transactions within one another.

Exception Handling:

In long-running transaction developer needs to take care of how exceptions are handled to recover the state of the orchestration to correct for the fault. Following condition will force exception inside a long running transaction:

1. Forced termination using "Terminate" shape (Exception type: Microsoft.XLANGs.BaseTypes.ForcedTerminationException)
2. System generated exceptions
3. User code (components or expression shape statements)
4. Transaction Failure:
5. Timeout expiration: Exception type: Microsoft.XLANGs.BaseTypes.TimeoutException
6. Throw Exception Shape
7. Receipt of a fault message. Any two-way port can have a fault message type associated with it. This is done by right-clicking the operation node for the port type in the Orchestration and selecting "New Fault Message" from the context.
   

Exceptions are caught and handled in a long-running transaction by adding an exception handler block to the transaction. Right-click the transaction scope shape and select "New Exception Handler". Exception handler has two properties that must be configured

1. Exception object Name, which is simply an identifier for this exception,
2. Exceptions object type, which is the .NET type of the exception to be handled.

Compensations:

There are occasions when a transaction completes successfully but must have its action reversed for some business reasons. Compensations blocks are explicitly called to undo the associated transaction. This is the purpose of the compensation blocks. Compensations blocks may be created for both atomic and long running transactions (see point 3 on "Atomic transactions restrictions"). Indeed, all transactions have a compensation block. If the orchestration designer does not explicitly create one, BizTalk creates an implicit compensation block.

To create a compensation block, right-click on the scope shape (Long running enabled) and select "New Compensation" from the context menu. Note that the flow of control does not automatically flow into the compensation block from the transaction. Compensation blocks must be explicitly invoked. To invoke the Compensations block, merely drop the "Compensate" shape into the exception handler block (Compensate shape can be placed only in exception or compensation block) and set the "Compensation" property to the corresponding transaction name in the properties window.

The default compensation process for nested transactions has the effect of running the compensation handler for each of the nested transactions in the reverse order of how they were committed. A particular scope can be compensated only once. The compiler will prevent more than one path leading to the compensation of a particular scope.

Compensation block may also be defined for the orchestration as a whole (by selecting "custom" for Compensation property). It is useful to compensate completed orchestration instances and applies primarily for called orchestrations. The custom compensation does not run for standalone orchestrations.

Persistence in Orchestrations

The orchestration engine saves the entire state of an orchestration instance at various persistence points to allow rehydration of the orchestration instance. The state includes any .NET-based components that may be used in the orchestration, in addition to messages and variables. 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

The engine optimizes the number of persistence points as they are expensive, especially when dealing with large message sizes. As shown in the two orchestration instances below, in the orchestration with the Send Shapes in an atomic scope, the engine determines a single persistence point between the end of the transaction scope and the end of the orchestration. In the other orchestration, there will be two persistence points, one for the first Send shape and the second for the Send shape plus end of the orchestration.

Any .NET-based objects you use in orchestrations, either directly or indirectly, must be marked as serializable unless they are invoked in atomic scopes, or if the objects are stateless and are invoked only through static methods. System.Xml.XmlDocument is a special case and does not need to be marked as serializable regardless of the transaction property for a scope.

How does the special handling for System.Xml.XmlDocument work:

When the user defines a variable X of type T, where T is System.Xml.XmlDocument or a class derived from System.Xml.XmlDocument then the compiler will treat X as a serializable object.

When serializing X, the runtime will keep the following pieces of information: (a) the actual type Tr of the object X is referring to (b) the OuterXml string of the document.

When de-serializing X, the runtime will create an instance of Tr (this assumes a constructor that does not take any parameters) and will call LoadXml providing the instance with the saved OuterXml. X will then be set to point to the newly created instance of Tr.

Correlation:

The orchestration engine uses the concept of correlation to match incoming message to an orchestration instance. The engine may spawn different orchestration instances, each of which deals with instance-specific data. Correlation needs to be used in scenarios where there might be a need to send/receive messages asynchronously, especially in the case of long running processes. The engine uses implicit correlation when dealing with request/response scenarios.

Correlation is achieved by creating correlation types and correlation sets based on the correlation type. A correlation type is a list of properties that can be picked from either the application-specific property schema or the GlobalPropertySchema used by BizTalk. It is important to note that the application-specific properties have to be promoted properties and will not appear in the Correlation Properties dialog box if they are identified as distinguished fields. The following figure shows the Correlation Properties dialog box. As is shown, the available properties by default include all the properties from the GlobalPropertySchema.

Correlation Properties dialog box

A correlation set is a collection of promoted message property values that you 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.

Consume and Publish Web Services

How to Consume a Web Service

At a high level, the typical steps required to consume a Web service are:

1. Add a Web reference to the service you want to consume.
2. Add an orchestration.
3. Add a port to the orchestration, setting the port type to the Web port type that was created when you added the Web reference.
4. Create a new message of the same type as the Web service request.
5. Create a new message of the same type as the Web service response.
6. Send the request message.
7. Receive the response message.
8. Sign the assembly, deploy it, and test it.

When a web reference is created, the following artifacts are created and readily available inside the Orchestration:

• Web Port Type
• Web Message Types (Multipart request and response messages to all web methods)

Constructing Web Service Requests and Responses

Two techniques are used for creating a Web message request: transformation and assignment. Which one you use depends on the parameter type of the method you are calling. If it is a complex type, then you use a transformation (map) or assignment (programmatic) to create the request. If the Web service method you are calling requires a simple parameter type (for example, string), then you directly assign a value to the request message parameter in an expression shape (in this case, you cannot map).

In some cases you may want to set the Web service URI dynamically. You can do this by specifying that your Web port is dynamically bound (as opposed to "specify now" or "specify later"), and then setting the URI in a Expression shape as follows:

CallRegistrationService(Microsoft.XLANGs.BaseTypes.Address) = "http://PayrollCompany/RegisterEmployee.amsx";

Exception handling:

An exception handling block can be used for the scope shape, which will handle the exceptions. If in case you want to deal with the SOAP exception particularly if you are interested in handling the return fault message, you can add Exception handler and assign "Exception Object type" property to "System.Web.Services.Protocol.SoapException" and inside the Exception handler, you can get hold of the message by loading the ex.Detail.OuterXml (ex is the name of the Exception handler) property into a XML DOM.

How to Publish your Orchestration as Web Service:

Open BizTalk Web Services Publishing Wizard and select an assembly containing the orchestrations (the wizard looks through it for schemas and orchestrations). Orchestrations containing public ports are listed on the wizard screen. Note that the default type modifier (which controls visibility) for port types is "Internal". You need to change this to "Public" for any ports that you wish to expose as Web services. These ports are published as Web methods, and the messages they send and receive are published as types. The publishing wizard includes a mechanism for adding additional SOAP headers and specifying whether unexpected SOAP headers should be permitted. Note that you only need to do this generation process if the orchestration ports or schemas change. You can modify the orchestration and redeploy it, and as long as the public interface has not changed you do not need to regenerate the Web service. The wizard process also generates the appropriate virtual root for your Web service, and the virtual root is configured for the default application pool. You'll need to assign the virtual directory to appropriate application pool, which is configured with the user belonging to "BizTalk isolated users" and "IIS_WPG" groups.

Returning a Fault Message

1. Create a fault message
2. Add a fault message to the operation of the request/response port that is exposed as a Web service
3. Return the fault message in the event of an error condition

Role Links:

Role Link (Trading partner mangement) is one of the functionalities that's been not widely used. There are very few documentation around. I found the following sample from BizTalk 2006 sample self contained.

Reference: http://download.microsoft.com/download/b/1/d/b1d9ddf9-88c6-4d4e-abea-4787fdc85bec/simplerolelink.exe

How to Create Role Links in Orchestrations
http://msdn2.microsoft.com/en-us/library/aa953864.aspx When a Role Link where the initiating role is a provider for receiving messages is set up, the DestinationParty is initialized automatically at the receiver. When such a Role Link is designed, the DestinationParty is set to the provider itself.
The DestinationParty is set explicitly only when the initiating role is a consumer.
The SourceParty is read-only when the initiating role is a provider. Therefore, setting it to any value is not possible.

Day 5 & 6 Summary: I felt Orchestration, which is core of business process integration, will be the key topic in the exam. So, I decided to spend 2 days covering most of the key topics for Orchestration. I spend around 6 hours in total for the Orchestration topic.

---

Day 7

Business Activity Monitoring

Reference: I've glanced at all the BizTalk books I have and decided to read Chapter 9 of "BizTalk 2006 Recipes" to cover BAM syllabus in the exam. It took me around 2 hours to finish the chapter. If in case you don't have the book read the white paper BizTalk Server 2006 Business Activity Monitoring published by Microsoft.

Business processes generally create metrics and data, which are needed for reporting purposes. One of the core components of BizTalk 2006 is BAM, its framework which allows you to create, deploy and view information about running or previously run processes. BAM implementations publish metrics and reports and make them available to users through custom interfaces, which are update in near real time as data progress through the system.

BAM is tied directly to the central BizTalk engine (that is, processes and databases) through OLAP cubes. These cubes are created automatically when a developer deploys a BAM report and profile. Typically by using Microsoft Excel pivot table and BizTalk Tracking Profile editor. Once all the BizTalk components are deployed and a running instance of Orchestration (not limited to Orchestration in BizTalk 2006) is executing, all defined steps of the flow will be subscribed to via OLAP cubes and published via BAM components to the user. Users can access the published data via

• Web (Service)
• SharePoint
• Excel Spreadsheets, or
• Custom application

Creating BAM Activities and Views in Excel Spreadsheet:

There are four categories of steps required to create the first part of the BAM solution. Each category of steps plays an integral role in developing a useful, rich and powerful solution:

1. Creating the BAM activity Workbook
2. Outlining the BAM View
3. Identifying aggregations, dimensions, and measures
4. Constructing the pivot table

Tutorial: http://msdn2.microsoft.com/en-us/library/aa561717.aspx

You can find the following walkthroughs in the BizTalk 2006 documentation download (CHM file). Do a search for the following topics and work out the walkthroughs

• Walkthrough: Creating a BAM Observation Model with the BAM Add-In for Excel
• Walkthrough: Deploying the BAM Observation Model
• Walkthrough: Creating a Tracking Profile
• Walkthrough: Consuming BAM Data

Day 7 Summary: Configuring and understanding BAM includes working with Excel Spread sheet, Tracking Profile Editor, BAM Portal and BM deployment tool. I found it harder to document the whole process in this article. The best thing I can suggest is go through some tutorials listed above and work out one or two full walkthroughs. I spend around 5 hours with BAM.

---

Day 8

Scalability

Reference: Chapter 15 of BizTalk Server 2004 Unleashed.

BizTalk Server is designed to provide convenience and flexibility for management of multiple servers that are part of a BizTalk server group from a centralized location. Management and maintenance of multiple BizTalk servers is simplified by abstracting away the physical servers from the roles the servers play using the concept of hosts, which are logical containers. Because of this level of indirection, the servers are not tightly bound to the roles they are designated to perform. By adding servers called host instances, into hosts, the servers take on the responsibility of performing the tasks that the hosts are designed to play. A host instance is effectively an instance of a windows service BTSNTSVC.exe running on a BizTalk server. It's possible to have multiple host instances running on a single BizTalk Server. This feature is useful if the server is underused. This design simplifies the process of adding, removing, starting and stopping specific BizTalk host instances without impacting other running BizTalk host instances. Thus servers are updated in real-time without impacting availability.

Deploying for Scalability:

Scaling out involves adding multiple BizTalk servers until the SQL Server Message Box database becomes the bottleneck because of severe contention. Thereafter its recommended to scale out the database tier, adding Message Box databases. When SQL tier again becomes the bottleneck, adding more Message Box databases will help scale out adding more BizTalk servers.

Scaling out BizTalk servers:

BizTalk server is a persistent messaging system whereby all data is persisted to disk. However, no data is persisted locally on the BizTalk servers; all data is persisted within multiple SQL server database tables. When you scale out using multiple BizTalk servers, it is necessary to add the compiled assemblies to GAC locally on all the BizTalk server machines. In addition to deploying the assemblies, any resources such as SOAP Web Services, HTTP virtual directories, File Receive Locations, and so on required to support the solution must be set up. You need to deploy the BizTalk assembly only once into the management database per group. Although BizTalk can be configured to run on a single machine, when scaling out it is recommended to first separate the SQL databases onto a dedicated server.

Scaling out SQL servers:

It's strongly recommended that SQL be installed in a highly available manner on an MSCS cluster. The BizTalk service is designed to automatically recover from a SQL server connection failure. Message box (BtsMsgDb) is the heart of the BizTalk server, all message data and tracking data are written to the Message Box database, making this database the point of contention. Every BizTalk group must have one and only one Master message box database. Due to high contention in Message Box database it's advisable to deploy the DBF and LOG files onto separate physical disks. When master message box database becomes bottleneck, you can scale out by adding multiple message boxes. None of the BizTalk server service instances have any affinity to any particular message box. The Messaging agent abstracts away this round robin load-balancing mechanism, thus the BizTalk service instances have no knowledge as to the physical locaton of data. It's recommended to scale out the database tier, deploying multiple message box databases, only when the SQL server machines hosting the Message Box database becomes the point of contention. Because adding more message box databases introduces overhead on master message box to perform the routing of data to other message box databases and also the additional overhead of network traffic and distributed transactions.

Scaling up BizTalk Servers

It's possible to scale up BizTalk servers by adding more memory, more CPU's, and/or higher-speed disks.

Scaling up SQL Servers:

SQL Server performs better when a large amount of memory is made available. However, under severe stress, SQL Server can become CPU bound. When this occurs, it is recommended to scale up adding multiple CPU's. Under severe stress, the SQL server can slow down the BizTalk servers because of high disk latency. When this happens, its recommended to upgrade the disks to either high-speed RAID5 disks with multiple spindles or, if possible, to a SAN drive using fiber optic channels. In additions, separating the DBF and LOG files onto dedicated disks helps reduce disk IO contention.

Scaling out HTTP/SOAP Transport:

The HTTP and SOAP receiving adapters can be scaled out using the WLBS service. The process is similar to the way load is balanced for any HTTP Web site or SOAP Web services.

High Availability

Reference: http://msdn2.microsoft.com/en-us/library/aa577430.aspx

BizTalk Server 2006 provides functionality that allows you to configure a BizTalk host as a clustered resource within a Windows Server cluster group. Host cluster support is provided to support high availability for integrated BizTalk adapters that should not be run in multiple host instances simultaneously; such as the FTP receive handler or, under certain circumstances, the POP3 receive handler. Host cluster support is also provided to ensure transactional consistency for messages sent or received by the MSMQ adapter in scenarios that require that the MSMQ service is clustered.

Note: Host clustering is only available with BizTalk Server 2006 Enterprise Edition.

Scale-out Receive hosts:

When you create multiple receiving hosts you can create security boundaries and ease the manageability and scalability of your environment; however, it does not make your environment highly available.

To make your environment highly available, you must create two or more host instances for each receiving host that you create. For example, you can create three different receive hosts (A, B, and C) to receive messages from three different companies. To make each of these hosts highly available you then create host instances of each of these hosts in two or more computers. Note that you can have instances of each host on one computer without losing the security boundary, manageability, or scalability.

File:
BizTalk Server 2006 provides high availability for the file receive adapter by letting you create host instances on multiple host computers that subscribe to the same UNC path. If a host instance running on one host computer encounters errors or fails, the same host instance running on another host computer can retrieve the message and persist it to the MessageBox database.

FTP:
The FTP receive adapter should not be configured to run in multiple hosts because the FTP receive adapter uses the FTP protocol to retrieve files from the target system and the FTP protocol does not have any notion of file locking to ensure that multiple copies of the same file are not retrieved simultaneously when running multiple instances of the FTP receive adapter. The FTP receive adapter should be configured to run in a clustered BizTalk host.

To provide high availability for the FTP send adapter, you should configure the FTP send adapter to run in a clustered BizTalk host. The FTP send adapter supports only one host instance running at a time.

Identify Security Requirement

Reference: http://msdn2.microsoft.com/en-us/library/aa559217.aspx

Identifying potential threats:

You can use the STRIDE model to identify potential threats to your BizTalk Server deployment. STRIDE is an acronym derived from the following categories: Spoofing identity, tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privileges

• Spoofing identity: If you save passwords in the binding files, and save these binding files, unauthorized users could read the passwords and use them to connect to the BizTalk Servers, and possibly cause harm. So, avoid saving passwords in binding files, or secure them properly.
• Tampering with data: You can use digital signatures to prevent malicious users from tampering with messages while they are in transit.
• Repudiation: You need to keep track of messages that BizTalk sends and receives. You can use digital signatures to prove that you sent a message and that your partners sent you a message.
• Information disclosure: Use SSL and IPSec instead of sending message in clear text.
• Denial of service: A malicious user can send a large number of messages to BizTalk Server, which could prevent BizTalk from receiving valid messages.
• Elevation of privileges: To minimize the possibility of an elevation of privileges attack, you should use non-overlapping, least permission accounts, and you should avoid the use of administrative accounts for run time services and operations.

Mitigating Denial of Service Attacks

• Use the Authentication Required property in the receive port.
• Limit the size of the messages that BizTalk can receive: For example, when you use the SOAP receive adapter, you can avoid receiving very large messages size by setting the maxRequestLength attribute in the <httpRuntime> element to an acceptable size.
• Use strong ACLs for receive locations.
• Use IPSec: The Microsoft Windows Server 2003 operating system includes an implementation of the Internet Engineering Task Force's Internet Protocol security (IPSec). IPSec, which is also included in Windows 2000 and Windows XP, provides network managers with a key line of defense in protecting their networks. IPSec exists below the Transport layer, so its security services are transparently inherited by applications. IPSec provides the protections of data integrity, data origin authentication, data confidentiality, and replay protection without having to upgrade applications or train users.
• Use IIS Lockdown Tool, when using Windows Server 2000.

---

Day 9 and Day 10

Revision

So far over the past 8 days I collected all the required material related for the exam MCTS BizTalk 2006. The documentation I've prepared is not complete, but covers almost all the important points necessary for the exam. I revised the material for couple of times and this time I expanded little bit with the links I mentioned as "Reference" under each day. If I find something important then I did study a bit. I worked out the example for Role links and some examples with BAM from BizTalk Receipes.