Understanding WebSphere Business Modeler and FileNet integration

IBM® WebSphere® Business Modeler can export models to several different target platforms, and its newest export capability is for IBM FileNet® P8 Business Process Manager. This article explains which modeling constructs are supported for FileNet, and shows you how to prepare a model for export using a practical follow-along example. This content is part of the IBM WebSphere Developer Technical Journal.


Marc Fasbinder, BPM Integration Solution Architect, IBM

Photo of Marc FasbinderMarc Fasbinder is an I/T Specialist at IBM with the WebSphere Technical Sales team in Southfield, Michigan.

developerWorks Contributing author

27 February 2008

Also available in Chinese


IBM WebSphere Business Modeler is a powerful tool for creating business process models. Business processes can be modeled for different reasons:

  • For documentation purposes: A powerful simulation engine can be used to evaluate process models to help find areas for improvements, and to enable As-Is and To-Be modeling. You can generate reports for both static and dynamic process analysis, including process comparison reports, and you can try out "what if" scenarios to test possible process improvements using process simulation.

  • For execution: Process models are useful assets for technical developers, because a model is like a plan for how to build something, which helps reduce complexity and speeds up the development cycle. In this way, WebSphere Business Modeler acts as the bridge between non-technical business analysts and technical developers.

The IBM FileNet Business Process Manager, which is part of the IBM FileNet P8 family of products, manages workflows for document- and human-centric business processes. Workflow process automation has many advantages, including maximizing process efficiency, ensuring processes are run consistently, improving quality while reducing cycle time, and lowering costs. IBM FileNet Business Process Manager is part of FileNet P8, and integrated to IBM Enterprise Content Management. Workflow processes are based on the XML Process Definition Language (XPDL) standard.

Prior versions of WebSphere Business Modeler (hereafter referred to as Modeler) have included modeling modes for target runtimes like IBM WebSphere MQ Workflow and IBM WebSphere Process Server. These modeling modes expose technical details that apply only to the target platform, plus provide an extra level of error checking to ensure that the exported model is correct for the target runtime.

Support Pac BA77, "IBM WebSphere Business Modeler FileNet Integration," was released for Modeler Version 6.0.2, enabling FileNet P8 Business Process Manager (hereafter referred to as FileNet) to be an additional export target for Modeler. With the release of Modeler Version 6.1, this capability is now included in the base product. This means you can take advantage of powerful Modeler features, such as simulation and analysis, and then export a process to XPDL for further refinement in the FileNet environment.

FileNet Business Process Manager mode

To export models to FileNet, you must first set Modeler to FileNet Business Process Manager mode. To do this, select Modeling => Mode => FileNet Business Process Manager from the Modeler menu bar (Figure 1). (Alternatively, you can type Alt+Ctrl+F.)

Figure 1. FileNet Business Process Manager mode
Figure 1. FileNet Business Process Manager mode

As with other export targets, not every construct in Modeler is supported in FileNet. Upon entering FileNet Business Process Manager mode, non-supported constructs are grayed out from the pallet, so you cannot add them to your process. The unsupported elements are:

  • Observers
  • Timers
  • Notification Broadcasters and Receivers
  • Global Tasks, Global Services, Global Repositories
  • Business Rules Tasks
  • Business Services and Business Service Objects.

If you are trying to export a model that contains any of these unsupported elements, they will be flagged as errors and must be corrected before exporting.

Model transformations

As you might expect, FileNet and Modeler do not possess all of the same elements. Therefore, elements in the process model need to be transformed into the closest matching element in FileNet. Understanding these transformations is important when you build a model that will be exported.

Data flow

Much like WS-BPEL, a flow in an XPDL process is for control only; data does not flow between process elements. Data is stored in global variables called data fields, which the activities can access. For this reason, processes for export to FileNet cannot use business items on the connector between tasks. Instead, you can use a local repository to store the output of the first task, then flow from the repository into the second task, as Figure 2 shows. The connection between tasks is mapped to a route in FileNet.

Figure 2. Data flow pattern
Figure 2. Data flow pattern

If there are multiple pieces of data to flow, you will need one repository for each piece of data. Each repository you create will correspond with a data field in FileNet. When you add a repository in FileNet Business Process Manager mode, the default capacity is set to 1. In other modes, the default capacity is unlimited. Global repositories are not supported in FileNet Business Process Manager mode; you must always use local repositories.

