Transforming business models to BPEL with WebSphere Business Modeler 6.02

IBM WebSphere Business Modeler (hereafter called Modeler) is a powerful tool for business analysts to accurately model their unique business processes. In addition, after the model is complete, they can export it to WS-BPEL. By generating useful artifacts for I/T, the business-driven development cycle saves time and ensures that the final process meets the needs of the business.

This article shows how Modeler transforms different constructs into WS-BPEL. The graphical representation of the WS-BPEL process for this article comes from IBM WebSphere Integration Developer (hereafter called Integration Developer).

You should have basic knowledge of Modeler and WS-BPEL

Share:

Introduction

Modeler is a powerful tool that can help with many tasks including:

  • Modeling for documentation and compliance: Many times a process is not well documented. Some companies want to capture the process just for the sake of documentation, while others need to do so for regulatory reasons.
  • Modeling for redesign: Some companies want to take their current state (as-is) processes, and improve them. Modeler provides a powerful simulation engine to help in this area, along with both dynamic and static reports for defining a future state (to-be) process.
  • Modeling for execution: Some companies want to implement a business-driven development cycle, where a business analyst can build a model that is used to create useful artifacts for IT. This model allows for faster development cycles, and ensures that the implemented process meets the business requirements.

When modeling for execution, after the business analyst has created the initial model, a resource from IT takes ownership of the model. The IT resource and the business analyst come to agreement on what the process is. At this point, the process is called the business contract, meaning that IT will use the process model as the basis for what they will deliver. If IT were to change what the process does, they would be breaking the contract with the business.

After the business contract has been established, IT can begin to enhance the business model with technical details. This technical information is used when the process is exported to WS-BPEL. However, Modeler hides these technical details from the business analyst who views the process in basic mode.

When the technical resource edits the process, they use WebSphere Process Server mode to expose the technical attributes. Modeler also provides another tab in this mode for the process technical specification, as well as a tab for the technical attributes view. Developers use these tabs to add the additional details to the process model.

This article shows you how the information in the business model gets transformed to WS-BPEL, the standards-based execution language for business processes (see the WS-BPEL specification). This article is based on WebSphere Business Modeler version 6.0.2.


Exporting a Modeler project

Modeler provides a variety of objects that you can use to create a business process model. These constructs can represent steps in the business process, the flow of control, data, resources, documentation, and more.

When you export the business process, the appropriate constructs are transformed into WS-BPEL, WSDL and XSD, providing useful artifacts for IT. However, some constructs in Modeler do not have an equivalent in WS-BPEL. In some cases, these constructs are ignored. In other cases you get an error or warning in the problems view. These objects are identified in the next section.

To export a Modeler project to WS-BPEL:

  1. Right-click on the project in the project tree.
  2. Select Export…
  3. Select WebSphere Process Server, and then click Next.
  4. Browse… to select a target directory.
  5. Click the check box for Module project name and enter a name for the module you are creating. The module is created in the current workspace.
  6. Optionally, click the check box for Library project name and enter a name. If you select a library for exporting, items such as XSDs which might be reused are placed into a library project. The module being created references the library.
  7. If you installed Modeler standalone, the check box for Project Interchange name is enabled. You can use this in place of exporting into the current workspace.
  8. If you want the process to generate events on the common event infrastructure, select Enable default events.
  9. Your Export window should now look something like Figure 1. Click Finish.
Figure 1. Exporting the Modeler project
Figure 1. Exporting the Modeler project

Local and Global Tasks

A task in Modeler is one of the most commonly used objects. It represents a step in the business process, whether manual or automatic. If several things are done by the same resource at the same time, they can all be grouped together as one single task.

It is important when modeling to consider the granularity of the tasks. If the tasks are too “fine grained”, the process model could become too complex to be of use. If the tasks are too “coarse grained”, the process can become overly simplified, so ensure that you use something in between.

Both local and global tasks in Modeler act the same way when exported. In this section we’ll look at how each type of task gets exported to BPEL.

Tasks for automatic activities

Tasks in Modeler that do not have a staff resource definition become invoke activities in WS-BPEL. It creates connections to and from the task for the invoke activity as well, as Figure 2 shows.

Figure 2. Tasks for automatic activities become Invoke activities
Figure 2. Tasks for automatic activities become Invoke activities

Tasks for human activities

