izTalk 2004 Server is an enterprise-class application from Microsoft designed to make the integration of disparate systems as easy as possible. It is a suite of tools that gives you flexibility in integrating and orchestrating your workflows, rules, and data translations. It allows you to program both short- and long-term business logic and business processes. This capability is known as Business Process Automation, or BPA.

BizTalk is at the forefront of the next generation of enterprise development?externalizing the workflow, rules, and logic of your system, allowing them to be defined in a declarative manner using a language such as BPEL, or in a visual manner using tools such as the BizTalk Orchestration Designer. This externalization is important on many fronts:

First, it allows for a greater interaction and understanding between the business side of your company and the development side. Traditionally a business analyst conceives of an application and describes it as best he can. Then a systems analyst or architect does his best to understand these requirements and translate them into entities that can be built using code. Finally a developer takes these entities and codes them to spec. In the ideal case the process is smooth, and there is no disjoin from one end to the other. But the ideal case rarely happens; friction between the business and the development sides is common in most industries.

Second, it allows for greater clarity in understanding the business process itself. Typically, the requirements created by the business analyst are realized in a compiled application that appears to do what it’s supposed to do. But nobody but the development team really understands what is going on under the hood. The test plan and its results are the only evidence anyone has that the system has truly satisfied all the requirements. When the business process can be developed declaratively both sides work more collaboratively in the process, and their confidence changes into the ability of the runtime engine to implement that process correctly.

Third, it allows for greater ability to change and debug the process. Generally, when an application written in a high-level language, such as C# or Java, needs to be changed, you go in and change the code to behave according to the new requirements. Over time and with many changes from many hands, the codebase can become completely disjoined from the original business requirements. It is difficult for a business analyst, who understands the requirements to understand the code, and likewise it is difficult for a coder to understand the business needs. If the process is built declaratively, in a language that both developers and analysts understand, then changes are much easier to manage.

When the process and rules can be described to a run time engine instead of programmed in code a lot of these problems go away. This is the purpose of XML schema such as BPEL (Business Process Execution Language) and RuleML (Rules markup language) and the engines that implement them.

To date, BPEL is implemented with Microsoft BizTalk, IBM WebSphere, and BEA WebLogic as well as a number of open source platforms. At the time of this writing, BEA is considering open sourcing its implementation of BPEL4J. This would result in a widely distributed Java runtime that parses and executes BPEL.

But this article is about another BPA engine: Microsoft BizTalk 2004. BizTalk has long been the leader of the BPA pack, adapting standards such as BPEL4WS (BPEL for Web Services) ahead of its competition, and having tight integration with Visual Studio. For the rest of this article I will explain how to use BizTalk to generate and automate a simple workflow and rules-based application.

The Application

Figure 1. Workflow for the System: The application executes the trade automatically only if there are 5,000 or fewer shares involved in the transaction.

The sample application for this article will automatically execute low-dollar stock trades for a financial services firm or a brokerage. The premise is that traders and analysts do not need to process and verify every trade, just the major ones. How a small trade executes is a flow, and how the trade is evaluated for execution is based on a rule. In this case the rule is that if the trade involves more than 5,000 shares it is passed to the broker’s terminal for approval; otherwise the system executes it automatically.

The process flow for the sample application logic is diagrammed in Figure 1.

As an enterprise-class server product, BizTalk enforces strong security policies. So the first step is to create a strong name assembly key file. To do this, open the Microsoft Visual Studio.NET command prompt, and changing to the directory in which you are going to build the project. For this example, I created a directory named DevXBT.

When you are in the directory, issue the following command at the prompt:

sn --k DevXBT.snk

Figure 2. Visual Studio.NET Containing the Schema: Put the two schemas for the sample app in your project folder in Visual Studio.

You should receive a message stating that the key pair was written to DevXBT.snk.

Create three new folders in the DevXBT directory, called In, OutSystem, and OutBroker. These will be used later.

In the next step you will create the data schema associated with the solution. For the purpose of simplicity, the order entry and allow trade will be one schema, and the order denied will be another, so there will only be two schema in the system.

Create a new ‘Empty BizTalk Server’ project in the DevXBT directory, and call it ShareTraderSchema. Add two new schema to the project and call them MakeRequest and DenyRequest. The download with this article contains the schema, which have very simple structures (see Figure 2).

