1

Business Process Management
Cross-component BPM
Author: Andrea Schmieden
2
© SAP AG 2004, BPM@BSGs / Volmering / 2
Obj ec t i ves
Af t er c ompl et i ng t hi s sessi on, you w i l l be abl e t o:
Understand the basic design principles of cross-component
BPM
Define integration processes
Import/export integration processes to/from non-SAP systems
Setup exception handling
3
Note: Terminology change: the XI object business process‘ was renamed to
integration process, the XI object business scenario was renamed to integration
scenario
These terminology changes are not yet reflected in the screenshots
© SAP AG 2004, BPM@BSGs / Volmering / 3
Agenda
ccBPM Architecture
Graphical Process Editor
Process Design Basics
More Step Types
BPEL4WS Import and Export
Exception Handling
4
© SAP AG 2004, BPM@BSGs / Volmering / 4
Integration Server
Business Process Engine
c c BPM Ar c hi t ec t ur e – Over vi ew
Integration
Repository
Abstract
Interfaces
Integration
Directory
Integration Process
(Configuration)
Routing Rules
Integration Builder
Integration Process
(Definition)
(References)
M
e
s
s
a
g
e
M
e
s
s
a
g
e
2
3
1
4
Process / Message Store
Process
Execution
Correlation
Handling
Routing Mapping
Channel
Det.
Adapter Engine
P
r
o
c
e
s
s