If the resource definition for a task is set to Staff, you can control how the generated process handles human interaction. If the implementation type from the technical attributes view is set to Human Task, it generates a WS-BPEL invoke activity, along with a task for the human task manager in WebSphere Process Server, as Figure 3 shows. If the implementation type is set to None or the resource type is an individual, the generated task uses the IBM WS-BPEL extension for human tasks. This is also called an inline human task.

Figure 3. Human activity tasks
Figure 3. Human activity tasks

Tasks with multiple input criteria

The tasks we’ve examined so far all have one business item flowing in, and one business item flowing out. However, models can have multiple inputs to a task in the process. Each input might have its own input criterion, meaning that the task can start if any of the inputs flow in. This is controlled in the input logic tab, as Figure 4 shows:

Figure 4. Input logic tab
Figure 4. Input logic tab

For tasks that have multiple inputs, the generated WSDL has multiple operations, as in Figure 5:

Figure 5. WSDL for multiple input task
Figure 5. WSDL for multiple input task

To generate a WSDL with multiple operations:

  1. Select a task in Modeler by clicking it.
  2. From the Inputs tab, click Add to create a second input. Give the new input a name, and associate it with a business item, as Figure 6 shows:
    Figure 6. Adding new inputs
    Figure 6. Adding new inputs
  3. From the Outputs tab, click Add to create a second output. Give the new output a name and associate it with a business item.
  4. From the Input Logic tab, click Add to create a second input criterion.
  5. The default is to perform an AND operation on the input criteria, so that task will wait for both of them. In this example, only one at a time will ever be used, so change the AND to an OR. Click the check box so that the new input criterion is associated with the new input. Also unselect the check box so that the new input is no longer associated with the original input criterion, as Figure 7 shows:
    Figure 7. Specifying input logic
    Figure 7. Specifying input logic
  6. Tasks must have an equal number of input and output criteria. Repeat steps 4 and 5 from the Output Logic tab to add a new output criterion and perform an OR.
  7. From the Advanced Output Logic tab, click the new output criterion to select it. Click the check box for the new input criterion to associate the output criterion, as Figure 8 shows:
    Figure 8. Specifying advanced output logic
    Figure 8. Specifying advanced output logic

When exported, the generated WSDL for the task now includes multiple operations.

Generated reference and interface partners

Each invoke activity in a WS-BPEL process is associated with a reference partner link, defined using a WSDL file. Modeler generates this WSDL file, using the document-literal, wrapped-binding style. It also creates an interface partner link, defining how the process can be invoked. Partner links append “Partner” onto the name of the invoke activity, as in Figure 9. For invokes inside container activities such as a loop, the generated name is container activity name || invoke activity name || Partner.

Figure 9. Interface partner link
Figure 9. Interface partner link

Most IT organizations have standards, such as naming conventions that must be followed for WSDL files. To control what is generated in the WSDL, use the Technical Attributes View. For example, you can define the WSDL operation name for the request. If you do not fill in these fields, Modeler uses default names; e.g. it sets the generated port type name to the name of the task in Modeler.

Figure 10. Modeler Technical Attributes View
Figure 10. Modeler Technical Attributes View

Implementation types for Modeler tasks

Along with the WS-BPEL process, Modeler also generates SCA components for WebSphere Process Server. In the Implementation tab of the Technical Attributes View for each task, you can set the implementation type (Figure 11). If you keep the default [none], it generates an SCA component with no implementation type. In most cases, IT knows how the task needs to be implemented, and can select one of the implementation types.

Figure 11. Setting the implementation type
Figure 11. Setting the implementation type

State machine

For tasks where the implementation type is set to State Machine, Modeler generates a state machine with one state and one operation, as Figure 12 shows. The error icon appears because the generated state machine is incomplete. IT needs to define the details of the implementation.

Figure 12. State machine tasks
Figure 12. State machine tasks

Rule group

For tasks where the implementation type is set to Rule Group, Modeler creates an empty rule group, as Figure 13 shows. IT needs to implement the actual rules. The error icon appears because required information is not included with the generated rule group.

Figure 13. Rule group tasks
Figure 13. Rule group tasks

Human task

For tasks where the implementation type is set to Human Task, Modeler generates a human task, as Figure 14 shows:

Figure 14. Human tasks
Figure 14. Human tasks

If the resource definition is set to Staff, Modeler uses the resource information to set the potential owner, as Figure 15 shows. For example, if you defined a role Role 1 for your task, the generated human task sets the staffing verb to Role Members, and the Rolename attribute is set to Role 1. For individual resources, Modeler selects the staffing verb Users by user ID , and sets the userID attribute to the person ID.

