IGrafx 2011 en BPEL Implementation Guide

BPEL Implementation Guide
iGrafx® 2011 BPEL Implementation Guide
© 2010 Corel Corporation. The contents of this guide and the associated iGrafx software are the
property of Corel Corporation and its respective licensors, and are protected by copyright. Any
reproduction in whole or in part is strictly prohibited. For more complete copyright information
about iGrafx products, please refer to the About iGrafx section in the Help menu of the software.
© 2010 Corel Corporation. All rights reserved. iGrafx® FlowCharter™ 2011, iGrafx®
Process™ 2011, iGrafx® Process™ 2011 for Six Sigma, iGrafx® Process™ 2011 for Enterprise
Modeling™, iGrafx® Process™ 2011 for SAP®, Process Central®, Enterprise Central®,
Enterprise Modeler®, Enterprise Modeler® for SAP®, iGrafx® Gateway for SAP® Solution
Manager are all trademarks or registered trademarks of Corel Corporation and/or its subsidiaries
in Canada, the U.S. and/or other countries.
Other product, font, and company names and logos may be trademarks or registered trademarks
of their respective companies.
Rev: June 9, 2010
Table of Contents
Introduction to BPEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
What Is BPEL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
What BPEL Is Not . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Who Uses BPEL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Why Use BPEL? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
About iGrafx and BPEL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Advantages of iGrafx BPEL Exporting and Implementation . . . . . . . . . . . . . . . . 5
Getting Started with BPEL Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Elements of BPEL Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Work Done at an Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Activity Sequencing, Parallelism, and Synchronization . . . . . . . . . . . . . . . . . 9
Message Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Choose an iGrafx Process or BPMN Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Choose a BPEL Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
About WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
The Generated WSDL File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Namespaces and BPEL Export. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Externally Defined and Controlled Namespaces . . . . . . . . . . . . . . . . . . . . . 17
BPEL Export-Defined Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
WSDL Import and Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Map iGrafx Messaging to WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
iGrafx and BPEL Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

About BPEL Export. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Files Used in BPEL Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
iGrafx Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Define Send and Receive Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Setting Up Messaging Partners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Importing Information From a WSDL File . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
iGrafx 2009 BPEL Implementation Guide 1

How the iGrafx Model Data is Mapped to BPEL . . . . . . . . . . . . . . . . . . . . . . . . 30
Generating Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Identifying the Origin of a BPEL Activity . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Flow Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Exporting a Process or BPMN Diagram to BPEL . . . . . . . . . . . . . . . . . . . . . . . 33
BPEL Implementation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

The Task Execution Goal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
The BPMN Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
The iGrafx Interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
The Example BPMN Diagram for BPEL Implementation . . . . . . . . . . . . . . . . . 39
The WSDL File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
The Mapping File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
The BPEL Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
BPEL Export and Mapping Files Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
Working With WSDL and Mapping Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Generating a Single Process Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

BPEL Export Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
iGrafx API Support for BPEL Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Importing WSDL into iGrafx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Limitations of BPEL Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
BPEL Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
The BPEL for Web Services Specification. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
2 iGrafx 2009 BPEL Implementation Guide

Introduction to BPEL 1
The following topics discuss BPEL and iGrafx products, and how you can combine them for
optimal business solutions in your environment.
What Is BPEL?
BPEL is an XML-based language designed to allow multiple computing environments to
share tasks that use a variety of web services. These environments and services can be
contained within one organization or expand across several organizations.
In the context of an iGrafx model, BPEL specifies a sequence of messages to automatically
communicate with a web service partner (messaging partner) to accomplish tasks in a
process. Messaging partners can be customers, suppliers, partners, or any entity that
performs a service that can be defined by a Web Service Definition Language (WSDL).
BPEL uses WSDL to define how to use the web service, such as obtaining product codes or
pricing from a set of vendors. BPEL runtime engines execute the BPEL code to perform
tasks in the process you designed in your iGrafx diagram. In addition to the web services
interaction model, a BPEL file can also describe how a process participates in a business
transaction.
A team of developers from Microsoft®, IBM®, Siebel® Systems, BEA®, and SAP®
created BPEL, which combines and replaces IBM’s WebServices Flow Language (WSFL)
and Microsoft’s XLANG specification.
With iGrafx® 2011, you can define messaging partners and enable web services with a
Business Process Execution Language (BPEL) implementation of a process. Use this guide to
help you export data from an iGrafx model–either a process diagram or BPMN diagram–to
BPEL, an XML schema for web services. With a valid BPEL license, you can use any iGrafx
diagramming application to export BPEL.
What BPEL Is Not

Non-automated activities are not supported by BPEL. For activities in the process that are
not automatically executable, a web service must be constructed to interact with a person.
BPEL is not a workflow language. Different vendors extend it in proprietary ways to address
the problem, but no standard support exists for attributes normally associated with
workflow activities. This includes attributes relating to participants and human interface.
BPEL is not a language for storing or exchanging flowcharts. It is a block-structured
programming language.
Who Uses BPEL?

In most organizations, business professionals design a process using a process diagramming
and analysis tool such as iGrafx® Process™, and then hand the process over to IT
professionals who may use BPEL to formally describe it. BPEL allows a business process to
execute across the web in such a way that any participant or cooperating entity can perform
one or more steps in the process the same way.
For example, in a supply chain process, a BPEL file might describe a business protocol that
specifies what pieces of information comprise a product order and what exceptions may have
to be handled. The BPEL program would not specify how a given web service should
process a given order internally.
4 BPEL Implementation Guide

Why Use BPEL?
BPEL is most useful for modeling a long-running business process that involves integrating
services, such as a banking. You can model the behavior of a participant in a business
interaction and the message exchange behavior of all parties involved using BPEL.
BPEL implementation can bring a new level of operations streamlining to your
organization, including:
• lower maintenance costs
• lower acquisition costs
• enterprise software module assembly
• reduced reliance on particular vendors
BPEL is an extensible, platform-neutral language that can run on multiple platforms with
minimal changes (if you avoid vendor-specific extensions). As a programming standard,
BPEL has the backing of several major vendors, including Microsoft and IBM.
About iGrafx and BPEL

None of the iGrafx diagramming applications are intended to be complete BPEL authoring
tools. BPEL is a specialized programming language. iGrafx process diagrams and BPMN
diagrams are derived from classical flowcharting methodologies, and flowcharts cannot
represent all the subtleties of a programming language. The goal of BPEL Export (the
iGrafx add-on feature that allows you to export BPEL from an iGrafx diagram) is to compile
diagrams that are conveniently and accurately represented in a flowcharting methodology
into equivalent BPEL files.
For more information, see iGrafx and BPEL Implementation on page 23.
Advantages of iGrafx BPEL Exporting and Implementation

iGrafx process diagrams and BPMN diagrams can be exported as BPEL with one easy
command in iGrafx. From there, you can use the generated files to execute on defined
messages from the process via web services.
iGrafx provides accurate process definitions using diagrams, not text. Business professionals
who design a process can change it by changing the iGrafx diagram that models the process,
improving the accuracy of communication with programmers. Also, by abstracting
messaging above the detailed WSDL model, you can remap the messaging concepts in your
process to different WSDL implementations by changing the mapping file. (For more
information, see The Mapping File on page 47.) This could include anything from invoking
the same service provided by a different partner to invoking a completely different WSDL
operation. This helps preserve a separation between the flow and logic of the process and the
details of the activity implementations.
iGrafx BPEL Export features these product strengths and capabilities:
• Automatically extracts graphical loops that can be legally converted into BPEL
<while> elements
• Detects loops not supportable by BPEL (for example, intersecting loops)
• Correctly supports all the BPMN constructs that can be mapped to BPEL, and
produces valid BPEL code for them
• Minimizes the usage of <link> elements
• Matches the simulation of a successfully exported BPEL model to the sequence of
execution in BPEL
• Allows business analysts without explicit knowledge of WSDL or BPEL to model
processes that send and receive messages to partners
• Support for BPEL4WS
iGrafx products are compliant with BPEL and BPMN standards. Design rules are built into
iGrafx for ease of process design, modification, and maintenance. Mapping files simplify the
process of mapping messages to web services.
6 BPEL Implementation Guide

Getting Started with BPEL Implementation 2
BPEL implementation requires a basic set of elements so that exported process information
can be exchanged with messaging partners. This chapter discusses the elements of BPEL
implementation and provides a basic overview of BPEL engines and WSDL.
Elements of BPEL Implementation

BPEL implementation begins with a diagram that defines messages, messaging partners,
and a simple process flow. You can create an iGrafx process diagram or BPMN diagram that
contains the necessary elements for exporting BPEL.
BPEL Export is the add-on feature within iGrafx that exports information from a process
diagram or BPMN diagram. When you export BPEL from an iGrafx diagram, the output is
a BPEL file and WSDL file with this naming convention:
[partnername].bpel
[partnername].wsdl
where partnername is derived from the diagram name or BPMN pool name as described in
Setting Up Messaging Partners on page 28. In the following example BPMN diagram, the files

generated from BPEL export of the diagram would be named Book_Dealer.bpel and
Book_Dealer.wsdl.
The process diagram captures the following data related to BPEL:

• Work done at an activity
• Activity sequencing, parallelism, and synchronization
• Message exchanges with the outside world
Work Done at an Activity

The work done at an activity is sometimes referred to as the task at an activity. BPEL is
limited in the ways it can describe work that an activity does. Other than sending or
receiving a message, it supports only the concepts of variable assignment, wait, and

terminate. Other activity types in BPEL are actually either control structures or parallelism
and synchronization control.
This BPEL flow behavior... is specified in the iGrafx Properties dialog box on the...
<assign> Attributes page

<wait> Task page, Step tab
<terminate> Task page, On Completion tab
For information about the generation of the task portion of an iGrafx activity, see Generating
Tasks on page 31.
Activity Sequencing, Parallelism, and Synchronization

Activity sequencing, parallelism, and synchronization is related to the topology of the
flowchart and sometimes the input and output specifications of the activity. Not all process
flows that can be represented by flowcharts can be implemented in a single BPEL file. For a
detailed discussion of these limitations, see Flow Mapping on page 33.
Message Exchanges
BPEL uses web services to support messaging to partners outside the process, and it is
almost exclusively through these messages that any work gets done by a BPEL process. A
message is defined from the Properties dialog box as follows:
This BPEL object... is specified in the iGrafx Properties dialog box on the...
<receive> Inputs page

<invoke> or <reply> Task page, On Completion tab
<onMessage> Outputs page, Exceptions tab
Note
Note that the word “web” in web services is something of a misnomer as they have no
necessary relationship to web technologies or networks. The only requirement is that they can
be defined by the WSDL, and that the BPEL engine executing the program recognizes the
binding of a portType to a service and can successfully send to it.

The exported BPEL file specifies a sequence of BPEL activities. The messages you originally
define in an iGrafx model are mapped to WSDL that specifies the data that is sent and
received between messaging partners when the process is executed by a BPEL engine.
Note
BPEL Export uses the vendor 1.1 spec (BPEL4WS).
WSDL, which is accessible through a file or web URL, describes how to use web services.
BPEL Export produces a WSDL file to provide basic portType and Message definitions for
any Partner messages that you have not mapped to WSDL from a messaging partner. If the
WSDL description uses terms that differ from the messages defined in the iGrafx diagram, a
mapping file resolves those discrepancies by converting the iGrafx messages to the correct
terminology needed to execute the web services.
BPEL Export uses these four types of files:
1 document (iGrafx .igx) containing a diagram
2 mapping (.xml)
3 BPEL (.bpel)
4 WSDL (.wsdl)
For more information, see Files Used in BPEL Implementation on page 26.
Note
You can view a .bpel file or a .wsdl file using a browser, such as Internet Explorer, or any
editor or viewer that can display an XML file.

