- Step 1: Determining the Interchange Goals and Objectives
- Step 2: Modeling the Business Process
- Step 3: Agreeing on Process Specifications and Parameters
- Step 4: Creating the Mapping Between Input and Output Data Formats
- Step 5: Configuring the Triggering Mechanisms to Process Information
- Step 6: Completing the Schedule for the Transaction Process
- Summary
Step 2: Modeling the Business Process
From the first step, we were able to interview the stakeholder(s) and/or the decision maker(s) to understand the business, technical, and operational goals and objectives of the organization. This information now needs to be modeled using the tools included with BizTalk Server to begin translating the process into code that can be run on the BizTalk Server.
This step involves identifying what needs to be processed, predicting what responses need to be returned, determining what events are sequential and what events trigger other events, and modeling the end-to-end information flow. This information is then entered in to a BizTalk Server tool called the BizTalk Orchestration Designer.
How to Describe the Business Processes
Key to the success of this step is translating the goals and objectives of the business into steps that can be followed methodically by the BizTalk Server. Effectively, a decision tree needs to be created where every yes/no or success/failure is identified, and appropriate loops are documented. If a group of planners is involved, this process may be done on a whiteboard.
If the organization already has a manual process that is desired to be automated, one big decision the organization needs to make is whether to mirror the existing process or rethink the entire process. Although an existing manual process might work fine, it might be laden with several steps that have no tie to any tangible function anymore. This might be a sign-off or verification process needed in a manual system but that can be bypassed in a fully automated system. It might be a process that involves checking or double-checking data entry information that might not be necessary in a single entry automated process. The business process steps need to be reviewed to determine whether they are necessary in an automated system.
Overview of BizTalk Orchestration
Unlike many IT-focused systems, BizTalk Server does not jump the organization straight from high-level business needs right into programming code. BizTalk Server includes a step called BizTalk Orchestration that allows an organization to define its business processes in a graphical format that can then be modeled and linked to more complex data processing models. This allows a separation between the definitions of a process and the implementation of the process. This enables different parts of the business process to be modeled by those who know the processes the best (the business-focused individuals). Those processes then are compared with the technical programmability parts of the process.
BizTalk Orchestration Designer
The tool that facilitates the modeling process is called the BizTalk Orchestration Designer. The tool is effectively a Visio modeling tool that provides a way for an organization to model its processes into a flowchart type drawing. This drawing is called an XLANG scheduling drawing. Most business managers understand the concept of BizTalk Orchestration Designer because they are familiar with flowcharts and flowchart processing, so having this orchestration design step helps to ensure that the technical process mirrors the expected business goals and objectives.
Note
Although a business manager usually understands flowcharting and will be able to review the models created in the BizTalk Orchestration Designer, typically a technical expert would be involved in the actual creation of the BizTalk Orchestration Designer model.
BizTalk Orchestration and the BizTalk Orchestration Designer are covered in more detail in Chapter 9, "Introducing BizTalk Orchestration."
Some of the BizTalk Orchestration Designer process options include Action, Decision, While, Abort, Fork, and Join. These options enable different flow routines to occur.
Action
An Action defines a process that typically requires information to be manipulated. It might be an action step that runs the information through a filter, or it might be an action step that reformats data being processed.
Decision
A Decision defines a process where a yes/no, data query, or other information analysis is conducted, and the result determines which branch to follow to continue with the workflow. It may be determined that if a field is blank to have a branch that enables an action to fill the field with data. However, if the field is not blank, then a branch would allow the process to continue.
While
The While object allows a process to loop until a specific event occurs. This might be a process that continues until the end of the dataset is reached, or it might be a process that continues until a specific data record is reached. A branch can then be followed to a subsequent decision or action.
Abort
An Abort object identifies a step where the process needs to be terminated. In many cases, the abort becomes a fail-safe test that determines that the information received is malformed, signaling data corruption in the transmission or just that incorrect data was transmitted. This step can provide a way to stop a process from continuing with incorrect information.
Fork and Join
A Fork splits a process to conduct simultaneous tasks that can then be Joined later in the process. This is frequently a process that enables information to be gathered for decisions to be made. For example, a fork in a process can be created to go out and gather price and availability information from multiple vendors. This information can be gathered and processed simultaneously. From this fork, when the information has been analyzed, the system can join back together to continue with the process.