Figure 15. Setting the potential owner for staff roles
Figure 15. Setting the potential owner for staff roles

Java task

For tasks where Java is selected as the implementation type, Modeler generates an SCA Java component. IT needs to edit the Java program and add the required business logic, as Figure 16 shows:

Listing 1. SCA Java component
package processes.process1;

import commonj.sdo.DataObject;
import com.ibm.websphere.sca.ServiceManager;

public class Task_0983731675Impl  {
/**
 * Default constructor.
 */
public Task_0983731675Impl() {
	super();
}
  /**
   * Return a reference to the component service instance for this implementation
   * class.  This method should be used when passing this service to a partner reference
   * or if you want to invoke this component service asynchronously.    
   *
   * @generated (com.ibm.wbit.java)
   */
	private Object getMyService() {
		return (Object) ServiceManager.INSTANCE.locateService("self");
	} 

/**
 * Method generated to support implemention of operation "InputCriterion" defined for
 * WSDL port type named "Task".
 * 
 * The presence of commonj.sdo.DataObject as the return type and/or as a parameter 
 * type conveys that its a complex type. Please refer to the WSDL Definition for more
 * information on the type of input, output and fault(s).
 */
public DataObject InputCriterion(DataObject Input)  {
		//TODO Needs to be implemented.
		return null;

}

}

Process task

For tasks where Process is selected as the implementation type, Modeler generates a WS-BPEL process, as Figure 16 shows. The process is empty, containing only a receive and reply located within a sequence container. If you want to specify the process logic, use a global process instead.

Figure 16. Process implementation type
Figure 16. Process implementation type

Global service and business service

A global service is a construct in Modeler where you can define a reusable business service. You can view the global service in the processes catalog from the project tree, and add it to the process using drag and drop.

A business service is similar to a global service, except that it comes from an imported WSDL file. It represents an existing service in the business. Modeler can also search the IBM WebSphere Service Registry and Repository to locate a business service.

When exported to WS-BPEL, both global services and business services become invoke activities. For a global service, Modeler generates a new WSDL. For a business service, it passes on the imported WSDL in the export.


Local subprocess and global process

A local subprocess is a container activity that you use to group together a series of tasks. A global process is simply a process from the project tree that you drag and drop into another process. You can reuse global processes, but can only use local subprocesses once, in the process where it is defined.

You can expand a local subprocess by clicking the + on its icon. When exported to WS-BPEL, it becomes a scope activity as Figure 17 shows. A scope is a container that holds one or more activities. WebSphere Process Server provides scope-based compensation. If you require scoped compensation in your process, use local subprocesses to define the boundaries of the scopes.

Figure 17. Local subprocess
Figure 17. Local subprocess

Modeler exports each global process as an independent WS-BPEL process, rather than a container inside of another process.


Simple decision and multiple-choice decision

Simple decisions have only two alternatives: yes and no. A multiple-choice decision can have two or more alternatives. You can use both to define the flow of control in a process. When using intermediate mode or higher in Modeler, you can define the logic for the decision using the expression editor.

Before exporting the process to WS-BPEL, you need to set one important attribute: In the technical attributes for the decision, check the box for Represent exclusive decision as BPEL Switch activity, as Figure 18 shows:

Figure 18. Setting exclusive decisions as BPEL switch activities
Figure 18. Setting exclusive decisions as BPEL switch activities

If you do not select the check box, Modeler places the logic for the decision on the connectors flowing out from the previous activity. The icon for the connectors shows a bulge with a diamond inside to indicate that there is associated logic, as Figure 19 shows:

Figure 19. Exclusive decisions represented as connectors
Figure 19. Exclusive decisions represented as connectors

If you select the check box, the generated WS-BPEL contains a switch activity, also known as a choice. Each branch in the decision is represented as a case. The logic following each branch in the decision is placed inside the case, as Figure 20 shows:

Figure 20. Exclusive decisions represented as switch activities
Figure 20. Exclusive decisions represented as switch activities

Be aware that for complex process logic where paths do not join back neatly together, the generated WS-BPEL may be more easily readable if you do not use switches, as Figure 21 shows:

Figure 21. Switch vs. connectors in complex logic
Figure 21. Switch vs. connectors in complex logic

The General tab in the attributes for the decision contains a check box called Inclusive. If this box is not checked, then only one path in the decision can evaluate to true. However, for an inclusive decision, any or all of the paths can evaluate to true.