Mapping files affect the exported BPEL by mapping iGrafx message definitions to a
partner’s WSDL file. See BPEL Export and Mapping Files Example on page 49 for an
example.
The iGrafx BPEL Interface
Dashed objects and relationships shown in the diagram of the iGrafx BPEL interface, above,
are optional. Export BPEL:
• Optionally creates a default mapping file. This is the basis for an optional mapping
file that correlates WSDL definitions to their iGrafx equivalents.
• Creates a WSDL file that describes the process interface defined by the iGrafx file.
At the time you export BPEL, you can choose to create a default mapping file:
igx_bpel_export_map_default.xml
This default mapping file contains mapping for all the WSDL definitions the process
requires. Sometimes mapping is required to complete communication between the BPEL

exported from the process and messaging partners. The mapping file can also be used to
change messaging partners and other parameters without having to change the diagram.
For more information, see Files Used in BPEL Implementation on page 26.
Currently, BPEL Export does not support the notion of abstract (non-executable) processes
in BPEL. It is intended to create executable processes, and uses default values for any
required data that is missing from the model.
Choose an iGrafx Process or BPMN Diagram

Whether you choose to use a process diagram or a BPMN diagram in which to model a
process is most likely a decision based on your own best practices criteria. iGrafx provides
diagram templates for both diagram types. If you are unsure, use BPMN.
BPMN diagrams and process diagrams share the same underlying information model.
BPMN is treated as a set of diagramming conventions on top of that data, and the user
interface recasts much of it into BPMN terminology. For a complete discussion of how
process simulation modeling features are mapped into BPEL, see How the iGrafx Model Data
is Mapped to BPEL on page 30.
See the iGrafx FlowCharter User Guide or iGrafx Process User Guide for a mapping of BPMN
terminology onto iGrafx terminology.
Meaningful BPEL export requires:
• Tasks and messages in a process diagram
• Process expressions
• Web service (messaging) partners
Tasks and Messages in a Process Diagram

When you design an iGrafx model for BPEL implementation, you must define the messages
themselves and where they are used in the diagram. Often, an IT professional provides a
template that defines some of the messages that the process must send to the outside world.
The template can include messages that a business person has identified as necessary, but for
which no WSDL definitions currently exist. It corresponds to external WSDL definitions

that will be mapped with a mapping file at export. For more information, see Map iGrafx
Messaging to WSDL on page 20 and About the Mapping File on page 21.
Things that trigger BPEL in a process can be extrinsic (incoming messages) or intrinsic
(time-based). In an iGrafx BPMN diagram, these could be modeled with a Message-type
start event and a Timer-type start event.
Messages model one partner sending data to another and making a request for action.
When you order a book at an online bookstore, you are one partner and the bookstore is the
other. The message might be “Order book stock number AB123 and send it to this
address.” The data you send is the book number and your address. The action you request is
to place an order. A process may send messages to other partners or receive messages and
reply to them.
Note
WSDL uses the word “message” to mean the form of the data rather than its content or the
intention of the communication. This publication uses the word “message” in either the
iGrafx and WSDL forms, depending on the context. Wherever possible, the WSDL form of
words that are also used in iGrafx is capitalized, i.e. Message, Attribute, Fault, and
Partner.
Faults are not necessary for defining a process, but some approaches to modeling a process
will benefit from it. Faults model anticipated but abnormal occurrences. They can be
signaled (thrown) by the process itself, a partner responding to a message, or by your
execution system. One type of fault your execution system might send the process is
“Attempt to contact partner failed.” The bookstore in the previous example might throw an
AddressInvalid fault if it could not verify your address. BPEL also defines a few standard
faults, such as joinFailure.
You can find the Define Faults dialog box on the Model menu. It is also available from the
Properties dialog box on the Exceptions tab of the Outputs page or the On Completion
tab of the Task page.
In iGrafx BPMN or process diagrams, the Define Messages dialog box is available from
the Model menu or from the Inputs page, the On Completion tab of the Task page, and
the Exceptions tab of the Outputs page on the Properties dialog box. The BPMN Guide
(BPMN page of the Properties dialog box) simplifies the choice of which page to use when
defining messages on a shape in the diagram.
For more information on defining messages, see iGrafx Models on page 27.

Process Expressions and BPEL
BPEL uses expressions of the process variables and external functions in making decisions
about process flow, assigning to variables, and looping. iGrafx expressions are used for these
same functions by the simulator. BPEL does not specify an expression language, but it does
mandate that any BPEL-compliant engine must support the XPATH 1.0 standard. (See the
w3.org web site for XPATH 1.0 standard details.)
BPEL Export does not support conversion of iGrafx expressions into XPATH, and it is likely
that a model that is intended for both simulation and execution will require hand-editing of
the BPEL code. However, if your model is not intended for simulation, you may enter any
string for the expression and it will appear unchanged in the BPEL. If you use this approach,
you should ignore the warnings you get from the Properties dialog box about them. For
more on expressions, see About BPEL Export on page 24.
BPEL also uses time specifications (time-spec) for delay and time-based events. They are
created by BPMN Timer-type events or a delay specification on the Step tab of the Task
page on the Properties dialog box. If your model uses these, the resulting time-specs in
BPEL may also need modifying before you can deploy on your engine. For more
information, see About BPEL Time-Spec on page 26.
Web Service (Messaging) Partners

Web service partners, referred to as messaging partners in iGrafx, are information systems
such as service providers or product vendors in the form of a software component. They are
often continuously accessible by standard web protocols such as HTTP, FTP, or SMTP any
time of the day or night. However, WSDL supports bindings that do not depend on web
protocols.
When you use messages, the messaging partners designed into the process model appear in
the Partner drop-down list in the Properties dialog box so you can specify to whom the
message is sent. For more information, see Setting Up Messaging Partners on page 28.
Choose a BPEL Engine

BPEL implementation requires a BPEL engine for execution of messages. The BPEL engine
interprets BPEL process definitions and other inputs, then creates and starts a new process
instance of an activity triggered by an incoming message. For example, an office supply
distributor receives a request for comparison pricing on a carton of paper from various

manufacturers. When that message is received, the incoming message triggers the office
supply distributor’s process to begin the task of obtaining pricing from the various
manufacturers requested. The BPEL engine drives the actions of the messaging and task
advancement in the process.
About WSDL
WSDL is a standard for describing what a web service can do, as well as how to successfully
send a message to it. The user of the diagram does not need to understand the structure of
WSDL, but can use the simpler model of messaging in iGrafx. Five key elements of WSDL
are:
• Message–a somewhat misnamed specification about how data sent to the service
must be structured. For instance, PurchaseOrderForm might be the name of a
message. The object in this example is a blank order form; a filled form is the input or
output to an operation.
• Operation–a function that a service provides. For instance, SendPurchaseOrder
might be an operation that takes data structured like PurchaseOrderForm, i.e. a
“filled-out” form versus a blank form, as input.
• portType–a collection of related operations. For instance, the PurchaseOrderPort
might be a portType that contains SubmitPurchaseOrder, InquireAboutStatus,
and OrderModification operations.
• Binding–specifies what method to use to communicate with a portType. A common
method is SOAP. (See the w3.org web site for SOAP standard details.)
• Service–provides the addressing information for a binding that allows the BPEL
engine to locate the Service and dispatch a Message with the appropriate method to
it. A Service often provides a URL for accessing it through the world wide web, which
is where the name “web service” comes from. However, the addressing and Binding
methods are open-ended in WSDL, and your engine may support “web services” that
aren’t based on the web at all.
WSDL supports any execution environment for web service that the client and server both
understand. Every vendor decides which execution environment to use, such as Java®,
SOAP or HTTP.
WSDL is available from many sources. You can obtain WSDL from a messaging partner or
create a custom WSDL file. WSDL is also available from open sources such as Xignite, the
Open Travel Alliance for travel, the Star Consortium for automotive retail, RosettaNet for

supply chain management and xmethods.net. Many of those groups employ a community-
oriented process and make their specifications available to anyone for comments.
If WSDL definitions required for the process are not completely specified by the mapping
file, BPEL Export generates a file containing that WSDL.

The Generated WSDL File
When you export a BPMN diagram or process diagram to BPEL, iGrafx usually creates a
WSDL file. If created, the generated WSDL file resides in the directory you specify. The
generated file contains WSDL for any message or partner that is used by the model, but is
not mapped by the mapping file to actual WSDL.
You can use the generated WSDL file as the basis for creating a custom WSDL file that
more completely describes web service tasks described in the iGrafx messages. The
generated WSDL file contains invented WSDL definitions provided by BPEL Export, based
on the messaging definitions in the model.
Namespaces and BPEL Export

It is possible to have collisions in names between objects (elements) that are named by
separate, non-communicating organizations. If a book vendor defines a service that refers to
an object called a bookFault and a travel service also defines a bookFault, a process that
used the WSDL from both could be confused.
XML defines a mechanism to avoid this ambiguity called namespaces. The full name of an
object is namespaceprefix:name, where namespaceprefix might be something like bks
that stood for the URI (Uniform Resource Identifier) http://www.bookstore1.com/
services/catalog. Note that despite the fact that namespace URIs conventionally look like
URLs that you could type into a browser, they are really nothing more than unique strings
of characters. The convention of using the company domain name in the string reduces the
possibility of inadvertent collision, and also provides a simple mechanism for looking up
information or a schema on the namespace via the web if the company chooses to provide it.
A namespace can have a prefix associated with it, or it can be the single namespace that is
referred to by names that have no prefix.
Externally Defined and Controlled Namespaces

BPEL Export refers to the following externally defined and controlled namespaces.

The BPEL Namespace
Where such objects as <process>, <invoke>, <receive>, and so on are defined for
BPEL 1.1 as:
http://schemas.xmlsoap.org/ws/2003/03/business-process/
As is usually the case for BPEL files, this is the default namespace in the exported BPEL
files.

The WSDL Namespace
Defines such things as <portType>, <operation>, <message>, and so on:
http://schemas.xmlsoap.org/wsdl/
This namespace is not used in BPEL (.bpel) files and is the default namespace in WSDL
(.wsdl) files.
The partnerLink Namespace

Defines <partnerLinkType>, an extension to WSDL that is defined by BPEL:
http://schemas.xmlsoap.org/ws/2004/03/partner-link
This is usually seen with the prefix plnk, which is what is used by BPEL Export.
The XMLSchema Namespace

Defines such things as <integer>, <double>, <schema>, and so on:
http://www.w3.org/2001/XMLSchema
It is conventionally assigned the prefix xsd, which is the one that BPEL Export chooses as
well.
BPEL Export-Defined Namespaces

The targetNamespace is the namespace that contains any names defined in the .bpel file.
BPEL Export uses the same namespace for both the WSDL file that is associated with BPEL
output as well as the BPEL file itself. The name of the namespace is http://igrafx.com/
bpel-export/processes/ followed by the name of the exported process, with illegal
characters replaced by “_”. The prefix for this namespace is tns, which is also conventional.
Note that you can specify a different namespace to use with the mapping file (see The
Mapping File on page 47 and Working With WSDL and Mapping Files on page 53).
A local namespace is defined http://igrafx.com/bpel-export/local, which contains
definitions that are needed only within this file. This guarantees no name collisions with
anything the user might define, which goes in the tns namespace. The local namespace
should never be used outside of any iGrafx generated file. The prefix for it is local.