If your process has a large number of variables, all of the connections to the repositories could make your process diagram appear complex. You might want to consider not showing the links between tasks and repositories, which will keep the overall look of the diagram cleaner. To hide the connectors:

  1. Right-click in the whitespace of the process background.
  2. Select Repository Connections to de-select it (Figure 3). Your process diagram will now show the repositories, but their connections will be hidden.
Figure 3. Hiding repository connections
Figure 3. Hiding repository connections

As for the data itself, not every data type that is available in Modeler has an equivalent in FileNet. Data types are mapped as closely as possible, but a few data types in Modeler are not supported in FileNet, as shown in Table 1.

Table 1. Data type mapping
Modeler data typeFileNet data field
Decimal (double-precision)Not supported
Decimal (single-precision)Float
DurationNot supported
Integer (byte)Not supported
Integer (long)Not supported
Integer (short)Not supported

If you create a repository or a business item using one of the unsupported data types, an error will appear in the error view. You must update your model to use a supported data type before exporting.

Business items

Service Pack 2 for FileNet Business Process Manager added a new capability to support complex data types, called data fields of XML type. Prior to this service pack, only supported simple data types. If you use a business item as the data type for a repository, it will be mapped to a data field of XML type, even if the business item only has one attribute. The use of business items does not result in any errors or warnings, but you should be aware that it is only supported in FileNet if you are at Service Pack 2 or later.


A top-level process in Modeler is transformed into a workflow process in FileNet. However, when using subprocesses or reusing global processes, different mappings are used.

You should not expect that the exported process will be ready to run in FileNet. The results of the export process will require further refinement before they can be run.

Local process

A local process is transformed into a submap within the workflow process created for FileNet. At the XPDL level, the submap is called a BlockActivity. Data does not flow into a local process in Modeler. Instead, repositories are used to store the data in the top level process. Steps inside the local process can then access the data from the repositories. For example, you might want to map the output of a step in the local process to a repository in the top level process. To do this:

  1. Click on your task in the local process to select it.
  2. Click Attributes to view the attributes for that task.
  3. Click the Output tab.
  4. Click the Add button to add a new output.
  5. Click the Associate data field, then click the ellipsis button that displays. (Alternatively, you can scroll down and click the Browse button for the Associate data field.)
  6. Click the drop-down menu for Basic type, and select your data type, such as Boolean in Figure 4, then click OK.
    Figure 4. Selecting data type
    Figure 4. Selecting data type
  7. Click the Output target field, and select Repository, then Enter. The panel will then update.
  8. Scroll down or enlarge the attributes area, and click the Browse button for Repository value.
  9. From the pulldown menu, select the local repository you want to use, and click OK. You have now mapped the output of your task to a local repository in the high level process (Figure 5).
    Figure 5. Mapping task output to a repository
    Figure 5. Mapping task output to a repository


A map in Modeler is used when the output of one task has a different data type or business item than the next task in the flow. Since data flows are not supported in FileNet Business Process Manager mode, there is no need for a map, so they are not supported in the process flow -- with one exception: the start.

At the start of a flow, there might be an incoming data flow. A map can be used at the very start of the process to map the incoming data flow to one or more repositories to hold the data so that it can be accessed by the other steps in the process. However, when the workflow process is viewed in FileNet, the map will not appear as an element of the flow: it is transformed into just the mapping of the incoming data into data fields.

The data flowing into the process needs to be defined as a series of simple data types (Figure 6). If a business item flows into the process, the map will be marked with an error.

Figure 6. Map as first element of a flow
Figure 6. Map as first element of a flow

Global process

A global process that is reused within the top level process in Modeler is transformed into a system step in FileNet. If the global process is called synchronously, the top level process will not resume until the system step has completed. In the generated XPDL, the global process will be a workflow process, defined at the same level as the main process (Figure 7).

Figure 7. Transforming global process from Modeler to FileNet
Figure 7. Transforming global process from Modeler to FileNet


Local tasks and local human tasks in a process defined in Modeler are transformed into general steps in a FileNet process. Inputs and outputs of a task map to parameters. If a local human task is used, the primary owner for the task maps to a FileNet participant for the step. Global tasks and global human tasks are not supported.