The WS-BPEL switch activity can only have one case evaluate to true. For this reason, if you mark a decision as inclusive in Modeler, it overrides the check box for representing the decision as a WS-BPEL switch, as Figure 22 shows:

Figure 22. An inclusive decision overrides a switch
Figure 22. An inclusive decision overrides a switch

Generating an otherwise case in a decision

WS-BPEL switches provide an otherwise construct inside a switch activity. If none of the other cases are true, then the otherwise path is followed. Modeler does not provide any explicit support for generating an otherwise path. However, you can use this work-around:

  1. From the Technical Attributes view’s General tab, click the check box Represent exclusive decision as BPEL Switch activity.
  2. From the General tab of the attributes, ensure that the check box for Inclusive is not checked.
  3. From the Output Branches tab, define the expression for each of the output conditions except for the last one, at the bottom of the list.
  4. For the last output condition, set the expression to the Boolean value true.

This workaround ensures that if none of the other branches in the generated WS-BPEL choice evaluate to true, the last one will. WebSphere Process Server evaluates cases in a choice activity from left to right, so the generated WS-BPEL will work. You could edit the WS-BPEL to add an otherwise, then move the link if you prefer.


Fork, join, and merge

A fork is a construct in Modeler to split a flow out to two parallel paths. Its counterpart is the join, which waits for all of the incoming paths to complete before flowing out to one single path. A join is like performing an AND operation on the incoming paths.

In the generated WS-BPEL process, the fork becomes two connectors without conditions. The flow evaluates both paths, allowing the tasks to be performed in parallel. The join becomes a Java snippet, which acts as a synchronization point for the parallel paths, as figure 23 shows:

Figure 23. Fork and join
Figure 23. Fork and join

The Java snippet contains default code to retrieve the output of both tasks. The IT resource has to decide how to set the output if data from both paths needs to be merged.

Listing 2. Java snippet
if (ListOf2To2DatasVariable == null){
com.ibm.websphere.bo.BOFactory factory =  (com.ibm.websphere.bo.BOFactory) new
com.ibm.websphere.sca.ServiceManager().locateService("com/ibm/websphere/bo/BOFactory");
    ListOf2To2DatasVariable = factory.create( "http://Businessitems", "ListOf2To2Datas"); 
}
ListOf2To2DatasVariable.getList("dataItem").add(0, DataVariable);
ListOf2To2DatasVariable.getList("dataItem").add(1, DataVariable2);

Listing 2 illustrates an anti-pattern that is important to understand: when dealing with parallel activities, the parallel paths should not use the same WS-BPEL variable, because they could lead to deadlocks. The best practice is to use a different variable for each parallel path, even if the data type is the same.

Merge with the same business item

Unlike a join, a merge does not wait for all incoming paths to complete. As soon as one of the incoming paths reaches a merge, the flow moves on to the next activity. A merge is like performing an OR operation on the incoming paths.

If the incoming paths to a merge carry the same business item, the generated WS-BPEL simply takes the outgoing paths and attaches them both to the next activity in the process, as Figure 24 shows:

Figure 24. Merge with the same business item
Figure 24. Merge with the same business item

Merge with different business items

If the two paths flowing into the merge carry different business items, Modeler generates the WS-BPEL as follows (Figure 25):

  • One of the activities being merged flows directly to the next activity.
  • The other activity being merged flows to a Java snippet where IT can specify what to do with the data. Following the Java snippet, the flow goes to the next activity.
Figure 25. Merge with different business items
Figure 25. Merge with different business items

The same holds true for merges with large numbers of incoming paths. For example, with three incoming paths with different business items, one will flow out directly, while the others flow through a Java snippet first, as Figure 26 shows:

Figure 26. Merge with a large number of incoming paths
Figure 26. Merge with a large number of incoming paths

Notification broadcaster, notification receiver, observer, timer, and map

Notification broadcasters and receivers are used in a process to represent events. A notification broadcaster sends out events to notification receivers. These constructs are not exported to WS-BPEL. They must be removed from your model before exporting.

An observer is a construct that can initiate a flow when a condition becomes true. This construct also does not export to WS-BPEL. Timers are constructs that wait for a period of time. They are also not exportable.

A map is a construct in Modeler used to indicate that the data in the flow is changing from one business item to another. When exported to WS-BPEL, a map becomes a Java snippet, which is an IBM extension to WS-BPEL. The snippet is empty. Any code required would need to be written by IT. Because SCA offers a powerful interface mapping tool, writing code for a map would not be recommended in most cases. However, a map could be used if you want an “inline” Java snippet in the generated WS-BPEL, as Figure 27 shows:

Figure 27. Map implemented with an inline Java snippet
Figure 27. Map implemented with an inline Java snippet

While Loop, Do-While Loop, For Loop

The WS-BPEL specification does not include support for For Loops or Do-While Loops. If you use either of these, an error appears in the problems pane and the process cannot be exported.

You can convert a For Loop to a While Loop by using an appropriate loop condition. A For Loop iterates a defined number of times, n for example. If a counter is used for each iteration, a While Loop with the condition counter <= n would accomplish the same thing.

A Do-While Loop is like a While Loop, except that the loop condition is checked after each iteration. In a While Loop, the loop condition is checked before each iteration. If the loop condition is true the first time, the behavior is the same. By selecting a loop condition that is true the first time, you could use a While Loop in place of a Do-While Loop.

For a close look at how While Loops are modeled and exported to WS-BPEL, see Using Loops in WebSphere Business Modeler v6 to improve simulations and export to BPEL.


Local repository, global repository, and business items

Business items represent the data flowing in a process. You use local and global repositories to store business items. When exported to WS-BPEL, all three constructs become variables. Each variable in WS-BPEL is associated with a data type, based on an XSD or an interface.

For each business item in the business process, Modeler creates a WS-BPEL variable, along with an XSD. As much as possible, the exported process reuses existing variables, rather than creating one for every activity. The variable name is business item name || Variable, unless you use the technical attributes to override the default name. Variables are also created for each repository in a process, as Figure 28 shows:

Figure 28. Business items and repositories
Figure 28. Business items and repositories

Start, stop, and end

Start, stop and end nodes are only used for simulations. They have no effect on the generated WS-BPEL.


Wiring to the process edge

If you wire the output of the last task in a process to a stop node, data does not flow out of that task. The activity in the generated WS-BPEL reads input from a WS-BPEL variable, but does not set a variable upon completion. The generated WSDL for this task has a one-way operation.

If you wire the output of the last task in a process to the process edge, data does flow out of that task, as Figure 29 shows. Now the generated WS-BPEL both reads and writes to a variable. Similarly, to flow data into the first task in a process, you should wire it to the process edge.

Figure 29. Wiring to the process edge
Figure 29. Wiring to the process edge

Annotations

You use an annotation to add visible comments to the process model. The information in the annotations is exported to the WS-BPEL process, which allows better communication between the business and IT.

Annotations can be connected to objects in the business model to indicate which object the comment relates to. The text from attached annotations appears as comments for the generated WS-BPEL activity. The text from unattached annotations goes into the comments area for the process, as Figure 30 shows. Be aware that WS-BPEL has a limit of 256 characters for a comment field. Longer comments will result in errors.

Figure 30. Attached and unattached annotations
Figure 30. Attached and unattached annotations

SCA assembly diagram

Along with generating a business process and components, Modeler also generates an SCA assembly diagram, which is used to wire references for each service invocation in the process to the interfaces for the components. Component assembly is like building a solution by linking building blocks together, as Figure 31 shows:

Figure 31. SCA assembly diagram
Figure 31. SCA assembly diagram

In the example above, a process called ExportProcess has two tasks as well as a global subprocess named Process 1. Modeler generates WS-BPEL for both of the processes, shown below the process diagram in Figure 31.

For each process, an SCA component appears in the assembly diagram at the bottom. ExportProcess has wires to the three components it invokes: Process 1, and the two tasks. Process 1 has one single reference, wired to another generated SCA component. Both processes have SCA Exports defined for them, at the far left of the diagram. You use exports to advertise the process interface to the world outside the SCA module.


Roles, resources, and time tables

Modeler does not export roles and resources, since WS-BPEL is not a user directory. However, they are used as parameters for the generated human tasks. Time tables are not exported as WS-BPEL does not contain a counterpart construct.


Processes with multiple input criteria

Unlike a task, a process in Modeler can have a different number of input and output criteria. This fact can be used with global processes to generate the WS-BPEL activity called a receive choice, or a pick in older versions of the specification. A receive choice waits for 1 of n events to occur. For example, a request could be sent out from a process, then a receive choice could process the first one to return (discarding the others). You use a WS-BPEL correlation set to know which events go with which process.