Setting Up the Pipelines
BizTalk uses the concept of a pipeline for a method of transferring data from one point to another. A pipeline prepares messages for processing after being received or before sending. In this case, we will simulate notifying the broker by converting the XML of the trade request into a flat file that would get written to his terminal. The terminal would process this flat file adding a user interface that allows the broker to accept or reject the trade. Systems such as this one would then have an Order Execution System to carry out the actual trade. Generally this would accept the same file format, so this conversion serves a dual purpose.

To create a send pipeline, simply right-click the ShareTraderSchema project in Solution Explorer, select Add New Item, and select Send Pipeline. Call it SendTradeRequest.btp.

You will see the pipeline designer on the screen. It has three stages: Pre-Assemble, Assemble, and Encode. You can add logic to each of these steps to take some action on the data in these three steps. For now, you just want to convert the output to a flat file, so you drag the item ‘Flat File Assembler’ from the toolbar onto the Assemble drop target.

Connecting the Schema

Figure 3. Link the Schema: The BizTalk Mapper is used to translate and link the source schema with the destination schema.

You inform BizTalk of the relationship between the documents by connecting their schema. You will notice that the two schema we defined earlier both have a tradeID field, so we will use this to connect them logically. You do this using the BizTalk Mapper.

Add a new Map item to your project and call it MapDenyRequest.btm. When you have done this, you will see Visual Studio open the file with an area for the Source Schema on the left, the Destination Schema on the right, and the Mapper Grid in the center. Add MakeRequest.xsd as the source schema, and DenyRequest.xsd as the Destination schema. Expand both schema and drag the TradeID field from the Source Schema to the Destination Schema. You have now linked the two (see Figure 3). Now drag CustomerID from the Source to CustomerID on the destination to connect the data between them.

You are now ready to build your project into a DLL resource file that the final system will use for the schemas, the pipeline, and the file mapping. Before building, you have to associate your DLL with the Assembly Key file that you created earlier. To this, select the project, right click, and select Properties. On the Property pages for the project, select Assembly, find the property called Assembly Key File, and set it to the DevXBT.snk file that you created earlier. You can now build your solution.

Building your Workflow

Figure 4. Trading Along: The Workflow for the ShareTrader application is shown, but exclamation points indicate that it’s incomplete.

The workflow is the heart of your application. Here is where you visually design the flow of the system, and describe the logic that each step will follow. The BizTalk Orchestration designer is the main tool for this. You will be building the workflow as a DLL that consumes the schema and pipelines that you built earlier, so you will need a second project in your solution to handle this. To do this, select the ShareTrader solution and select Add followed by New Project. In the dialog box select Empty BizTalk Server Project and call it ShareTraderWorkflow.

Add a new item of type BizTalk Orchestration to the project and call it ShareTraderWorkflow.odx. The workflow designer will open, showing the workflow in Figure 4.

You will notice the exclamation mark on a number of the shapes within this workflow. This simply denotes that the configuration is incomplete. In the next step you will complete these fully.

The documents that fuel this workflow are in the schemas DLL that you constructed earlier, so, from this project you need to reference them. To do this you open the references node of the ShareTraderWorkFlow project and select Add Reference. On the Projects tab you then double click ShareTraderSchema to add it to the selected components list. Click OK to exit the dialog.

You will now assign instance variables based on the contents of the schema to the workflow orchestration by creating BizTalk Message Instance Variables with the designer. To do this, select the Orchestration View tab beside the Solution Explorer. Right-click Messages, and select New Message. A message called Message_1 will be created for you. Change its Identifier property to RequestTradeInstance. On the MessageType property, expand Schemas and then choose Select from Referenced Assembly. A dialog will appear. On this dialog, select the MakeRequest schema you built earlier. Repeat this process for a message called DenyTradeInstance, mapped to the DenyRequest schema.

Interfacing with the Rest of the World
BizTalk interfacing is done through ports. The workflow has three interfaces to the outside world, the input interface to get the trade request and the output interfaces for sending the request to either the broker or the trading system. To keep this example relatively simple, the file system will be used as the interface, namely if a file is dropped in a specific directory, the GetRequest port will intercept and handle it, and the output to the broker or the trading system will be simulated by outputting the flat file to the relevant directory.

To configure the ports you drag the Port shape from the toolbox to the Port Surface area on the workflow. The Port Configuration wizard will launch. For the first port use the following settings:

