 | Level: Intermediate Joshy Joseph (joshy@us.ibm.com), Software Engineer, IBM
Ken Beck (kabeck@us.ibm.com), Managing Consultant, IBM
Germán Goldszmidt, Ph.D., Senior Technical Staff Member, IBM
28 Dec 2004 Part 3 of this series introduces a method and techniques for graphically modeling a business process using IBM® WebSphere® Business Integration Modeler V5.1 for the generation of artifacts you can use in the development environment. The authors provide guidelines for conducting an iterative modeling method, a step-by-step process modeling method with the identification and listing of tasks, sequencing of tasks, creation of flow controls between tasks, introduction of data into the model, and the integration of services into the process model. They also give a description of the export options and the generated artifacts you can use as input to the development tools described later in this series.
Introduction
This series is based on work related to a real on demand transformation
project, Oneida-2, as described in the series overview paper, "On demand business process life cycle, Part 1" (see Resources). This specific article of the series focuses on one aspect of this life cycle: the design of a
Business Process (BP) model. In Elements of Business Process modeling (forthcoming), we introduce the basic
concepts of process modeling using WebSphere Business Integration Modeler. In this paper we describe the
details of modeling using the Order to Manufacturing Processing System
(OTMPS) scenario described in the series overview article.
We follow a series of steps for modeling the OTMPS. Note that several iterations
might be needed to make the model most useful for development.
Gather Business Process requirements
In this scenario, a business needs to automate the
order process taking advantage of IBM® WebSphere® Business Integration Server Foundation's Process
Choreographer. This lets you modify the automated process much more
quickly in the on demand environment. By creating a model of the process in
the WebSphere Business Integration Modeler, the information that the business analyst captures about how
the process works can be exported for use by the workflow developers in
Websphere Studio Application Developer Integration Edition. The
business analyst identifies the following core activities in this scenario:
- Receive orders
- Validate the orders with external validation services
- Document invalid orders and inform the operators
- Send valid orders to the appropriate manufacturing plants.
The next step is to identify and model the data elements such as incoming
orders, manufacturing data, and validation data. These data items can be input
and/or output to activities, repositories, processes, or services.
Modeling business items
We step through how to create business items, business item templates, and business item
instances.
Figure 1. Data catalog and business item
Figure 1 shows a data catalog called manufacturing for organizing all
manufacturing-related data models, such as orders and order status. The
creation of a data catalog is optional; otherwise you can create the data models in a default Business items data catalog that WebSphere Business Integration provides.
The business items are created and added to an existing data catalog. For
example, Figure 1 shows an "Orders" business item with its attributes
such as "orderItems," "mfgNum," and "valid". These attributes could be simple types
(for example, String, Integer, and Boolean) or could be business items from the same or a
different data catalog. The "Orders"
business item includes an "orderItems" attribute of type "OrderItem" from the
same data catalog.
Instead of creating business items, it is possible to import existing XSD schemas into WebSphere Business Integration Modeler before the modeling process. For each XML schema, one data catalog is created, and the content of the schema is mapped to elements of the data catalog, such as business items and templates.
Modeling services
In WebSphere Business Integration Modeler, services are defined as external entities (outside the process
being modeled) that can be used from within the organization's processes. In the
OTMPS scenario we are interacting with external services such as the Validate &
Generate Topology service and Manufacturing service.
Figure 2. A service creating wizard
|
What is a process diagram?
A process diagram is a graphical representation of a BP flow, consisting of
activities and the connections between them. A WebSphere Business Integration Modeler process editor is
used to visually compose a process flow, using elements that you drag and drop
from the palette or from the project tree.
A process diagram can contain pre-defined processes, tasks, repositories, and
services, which you can drag and drop from the project tree.
In addition, a process diagram contains other non-reusable elements, which you
can drag and drop from a palette, such as processes, tasks, repositories,
start/stop/end nodes, connections, forks, joins, loops, maps, decisions,
notification broadcasters, notification receivers, observers, timers, and
annotations.
|
|
Figure 2 shows a WebSphere Business Integration Modeler wizard for defining inputs
and output for an external service. The figure shows the
Validate & Generate Topology service with the input of type "Validate In."
Similarly, you could create the output messages from the service. In WebSphere Business Integration
Modeler, you can group a set of inputs known as an input criteria. Because we are
exporting to Business Process Execution Language (BPEL), you are restricted to having only one input criterion per
element. In a Web Services Description Language (WSDL) interface model (portType definition) this input
criteria and output criteria map to operation input message and output message
respectively.
In later steps of the modeling process, you will see how to create service invoke
tasks in a BP model.
Modeling business policies
Analysts might specify the intended policies as comments in natural language. In this sample scenario, you define a
policy for manufacturing plant selection. This policy enables business owners to
decide which manufacturing plant to use for specific orders. For example, a
policy might specify that orders with a value exceeding 1 million dollars should be
processed by certain manufacturing plants according to some priority criteria, such as turn-around time. Another policy might specify how to handle orders
when the preferred plant is not in production.
The analyst documents the policies in the comments field of each task. The
developers are responsible for converting the policies to rules. The analyst can add to the model service
elements that represent pre-existing services that provide enforcement points.
They might also add tasks to represent placeholders for code that enforces
policies. The developer adds the necessary code to implement the task, for example,
execute the correct rules. (Details forthcoming in Part 6 of this series, "Customization: Policies and Rules" -- see Resources).
Process model development
This section describes how to define the following process elements:
- Control flows
- Sub processes
- Policies
- Measurements
We describe the modeling method
starting with the following:
- Identification and listing of tasks
- Sequencing of the tasks
- Creation of flow controls between tasks
- Introduction of data into the process
- Integration of services within the process model
Create processes
|
Process diagram viewing
Swimlane view. Swimlanes are visually separated rows within a process diagram that group
activities by roles, resources, organization units, or locations. Swimlanes
visualize the activities that are performed by a specific type of resource, role, or
organization unit, or that are associated with a particular location.
Free-form layout. Free-form layout lets you edit the diagram and change the position of
elements within the diagram.
|
|
You access the WebSphere Business Integration Modeler features by selecting the Business Process
modeling perspective in Eclipse. You then create process catalogs, or folders, that help to organize process, task, service, and repository model
elements.
Figure 3. New process model creation dialog
Once a process catalog is created, the next step is to open the "Create a new
process" dialog box, as shown in Figure 3. The figure shows
two process catalogs, "Processes" and "Services". In this example you create a
BP called OrderProcessSystem in the "Processes" catalog. Afterward, you can
open this process in the WebSphere Business Integration Modeler process editor to complete the process
diagram (see the sidebar What is a process diagram?).
Figure 4 shows the empty process editor. There are two types of views
enabled in the process diagram: Swimlane view and Free-Form layout (see
the sidebar Process diagram viewing for more details). Here you use a
free-form layout diagram.
Figure 4. An empty process diagram
Figure 5 illustrates a completed process segment for Order Process
Subsystem in WebSphere Business Integration Modeler V5.1. This simple model illustrates the flow of orders
through validation and manufacturing. The model integrates a validation service
partner, through the Validate & Generate Topology service invoke step.
Figure 5 shows a decision point, "validation successful?", two data
format conversion tasks, local data repositories to store customer orders for later
use in the process, and a process loop to select and forward orders to the correct
manufacturing plant.
Figure 5. Business Process Model for OTMPS
Figure 6 shows the contents of the while loop
(Manufacturing Loop). This model illustrates a policy enforcement point in the
process flow using the Apply manufacturing Plant Selection task and a
manufacturing plant service invoke step.
Figure 6. BP Model -- subprocess model for Manufacturing Loop While Loop in OTMPS
In the following sections we explain how we completed the model as illustrated in
Figure 5 and Figure 6.
Create tasks
In process modeling, tasks are the lowest level of activity. For example, in Figure 5, Data Format Conversion is a task with the responsibility of converting
purchase order messages to validation service messages. A task cannot be
further decomposed. Each task specification expects input, output, and the
resources necessary to complete the task. The Data Format
Conversion task receives the "Orders" business item as input, and outputs the
"Validate In" business item. The developer later adds the business logic implementation of this task. For example, when the above task is converted to BPEL, the task becomes an invoke method in the BPEL process.
The generated WSDL file for the Order Process Subsystem contains a
portType with the operation as shown in Listing 1.
Listing 1: WSDL portType definition for data format conversion task
<portType name="DataFormatConversionPT">
<operation name="sendDataFormatConversion_InputCriteria">
<input message="tns:InputCriteriaMessage"
name="InputCriteriaMessage3"/>
<output message="tns:OutputCriteriaMessage3"
name="OutputCriteriaMessage3"/>
</operation>
</portType>
|
|
Expression Builder
The Expression Builder is used to write the expression by selecting types and
specifying values for the terms of the expression. Types can be: Boolean, Date,
Date/Time, Duration, Function (Contains-the-text, Starts-with-the-text, Select,
Every, At-least-one, Get-all, Sum, Count), Modeling artifact, Negation, Not,
Number, Sub expression, Text, or Time. Terms are combined with operators:
AND, OR, is equal to, is not equal to, is greater than, is greater than or equal to,
is less than, is less than or equal to, +, -, x, /, mod, is before, is after, +duration,
or -duration.
|
|
The developer later generates the service implementation code for the above
portType and adds the necessary implementation code. Details on this are
forthcoming in Part 5 of this series, "Workflow development, deployment, and testing" (see Resources).
Create loops
A loop describes a repeating sequence of activities contained within a process.
Figure 6 shows a while loop (Manufacturing Loop) that iterates over
each order, selecting the correct manufacturing plant and submitting each order
to the selected manufacturing plant. A while loop is a loop that repeats the
included activities while some condition is satisfied. This condition is specified
through a formal expression created using the Expression Builder (see the sidebar Expression Builder).
Figure 7. Expression Builder
As shown in Figure 7, Modeling artifact with value
"Processes.OrderProcessSystem.Control Data.Order
Count" is selected for the first term. Then the operator "is greater than" is
selected and finally the type "Number" with value 0.0 is selected for the last term.
This produces the expression: "Processes.OrderProcessSystem.Control Data.OrderCount' is greater than 0.0," which can then be output in the BPEL file. Listing 2 shows this while
loop and the corresponding condition.
Listing 2: Exported BPEL with while condition
<while condition="DefinedByJavaCode" name="ManufacturingLoopInputCriteria"
wpc:displayName="Manufacturing Loop">
<wpc:condition>
<wpc:javaCode>
<![CDATA[return
((getControlDataVariable().getControlDataPart().getOrderCount()) > (0.0));
]]>
</wpc:javaCode>
</wpc:condition>
. . .
|
Add decision points
A decision routes inputs to one of several alternative outgoing paths based on
successful evaluation of the condition to "true." A simple decision has one
incoming branch with one input and two outgoing branches with one output each.
At run-time, the process flow takes one outgoing branch if a certain condition is
true and the other branch if the same condition is false. Figure 5 shows a
simple decision point, "Validation Successful?", which takes the "service output"
business item, checks whether validation is successful, and then selects a path
to continue with the order processing or quits the execution process.
This condition is specified through a formal expression created using the
Expression Builder.
Sequencing
Connectors are added between the elements to cause them to start at the proper
time. The logic for elements having multiple connectors is controlled by their
Input Criteria. The analyst uses business rules and data precedence
requirements to determine the order of the elements in the sequence.
Create repositories
A process might store data and later use that data while processing. In WebSphere Business Integration Modeler this data storage mechanism is called a repository. This concept is similar
to variables in programming languages. Every repository has a name and an
associated business item type. The two types of repositories are local and global.
Local repositories are owned by a process and can only be used by elements in
that process. These data elements are available until the process ends. Global
repositories are created at the project level and are accessible to multiple
processes. Our discussion focuses only on the local repository because global
repositories are not supported for BPEL execution.
Figure 5 shows three local OTMPS repositories:
- Orders Repository, which holds "order" business items.
- Subprocess Execution Control Data, which holds process execution "control" data.
- Manufacture Data Input Repository, which holds "manufacturing input" data.
In our example we used
repositories to store business items (orders, control data, and manufacturing
data) that are accessed inside the while loop (Manufacturing Loop), because
they cannot be passed on the connector. Listing 3 shows an example of
converting a local repository to a BPEL variable.
Listing 3: Order repository Java snippet and associated BPEL variable
Repository "Orders Repository" becomes a Java snippet and repository content
becomes a BPEL variable:
<variable messageType="wsdl:OrdersRepositoryMessage"
name="OrdersRepositoryVariable"/>
and could be accessed from the workflow using the expression:
getOrdersRepositoryVariable(true).
|
Associate business items with connections and local repositories
In a process model the data flows through the tasks. Business items or instances
can be associated with the connections from task to task. Figure 8 shows
a portion of the OTMPS model.
Figure 8. Business items associated with tasks and connections
Figure 8 shows a flow of control from the Order Process Subsystem task to
the Data Format Conversion task, and then to the Validate & Generate
Topology service. In addition the model shows data flow to local repositories. All
the tasks are connected using the connection tool from the palette (see
Sequencing). You then can associate the business items with the
connections. For example, the connection between the Data
Format Conversion and Validate & Generate Topology servicess shows an
associated business item "Validate In." The process of associating business
items with local repositories is done in the same way.
Once local repositories are created and connected to a task using a connector
tool, the business item is usually associated with the connection. For example,
Figure 8 shows a connection between the task Order Process Subsystem
and two local repositories. The first connection associates "Orders" data with the
repository Orders Repository, while the other associates Controller Control
Data with the repository Subprocess Execution Control Data.
Note that while in WebSphere Business Integration 'Basic' mode, if the elements being connected already
have business items assigned to their inputs and outputs, then a dialog box (see
Figure 9) is displayed while drawing the connection between elements.
The dialog box provides the option of selecting the existing input or output, or a
new input or output can be created.
Figure 9. Data connection dialog
Integrate services and subprocesses into the process model
Service and sub-process elements are added to the process in the same way that other elements are added. Services are not selected from the palette, but are created (as described Modeling services) and then dragged from the project
tree because they are reusable elements. Services export to BPEL in the same
way as tasks, except that each service has its own WSDL file.
As a best practice, any known information about an existing service being
modeled should be added to the service's description field. This information might
include the service description, binding choice, discovery mechanisms, and
deployment options. This description guides the developers to create the
necessary discovery, binding, deployment and integration code.
Sub-processes are used to hide detail in the model and export to BPEL as
scopes with a flow structured activity. In BPEL, scopes allow defining a nested
activity with its own associated variables, fault handlers, and compensation
handler.
Map elements
Map elements are used to convert the data format between different structures,
for example, whenever the data formats between consecutive elements are incompatible.
In the executable BPEL workflow they appear as Java snippets. As shown in
Figure 5, a map element is added at the end of the process to convert the
business item "Service Output" to "OrderProcessResponse".
KPI and measurements
BP monitoring capabilities allow the process owners and administrators to
monitor the BP Key Performance Indicators (KPIs) in real-time. In the OTMPS
scenario the analyst might define a KPI and add observation points to the
corresponding task or process.
Figure 10. KPI and observation points
For example, Figure 10 shows a KPI "Number of orders received each
hour" and the corresponding observation points. In the figure we selected
Input Criteria and Output Criteria as observation points. This KPI is associated
with the Order Process Subsystem task in the process model. The details on
how these KPI definitions and observation points are implemented are forthcoming in Part 7 of this series, "Business Process monitoring using CEI" (see Resources).
Process model validation and export
Placing the modeler in BPEL mode turns on the BPEL validation checker. Any errors or warnings appear in the Error View. The model can be exported with errors, but these should be fixed eventually so that rework is not required on future exports. Once the process model is ready, the analyst exports the required BPEL, XSD, and WSDL files for WebSphere Studio Application Developer Integration Edition, either to an existing service project or to a folder for later importing to a service project. For details on the generated files and the relationship between the process model elements and the corresponding artifacts in the generated files, watch for the forthcoming paper, "Elements of Business Process modeling."
Conclusion
On demand business processes are modeled in a top-down approach and
implemented following a Service-Oriented Architecture (SOA). Top-down
modeling by a business analyst is a key element of the on demand business
process life cycle methodology. The BP model defines the technical framework to
align business specifications with IT development. A shared model is preserved
over the lifetime of the business process, helping to keep the business and IT
views synchronized. This paper described techniques and guidelines that
analysts can use to define on demand business processes using WebSphere Business Integration Modeler V5.1.
Acknowledgements
The authors would like to thank Samantha Shurety for reviewing an early draft of this article.
Resources
-
Read all parts of the On demand business process
life cycle, and keep track as we add new installments.
-
Read the specification Business Process Execution Language for Web Services, Version 1.1, May 2003.
- Learn about how you can use BPEL and the Java programming language together to build business process applications in the article BPELJ: BPEL for Java technology.
- Find answers to your questions in the
WebSphere Business Integration Modeler 5.1 FAQ.
- Browse the WebSphere Business Integration Library for executive briefs, Redbooks, and product documentation.
-
The article Elements of Business Process modeling (forthcoming) by Ken Beck, Joshy Joseph, and German Goldszmidt, provides valuable information on modeling concepts that analysts use to define business processes, and some of the features of WebSphere Business Modeler that support them.
- Get information about the On Demand operating environment from the following articles:
- Browse for books on these and other technical topics.
- Want more? The developerWorks SOA and Web services zone hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
About the authors | 
| | Joshy Joseph is a Software Engineer working with the IBM On Demand development organization. He is an architect and programmer with primary skills and expertise in the areas of distributed computing, grid computing, Web services, Business Process, and workflow development. He is the author of the book Grid Computing from Prentice Hall, 2003. In addition, he has written numerous technical articles about Grid computing, Business Process development, and Web services. |
| | | Ken Beck is a Managing Consultant working in the IBM Global Services
Application Management Services Business Transformation Center of
Excellence. He is currently assigned to the IBM BT/CIO Enterprise Component
Business Architecture group as a lead process designer developing methods for process model reuse. He has been with IBM as a Business Process Consultant since 1993.
|
| | | Dr. German Goldszmidt is a Senior Technical Staff Member working in the IBM Software Group, with focus on architecture of an integrated platform for delivering, customizing, and deploying on demand solutions. Previously, he was a researcher at the IBM T.J. Watson Research Center, and led the design and implementation of several technologies, including Oceano, the first prototype autonomic computing eUtility, and Network Dispatcher, the load balancer component of WebSphere. |
Rate this page
| |