To create a process with multiple input criteria:

  1. Create a new process in Modeler.
  2. From the Inputs tab in the attributes, add two inputs. Associate them with a business item for the data type. The process diagram shows two inputs.
  3. From the Outputs tab, add an output and associate it with a business item.
  4. Add activities to the process, as Figure 32 shows:
    Figure 32. Example process activities
    Figure 32. Example process activities
  5. On the Input Logic tab, add a second input criterion. Click the check box to associate the new input criterion with the second input. Click the check box to unassociate the new input criterion from the original input, as Figure 33 shows:
    Figure 33. Input logic
    Figure 33. Input logic
  6. In the Advanced Output Logic tab, click the Output Criterion to select it. The Advanced Output Logic tab is only available in intermediate mode or higher. Scroll to the bottom and select the checkbox for Input Criterion:2.
  7. Save the process. You may still see a warning in the errors view, which you can ignore.
  8. Export the process and select WebSphere Process Server as the target.
Figure 34. Exported process with receive choice activity
Figure 34. Exported process with receive choice activity

The resulting process (Figure 34) starts with a receive choice activity with the same name as the Modeler process. The two input criterion become receives within the receive choice activity. You see the red error indicator on the process because we haven’t set the required correlation attributes. These need to be set by IT to complete the process.

This technique only applies to global processes however, since Modeler transforms local subprocesses into scope activities.


Processes with multiple output criteria

Just as a global process can have more than one input criteria, it too can have multiple output criteria. You can use these criteria to generate a receive choice activity in the middle of a process, rather than at the start. You can place the process with multiple output criteria into another process, generating the receive choice activity there.

To create a process with multiple output criteria:

  1. Create a new process in Modeler called MultiOutput.
  2. From the Input tab add one input and associate it with a business item.
  3. From the Output tab add two outputs and associate them with a business item. The two outputs now appear on the diagram.
  4. Add tasks to the process and add connectors, as Figure 35 shows:
    Figure 35. Process with tasks
    Figure 35. Process with tasks
  5. On the Output Logic tab, add a second output criterion.
  6. Click the check boxes to unassociate the second output from the first output criterion, and to associate it with the new one, as Figure 36 shows:
    Figure 36. Associating output criteria
    Figure 36. Associating Output Criteria
  7. In the Advanced Output Logic tab, select the second output criterion. Click the check box to associate it with the input criterion, as Figure 37 shows:
    Figure 37. Associating input criteria
    Figure 37. Associating Input Criteria
  8. Save the process. It is normal to have a warning in the error view.
  9. Create a second process called MainProcess. Drag and drop the first process into the new process along with tasks, as Figure 38 shows:
    Figure 38. MainProcess
    Figure 38. MainProcess
  10. Export the new process, selecting WebSphere Process Server as the target. The resulting BPEL process includes a receive choice in the middle of the process, as Figure 39 shows:
    Figure 39. Process exported to WS-BPEL
    Figure 39. Process exported to WS-BPEL

The generated WS-BPEL process invokes MultiOutput, then waits to receive one of two different responses. Again, an error appears because the correlation set needs to be configured.


General Recommendations

  • Make sure to edit the model in WebSphere Process Server mode, then check the error view before exporting. You can export processes with warnings, but not processes with errors.
  • Make sure you save before attempting to export so you are sure to include any updates.
  • When exporting from a large project, select only the processes you want to export. All of their needed references will be included in the export, but nothing you don’t want, such as older as-is versions of processes.
  • Use technical attributes to set the names for the generated component. Otherwise the name will be the name from Modeler with a set of numbers appended to ensure it is unique.

Conclusions

This article walked you through each of the constructs in WebSphere Business Modeler, showing how it transforms them when exporting to WS-BPEL. Knowing and understanding Modeler constructs allows you better control the generated WS-BPEL.You also learned some tips and techniques for how to model a process to help generate the intended WS-BPEL. In summary:

  • The WS-BPEL generated for each of the test cases ran properly on WebSphere Process Server.
  • Not all WS-BPEL activities can be generated from Modeler. However, the most commonly used activities are generated.
  • The generated WS-BPEL still needs work if you want to include features such as fault handlers, compensation handlers, etc.
  • The generated SCA components need additional work before they are ready for usage. However, they are generated with the correct interfaces and structures, simplifying development and ensuring that the needs of the business are met.

Resources

Learn

Get products and technologies

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services, Architecture, Business process management
ArticleID=232429
ArticleTitle=Transforming business models to BPEL with WebSphere Business Modeler 6.02
publish-date=06272007