WSDL Import and Namespaces
On the Tools menu, choose Define Messaging From WSDL to import a WSDL file so that
Messages, Attributes, Partners, and Faults are defined in a way that a mapping file can be
generated, which will allow BPEL Export to map them correctly to that WSDL. For more
information about using the iGrafx API, see iGrafx API Support for BPEL Export on page 69.
The targetNamespace and other namespaces defined in WSDL are carried along with the
definitions, and preserved through to the output BPEL. For instance, if the input WSDL file
has a namespace defined with the prefix bk1 and defines a <portType> named
BookOrdering in that namespace, then the BPEL that is emitted declares that same
namespace and references the bk1:BookOrdering portType. This happens because the
mapping file carries the namespaces and namespace prefixes within itself, and maps the
message to an operation (for example, CancelOrder Message to CancelOrder Operation)
in the bk1:BookOrdering portType.
Special rules for using namespaces apply. For information, see Working With WSDL and
Mapping Files on page 53.
Map iGrafx Messaging to WSDL

The following discussion describes the iGrafx messaging model from the perspective of
mapping to WSDL.
The messaging model consists of Attributes, Messages, Faults and Partners. Attributes are
mapped to BPEL <variable>. Messages consist of data sent to a Partner, an expectation of
what to do with it, and data received back. They map to WSDL <portType>/
<operation> objects, and the data maps to BPEL Variables of the type of the WSDL input
and output <message> objects. A Fault may be mapped to a WSDL <fault> or a fault
in any namespace. A Partner is any entity to which a process can send Messages. A Partner is
mapped to one or more WSDL <portType> and one or more BPEL <partnerLink>.
BPEL Export provides default mappings in the generated WSDL file for any of these that
are not mapped explicitly. However, by using a mapping file, you can control how they are
mapped.
Note
A Message named CancelOrder could refer to a different portType/operation when sent to one
Partner than in another. The mapping file supports multiple mappings.

About the Mapping File
If a file named igrafx_bpel_export_map.xml exists in the target directory, BPEL Export
loads the definitions in it and uses them to map the iGrafx messaging objects to WSDL
objects. Some environmental settings can be determined by the mapping file.
The <targetNamespace> element can be used to override the default targetNamespace
for the BPEL and WSDL for the process. The default for a process named Order is http://
igrafx.com/bpel-export/processes/Order.
When loading the mapping file, elements load in the following order:
1 any WSDL <import>
2 WSDL Messages
3 portTypes
4 partnerLinkTypes
5 partnerLinks
6 Fault mappings
7 Message mappings
8 Partner mappings
9 Attribute mappings
By providing any or all of these, you control how iGrafx messaging is mapped to WSDL to
produce the appropriate BPEL. The details are described in Working With WSDL and
Mapping Files on page 53.

iGrafx and BPEL Implementation 3
The iGrafx interface contains these elements:
• messaging partner–Corresponds with the portType specified in WSDL. In a BPMN-
type diagram, a pool can represent a messaging partner. If you are using a process
diagram, a messaging partner is represented by the diagram name.
• message–Corresponds with the operation specified in WSDL. A message invokes an
operation in a portType supported by the partner it is sent to.
• fault–Can map to WSDL Fault. Also may map to a system-defined fault or one of the
BPEL built-in faults.
• attribute–Maps to WSDL input and output on an operation.
To create this element... Use this iGrafx command...
messaging partner Insert Department on the Departments toolbar

toolbox
message Properties dialog box
• BPMN page or
• Inputs page or
• Task page (On Completion tab) or
• Outputs page (Exceptions tab)
fault Properties dialog box
• BPMN page or
• Inputs page or
• Task page (On Completion tab) or
• Outputs page (Exceptions tab)

To create this element... Use this iGrafx command...
attribute Define Messages dialog box
About BPEL Export

BPEL Export takes an arbitrary directed graph that is described in an iGrafx flowchart and
produces a block-structured BPEL file with synchronizing links. While you can have BPEL
code that is a flat “sea” of activities that are sequenced and synchronized by links in BPEL,
the preferred convention is to use <sequence> to control sequencing and reserve <flow>
and <link> for explicit parallelization and synchronization. BPEL Export minimizes the
use of <link> and maximizes the lengths of <sequence>. It also attempts to define the
link at the lowest valid level in the hierarchy.
BPEL does not support a <link> that produces feedback loops, wherein a previously
executed activity is the target of a subsequent activity. Instead, BPEL provides an explicit
<while> activity that must enclose activities that may execute more than once. BPEL
Export automatically infers <while> activities from arbitrary feedback loops in the
diagram. Note that this is not always possible, depending on the loop flow. For examples,
see Loops on page 64. BPEL Export also attempts to detect and generate an error on loops
that BPEL cannot support.
BPEL does not allow a link to be sourced within a <while> when the target is outside the
scope of the <while>. BPEL Export attempts to detect this condition in the diagram,
which occurs when a path unconditionally forks from an activity inside a feedback loop. If
detected, it generates an error.
The overall approach to compiling the diagram into BPEL is:
1 Load the messaging definitions from iGrafx scenarios and the mapping file, if one exists.
2 Load and analyze the diagram flow.
3 Traverse the flow and generate the equivalent BPEL code, using the messaging
definitions loaded in step 1 to emit valid BPEL.
4 Generate a WSDL file that contains default WSDL definitions for any messaging
definitions in iGrafx that are not mapped in the mapping file. It is possible that this file
is not needed and will not be generated.
5 If requested, generate a default mapping file that would fully map the iGrafx
messaging definition into the WSDL generated by step 4. This file can be useful, when

generated from the first run of an export, as a starting point for creating the mapping
file used in step 1.
Expressions can occur in several places in the BPEL model, including <assign>, <wait>,
<switch>, and <while>. Expressions in iGrafx models are written in a simple
proprietary form that can reference transaction attributes (BPEL <variable>), built-in and
user-defined functions, enumerated type member names, and attributes in several global
scopes. Process expressions are global, i.e. they are shared by all transactions, yet they do
have some locality of reference within the structure of the process.
Note
The iGrafx word “transaction” is used here in the sense of a single instance of a process. It is
not related to the BPMN term “transaction.” While it is not strictly true for simulation, in
BPEL Export and in this publication, “transaction” and “process instance” are
interchangeable. Also, if the transaction is split into separate paths at an activity output, the
result is a set of family members, each of which represents a separately executing thread in the
transaction.
You can enter any string in expression fields in the iGrafx user interface, but if the string
cannot be interpreted as an iGrafx expression, iGrafx generates a warning and simulation
will not run. If you don’t need to simulate your process, you can directly enter the
expression in whatever expression language your BPEL engine prefers. To use this
effectively, you must coordinate those expressions and the mapping file variable names
manually. The expression validity cannot be checked until you deploy the BPEL.
The iGrafx expression language, if it contains only transaction attributes and operators, is
similar to simple use of XPATH 1.0. The two most common problems are that iGrafx
expressions use True and False instead of true and false, and the “&” and “|” operators are
equivalent to and and or.
If your model uses simulation, the expressions are likely to require manual editing after
export to be compatible with your BPEL engine, especially if it uses the global attribute
types or functions.
Because all attribute values in iGrafx simulations are floating point values, subparts of a
value cannot be qualified in the expression language. You can use the mapping file to map
an attribute in iGrafx to any XPATH query into a WSDL <message>, thereby qualifying
subparts of a value. Then the value of the attribute is assigned from a <variable> of that
type whenever it is received, and assigned to a <variable> of that type whenever it is sent.
For more information, see Map iGrafx Messaging to WSDL on page 20.

About BPEL Time-Spec
A time-spec is used for <wait> and <onAlarm> elements. In BPEL 1.1, it is an
attribute, for example:
<wait for="10d"/>
Currently, BPEL Export does minimal translation of the iGrafx model representation of
these quantities. The for form is represented in iGrafx as an expression and a time unit
(seconds, minutes, etc.) The expression is written unchanged into the for attribute, and the
time unit is ignored.
The until form is specified by the name of an Event, defined using the Define Event dialog
box. This is not the same as a BPMN event. An Event describes a list of points in time when
an event occurs (for instance, every Friday at 4:00) that possibly repeats. This name is used
as the value of the until attribute, and is unlikely to be meaningful to your target BPEL
engine unless the name was carefully designed when it was defined.
The result is that in many cases, if Delay, Timer exceptions, or Input constraint by Event is
used in the model, you will need to hand edit the result to make it compatible with your
BPEL engine.
Files Used in BPEL Implementation

[documentname].igx is the iGrafx document containing the diagram that models a
process from which you export to BPEL for implementation of web service messaging.
igrafx_bpel_export_map.xml is an optional file that configures the exported BPEL and
maps iGrafx messaging to existing WSDL.
[partnername].bpel is automatically generated when you export a process diagram or
BPMN diagram type document to BPEL.
[partnername].wsdl is usually required and is automatically generated when you export a
document to BPEL.
igx_bpel_export_map_default.xml maps process messaging to WSDL. This file is
automatically generated when you specify it at export. You can use it to initialize a more
custom mapping to pre-existing WSDL.

iGrafx Models
The iGrafx process diagram or BPMN diagram models the process and defines messages
and messaging partners for web services while BPEL Export generates default messages for
any that you don’t define. Normally you define one or more messages to describe how you
will communicate with partners.
Define Send and Receive Messages

Before you can send and receive messages through BPEL implementation of your process,
you must first define messages that send or receive information in the process. Next, you are
ready to lay out the activities that send and receive the messages to partners in the correct
order.
To define a message in iGrafx:
1 Open your process diagram or BPMN diagram in iGrafx.
2 Determine whether the message is an input that triggers the start of the process, is
received to start execution of a task, is sent on completion of a task, or is received to
trigger an exception output flow from a decision shape.
3 Double-click the event shape. The Properties dialog box appears.
4 Use the BPMN page or click the appropriate page (Inputs, Task, or Outputs) based on
the assessment you did in step 2.
Use this page... If you want to...
Inputs Wait until a message is received before starting a task or

activity.
Task (On Completion tab) Send or receive a message when a task or activity is
completed.
Outputs (Exceptions tab) Specify that if a message is received while the task is active,
the transaction is to take the exception path.

5 Click the Create/Modify Messages button to display the Define Messages dialog
box. Use this dialog box to add, rename, or delete custom messages that can send data,
receive data, or both based on data attributes you configure.
Send data is data that is provided by the sender of the message and received as input by the service. Receive
data is data sent by the service and received by the sender.
6 Click OK.
7 In the Properties dialog box, select a partner in the drop-down list. The Partner list is
populated by the BPMN pools and process diagrams in the document. For more
information, see Setting Up Messaging Partners on page 28.
8 Click OK.
For an example, see The Example BPMN Diagram for BPEL Implementation on page 39.
Setting Up Messaging Partners

You set up messaging partners as diagrams in your document or BPMN pools in a diagram.
This allows you to model the information flow in a diagram from one entity or flow to
another. For example, a book dealer needs to obtain price quotes from different sources. The

Book Dealer pool below represents a process that sends messages to messaging partners
Bookstore1 and Bookstore2 and acts upon message data it receives in reply.
Note
Defining a partner with a pool is not a requirement. Process diagrams also define partners.
The default partner is a placeholder in the output BPEL.
Messaging partners correspond to web services for BPEL. A messaging partner is something
with which you can exchange messages, and often represents a supplier, customer or client.
In iGrafx, all diagrams in the same document have the same available messaging partners.
One partner is defined for each process-type diagram, and it has the same name as the
diagram. If your BPMN-type diagram has no visible BPMN pool, or you are not using
pools, its name also appears in the Partners list. If you have one or more pools on the
diagram, a partner is defined for each pool name, and the diagram name is not used.
You can send messages to partners that do not appear on your diagram if you prefer not to
show them. It is important to realize that BPMN message flow lines (shown as dashed lines)
do not specify messaging. Message flow lines are optional, and serve as visual

