IBM FileNet Business Process Manager
IBM FileNet Business Process Manager
Step-by-step
instructions
Wei-Dong Zhu
Eric Adel
William Benjamin
Imtiaz A Khan
Mike Marin
Mark Yingling
ibm.com/redbooks
International Technical Support Organization
August 2008
SG24-7509-00
Note: Before using this information and the product it supports, read the information in
“Notices” on page ix.
This edition applies to Version 4, Release 0 of IBM FileNet Business Process Manager (product
number 5724-R76).
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The team that wrote this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Chapter 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Business process management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Transactional processes and content centric processes . . . . . . . . . . 3
1.2 IBM FileNet Business Process Manager overview . . . . . . . . . . . . . . . . . . . 4
1.3 Process design with BPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Process definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.3 Routes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3.4 Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.5 Deadlines and timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.6 Content events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 BPM application development options . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4.1 IBM FileNet Workplace (or Workplace XT) . . . . . . . . . . . . . . . . . . . . 10
1.4.2 Business Process Framework (BPF) . . . . . . . . . . . . . . . . . . . . . . . . 11
1.4.3 Electronic forms (eForms or Lotus Forms) . . . . . . . . . . . . . . . . . . . . 11
1.4.4 Portal user interface through IBM FileNet P8 portlet. . . . . . . . . . . . . 12
1.4.5 Web Application Toolkit (WAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.6 Process Engine API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 BPM integration to external systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.1 Component Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.2 Web services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.3 Business rules engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.6 BPM process monitoring and analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.6.1 Process Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6.2 Process Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.6.3 IBM FileNet Business Activity Monitor . . . . . . . . . . . . . . . . . . . . . . . 16
1.7 BPM applications and tools summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.8 The IBM FileNet P8 family of products . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.8.1 IBM FileNet content products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.8.2 IBM FileNet process products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Contents v
6.7 Creating a workflow subscription. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.7.1 Exposing a system property and mapping it in a workflow . . . . . . . 199
6.8 Testing the basic process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
6.8.1 Monitoring workflow processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
6.8.2 Testing the workflow process from beginning to end . . . . . . . . . . . 212
6.9 Creating and calling a Web service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
6.9.1 Creating a workflow process as a Web service . . . . . . . . . . . . . . . 231
6.9.2 Calling the Web service in a workflow process . . . . . . . . . . . . . . . . 244
6.9.3 Create a subscription to launch your process . . . . . . . . . . . . . . . . . 256
6.9.4 Testing the process with Web services . . . . . . . . . . . . . . . . . . . . . . 256
Chapter 7. Integration with external systems and services with BPM . . 257
7.1 Component Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
7.1.1 Content Engine operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
7.2 Web services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
7.2.1 Process orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
7.3 Rules connectivity framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Contents vii
viii Introducing IBM FileNet Business Process Manager
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area.
Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs.
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Cognos, and the Cognos logo are trademarks or registered trademarks of Cognos Incorporated, an IBM
Company, in the United States and/or other countries.
FileNet, and the FileNet logo are registered trademarks of FileNet Corporation in the United States, other
countries or both.
Network Appliance, SnapLock, and the NetApp logo are trademarks or registered trademarks of NetApp,
Inc. in the U.S. and other countries.
IBM FileNet, and the IBM FileNet logo are registered trademarks of IBM FileNet Corporation in the United
States, other countries or both.
J2EE, Java, JavaScript, JDBC, JSP, Streamline, and all Java-based trademarks are trademarks of Sun
Microsystems, Inc. in the United States, other countries, or both.
Excel, Expression, Internet Explorer, Microsoft, Visio, Windows, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
In this book, we cover the key elements that make up a business process,
including tasks, participants, roles, steps, routing, and deadlines. We describe
how to use Process Designer (a BPM application) to design your business
processes. In addition, we provide step-by-step instructions on how to implement
a use case business process scenario (an auto claim approval process).
At the end of the book, we discuss, from a high level, the planning and designing
of content centric BPM applications.
This book is useful for system architects, process analysts, and designers who
require an understanding of IBM FileNet Business Process Manager. It also
serves as a practical guide for those who want detailed instructions in order to
implement a BPM system.
Mike Marin is a Distinguished Engineer at IBM Software Group and the Product
Architect for IBM FileNet Business Process Manager. He holds a Master of
Science degree in Computer Science, specializing in Artificial Intelligence and
has more than twenty years of experience designing and developing system
software. The last eleven years, he has been developing business process
management and workflow products, and participating in standard organizations
including OMG, OASIS, and WfMC, working on business process management
and workflow standards. He has edited and contributed to the definition of
several of these standards. Mike is a Fellow of the WfMC and has received the
WfMC Excellence Award for his technical contributions to the WfMC
standardization efforts.
We would like to extend special thanks to the following people who have made
this project possible:
Richard Palfini
Steve Mason
Manoj Puthenveeti
Darik Siegfried
IBM Software Group, Costa Mesa, California
We also thank the following people for their contributions to this project:
Charles Burnett
Jingli Chen
Khoi Dang
Quynh Dang
Victor Falco
Kevin Fally
Evangeline Fink
Steven Kelly
Patrice Lewis
Jane Luo
Mark Muller
Ken Rong
Michael Samiley
Bernadine Sisneros
Chuck Snow
Christopher Timbreza
IBM Software Group, Costa Mesa and Sacramento, California
Preface xiii
Your efforts will help increase product acceptance and customer satisfaction. As
a bonus, you will develop a network of contacts in IBM development labs, and
increase your productivity and marketability.
Find out more about the residency program, browse the residency index, and
apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
Chapter 1. Overview
In this chapter we provide a high level overview of the IBM FileNet Business
Process Manager (BPM) and an introduction to the IBM FileNet P8 family of
products.
Process automation
Processes are performed by people and applications. Automated processes
save time when compared with manual processes. The goal of process
automation is to provide technology to coordinate how people and applications
work together to perform processes. The technology should provide enough
functionality and be robust enough to be trusted with business critical processes.
Workflow
Workflow is a structured way of performing tasks by an individual or a team.
Examples of workflow include auto insurance claims that require the efforts of
multiple people to process. The workflow process involves a policy holder filing a
claim, a field agent processing the claim, an adjustor adjusting the claim amount,
and finally the claimant either receiving the claim amount or the claim being
rejected.
Process optimization
Process optimization refers to measuring, monitoring, simulating, and analyzing
business processes, and ultimately improving the processes. By providing the
continuous process optimization capability in a business process management
solution, organizations can increase their responsiveness, identify issues before
they become problems, and maximize the performance of their business
operations.
Content centric processes are highly collaborative and require users or systems
to make decisions based on content during the processes.
Content centric processes involve people and content and are usually longer
lived than transactional processes. Any addition or change to content, such as
new document creation, can trigger the associated process to act on the content,
thus the processes are considered content centric.
Chapter 1. Overview 3
Most applications require both content and transactional processes to run
together to achieve a business goal. As organizations start automating
processes, they require both types of processes.
IBM FileNet Business Process Manager can be used in many areas, including
banking, insurance, manufacturing, health industry, and government. Examples
in the banking and insurance industries include applications for processing loans,
claims, credit card approvals and policy underwriting.
IBM FileNet Business Process Manager addresses the primary focus of business
process management (that is, managing, transforming, and optimizing business
processes). It provides the following functions:
Process automation
Process modeling and designing
Process integration
Process monitoring and optimization
Process automation
IBM FileNet Business Process Manager (BPM) provides a Process Engine and a
set of associated components and applications that enable easy implementation
of robust business process management solutions designed for use by business
users. BPM also provides a set of APIs to enable custom programming for
automating processes and a flexible environment for process improvements.
IBM FileNet Business Process Manager offers Process Designer, a tool that
creates executable processes. It can import Microsoft Visio diagrams and read
XML process definition language (XPDL) files that are generated by WebSphere
Business Modeler. In addition, Process Designer can read XPDL files generated
by other tools. Process Designer can use these models as a starting point to
create executable processes. IBM FileNet Business Process Manager also
offers Process Simulator, a tool that is used to simulate these processes to
identify bottlenecks and to play with “what if” scenarios.
Process integration
IBM FileNet Business Process Manager provides process integration capabilities
with external applications and systems through Component Integrator, rules
engine framework, and Web services. These integration options accelerate the
speed of business process management solution development and reduce the
overall costs associated with the development and maintenance of processes.
Chapter 1. Overview 5
process. In the mortgage case, some milestones might include application
received, in process, approved, and rejected. In this scenario, a business analyst
can be assigned as the tracker for a particular mortgage process and the
customer can be provided with access to the milestone view of the process.
For monitoring and analysis of all the processes, IBM FileNet Business Process
Manager offers Process Analyzer and Business Activity Monitor (BAM). Process
Analyzer enables users to evaluate process workload, discover processing
trends, and identify bottleneck areas. Business Activity Monitor lets managers
monitor various aspects of their business operations, set thresholds, and
automate actions to react to thresholds being exceeded.
IBM FileNet Business Process Manager offers Process Simulator, which can be
used to analyze processes and evaluate how they behave in different scenarios.
Process Simulator can be populated with data from Process Analyzer to work
with processes that are already in production.
Map
Annotation
Step
Route
Figure 1-1 Process Designer showing a map with steps, routes and a step annotation
1.3.2 Steps
Steps represent specific business or system activities. Activities can be
performed by an individual user (the participant), by a group of users, or by an
automated application.
Chapter 1. Overview 7
There are several types of steps:
Launch step: The first step in a process. Every process has this step.
General step: Represents a general activity to be processed by a participant
(or a group of users), or an automated process. It can be categorized as
follows:
– Participant step: A step that has an associated participant or a group of
users, all of whom must process the work item to complete the step. The
identity of these users can be defined at runtime through the use of
groups.
– Work queue step: A step that is assigned to a work queue (see definition
below) instead of a specific participant.
– Unassigned step: A step that has no effect in the process and can be used
for routing or documentation purposes.
System step: Represents one or more functions to be performed by the
system. For example, a system step might include assigning data field
values, creating a new process instance, or suspending a process for a
specified period of time.
Submap step: Calls another map in the current process definition.
Component step: Performs operations in an external application or system.
It is accomplished by IBM FileNet Business Process Manager’s Component
Integrator.
Web services step: Invokes or implements Web services. IBM FileNet
Business Process Manager uses Web services to integrate to external
applications and services.
Work queue
A work queue holds work items that can be completed by a user from some user
groups or by an automated process. Assigning work to a work queue rather than
to an individual participant provides flexibility as to who can perform the specific
activity at a step.
1.3.3 Routes
Routes define the order of execution for a series of steps based on specific rules
(using workflow data fields) and user responses (Approve and Deny as
examples). You can specify to always take a route or to only take the route when
a condition is met.
Routes can also be used to define parallel branches where the steps are
executed in parallel.
1.3.4 Maps
A map represents the sequences of steps and routes required to complete a
process. You can define maps using Process Designer or import them from other
process design tools, such as Microsoft Visio.
A complex process can be broken down into simpler and reusable components
with each component being represented by a map. A process, therefore, can use
a collection of maps. The ability to break down processes into smaller
components makes complex processes easier to build and understand. It also
results in a significant reduction in the total cost of development. The reuse of the
maps ensures the consistency of processing and reduces time and costs
associated with the deployment of new processes.
Chapter 1. Overview 9
1.3.6 Content events
Processes can be automatically launched when objects in a content repository
are created or changed. In general, any content event can be used to launch or
to trigger a process. For example, if a new customer (object) is created, a
process that manages new customers can be automatically launched.
1
Workplace XT is the latest release of the Workplace application. Although this book deals
exclusively with Workplace, many of the features and functions that are discussed for Workplace
are also applicable for Workplace XT. For simplification, we mention just Workplace in many parts
of the book.
BPF supports a broad set of functions, including data entry, layout with built-in
validations, and data types. An IBM FileNet Business Process Manager Web
application can be created with simple configuration rather than coding. The
framework provides user interface components that can be configured and
customized easily, thus reducing development time and costs.
The user interface for a particular step in a process can be created using the
eForms or Lotus Form Designer. The resulting forms can be automated and
tightly integrated with the Process Engine without custom programming.
The form filled out by a user in a process step can be saved and stored in the
content repository as a document, which can then become a record of the user
action. In addition, data in the form can be used to populate the document
metadata or update an external database.
Chapter 1. Overview 11
1.4.4 Portal user interface through IBM FileNet P8 portlet
IBM FileNet P8 provides a set of predefined portlets that are compatible with
industry standard Web portals. A portlet is a user interface component that
encapsulates a small set of functions.
IBM distributes the source code for the predefined portlets, so their capabilities
can be modified and extended. In addition, users can create their own portlets
using the Content Engine and Process Engine Java™ APIs.
WAT includes a rich set of APIs that can be used to create custom Web
applications or to integrate IBM FileNet P8 components with existing
applications. IBM FileNet Workplace is an example of a Web application that has
been developed using the toolkit.
Web services calls can also start a business process in IBM FileNet Business
Process Manager. A business process can be exposed as a Web service.
In a process, business rules can be used in two distinct ways. The first is to
control the process itself. For example, steps can be skipped or re-executed. The
second is to implement application logic at a particular step. For example, a
business rule can be used to calculate the price of a discounted item.
The IBM FileNet P8 Platform can be integrated with industry standard rules
engines enabling process designers and business analysts to associate rules
with individual steps in a process.
Chapter 1. Overview 13
development phase. The Process Analyzer is used for dynamic, chart-based
analysis of process activity at runtime. The IBM FileNet Business Activity Monitor
is used to monitor various aspects of in-progress business operations including
not only the executing processes but associated applications.
As shown in Figure 1-2, the life cycle of process improvement starts by analyzing
the current process that can be manual or automated, and identifying areas for
improvement. Simulation technology can be used to validate the process. Then
the improved process can be deployed into production, where it can be
monitored using Process Analyzer or BAM.
Deploy Analyze
Validate Identify
Simulate
3
Figure 1-2 Round trip process improvement
You can create your own custom reports, extending the reporting functions by
including business data that is tracked in the Process Engine event logs. In
addition to Microsoft Excel, if you require sophisticated reporting capabilities, you
can use IBM Cognos® Analysis Studio or IBM Cognos Reports.
Chapter 1. Overview 15
Figure 1-4 shows the sample reports based on Process Analyzer output.
Figure 1-5 shows the BAM Dashboard which illustrates various business
activities such as case arrivals, arrivals by hour, cases by product, along with
respective service level agreement (SLA) performance.
Real-time updates
Figure 1-5 Business Activity Monitor in IBM FileNet Business Process Manager
The last three items on the list do not come with IBM FileNet Business Manager.
They are separate components that work with and support IBM FileNet Business
Manager solutions (as we have covered briefly in previous sections of this book).
Chapter 1. Overview 17
The main tool to do process design in IBM FileNet Business Manager is Process
Designer. We discuss how to use this tool in more detail in Chapter 5, “Using
Process Designer” on page 67. Although other supporting applications and tools
are also important in improving, monitoring, and managing your business
process, it is beyond the scope of this book to cover them.
The IBM FileNet P8 family of products are divided into three major categories:
Content
Process
Compliance
There is also a set of tools that the IBM FileNet P8 Platform provides for system
management.
Chapter 1. Overview 19
1.8.3 IBM FileNet compliance products
IBM offers a cohesive compliance framework that combines e-mail and file
system capture with records policies and BPM processes. Using the IBM FileNet
P8 family of products, compliance can be enforced automatically without user
intervention.
There are three core products under the compliance framework: IBM FileNet
Records Manager, IBM FileNet Records Crawler, and IBM FileNet Email
Manager.
Records can be automatically captured, declared, and classified, using any one
of the following methods:
Document centric: The declaration and classification of records are based
on documents. When a file is saved to a particular folder in the IBM FileNet
P8 content repository, the system responds to certain criteria to declare and
classify the document as a record. The process can be set up to be
completely transparent to users, eliminating the necessity for additional steps
or manual decisions associated with records declaration and classification.
Event based: The declaration and classification of records are based on
events. Following certain events or transactions associated with Web-based
or line-of-business applications, records can be automatically captured and
classified, based on pre-defined criteria or rules, such as the type of
transactions or metadata associated with the transactions.
Process-centric: The declaration and classification of records are based on
business processes. At pre-determined points in a business process, records
can automatically be identified, declared, and precisely classified, based on
pre-defined criteria or data from the business process.
IBM FileNet Records Manager reduces the risk of litigation and provides
business continuity by enforcing corporate compliance procedures, storing only
records that are required and only for as long as they are required, and ensuring
that expired records are destroyed in a legally acceptable manner.
IBM FileNet System Monitor automates the monitoring of the entire IBM FileNet
P8 environment, including software components, application servers, databases,
log files, network communication and devices, and the full range of IBM FileNet
storage libraries.
Chapter 1. Overview 21
22 Introducing IBM FileNet Business Process Manager
2
The current process is dependent on the documentation that comes from the
field offices. If there is a mistake, such as missing signatures, or if a document
takes too long to get into the office, it impacts the entire claim approval process.
Due to the mostly manual process, it takes a long time to get claim settlements
out to the policy holders. In addition, it is difficult to find and group all of the
documents associated with a policy holder and their open or closed claims, and
forms often get lost in the mail or in the mail room. With a long and error-prone
claim approval process, XYZ Corporation faces unsatisfied customers, and the
risk of losing customers and market share.
The process is content intensive and requires people to make decisions based
on that content; therefore, IBM FileNet Business Process Manager is the perfect
solution to streamline this business process.
A policy holder has an auto insurance policy with XYZ Corporation. The policy
holder has been involved in an automobile accident and submits a claim with the
XYZ Corporation. Once the claim is submitted, it will either be approved or
denied. If the claim is approved, the policy holder will get a check to cover repairs
to their vehicle and can secure a rental car while their car is being repaired. If the
claim is denied, the policy holder will be notified and will not get paid.
1.Customer calls
and submits a
claim
Front Office
CSRs
7. Accounting
Clerk gets the
approved claim
8. Filing Clerk
package and writes
gets the closed
a check and sends
file and files it.
it to the claimant.
The closed file is
then sent for filing.
Back Office
Mailroom Clerks
Adjustors
6. Supervisor reviewes
Supervisors
Accounting Clerks 4. Field Agent gets the
the claim and either claim package, reviews
approves or rejects it. Filing Clerks it, associates police
Approved claims go to report and other related
Accounting Department
documents, then sends it
for payment to Adjustor
Field Agents
5. Adjustor receives the claim
package, reviews it, and either
approves or rejects the claim or
escalates it to Supervisor.
Approved claims go to
Accounting Department for
payment
Based on Figure 2-1, the claim process can be broken down into the following
logical stages:
Initiating a claim (steps 1 and 2)
Back office mailroom clerk task (step 3)
Claim processing (steps 4 through 6)
Financial controls (part of steps 5 through 6 and 7)
The agent takes the call from the customer and creates documentation about the
incident, such as where the auto loss occurred and when. The agent also faxes
the documentation about the loss to the back office. The faxed information
creates a document on the receiving end with its own life cycle and retention
rules. This is the content that is crucial to the approval process. The information
that is documented by the agent is what starts the claim approval process.
Because this filled-out document starts the claim approval process, it is clear that
when a new document of this type is created, a new claim process could be
started automatically. The combination of creating the initial claim document,
populating it with information, and faxing the document to the back office are the
key pieces that start the claim approval process.
We have identified the components that start the process. Now we can
streamline the process and optimize the workflow by unlocking the value of the
content. Leveraging components such as electronic forms (eForms), we can
automate the paperwork that the agent is required to fill out to initiate the claim.
Leveraging database lookups within the electronic forms, we can pull up the
customer’s information such as the address, make and model of the vehicle, and
the VIN number.
The electronic form can take items such as customer number, policy number, or
customer name, and retrieve the additional information required to start the claim
approval process. The initial claim document can be combined with additional
supporting documents about the claim and stored in the content repository
together. If there is ever a need to look up and review any of the customer’s
documents, we can find them all filed in the same system and using a single
search interface. IBM FileNet Business Process Manager leverages the stages
and life cycle of the content and makes it an active part (active content) of the
business process.
IBM FileNet Business Process Manager has a routing capability that facilitates
the routing of content to other users, processes, or systems. In addition to
automatically routing the claim package to a field agent, we can also leverage
the conditional routing capability to assign the right field agent to handle the
claim, based on data such as the policy holder and the location of the loss. IBM
FileNet Business Process Manager can remove time consuming tasks such as
interoffice mail routing, manual lookup, and assignment of field agents. We can
leverage database lookups and Web services to find out how to get the right
information to the right person at the right time.
Delays in getting the supporting documents to the adjustor can slow or halt the
claim approval process. After receiving the claim package, the adjustor reviews
the entire claim package and decides to either approve or reject the claim.
Alternatively, the adjustor escalates the claim to a supervisor. The approved
claim goes to the accounting department for payment and record keeping. This is
step 5 in Figure 2-1 on page 25.
The adjustor might rely on several external systems to get all of the information
required to complete the customer’s claim. Working with the field agent to
process the claim, the adjustor uses the supporting documents to determine the
validity of the loss or the amount of monetary compensation that the policy holder
is entitled to receive.
The steps in this claim process can be delayed by dependencies on surface and
interoffice mail to get the claim packages and loss information to the field agent
and the adjustor. Other areas that can slow the process include the utilization of
external systems to locate other information required to process the claim. If the
field agent does not assign an adjustor when all the required documents are
available, the claim process can be further delayed. Automation in assigning an
adjustor and getting the right information to the field agent and the adjustor are
beneficial in removing latency from these steps.
IBM FileNet Business Process Manager can also automate the classifying and
processing of this content, thus ensuring that it is filed in the correct customer
folders. This enables fast discovery of content for future claims and can help
satisfy record management and compliance requirements.
In addition to the above capabilities, IBM FileNet Business Process Manager can
interact with external systems, data sources, and applications to get the
information required to process the claim. External systems can provide the
customer’s information, such as additional policies, previously submitted claims,
and pending claims, to the field agent and the adjustor.
The supervisor informs the adjustor if the claim is rejected. The adjustor then
informs the field agent of the decision. A letter outlining the reasons for the
rejection is generated and it is sent to the customer. The field agent notifies the
customer (either by phone or email) of the decision.
Using IBM FileNet Business Process Manager, we can use the routing capability
to automate the way the work goes from an adjustor to a supervisor. The routing
rule can be implemented with conditions that make it seamless for work to be
routed from the adjustor to the supervisor. After the work is completed (approved
by the supervisor if required and by the adjustor), it can resume its progress
along its defined path in the workflow, or it can be sent back to the point where it
started. IBM FileNet Business Process Manager also has the capability to
escalate the claim to another person such as a manager, if a certain amount of
time has expired (for example, three days).
IBM FileNet Business Process Manager has the ability to interact with external
systems and processes to automate the creation of letters or the generation of
payment for customers. After the letters, invoices, or purchase orders are
created, IBM FileNet Business Process Manager can automatically file the letter
along with the other documents from the claim in one place, making it simple to
find all related content items for the customer or the claim.
Figure 2-2 shows the main workflow process map that drives the claim approval
process.
Figure 2-2 Main workflow process map for the claim approval process
The activities of setting up a claim case that involves creation of a case (folder)
for the claim, assigning of a field agent, gathering of supporting documents, and
assigning of an adjustor are encapsulated in a workflow subprocess, which is
implemented as a separate submap. Figure 2-3 illustrates this claim setup
submap.
Figure 2-3 Claim set up workflow process submap for the claim approval process
By automating the process and using routing of the work to different people,
work (the claim package) can move seamlessly between field agents, adjustors,
supervisors, and the accounting department. IBM FileNet Business Process
Manager also interacts with external systems, making the generation and
distribution of letters to policy holders a simple, automated process. The process
is made more efficient and less error prone. Reporting and audit and archival are
simplified.
The three core engines for the IBM FileNet P8 Platform are:
Content Engine: The Content Engine provides software services for
managing different types of business-related unstructured content, which we
refer to as objects. It manages one or more object stores. An object store is a
repository for storing objects in an IBM FileNet P8 environment.
Process Engine: The Process Engine components allow you to create,
modify, and manage automated business processes. These processes are
performed by applications, enterprise users, or external users, such as
partners and clients.
Application Engine: The Application Engine hosts the Workplace Web
application, Workplace Java applets, and Application Programming Interfaces
(APIs). It is the presentation tier for both process and content.
Figure 3-1 illustrates the three IBM FileNet P8 engines and their relationships.
Application Engine
Web Client
Application
Client Tier
Process
Engine Middleware Tier
In the IBM FileNet P8 Platform, the functionality is exposed using the same tiered
architecture with other components in each tier. Those extra components provide
valuable features for the BPM functionality, including content management,
electronic forms, records management, collaboration functionality, and more.
Figure 3-3 shows a high level architecture of the IBM FileNet Business Process
Manager components.
Presentation Tier
Java Connector
...
PE Applications eForms
Java API
Middleware Tier
WS API
Content Process
Engine Engine Process Process Rules
BAM
Analyzer Simulator Framework
Data Tier
Figure 3-3 High level architecture of IBM FileNet Business Process Manager
components
Component Integrator
The Component Integrator is used to integrate Java or Java Message Service
(JMS) components for use in processes. Components are registered in the
Process Configuration Console to make them available in Process Designer.
Figure 3-4 shows a Java component that has been registered.
Application Engine
Java Component
Java adaptor
Component Integrator
Service Manager
Process Engine
Application Engine
Incoming message
WS Listener
WS Adapter
Outgoing message
Component Integrator
Service Manager
Process Engine
The Process Orchestration component can be started by the Task Manager and
it is composed of a Web services Listener that receives all the incoming
messages and a Web services Adaptor that is used to send outgoing messages.
Middleware tier
WS API
The IBM FileNet BPM middleware tier includes the following components:
Content Engine (CE) Kernel: The core Content Engine.
Process auto-launch: The event-driven component that launches process
instances in the Process Engine system. This component can be configured
to launch a specific process version in response to specific events. For
example, filing a document in a folder can launch a particular process in the
Process Engine system.
Process Engine (PE) Kernel: The core engine of the BPM system that
includes the execution sub-system.
E-mail Notification: Enables automatic transmission of e-mail to users when
specified process-related events occur. E-mail notification can also be used to
track processes.
WS API: Provides a Web services API to the Process Engine and to the
Content Engine.
Rules Framework: Provides a framework for rules engines to integrate with
IBM FileNet Business Process Manager. The framework uses a well-defined
rules interface that must be implemented to integrate with rules engines.
Process Analyzer: Provides analysis capabilities to determine cycle times,
find trends and bottlenecks, and generate reports and charts to analyze the
processes deployed in the Process Engine system.
Data Tier
Process
Process Process Task
Simulation
Designer Administrator Manager
Designer
Process Process
Step
Configuration Tracker Simulation
Processors
Console Console
Application Engine
Simulation Simulation
Designer Console
Scheduler
Content Process
Engine Publisher Engine
Process Simulator
Event Dispatcher
Publisher
Process Analyzer
Process Process
Analyzer OLAP Engine
Database Database
BAM Dashboard
BPF applications are built based on a case paradigm. For example, an auto
insurance claim can be considered a case. The generated application uses both
Content and Process Engine APIs. The application user interface is
metadata-driven and is built dynamically upon user request. The metadata
describing the user interface layout is stored in the BPF configuration database
and is managed via the BPF Explorer configuration tool.
Application Engine
BPF Web
Workplace BPF Explorer
Application
Content Process
Engine Engine
Figure 3-13 shows how a basic Web service is used. A client looks up a Web
service from a UDDI registry and obtains its WSDL. It then invokes the Web
service. In addition to UDDI, IBM FileNet Business Process Manager also
supports the IBM WebSphere Service Registry and Repository (WSRR).
Simply having a Web service or a Web services API does not imply Service
Oriented Architecture. It is the ability to orchestrate these Web services that is
fundamental in building or integrating with Service Oriented Architecture. The
ability to consume and publish Web services to create higher value services is an
essential aspect of a Service Oriented Architecture. IBM FileNet Business
Process Manager provides the facilities to participate in a Service Oriented
Architecture.
1
For an explanation of isolated regions, refer to “Isolated regions” on page 50.
Map
queue roster Event
log
Queue Roster Step
Log Step Step
Step
Isolated Region
Compile
queue roster Event
log
Queue Roster
Log
Work
Item
Process server
A process server is a physical machine designated as a member of a Process
Engine system. A Process Engine system is a farm of Process Engine servers,
with one or more servers. A process server can only be a member of one
Process Engine system. The process server runs the Process Engine software.
Isolated regions
An isolated region (as illustrated in Figure 3-14) is a logical subdivision of the
Process Engine database. Isolated regions are often used to provide separate
development, testing, and production environments which enable developers
and testers the ability to efficiently utilize shared computing resources and
provide the necessary isolation between these disparate activities. An isolated
region consists of queues, rosters, and event logs.
A roster is a database structure that stores the current location and other
information about a work item. Process rosters provide the Process Engine
software with an efficient way to locate a specific work item. An event log is a
database structure that contains information about system-level events related to
work item processing.
Process definition
A process definition (as illustrated in Figure 3-14 on page 50) describes a
business process. It includes information such as fields and maps used in the
process.
Process instance
A process instance corresponds to a single execution of a process definition.
For example, the auto insurance claim for Account 120-021 is an instance of the
claim process definition, where the Account field has the value 120-021. A
process instance consists of work items.
A work item is a single unit of work composed of a collection of fields. Work items
transverse the process map, moving the data required by the process from step
to step as indicted by the map.
People who perform tasks are participants for the defined tasks. In a business
process, participants are assigned specific work that must be completed at one
or more steps in the workflow. Participants can be people, a group of people, a
department, or a system.
From the auto claim approval process example, we identify the following tasks:
Interact with policy holders.
Create and submit claim packet.
Review submitted claims packets.
Assign field agents to claims.
From the auto claim approval process example, we also identify the following
participants:
Agents
Adjustors
Field agents
Accounting department
Administration department
Finance department
Mail room
Roles tie tasks to participants. From our example, we identify the following roles
in the claim approval process:
Agents who interact with policy holders and create and submit claim packets
Adjustors who review the claims packets and assign field agents to claims
Field agents who gather supporting documents for claims
Accounting department that processes claims and issues claim settlement
funds to policy holders
Administration department that performs administrative tasks such as
classifying claims that are received in the back office, and sends initial claim
packet to the adjustors
Finance department that approves or rejects claims
Mail room that classifies and processes claim packets that are received from
the field agents
Workflow group
A workflow group represents a collection of one or more users or groups that
can be assigned as workflow participants. The members of a workflow group
typically perform a particular task or a set of tasks in a business process, for
example, claims adjustors or supervisors.
For flexibility in defining a workflow, you can either assign one or more specific
participants to a workflow group, or allow the participants to be assigned later,
either as part of the launch process or at a particular step when the business
process is running. This technique of using unspecified workflow groups in a
workflow definition is useful when the participant for a particular task is likely to
change each time the business process runs.
All assigned members of the F_Trackers group become workflow trackers, with
access to the Process Tracker application. Although it is not required, every
workflow definition should have one or more users or groups assigned as
trackers to monitor events and help resolve problems when a process is running.
Attachments
An attachment is a link to information that a participant uses to complete a step in
a workflow. The specific item that an attachment links to is referred to as a target
in the Process Engine documentation. The most common target is a document
located in an object store. However, document arrays, stored searches, folders,
URLs, or files located on a shared disk can also be targets.
You define attachments as part of the workflow definition properties, and then
indicate which attachments will be used at each step.
Using our claim approval example, we can design a matching step for each
identified task in the claim approval process. If a task is complicated, you can
break the task into multiple subtasks, thus multiple steps.
4.1.4 Routing
Routing specifies the sequence in which steps are executed in a business
process. A route represents the path between two steps and defines the order in
which steps will be processed. Aside from the first step and the last step in a
business process, all other steps can have one to many inbound routes and one
to many outbound routes.
There are three ways to incorporate routing options and responses in a business
process:
Single (linear) routing
Conditional routing
Parallel routing
Single routing describes a route in a business process where work can only
continue along a single path. At most, one step in the workflow is active. There
can be one or more outbound routes defined for a step, but only one step can be
active at a time.
Let us see how different routes can be used in the claim approval example. We
have the following two steps:
Step A: An agent documents a loss due to an auto accident by a policy
holder, and submits a claim packet to the back office.
Step B: The mail room clerk logs and adds a timestamp on the claim packet
in the back office.
The routing between these two steps is straightforward, single routing. There is a
single active path from one step to the next. The task in the first step must be
completed by the agent before the task in the second step can be completed by
the mail room clerk.
Continuing with the same example, with some deviation for the purpose of
explanation, we assume that after the mail room clerk logs the claim in the
system (Step B), we have the following steps:
Step C: A field agent needs to assess and report property damage.
Step D: A medical reviewer needs to assess and report injuries resulting from
the accident.
Step E: When the property damage report and the injury report are filed, then
the adjustor decides the claim amount.
Since Step C and D are two steps that are independent of each other, we can
design them to work in parallel. Thus, we can use parallel outbound routing from
Step B, to go to Step C and Step D in parallel. Then we can have a collector step
to ensure that both finish before it routes to Step E.
Routes ensure that work is sent to the right participants to be processed. The
combination of defined steps and routes becomes a template that is used each
time the business process runs.
Each milestone can be used in one or more steps. The status message can be
either specific text, or it can include the values of one or more data fields. When
the workflow process reaches a milestone, the specified message can be
displayed for participants and users who launched the workflow.
4.1.6 Deadlines
Deadlines are time-based constraints that can be applied to steps in a business
process. A step with a deadline implies that the participant must complete the
step within a specified amount of time. The specified time (the deadline) is
relative to the time that the step starts (when the participant receives the work
packet).
A participant that is routed a task with a deadline can receive a reminder of the
pending deadline via e-mail. When a deadline is reached, e-mail messages are
sent to the step participants (with the uncompleted step) and the workflow
trackers. Users can update their e-mail notification preferences to turn off
different types of e-mail notification. When a deadline expires, it can also be set
to trigger escalation such that the work packet is routed to a special escalation
step to be performed by a supervisor or some other participants. Using a
deadline provides added control and an escalation mechanism for a business
process.
Using our claim approval example, we have the following step that might require
implementation of a deadline:
Step: The adjustor assigns a field agent.
The adjustor assigns a field agent. If this task does not happen in a timely
fashion, it impacts the entire claim approval process. By adding a deadline on
this step, we can add some time management to the step to ensure that the
adjustor is not delaying the claim approval process. We can also set the
adjustor's supervisor as the tracker for the workflow (by adding the supervisor to
the F_Trackers group for the workflow). When a deadline or a reminder is
reached, both the adjustor and the supervisor are notified. Again, receivers of the
reminder have options to turn off different types of e-mail notifications.
Of course, we can also automate the field agent assigning step such that the
adjustor does not manually assign a field agent to the claim; rather, the system
automatically assigns a field agent based on the place of the incident. In this
scenario, a deadline is not required.
The task of gathering supporting documents for a claim might be a good step in
which to apply a deadline. Although a participant might not always be able to
complete a task in a timely manner due to factors outside of their control,
deadline mechanisms (including reminder e-mails and automatic escalations)
provide effective time management and control to ensure more timely completion
of a step.
You can implement the routing decision based on one of the following conditions:
When all participants select the same response (for example, when all
approve)
Let us see how this can be applied to the XYZ Corporation’s claim approval
business process example (we will deviate somewhat from the actual example
for the purpose of explanation).
We assume that, in the claim approval process, there is a step when the claim
approval decision task is escalated to a supervisor if the claim is determined to
be a high risk (for example, the claim amount is extremely high). According to the
business rules in place, multiple risk managers make the approval decision.
The supervisor thus routes the decision task to the risk managers who are
experienced in dealing with assessing risks. The risk managers review the claim
and then each either approves or rejects the claim. Per the business rule in the
example, as long as the majority of the risk managers approve, the claim is
deemed approved. In this case, we would implement the simple majority
condition for processing voting.
General functions
General system functions include the following functions:
if(bool_expr, expr2, expr3)
Conditional expression returns expr2 if true or expr3 if false.
sizeof(array_id)
Returns the size of the array.
Time functions
Time functions include the following function:
adddays()
Adds a specified number of days. Functions are also available for minutes,
hours, and so forth.
Queue operations
An operation is a function within a step that performs a specific task associated
with a particular queue. When an operation and its parameters are being defined,
Referring back to the claim approval example, there are areas where we can
leverage inter-related processes. Consider the following steps:
Step A: An agent documents a loss due to an auto accident by a policy
holder, and submits a claim packet to the back office.
Step B: The mail room clerk logs and adds a timestamp on the claim packet
in the back office.
If the claimant’s car is no longer operational due to the accident and the
claimant’s policy covers the cost of a rental car while the claim is being
processed and the car is being fixed, then we can add a few new steps in
between the above two steps to get the claimant a rental car immediately.
For the purpose of explanation only, using this example, we can add steps for a
rental car reservation. The resulting business process looks like this:
Step A: An agent documents a loss due to an auto accident by a policy
holder, and submits a claim packet to the back office.
Step A2 (new step): The agent performs an initial review on the claim.
Step A3 (new step): If the claimant claims that the insured car is no longer in
operation due to the accident and the policy allows for a rental car in this type
of situation, then the agent calls another entity within the company to set up a
rental car for the claimant, gets the rental car confirmation number back from
the entity, and passes that confirmation information to the claimant.
In Step A3, another group is involved in making a car reservation for the claimant
or any individual within the company. This is an independent business process
performed by the group. If it already exists for the company, then the claim
approval process can call the car rental process to perform the task. The agent,
involved in the claim approval process, does not have to understand the actual
process of reserving the rental car. All it requires is for the agent to pass the
necessary claimant information and retrieve the confirmation number later.
If, at the design time of the claim approval process, the car reservation process is
not created within the system, you can create this separate process and call it in
the claim approval process.
For the rental car reservation process that is mentioned in 4.3, “Inter-related
processes” on page 64, the reservation process can be a process performed by
the rental car company that is transparent to the agent. If such an automated
process exists in the rental car company, then the claim approval process can
interact directly with the external process to make the appropriate rental car
reservation. All the process has to do is to have the agent to approve the rental
car, after which it requests the external reservation process to reserve the car
and retrieves the reservation number automatically.
Which technology to use (either Component Integrator, Web services, or the EAI
connector) depends on how the external system works and what is available for
the claim approval process to interact with the external system.
For more information regarding direct interaction with the external systems, refer
to Chapter 7, “Integration with external systems and services with BPM” on
page 257.
For process design concepts, refer to the previous chapter. For creating a case
study business process using Process Designer with step-by-step instructions,
refer to the next chapter.
Using Process Designer, you can create the specifications for each step in a
business process, including which participant processes the work for the step;
what interface application (also known as a step processor) the participant uses
to perform a task; what attachments, if any, are required for the process; what
data is necessary to view, add, or edit; what responses the participant can
choose; and what routes to take within a business process. The electronic
representation of the business process designed in Process Designer is called a
workflow definition (also known as a process definition).
Note: After launching the Process Designer application, do not close the IBM
FileNet Workplace Internet Explorer® window. Closing the Internet Explorer
window will result in the closing of the Process Designer application.
Figure 5-3 shows the Process Designer user interface. The window consists of
the Map pane, Properties pane, and Step Palette pane. There is also a set of
toolbar icons on top of the Map pane.
Note: This book is written based on Version 4.0 of IBM FileNet Business
Process Manager. For release 4.5 or later, some of the user interface,
including menus and toolbar, might be changed.
Figure 5-4 shows the Properties pane for the LaunchStep. For this step, you can
provide the user with instructions for how to complete the step in the General tab,
select parameters to read and write in the Parameters tab, modify parameter
values in the Assignment tab, and specify routing information in the Routing tab.
We discuss the various settings in the Properties pane for different steps and
routing in later sections.
Figure 5-5 shows the Step Palette drop-down menu in Process Designer.
BPM Palette
The BPM Palette (Figure 5-6) contains common types of steps you use for a
workflow.
General steps are used to handle basic workflow activities (tasks) that are
performed by an individual participant or a group of participants. System steps
are used to call built-in system functions. Component steps are used to call
operations from an external application.
To simplify a workflow map, you can break a workflow into one main map and
several smaller submaps. To call the submap from a main map, you insert a
Submap step and specify which submap to call at the step. A submap can call
other submaps.
The General System Palette comes with the following types of steps:
Assign
Create
DbExecute
Delay
Log
Return
TerminateBranch
TerminateProcess
WaitForCondition
All of these system functions can be called directly in the system step available
from the BPM Palette. The difference is visual. By using the system step from the
BPM Palette, you do not know what system function the step calls in the map
unless you look into the step properties (or you can provide a very descriptive
name for the step that shows on the map). If you use the step from the General
System Palette, you can tell what the step does by its name.
Timer Palette
The Timer Palette (Figure 5-8) contains steps that allow timer functions to
interact with steps in the workflow definition. The timer functions are used to
specify processing time limitations for steps in the workflow. This is different than
the deadline function we discussed earlier in Chapter 1, “Overview” on page 1.
A deadline applies to a specific step. A timer usually applies to a series of steps.
CheckPoint Palette
The CheckPoint Palette (Figure 5-9) contains steps that allow the checkpoint
system functions to interact with steps in the workflow definition. The checkpoint
functions provide mechanisms that allow data field values of work items to be
rolled back to an earlier state. Checkpoint functions also make it possible to
resume processing for work items at a previous point in the workflow.
My Palette
This palette allows you to create your own collection of step types you use most
often in designing your workflow. For example, if you create a custom step that is
reusable in another workflow, you can add the custom step to My Palette (drag it
from the workflow map in the Map pane) and then use it later for a different map.
You can treat My Palette as a temporary holding place for commonly used or
reusable steps.
We cover what you can set for each step in later sections. For more detailed
information about what each step does, refer to ecm_help.
The Workflow Properties, Validate Workflow, and Launch Workflow icons are
commonly used while you create your workflow. We use these icons as we
create our case study for the book.
For each step, you specify the actual participants that will process work items at
this step, as well as the data fields available at this step for reading and writing by
systems or participants. There are other configurations that you can set up in
each step, depending on the type of step. Figure 5-12 illustrates the elements
that comprise a workflow definition.
Map
Step
Route
Step Step
Route
Route Step
To create a workflow definition, you must set up workflow properties and create
the appropriate workflow maps.
To set or view the workflow properties, click the Workflow Properties icon from
the toolbar in the Process Designer, or select View → Workflow Properties
from the menu. See Figure 5-13.
General tab
Figure 5-14 shows the General tab in the Workflow Properties dialog box.
The General tab allows you to specify general information for the workflow,
including base workflow, name, subject, description, and deadline.
Advanced tab
Figure 5-15 shows the Advanced tab in the Workflow Properties dialog box.
The Advanced tab allows you to specify advanced features for the workflow,
including roster, event log, condition identifier, and e-mail notification.
The Data Fields tab allows you to define all data fields that can be used in
workflow steps. When you define each step, you specify which data fields are
parameters for that step, and what access permission the participants have to
modify the values. Enter the following information for each data field:
Name
Enter the name for the data field.
Type
Select one of the data types for the field: Boolean, Float, Integer, String,
Time. If the field has multiple values, then select the array version of the type
indicated by brackets [].
Merge Type
Specify how values will be merged when necessary.
A step in a workflow can have multiple outgoing routes if multiple tasks
(following this step) can be performed in parallel. When they merge back to
one step, this field specifies how values from multiple sources of the same
data type are to be merged into one. The default for Merge Type is Override.
Expression
Specify an initial value for the field. String fields can be blank, but all other
types require an initial value. The value must match the data type and meet
the requirements for expressions. From our example in Figure 5-16, we use
systemtime() for several date fields.
Attachments tab
Figure 5-17 shows the Attachments tab in the Workflow Properties dialog box.
The Attachment tab allows you to specify attachments that participants use in
workflow steps. Attachments include documents and URLs. For each
attachment, specify the following information:
Name
Enter the name for the new attachment.
Array
Specify whether there are multiple attachments. If the Array checkbox is
selected, it represents multiple attachments. For our example, as shown in
Figure 5-17, we select the Array checkbox for SupportingDocs. This is
because we expect the workflow to have multiple supporting documents.
Value
Specify a value for the attachment. If it is a file or folder in an object store or
library, you can double-click the field and select one from a list. Alternatively,
you can leave it blank. This allows the value to be assigned at the workflow
launch time or by a participant during workflow processing.
Description
Provide a description for the attachment. This is an optional field.
The Workflow Groups tab allows you to specify an individual user or a group of
users who can be assigned as participants in the workflow. For each workflow
group, specify the following information:
Name
Enter a name for the workflow group.
Participants
Select users for the workflow group. Click Modify to select users.
If a step is processed by a workflow group, then the participant or the group
must be defined in the workflow group here before the step can use it in its
setup.
Descriptions
Provide a description for the workflow group. This is an optional field.
Maps tab
Figure 5-19 shows the Maps tab in the Workflow Properties dialog box.
The Maps tab allows you to specify the main workflow map and the submaps that
you use in your workflow. You can create more flexible and modular workflow
definitions by creating submaps. In addition, you can redefine the behavior of
maps that are inherited from the base workflow. For example, by default, you get
Terminate and Malfunction submaps. Using submaps and the ability to redefine
inherited maps enable you to create custom actions and processing for your
workflow process.
If there is a down-arrow icon next to the map, it means that the map is inherited
from another map. If you create a new map from scratch, there will not be an icon
next to the map.
Figure 5-20 shows the Maps tab with a newly created submap called Claim
Verification. Clicking the Map Usage icon on the upper right corner reveals the
map that calls the Claim Verification submap. See Figure 5-21.
Milestones tab
Figure 5-22 shows the Milestones tab in the Workflow Properties dialog box.
The Web Services tab allows you to specify Web Services to be used in the
workflow. Set the following information for the Web Services:
General tab
Enter general settings for invoking or providing Web services.
Figure 5-24 Workflow Properties - Web Services -> Partner Links tab
Figure 5-26 Workflow Properties - Web Services -> XML Data Fields tab
We discuss Web services and how to set one up in later chapters of the book.
There are two other steps that can be found on a workflow map:
Launch step (the default first step in a main workflow map)
Start step (the default first step in any submap)
Figure 5-27 illustrates what some of the steps look like in a workflow map. Notice
that for each type of step, there is a different icon symbol representation.
General steps
Adding a step
To add any step to a workflow map:
1. Use the Step Palette drop-down menu and select the appropriate palette.
Usually, this is the BPM Palette.
2. Select the step icon from the palette and drag it to the Map pane.
The user can also add a step to the map using the map's context menu.
Configuring a step
To configure a step that you added to a workflow map:
1. Select the step icon in the workflow map.
2. Edit its properties in the Properties pane.
Depending on the type of the step, you can configure different settings for it.
We cover that in more detail later in this section.
Deleting a step
To delete a step from a workflow map:
1. Right-click the step icon in the workflow map.
2. Select Delete from the context menu.
You cannot delete the default steps (launch step and start step) that are always
included in a main workflow map and its submaps.
You can assign a task to a work queue in the general step. Anyone who has
access to the work queue can perform the task. Assigning work to a work queue
offers more flexibility than assigning a task to an individual. How you assign tasks
depends on your business practice.
Many of the configuration settings for the general step apply to other types of
steps. Use the setting discussed here as a reference for configuring similar
properties for other types of steps.
To configure a step, provide a name in the Name field of the Properties pane. We
recommend providing a meaningful, descriptive name. The name appears in the
workflow map below each step icon and it provides information about what the
step does.
Other properties of a general step can be configured through the following tabs:
General tab
Deadline tab
Parameters tab
Assignments tab
Routing tab
If you configure your workflow to use a rules engine, there is also a Rules tab. It
is beyond the scope of this book to cover rules engines. We do not discuss the
configuration of rules engines in this book.
General tab
Figure 5-28 shows the General tab in the Properties pane for a general step.
The General tab allows you to configure general information about the step, such
as the participant’s instructions for the step, the step destination, and the step
processor.
Deadline tab
Figure 5-30 shows the Deadline tab in the Properties pane for a general step.
For time management, you can set a deadline for when the task should be
completed at this step. Reminders can also be set to notify participants of an
approaching deadline. The deadline set in the workflow properties applies to the
entire workflow process. The deadline set here applies to this step only.
Setting up a deadline for a step is optional. You can choose not to set deadlines,
or selectively set up different fields. For example, you can set up a Complete
within field, without setting up the Send Reminder and Deadline Submap fields.
You can specify the operations and parameters that can be used for read and
write at this step. Parameters include data fields, attachments, workflow groups,
and XML fields. You can use the parameter values to help you perform the task
at this step or update their values as part of the task. There is a list of available
parameters for you to choose from. If the one you want does not appear in the
Available Parameters list, go back to the workflow properties and add it there.
Also, the checking of any of the four icons above the list determines what
parameters appear on the available list.
Assignments tab
Figure 5-31 shows the Assignments tab in the Properties pane for a general step.
Setting up assignments for a step is optional. You can choose not to set them or
selectively set up different fields. For example, you can set up Milestone without
setting up Field Assignments and Attributes information.
Routing tab
Figure 5-31 shows the Routing tab in the Properties pane for a general step.
There are three options listed under the Outgoing Routing information:
Approve
Escalate
Reject
These show the possible outgoing routes from this step. They are configured
when you set up the outgoing routes for the step (which we discuss later in the
route configuration section).
Notice that, although you cannot change the outgoing routes in this step, you can
specify the order in which the route conditions are evaluated. Select any one of
the outgoing routes and click the up and down arrows next to it to rearrange its
order in the list. Depending on how you set up the condition, sometimes the order
of the condition might become important.
Figure 5-35 shows the main workflow map with the Adjustor Review step.
As long as any participant selects the Approve response from the Adjustor
Review step, the next step goes to the Generate Letter step. If any participant
selects the Escalate response, then the next step goes to the Supervisor Review
step. If the response is Reject, then the next step goes to the Claim Rejected
step.
If multiple tasks can be performed in parallel after this step, you can select the
option All true conditions.
Figure 5-35 on page 100 shows our example, the main workflow map. In the
map, there is a submap step called Claim Setup. This submap step calls the
Claim Setup submap as shown in Figure 5-36. The submap encapsulates all the
tasks of setting up the claim, allowing the main workflow map to hide the details.
If you configure your workflow to use a rules engine, there is also a Rules tab. It
is beyond the scope of this book to cover rules engines. We do not discuss the
configuration of rules engines in this book.
The General tab allows you to configure general information about the step, such
as the submap to call and the description.
You can set up attributes to be used in the submap step for special processing.
Attributes are valid only within this step. Unlike parameters, which can be used
throughout the entire workflow, attributes are created and used only at the
particular step.
From the Attributes tab, for each attribute that you want to use, set up the
following information:
Name
Enter a name for this attribute.
Type
Select the attribute type, including boolean, float, integer, and string. Attribute
type also supports arrays.
Value
Enter a value for the attribute. Note that you cannot use Expression Builder
for an attribute value.
Setting up attributes for a submap step is optional. For our example, we do not
set up any.
In the Routing tab, you configure how the step handles the incoming routes and
how it processes the outgoing routes.
Clicking Details on the bottom of the Routing tab shows the routing condition
that is set from this step to the next step. Figure 5-40 shows the outgoing routing
conditions from the Claim Setup step. If the VehicleEstimationAmount is greater
than 3000, then it goes to the Adjustor Review step. If the estimated amount is
less than or equal to 3000, then it goes directly to the Generate Letter step.
There are several tabs available where you can configure a system step:
General tab
Attributes tab
Routing tab
The configuration of the last two tabs is similar to that of a general step and a
submap step. We discuss only the general tab here.
From the general tab, provide a description for the system step. For each system
function that you want the system step to perform, follow these procedures:
1. Select the system function from the Available Functions list.
2. Click the right arrow icon.
3. After the system function appears in the Selected Functions list, double-click
it.
4. Depending on the type of the system function you added, enter appropriate
configuration information.
The best way to learn how to use various system functions is to try them out in
Process Designer. The settings for the system functions are fairly intuitive. We
do not cover the configuration of each of them in detail. For detailed information,
refer to ecm_help.
Figure 5-42 shows the Claim Setup submap with the component steps.
Component steps
There are several tabs available where you can configure a component step:
General tab
Attributes tab
Routing tab
The configuration of the last two tabs are similar to that of a general step, a
submap step, or a system step. We discuss only the general tab here.
General tab
Figure 5-43 shows the general tab in the Properties pane for a component step.
The general tab allows you to set up the component and the operations that you
use at this step.
Operation Parameters
Enter the necessary parameter information (their names, types, and values in
the expression column) required for the operations in this step. Not all
operations require parameters. For our example, as shown in Figure 5-43,
only the file() operation requires two parameters:
– sourceDocument
– destFolder
Both of these parameters are of attachment type. The file() operation files the
claim related documents (sourceDocument) to the claim folder (destFolder).
Adding a route
To add a route between two steps in a workflow map, do the following procedure:
1. Move the mouse over the starting step until the route symbol appears.
2. Drag the route from the starting step to the ending step.
Deleting a route
To delete a route from a workflow map:
1. Right-click the route in the workflow map.
2. Select Delete from the context menu.
If there is only one outgoing route from the current step to the next step, that is, if
the workflow process always goes from the current step to the next step, then
select Always true. Figure 5-46 shows routes in the main workflow for our
example. From the Launch step to the Claim Setup step, there is only one route.
Thus, for the example, we select Always true in the Properties pane. Notice that
when Always true is selected, you cannot configure anything else for the route.
If there are multiple routes coming from the current step to other steps, you
select Condition for the route. You can configure the routing condition based on
responses that the participants select in the current step (where this route comes
from) or based on values of the data fields in the workflow process. You can also
use the combination of both responses and data fields to set up the routing
condition.
The data fields used for conditional routes, such as data fields, attachments, and
workflow groups, must be defined in the workflow properties.
With multiple outgoing routes, configure the condition for each route so the
system understands under which condition a specific route is taken.
For a route that is set as Condition and not as Always true, configure it with the
following tabs:
Responses tab
Data fields tab
Response tab
When a participant completes a task at a step, you can set up a list of responses
that a participant can select. Each response corresponds to an outgoing route
from the step.
To configure the route based on the responses, configure the following fields in
the Response tab:
Condition
Select one of the condition options:
– ALL: Return true if all participants select a particular response.
– NONE: Return true if none of the participants selects a particular
response.
After setting the condition, click the Insert button to add the expression on the
condition field. You can manually edit the condition expression also. After you
insert the condition for a route on the bottom entry box, it does not matter what
values are selected or shown in the Condition, Response, and other fields
mentioned previously. Always make sure that the condition appears at the
bottom before continuing. See Figure 5-47.
Figure 5-47 Properties pane - Conditional Routing for the Approve route
Remember that you must define a list of available responses at the step from
which the routes originate. At each route leading from the step, you set the
condition for when each route should be taken.
Note: If there is only one participant processing the task at the step, then the
condition ANY and ALL would be the same.
Figure 5-48 Properties pane - Conditional Routing Data Fields for a route
To set up the condition, use the following fields to construct an expression for the
condition and then click Insert:
Field: Select a data field to be used in the condition expression.
Operator: Select the operator to evaluate the condition.
Value: Select a value to evaluate the condition.
Remember that, after you select and set the field values, click Insert to add the
condition for the route. You can manually edit the condition using AND, OR, and
parentheses to create complex expressions.
For the example shown in Figure 5-48, we have the following condition:
EstimateVehicleAmount>3000
This means that the route is taken if the estimated repair cost for the vehicle is
less than 3000.
Note: Set up condition routing carefully. If you have multiple outgoing routes
from a step, yet none of the conditions in the routes returns true, the workflow
will stop and produce an error.
A new workflow can inherit the following items from a base workflow:
Main workflow map
Submaps
Data field, attachment, and workflow group definitions
Workflow deadline and reminder
Milestones
Event log
Roster
Condition Identifier
Partner link and XML schema
XML data field
Incoming Web services attachment folder
Rule set names
E-mail notification preference
Let us look at some examples. Figure 5-49 shows two workflows, Workflow A
and Workflow M, and their local and inherited workflow properties.
Workflow M inherits some of the items from Workflow A and overrides others.
Workflow M contains the following items:
Main workflow map M (which overrides the one from Workflow A)
Submap a1* (which overrides the one from Workflow A)
Submap a2 (which is inherited from Workflow A)
Submap m1 (which is new for Workflow M)
Data fields a1 and a2 (which is inherited from Workflow A)
Data field m1 (which is new for Workflow M)
Now adding a new Workflow R, we have the workflow inheritance flow hierarchy
for these three workflows as shown in Figure 5-50.
If inheritance is disabled, then Workflow R contains only the following items (see
Figure 5-51):
Main workflow map R (which is new for Workflow R)
Submap rm1 (which is new for Workflow R)
Data field r1 (which is new for Workflow R)
All other inherited main maps, submaps, and data fields are no longer available.
From Figure 5-52, Workflow N, which inherits from Workflow A, contains the
following items:
Main workflow map N (which is new for Workflow N)
Submaps a1 and a2 (which are inherited from workflow A)
Submap n1 (which is new for Workflow N)
Data fields a1 and a2 (which are inherited from Workflow A)
Data field n1 (which is new for Workflow N)
When inheritance is enabled and we switch the base workflow for Workflow R
from Workflow M to Workflow N, Workflow R now contains the following items:
Main workflow map N (which is inherited from Workflow N)
Submaps a1 and a2 (which are inherited from Workflow A through N)
Submap n1 (which is inherited from Workflow N)
Data fields a1 and a2 (which are inherited from Workflow A through N)
Data field n1 (which is inherited from Workflow N)
Submap rm1 (which is new for Workflow R)
Data field r1 (which is new for Workflow R)
By comparing the resulting main workflow map, submaps, and data fields of
Workflow R now with the one earlier (which inherits from Workflow M), you can
see how inheritance works.
IBM FileNet Business Process Manager comes with a set of default system
submaps that you can use for your workflow: Malfunction and Terminate maps.
You can customize them for your business requirements.
Malfunction map
The malfunction map executes whenever an error occurs during workflow
processing. When an error occurs, the malfunction map moves the work item to a
system queue to be reviewed by an administrator. After the work item is reviewed
and the error condition is resolved, the work item can be returned to either the
calling step where the error condition occurred or it can be routed to the next step
in the business process.
Terminate map
When a process is complete, the work item is routed to the Terminate map.
There are no steps associated with the Terminate map and there is no need to
explicitly call it from the main workflow. Each workflow map automatically calls
the Terminate map at the end of the workflow.
In most cases, there is no need to work with the Terminate map. The system
executes it automatically. By default, the Terminate map is read-only, but you
can override it to embed common terminating steps for your workflow process.
Use caution when changing the default behavior of the Terminate map. Test
thoroughly to avoid unexpected results during workflow processing.
Choose the desired category items from the pick list to be added to the
expression.
Figure 5-56 shows the data fields available for the workflow.
Figure 5-58 shows the functions that are available to be used in an expression for
the workflow.
Note: Click the Clear button to remove the content from the expression area.
You can use a combination of data fields, system fields, functions, Workflow
Groups, and other categories to build the expression. If you manually edit the
expression, make sure the syntax is correct.
To type literals into the expression area, enter values in the appropriate format:
Strings must be enclosed in quotes.
Array values must be separated by commas (,) and surrounded by braces {}.
Note: This book is written based on Version 4.0 of IBM FileNet Business
Process Manager. For release 4.5 or later, some of the user interface,
including menus and toolbar, might be changed.
Not all the steps have to be created in the sequence we describe here. For
example, it is common to create a simple workflow map, with all the steps and
routes first drawn in Process Designer, before going into more detail of defining
each step. This is a top-down approach where you define all the elements (steps
and routes) on the map graphically and then define each element in detail.
Another approach is to define each element in detail as you build the entire map.
In addition, you can decide when to build the submap and when to build the Web
services or Component Integrator steps. Based on your preferences, you decide
how you want to build your workflow.
To store content in Content Engine, you must first define the object model using
the IBM FileNet Enterprise Manager. It is beyond the scope of the book to show
you how to define the object model step-by-step. However, for your convenience,
we provide the XML data files that you can import into the Content Engine so that
you can follow the steps we show here for our case study.
ClaimID N
Last Name N
DocType Y
DocType String
Misc Misc
Define an entry template. Set the folder, properties and security as shown in
Table 6-6.
Folder Incoming
Set the Document Entry Template properties as shown in Table 6-8. Set the
Entry Template security settings as shown in Table 6-9.
#AUTHENTICA
TED-USERS
Administrator
Under option 6, select Folder and Document Title. See Table 6-11.
Tip: Roll your mouse over the tool bar below the main menu to locate the
shortcuts to frequently used functions, such as the Workflow Properties
icon.
4. From the Workflow Properties dialog box, click the Data Fields tab. This is
where you specify all the data fields (parameters) that are used for the
workflow process. In this tab:
– Add the data fields used for your workflow process. For each data field,
double-click the Name cell to enter its value and press Enter. Use the
drop-down box under the Type to select the data type. Also, enter
information for Merge Type, Expression, and Description. If you decide
later that you need additional fields, you can come back to this tab and
add more fields.
For our case study, we enter the data fields as shown in Figure 6-6.
Tip: Before adding a number of data fields of the same type, change
the data field type to the one you use the most. Each subsequent data
field entry automatically uses this type. For our case study, we use
String frequently, so we change the Type to String, and then add the
rest of the data fields.
There is always one extra line in the end. Ignore that line.
5. From the Workflow Properties dialog box, click the Attachments tab. This is
where you specify all the attachments that can be added during the workflow
process. Attachments can include folders, IBM FileNet P8 documents and
objects, and external documents that are a part of the work item for the
workflow process. In this tab:
– Add attachments used for the workflow process. For each attachment,
enter Name, Value, and Description.
For our case study, we enter attachment information as shown in
Figure 6-7.
– If there are multiple attachments of the type specified, select the Array
check box. If there is only one attachment of the specified type, leave the
check box blank.
For our case study, we might have multiple SupportingDocs. We select
the Array check box for that attachment type. For other types of the
attachments, such as ClaimForm and PolicyDoc, we leave that check box
blank.
– To enter a value for the attachment, double-click the value cell and select
an item from an existing object store.
For our case study, the workflow process uses a search template to
search for claims during one of its tasks. We need to add this search
template as an attachment for the workflow. We call this attachment
ClaimSearchTemplate and it uses a search template that is already
created in the system as its value. The existing search template, called
Search for Claim ID, searches from the system and returns the claims with
a given Claim ID. To specify the existing search template (Search for
Claim ID) as the value for the attachment (ClaimSearchTemplate), use the
following steps:
i. Select the attachment, for our case study, ClaimSearchTemplate.
ii. Double-click the corresponding Value entry. This displays a Browse for
item window as shown in Figure 6-8.
iii. Navigate to the location where the search template (Search for Claim
ID) is stored. In our scenario, double-click objectstore → Case Study
Searches, and select Search for Claim ID. See Figure 6-9.
For our case study, we also select values for other attachments as shown in
Table 6-12.
6. From the Workflow Properties dialog box, click the Workflow Groups tab.
This is where you specify the workflow groups that are used in a workflow
process. A workflow process has multiple steps. Each step can have one or
more participants performing tasks. The participant can be an individual or a
group of people. If it is a group of people, you define the group of people as
the workflow group in this tab.
Enter the workflow group name by selecting the Name cell and typing in the
workflow group name or use the pencil icon to add or modify the workflow
group:
a. Click the Modify (pencil) icon. See Figure 6-10.
c. A list of users or groups appears that matches the characters you typed in
the Starts with field. Select the users or workflow groups and click the Add
button. See Figure 6-12.
d. Click OK.
For our case study, we add Adjustor, Field_Agent, and CreatedBy as the
workflow groups as shown in Figure 6-13.
7. From the Workflow Properties dialog box, there are other tabs including the
Maps, Milestones, and Web services tabs. In these tabs, you can specify
other workflow maps that you use, any milestones you want to establish, and
any Web services that you want to use within the workflow process.
For simplicity of the first basic workflow, we do not define anything in these
tabs at this point in time for our case study.
8. When everything is defined in the Workflow Properties dialog box, click
Close.
Note: Use IBM FileNet Add New for the first time check-in only. After the
initial check-in, use IBM FileNet Open/Checkout, IBM FileNet Checkin,
and IBM FileNet Cancel Checkout functions to manage the versioning of
the workflow process.
2. The Save the workflow definition to an object store dialog box displays as
shown in Figure 6-15. Click Browse and navigate to a folder where you want
to store the workflow process. To navigate, select a folder and click Open or
double-click the folder.
For our case study, we browse to the Case Study Process folder as shown
in Figure 6-16 and click Select.
4. The dialog box prompts you to enter a document title for the workflow
process. See Figure 6-18. Enter a descriptive name and click Finish.
Tip: To test your workflow process, you can click the Launch icon on the
toolbar (the icon on the far right).
Notice that from the preference dialog shown in the figure, you can also set
whether you want the system to automatically validate your workflow before
you transfer or launch the workflow.
The default palette is the BPM Palette. To see steps that are available for a
different palette, click the drop-down arrow next to the palette name and select a
different palette. Provided palettes include CheckPoint Palette, General System
Palette, Timer Palette, and Web services Palette. You can also create your own
palette for convenience of workflow design.
Note: The pop-up menu from the first method displays only a list of steps
that are available from the BPM palette. To add steps other than what are
available from the BPM palette, use the drag-and-drop method.
For our case study, we right-click at the map area and select New Submap
Step from the pop-up menu.
For our case study, we add six steps as listed in Table 6-13. We arrange the
steps as shown in Figure 6-23.
Deleting steps
If you want to delete a step from the map, right-click the step in the map and
select Delete from the pop-up menu.
To draw a route from one step (the from step) to another step (the target step):
1. Place the mouse cursor at the edge of the from step so that the cursor
changes to the one shown in Figure 6-24.
2. Left-click, hold, and drag the cursor to the target step and release the mouse
button.
3. Enter a name for the route in the Properties pane Name field located at the
right side of the Process Designer. The route name becomes the label of the
route on the map. Naming a route is optional.
Tip: If there are multiple routes leading from one step to other steps, we
recommend providing a descriptive name for each route. This makes the
map easier to read and understand.
4. Add routes between all the steps as designed for your workflow process.
For our case study, we create routes as listed in Table 6-14. Figure 6-24 shows
the setup of our case study at this point.
Deleting routes
If you want to delete a route from the map, right-click the route and select Delete
from the pop-up menu.
If a step has multiple outgoing routes, you can specify the conditions with which
the routings happen, as follows:
1. Define the step’s routing responses if user responses are involved.
2. Configure the conditional routing to be based either on user responses or on
data fields.
Routing of work can be based on data field values used in the process or based
on user responses.
Note: The drop-down list should provide a list of the responses you
defined earlier for the step where this route comes from. If a response
you expected is missing from the list, probably you did not press Enter
earlier to register the response. Go back to the step and add the
missing response.
c. Click Insert.
If you make a mistake, you can click Clear to clear the routing condition
and restart again. Always remember to click Insert or else the condition is
not registered in the system.
For our case study, we set up conditional routings based on user responses as
listed in Table 6-16.
Note: The Field drop-down list shows a list of the data fields you set up
earlier in the Workflow Properties dialog box. If a data field you require is
not on the list, go back to the Workflow Properties and add the data field
there.
For our case study, we set up conditional routing based on data field values as
listed in Table 6-17. Figure 6-28 shows the setup of our case study at this point.
Note: We also recommend validating your map after you make any significant
change to the map.
To validate a workflow process map using the menu selection, select File →
Validate as shown in Figure 6-29.
Or, you can use the second method to validate a workflow process map, by
clicking the Validate icon on the toolbar, as shown in Figure 6-30.
If you receive more than the three errors mentioned, use the information in the
error dialog box to correct the problem before you continue with the rest of the
chapter.
Note: You can define the properties of steps at the same time when you build
the workflow process map. From our experience, it is best to create the map
first and go back to define the steps at a separate time. The sequence of
building the complete workflow process depends on your preference.
You can define the properties of each step at the Properties pane on the right
side of the Process Designer window.
For our case study, we set up properties for the following steps:
LaunchStep
Adjustor Review
Supervisor Review
Claim Rejected
Claim Processed
Generate Letter - A component step
Company InsuredSSN
3. Select the Assignments tab. This is where you set the milestone for this step
and assign fields and attributes with values and expressions.
For our case study, after the completion of LaunchStep, we want to set the
field F_Subject to be "New Claim : Claim ID "+ClaimID with quotes. To set
this, we follow this procedure:
a. Under the shaded Field Assignments section, double-click the empty cell
under Name and enter the field name, F_Subject.
c. The Expression Builder window opens as shown in Figure 6-34. Enter the
following expression with quotes on the bottom pane and click OK:
"New Claim: Claim ID "+ClaimID
CreatedBy {Creator}
– This step can be accessed by users under the CreatedBy workflow group.
To set this up, under the Step Destination:
i. Select Participants and click the Modify (pencil) icon. The participant
Selection dialog box opens (see Figure 6-36).
ii. Select Workflow Groups.
iii. Select CreatedBy from the Available Participants, click Add to add it to
the Selected Participants list.
iv. Click OK.
e. The participants in this step do not have rights to reassign the task, or to
view the workflow status or history. To set this up, under Participant
Privileges, clear Reassign, View Status, and View History.
3. From the Properties pane on the right side, click the Parameter tab. For our
case study, we select the parameters for the Adjustor Review step as listed in
Table 6-20.
Company InsuredSSN
DebitAccountNumber LastName
Company InsuredSSN
DebitAccountNumber LastName
5. For each operation, under the shaded Operation Parameters list, enter values
for the parameters that are required for the operation.
For our case study, the following parameters are required for the copy
operation:
– Object: A container for the document to be copied. In the Expression
drop-down list, select WordTemplate as shown in Figure 6-39.
Table 6-23 Component and function setup for the Generate Letter step
Component name Operation names Parameter names Expression
File false
Copy ClaimNotice
destFolder CaseFolder
A submap cannot execute by itself. It must be called by the main workflow map
or other submaps.
Adding steps
For our case study, Table 6-24 lists the steps in the Claim Setup submap. Add
these steps as shown in Figure 6-42.
Adding routes
Add routes to connect the steps in the Claim Setup submap as shown in
Figure 6-43.
In real life, the conditional routing would be more complicated than what we show
here. As mentioned earlier, depending on your business process requirements,
you can set the Check for Attachments step to check whether a policy report has
been filed and whether the vehicle repair estimate from an approved auto-repair
shop has been submitted.
8. For route [2] from Check for Attachments to File Supporting Docs, click
Always true in the route’s Properties pane.
Table 6-25 shows the conditional routing set up in the Claim Setup submap.
Notice that the routing [1] from Check for Attachment to Field Agent is always
checked first. If the condition is not true, the second routing [2] always executes.
parentFolder ParentFolder
className "Folder"
properties {"FolderName",
"STRING", ClaimID}
folder CaseFolder
objectType "document"
itemIds {1}
values {LastName}
object PolicyDoc
destFolder CaseFolder
Note: It is important that the functions are added in the order listed. When
control is passed to a component step, the functions are executed in a serial
order. Also, remember the quotes around the expressions. In an expression, if
the quotation marks are used, then the value of the parameter is set to the
value within the quote. Finally, you must press Enter after each entry to
ensure that the values are registered.
Table 6-27 Component and function setup for the Retrieve Related Docs step
Component name Function Parameter Expression
name Name
objectType "document"
itemIds {1}
values {LastName}
objects SupportingDocs
Note: This step only searches for documents related to the claim but it does
not do anything. To simplify the case study, we keep the step as is. In real life,
we would probably want to search for the related documents and then add to
the claim folder.
Assignments.
To simplify the case study, before the execution of the step, we assign
SupportingDocs to an array of empty objects. See Table 6-29.
Table 6-29 Before execution tab
Name Expression
SupportingDocs {““}
After the execution of the step, we want to count the number of supporting
documents that have been added to the claim case:
– If there is no support document added to the claim folder, which is
elementcount(SupportingDocs) = 0, then:
• Set the AttachmentCheck field to false.
• Set F_Subject to the following text:
"Please add the supporting documents to this claim: "+ClaimID
– Otherwise:
• Set the AttachmentCheck field to true.
• Set F_Subject to the following text:
"New claim ClaimID: " + ClaimID
The AttachmentCheck field value (true or false) is used in the conditional
routing to determine whether the control should go back to the Field Agent
step again or move forward to the next step. If the controls are to go back to
the Field Agent step, we also set the F_Subject value to inform the field agent
at that step that supporting documents have to be added to the claim.
Table 6-31 Component and function setup for the File Supporting Docs step
Component name Function Parameter Expression
name Name
objects SupportingDocs
For our case study, in the Claim Setup submap, we use two system steps:
Get Field Agent
Get Adjustor
Figure 6-45 Set up Get Field Agent system step: Add Assign function
4. Double-click Assign from the Selected functions and the Assign dialog box
opens.
5. Select FieldAgent from the drop-down list as shown in Figure 6-46.
6. Click the Expression input box. Click the Expression icon and the Expression
Builder dialog box opens.
7. Enter the following expression on the lower input box and click OK:
if(LossCity = "Los Angeles", "Fran", "Fred")
8. The Assign dialog box should look similar to Figure 6-47. Click Close.
Figure 6-47 Set up Get Field Agent system step, Assign function, FieldAgent parameter
This is the exact same setup as for the Get Field Agent step. Use the Assign
function, and assign Adjustor with the following expression:
if(VehicleEstimateAmount <= 7000, "Annie", "Author")
Figure 6-48 Set up Get Adjustor system step, Assign function, Adjustor parameter
Figure 6-50 Linking the submap step with the called submap name
4. To test the connection, double-click the submap step and the called submap
should open. For our case study, click the Claim Setup step on the main map
and the Claim Setup submap opens.
Validating map
To validate your work, select File → Validate. Make sure you resolve any issues
before continue with the rest of the chapter.
To check in, use File → IBM FileNet Add New from Process Designer. For
details, refer to “Option 2: IBM FileNet Add New” on page 143.
Note: Before you create a workflow subscription, make sure that the
associated workflow is saved, checked into Content Engine, and transferred
to the Process Engine.
b. Select the target object class type. For our case study, the object type of
the Claim object class is a custom object. We select Custom Object. See
Figure 6-53.
Figure 6-53 Add workflow subscription: Select target object class type
Figure 6-55 Add workflow subscription: Select workflow process, browse the folders
Figure 6-57 Add workflow subscription: Select the workflow version to launch
Note: In most cases, you select the most current workflow version.
However, you have the option to select an older version of a workflow if
required.
5. Click Accept and Next to move to the next step. See Figure 6-61.
6. Click Next to move on to the next pane. We do not build any special
expressions for the workflow subscription. Click Next again to continue to the
next step.
7. You should now be at the Set Property Map step. See the arrow on the left
side of the pane as shown in Figure 6-62.
In this step, you map the properties of your target object class to the data
fields used of the workflow to be launched:
a. From the left side, the Data Field Name drop-down box, select the data
field of the workflow that requires data information. For our case study, we
select Agency (String). See Figure 6-62.
When you launch a workflow based on the subscribed event that occurred
on a target object, the property information from the target object will be
mapped to the data fields of the launched workflow. This way, the workflow
gets the information it needs from the target object to do its work.
Figure 6-62 Set property map: Select the data field of the target object class
b. From the right side, the Property Name drop-down box, select the property
of the target object class that triggers the workflow. For our case study, we
select Agency (String). See Figure 6-63.
c. Click the plus sign icon to complete the mapping. See Figure 6-64.
d. Repeat the previous three steps for other property mappings. When all
data fields of the workflow are mapped by the properties of the target
object class, click Next.
Figure 6-64 Set property map: Click the plus sign icon to complete the mapping
Note: If you follow through our case study example, make sure that you
map things precisely as described in the table.
AccidentDate Date
Agency Agency
AgentName AgentName
ClaimID ClaimID
Company Company
Creator Creator
EffectiveDate EffectiveDate
LastName LastName
LossLocation LossLocation
PolicyNumber PolicyNumber
VehicleEstimateAmount VehicleEstimateAmount
VehicleReplacement VehicleReplacement
The data fields of the workflow and the properties of the target object class
might not always have a one-to-one naming correspondence. For our case
study, the workflow uses a data field called AccidentDate. The object class
uses a property called Date. We map Date from the object class to
AccidentDate in the workflow.
8. The last step in the workflow subscription creation process includes setting
the security. In this step, you can specify who has owner control, modify
control, view control, and remove right of the workflow subscription. For our
case study, we use the default.
Figure 6-65 Add workflow subscription: Click Finish to complete the subscription
Note: You can also create a workflow subscription using IBM FileNet
Enterprise Manager if you want to create a workflow subscription for a
particular document, folder, or custom object. For simplicity of discussion, we
do not cover this topic in the book.
If you imported the Content Engine objects from the downloadable materials
provided with this book, the Creator property has already been exposed in the
object class.
Figure 6-66 Browse to the target object class - For our case study, it is Basic Process
b. Select the System Properties check box. This enables the system
properties to be exposed for property mapping when creating a workflow
subscription.
c. Select the system property you want to expose for property mapping. For
our case study, we select Creator.
Figure 6-73 Complete exposing of the system property and its mapping to the workflow
Note: To save the time and effort of logging in and out as different users,
this process is set up so that testing can be done using the administrator’s
task box. The Administrator has not been added to the F_Trackers
workgroup, because the Administrator has access to the Process
Administrator, which can view Process Tracker. If you would like to add
Administrator to the F_Trackers workgroup now, you have to save and
transfer the new process and then modify your subscription to use the new
version of the process.
The workflow properties that show the details of the current status.
On the right side of the window, you can see the details of the selected item of
a workflow, a step, or a route. See Figure 6-77.
Note: The cursor in the figure is pointing to a blue arrow. The blue arrow
and the one above it allow you to expand either the workflow map or the
properties pane to the full width of the window. These arrows can also be
found on the Process Designer window.
To show the progress of a process, click the Refresh icon. See Figure 6-78.
Also in this view, the step currently being executed is the Field Agent step,
indicated by the hour glass. This tells you that input from the field agent is
required. It is waiting for the field agent to add supporting documents.
Process Administrator
With Process Administrator, you can search for and view workflows, edit
workflow data and properties, and manage workflows.
After you locate one or more workflows or work items (as shown in Figure 6-81,
for example), you can use Process Administrator to make various changes to the
work in progress, such as these:
Complete a step and send it on to the next step.
Modify workflow field values.
Assign users to or remove users from a workflow group.
Delete an entire workflow or one or more work items.
The highlighted task in the figure shows a workflow process currently running.
The F_Subject column shows the completed expression you built earlier and
assigned to F_Subject. The cursor is currently pointing to the Process Tracker
icon. By clicking this icon, you launch Process Tracker to view the current status
of the highlighted workflow process.
Note: The only required field is the Claim ID. It is required to create the
claim folder.
Figure 6-87 Add a claim: Use default security and complete the claim
Note: The long name listed in the confirmation window is the internal ID for
the object.
Note: If the new claim does not appear here, this might be for one of two
reasons:
The step that moves the new claim to the field agent has not completed
yet. Wait a while for the step to be completed.
There might be a problem with the workflow process definition. The
problem can be seen in Process Tracker. Navigate from Workplace →
Tasks → Task Tracker to see where the workflow process stopped.
Note: Documents can be attached to the claim in many ways. In our case
study, we choose to attach the ones that reside in the content repository.
The Add New link enables you to add documents outside of the repository.
8. Click Complete to move the claim to the next step in the workflow process
(see Figure 6-98).
3. View the claim, the supporting documents, and the claim processed letter
(see Figure 6-103).
For our case study, we create two new workflow processes (GetAdjustor, and
GetFieldAgent) and expose them as Web services. These new processes (Web
services) replace the existing steps (Get Adjustor and Get Field Agent) in the
basic workflow process.
For our case study, we create two workflow processes that are to be used as
Web services:
GetFieldAgent
GetAdjustor
4. Select the Data Fields tab and add the City and State fields as shown in
Figure 6-105. When the other workflow process calls this Web service, the
other workflow process should supply the City and State values.
Figure 6-106 GetFieldAgent workflow property - Web services -> Partner Links tab
Figure 6-107 GetFieldAgent workflow property - Web services -> Partner Links data
3. For the Los Angeles route, if the City parameter is not equal to “Denver”, the
route goes to the Fred step. Set up the conditional routing for the Los Angeles
route as follows:
a. Select Condition in the Properties pane.
b. Select the Data Fields tab.
c. Select City (String) from the Field drop-down list.
d. Select is not equal from the Operator drop-down list.
e. Enter “Denver” in the Value field. Make sure to include the double quotes.
f. Click Insert. Without clicking this button, the condition will not be saved.
Figure 6-111 GetFieldAgent workflow map: GetFieldAgent step - Partner Link property
3. Define the Fran step using the similar procedures as the Fred step. Instead of
“Fred”, type “Fran” in the Expression field under the Operation Parameters
section.
For simplicity of the workflow, we hard-coded the names of the adjustors. The
GetAdjustor workflow process assigns Author or Annie as the adjustor name
based on the vehicle’s estimated repair amount provided by the calling process.
4. In the Data Fields tab, add the data field Amount, with type as Float. See
Figure 6-118. When other workflow process calls this Web service, the other
workflow process should supply the Amount value for this Web service.
5. In the Web services tab, go to the Partner Links tab. Enter the Partner Links
information as shown in Figure 6-119. Note that we set the Web service with
the name, GetAdjustor, of type Receive/Reply. This means that the Web
service contains both Receive and Reply functions.
Calling a Web service from a workflow process consists of the following main
steps:
1. Open the existing workflow and define its workflow properties:
– Web service name and type - You must specify the Web service that the
current workflow process will call (invoke) within its process. In addition,
the specified Web service must be set up as an Invoke Web service type.
For our case study, we go back to our basic workflow process and update it to
use the two new Web services we created in the previous section.
Figure 6-126 Claim Setup submap: Browse for the Web services
2. Add the Invoke steps and routes in your workflow. For our case study, we add
two Invoke steps: Get Field Agent and Get Adjustor steps (see Figure 6-130).
2. Define the Get Adjustor step. The step is an Invoke step that calls the
GetAdjustor Web service. It requires the Amount parameter as input. Its value
comes from the workflow’s VehicleEstimateAmount data field. Define the step
as follows:
a. Select the Get Adjustor step.
b. In the General tab:
i. Select GetAdjustor from the Partner Link drop-down list (see
Figure 6-135).
ii. Select GetAdjustor from the Operation drop-down list.
c. Ensure that the Parameters radio button is checked. See Figure 6-136.
d. Under the shaded Outgoing Parameters section, for the Amount
parameter, from the Expression drop-down list, select
VehicleEstimateAmount. This is how you set the workflow’s data field
value (from VehicleEstimateAmount) to the input parameter’s value
(Amount) required by the Web service.
For step-by-step instructions on how to implement these features for our case
study, refer back to Chapter 6, “Implementing business processes: Case study”
on page 127.
JMS provides basic Enterprise Information System (EIS) integration. For JMS
information, see:
http://java.sun.com/products/jms
How it works
In Figure 7-1, a work item represents a workflow step waiting in the Process
Engine for processing. The work item makes a request of a component. The
component provides a response by performing some actions that might be
outside of the Process Engine. The response is used in the subsequent steps on
the workflow. You do not have to know the details of the component itself, it can
be some custom Java code that connects to a legacy system, database server,
or mail server. The advantage of Component Integrator is that it hides the
complexity of the outside component.
1. Request (2+2?)
Component
3. Response (4)
2. Action (log “2+2=4”)
Work
Item
Process Engine
Following are some examples of how the Component Integrator can be used in
an IBM FileNet Business Process Manager application:
A company has existing Java codes that query proprietary systems for
claimant policy information. Adjustors need this claimant policy information to
adjust the claim amount in an IBM FileNet Business Process Manager
workflow process. The Java codes can be made available through
Component Integrator in the workflow step.
A company has a Java application that stores and retrieves customer profile
data from a legacy data store. In an IBM FileNet Business Process Manager
workflow process, there is a requirement to retrieve and update customer
profiles. Component Integrator can be used to utilize the existing Java codes
for this IBM FileNet Business Process Manager workflow process.
A company has a supplier that accepts order requests as XML documents
through guaranteed messaging service using message queues, and wants to
automatically generate order requests as part of its business process.
An accountant uses existing JMS queue to send payment data. This data is
used (also considered as being consumed) by an electronic payment system
to process and issue check to customers.
A customer has existing Java code that update sales order records in a
proprietary sales order system, and wants to integrate these functions in an
IBM FileNet Business Process Manager business process.
Chapter 7. Integration with external systems and services with BPM 259
See Figure 7-2. which shows some of the CE_Operations you can select within a
workflow process.
The More_Operations component offers a rich set of functions (see Figure 7-3),
some of which include:
Create, delete, copy, and move documents, folders, or custom objects.
Get and set multiple property values of a given document or folder.
Check in and check out of a document.
Search for a document or documents using search templates.
Send e-mails with attachments, and optionally using templates.
There are three ways that IBM FileNet Business Process Manager uses the Web
services technology:
Invoke Web services from a BPM workflow process. This enables you to use
the Web services developed for other applications in your organization and
the ones that are available externally on the Internet.
Provide a BPM workflow process as a Web service and enable other
applications to use this BPM workflow process to accomplish their tasks.
Use the Web service API to write step processors (not covered in this book).
There are two message type options when invoking or creating a Web service:
Parameters: This is an easy way to use Web services. You do not need to
understand XML or XML schemas.
XML: This is for working with complex parameters that the Parameters
message type cannot handle. To use it, you need to know XML and XML
schema knowledge.
There is a set of protocols that define how a Web service can be published,
discovered, and used in a technology neutral, standard format. Among these
standards are:
Web Services Description Language (WSDL): Interface definition used to
define Web services. A WSDL definition describes how to access a Web
service and what operations it performs. You can use WSDL to create Web
services and publish these services to UDDI.
Universal Description, Discovery and Integration (UDDI): The directory that
provides the means for discovering and publishing Web services. It is
provided by a third party that makes these services available for inquiry. It is
the equivalent of “Yellow and White Pages” of Web services.
Chapter 7. Integration with external systems and services with BPM 261
Extensible Markup Language (XML): The base meta-language for many
Service Oriented Architecture related technologies and standards. In Web
services, the messages including embedded data are written in XML format.
It can be used to exchange data, so that data can go back and forth between
the services provider and the client in the standard recognizable format. You
can consider it as the payload (in relation to HTTP).
Hypertext Transfer Protocol (HTTP): The vehicle that carries the XML data
between systems. You can consider this as the transport.
Company A
(Web Services provider)
2
e
r vic
Se
th e
es
3 Us 3
Company B
(Web Services consumer)
1
Definition is extracted from http://www.serviceoriented.org/process_orchestration.html
Chapter 7. Integration with external systems and services with BPM 263
IBM FileNet Business Process Manager processes can use (consume) existing
Web services and provide (be consumed as) Web services. The IBM FileNet
Business Process Manager processes can be published as Web services, which
then can be discovered through a UDDI registry.
IBM FileNet Business Process Manager offers the following Web services
system functions to achieve Process orchestration:
Invoke: Requests a service from a selected partner link.
Receive: Provides a service in response to a Web service request.
Reply: Sends a response to a Web service associated with a previously
accepted receive system function.
Invoke function
You can use the Invoke system function anywhere in a workflow process. The
Invoke system function calls an application component that provides a Web
service. This enables a workflow process to interact with and use external Web
services.
In the workflow process, there is a workflow step called Authorize Credit Card. At
this step, an Invoke system function calls a Web service from a Web services
provider, Visa.com. The Web service provides a credit authorization service.
Authorization request information is sent to the Web services. The Web service
returns a response, either Valid or Not Valid, back to the service requester (the
Authorize Credit Card workflow step) in the workflow process. The returned
response is evaluated at the next step of the workflow process and then routed to
the appropriate steps to accept or deny the credit card transaction.
In this example, Visa.com is the Web services provider and XYZ Corporation’s
workflow process is the Web services consumer.
Receive/Reply function
Handling of inbound requests from external Web services is done using the
Receive and Reply system functions.
The Receive system function can be viewed as representing an entry point to the
workflow process. Incoming messages are processed by a listener called
WS-Listener, which is running as part of Component Integrator. If you put a
Receive step immediately after a Launch step in a workflow, an appropriate
incoming message received by the system can launch a workflow process.
The Reply system function provides the ability to pass back information to the
application that made the original request. There might be multiple Reply steps in
a workflow process for one Receive step. The relationship between Receive and
Reply is usually one to many.
Similar to the Invoke system function, the Reply system function is implemented
as an operation on the WSRequest queue. When the Process Engine encounters
a Reply system function in a workflow, the work item is routed to the WSRequest
queue. The WS-Adapter, running under the Component Integrator, queries the
queue and processes the work item.
Unlike the Invoke system function, there is no response received back from the
call.
Chapter 7. Integration with external systems and services with BPM 265
Receive/Reply example: Publish XYZ Corporation statistics
An example of using Receive and Reply system functions is in the insurance
claims processing workflow that provides statistics lookup service to the
executives of the company.
The executives require high level statistics on insurance claim totals and
processing time displayed in their home page.
The IT department creates a workflow that collects current statistics from the
claims processing database on demand. The workflow contains a Receive
system step that gets the request for high level statistics. When the request is
received, it launches the workflow process. A DB Lookup system step is called
within the process that retrieves the current statistics from the Claims database,
and summarizes them to the high level that is required by the executives. The
workflow also contains a Reply system step that sends back the high level
statistics information to the requester.
The IT department publishes the workflow to a UDDI registry. It also modifies the
executives’ home page template to include the WSDL that associated with the
Web services. The executives can use the link provided in their home page to get
the high level statistics they need.
Figure 7-6 illustrates the example. Notice that, in this case, the workflow process
is the Web services provider, and the executive home page is the Web services
consumer.
XYZ claims
Statistics DB
Figure 7-6 Web services Receive and Reply system functions usage example
Note: IBM FileNet Business Process Manager by itself does not provide a
business rules engine. It integrates with the third-party rules engine software
of your choice in its system.
Workflow process designer and business analysts can create and add business
rules to individual steps of a workflow. Rules are used to separate business rules
from the process, making it easier for a business analyst to adjust a complex
process by modifying the rules rather than modifying a workflow process.
Chapter 7. Integration with external systems and services with BPM 267
Rules can control the following types of operations in a workflow:
Assign data to a field in the work item.
Send a work item to a workflow map.
Send a work item to a custom exception workflow map.
Skip a workflow step.
Repeat a workflow step.
How it works
When a workflow encounters a rule, the Process Engine sends a request to the
Rules Listener (an interface provided by IBM FileNet), which passes the request
to the rules engine. The rules engine executes the rule-set and returns the
results to the Process Engine.
It is beyond the scope of this book to cover detailed steps of setting up a rules
engine and using the rules. However, in the following two chapters, we provide
more details on understanding and implementing Component Integrator.
Chapter 7. Integration with external systems and services with BPM 269
270 Introducing IBM FileNet Business Process Manager
8
Component adaptors are used to interact with different types of components from
a workflow step. You can use the Java adaptor to call Java components, and the
JMS adaptor to interact with message queues. You can also write your own
adaptors for different components and applications.
For each step in the workflow, the general sequence of events takes place as
shown in Figure 8-1. The diagram illustrates the runtime interaction of the
Component Integrator with Application Engine services (such as Component
Manager), component queues in the Process Engine server, and a custom
entity. The numbers in the diagram represent the steps in the operation of the
Component Integrator.
JAAS is used for the Process Engine and component authentication of users. It
supports a single sign-on capability.
There is also a configuration option to allow the system to automatically check for
new events. This option causes the Component Manager to respond to items in
a component queue as they arrive. This event-driven mechanism can be enabled
in addition to polling for work items.
If your IBM FileNet Business Process Manager system has been configured to
automatically check for new events, the Component Manager responds to both
the component's polling rate and to new events as they occur.
The user you used to log into the Workplace must have administrative rights
on your Process Engine server.
4. The Add Component Queue Wizard starts. Enter the following information
and click Next:
– Queue Name: The name of the component queue. This name will appear
in the list of component queues in Process Designer. For our example, we
enter More_Operations.
– Description: You can optionally enter a brief description of the queue. For
More_Operations, we leave it blank. See Figure 8-3.
• Java Class: Select the appropriate class from the drop-down list of the
available classes. After you select the Java class, a list of available
methods display in the Available Methods box. When you configure the
component queue operations, you have the opportunity to select one
or more of these methods. For our More_Operations example, we
select:
com/IBM FileNet/churnett/ciMore_Operations.class
Figure 8-4 shows the Jar File Path and Java Class set up for our example.
Figure 8-4 Configure Java component: Jar File Path and Java Class
8. Click Finish.
3. Select either the Java methods or the JMS events to import, depending on
the adaptor type:
– For the Java component, select one or more methods from the Available
Methods drop-down list and click OK. The methods you select will be
converted into operations. The method name becomes the operation
name, and the method parameters become the operation parameters.
In the Process Designer, you can then specify the operation and its
parameters when designing the component steps of your workflow.
You can optionally rename parameters and enter descriptions for
operations and parameters. These can be helpful to the workflow designer
when specifying expressions for the parameters.
Important: If the imported methods depend on other Jar files, then you
should make them available to the Process Configuration Console
through the Register Additional Classes interface. See Figure 8-2 on
page 276.
Otherwise, the Process Configuration Console will fail to load the class
and thus does not display any methods.
Figure 8-7 Select methods from Java class to import for the Java component queue
Note: You cannot import Java methods that use byte, char data types,
or any Java objects other than Short, Integer, Long, Float, Double or
Boolean. You can use methods that use VWAttachment and
VWParticipant.
– For JMS operations, enter the events for this component queue. For each
event, you enter an event name, and then specify the parameters for that
event. All parameters that you specify have read-only access. You can
optionally enter a description for each event and for each parameter.
The events will be converted into operations. In the Process Designer, you
specify the expressions for parameters in the component step of your
workflow.
The JMS adaptor only supports outgoing data to a JMS queue.
In addition, you must commit your changes and restart Component Manager
before the new queue operations or changes take effect. Otherwise, the
changes will be lost when you stop or refresh the Component Manager.
The Process Task Manager in the Application Engine enables you to configure,
start, and stop a Component Manager and its associated components. You can
run one or more Component Managers. Each Component Manager coordinates
one or more components which are responsible for delivering events from the
Process Engine to an external entity such as a Web service or a messaging
system. In the Process Task Manager, the Component Managers folder displays
all the Component Managers currently defined. Selecting a Component Manager
displays its associated components.
To configure a Component Manager to use the new component queue that you
created, perform the following steps:
1. Start the Process Task Manager from the Application Engine.
2. Stop the Component Manager where you will add the component queue. You
cannot update its information while it is running.
3. In the General tab, append the Queues field to include the new component
queue name. Remember to add a comma in between value and the new
name. There should be no space between them. For our More_Operations
example, we append the queue name, More_Operations, at the end. See
Figure 8-10.
4. In the Required LIbraries tab, specify the location of the Jar file that contains
the class associated with the component queue. The Process Task Manager
appends the Jar file location to the class path when starting the Component
Manager. You must add a required library entry for each component queue
that you create. Click Add to add the path. See Figure 8-11.
Note: The Jar file must exist on your Application Engine server.
Figure 8-11 Add Jar file path (for the component queue) in the Required Libraries tab
IBM FileNet Business Process Manager processes can use (consume) the
existing Web services. In addition, the processes can be published as Web
services, to provide services to (be consumed by) others. The published Web
services can be discovered through a UDDI registry. Using Process
Configuration Console, you can configure a limited UDDI registry list for an
isolated region or allow users to browse for published Web services.
WSRequest WSPending
Queue Table
As shown in Figure 8-13, the outbound requests for Web services are handled
through WS-Adapter, running as part of the Component Integrator. The inbound
requests for Web services are handled by WS-Listener, running as part of the
Component Integrator. The Process Engine has a WSRequest queue and a
WSPending table, which are system-managed data structures used in
processing the requests for Web services.
All communications are accomplished through XML. When using Web services,
you have to set data field mapping. There is no requirement for you to
understand XML. The Process Designer tool automatically parses the WSDL for
input and output parameters. The data fields are updated with the values of the
incoming parameters at runtime.
The Receive step in a workflow calls the Receive system function. The Receive
function can be viewed as representing an entry point to the workflow process.
Incoming messages are processed by WS-Listener, which is running as part of
Component Integrator. When processing incoming messages, the WS-Listener
interacts with both the WSRequest queue and the WSPending table. If you put a
Receive step immediately after a Launch Step in a workflow, an appropriate
incoming message received by the system can launch a workflow process.
The Reply system function provides the ability to pass back information to the
application that made the original request. There might be multiple Reply steps in
a workflow process for one Receive step. The relationship between Receive and
Reply is usually one to many.
The Reply step in a workflow calls the Reply system function. Similar to the
Invoke function, the Reply function is implemented as an operation on the
WSRequest queue. When the Process Engine encounters a Reply system
function in a workflow, the work item is routed to the WSRequest queue. The
WS-Adapter, running under the Component Integrator, queries the queue and
processes the work item.
Unlike the Invoke function, there is no response received back from the call.
Note: For the step-by-step instructions that we used for our case study
(excluding the configuration of the UDDI registry list), refer to 6.9, “Creating
and calling a Web service” on page 230. There, we show you how to create a
workflow process as a Web service, call the Web service in a workflow
process, and test the process with Web services.
Select or clear the check box option to allow or deny access from the Process
Designer to any arbitrary WSDL. This controls access to Web services.
3. Right-click the isolated region and select Properties from the context menu.
4. In the Isolated Region Properties window, select the UDDI tab and then select
the UDDI Registry List tab.
5. Click the Add icon to add an entry to the list. See Figure 8-15.
If a workflow invokes or receives requests for Web services, specify the Web
services on the Partner Links tab. If XML data fields and XML schemas are
required for invoke, receive, or reply tasks, define them in the XML Data Fields
tab and the XML Schemas tab. On the Web services General tab, you can
specify a folder in your object store or library where any incoming attachments
are stored.
Figure 8-18 Use the System step with the Invoke function in workflow map
Figure 8-19 Use Invoke System step from Web services Palette
3. Specify the general properties for the Invoke system function. If you use the
System step, double-click Invoke from the Selected Functions field. If you
use the special Invoke step, select the step from the map and select the
General tab on the right. Enter the following information:
– Partner Link: Select the Partner Link for the Web service. The Partner Link
list contains only entries already specified for Invoke Web services in the
workflow properties.
– Operation: Select the appropriate operation in the Web service.
4. Select the Advanced tab. In this tab, you can optionally set the time out
expression for the step and the time out map that would be executed if a time
out does occur. In addition, you can select the Use reliable messaging option
here.
5. Make the appropriate routing connections between this Invoke step and other
steps and save the workflow definition.
Note: For the step-by-step instructions we used for our case study, refer to
6.9, “Creating and calling a Web service” on page 230 in which we show you
how to create a workflow process as a Web service, calling the Web service in
a workflow process, and testing the process with Web services.
To do so:
1. Start the Process Designer and open the workflow definition.
2. Open the Workflow Properties window.
3. Select the Data Fields tab and enter the data fields that will be used to hold
the reply messages.
4. Select the Web services tab and then select the Partner Links tab.
5. Select the Receive/Reply check box (see Figure 8-21). Enter the following
information:
– Name: Enter the name for the Web service on the left panel.
– Process Port Type: Enter a name for the port.
– Process Role
Figure 8-22 Use the System step that calls the Receive function
Important: The Receive step must be the first step after the Launch step in
order to launch this workflow automatically in response to an invoke of the
Web service.
3. Specify the general properties for the Receive function. If you use the System
step, double-click Receive from the Selected Functions field. If you use the
special Receive step, select the step from the map and select the General
tab. Enter the following information:
– Partner Link: Select the Partner Link for the Web service. The Partner Link
list contains only entries already specified for Invoke Web services in the
workflow properties.
– Operation: Select the appropriate operation in the Web service.
– Message Type: The Process Designer automatically selects the message
type. Two message types are:
• Parameters: Uses the workflow data fields and attachments for input
and output. This option is available for simple parameters.
4. Select the Advanced tab. In this tab, you can optionally set the time out
expression for the step and the time out map that would be executed if a time
out does occur. In addition, you can select whether to authenticate user or not
and restrict the users (who can invoke this Web service) to specific users or
groups.
5. Make the appropriate routing connections between this Receive step and
other steps.
6. Optionally, add a Reply System step if required, to reply to the Web service
consumer with its information.
7. Save the workflow definition.
To finalize the Web service operations and transfer the workflow definition:
1. In the Process Designer, open the workflow properties of the workflow.
2. Select the Web services tab and then select the General tab.
3. Select the Finalize existing web services operations option. See
Figure 8-24. The system prompts you with a message regarding the
implications of this action.
4. Click Close.
5. Save the workflow.
6. Transfer the workflow by select File → Transfer.
The Partner Link of the finalized Web service does not identify a specific version
of the workflow. Other workflow processes always invoke the latest version of the
transferred workflow.
Note: After you transfer the workflow definition to the Process Engine with the
finalized option enabled, you cannot disable this option in the workflow
definition.
Before you can publish a workflow to a UDDI registry, you must specify the
appropriate UDDI registry in the isolated region properties in Configuration
Console.
After creating the workflow definition and transferring it into the Process Engine,
use the Process Configuration Console to publish the workflow to a UDDI
registry.
If you are publishing a business entity for the first time, enter the business name
and description, and provide a user name and password for the UDDI registry.
Otherwise, you cannot change the business name or user name. The information
that you enter here displays in the UDDI Registry List for the isolated region.
In this chapter we cover the process of planning and designing a content centric
IBM FileNet Business Process Manager (BPM) application at a high level. This
includes gathering requirements, transforming them into a workflow process,
validating, and finally producing a high level architecture design.
Figure 9-1 shows the steps in modeling a process in an IBM Business Process
Manager system.
There are five major areas in the outer circle to look for when designing a BPM
process: process flow, integration, user interface, roles and responsibilities, and
controls.
Process flow
This action entails creating process definitions and flow. In the initial iteration,
focus on the core functionality that delivers the bulk of the value.
Integration
This action focuses on integrating with and extracting information from internal
and external systems, getting the required results, and updating databases.
User interface
After you understand the roles and responsibilities of all users, the next action is
to ensure that the user interface windows deliver the required information and
provide the right interface for users to interact with the system to perform their
tasks.
Controls
Business managers want ways to improve performance of the process, allowing
them to better control process execution. They require mechanisms that help
them cater to peak system performance on demand, or influence the way in
which business rules apply. This action focuses on providing the controls to the
business managers.
The emphasis here is on understanding the process, not building models for
transformation into code or executable process definitions. This enables both the
business analyst and the business users to step outside of the business-as-usual
view and see the existing process differently.
After you and your audience are ready, look for information in the following
specific areas of the business:
Organization and business objectives.
Industry and comparable initiatives.
Within current processes:
– Departmental, inter-departmental, and external flows
– Roles
– Inefficiencies and associated costs
Perceived gaps to desired business processes:
– Functional requirements
– Non-functional requirements
Opportunities for improvement that have not been identified, such as:
– Application integration
– External process participants
– Interactive process monitoring
Job shadowing
The job shadowing is primarily use for observing the current business process of
workers below the supervisor level and observing corporate culture.
You can use job shadowing when the as-is state is important input to the
requirements. Sometimes the requirements are better observed than described.
Another reason for job shadowing is that the participants might have insufficient
skills to communicate their requirements or current process, or are unwilling to
communicate such information completely, or are intimidated in an interview
environment.
Interviews
Use one-on-one interviews when a few individuals have specific unique
knowledge or the requirements are better described than demonstrated, for
example, when job shadowing is not appropriate.
You can use an interview primarily for management and executives, and for
understanding high-level business objectives and long-term vision, the big
picture.
Focus group
Use focus groups when knowledge is distributed over a number of individuals.
The interaction between the participants is relevant to determine the
requirements. The participants are peers (or nearly so) to reduce power-based
domination.
Questionnaires
Use questionnaires when there are many participants to survey or they are
geographically remote. You can also use questionnaires for external constituents
who might be inappropriate for internal meetings. Answers to specific
well-defined questions, such as how many and how often, can also be surveyed
in the form of questionnaires.
For managers and knowledge workers, it is often easiest to start with questions
about the department, such as:
What are the existing processes, including any process diagrams or
procedures that they have created?
How do they interface with other departments?
How do they interface with external third parties systems, services, and
customers?
What are the existing and upcoming regulatory and customer service
standards that they must meet?
XYZ Corporation offers a range of financial and insurance products and services
through a large network of field offices.
After gathering the existing process requirements and business initiatives of XYZ
Corporation, we create a flowchart describing the current as-is auto claim
approval process as shown in Figure 9-2.
Mailroom Clerk
determines which Field Decision
Agent should work on Adjustor reviews the END
the claim depending on claim and waits for
the location of accident police report and car
photos
Supervisor rejects Supervisor
the claim approves the claim
Mailroom Clerk manually
classifies the claim Field Agent receives
and sends the police
report and photos to the Supervisor writes
head office Mailroom Clerk gets the
a rejection letter
Mailroom Clerk sends letter and dispatches it
and sends it to the
the claim to Field Agent to claimant
mailroom
via internal office mail
Mailroom Clerk receives
the package, stamps it,
classifies and forwards
to Adjustor
Figure 9-2 Flowchart describing XYZ Corporation as-is auto claim approval process
In our case study of auto claim process, we can eliminate the mail-room
operation. This alone saves labor hours thus improving processing time and
reducing the claim processing errors and overall costs.
Map the current as-is and future (or want) to-be business processes. Analyze the
future business processes and find out more information about these business
processes. This includes identifying the following information:
The functions and roles within the process
The source of content and its method of acquisition within the process
Steps that can be automated
Integration point within the process
Overlay the IBM FileNet Business Process Manager to check for the right fit, and
identify the potential gaps in functionality between the as-is and to-be business
process.
The purpose of having a future to-be process is to ensure that we understand the
process in its entirety, including the roles and responsibilities of each player in
the process. This way, we can get an agreement on the process steps and on
the more low level requirements.
YES
Claim case is
created
(System step) Final review by Payment
Adjustor processing
(Human task) (Human task)
Field Agent is
assigned
(System step)
Goes for second approval Approve if claim amount is
if claim amount is more less than or equal to
than $3000 $3000
Claim approves
Claim amount?
(System step)
Field Agent reviews the
case, completes
END
information, determines
the claim amount YES
(Human task)
Escalate for any
exception Is the claim
(System step) approved?
Adjustor is
assigned NO
(System step)
Supervisor reviews
(Human task)
Figure 9-3 XYZ Corporation to-be process auto claim approval process
For auto claims, the comparison of the as-is process and the to-be process
clearly shows a considerable reduction from 30 steps to 13 steps. This is done by
eliminating mail-room operation and automating manual processes such as field
agent and adjustor assignments.
After identifying the business process and the responsible roles, we create a
business context diagram that explains users’ roles, connectivity, and
information flow for the auto claim process. See Figure 9-4.
1.Customer calls
and submits a
claim
Front Office
CSRs
7. Accounting
Clerk gets the
approved claim
8. Filing Clerk
package and writes
gets the closed
a check and sends
file and files it .
it to the claimant.
The closed file is
then sent for filing.
Back Office
Mailroom Clerks
Adjustors
Supervisors
6. Supervisor reviewes 4. Field Agent gets the
the claim and either Accounting Clerks
claim package, reviews
approves or rejects it. Filing Clerks it , associates police
Approved claims go to report and other related
Accounting Department documents, then sends it
for payment to Adjustor
Field Agents
5. Adjustor receives the claim
package, reviews it, and either
approves or rejects the claim or
escalates it to Supervisor .
Approved claims go to
Accounting Department for
payment
Figure 9-4 Business context diagram with roles and connectivity for auto claim process
Using both the to-be process and the business context diagram, you can clarify
your understanding of the process and gain your customer’s commitment on the
requirements.
The alternatives will become part of the detailed solution design, wherein you
describe the readily available functions as-is and any of the added functions from
customization.
For the purpose of our case study, we use two interfaces. The eForms interface
is used by CSRs who take customers’ calls and prepare claims. The eForms
helps in filling the required information interactively while the customer is on the
phone. After the process is initiated, a case is created. Other users, such as field
agent, adjustor, and supervisor, require a review of the case. Therefore they use
a customized user interface that provides more functions, such as reviewing the
claimant folder, and associating more documents with the case, such as police
reports, creating comments, and approving or rejecting the claims.
In our case study, we map the key business requirements with the features
provided by IBM FileNet Business Process Manager and other IBM FileNet P8
products. The result is shown in Table 9-1.
Table 9-1 Mapping of key business requirements with readily available P8 features
Business requirements IBM FileNet P8 features
Replace manual steps of creating the Use eForms to fully automate this
claim, such as creating and faxing word process.
documents, time-stamping, classifying,
and reviewing for input errors for the
claim.
Replace the manual process of locating Through the BPF customization, a case is
the policy document from a manual filing created automatically after the claim is
system, printing, and associating the submitted. The claim and all associated
policy with the claim package and re-filing. documents are part of the case folder.
Replace manual interaction between field Interaction through the IBM FileNet
agent and adjustor, which has usually Business Process Manager system, with
delayed the claim processing. built-in Time Delay, Exception, and
Escalation triggers.
Replace manual handling of associated The Content Engine used within IBM
documents that were causing delay in the FileNet Business Process Manager stores
processing, for example, police reports, these documents electronically.
car photos, and so on.
Improve risk assessment, which currently Intelligence is built into the IBM FileNet P8
is completely manual, using the previous process. Based upon the risk assessment
claims history. rules, the adjustor can make informed
decisions.
Improve payment process, which takes up The claim case would have every
time, due to not having complete document that is needed for a final
information. payment.
Properly retain and destroy claim files and IBM FileNet P8 compliance framework
associated documents, such as e-mails, can be proposed to address this
according to corporate compliance requirement.
policies, a feature that currently the
manual process does not offer.
While the BPF user interface is critical to claim processors, it is “overkill” for
CSR’s role. We decide to use a simple eForms-based user interface. A form can
be used as a document or can be customized as an intelligent user interface. For
our case study, we use the document type eForms.
Besides automating the claim process, XYZ Corporation also ask for monitoring
the claim process and using the results for further process improvements. This
can be addressed by implementing Process Analyzer, Process Simulator, and
Business Activity Monitor BAM.
IBM FileNet Business Process Manager can use various high availability options,
including server farms for scalability and expendability; while IBM FileNet
Records Manager, Email Manager, and Record Crawler can be used in
conjunction to address the compliance requirements.
Finally we model the process in Visio using business process modeling notation,
BPMN. The final BPMN design is shown in Figure 9-5. It can be imported as a
BPM process design diagram into Process Designer (see Figure 9-7 on
page 322).
LDAP
Content
Engine
operation
Figure 9-6 shows the created technical architecture of our auto claim process.
The auto claim BPM process design diagram is shown in Figure 9-7.
Ethernet
Figure 9-6 High level architecture for XYZ Corporation prototype auto claim process
Start End
Field Agent
Review
If <=3000 .00
Approved
Review
Reject
Escalate
If > 3000.00 For exception
Second approval
Supervisor
Supervisor
Review
Select the Additional materials and open the directory that corresponds with
the IBM Redbooks form number, SG24-7509.
The publications listed in this section are considered particularly suitable for a
more detailed discussion of the topics covered in this book.
IBM Redbooks
For information about ordering these publications, see “How to get Redbooks” on
page 327. Note that some of the documents referenced here might be available
in softcopy only.
IBM FileNet Content Manager Implementation Best Practices and
Recommendations, SG24-7547
Online resources
These Web sites are also relevant as further information sources:
Product documentation for the IBM FileNet P8 Platform
http://www.ibm.com/support/docview.wss?rs=3247&uid=swg27010422
This is where you can download the IBM FileNet P8 Platform ecm_help
documentation (ecm_help.zip), FileNet P8 System Overview (in PDF), and
many other valuable product documentation.
Index 331
workflow process 143 properties pane 71, 148, 152, 159
workflow process definition 142 select condition 235
workflow properties 71 Publisher 44
XML process definition language (XPDL) 5–6
Process Administrator 43, 205–206, 210–211
Process Analyzer 6, 13–16, 41, 44, 320
Q
questionnaire 309
database 42
queue
OLAP 42
component queue 274
process automation 2
component queue, import operations 279
process configuration 39
definition 51
Process Configuration Console 43, 268–269, 274
Instruction Sheet Interpreter 268
process definition 6, 9, 51, 305–306
work queue 164
definition 7
queues
Process Designer 5–6, 9, 39, 43, 47, 128, 132, 158,
component queues 272, 276
267, 269, 274, 276, 280–281, 304, 320
component queues 276
malfunction map 121 R
step palette 72 Receive system function 264–265
workflow properties 71 receive Web services 288
process designing 4 Records Crawler 21
Process Engine (PE) 4, 6, 13, 15, 21, 36, 43, 47, Records Manager 20
49–51, 129, 186, 258, 261, 272–273 Redbooks Web site 327
APIs 10, 12, 43 Contact us xiv
component 36 region
components 47 isolated region 49–50, 79, 275, 282, 286, 289
database 42, 44, 46, 50 Reply function 87
event log 15 Reply step 288, 296–297
logical view 49 reply step 49, 231, 245
server 50–51, 272, 275 Reply system function 264
system 41, 50 reply Web services 288
Process Engine (PE) Kernel 41 requirements gathering 305
process flow 305 Return on investment (ROI) 310, 323
process improvement cycle 14 role 55
process instance roster 80
definition 51 definition 51
process modeling 4 route 7
process monitoring 5–6 conditional route 114, 128, 176
process optimization 3, 5 definition 8
Process Orchestration 40 parallel 9
process orchestration 263–264 routes
process server 50 multiple routes 150, 152
Process Simulation Console 44 routing 28, 58
Process Simulation Designer 44 conditional routing 59
Process Simulator 5–6, 13–14, 42, 44, 320 simple majority 62
process subscription 191 single routing 58
Process Task Manager 43, 283 Rules connectivity framework (RCF) 267
Process Tracker 150, 205–206 rules engine 41, 267–268
process voting 61 rules engine framework 5
properties 71 Rules Framework 41
Index 333
Partner link 291, 294, 299, 301 multiple Reply steps 265
publishing 301 publishing as Web services 301
reply, receive 288 validate and check 231, 245
standards 261 Web services 142, 230, 244
use case examples 262 Web services step 249
workflow properties 291, 296 work item 137
Web services (WS) 255–256 workflow process definition 142
Web Services Description Language (WSDL) 261, workflow properties 57, 71, 77
287, 289 workflow property 128, 134, 288, 290
Web Site 325 data fields 231
WebSphere Business Modeler 5–6 Web services 294, 299
work item 51, 74, 80, 137, 152, 258, 264, 274, Web services information 288, 291
286–288 workflow group 206
data field 286 workflow subscription 128, 186
data field values 74 special expressions 195
work packet 28, 30, 61 Workplace 10, 12, 68
routing 28, 30 Workplace XT 10
work queue 51, 164 WS-Adapter 265, 287
workflow 2, 128–129, 142, 186, 258–259, 272, 274 WS-Listener 265, 287
Base Workflow 78–79 WSPending table 287
definition 2 WSRequest 265
process 189 WSRequest queue 287
process definition 6–7, 9
Process Designer 5–6, 9, 39, 43, 47, 128, 132,
158, 267, 269, 274, 276, 280–281, 304, 320
X
XML data field 291
Process Simulator 5–6, 13–14, 42, 44, 320
XML file 275, 282
step, Submap step 8
import 275
step, System step 8
XML message 295, 300
version 192
XML process definition language (XPDL) 5–6
work queue 51
XML schema 87, 117, 261, 291
workflow definition 68, 79–80, 143, 189, 207, 285,
XML Web services 261
291
XYZ Corporation
disable email notification 81
sample solution 55
Reply functions 87
system functions 105
workflow group 57, 78, 83, 140–141
definition 117
name 140
setup 206
workflow inheritance 117
workflow map 70–71, 91, 128, 142, 242, 268, 285,
293
main 128, 184
workflow name 79, 135, 232, 297
workflow process 121, 128, 132, 140, 212,
231–232, 241, 244, 259, 261, 272, 288, 303, 306
definition 142, 221
document title 144
map 128, 146, 157