Although both types of tasks are mapped to FileNet, there are some restrictions. Only one input criterion and one output criterion are supported. For example, say that Task1 and Task2 both need to flow into another task, called InputTask. Either Task1 or Task2 can run, but not both. InputTask would need two input criteria so that it could start (one for each of the incoming tasks, with a logical OR being performed). This pattern is not supported; a merge element must be used instead, as shown in Figure 8.

Figure 8. Using a merge
Figure 8. Using a merge

Similarly, instead of using two output criteria, you can use a decision after the task to decide which path in the flow to take.

Roles and resources

For the case of a human task, the roles and resources defined in Modeler are mapped into the equivalent constructs in FileNet. As with other mappings, there are restrictions based on the differences in the two environments.

  • An individual resource requirement in Modeler maps to a participant in FileNet. However, the specified individual resource must be based on the predefined staff or person resource definition. In other words, if the individual resource requirement is for a non-staff or person resource, it does not export.

  • A role in Modeler is mapped to a workflow group in FileNet, while a role requirement is mapped to a participant. There is no mapping for resource definitions, resource definition templates, and individual resources.

Flow control

Modeler elements used to control the flow of the process are mapped to their closest equivalents in FileNet.


In Modeler, decisions can be either inclusive or exclusive. The most common pattern is the default, using exclusive decisions, where only one of the possible paths can be true. Simple decisions are always exclusive. In FileNet, routing information is part of a step. If Task1 is followed by a decision, the logic from the decision is mapped into the routing information for Task1. In cases where the logic cannot be mapped directly to the task, a new general step is created for the process, including routing information. In either case, the logic from the business process is preserved in the generated XPDL. The decision becomes a logical OR split in the routing information.

Inclusive decisions in Modeler can have more than one branch evaluate to true. Only complex decisions can be inclusive. By clicking the checkbox on the General tab of a complex decision, you can mark it as inclusive. The graphic changes for an inclusive decision, as Figure 9 shows. Since more than one branch can evaluate to true for an inclusive decision, the percentages for the outputs can total to a number greater than 100%. Inclusive decisions are also mapped into the routing information of the task preceding the decision, using a logical AND split in the routing information.

Figure 9. Inclusive and exclusive decisions
Figure 9. Inclusive and exclusive decisions

The expression editor in Modeler is used to define the logic for decisions. In FileNet Business Process Manager mode, expressions are required for each output. If you do not define the expressions, it will be marked with an error. Expressions are mapped to routing conditions in FileNet.

Merge and join

A merge in Modeler is used to connect multiple paths into a single path. Only one of the inputs to a merge needs to be true. In this way, a merge is like a logical OR for the process logic.

FileNet, however, does not have a similar construct. For this reason, when a merge is used in Modeler, it is mapped to routing information in the step following the merge. For example, if three steps flowed into a merge, and the output was then connected to a task named Task2, then the exported process would include routing information in XPDL generated for Task2. In cases where that is not possible, a new general step is generated, including the routing information.

A join is used in conjunction with a fork. A fork branches out to two or more parallel paths. A join waits for all of the parallel paths to complete before proceeding. In this way, a join is like a logical AND for the process logic.

FileNet does not have a similar construct, and so, similar to merge, a join is mapped to the routing information for the task to which its output is connected. If that is not possible, then a new general step with the routing information is generated.

FileNet requires symmetrical process flows. When parallel paths are used, each path must merge or end. There is an additional consideration for parallel paths, because tasks on each path can be performed at the same time; you need to consider how to handle the data. If two parallel paths try to access the same data at the same time, you could run into consistency issues. For this reason, if you use the same repository in parallel paths, each path in the export will have its own copy of the data. You might consider using different repositories yourself, so you will have greater control over the generated data fields.


Many notations and runtimes do not permit backward flowing connections. Therefore, groups of steps that might need to be repeated are placed inside of a loop. Modeler has three types of loops you can use in a process flow:

  • While loops have a loop condition that is evaluated before each iteration. While the condition is true, the steps in the loop are performed. Since the loop condition is checked before each iteration, the steps in the loop would not run at all if the condition is initially false. This is the only type of loop supported in WS-BPEL.
  • For loops are run for a set number of iterations. For each iteration, all of the steps in the loop are run.
  • Do-while loops are similar to while loops, except that the condition is checked after each iteration. This means that the steps in the loop will be performed at least once.