documentation. You specify the partner a message is sent to in the same place in the dialog
box where you specify the message sent.
Two additional partners exist, one explicitly and one implicitly. A default partner for all
diagrams would serve as a placeholder in the output BPEL. Also, if you send or receive
Cancel- or Rule- (expression) based events, they are presumed to go to, or be received from,
a system partner as support would have to be provided in the BPEL engine to have this
functionality available.
It is possible to define messaging from existing WSDL as described below. In this case, you
may also see one or more partners that were created from a WSDL service definition.
Importing Information From a WSDL File

While it is not necessary to understand or use WSDL to create a process that is targeted for
BPEL export, it can be convenient to automatically define iGrafx messaging objects for
specific WSDL. WSDL portType and operation names are typically long and likely obscure
to non-programmers, but that is not a requirement of the standard. To define messaging
from a WSDL file, from the Tools menu, choose Define Messaging From WSDL. If you use it,
you may find a large number of Messages defined, along with Attributes for any input or
output from them. However, you can freely delete any that you don’t use in the Define
Messages or Define Attributes dialog boxes.
Note
If you rename the imported Messages or Attributes, it will break a mapping that may exist in
the mapping file.
For more information on using the iGrafx API, see iGrafx API Support for BPEL Export on
page 69.
How the iGrafx Model Data is Mapped to BPEL

BPEL Export uses BPEL 1.1.
For information about mapping a single activity, with the exception of messaging, see
Generating Tasks on page 31.
For information about the mapping of the diagram flow, see Flow Mapping on page 33.

For information about the mapping of iGrafx messages into WSDL and BPEL, see Map
iGrafx Messaging to WSDL on page 20.
Generating Tasks
In the iGrafx process diagram, an activity is any shape in the flowchart. Any activity can
exhibit any combination of the behaviors of an activity. BPEL, and to a lesser extent BPMN,
limits the functionality of a single activity. Consequently, mapping a single activity in iGrafx
can produce many BPEL activities.
Note
BPMN actually divides shapes in the diagram into three types of flow objects. In addition to
activity, at which work, messaging, and some forms of conditional output can be done, there
are events, which are focused on single time points and do synchronization or fire events, and
gateways, which merge and diverge flow. A single iGrafx process diagram activity can do
any or all of these.
Attribute assignment can be done at several points throughout the execution of a Process
activity, some of which are coincident for purposes of BPEL export.
The steps for generating a single BPEL activity may include any of the following, in order:
1 Generate input synchronization.
2 Open the <scope>, <sequence> and/or <flow> activities required to support the
output and exception structure of the activity.
3 Open the <while> specified by the Repeat configuration on the activity.
4 Generate <copy> activities for the entry assignments.
5 Generate input <receive> or <wait> for the input Message or Event.
6 Generate <copy> activities for post-input and pre-task assignments.
Note
These are separated by resource acquisition in the simulator. Because resource acquisition is
not mapped to BPEL, they happen at the same time for BPEL.
7 Generate <wait> if the task type of the activity is Delay.

8 Generate subprocess <invoke> or open <scope>. If it is a scope, the subprocess is
recursively generated at this point.
9 Generate <copy> for post-task assignments.

10 Generate <invoke>, <reply>, <throw> or <terminate> for the on-completion
specification. This may involve a <switch> for Fault or Discard cases.
11 Generate <copy> for exit assignments.
12 Close the <while> opened in step 3.
13 Close any structure opened in step 1.
An iGrafx activity may contain modeling data that is not meaningful to BPEL. Two areas in
particular are Resource allocation and queuing, and multi-transaction input synchronization
or output behavior.
The BPEL standard does not address resource requirements for an activity. It assumes the
web service and any data passed to its invocation will determine the resources needed, if any.
As such, BPEL Export assumes the model for resource acquisition on the activity is part of
the model of the behavior of web service at that activity.
Process simulation has as a primary of goal analyzing the effects of resource contention
among many simultaneously executing transactions. As a result, some modeling features at
an activity can create, synchronize, and destroy transactions. BPEL is only concerned with
the behavior of a single transaction, so those modeling features are assumed to model the
behavior of the activity rather than define its action. The modeling features include on-
completion behaviors like duplicate and unbatch, input collection behaviors like batch,
group, and join when it combines separate instances rather than separate family members,
and input constraints like by count, by attribute member, and entire group.
While a fully featured iGrafx model can generate extensive BPEL, the vast majority of
models in real-world process diagrams generate one or a few BPEL activities. If an iGrafx
activity generates no BPEL activities at all (which is the case for a default activity that has a
single output, for instance), BPEL Export inserts <empty> to represent it in the BPEL.
For more information on the steps of mapping the activity, see Generating a Single Process
Activity on page 57.
Identifying the Origin of a BPEL Activity

The first BPEL activity generated for an iGrafx activity is given a name attribute composed
of the letter A followed by the diagram object ID of the shape that represents the activity in
the diagram. This ID can be seen on the General page of the Properties dialog box and
serves as a unique serial number for the shape, generated when it is created, in the scope of
the diagram. Additionally, if the shape has text in it, a comment containing that text

immediately prior to the first BPEL activity is generated. Finally, for each <case> of a
<switch>, a comment containing the case number of the output, if any, and the name of
the Case, is generated.
Note that usually, but not always, the first BPEL activity for a shape is either the only one,
or a <scope>, <flow> or <sequence> compound activity that opens the iGrafx
activity.
Flow Mapping
BPEL can be viewed as a block-structured (strict hierarchy) programming language with
strong support for threads and synchronizing links between them. A flowchart is a directed,
cyclic graph.
BPEL Export has a flow analysis phase and a BPEL generation phase. In the flow analysis
phase, BPEL Export traverses a flowchart to produce the tree, the links among the branches,
and the <while> elements, when possible, to handle the cycles in the flowchart. For more
information about the flow analysis phase, see BPEL Export Flow on page 63.
Exporting a Process or BPMN Diagram to BPEL

After you have completed a process diagram with defined messages and messaging partners,
you are ready to export information contained in the diagram to BPEL.
To export BPEL from an iGrafx diagram:
1 From the Tools menu, choose Export BPEL.
2 In the Export BPEL dialog box, browse to a folder that will contain files generated by
the BPEL export function.
• If you have a custom mapping file from a messaging partner, make sure that it is
in the folder you specify in the Export to Folder text box.
• If you do not have a mapping file, you can choose to select the Export default
map file check box to create a default mapping file.
3 Click OK.

4 View the folder you specified in the Export to Folder text box. It should contain a
BPEL file, usually a WSDL file, and a mapping file if you specified it.
Note
You can view a .bpel file or a .wsdl file using a browser, such as Internet Explorer, or any
editor or viewer that can display an XML file.

BPEL Implementation Example 4
The following is an example of BPEL implementation from an iGrafx BPMN diagram for a
book vendor. In this example, the business professional creates a BPMN diagram that
defines messages and messaging partners based on task execution goals. Then, the IT
programmer obtains a WSDL file from a messaging partner to use with BPEL Export and
creates a custom mapping based on the default output. The final step is deployment to a
BPEL engine.
The Task Execution Goal

In this example, our process is represented by a pool called Book Dealer in the BPMN
diagram. It contains messaging requirements for completing the task of ordering a
particular book from a supplier. The web services implementation executes the following:
1 Receive a request for a book by ISBN code.
2 Request a price from two suppliers identified as Bookstore1 and Bookstore2.
3 Wait until both suppliers have responded.
4 Compare the prices.
5 Order from the supplier that quotes the lowest price.
The BPMN Diagram

The example uses a BPMN-type diagram, and all terminology used in this section is BPMN
terminology unless it is apparent in context otherwise. Most people find BPMN is easier to
use for defining message-based processes. You can use the Shape Palettes window to
conveniently place message-related events and activities. The BPMN Guide (the BPMN
page of the Properties dialog box) and its Details button aid message and partner
specification. The Attributes page of the Properties dialog box defines assignments, and
the Normal tab of the Outputs page is where you specify decision expressions. You may
also use the Step tab of the Task page to establish repeat activities.

In this example, the message flow lines were drawn to document the messaging visually.
However, these are optional as described in Setting Up Messaging Partners on page 28.
You can model a web service process in either a process diagram or a BPMN diagram.
BPMN diagrams provide shape palettes that are useful for modeling a process for BPEL
export. A process modeled in iGrafx contains events, gateways, tasks, activities, pools
(BPMN), and floating departments (process). It models messages as events or on-
completion tasks and defines messages to be sent to messaging partners. The process also
identifies messaging partners, and specifies partner WSDL files to be used with BPEL for
web service execution.
In this example, a BPMN-type diagram models a process that exchanges messages with two
messaging partners. BPMN pools represent the process and the two messaging partners.
The client that started the process is also an implicit partner. In this model, we are using the
default partner for the implicit partner.

For a complete set of instructions for creating the example process diagram, see the
following procedures in The Example BPMN Diagram for BPEL Implementation on page 39:
1 Define pools representing the Book Dealer process and partners that communicate with
the Book Dealer process.
2 Draw connection lines representing the flow of the process.
3 Define attributes representing data sent and received by messages.
4 Define the behavior of the Book Dealer process events and activities.
5 Define the behavior of the Book Dealer process gateways.
6 Draw message lines.
The iGrafx Interface

When you create a new BPMN diagram, a start event shape is placed by default. You can
change the start shape to a Message-type start event using the BPMN Guide (the BPMN
page of the Properties dialog box) or delete the shape and replace it with a Message-type
start event from the Shape Palettes window.
A Message-type start event receives a message. If you modify it to send data, the event
shape changes from a start event to an end or intermediate event, depending on how it is
connected. This is a BPMN compliance rule in the BPMN-type diagram. For more
information about placing shapes in iGrafx diagrams, see the iGrafx Rapid Learning Guide or
the iGrafx Help system.

When you define messages in an iGrafx diagram, you use the Define Messages dialog box.
The Define Messages dialog box is available from the Properties dialog box.
If the message... It is defined on the...
Causes the transaction to wait until the message is received Inputs page
before starting a task or activity.
Is to be sent or received when a task or activity is Task page (On
completed. Completion tab)
Is received, the transaction is to take the exception path. Outputs page
(Exceptions tab)
Note
You can use the BPMN Guide (the BPMN page of the Properties dialog box) to simplify the
transaction choice for you.
Although you cannot control whether a messaging partner actually sends or receives a
message, you can specify that messages are sent and received between your process and a
messaging partner. For example, a task or activity that sends a message to a messaging

partner requesting data to be returned from the messaging partner on completion of the
task is defined from the Task page, On Completion tab.
Message-type events in a BPMN diagram are restricted activities, and the BPMN Guide
makes it easier to establish the message and messaging partner.
The Example BPMN Diagram for BPEL Implementation

Use the following procedures to create the example BPEL implementation discussed
throughout this guide.
Define pools representing the Book Dealer process and partners that communicate with the Book Dealer
process.
1 If rulers are not visible, on the View menu, choose Rulers.
2 On the File menu, point to New and choose BPMN Diagram. A new BPMN diagram
appears with a default BPMN pool populated with a start event shape.
3 Click the Department Name area of the BPMN pool and type “Book Dealer”.
4 Click empty space in the diagram and click the Department Name area to highlight it.

