ccBPM in XI

8/18/2019 ccBPM in XI

1/47

1

Business Process ManagementCross-component BPM

Author: Andrea Schmieden


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


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


Agenda

ccBPM Architecture

Graphical Process Editor

Process Design Basics

More Step Types

BPEL4WS Import and Export

Exception Handling


4/47

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


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.


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


6/47

6


Agenda

ccBPM Architecture



More Step Types


Exception Handling


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


Process Design with the Graphical Process Editor

Output Area Object Area

Header

Overview Area

Edit Area

Properties

Area


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


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


9/47

9


Agenda

ccBPM Architecture



More Step Types


Exception Handling


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


ccBPM - Process Step Types

Receiver Determination

Receive

Transformation

Process Flow Control Relevant:

Send

Container Operation

Messaging Relevant:

Control

Loop

Undefined

Fork Switch

Wait

Block


11/47

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


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.


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)


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.


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


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.


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


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.


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)


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.


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


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.


Receive Step – Sync/Async-Bridge

Communication between a synchronous and an asynchronous business

system:


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.


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


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.


Send Step – Send Message (Synchronous)


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.


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


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.


Send Step – Sync/Async-Bridge

Closing a Sync/Async-Bridge: send step sends the response from theasynchronous business system to the synchronous business system


22/47

22


Agenda

ccBPM Architecture



More Step Types


Exception Handling


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)


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


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.


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


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


Switch Step – Defining Processing Branches

Otherwise branch

(created automatically)

Executed if no other

branch returns TRUE


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.


Container Operation Step – Assigning a Value


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.


Container Operation Step – Appending a Value

Multiline

Element


28/47

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


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


Block – Exception Handling

Define exception

Assign exception to

exception handler

Throws exception –

process continues in

exception branch


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.


Block Step – ParForEach (Dynamic ParallelProcessing)


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.


Block Step – ForEach (Dynamic SequentialProcessing)


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.


Control Step – Trigger Exception


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


Control Step – Trigger Alert

Alert Message

will be displayed

in Alert Inbox


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.


Control Step – Cancel Process


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.


Fork Step – Independent Processing Branches


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.


Loop Step – Repeat Execution of Steps


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.


Wait Step – Specifying Start Time for Next Step


38/47

38


Agenda

ccBPM Architecture



More Step Types


Exception Handling


39/47

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


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/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


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


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.


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


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.


BPEL4WS Export


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.


BPEL4WS Import Select .zip filecontaining (.bpel

and .wsdl file)

Select Message

Interface (should be

created before startingthe import)


44/47

44


Agenda

ccBPM Architecture



More Step Types


Exception Handling


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.


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


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.


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


47/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

ccBPM in XI

Documents

Transcript of ccBPM in XI