Name: PortGetRequest
Port Type: Create New
PortTypeName: GetRequestPort
Communication Pattern: One Way
Access Restrictions: Internal
Direction: Always receiving
Binding: Specify Now
URI: C:DevXBTIn
Transport: File

On the GetRequest shape, set RequestTradeInstance as the Message and PortGetRequest.Operation_1.Request as the operation.

Drag another port to the port surface. On the wizard, use the following settings.

Name: PortSendToTradeSystem
Port Type: Create New
Port Type Name: SendToTradeSystemPort
Communication Pattern: One Way
Access Restrictions: Internal
Port Direction of Communication: Always Sending
Port Binding: Specify Now
URI: C:DecXBTOutSystem
Transport: File

On the SendMessageToSystem shape, set Message to RequestTradeInstance and set Operation to PortSendToTradeSystem.Operation_1.Request. Repeat these steps for PortSendToBroker and attach it to the SendMessageToBroker shape in the same way you did for SendMessageToSystem. Make sure the URI is C:DevXBTOutBroker to send the file to the different directory.

At this point you will notice that the ConstructMessage_1 shape still has an exclamation mark on it, showing that it hasn’t been properly configured yet. In a real system you may have to translate the message from the GetRequest schema to a specific one used by the trading system. You would do that by amending this shape and associating it with a map. For now you are building a simple passthrough so you can delete the shape.

Finally you will notice that the SendToSystem shape to the left of the branch still have the exclamation icon mark on it, showing that it isn’t fully configured. What hasn’t yet been entered is the Rule that we specifie?if the deal is for less than 5,000 shares we let the system handle it. This is done using the XLANG language.

Select the exclamation mark smart tag and you will be presented with an option to edit the expression in the expression editor. Type the following:

RequestTradeInstance.Body.Number < 5000

Finally on the GetRequest shape, set the Activate property to True.

You can now build your solution. Don’t forget to set the Strong Name assembly key file property on the Property pages for the workflow project.

Deployment
Your BizTalk solution needs to be added to the BizTalk deployment database and to the Global Assembly Cache. You do this using the BizTalk Deployment wizard, which is in the BizTalk Start menu folder. The BizTalk runtime reads your compiled logic from these locations.

When the deployment wizard starts, skip the welcome screen to the Deployment Task screen and select ‘Deploy BizTalk Assembly to Database.’ On the next screen accept the default settings and click Next. The next screen asks you to identify the BizTalk assembly file, so browse to the schemas project that you created earlier and find ShareTraderSchema.dll. Make sure that ‘Install Assembly to the GAC on this Computer’ is checked. Click Next twice to finish the wizard.

Run the wizard a second time, performing exactly the same steps to install ShareTraderWorkflow.DLL.

Running the Orchestration
Running the application isn’t quite as easy as it sounds! The concept is that you are configuring a running service on the computer, and as such you follow two steps: enlisting, which means you are informing BizTalk that you will be using this service frequently, and starting, which is the actual process of running it!

To run your application you use the BizTalk Administration console, which is found in the BizTalk Start menu folder. On the BizTalk Server 2004 (local) node, open hosts and select BizTalkServerApplication. If the server (your computer) in the right pane isn’t running, right click it and select Start.

Select the Orchestrations folder. You should see the ShareTraderWorkflow.Orchestration_1 on the right-hand side. Right-click it and then select Enlist. Accept all the defaults on the wizard.

Now select the Send Ports folder. You should see the two workflow send ports on the right. Right-click each and select Enlist, and then again right-click each and select Start.

Go back to the Orchestrations folder. Now you can select the ShareTraderWorkFlow orchestration and select Start Processing.

Your first BizTalk application is now running. To test it, simply create an instance document of the RequestTradeSchema, fill it in with some meaningful data and copy it to the In folder. Depending on the value of the field, the BizTalk engine will pass it either to the broker’s folder or the system folder.

This may seem like a lot of work for a very simple task, but you have touched on most of the main points of BizTalk in building this application. The documentation that comes with the server will help you build on this example to do real world, enterprise systems. For example you can replace the file system used in this example with Web services calls to do multiple transforms.

As an exercise, see if you can build a Web service that returns the acceptance or denial from the broker, and pass the request denied back to the user or the accepted trade on to the system. The schema and mapping have already been set up for you. Have fun!