5 Place the cursor over the sizing handle at the lower right corner of the selected name
area, then click the mouse button and drag the handle to the right and down to make
the name area approximately 1 inch wide and 3 inches high.
6 Place the cursor in the name area, right-click and choose Insert Department. The Insert
Department dialog box appears.
7 Type “Bookstore1” and click the Apply button.
8 Type “Bookstore2” and change the Location drop-down to After.
9 Click OK to dismiss the Insert Department dialog box.
10 Click the “Bookstore1” name area and use the bottom-center sizing handle to shorten
the department to approximately ½ inch high. Follow the same procedure to shorten
the “Bookstore2” department to approximately ½ inch high.
11 Click the start event shape and type “Receive Book Request”.
12 Click empty space on the diagram and then click the start event shape. Using the arrow
keys, center the shape vertically in the Book Dealer department as shown:
Add shapes representing process activities, events and gateways.

1 On the Toolbox toolbar, click the Activity shape. Move your cursor to empty space in
the “Book Dealer” department. Click and hold the left mouse button (a shape outline
appears). Align the cursor approximately 3½ inches right and 1½ inches down from the
left and top border and release the mouse button.
2 With the shape selected, type “Get Bookstore1 Quote”.

3 Click empty space, then click again and hold the left mouse button. Add another
Activity shape approximately two inches below the other Activity shape.
4 With the shape selected, type “Get Bookstore2 Quote”.
5 Add two Gateways and two Events to the diagram in the approximate locations shown
below:
6 Label the right-most Gateway “Store1 Lower?”
Draw connection lines representing the flow of the process.

1 Place your cursor inside the right side of the “Receive Book Request” shape.
2 Click and hold the left mouse button, drag the cursor to inside the left border of the
“Get Bookstore1 Quote” shape and release the mouse button.

3 Add connection lines as shown below. Disregard the warning displayed on the Gateway.
Draw the connection from the “Store1 Lower?” decision shape to the Event shape below
it first to make the decision case work correctly.
Define attributes representing data sent and received by messages.

1 On the Model menu, choose Attributes. The Define Attributes dialog box appears.
2 Click the Add button, type “ISBN” and click OK.
3 Add these additional attributes: “Bookstore1Price” and “Bookstore2Price”.

4 Click OK.
Define messages sent and received by the “Book Dealer” process.

1 On the Model menu, choose Messages. The Define Messages dialog box appears.
2 Click the Add button and type “RequestBook”. You may enter a description for the
message to document its purpose or any other internally used information.
3 Select the Receive Data check box and select the ISBN check box.
4 Click the Add button and type “Bookstore1GetPrice”. Select the Send Data, ISBN,
Receive Data and Bookstore1Price check boxes.
5 Click the Add button and type “Bookstore2GetPrice”. Select the Send Data, ISBN,
Receive Data and Bookstore2Price check boxes.
6 Click the Add button and type “Bookstore1Order”. Select the Send Data and ISBN
check boxes.
7 Click the Add button and type “Bookstore2Order”. Select the Send Data and ISBN
check boxes.
8 Click OK.
Define the behavior of the Book Dealer process events and activities.
1 Double-click the start event shape. The Properties dialog box appears.
2 In the Modeling section, click Inputs.
3 On the Inputs page, select the Collect Transactions at Input check box and select
Gate and by Message from the first two drop-down text boxes.

4 Change the Name drop-down to RequestBook.
5 Change the Partner drop-down to <default>.
6 While the Properties dialog box remains visible, click the “Get Bookstore1 Quote”
shape.
7 Click the Task page, On Completion tab.
8 Define a message by changing the drop-down list that says None to Message. Change
the Name drop-down to Bookstore1GetPrice. Change the Partner drop-down to
Bookstore1.

9 Click the “Get Bookstore2 Quote” shape and repeat step 8 using Bookstore2GetPrice
for the message name and Bookstore2 for the partner name.
10 Click the top-most end Event shape (circle with a thick border). Define a message with
Name set to Bookstore1Order and Partner set to Bookstore1.
11 Click the other end event. Define a Message with Name set to Bookstore2Order and
Partner set to Bookstore2.
12 Click OK.
Define the behavior of the Book Dealer process gateways.

1 Double-click the left-most Gateway (diamond) and click the BPMN guide. Change the
Gateway Type drop-down to Inclusive (OR).
2 While the Properties dialog box remains visible, click the “Store1 Lower?” shape and
click the Outputs page.
3 On the Normal tab, select Expression and click the Expression Builder button.
The Expression Builder dialog appears.
4 Click the Paste Attribute button. The Paste Attribute dialog box appears.
5 Double-click Bookstore1Price. Type “<” to the right of this attribute and click the
Paste Attribute button.
6 Double-click Bookstore2Price. In the Expression Builder dialog box, click OK.
7 Click OK.

Your diagram should look like this:
Draw message lines.

1 Place your cursor inside the top border of the “Get Bookstore1 Quote” shape.
2 Press and hold the left mouse button, drag the cursor to bottom border of the
“Bookstore1” department and release the mouse button.
3 In the same manner, add a message line to the top border of the “Bookstore2”
department.

Because we used dashed lines to show message flow we will turn off the message indicator
visible on the two BPMN activities.
1 On the Format menu, choose Diagram.
2 In the Format Diagram dialog box, click the Indicators tab and clear the Send
Message box. You may need to scroll the list to view this.
3 Click OK.
The WSDL File

If you export this process without providing a mapping file that maps all the messages and
partners, a WSDL file is generated to define them. It also defines the WSDL for the BPEL
process itself, since any BPEL process is also a web service by definition.
The Mapping File

A mapping file allows your process and the messaging partner to communicate using the
same terminology by mapping two terms with the same meaning. Likewise, you may have
two messaging partners that use the same term to describe different objects. Again, the
mapping file sorts out these differences so that all entities can communicate with efficiency
and accuracy. For example, your iGrafx process uses the term BookError and one of your
messaging partners uses the term BookFault to describe the same programming object. The
mapping file bridges the miscommunication by mapping the terms to each other.
For more information, see Working With WSDL and Mapping Files on page 53.
In this example, the IT professional may have provided an iGrafx document template that
predefines some of Bookstore1’s book searching messages against the publicly available
Bookstore1WebServices.wsdl definitions. These are defined such that processes created
using the template can use a standard map file to export correct BPEL for accessing this
service without further editing, other than to provide the correct location for the
Bookstore1WebServices.wsdl file at deployment time.
Further, in this example, IT does not have templates provided for Bookstore2 or for book
ordering (not searching as in Bookstore1WebServices.wsdl above) for either store. In this
case, the business professional creates the process using the previous template, and the IT
professional adds mapping information for it later after evaluating and qualifying the
services provided by Bookstore2 for searching and ordering, and by Bookstore1 for
ordering.

To load a WSDL file into an iGrafx template, on the Tools menu, choose Define Messaging
From WSDL or use an iGrafx API as described in iGrafx API Support for BPEL Export on page
69.
All messages in this example, with the exception of the RequestBook message, must be
mapped to a WSDL portType from those partners that provide the functionality.
The RequestBook message is provided by the portType for the Book_Dealer process itself,
and appears in the generated WSDL file.
The BPEL Engine

Every BPEL engine is unique and must be configured to run BPEL. A BPEL program
defined to run on one engine may not run on other engines.
Please refer to the documentation for your BPEL engine to configure it for proper BPEL
execution.

BPEL Export and Mapping Files Example Appendix A
This example shows how a mapping file affects the BPEL exported from iGrafx. The Get
Bookstore1 Quote activity is the focus of the example.
At the Receive Book Request shape, the Message-type start event properties are set to
collect transactions at input on the Inputs page of the Properties dialog box in iGrafx.
Gate by Message causes the RequestBook message to trigger the process to start at this
shape. The Partner is set to default.
BPEL Export and Mapping Files Example 49

The Get Bookstore1 Quote activity has one message defined:
If no mapping file resides in the export folder, the Export BPEL command (on the Format
menu) produces the following BPEL code for the Get Bookstore Quote activity:

Before you run the BPEL Export command again, place the following mapping file in the
export folder. This file maps the iGrafx message definitions to the Amazon® WSDL
describing how to get a price quote from Amazon:
BPEL Export and Mapping Files Example 51

Because the above mapping file resides in the export folder, the Export BPEL command
produces this BPEL code for the Get Bookstore1 Quote activity:
This example shows how BPEL complexity can be hidden from the iGrafx user. The process
analyst can concentrate on the process flow and ignore much of the intricacies of a
programming language such as BPEL.

Working With WSDL and Mapping Files Appendix B
The sequence of operations for loading a mapping file is listed on page 21 in the section Map
iGrafx Messaging to WSDL. The following is a detailed description of those steps.
A schema and namespace are available from:
http://www.igrafx.com/schemas/2005/igrafx-BPEL-mapping
Importing WSDL
WSDL is imported as part of the BPEL Export function. The first phase of loading the
mapping file is to resolve and load WSDL imports. This can be a convenient way to simplify
the mapping file, but is not necessary. It can reduce or eliminate steps 2 through 8 of the
map file load process described in About the Mapping File on page 21.
Working With WSDL and Mapping Files 53

Importing WSDL does the following for BPEL Export:
• Defines WSDL message names and part names.
• Defines portType names, associates operations with those portTypes, and associates
input and output messages with the operations.
• Defines partnerLinkType names, their role names and portTypes.
• Creates a Partner for any <service> element.
• Creates a Message for every operation in every portType.
• Creates an Attribute for input and/or output of each Message.
• Creates a Fault for every WSDL fault. The name of this Fault is formed as a
combination of the Message name from the associated operation and the name of the
WSDL fault.
Note
The Partner, Message, Attribute and Fault definitions are not defined in the iGrafx model
itself, but are matched by name to those in the model. If definitions conflict, the one from
WSDL takes precedence for purposes of export. If you want to define these to be visible to the
user, see Importing Information From a WSDL File on page 30.
WSDL messages
The <WSDLMessages> element specifies the existence of a WSDL message. Each
<part> element specifies a part name in the message. There is no type information
specified because BPEL Export does not require it.
WSDL portTypes
The <portTypes> element specifies the existence of a WSDL portType, and the names of
the operations and their inputs and outputs. It is defined the same as a WSDL
<portType> element, but only <operation>, <input>, <output>, and the
corresponding message attributes, are interpreted.

partnerLinkTypes
The <partnerLinkType> element specifies the existence of a BPEL
<partnerLinkType> and the roles and portTypes in it. It is identical to the BPEL
partnerLinkType.
partnerLinks
The <partnerLinks> element defines partnerLinks and the roles in them. It is identical to
the BPEL partnerLink.
Fault Mappings
The <DocFaults> element maps Faults to WSDL Faults, BPEL predefined faults, or other
fault names. The fault attribute provides the name that a BPEL <throw> or <catch>
element will use. If the <HasValue> element exists and its text evaluates to true, then the
<ValueType> element text provides the type name. If ValueType is not supplied, the value
type defaults to xsd:double.
Message Mappings
The <DocMessage> element maps Messages to WSDL portType/operation pairs.
iGrafx messages define a set of attributes that are sent with or received from the Message.
The send set is mapped to a variable for the <input> element of the WSDL operation,
and the receive set is mapped to a variable for the <output>. Note the terms send and
receive are from the perspective of the client of the Message.
The <DataSent> and <DataReply> elements respectively define the input and output
for an invoke. Each <Value> child element refers to the name of an Attribute value that is
copied to or from the variables specified on the invoke. For more information, see Attributes
on page 56.
Each <portTypeOperation> child of a <DocMessage> element specifies an operation
in a portType that will be invoked when the Message is sent in the model. Which one is used
depends upon the portType(s) associated with the Partner that is to receive the message.
Working With WSDL and Mapping Files 55