FileNet does not have the concept of loops. However, XPDL does not restrict flows from having links to predecessor activities. This condition is ideal for document centric flows, whereas integration centric processes are better supported by a "programmer-oriented" language such as WS-BPEL, which requires loops. The cyclic flow activity in IBM WebSphere Process Server V6.1 brings this type of capability to WS-BPEL.

Modeler loops are mapped to FileNet constructs for each loop, by having one step to represent the condition check in the loop, and another step to represent the contents of the loop. In the case of a for loop, three additional data fields are generated. These fields keep track of the number of iterations that have been performed in the loop, and check the condition to determine when to end.

Figure 10. Modeler process with a while loop
Figure 10. Modeler process with a while loop

After exporting the process with a while loop to XPDL, the process can be opened in the FileNet Process Designer (Figure 11).

Figure 11. While loop process exported to FileNet
Figure 11. While loop process exported to FileNet

The system task named While Loop points to an activity set that contains tasks corresponding to the ones in the while loop (Figure 12). The routing between the general step (with no name) and While Loop contains logic that corresponds with the loop condition. The routing to Process Task has the logical opposite, so when the loop condition is false, this route will be taken instead. In this way, the FileNet process acts in the same manner as a while loop, even though loops are not supported.

Figure 12. While loop activity set
Figure 12. While loop activity set

Other elements

Processes in Modeler typically begin with one or more start nodes. FileNet processes begin with a single launch step activity. The launch step is automatically created, whether you use a start node or not.

Stop nodes in a top-level process are mapped to system steps using the terminateProcess function. In local processes or loops, stop nodes are ignored when exporting to FileNet.

There is no mapping for an End node; they are ignored when exporting.

Annotations are mapped to text annotations in FileNet, shown in Figure 11.

Global elements and services

Modeler has the concept of reusable global elements to promote reuse and to support environments such as WebSphere Process Server, which has reusable libraries. There are no mappings from global elements to constructs in FileNet. Only global processes can be used.

Modeler also has a concept of global and business services. There is no mapping of these elements from Modeler to FileNet.

Example process

A sample process is presented below to demonstrate some of the other export features and capabilities of Modeler (Figure 13).

Figure 13. Sample process
Figure 13. Sample process

As mentioned earlier, you can hide the connections from tasks to repositories to make the process look cleaner (Figure 14). This tip might be preferred as the process complexity increases.

Figure 14. Process with repository connections hidden
Figure 14. Process with repository connections hidden

The process contains several elements.

  • Review Request: A human task, with the role of Reviewer assigned.
  • Approved?: A simple decision, based on the Approval Status boolean variable. An expression was created with the expression editor (Figure 15). Data does not flow into the decision, so you must click the Add button to create the expression.
  • Process Approval: A task with a role requirement of Reviewer and resource type Staff.
  • Process Rejection: A task with a role requirement of Reviewer, but no resource type specified.
  • Merge: Merge the two paths to one.
  • Stop: End of the process.
Figure 15. Expression editor
Figure 15. Expression editor

The process was exported to FileNet, and opened in the FileNet Process Designer (Figure 16).

Figure 16. Example process in FileNet Process Designer
Figure 16. Example process in FileNet Process Designer

In the FileNet process:

  • LaunchStep: FileNet processes begin with a launch step. Parameters in LaunchStep correspond with the incoming data in the Modeler process.
  • Review Request: A task with work assignment to the role of Reviewer.
  • Process Approval: A task with work assignment to the role of Reviewer.
  • Process Rejection: A task with work assignment to the role of Reviewer.
  • Stop Node: A system step with the function terminateProcess selected.
  • Routings: Routings between Review Request and the following steps include logic for which route to use.

The Modeler tasks Process Approval and Process Rejection both used a role requirement. Unlike an individual resource requirement, it did not matter whether the resource type was set to Staff or not; both tasks were mapped to tasks with work assignment set to Reviewer.

The business intent of the process was preserved, and constructs from Modeler were mapped to their counterparts in FileNet.


In this article, you learned about the FileNet Business Process Manager mode in IBM WebSphere Business Modeler V6.1. You learned how elements of a model are transformed into XPDL for FileNet and which elements are not mapped, along with modeling recommendations. A sample process was described to give you a practical example of the export capabilities from Modeler to FileNet.



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 Business process management on developerWorks

Zone=Business process management, WebSphere, Information Management
ArticleTitle=Understanding WebSphere Business Modeler and FileNet integration