Date post: | 07-Jul-2018 |
Category: |
Documents |
Upload: | leandromachado |
View: | 233 times |
Download: | 1 times |
of 47
8/18/2019 ccBPM in XI
1/47
1
Business Process ManagementCross-component BPM
Author: Andrea Schmieden
8/18/2019 ccBPM in XI
2/47
2
© SAP AG 2004, BPM@BSGs / Volmering / 2
Objectives
After completing this session you will be able to:
Understand the basic design principles of cross-componentBPM
Define integration processes
Import/export integration processes to/from non-SAP systems
Setup exception handling
8/18/2019 ccBPM in XI
3/47
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
8/18/2019 ccBPM in XI
4/47
4
© SAP AG 2004, BPM@BSGs / Volmering / 4
Integration Server
Business Process Engine
ccBPM Architecture – Overview
Integration
Repository
Abstract
Interfaces
IntegrationDirectory
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
23
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
8/18/2019 ccBPM in XI
5/47
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
ScenarioScenario
Party
RepositorySWCV
Architecture – Definition
Cache/Runtime
ProcessProcess
Flow
If
**
Interf. MappingsInterf. Mappings
Abs tract In terf aces Abs tract In terf aces
Context ObjectsContext Objects
Message TypeMessage Type
XML-objectsXML-objects
CorrelationsCorrelations
Integration ScenarioIntegration Scenario
*
*
Routing RelationRouting Relation
ProcessProcess
Flow
If **
Integration ProcessIntegration Process
Flow
If
**
Mapping RelationMapping Relation
ProcessProcess
ProcessProcess
Message MappingsMessage Mappings
IDOCIDOC
RFCRFC
8/18/2019 ccBPM in XI
6/47
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
8/18/2019 ccBPM in XI
7/47
7
Header AreaDisplays 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 processdefinition to/from BPEL4WS, automatic refresh after modifications in outline view etc. possible (seePersonal 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 oroutbound interfaces. If you want to integrate a business process in a business scenario, youmust 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
Process Design with the Graphical Process Editor
Output Area Object Area
Header
Overview Area
Edit Area
Properties
Area
8/18/2019 ccBPM in XI
8/47
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
Process Editor Settings
Personal Settings
• Default Editor• Horizontal/Vertical Display of Process Definition
• Hide Output Area
• Error Level for Processing Log
• Automatic ref resh for BPEL4WS
Detach, then
maximize window
8/18/2019 ccBPM in XI
9/47
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
8/18/2019 ccBPM in XI
10/47
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
ccBPM - Process Step Types
Receiver Determination
Receive
Transformation
Process Flow Control Relevant:
Send
Container Operation
Messaging Relevant:
Control
Loop
Undefined
Fork Switch
Wait
Block
8/18/2019 ccBPM in XI
11/47
11
© SAP AG 2004, BPM@BSGs / Volmering / 11
Block-oriented Design
Nested blocks Deadlinebranch
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
8/18/2019 ccBPM in XI
12/47
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
Container – Process Data
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 runt ime – references to
messages, loop counters, …
Al lows 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 Defin ition) types: XSD:date, XSD:time,
XSD:integer, XSD:string
Abstract In terface
Receiver
Can be Multil ine (a vector of the types above)
8/18/2019 ccBPM in XI
13/47
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 objectarea.
© SAP AG 2004, BPM@BSGs / Volmering / 13
Process Container and Local Containers
Container elements of inner
block SendParallel are notvisible in outer block
In inner block
CheckResult, container
elements of outer block
SendParallel and
Process container arevisible
8/18/2019 ccBPM in XI
14/47
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 aninstance 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
Correlation Definition
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 coupl ing 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
8/18/2019 ccBPM in XI
15/47
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
Correlation Example
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 fi ll
the corresponding element in
the correlation container (use
context ob jects or XPath)
8/18/2019 ccBPM in XI
16/47
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 messagefrom 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 befilled when the correlation is activated. You can use the whole process container for this purpose. Ifyou 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 receivestep, then the message is received by the process and stored temporarily. As soon as the relevantreceive step is activated, the system automatically assigns it the message that was received firstfor the relevant message interface, which satisfies the correlation used in the receive step. Amessage is only ever assigned to one receive step, even if multiple receive steps are waiting for amessage from the same message interface. In the following cases, multiple receive steps can waitfor a message from the same message interface:
Receive steps arranged one after the other: The first message that arrives is assigned to the first receivestep, the second message is assigned to the second receive step, and so on. Therefore, the firstmessage 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 messagearrives, the process receives the message and places it in a queue. As soon as the process reaches thereceive step and the relevant correlation is active, the system assigns the receive step the oldestmessage from the queue. If the process reaches the receive step but the queue is empty, then theprocess waits until a new message arrives.
Multiple receive steps in a fork: If multiple receive steps in forks are waiting for messages from the samemessage interface, then an inbound message is only assigned to one receive step (at random). Theremaining receive steps must continue to wait.
© SAP AG 2004, BPM@BSGs / Volmering / 16
Receive Step – Starting a Process
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
8/18/2019 ccBPM in XI
17/47
17
You can only define one sync/async bridge per integration process. This comprises the following steps (fordetails see the Process Patterns chapter):
Synchronous Receive (Opening Receive): Receives the Request message from the synchronous business systemand opens the sync/async bridge. The receive step must be the first step in the integration process. In the receivestep you specify the synchronous interface receiving the message from the synchronous business system. Theintegration process is started when the message is received. The message type of the message to be received andthe 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 thesynchronous business system and closes the sync/async bridge. The message type of the message to be sent mustcorrespond 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 integrationprocess.
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 automaticallyreset 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 requestmessage 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
Receive Step – Sync/Async-Bridge
Communication between a synchronous and an asynchronous business
system:
8/18/2019 ccBPM in XI
18/47
18
Asynchronous mode (default): the send step does not wait for a reply message from the receiverafter it has sent the message. However, you can specify that the asynchronous send step must waitfor a confirmation of receipt from the receiver, in the form of an acknowledgment. Prerequisite: Thereceiver (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 thatthe message was received successfully.
Application Acknowledgement: The Send Step waits for an application acknowledgment. This specifiesthat 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 variousoptions 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 sendcontext in a condition in the receiver determination in the Integration Directory. You must specify the send context if you want tosend 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 sendstep, choose the container element that contains the receiver list. The send step itself does not call the receiver determinationthat 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 responseto. The receiver is determined from the message header of this message. In this case, the receiver determination that isconfigured 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 multilinecontainer element are processed in parallel instances of the block at runtime. If a send step within theParForEach 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 Step – Send Message (Asynchronous)
Acknowledgement:
• None
• Transport
• Appl ication
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
8/18/2019 ccBPM in XI
19/47
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 Step – Send Message (Synchronous)
8/18/2019 ccBPM in XI
20/47
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 Step – Send Acknowledgement
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
acknowledgmentis automatically
determined from
the header of the
message
8/18/2019 ccBPM in XI
21/47
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 Step – Sync/Async-Bridge
Closing a Sync/Async-Bridge: send step sends the response from theasynchronous business system to the synchronous business system
8/18/2019 ccBPM in XI
22/47
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
8/18/2019 ccBPM in XI
23/47
23
You use a transformation step to do the following:
n:1 Transformation: Bundles multiple messages into one message, for example, individual purchaseorder items into one purchase order.
1:n Transformation: Splits a message into multiple messages, for example, a purchase order into theindividual purchase order items.
1:1 Transformation: Converts a message into another message, for example, a message that is definedby 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 mapping with a corresponding value
mapping.
At tachments 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 aunique name. If they don’t, the most recently received attachment will overwrite any attachments with thesame name.
If the message you want to split contains attachments, the system replicates them and appends them toall 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
Transformation Step
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
8/18/2019 ccBPM in XI
24/47
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
Receiver Determination Step – List of Receivers for 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
8/18/2019 ccBPM in XI
25/47
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
Switch Step – Defining Processing Branches
Otherwise branch
(created automatically)
Executed if no other
branch returns TRUE
8/18/2019 ccBPM in XI
26/47
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
Container Operation Step – Assigning a Value
8/18/2019 ccBPM in XI
27/47
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
Container Operation Step – Appending a Value
Multiline
Element
8/18/2019 ccBPM in XI
28/47
28
© SAP AG 2004, BPM@BSGs / Volmering / 28
Block Step
Basic design element
Blocks can be nested Block hierarchy defines scope/visibi lity 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
8/18/2019 ccBPM in XI
29/47
29
Exception Handling
Situations can arise in an integration process where it is not possible to continue the integrationprocess normally (for example, due to a system error), or where it is not recommended to continuenormally. You can prepare for such situations when you define the integration process, by usingexceptions and exception handlers.
Exception Handler
You define the reaction to an exception, the exception handler, in a separate processing branch ofa block. In the exception handler branch, you can insert a control step triggering an alert, a controlstep canceling the process or any other steps. The exception handler has read and write-to accessto all data within the block.
Processing at Runtime
If an exception is triggered at runtime, the system first searches for the relevant exception handlerin 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 theexception handler is defined and then continues processing in the exception handler branch. Oncethe 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 throwsthe 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 andwrite 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 menufor the block.
To assign an exception handler to an exception
© SAP AG 2004, BPM@BSGs / Volmering / 29
Block – Exception Handling
Define exception
Assign exception to
exception handler
Throws exception –
process continues in
exception branch
8/18/2019 ccBPM in XI
30/47
30
You can define the dynamic modes Parallel For Each (ParForEach) or For Each (ForEach) for ablock. 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 themultiline container element. All instances are processed simultaneously.
You can use the ParForEach mode when you want to send a message to multiple receiverssimultaneously, for example. To do so, you use a receiver determination step to determine amultiline container element with the list of receivers. You then define that the message is sent tothese receivers in a block with the ParForEach mode.
You specify the multiline container element in the Multiline Element property. In the Current Linefield 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 ofthe lines of the multiline container element returns true for the end condition, or all lines of themultiline container element have been processed.
Local Correlation
Usually, a correlation is valid for the entire process. For example, if a correlation was activated for aparticular purchase order number, then this correlation cannot be used for other purchase ordernumbers. However, you can restrict where a correlation is valid by assigning the correlation to ablock as a local correlation. The local correlation is then only valid within the block. It cannot beactivated or used outside the block to which it is assigned. For example, you can use a localcorrelation in a ParForEach to create and use a correlation with its own unique key (GUID) for eachinstance created at runtime. This then enables each block instance to process a different purchaseorder number.
© SAP AG 2004, BPM@BSGs / Volmering / 30
Block Step – ParForEach (Dynamic ParallelProcessing)
8/18/2019 ccBPM in XI
31/47
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
Block Step – ForEach (Dynamic SequentialProcessing)
8/18/2019 ccBPM in XI
32/47
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
Control Step – Trigger Exception
8/18/2019 ccBPM in XI
33/47
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
Control Step – Trigger Alert
Alert Message
will be displayed
in Alert Inbox
8/18/2019 ccBPM in XI
34/47
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
Control Step – Cancel Process
8/18/2019 ccBPM in XI
35/47
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
Fork Step – Independent Processing Branches
8/18/2019 ccBPM in XI
36/47
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 Step – Repeat Execution of Steps
8/18/2019 ccBPM in XI
37/47
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
Wait Step – Specifying Start Time for Next Step
8/18/2019 ccBPM in XI
38/47
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
8/18/2019 ccBPM in XI
39/47
39
© SAP AG 2004, BPM@BSGs / Volmering / 39
Standards Support
Support for open standards
BPEL4WS 1.1
(BPM in SAP XI 3.0) Active part ic ipation in
standards, e.g.:
Advance BPEL4WS 1.1
together wi th 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 .
8/18/2019 ccBPM in XI
40/47
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 Introduction
Business Process ExecutionLanguage for Web Services
Language for the formalspecification of business processesand business interaction protocols
Extends Web Services interactionmodel enabling it to suppor tbusiness transactions:
Temporal and logical dependenciesbetween activities, especially Webservice interactions
Association between a message
received by the Web service and aparticular process instance
Error handling and compensationbehavior
Binary relationships between processroles
8/18/2019 ccBPM in XI
41/47
41
ccBPM supports 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 to Use BPEL4WS in ccBPM
BPEL4WS as exchange format for exporting and importing in tegrationprocesses to/from non-SAP systems
BPEL4WS not intended for import ing or exporting integration processesbetween Integration Repositories on different XI systems (use importfunction instead)
WSDL
View
BPEL4WS
View
8/18/2019 ccBPM in XI
42/47
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 thatcontains the following files:
.bpel: Definition of the integration process as displayed in the BPEL4WS view
.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 theintegration process from the Integration Repository, you must also specify the partner link type and partnerlink.
A partner link type describes the relationship between two services and the role that each service has. Forexample, the partner link type BuyerSellerLink can define the roles Buyer and Seller. A partner link definesthe services with which an integration process interacts. Each partner link has a partner link type. Multiplepartner links can have the same partner link type, for example, a procurement process can interact withmultiple 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 processdefinition in the Integration Repository, it cannot be exported automatically. Furthermore, a message interfacecan be used in different ways in different steps. For example, an integration process receives a purchaseorder request in a receive step by means of an message interface. In this case, you can define the partner linktype PurchaseOrderRequest for the message interface. The same message interface can then be used in asend step later on in the integration process, for instance, to send a purchase response. You can then alsodefine 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 thatyou 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 Export
8/18/2019 ccBPM in XI
43/47
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 namespacehttp://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 softwarecomponent 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 Import Select .zip filecontaining (.bpel
and .wsdl file)
Select Message
Interface (should be
created before startingthe import)
8/18/2019 ccBPM in XI
44/47
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
8/18/2019 ccBPM in XI
45/47
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
Exception Handling – Exception and Exception Handler
Exception can be triggered by:
Async or sync send step, transformat ion 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 (exceptionbranch of the block)
Send step triggers
exception
in case of a
permanent system
error
8/18/2019 ccBPM in XI
46/47
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 notautomatically 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
Deadline Monitoring
Control step
triggers
TimeOut
exceptionDeadline branch
– executed, i fthe deadline has
exceeded
Exception handler for
Timeout Exception
Deadline,
defined in the
deadline
branch
8/18/2019 ccBPM in XI
47/47
© SAP AG 2004, BPM@BSGs / Volmering / 47
Summary
Now you should be able to:
Understand the basic design principles of cross-componentBPM
Define integration processes
Import/export integration processes to/from non-SAP systems
Setup exception handling