Partner Mappings
The <DocServices> element specifies the Partners and the portTypes they support. Each
<portType> element names a portType that is supported by the Partner. The portTypes
are used in conjunction with partnerLinks to determine which partnerLink is the target of a
given invoke.
Attributes
The <Variables> element defines how attributes in the model are mapped to
<Variable> elements in the BPEL. This mapping occurs whenever a message is received or
sent in the model.
During simulation, a transaction attribute refers to a floating point value associated with the
transaction. However, BPEL Export can map an attribute to any type. Three different
mappings correspond to three of the from-specs and to-specs of the BPEL <copy>:
1 An entire BPEL variable
2 A message part of a BPEL variable
3 Any value that results from an XPATH query on a BPEL variable
The <Variable> element specifies the attribute name and the WSDL message type or
XML Schema type it is mapped to. If it is an XML Schema type, one or more
<WSDLMessage> elements may appear. These <WSDLMessage> elements define
message types and a query path into them that the attribute should be copied from after
receiving a message or copied to prior to invoking a message. If the query attribute begins
with the “/” character, it is a query path. Otherwise, it is the message part name. If query is
empty, the attribute name is used as the message part name.

Generating a Single Process Activity Appendix C
The following is an overview of the algorithm for analyzing a shape, which is intended to
allow you to better understand the BPEL generated from a particular diagram. However,
you can successfully use BPEL Export without analyzing each shape in the process.
Note
The terms introduced here are used to describe the algorithm and are not meant to suggest
standard terminology.
This procedure is referenced in Generating Tasks on page 31. A detailed explanation of each
step follows.
Step 1: Input synchronization

Before any activity in BPEL executes, BPEL must determine the status of all the links it is a
target of (all the incoming paths). BPEL also supports expressions of those links so that once
they are all determined, the activity may still not execute if the expression is false, and an
optional joinFailure fault can be thrown. The default is an OR of all the links; if any link is
fired, the activity executes. In iGrafx terms, this is a join by entire family, or the BPMN
Inclusive-or Gateway. The only other expression that iGrafx supports is an AND of all the
links, the join by input path by family, and is equivalent to the BPMN Parallel Gateway.
However, the current BPMN specification indicates that a parallel gateway without all
incoming link paths activated is a design error. With that assumption, there is no behavioral
difference to BPEL between an iGrafx join by family and a join by input path by family.
All input joins are treated as default BPEL joins, with suppressJoinFailure=true. As a
result, no explicit BPEL code is generated for joins, other than the links themselves.
Generating a Single Process Activity 57

Step 2: Open activities needed to support output flow
Any output from an iGrafx activity can be unconditional, conditional, or exception. One
output may also indicate compensation. An activity can have any combination of these
output types, which results in significant complexity in both opening the activity and
generating the fan-out from it in step 13. See some of the implications in the discussion
below.
The compensation exception is not actually an output, but is used to establish a
<compensationHandler> for the scope of the activity. If it is specified, the
<compensationHandler> and its corresponding <sequence> is generated within the
<scope> opened for the activity, as mentioned in the following paragraph. The
<sequence> must close within the <compensationHandler> without sourcing links
back into normal flow. This translates into a diagram that has no path from the
compensation exception to any activity that is also on a path from any other compensation
exception or any activity output. An error is generated if a violation of this rule is detected in
the diagram.
If the activity has exception outputs, a top level <flow> is used to contain the normal
output flow sequences along with the exception sequences. This is followed by a <scope>
to contain the <faultHandlers> and <onMessage> and <onAlarm> elements that
are used to implement the various exception types, as well as the
<compensationHandler>, if specified. Finally, a <sequence> is opened, if necessary,
and the activity task is generated (steps 3 through 12). This structure is then closed in
step 13.
If the activity has any Fault exceptions, a <catch> is generated for each one, or a
<catchAll> if it is an Any Fault. Any other exception type generates a <catch> for an
internally defined fault, which is thrown by the associated <onMessage> or <onAlarm>
described in the next paragraph. The <catch> activities themselves simply fire links whose
targets are the associated output sequences generated in step 13.
If the activity has any exceptions other than Fault exceptions, an <eventHandlers> is
opened. If it has Timer exceptions, <onAlarm> is generated for each of them. Note that
for until type onAlarm activities, the name of the iGrafx event is emitted as the until-spec.
This will almost certainly need post-editing to make it meaningful to your BPEL engine.
If the process has message exceptions, corresponding <onMessage> elements are
generated. For the other two types of exceptions, Expression and Cancel, system messages
are assumed to be sent to the process when these conditions are encountered. It is not likely

that these will be used often in processes intended for BPEL. If they are used,
<onMessage> is generated for them, specifying default names for the system messages.
In all cases of <onAlarm> or <onMessage> handlers, a <throw> of the internal fault
is generated for the activity.
The intent of the structure opened for handling exceptions in this step is to allow an activity
that is terminated prematurely to activate the single sequence out of the activity that is
associated with the exception. These sequences, as well as the conditional and unconditional
sequences, are generated after the activity scope or sequence is closed in step 13.
Step 3: Open the <while> specified by the Repeat specification on the activity
You can specify that the activity repeats on the Step tab of the Properties dialog box Task
page. It is usually used in conjunction with a subprocess. A repeat can be ended on the
condition of an expression, a count, or both. The condition can be specified as tested before
or after the execution of the activity.
The BPEL <while> uses a pre-test, so the condition for the <while> is potentially made
up of the AND of three parts:
1 If there is an expression, it is one part.
2 If there is a count, a counter is generated for the loop and it is tested against the limit as
the second part.
3 If the test is After, then a boolean _firstRepeat is created, assigned to true prior to the
<while>, assigned to false inside the <while>, and is tested as the third part of the
condition.
Step 4: Generate <copy> activities for assignments

At each step in the activity where an assignment occurs, an <assign> activity is opened if
one is not already open. For each assignment, the attribute and expression are mapped (see
Process Expressions and BPEL on page 14) and a <copy> is generated.
Any step of the activity that generates any other element than <copy> closes any open
<assign>. The result is that all the assignment steps may be in a single <assign> if no
intervening BPEL-relevant model data exists.

Step 5: Generate input <receive> or <wait>
If the activity specifies a message or event on the Input page of the Properties dialog box,
the corresponding <receive> for the message, or <wait until=...> for the event is
generated. If the activity has no inputs, it is marked as createInstance=true. It is not
possible with iGrafx to generate createInstance=true for an activity that has input flow.
For the other supported input constraints, system messages are assumed and the
corresponding <onMessage> with default names and partners is generated.
As a special case, an activity that is marked as a process start point and has no inputs is
defined as a <receive createInstance=true>, using a default Message.

See step 4 on page 59.
Step 7: Generate <wait>

If the activity is specified on the Step tab of the Task page to be of type Delay, the
corresponding <wait for=...> is generated. Note that there is not a corresponding
<invoke> generated for type Work. In this case, it is assumed the message is made explicit
on the On Completion tab, and that the Work specification is part of the model of the
behavior of that <invoke>.
Step 8: Generate subprocess <invoke> or open <scope>

If the activity is specified on the Step tab of the Task page to be of type Process, it is further
specified to be of type Subprocess, Concurrent Process, Private Subprocess, or Embedded.
Subprocess (and Private Subprocess, a slight variation that is only significant to simulation)
and Embedded are immediately generated within a <scope>. Concurrent Process is
generated as an <invoke> of a message, defined by a name using the start point name
specified and the partner name of the start shape.
A subprocess, private subprocess, or embedded process is expanded into <scope> elements
in the file; in other words, its entire hierarchy is traversed and exported as BPEL.

Subprocesses that are independent web services should be defined as Concurrent Process
types. A concurrent process must be exported separately; BPEL Export only exports one
process hierarchy at a time.

Step 10: Generate <invoke>, <reply>, <throw> or <terminate> for On Completion

The On Completion tab of the Task page can specify behavior that is not related to BPEL,
as described in section Generating Tasks on page 31. However, if Message, Fault, Cancel or
Discard are chosen, the corresponding BPEL is generated. Currently, iGrafx does not allow
specifying an activity as the target of a Compensate, so BPEL Export generates a warning.
For Fault and Discard specifications, an expression can conditionally throw the Fault or
Discard. If it is specified, the <throw> or <terminate> is wrapped with a <switch>.
For the Cancel specification, a system-defined message is assumed and is sent to an assumed
system partner using <invoke>.
Note
Discard includes an option to Discard Transaction, which means the single family member
(thread) that is at the activity. Discard Family Member means to terminate all family
members other than this one. If either check box is clear, a warning is generated and BPEL
is generated assuming both are selected.

Step 12: Close the <while> opened in step 3

The closing </while> is generated if it was opened in step 3.
Step 13: Close any structure opened in step 1

If structure was opened in step 1, either an exception flow or more than one output and at
least one non-exclusive output exists. If there is a single output, the output sequence is the

same sequence the activity is in. In the special case of all exclusive outputs (known as a
Decision in iGrafx), a single <switch> structure can appear in the same sequence as the
activity. For all other multiple output cases, a <flow> must be established, here referred to
as the normal output, and a new sequence is created within that flow for each of the
unconditional and non-exclusive conditional outputs. Additionally, one sequence is created
within the normal <flow> for the <switch> that contains all the exclusive outputs.
Finally, if exceptions exist, one sequence is created for each exception output. These outputs,
along with the normal <flow> output, are nested within the <flow> created in step 2.
Note
Exception outputs are exclusive of all other outputs by definition, but in the paragraph above,
“exclusive” refers to normal outputs only.
An activity completes either normally or exceptionally. If it completes normally, and there

are exception outputs as well, a special <link> is sourced by the activity <sequence>
whose target is the normal output <flow>, <switch> or <sequence>. The exception
outputs are each the target of their own <link>, which was sourced in step 2 by the
<catch> for the corresponding exception.

BPEL Export Flow Appendix D
BPEL Export generates sequences and splits during this phase. Sequences are lists of
connected activities and splits are activities that have more than one output.
The following is an overview of the algorithm for analyzing the flow, which is intended to
provide a better understanding of the BPEL generated from a particular diagram.
Note
The terms introduced here are used to describe the algorithm and are not meant to suggest
standard terminology.
Step 1: Locate the start points

BPEL Export is run on a diagram that is the root of a process hierarchy. Each BPEL export
generates a single BPEL process. The BPEL Export dialog box displays the Partners
available for export in the current diagram. There is always one messaging partner for
Process diagrams–the name of the diagram itself. There may be more than one for BPMN
diagrams that have more than one BPMN pool and where more than one pool contains a
valid start point.
For BPEL Export, a start point is defined to be any activity with no shape incoming
connections, and that has a Message, Expression or Event input constraint. It also includes
activities with no inputs that are marked as start points on the Inputs page of the
Properties dialog box.
Step 2: Scan the connectivity to produce sequences and splits that it represents
For each start point, a sequence is started and the start activity put in the list. BPEL Export
then follows the output of one activity to the next and adds it to the sequence if the
following activity has zero or one output. If it has more than one output, a split is created
BPEL Export Flow 63

