BizTalk Server 2006 ODBA Updated
The download for BizTalk Server 2006’s ODBA (Orchestration Designer for Business Analysts) was recently rev’d on April 14th. Be sure to download the latest version at:
WSS Adapter webcasts/videos
BizTalk 2006 RTMd last month, and the BizTalk Betaplace has been closed for a few weeks now. Many people have asked me for access to the WSS Adapter videos that were shared on the betaplace and finally, here they are.
The videos are shared on this SharePoint site: http://wssadapter.members.winisp.net/default.aspx, in the Shared Documents document library, WSS Adapter Webcasts folder.
This posting is provided “AS IS” with no warranties, and confers no rights.
Use of included videos are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm. Some of the content was developed for the BizTalk Beta builds, but it is still generally applicable to the RTM version.
Demystifying Direct Bound Ports – Part 1
Direct Bound Ports
In BizTalk Server 2004/2006 orchestrations can have direct bound ports.
Direct bound ports are logical one-way or two-way ports in your orchestration that are not explicitly bound to physical ports that allow you to have different communication patterns amongst your services. To create a direct bound port select the binding of the logical port to be direct then choose as the ’Partner Orchestration Port’ what this port will be bound to.
There are three types of direct bound ports that you can choose as the Partner Orchestration Port; message box, partner, and self-correlating.
Message box direct bound ports allows for publish-subscribe design patterns. Messages sent on a message box direct bound port are published to the message box without any explicit intent of the message recipients. Logical receive ports configured as message box direct bound ports get messages directly from the message box whose subscriptions are based only on message type and filter expression (for activating receive shapes) or correlation set (for non-activating receive shapes).
Figure 1 Message Box Direct Bound Ports
Partner direct bound ports provide for inter-orchestration communication. Messages sent on a direct bound port can be sent to an intended recipient orchestration and messages received on a partner direct bound port can be received from an intended sender orchestration.
Figure 2 Partner Direct Bound Ports
Self-correlating direct bound ports assists you in designing asynchronous inter-orchestration communication. Messages sent to a self-correlating direct bound port are routed to the instance of the orchestration that created the receiving end of the self-correlated direct bound port.
Figure 3 Self-Correlating Direct Bound Ports
A commonly misunderstood aspect of direct bound ports is its interaction with the message box with some incorrectly thinking that there is direct communication with another instance of an orchestration without traversing the message box. This is not the case; any message sent through any type of logical port always travels through the message box.
Figure 4 All logical ports communicate through the message box
Direct bound ports are only logical ports and therefore only a design time configuration feature. An administrator cannot bind a direct bound port to a physical port nor change the partner it is currently configured for.
To see each of these different types of ports in action and in context you can look at the Business Process Management (BPM) scenario that ships as part of the SDK in BizTalk Server 2006.
I will have a separate posting and go into more detail on each type of direct bound port.
WSS Adapter webcasts/videos
BizTalk 2006 RTMd last month, and the BizTalk Betaplace has been closed for a few weeks now. Many people have asked me for access to the WSS Adapter videos that were shared on the betaplace and finally, here they are.
The videos are shared on this SharePoint site: http://wssadapter.members.winisp.net/default.aspx, in the Shared Documents document library, WSS Adapter Webcasts folder.
This posting is provided “AS IS” with no warranties, and confers no rights.
Use of included videos are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm. Some of the content was developed for the BizTalk Beta builds, but it is still generally applicable to the RTM version.
Demystifying Direct Bound Ports – Part 1
Direct Bound Ports
In BizTalk Server 2004/2006 orchestrations can have direct bound ports.
Direct bound ports are logical one-way or two-way ports in your orchestration that are not explicitly bound to physical ports that allow you to have different communication patterns amongst your services. To create a direct bound port select the binding of the logical port to be direct then choose as the ’Partner Orchestration Port’ what this port will be bound to.
There are three types of direct bound ports that you can choose as the Partner Orchestration Port; message box, partner, and self-correlating.
Message box direct bound ports allows for publish-subscribe design patterns. Messages sent on a message box direct bound port are published to the message box without any explicit intent of the message recipients. Logical receive ports configured as message box direct bound ports get messages directly from the message box whose subscriptions are based only on message type and filter expression (for activating receive shapes) or correlation set (for non-activating receive shapes).
Figure 1 Message Box Direct Bound Ports
Partner direct bound ports provide for inter-orchestration communication. Messages sent on a direct bound port can be sent to an intended recipient orchestration and messages received on a partner direct bound port can be received from an intended sender orchestration.
Figure 2 Partner Direct Bound Ports
Self-correlating direct bound ports assists you in designing asynchronous inter-orchestration communication. Messages sent to a self-correlating direct bound port are routed to the instance of the orchestration that created the receiving end of the self-correlated direct bound port.
Figure 3 Self-Correlating Direct Bound Ports
A commonly misunderstood aspect of direct bound ports is its interaction with the message box with some incorrectly thinking that there is direct communication with another instance of an orchestration without traversing the message box. This is not the case; any message sent through any type of logical port always travels through the message box.
Figure 4 All logical ports communicate through the message box
Direct bound ports are only logical ports and therefore only a design time configuration feature. An administrator cannot bind a direct bound port to a physical port nor change the partner it is currently configured for.
To see each of these different types of ports in action and in context you can look at the Business Process Management (BPM) scenario that ships as part of the SDK in BizTalk Server 2006.
I will have a separate posting and go into more detail on each type of direct bound port.
How to Get Message Context Values Inside a Map
Carlos Medina has created a functoid that can be used to extract context values from a message inside a map!
This is a very common problems and this approach is something I didn’t really consider.
Make sure you check out his post. He has sample code and the solution for download.
BizTalk Message Context Functoid – How to Get Context Values Inside a Map
Carlos Medina has created a functoid that can be used to extract context values from a message inside a map! This is a very common problems and this approach is something I didn’t really consider. Make sure you check out his post. He has sample code and the solution for download.
BizUnit 2006 is Released – BizTalk 2006 and Visual Studio 2005
I’ve finally got around to finishing off BizUnit 2006 – v2.1 just in time for the BizTalk 2006 GA, this version is targeted at BizTalk 2006 and Visual Studio 2005 and is built using .Net 2.0. I’ve been using the new unit testing capability in Visual Studio 2005 to drive BizUnit for a while now instead of NUnit and have to say I’m pretty pleased with it.
And some new Validation Steps: I’ve also added wild card support for reading configuration, the following wild cards are supported, let me know if there are others you’d like to see supported: For example, for the test step configuration below: <TestStep assemblyPath=”” typeName=”Microsoft.Services.BizTalkApplicationFramework.BizUnit.FileCreateStep”> <SourcePath>..\..\..\TestData\InDoc1.xml</SourcePath> <CreationPath>..\..\..\Rec_03\TransactionId_%Guid%_%ServerName%.xml</CreationPath> </TestStep> CreationPath becomes “..\..\..\Rec_03\TransactionId_12345678-D6AB-4aa9-A772-938972E3FD51_ZEUS001.xml“ If you’re new to BizUnit here’s a brief overview of how it works… Test Case Format A test case is made up of three stages, test setup, test execution and test cleanup, the cleanup stage is always executed (even if the main execution stage fails) and intended to leave the platform in the same state that it started. Each stage may consist of zero or more test steps, test steps are in general autonomous, state can be flowed between them if required using the ’context’ object that is passed to each test step by the framework. BizUnit also has the notion of TestGroupSetup and TestGroupTearDown, these are test cases that are executed at the begginning and end of a suite of unit tests. The diagram below illustrates the format of a test case.
In case you’re not aware, BizUnit is a declarative test framework targeted at but not restricted to the automated testing of BizTalk solutions. BizUnit is fully extensible, v2.0 has had over 2077 downloads to date and there are many customers world wide using it to drive up the quality of their BizTalk solutions. Its approach is to enable test cases to be constructed from generic reusable test steps, test cases are defined in XML which allows them to be auto-generated and also enables the ’fixing up’ of Url’s for different environments, e.g. test, staging and production environments.
This version adds some additional test steps:
In addition to test steps, BizUnit has the notion of validation steps and context loader steps. These can be thought of as sub-steps and can in general be independantly executed from any test step. For example, an MSMQ-read step might be used to read and validate both Xml and Flat File data from a queue, the same step can be used with both the RegExValidationStep and the XmlValidationStep to validate the data read.
A test step within a test case can be marked with the attribute – runConcurrently which causes subsequent test steps to be started before it has completed. In addition test steps maybe marked with the attribute – failOnError, setting it to false cause BizUnit to ignore a failure of that test step, this is particularly useful for the setup and cleanup stages of test cases.
Lets look at an Example Scenario…
BizUnit takes a black box approach to testing solutions, if you look at the scenario below, a BizTalk solution receives a request-response message over HTTP, the message is routed to an Orchestration which, sends a message to MSMQ and another to a FILE drop, the Orchestration waits for a FILE to be received, after which the Orchestration sends the response back to the waiting HTTP client. The solution also uses BAM, writing business data to the BAM database.
In order to test this scenario, a BizUnit test case is defined that has 5 test steps:
- The HttpRequestResponseStep sends the request to the two-way receive port and waits for the response. This step is executed concurrently so that the other test steps may execute whilst it waiting for the response
- The MSMQReadStep waits for a message to appear on an MSMQ queue, when it reads the message it uses the XmlValidationStep to perform schema validation and also execute a number of XPath expression to ensure the message contains the correct data
- The FileValidateStep waits for a FILE to be written to a given directory, when it reads the FILE it validates the data using the RegExValidationStep validation step since the FILE picked up was a flat file format
- The FileCreateStep creates a new FILE in the specified directory containing the data that the backend system would typically create. This allows the Orchestration to complete and send the response back to the waiting HttpRequestResponseStep step
- Finally, DBQueryStep is used to check that all of the BAM data has been successfully written to the BAMPrimaryImportDB
Finally, I’d like to give a big thanks to the following who have contributed new steps, ideas, etc to this version of BizUnit, my apologies if I have missed off anyone, it’s not intentional just my disorganisation!, please let me know if that is the case and I’ll add you:
Jon Fancey
Mike Becker
Tanveer Rashid
Young Jun Hong
If you find bugs, have new steps or ideas/requirements for new features that you’d like incorporated let me know.
Enjoy!
BizUnit 2006 is Released – BizTalk 2006 and Visual Studio 2005
I’ve finally got around to finishing off BizUnit 2006 – v2.1 just in time for the BizTalk 2006 GA, this version is targeted at BizTalk 2006 and Visual Studio 2005 and is built using .Net 2.0. I’ve been using the new unit testing capability in Visual Studio 2005 to drive BizUnit for a while now instead of NUnit and have to say I’m pretty pleased with it.
And some new Validation Steps: I’ve also added wild card support for reading configuration, the following wild cards are supported, let me know if there are others you’d like to see supported: For example, for the test step configuration below: <TestStep assemblyPath=”” typeName=”Microsoft.Services.BizTalkApplicationFramework.BizUnit.FileCreateStep”> <SourcePath>..\..\..\TestData\InDoc1.xml</SourcePath> <CreationPath>..\..\..\Rec_03\TransactionId_%Guid%_%ServerName%.xml</CreationPath> </TestStep> CreationPath becomes “..\..\..\Rec_03\TransactionId_12345678-D6AB-4aa9-A772-938972E3FD51_ZEUS001.xml“ If you’re new to BizUnit here’s a brief overview of how it works… Test Case Format A test case is made up of three stages, test setup, test execution and test cleanup, the cleanup stage is always executed (even if the main execution stage fails) and intended to leave the platform in the same state that it started. Each stage may consist of zero or more test steps, test steps are in general autonomous, state can be flowed between them if required using the ’context’ object that is passed to each test step by the framework. BizUnit also has the notion of TestGroupSetup and TestGroupTearDown, these are test cases that are executed at the begginning and end of a suite of unit tests. The diagram below illustrates the format of a test case.
In case you’re not aware, BizUnit is a declarative test framework targeted at but not restricted to the automated testing of BizTalk solutions. BizUnit is fully extensible, v2.0 has had over 2077 downloads to date and there are many customers world wide using it to drive up the quality of their BizTalk solutions. Its approach is to enable test cases to be constructed from generic reusable test steps, test cases are defined in XML which allows them to be auto-generated and also enables the ’fixing up’ of Url’s for different environments, e.g. test, staging and production environments.
This version adds some additional test steps:
In addition to test steps, BizUnit has the notion of validation steps and context loader steps. These can be thought of as sub-steps and can in general be independantly executed from any test step. For example, an MSMQ-read step might be used to read and validate both Xml and Flat File data from a queue, the same step can be used with both the RegExValidationStep and the XmlValidationStep to validate the data read.
A test step within a test case can be marked with the attribute – runConcurrently which causes subsequent test steps to be started before it has completed. In addition test steps maybe marked with the attribute – failOnError, setting it to false cause BizUnit to ignore a failure of that test step, this is particularly useful for the setup and cleanup stages of test cases.
Lets look at an Example Scenario…
BizUnit takes a black box approach to testing solutions, if you look at the scenario below, a BizTalk solution receives a request-response message over HTTP, the message is routed to an Orchestration which, sends a message to MSMQ and another to a FILE drop, the Orchestration waits for a FILE to be received, after which the Orchestration sends the response back to the waiting HTTP client. The solution also uses BAM, writing business data to the BAM database.
In order to test this scenario, a BizUnit test case is defined that has 5 test steps:
- The HttpRequestResponseStep sends the request to the two-way receive port and waits for the response. This step is executed concurrently so that the other test steps may execute whilst it waiting for the response
- The MSMQReadStep waits for a message to appear on an MSMQ queue, when it reads the message it uses the XmlValidationStep to perform schema validation and also execute a number of XPath expression to ensure the message contains the correct data
- The FileValidateStep waits for a FILE to be written to a given directory, when it reads the FILE it validates the data using the RegExValidationStep validation step since the FILE picked up was a flat file format
- The FileCreateStep creates a new FILE in the specified directory containing the data that the backend system would typically create. This allows the Orchestration to complete and send the response back to the waiting HttpRequestResponseStep step
- Finally, DBQueryStep is used to check that all of the BAM data has been successfully written to the BAMPrimaryImportDB
Finally, I’d like to give a big thanks to the following who have contributed new steps, ideas, etc to this version of BizUnit, my apologies if I have missed off anyone, it’s not intentional just my disorganisation!, please let me know if that is the case and I’ll add you:
Jon Fancey
Mike Becker
Tanveer Rashid
Young Jun Hong
If you find bugs, have new steps or ideas/requirements for new features that you’d like incorporated let me know.
Enjoy!
Symmetric Encryption/Decryption Pipeline Components
I just finished with an initial implementation of a custom encryption/decryption pipeline
component for BizTalk Server 2006, which supports all the symmetric cryptography algorithms
included with the .NET Framework’s System.Security.Cryptography package: RC2, Rijndael,
DES and 3DES.
Included in the component are both an encoder and decoder pipeline components so that
you can both encrypt and decrypt messages from your custom pipelines. The encoder
component does its work in a fully streaming fashion, while the decoder component
decrypts into an intermediate in-memory buffer for now (see this for
the reason).
For both encoder/decoder components, you just have to configure two different properties:
- Algorithm: Specifies the symmetric crypto algorithm to encrypt/decrypt messages.
-
SsoConfigApp: Specifies the name of a Configuration Application in the Enterprise
Single Sign-On ConfigStore that contains the Key and Initialization Vector to use
for encryption/decryption. This way keys are stored securely inside the SSODB database.
Initially, I thought about using Jon Flander’s excellent
utility for storing configuration data in the SSO, but finally decided to code
my own to avoid external dependencies (something I usually try to do for pipeline
components as it makes deployment easier). Coding my own allowed me to also add a
few things that should simplify deployment somewhat.
I provide a sample WinForms application that you can use to create/open/update/delete
ConfigApps in the SSO to store keys and IVs securely. The application has the following
features:
-
The ConfigApp in SSO is created as a Config Store application, with two custom fields:
CryptoKey and CryptoIV. Both are stored as Base64-encoded strings. -
The utility uses WMI to query the names of the BizTalk Administrators Group and the
names of the user groups associated to each BizTalk Host. The admin and users groups
in the SSO application are set to these values. I take advantage to a feature
in SSO 3.0 which allows you to associate multiple groups as users of the SSO Application,
so this way you don’t need to create a new group just to have all application and
isolated hosts access to the configuration data. -
Both the Key and IV as entered as a long string of hexadecimal digits. If you don’t
want to write your own, you can use the Generate buttons to automatically generate
a Key/IV pair appropriate for the selected symmetric algorithm, which is done via
the GenerateKey() and GenerateIV() methods of the specified SymmetricAlgorithm-derived
class. -
Some basic validations are done on the key and IV you enter, such as ensuring it has
a valid length according to the selected algorithm.
You can download the code for this component here.
Included in the solution are both the pipeline component and the Winforms configuration
application, as well as a messaging-only sample use of both encoder and decoder components.