E
d
i
t
o
r
Integration Engine
5
Repository
Scenario references a process definition
Process references Local Interface
Local Interface references Interface Types (in another SWCV)
Local Interface references Message Type
Process references Interface-Context-Object-Relation
Process references Interface mappings
Interface mapping references Message Mapping
Directory
Process in directory refers active version of Process in Repository
SWCV (Software Component Version)
An integration process can use all objects that are available in the SWCV of the
process.
© SAP AG 2004, BPM@BSGs / Volmering / 5
Directory
Scenario
Scenario
Party
Repository
SWCV
Ar c hi t ec t ur e – Def i ni t i on
Cache/Runtime
Process
Process
Flow
If
* *
Interf. Mappings
Interf. Mappings
Abstract Interfaces
Abstract Interfaces
Context Objects
Context Objects
Message Type
Message Type
XML-objects
XML-objects
Correlations
Correlations
Integration Scenario
Integration Scenario
*
*
Routing Relation
Routing Relation
Process
Process
Flow
If
* *
Integration Process
Integration Process
Flow
If
* *
Mapping Relation
Mapping Relation
Process
Process
Process
Process
Message Mappings
Message Mappings
IDOC
IDOC
RFC
RFC
6
© SAP AG 2004, BPM@BSGs / Volmering / 6
Agenda
ccBPM Architecture
Graphical Process Editor
Process Design Basics
More Step Types
BPEL4WS Import and Export
Exception Handling
7
Header Area
Displays name, namespace, software component version, status of the integration process
(automatically generated), description can be entered
Edit Area
Graphical Process Definition: Defining steps of the Integration process
Correlation Editor: Defining correlations
BPEL4WS View: Viewing BPEL4WS description of the process definition, exporting/importing process
definition to/from BPEL4WS, automatic refresh after modifications in outline view etc. possible (see
Personal Settings)
Overview Area
Process Outline: tree view of the process definition, steps can be inserted and modified
Process Overview: overview of the process definition, focus can be changed
Properties Area: Defining the properties of the selected step
Object Area
Container: Defining container elements (variable declaration)
Process Signature: shows which abstract interfaces a business process uses as inbound or
outbound interfaces. If you want to integrate a business process in a business scenario, you
must create appropriate actions for the inbound or outbound interfaces.
Output Area
Tasks: Results of checks
Processing Log: error, warning and info messages
Search results: Results of searching for steps
WSDL view: available only if Edit Area displays BPEL4WS view
© SAP AG 2004, BPM@BSGs / Volmering / 7
Pr oc ess Desi gn w i t h t he Gr aphi c al Pr oc ess Edi t or
Output Area Object Area
Header
Overview
Area
Edit Area
Properties
Area
8
To increase the visible part of the process definition:
Click the Detach Icon and then maximize the window
To increase the default space for the Properties area:
Click the Personal Settings Icon and on the Process Editor page choose Hide Output Area
To increase the default space for the Object area (Container elements):
Click the Personal Settings Icon and on the Process Editor page choose Hide Output Area
© SAP AG 2004, BPM@BSGs / Volmering / 8
Pr oc ess Edi t or Set t i ngs
Personal Settings
•Default Editor
•Horizontal/Vertical Display of Process Definition
•Hide Output Area
•Error Level for Processing Log
•Automatic refresh for BPEL4WS
Detach, then
maximize window
9
© SAP AG 2004, BPM@BSGs / Volmering / 9
Agenda
ccBPM Architecture
Graphical Process Editor
Process Design Basics
More Step Types
BPEL4WS Import and Export
Exception Handling
10
Receive: Receive message (can trigger process) / Modus Open S/A-Bridge
Send: Send message synchronously or asynchronously / Send acknowledgement / Mode Close
S/A-Bridge
Transformation: Split, merge or convert messages
Receiver Determination: Get a list of receivers for subsequent send steps
Block
Block hierarchy is basis for visibility of container elements (local variables)
Deadline can be defined for block
Exception handling – multiple exception handlers (branches) possible
Dynamic modes: dynamic parallel (ParForEach), dynamic sequential (ForEach)
Loop (While): Repeat steps while a condition is TRUE
Fork: Define independent processing branches
Switch: Define processing branches based on conditions
Control: Terminate process / Trigger exception /Trigger alert
Container Operation: Assign value to element / Append value to multiline element
Wait: Incorporate delay – usually used to set start time for next step
Undefined: No function – can be used as place holder or for test purposes
© SAP AG 2004, BPM@BSGs / Volmering / 10
c c BPM - Pr oc ess St ep Types
Receiver Determination
Receive
Transformation
Pr oc ess Fl ow Cont r ol Rel evant :
Send
Container Operation
Messagi ng Rel evant :
Control
Loop
Undefined
Fork
Switch
Wait
Block
11
© SAP AG 2004, BPM@BSGs / Volmering / 11
Bl oc k -or i ent ed Desi gn
Nested blocks
Deadline
branch
Exception branch
In a block-oriented modeling paradigm, every split structure has a corresponding
join structure thus facilitating properly closed structures. This paradigm relates to
well-known structured programming concepts. It also provides effective means for
restricting structural modeling errors (e.g. deadlocks) in the process models and
allows hierarchical abstraction. Block orientation guides the user and makes sure
that only valid processes can be created.
You can define blocks in a sequence or nest them within one another. However, a
block cannot extend beyond any existing block boundaries. The outermost block
of a process is always the process itself.
The block hierarchy is the basis for the visibility/scope of container elements (local
variables).
Nested
blocks
12
Simple XSD types: for process control elements like counters
Abstract Interface: For messages, which are defined by using the corresponding
asynchronous abstract interface and which are used in receive or send steps, for
example.
Receiver: For a receiver list, which is determined from a receiver determination
step, and which can be used in a send step.
Multiline: For example, if you want to collect messages in a container element, you
must define this element as a multiline container element.
© SAP AG 2004, BPM@BSGs / Volmering / 12
Cont ai ner – Pr oc ess Dat a
Container
Defines the data for a business process and to enable data to be
transferred between the individual steps of the business process
Consists of an unlimited number of container elements
Carries the overall state of the process at runtime – references to
messages, loop counters, …
Allows to access data by a name relevant within the process
Container Element (Variable Declaration)
Consists of a name to address data in the process
Can be typed to
Simple XSD (XML Schema Definition) types: XSD:date, XSD:time,
XSD:integer, XSD:string
Abstract Interface
Receiver
Can be Multiline (a vector of the types above)
13
For each block, you can define container elements.
Elements of a super container are visible in sub containers.
Elements of a subordinate container are not visible in super containers.
Container elements defined in the process container are visible in all blocks.
To define a container element in a block container, select the container in the
editing area and then define the container element in the object area.
To define a container element in the process container, make sure that no block is
selected in the editing area and then define the container element in the object
area.
© SAP AG 2004, BPM@BSGs / Volmering / 13
Pr oc ess Cont ai ner and Loc al Cont ai ner s
Container elements of inner
block SendParallel are not
visible in outer block
In inner block
CheckResult, container
elements of outer block
SendParallel and
Process container are
visible
14
You use a correlation to assign messages that belong together to the same
process instance. A correlation joins messages that have the same value for one
or more XML elements. A correlation is therefore a loose coupling of messages. At
design time, a correlation enables you to define which message a receive step
must wait for, without knowing the message ID.
For example, in a process, receivestep_1 receives the message purchase order,
while receivestep_2 receives the message sales order. Receivestep_1 creates a
correlation that defines that the corresponding sales order must have the same
purchase order number. Receivestep_2 uses this correlation. This means that an
instance of the process processes a purchase order and the corresponding sales
order, which has the same purchase order number.
© SAP AG 2004, BPM@BSGs / Volmering / 14
Cor r el at i on Def i ni t i on
Used to assign messages that belong together to the same
process instance.
Joins messages that have the same value for one or more XML elements
A loose coupling of messages
Example
Step 1 receives a message of purchase order
Step 2 receives a message of sales order
Step 1 creates a correlation so that sales order in Step 2 contains the
same purchase order number, then these two messages can be
processed in the same process
15
You can activate a correlation from either a receive step or a send step.
A correlation is normally valid within the whole process and can be activated and
used for the whole process. However, you can also define a correlation as a local
correlation by assigning it to a particular block. You can only activate and use a
local correlation in the block that it is assigned to.
© SAP AG 2004, BPM@BSGs / Volmering / 15
Cor r el at i on Ex ampl e
Enter name of correlation
for its details
Define elements to
be used to correlate
the messages
Specify messages that
satisfy the correlation at
runtime
Specify which element is to fill
the corresponding element in
the correlation container (use
context objects or XPath)
16
Receive Step to Start a Process
Can be the first step of the process or first step of a fork, a block or a loop. In the case of the latter,
the fork, block, or loop must be the first step in the process.
If the process contains further receive steps you can correlate their messages with the message
from the first receive step. To do so, specify the correlations you want to activate.
For each correlation you must specify how you want the elements of the correlation container to be
filled when the correlation is activated. You can use the whole process container for this purpose. If
you specify multiple correlations, then the message to be received must satisfy all correlations.
Assigning Messages to Receive Steps
A receive step waits for a message as soon as the process has reached the receive step and the
relevant correlation has been activated. If a message arrives for which there is no waiting receive
step, then the message is received by the process and stored temporarily. As soon as the relevant
receive step is activated, the system automatically assigns it the message that was received first
for the relevant message interface, which satisfies the correlation used in the receive step. A
message is only ever assigned to one receive step, even if multiple receive steps are waiting for a
message from the same message interface. In the following cases, multiple receive steps can wait
for a message from the same message interface:
Receive steps arranged one after the other: The first message that arrives is assigned to the first receive
step, the second message is assigned to the second receive step, and so on. Therefore, the first
message is not assigned to all receive steps that are waiting for a message from this message interface.
Receive step in a loop: If the process has not reached the receive step by the time that the message
arrives, the process receives the message and places it in a queue. As soon as the process reaches the
receive step and the relevant correlation is active, the system assigns the receive step the oldest
message from the queue. If the process reaches the receive step but the queue is empty, then the
process waits until a new message arrives.
Multiple receive steps in a fork: If multiple receive steps in forks are waiting for messages from the same
message interface, then an inbound message is only assigned to one receive step (at random). The
remaining receive steps must continue to wait.
© SAP AG 2004, BPM@BSGs / Volmering / 16
Rec ei ve St ep – St ar t i ng a Pr oc ess
Several start messages:
Receive steps in a Fork
Each Receive activates / uses correlation
Example on left:
Receive step is the 1st step
A message to be received
Indicator Start Process
Mode Asynchronous
Can activate correlations
17
You can only define one sync/async bridge per integration process. This comprises the following steps (for
details see the Process Patterns chapter):
Synchronous Receive (Opening Receive): Receives the Request message from the synchronous business system
and opens the sync/async bridge. The receive step must be the first step in the integration process. In the receive
step you specify the synchronous interface receiving the message from the synchronous business system. The
integration process is started when the message is received. The message type of the message to be received and
the request message from the synchronous interface must be identical.
Asynchronous Send: Sends the received Request message asynchronously to the asynchronous business system.
Asynchronous Receive: Receives the Response message from the asynchronous business system.
Synchronous Send: Sends the Response message from the asynchronous business system synchronously to the
synchronous business system and closes the sync/async bridge. The message type of the message to be sent must
correspond to that of the reply message from the synchronous interface in the opening receive step. In the send step,
enter the name of the receive step that opened the sync/async bridge (in this example SyncReceive).
Opening Receive step:
You can only use one receive step to open a sync/async bridge for each integration process. The receive step to
open an s/a bridge must start the integration process. There must be no other receive steps to start the integration
process.
You can insert the receive step for opening a sync/async bridge in the following positions in an integration process:
Directly after the start marker
As the first step in a block if the block is the first step of the integration process and has the mode Standard
As the first step in a fork. If the fork already contains some starting receive steps, the Start Process indicator is automatically
reset for these steps.
In the object area, define the container element that receives the synchronously sent message:
You must specify an asynchronous, abstract interface in the container element. The message must correspond to the request
message of the synchronous interface used to receive the message.
Choose this container element for the property Message.
Set the Start Process indicator.
Choose Opens S/A Bridge for the property Mode.
Choose the synchronous interface to be used to receive the message.
© SAP AG 2004, BPM@BSGs / Volmering / 17
Rec ei ve St ep – Sync /Async -Br i dge
Communication between a synchronous and an asynchronous business
system:
18
Asynchronous mode (default): the send step does not wait for a reply message from the receiver
after it has sent the message. However, you can specify that the asynchronous send step must wait
for a confirmation of receipt from the receiver, in the form of an acknowledgment. Prerequisite: The
receiver (adapter, business system and so on) sends the corresponding acknowledgment.
None (default): The Send Step is complete when the message has been successfully sent to the pipeline.
Transport Acknowledgement: The Send Step waits for the transport acknowledgment. This specifies that
the message was received successfully.
Application Acknowledgement: The Send Step waits for an application acknowledgment. This specifies
that the message was processed successfully by the receiver application (for example, ‘posted’).
Receiver Determination
The message receiver can be a business system or another integration process. You have various
options for the receiver determination:
Send Context (default): The send context is a freely definable string, which you specify in the send step. You query the send
context in a condition in the receiver determination in the Integration Directory. You must specify the send context if you want to
send messages from the same message interfaces to different receivers in different send steps.
Receiver list: You determine the list of receivers in a preceding receiver determination step. Next, from the properties of the send
step, choose the container element that contains the receiver list. The send step itself does not call the receiver determination
that is configured in the Integration Directory; instead it uses the receiver list.
Response message in reply to a previously received message: You specify the message that the send step is to send a response
to. The receiver is determined from the message header of this message. In this case, the receiver determination that is
configured in the Integration Directory is not called.
Activating Correlations
Send step within a block with a ParForEach: In a block with a ParForEach, the elements of a multiline
container element are processed in parallel instances of the block at runtime. If a send step within the
ParForEach sends a message, and a separate message is to be received for this message for each
element of the multiline container element, then the send step can activate the corresponding correlation.
© SAP AG 2004, BPM@BSGs / Volmering / 18
Send St ep – Send Message (Async hr onous)
Acknowledgement:
•None
•Transport
•Application
Receiver
Determination:
•Send context
•Receiver List
•Response to
Message
Exception:
Enter Exception
to be triggered
when a system
error occurs
(permanent
error)
Activate
Correlation for
send step in a
ParForEach
block
19
In Synchronous mode, the send step waits for a reply message from the receiver
after it has sent the request message. In a synchronous send step you specify the
synchronous abstract interface for sending the request message and receiving the
reply message. Furthermore, you specify the container element that the request
message references and the container element in which the reply message is to
be received. The container element type for the request message must be the
same as the outbound message interface of the synchronous interface. The
container element type used to receive the reply message must be the same as
the inbound message interface of the synchronous interface.
In a synchronous send step you can define additional exceptions for application
errors, provided the corresponding fault messages are defined in the synchronous
interface. You can define an exception for each fault message. This exception is
thrown when the corresponding fault message is received.
Activating Correlations
A synchronous send step waits for a reply message to be received. On receipt of
this reply message, correlations can be activated to correlate additional
messages.
© SAP AG 2004, BPM@BSGs / Volmering / 19
Send St ep – Send Message (Sync hr onous)
20
In Acknowledgment mode, a send step can send a positive or a negative
acknowledgment for a particular message:
You usually use a positive acknowledgement in a branch that defines the normal case. A
negative acknowledgment on the other hand is usually used in an exception handler.
The system automatically determines the receiver of the acknowledgment from the header of
message, for which the acknowledgment was sent.
© SAP AG 2004, BPM@BSGs / Volmering / 20
Send St ep – Send Ac k now l edgement
Send positive
Acknowledgment –
usually used in a
branch that defines
normal processing
Send negative
Acknowledgment –
usually used in an
exception handler
(exception branch of a
block)
Receiver of the
acknowledgment
is automatically
determined from
the header of the
message
21
Closing A Sync/Async Bridge
You can use a send step to close a sync/async bridge for communication between
a synchronous and an asynchronous business system. The send step sends the
response from the asynchronous business system to the synchronous business
system.
There can only ever be one sync/async bridge in an integration process.
Therefore, there can only be one send step that closes a sync/async bridge as
well. The send step cannot be in a loop, block, or a fork.
In the send step, specify the receive step that opened the synch/async bridge.
Also specify the message to be sent to the synchronous interface. This message
must be of the same type as the response message from the synchronous
interface that you specified in the opening receive step.
For details on Sync/Async-Bridging see Process Patterns section.
© SAP AG 2004, BPM@BSGs / Volmering / 21
Send St ep – Sync /Async -Br i dge
Closing a Sync/Async-Bridge: send step sends the response from the
asynchronous business system to the synchronous business system
22
© SAP AG 2004, BPM@BSGs / Volmering / 22
Agenda
ccBPM Architecture
Graphical Process Editor
Process Design Basics
More Step Types
BPEL4WS Import and Export
Exception Handling
23
You use a transformation step to do the following:
n:1 Transformation: Bundles multiple messages into one message, for example, individual purchase
order items into one purchase order.
1:n Transformation: Splits a message into multiple messages, for example, a purchase order into the
individual purchase order items.
1:1 Transformation: Converts a message into another message, for example, a message that is defined
by interface A is converted to message that is defined by interface B.
Since no receiver information is available in the transformation step, there can be no value mapping
within the transformation step. If the messages to be transformed give values in different formats,
for example different date formats, you must first ‘normalize’ the values before the messages can
be processed in the process. To do so, define a message mappingwith a corresponding value
mapping.
Attachments for n:1 and 1:n Transformations
If the messages you want to bundle contain attachments, the system collects and appends them to the
bundled message. The source system or source systems must ensure that the attachments each have a
unique name. If they don’t, the most recently received attachment will overwrite any attachments with the
same name.
If the message you want to split contains attachments, the system replicates them and appends them to
all the messages once they have been split.
Exceptions
You can enter an exception to be triggered when a system error occurs (permanent error)
© SAP AG 2004, BPM@BSGs / Volmering / 23
Tr ansf or mat i on St ep
Displays Source and
Target Messages defined
in the interface mapping.
-
Specify the container
elements that contain the
message reference or that
the message reference is
to be written to
24
You use a receiver determination step to get a list of receivers for a subsequent
send step. The receiver determination step calls the receiver determination that
you configured in the Integration Directory and returns the receiver list.
In the receiver determination step, specify the send context and the multiline
container element for the receiver list.
The send context is an arbitrary string. You query this context in a condition in the
receiver determination in the Integration Directory. You must specify the send
context if you want to send messages from the same interface to different
receivers in different send steps.
© SAP AG 2004, BPM@BSGs / Volmering / 24
Rec ei ver Det er mi nat i on St ep – Li st of Rec ei ver s f or Send
Multiline container
element for receiver
list, Category
Receiver
Receiver
Determination step
used to get a list of
receivers
Send step uses list of
receivers
25
You use a switch to define different processing branches for a process. The
Otherwise processing branch is created automatically.
You define a condition for each processing branch. The condition is checked at
runtime. The process is continued in the branch that is first to return the value true.
If no branch returns the value true, then the process is continued in the Otherwise
branch.
The system checks the conditions in the order that they are numbered. This
corresponds to the following sequence:
Vertical layout: From top to bottom
Horizontal layout: From left to right
© SAP AG 2004, BPM@BSGs / Volmering / 25
Sw i t c h St ep – Def i ni ng Pr oc essi ng Br anc hes
Otherwise branch
(created automatically)
Executed if no other
branch returns TRUE
26
You use a container operation to set a value for a target container element at
runtime. The target container element and the assigned value must have the same
data type. Use the Expression Editor to specify the value.
Assign: Assigns a value to a single line or multi-line container element. This value
overwrites the previous value. You can use this container operation to count a
counter variable, for example.
You cannot change a message by using a container operation. To change a
message, use a transformation step.
© SAP AG 2004, BPM@BSGs / Volmering / 26
Cont ai ner Oper at i on St ep – Assi gni ng a Val ue
27
Append: Appends a value to a multiline container element. For example, you can
use this container operation to attach individual messages to multiline container
elements when collecting messages.
© SAP AG 2004, BPM@BSGs / Volmering / 27
Cont ai ner Oper at i on St ep – Appendi ng a Val ue
Multiline
Element
28
© SAP AG 2004, BPM@BSGs / Volmering / 28
Bl oc k St ep
Basic design element
Blocks can be nested
Block hierarchy defines scope/visibility of container elements (local
variables)
Also: local correlations
Modes
Default
Dynamic
Parallel For Each (ParForEach) – Dynamic parallel
For Each – Dynamic sequential
Basis for deadline monitoring and exception handling
29
Exception Handling
Situations can arise in an integration process where it is not possible to continue the integration
process normally (for example, due to a system error), or where it is not recommended to continue
normally. You can prepare for such situations when you define the integration process, by using
exceptions and exception handlers.
Exception Handler
You define the reaction to an exception, the exception handler, in a separate processing branch of
a block. In the exception handler branch, you can insert a control step triggering an alert, a control
step canceling the process or any other steps. The exception handler has read and write-to access
to all data within the block.
Processing at Runtime
If an exception is triggered at runtime, the system first searches for the relevant exception handler
in the block itself, then in the next block in the block hierarchy.
When the system finds the correct system handler, it stops all active steps in the block in which the
exception handler is defined and then continues processing in the exception handler branch. Once
the exception handler has finished processing, the process is continued after the block.
If the system fails to find an exception handler, it terminates the integration process with an error.
You can
For a block, you can define multiple exceptions. To trigger an exception, you insert a control step that throws
the corresponding exception. The process is then continued in the corresponding exception branch.
In a block you can define processing branches as exception handlers. An exception handler has read and
write access to all data within the block. You can define multiple exception handlers for each block.
To insert an exception handler branch, choose Insert ->Branch ->Exception branch from the context menu
for the block.
To assign an exception handler to an exception
© SAP AG 2004, BPM@BSGs / Volmering / 29
Bl oc k – Ex c ept i on Handl i ng
Define exception
Assign exception to
exception handler
Throws exception –
process continues in
exception branch
30
You can define the dynamic modes Parallel For Each (ParForEach) or For Each (ForEach) for a
block. This means that the block is executed for each line of a multiline container element.
In ParForEach (Dynamic parallel) mode, an instance of the block is generated for each line of the
multiline container element. All instances are processed simultaneously.
You can use the ParForEach mode when you want to send a message to multiple receivers
simultaneously, for example. To do so, you use a receiver determination step to determine a
multiline container element with the list of receivers. You thendefine that the message is sent to
these receivers in a block with the ParForEach mode.
You specify the multiline container element in the Multiline Element property. In the Current Line
field specify a container element that takes the value of the multiline container element for which
the block will run.
You can define an end condition for the dynamic mode. This is checked as soon as the block has
run through for one line of the multiline container element. The block is complete as soon as one of
the lines of the multiline container element returns true for the end condition, or all lines of the
multiline container element have been processed.
Local Correlation
Usually, a correlation is valid for the entire process. For example, if a correlation was activated for a
particular purchase order number, then this correlation cannot be used for other purchase order
numbers. However, you can restrict where a correlation is valid by assigning the correlation to a
block as a local correlation. The local correlation is then only valid within the block. It cannot be
activated or used outside the block to which it is assigned. For example, you can use a local
correlation in a ParForEach to create and use a correlation with its own unique key (GUID) for each
instance created at runtime. This then enables each block instance to process a different purchase
order number.
© SAP AG 2004, BPM@BSGs / Volmering / 30
Bl oc k St ep – Par For Eac h (Dynami c Par al l el
Pr oc essi ng)
31
In ForEach mode, the block first runs through for the first line of the multiline container element,
then for the second, and so on.
You can use the ForEach mode when you want to send a message to multiple receivers one
after the other, for example.
© SAP AG 2004, BPM@BSGs / Volmering / 31
Bl oc k St ep – For Eac h (Dynami c Sequent i al
Pr oc essi ng)
32
Trigger an exception
Choose Trigger Exception and specify the exception to be triggered. The corresponding
exception handler must be defined in the same block or a super block. The system triggers the
specified exception at runtime.
© SAP AG 2004, BPM@BSGs / Volmering / 32
Cont r ol St ep – Tr i gger Ex c ept i on
33
Trigger an Alert
Choose Trigger Alert and specify the alert message and alert category. The alert category
must be defined in Alert Management. The entered alert message will be displayed in the Alert
Inbox. In the alert message, you can use expressions.
The system triggers the alert at runtime for the user who is defined in Alert Management. The
process continues unchanged. The user who is informed by alert management must then
decide whether to intervene in the process or not.
The alert inbox can be viewed as follows
With the Universal Work List of the Enterprise Portal (as of SAP NetWeaver ’04)
Using the application into which it is integrated, such as CRM or XI Runtime Workbench
With SAPGUI by using transaction ALRTINBOX
© SAP AG 2004, BPM@BSGs / Volmering / 33
Cont r ol St ep – Tr i gger Al er t
Alert Message
will be displayed
in Alert Inbox
34
Cancel process
At runtime, with the action of “Cancel Process”, the system terminates the current process
instance, including all active steps, and sets the status for the process to logically deleted.
Can be used in exception branches, for example.
© SAP AG 2004, BPM@BSGs / Volmering / 34
Cont r ol St ep – Canc el Pr oc ess
35
You use a fork when you want to continue a process in branches that are
independent of each other, for example, to communicate with two systems that are
independent of each other. The branches of the fork join in a union operator.
You can specify the required number of branches and then define whether the
process must run through all branches, or just a particular number of branches.
Furthermore, you can define an end condition for the fork.
As soon as a branch reaches the union operator at runtime, the system checks the
following conditions in the specified order:
The process has run through the required number of branches
The specified end condition has returned true
The step is complete as soon as one of the conditions returns true.
© SAP AG 2004, BPM@BSGs / Volmering / 35
For k St ep – I ndependent Pr oc essi ng Br anc hes
36
You use a loop to repeat the execution of steps within the loop. The loop
continues to run while the end condition returns true (while loop).
To specify the end condition, use the condition editor.
© SAP AG 2004, BPM@BSGs / Volmering / 36
Loop St ep – Repeat Ex ec ut i on of St eps
37
You use a wait step to incorporate a delay in a process. Usually, you use a delay
to define when the next step in the process is to start. You can define a delay as
either a point in time or a period of time.
At runtime, the step waits until the specified point in time is reached or the
specified period of time has passed. The system then continues the process by
proceeding with the next step.
© SAP AG 2004, BPM@BSGs / Volmering / 37
Wai t St ep – Spec i f yi ng St ar t Ti me f or Nex t St ep
38
© SAP AG 2004, BPM@BSGs / Volmering / 38
Agenda
ccBPM Architecture
Graphical Process Editor
Process Design Basics
More Step Types
BPEL4WS Import and Export
Exception Handling
39
© SAP AG 2004, BPM@BSGs / Volmering / 39
St andar ds Suppor t
Support for open standards
BPEL4WS 1.1
(BPM in SAP XI 3.0)
Active participation in
standards, e.g.:
Advance BPEL4WS 1.1
together with IBM, BEA
and Microsoft
Graphical Process Editor
Supports process design
adhering to standards
Import/ export of standard
process descriptions
Cross-Component BPM
adheres to evolving future
standards via a pluggable
import/export-interface
concept .
40
Language for formal specification of business processes and business interaction
protocols (also dubbed executable resp. abstract processes)
Initiative of BEA, IBM, Microsoft, SAP, Siebel Systems
Goal:
interoperability for description & communication of business processes
based on web services
Scope:
Executable business processes (model actual behavior of a participant in a business
interaction)
Business protocols (Abstract processes, use process descriptions that specify the mutually
visible message exchange behavior of each of the parties involved in the protocol, without
revealing their internal behavior)
For more information see http://ifr.sap.com/bpel4ws
© SAP AG 2004, BPM@BSGs / Volmering / 40
BPEL4WS I nt r oduc t i on
Business Process Execution
Language for Web Services
Language for the formal
specification of business processes
and business interaction protocols
Extends Web Services interaction
model enabling it to support
business transactions:
Temporal and logical dependencies
between activities, especially Web
service interactions
Association between a message
received by the Web service and a
particular process instance
Error handling and compensation
behavior
Binary relationships between process
roles
41
ccBPMsupports process definition part of BPEL4WS
You can display the BPEL4WS representation of the process definition to be
exported in the Process Editor at any point. When exporting a process you can
display the corresponding data type definitions in the form of a WSDL description
in the output area.
You can use BPEL4WS as the exchange format for exporting an integration
process to a non-SAP system and executing it there. Conversely, you can use
BPEL4WS to import an integration process from a non-SAP system to SAP
Exchange Infrastructure and execute it there. For information about restrictions to
the BPEL4WS import and export functions, see SAP Note 709650.
BPEL4WS is not intended for importing or exporting integration processes
between Integration Repositories. For this purpose, use the Integration Repository
import function instead.
© SAP AG 2004, BPM@BSGs / Volmering / 41
How t o Use BPEL4WS i n c c BPM
BPEL4WS as exchange format for exporting and importing integration
processes to/from non-SAP systems
BPEL4WS not intended for importing or exporting integration processes
between Integration Repositories on different XI systems (use import
function instead)
WSDL
View
BPEL4WS
View
42
The export exports the integration process definition as a BPEL4WS representation. Additionally, data types,
message types, and operations referenced in the process definition are exported as a WSDL description.
The process definition displayed in the Process Editor is exported as a file. The export file is a .zip file that
contains the following files:
<name>.bpel: Definition of the integration process as displayed in the BPEL4WS view
<name>.wsdl: Referenced data types, message types, and so on
You can give the .zip file an arbitrary name. This name will also be used for the .bpel and .wsdl files as well.
The .zip file does not contain any path specifications or directories.
To create a valid BPEL4WS description when you export an integration process, besides defining the
integration process from the Integration Repository, you must also specify the partner link type and partner
link.
A partner link type describes the relationship between two services and the role that each service has. For
example, the partner link type BuyerSellerLink can define the roles Buyer and Seller. A partner link defines
the services with which an integration process interacts. Each partner link has a partner link type. Multiple
partner links can have the same partner link type, for example, a procurement process can interact with
multiple vendors but use the same partner link type for all vendors.
Since this information is configured in the Integration Directory and is not part of the integration process
definition in the Integration Repository, it cannot be exported automatically. Furthermore, a message interface
can be used in different ways in different steps. For example, an integration process receives a purchase
order request in a receive step by means of an message interface. In this case, you can define the partner link
type PurchaseOrderRequest for the message interface. The same message interface can then be used in a
send step later on in the integration process, for instance, to send a purchase response. You can then also
define the partner link type PurchaseOrderResponse for the same message interface in this example.
However, defaults are generated for the partner link type, partner link, and role during the export. Ensure that
you enter a name that is meaningful within this integration process for the partner link type at least.
© SAP AG 2004, BPM@BSGs / Volmering / 42
BPEL4WS Ex por t
43
If you import into an existing integration process it will be overwritten.
The import only imports the BPEL4WS definition of an integration process. The import expects that
the data types, message types, and message interfaces (WSDL operations) referenced in the
process definition are already available in the relevant namespace, as explained in the following
example. The data types and so on are not actually imported but are merely used to support the
import procedure.
Example: The process definition to be imported references a message Msg in the namespace
http://sap.com/xiexample. The process definition is to be imported to the software component version
MySWCV. The import expects that there is a namespace http://sap.com/xiexample in this software
component version that contains the XI message type Msg.
The import expects a .zip file that contains a .bpel file and a .wsdl file. The three files must have the
same name. The .zip file must not contain any path specifications or directories.
In Business Process Management, message-based container elements are used in the properties
of certain steps and in correlations. These correspond to variables in BPEL4WS. A container
element references a message interface that in turn references a message type. However, a BPEL
variable references a message type directly. Therefore, the message interface specification is
missing when a BPEL variable is imported.
It is advisable to create the required message interfaces in the Integration Repository before
beginning the import. You can then assign them during the import by using a wizard. If you do not
create the required message interfaces beforehand, the process definition will still be imported but
the values between the various properties will be missing.
© SAP AG 2004, BPM@BSGs / Volmering / 43
BPEL4WS I mpor t
Select .zip file
containing (.bpel
and .wsdl file)
Select Message
Interface (should be
created before starting
the import)
44
© SAP AG 2004, BPM@BSGs / Volmering / 44
Agenda
ccBPM Architecture
Graphical Process Editor
Process Design Basics
More Step Types
BPEL4WS Import and Export
Exception Handling
45
Situations can arise in an integration process where it is not possible to continue the integration
process normally (for example, due to a system error), or where it is not recommended to continue
normally. You can prepare for such situations when you define the integration process, by using
exceptions and exception handlers.
Exceptions can be triggered in the following ways:
Send step:
Asynchronous or Synchronous: can trigger an exception when a permanent system error occurs
Synchronous: You can define an exception for each fault message that is defined in the synchronous interface. This exception is
thrown when the corresponding fault message is received.
Transformation step: can trigger an exception when a permanent system error occurs
Control step: The exception is triggered when the control step is received.
In a block you can define processing branches as exception handlers. An exception handler has
read and write-to access to all data within the block. You can define multiple exception handlers for
each block. To insert an exception handler branch, call the context menu for the block.
If an exception is triggered at runtime, the system first searches for the relevant exception handler
in the block where the exception was triggered. If it does not find the correct exception handler, it
continues the search in the next surrounding block in the block hierarchy.
When the system finds the correct system handler, it stops all active steps in the block in which the
exception handler is defined and then continues processing in the exception handler branch. Once
the exception handler has finished processing, the process is continued after the block.
If the system fails to find an exception handler, it terminates the integration process with an error.
© SAP AG 2004, BPM@BSGs / Volmering / 45
Ex c ept i on Handl i ng – Ex c ept i on and Ex c ept i on Handl er
Exception can be triggered by:
Async or sync send step, transformation step: system error
Sync send step: exception for each fault message defined in the sync interface
Control step
Exception is caught by exception handler (exception branch of block)
Exception handler
defines reaction to the
exception (exception
branch of the block)
Send step triggers
exception
in case of a
permanent system
error
46
A deadline specifies the last point in time that a block can be executed. You can
define a deadline as follows:
The point in time when the step or process is generated
An arbitrary point in time that you specify as an expression
You define how you want the process to react if the deadline is exceeded in a
separate branch (deadline branch). The system checks the deadline at runtime. If
the deadline has been exceeded, the processing branch is executed for the
deadline. The steps in the remaining processing branches in the block are not
affected by this. In particular, note that these steps within a block are not
automatically completed.
In the deadline branch you can trigger an exception or an alert for Alert
Management by using a control step, for example. The branch has read and write-
to access to all data within the block.
To insert a deadline branch, call the context menu for that particular block.
© SAP AG 2004, BPM@BSGs / Volmering / 46
Deadl i ne Moni t or i ng
Control step
triggers
TimeOut
exception
Deadline branch
– executed, if
the deadline has
exceeded
Exception handler for
Timeout Exception
Deadline,
defined in the
deadline
branch
47
© SAP AG 2004, BPM@BSGs / Volmering / 47
Summar y
Now you shoul d be abl e t o:
Understand the basic design principles of cross-component
BPM
Define integration processes
Import/export integration processes to/from non-SAP systems
Setup exception handling