and added to the sequence. Then one new sequence is started for each output, and each of
those sequences is extended.
When a sequence arrives at an activity, it will only be processed if all input sequences have
arrived. When all input sequences have arrived, the creating split of each of the inputs is
notified to merge the sequences. If all the sequences from a given split have been closed, the
incoming sequence for that split can be propagated forward. In this way, the sequences tend
to be maximal length/minimum hierarchical depth. The splits appear in the generated
BPEL as <flow> elements, and the merging sequences as <link> elements. Of course,
the sequences themselves become <sequence> elements.
Sequence 1 contains A1, A2, A3 (which is a <flow> containing Sequence 2 and 3), A6 and A7.
Sequence 2 contains A4 and Sequence 3 contains A5.
An activity may be a subprocess activity that is to be expanded as a <scope>, and it may

have a compensation sequence associated with it. If so they are noted, and the associated
sequences are processed later in separate passes.
Loops
In a diagram with feedback loops, the above algorithm will not traverse the complete flow.
It is blocked at activities that have inputs that feed back, because those sequences will never
arrive. To avoid this problem, when all currently processing sequences have ended, BPEL
Export force-propagates the remaining pending activities until all have been propagated. A
pending activity is one at which at least one but not all inputs have arrived.
Not all pending activities turn into loops; depending on flow, they may be normal activities
that have inputs blocked by loops elsewhere. Sequences that feed back to pending activities

are noted, and are used later to define the activity as a loop activity and create the <while>
element that it implies for BPEL.
A valid loop structure for BPEL. Note that A1 will not get propagated in the first pass because the two
feedback inputs will not arrive until after A1 is force propagated.
Some loop flows violate BPEL rules. In many cases, these are detected in BPEL Export and
an error is generated. In some cases, such a problem is not revealed until deployment time.
This loop structure is not generated into BPEL. The intersecting loops imply overlapping <while> or a
<link> into <while> from outside the <while>.
BPEL Export Flow 65

This loop structure is not generated into BPEL. It is another intersecting loop, this time in the feedback
path.
Another invalid loop structure. A3 has a non-exclusive branch outside the loop, which is prohibited by the
BPEL specification. It would create a <link> across the scope of a <while>.
Subprocess Loops
Since a subprocess activity refers to another process, which may have a subprocess activity in
it that refers back to the original process, subprocess loops can be created. This is
uncommon, but BPEL Export does not attempt to mimic this behavior in BPEL and
generates an error. Note, however, that if the sequence from the start point in the original

process is disjoint from a second start point that is referenced from the subprocess, this is not
considered an error and is generated normally.
A process named Subprocess is invoked by the top sequence. Subprocess invokes the Subprocess Start point in
this process. This is valid, and not considered a subprocess loop. Note that this process could not be the
main process because BPEL Export would consider both start points part of the main process.
BPEL Export Flow 67

iGrafx API Support for BPEL Export Appendix E
The iGrafx API includes an API object, the ProcessDocument, that can be retrieved by
calling the Document.AsType(“iGrafx.ProcessDocument”) method. It defines the following
methods that are useful in BPEL Export.
GetMessagingXML and DefineMessaging methods are used to retrieve or establish the
messaging model defined for the document. These are provided in place of a set of API
objects, and allow manipulating the data as XML directly rather than through the API. The
first takes two parameters, an XML file URL, string or document
(MSXML3.DOMDocument) and a boolean to determine if the current model should be
merged or replaced. The second returns an XML string that contains the current messaging
model.
A schema is available at:
http://www.igrafx.com/schemas/2005/igrafx-messaging
ExportBPEL method allows you to export from the API without using the BPEL Export
dialog box.
• The first parameter is a PartnerName for a partner defined in the document. For
information on how these names are defined, see Setting Up Messaging Partners on page
28.
• The second parameter is a directory that will contain the output file.
• If non-empty, the third parameter is the filename in that directory that will contain
the default mapping file. Providing this name is equivalent to selecting the Default
Map File check box in the BPEL Export dialog box.
• The final parameter is reserved for future use.
An invocation might look like the following:
ActiveDocument.AsType ("iGrafx.ProcessDocument").ExportBPEL
"Book_Dealer",ActiveDocument.Path, "1.1"
iGrafx API Support for BPEL Export 69

CreateDefaultMessageMap and DefineMessagingFromWSDL are APIs that perform
different functions. One loads WSDL and generates a mapping file from it, and the other
loads WSDL and generates an iGrafx messaging model from it. Both APIs take a WSDL
URL, filename, string or document (MSXML3.DOMDocument) and a boolean that
determines the form of the Messages generated from it. Consider an operation oper in
portType pt. If the QualifyOperationWithPorttype boolean is true, it creates a message in
iGrafx named “pt_oper”. If false, the name for the message is the same as the name for the
operation, “oper”. The third parameter for the first method is a filename to contain the
exported map. The third parameter on the other is whether to replace or merge with the
existing messaging model in the document.
Importing WSDL into iGrafx

WSDL is imported into iGrafx using either of the API methods mentioned above, using the
<import> element in the mapping file, or using the Define Messaging From WSDL
command on the Tools menu. Importing WSDL does the following, if the associated
elements appear in input:
1 Defines WSDL Message names and Partner names.
2 Defines portType names, associates operations with those portTypes, and associates
input and output messages with the operations.
3 Defines partnerLinkType names, their role names, and portTypes.
4 Creates a Partner for any <service> element.
5 Creates a Message for every operation in every portType.
6 Creates an Attribute for input and/or output of each Message.
7 Creates a Fault for every WSDL fault. The name of this Fault is formed as a
combination of the Message name from the associated operation and the name of the
WSDL fault.
Note
The Partner, Message, Attribute and Fault definitions are only defined in the process model
itself if you use DefineMessagingFromWSDL. For the other cases, the names defined in
steps 4 through 6 are matched, if possible, to those already existing in the model. If
definitions conflict, the one from WSDL takes precedence for purposes of export.
Usually, if you use DefineMessagingFromWSDL to load WSDL, you will also want to use
CreateDefaultMessageMap from the same WSDL to initialize a mapping file that you can
use during BPEL export.

Limitations of BPEL Implementation Appendix F
The current release has certain limitations with regard to BPEL Export that will be
addressed in future releases.
• Correlation sets are not supported. If your engine and process require it, correlation
sets must be added to the BPEL manually.
• Attributes, which map to BPEL <variable>, are limited to floating point data types.
For other data types, you must use the mapping file.
• Expressions in iGrafx are in a proprietary language. In many cases, it is successfully
converted to a simple XPATH expression, but not in all. iGrafx allows you to enter
anything you want into an expression field and provides a warning message if it is not
a valid iGrafx expression. The contents of these expressions are passed into the output
BPEL, but are not allowed in simulation.
• You can specify compensation handlers, but you cannot create a <compensate>
activity to trigger them. If your process needs this feature of BPEL, the
<compensate> activities must be added manually. You can create placeholder
activities at the correct places in the flow.
• In more complex flows, detecting invalid looping constructs is problematic. If your
process uses complex looping structures, you may factor them into a Repeat
subprocess to ensure valid BPEL.
• BPEL code does not necessarily insert all the engine-specific tags required. Since
engine vendors routinely extend BPEL with non-standard tags, you must manually
Limitations of BPEL Implementation 71

add any extension your process or engine needs. You may be able to avoid this
problem by using a standard BPEL engine such as FiveSight PXE.
• Support for <pick>, more robust expression capability, <correlation>,
<compensate> and <transitionCondition> may be included in a future release.
• iGrafx only supports BPEL4WS version 1.1.
• iGrafx has no plans at this time for importing BPEL and creating a diagram from it.
• iGrafx has no provision for specific extensions to BPEL. Many of these use data that is
captured in iGrafx, and iGrafx offers a separate XML output that can be merged with
the BPEL code using XSLT or other technique.
• The current release of iGrafx does not check that if a message flow exists, it targets a
partner that is mentioned in the messages received or sent by the activity.

BPEL Standards Appendix G
BPEL Export in the current release supports the original BPEL4WS 1.1 spec.
The BPEL for Web Services Specification

The Business Process Execution Language for Web Services specification version 1.1 is used
as a reference for many of the discussions in this publication and is available from these
locations:
http://dev2dev.bea.com/technologies/webservices/BPEL4WS.jsp
http://www-128.ibm.com/developerworks/library/specification/ws-bpel/
http://en.wikipedia.org/wiki/BPEL
BPEL Standards 73
Glossary of Terms Appendix H
The following terms are introduced throughout this publication.
attribute When used in lowercase, this refers to an attribute of an XML

element in the output BPEL or WSDL files.
Attribute When used in uppercase, this refers to a data value that is associated
with a particular transaction (process instance). Attributes are
similar to BPEL variables, and are mapped to them. In iGrafx, you
define Attributes in the Define Attributes dialog.box.
BPEL engine A program that reads BPEL process definitions, WSDL, and other
inputs, and creates executable BPEL representations of processes
that invoke web services.
binding Specifies what method to use to communicate with a portType. A
common method is SOAP.
default partner The assumed source or target of a Message for which the Partner is
unspecified.
deploy, The process of defining the external environment in which a BPEL
deployment program runs, and converting the BPEL text file into an executable
process on a BPEL engine.
Glossary of Terms 75
element The XML element. Elements mentioned in this document include:
<targetNamespace>, <BPELOutputVersion>, <wait>,
<onAlarm>, <while>, <service>, <WSDLMessages>,
<WSDLMessage>, <part>, <portType>, <portTypes>,
<partnerLink>, <partnerLinks>, <partnerLinkType>,
<DocFaults>, <throw>, <catch>, <HasValue>,
<ValueType>, <DocMessage>, <input>, <output>,
<DataSent>, <DataReply>, <Value>, <portTypeOperation>,
<DocServices>, <Variables>, <Variable>,
<compensationHandler>, <faultHandlers>, <onMessage>,
<copy>, <assign>, <scope>, <flow>, <link>, and
<sequence>.
fault An exceptional event that occurs in a process or its environment that
will cause termination of the transaction (process instance) unless it
is handled explicitly. WSDL also uses the term fault for the element
that describes an exceptional response to an operation.
Fault When capitalized, this refers to an element of the iGrafx interface
that can map to WSDL fault. Also may map to a system-defined
fault or one of the BPEL built-in faults.
implicit partner A Partner that is not defined in the model, but that must exist to
create valid BPEL output. The default partner is most common.
BPEL Export also infers an implicit partner (the “system” partner)
from BPMN Rule or Timer events that start the process.
mapping file A file that resolves conflicting terminology used in iGrafx and
WSDL by converting the iGrafx Partners, Messages, Faults, and
Attributes to the correct terminology needed to execute the web
services. It also can map a single iGrafx object to multiple WSDL
objects in different services.
message WSDL uses this term to refer to the structure of the data that is sent
with an operation. Conventional usage is that it represents the data
itself, along with the intentions of the sender. WSDL uses the term
“operation” for this concept. PurchaseOrderForm might be a WSDL
message, representing a blank form, and SendPurchaseOrder the
operation that takes as input specific data values structured as a
PurchaseOrderForm, representing a filled out order.

Message The iGrafx object that represents the conventional meaning of the
term “message” (see message definition above). It contains data to
send, instructions about what to do with it, and optionally an
expected response. The iGrafx Message is mapped to WSDL
portType, operation, input and output elements.
messaging partner A web service partner that accomplishes tasks for a BPEL process.
Messaging partners can be customers, suppliers, partners, or any
entity that performs a service that can be defined by a WSDL.
namespaces An XML mechanism that removes ambiguity when two XML
sources use the same terminology for different objects.
normal output The <flow> established for multiple outputs from an activity.
partner See messaging partner definition above.
Partner An iGrafx object that represents a service provider, customer,
supplier, etc. that a process will depend upon. Note that a Partner
may map to more than one BPEL partner/WSDL portType.
partnerLink A BPEL element that is an instance of a partnerLinkType and
identifies which of the roles of the partnerLinkType is taken by the
process or by the web service.
partnerLinkType A BPEL-defined element in a WSDL definition element that defines
the roles played by the client and the service in a message exchange.
portType A collection of related WSDL operations. For instance, the
PurchaseOrderPort might be a portType that contains
SubmitPurchaseOrder, InquireAboutStatus, and OrderModification
operations.
process diagram A diagram that models a process for simulation, analysis, or BPEL
implementation.
Process diagram A diagram created and maintained by the iGrafx Process product.
receive A process (web service) takes action for and may reply to messages it
receives. Also, the BPEL element that defines an activity that waits
to receive a message. Also, when used to modify the term data
(“received data”), it is used from the perspective of the client of the
message.
Glossary of Terms 77
send A process may send messages to other partners (web services)
requesting an action and may receive a reply. The BPEL element
invoke defines an activity that sends a message. Also, when used to
modify the term data (“sent data”), it is used from the perspective of
the client of the message.
service An external entity that is willing or is contracted to carry out actions
requested by a client, and may return data to the client as a result.
Also, the WSDL element name that defines a web service.
SOAP Simple Object Access Protocol (SOAP) defines the XML-based
information that can be used “for exchanging structured and typed
information between peers in a decentralized, distributed
environment.” For more information, see www.w3.org.
system partner BPMN and iGrafx define events that BPEL does not support that
can trigger actions in the process, including the expression (BPMN
Rule) event and Timer start event. Often, these features are provided
by BPEL engines, so BPEL Export creates a placeholder message for
these events, and assumes a “system partner” to send them. See also
implicit partner.
task The work done at an activity.
web service A service whose interface can be described with WSDL. It is
commonly invoked via the worldwide web, but not all web services
involve the worldwide web.
WSDL, WSDL file Web Service Definition Language (WSDL) defines the interface to a
web service, and is accessible from a web URL or a file. WSDL
defines what a web service can do, and how to use it. For more
information, see www.w3.org.

Index
Symbols B
.bpel file 10, 26 binding 75

.igx file 10 BPEL 30
.wsdl file 10, 26 <invoke> object 9
.xml file 10 <onMessage> object 9
.xml files 26 <receive> object 9
<assign> 9 <reply> object 9
<import> element 70 and iGrafx 5
<link> 24 and process expressions 14
<terminate> 9 benefits 5
<wait> 9 creators 4
<while> 24 export requirements 12
exporting a diagram to 33
from iGrafx diagram 24
implementation elements 7
A
overview 4
time-spec 26
activity 8 triggers 13
parallelism 9 BPEL activities
pending 64 multiple from one activity 31
sequencing 9 BPEL activity
synchronization 9 identifying the origin of 32
work done at 8 steps for generating 31
ambiguity in WSDL 17 BPEL advantages 5
API BPEL default version 30
to load WSDL and generate a mapping file BPEL engine 14, 75
70 compatibility with simulation model 25
to load WSDL and generate a messaging example 48
model 70 BPEL Export 5, 7
API functions 20 about 24
API support 69 advantages 5
Attribute 75 and mapping file definitions 21
attribute 75 and namespaces 17
creating in iGrafx 23 API support 69
in iGrafx interface 23 architecture 11
attributes 42 file types used by 10
attributes mapping 56 flow 63
flow analysis 33
limitations 71

using to export from a diagram 33 deploy 75
BPEL export and mapping files example 49 deployment 75
BPEL Export features 6
BPEL flow behavior 9
BPEL for web services specification 73
E
BPEL implementation advantages 5
BPEL implementation files 26
BPEL namespace 18 element 76
BPEL overview 3 engine
BPEL standards 73 BPEL 14
BPEL4WS 4, 10 establish messaging model 69
BPEL4WS specification 73 example
BPMN BPEL code using mapping file 52
message flow lines 29 BPEL code with no mapping file 50
BPMN diagram BPEL engine 48
procedures for creating example 39 BPEL export and mapping files 49
BPMN diagram example 36 BPEL implementation 35
BPMN Guide 13, 27 BPMN diagram in 35
BPMN page 27 BPMN diagram procedures 39
BPMN pools 28, 39 define attributes 42
define gateway behavior 45
Define Messages and Properties dialog boxes
50
C Define Messages dialog box 38
define pools 39
close any opened structure 61 draw connection lines 41
close the <while> 61 draw message lines 46
connection lines 41 iGrafx interface 37
CreateDefaultMessageMap 70 invalid loop 65, 66
mapping file 47
mapping messages 48
Properties and Define Messages dialog boxes
D
50
Properties dialog box 38
data task execution goal 35
from model not meaningful to BPEL 32 vendor WSDL 51
default partner 29, 75 WSDL file 47
define attributes 42 ExportBPEL invocation 69
Define Messages dialog box 38 ExportBPEL method 69
how to invoke 38 ExportBPEL method parameters 69
define pools 39 exporting a diagram 33
DefineMessaging 69 expressions
DefineMessagingFromWSDL 70 common problems 25
delay events 14

simulating in iGrafx 25 I
expressions in iGrafx models 25
iGrafx and BPEL 5
iGrafx API 69
F for importing definitions from WSDL 30
iGrafx diagram
Fault 76 compiling into BPEL 24
fault 76 exporting to BPEL 33
creating in iGrafx 23 iGrafx diagrams 5
in iGrafx interface 23 choosing 12
Fault mappings 55 expressions in 25
faults iGrafx interface 37
defining 13 iGrafx message mapping to WSDL 21
feedback loops 64 iGrafx models 27
file naming convention 7 implicit partner 76
flow import WSDL into iGrafx 70
incomplete 64 importing WSDL 53
flow analysis 63 input synchronization 57
flow mapping 33 intersecting loops 65
flowchart topology 9
for
in BPEL time-spec 26 L
limitations of BPEL implementation 71

G loop
intersection in feedback path 66
generate <copy> activities 59, 60, 61 invalid structure 66
generate <wait> 60 non-exclusive branch outside of 66
generate input <receive> or <wait> 60 not generated into BPEL 65, 66
generate objects for On Completion 61 valid 67
generate subprocess <invoke> or open valid for BPEL 65
<scope> 60 loops 64
GetMessagingXML 69 start points and 67
glossary 75 subprocess 66
H M
hand editing manual editing

BPEL time-spec 26 exported BPEL 25
mapping attributes 56

mapping Fault 55 normal output 77
mapping file 10, 21, 76
default 11
sequence of load operations 21
O
mapping files and BPEL export example 49
mapping Message 55
mapping of iGrafx model data to 30 object ID 32
mapping Partner 56 open activities needed to support output flow 58
Message 77 open the <while> 59
message 76
creating in iGrafx 23
defining from existing WSDL 30 P
in iGrafx interface 23
recipient 14 Partner 77
WSDL and iGrafx 13 partner 3, 77
message exchanges 9 in diagrams 7
message lines 46 Partner mappings 56
Message mappings 55 partnerLink 77
messages partnerLink namespace 19
defining 13 partnerLinks 55
in a process diagram 12 partnerLinkType 77
WSDL 54 partnerLinkTypes 55
messaging partner 3, 28, 77 pending activity 64
creating in iGrafx 23 portType 77
in iGrafx interface 23 portTypes
messaging partners 14 WSDL 54
about 29 Process diagram 77
setting up 28 process diagram 77
models for simulation 14 process expressions 14, 25
process flow 9, 41
process gateways 45
N process instance 25
ProcessDocument API object 69
namespace Properties dialog box 9, 14, 32
BPEL 17
partnerLink 17
WSDL 17 R
XMLSchema 17
namespaces 17, 77 receive 77
defined by BPEL Export 19 receive data 28
externally defined and controlled 17 receive messages
WSDL import and 20 defining in iGrafx 27

retrieve messaging model 69 W
web service 9, 78
S web service partner 3
web service partners 14
schema 69 WS-BPEL 4, 10
send 78 WSD
send data 28 importing into iGrafx 70
send messages WSDL 3
defining in iGrafx 27 about 15
service 78 ambiguity and 17
shape analysis algorithm 57 Binding 15
SOAP 15, 78 execution environment 15
subprocess loops 66 generated file 17
system partner 78 import and namespaces 20
importing 53
mapping iGrafx messaging to 20
mappings in 20
T Message 15
Operation 15
targetNamespace 19, 21 portType 15
task 8, 78 Services 15
tasks where to obtain 15
generating 31 WSDL and mapping files 53
in a process diagram 12 WSDL file
template importing information from 30
iGrafx document 47 WSDL import
time-based events 14 and BPEL Export 54
time-spec 14, 26 WSDL messages 54
transaction 25 WSDL namespace 19
WSDL portTypes 54
WSDL, WSDL file 78
U
Uniform Resource Identifier (URI) 17 X

until
in BPEL time-spec 26 XMLSchema namespace 19
XPATH 25
converting iGrafx expressions into 14


IGrafx 2011 en BPEL Implementation Guide

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

IGrafx 2011 en BPEL Implementation Guide

Transféré par

Droits d'auteur :

Formats disponibles

BPEL Implementation Guide

iGrafx® 2011 BPEL Implementation Guide

Getting Started with BPEL Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

iGrafx and BPEL Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

iGrafx 2009 BPEL Implementation Guide 1

BPEL Implementation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

BPEL Export and Mapping Files Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49

Working With WSDL and Mapping Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Generating a Single Process Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

iGrafx API Support for BPEL Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Limitations of BPEL Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

2 iGrafx 2009 BPEL Implementation Guide

What BPEL Is Not

Who Uses BPEL?

4 BPEL Implementation Guide

About iGrafx and BPEL

Advantages of iGrafx BPEL Exporting and Implementation

6 BPEL Implementation Guide

Elements of BPEL Implementation

Getting Started with BPEL Implementation 7

The process diagram captures the following data related to BPEL:

Work Done at an Activity

8 iGrafx 2009 BPEL Implementation Guide

<assign> Attributes page

Activity Sequencing, Parallelism, and Synchronization

<receive> Inputs page

Getting Started with BPEL Implementation 9

10 iGrafx 2009 BPEL Implementation Guide

The iGrafx BPEL Interface

Getting Started with BPEL Implementation 11

Choose an iGrafx Process or BPMN Diagram

Tasks and Messages in a Process Diagram

12 iGrafx 2009 BPEL Implementation Guide

Getting Started with BPEL Implementation 13

Web Service (Messaging) Partners

Choose a BPEL Engine

14 iGrafx 2009 BPEL Implementation Guide

Getting Started with BPEL Implementation 15

16 iGrafx 2009 BPEL Implementation Guide

Namespaces and BPEL Export

Externally Defined and Controlled Namespaces

Getting Started with BPEL Implementation 17

18 iGrafx 2009 BPEL Implementation Guide

The partnerLink Namespace

The XMLSchema Namespace

BPEL Export-Defined Namespaces

Getting Started with BPEL Implementation 19

Map iGrafx Messaging to WSDL

20 iGrafx 2009 BPEL Implementation Guide

Getting Started with BPEL Implementation 21

messaging partner Insert Department on the Departments toolbar

iGrafx and BPEL Implementation 23

attribute Define Messages dialog box

About BPEL Export

24 iGrafx 2009 BPEL Implementation Guide

iGrafx and BPEL Implementation 25

Files Used in BPEL Implementation

26 iGrafx 2009 BPEL Implementation Guide

Define Send and Receive Messages

Inputs Wait until a message is received before starting a task or

iGrafx and BPEL Implementation 27

Setting Up Messaging Partners

28 iGrafx 2009 BPEL Implementation Guide

iGrafx and BPEL Implementation 29