Bit430 en Col74

BIT430SAP NetWeaver PI Business

Process Management

SAP NetWeaver

Date

Training Center

Instructors

Education Website

Participant HandbookCourse Version: 74Course Duration: 3 Day(s)Material Number: 50089751

An SAP course - use it to learn, reference it for work

Copyright

Copyright © 2008 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without theexpress permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary softwarecomponents of other software vendors.

Trademarks

• Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® areregistered trademarks of Microsoft Corporation.

• IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®,AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.

• ORACLE® is a registered trademark of ORACLE Corporation.

• INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered trademarksof Informix Software Incorporated.

• UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group.

• Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®,VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks ofCitrix Systems, Inc.

• HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World WideWeb Consortium, Massachusetts Institute of Technology.

• JAVA® is a registered trademark of Sun Microsystems, Inc.

• JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license fortechnology invented and implemented by Netscape.

• SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAPEarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com aretrademarks or registered trademarks of SAP AG in Germany and in several other countries allover the world. All other products mentioned are trademarks or registered trademarks of theirrespective companies.

Disclaimer

THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLYDISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING WITHOUTLIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULARPURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT,GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. INNO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL,CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDINGWITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROMTHE USE OF THESE MATERIALS OR INCLUDED SOFTWARE COMPONENTS.

g20089234550

About This HandbookThis handbook is intended to complement the instructor-led presentation of thiscourse, and serve as a source of reference. It is not suitable for self-study.

Typographic ConventionsAmerican English is the standard used in this handbook. The following typographicconventions are also used.

Type Style Description

Example text Words or characters that appear on the screen. Theseinclude field names, screen titles, pushbuttons as well asmenu names, paths, and options.

Also used for cross-references to other documentationboth internal (in this documentation) and external (inother locations, such as SAPNet).

Example text Emphasized words or phrases in body text, titles ofgraphics, and tables

EXAMPLE TEXT Names of elements in the system. These include reportnames, program names, transaction codes, table names,and individual key words of a programming language,when surrounded by body text, for example SELECTand INCLUDE.

Example text Screen output. This includes file and directory namesand their paths, messages, names of variables andparameters, and passages of the source text of a program.

Example text Exact user entry. These are words and characters thatyou enter in the system exactly as they appear in thedocumentation.

<Example text> Variable user entry. Pointed brackets indicate that youreplace these words and characters with appropriateentries.

2008/Q2 © 2008 SAP AG. All rights reserved. iii

About This Handbook BIT430

Icons in Body TextThe following icons are used in this handbook.

Icon Meaning

For more information, tips, or background

Note or further explanation of previous point

Exception or caution

Procedures

Indicates that the item is displayed in the instructor'spresentation.

iv © 2008 SAP AG. All rights reserved. 2008/Q2

Contents

Course Overview .... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiCourse Goals. . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . . .viiCourse Objectives . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . . .vii

Unit 1: Business Process Management (BPM) Motivation and Approach . .. . . . . .1

Overview of the Development of Business Process Management in the SAPNetWeaver Environment . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . . . .2

BPM Standards .. . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . . 11ccBPM as Part of SAP NetWeaver Process Integration Infrastructure . . . . . . . .. . . . . 17

Unit 2: Business Process Management: Cross-Component BPM .... . . . . . . . . . . . . 35

First Steps in ccBPM ... . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . . 37Step Types (Part 1) and Correlation. . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . . . . . . . .. . . . . 58Step Types (Part 2) and Exception Handling . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . . . . . . . .. . . . . 76Process Templates and Step Groups .. . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . . . . . . . .. . . .104Step Types (Part 3) . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . .122

Unit 3: Business Process Management: Execution and Troubleshooting. .. . .151

Business Process Engine: Overview and Runtime Cache... . . . . . . . . .. . . . . . . . . . .. . . .153Process Execution Monitoring .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . .185Message Monitoring. .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . .198

Unit 4: Business Activity and Performance Management ... . . . . . . . . . . . . . . . . . . . . . . 211

Business Activity Monitoring in ccBPM ... . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . . . . . . . .. . . .212BPE Performance Management . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . . . . . . . .. . . .218

Appendix 1: Optional Exercise for Pattern - Overall Scenario: Create IntegrationProcess, Integrated in SAP Exchange Infrastructure ... . . . . . . . . . . . . . . . . . . . . . . . . .235

Appendix 2: Solution for Optional Exercise Pattern - Overall Scenario: CreateIntegration Process, Integrated in SAP Exchange Infrastructure ... . . . . . . . . . .237

Appendix 3: Optional: Combining ccBPM and Business Workflow: ExampleCoding ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243

2008/Q2 © 2008 SAP AG. All rights reserved. v

Contents BIT430

vi © 2008 SAP AG. All rights reserved. 2008/Q2

Course OverviewThe course provides an overview of cross-component Business Process Management(ccBPM) in the SAP NetWeaver environment. You will learn about ccBPM and all itscomponents.

The course will also explain how to implement ccBPM processes and introduceBusiness Activity Monitoring.

Target Audience

This course is intended for the following audiences:

• Consultants in the area of Business Process Management

• Anyone who is interested in Business Process Management in SAP NetWeaver

• Customers who want to implement cross-component processes

• Project managers in the area of Business Process Management

Course Prerequisites

Required Knowledge

• BIT400 (SAP NetWeaver Process Integration)

• Good knowledge of the configuration of the SAP Process IntegrationInfrastructure

Recommended Knowledge

• Knowledge of SAP Business Workflow

Course GoalsThis course will prepare you to:

• Understand the concepts of Business Process Management

• Understand the logic of cross-component Business Process Management

• Use SAP Exchange Infrastructure to implement cross-component processes inyour system landscape

2008/Q2 © 2008 SAP AG. All rights reserved. vii

Course Overview BIT430

Course Objectives

After completing this course, you will be able to:

• Describe the components of Business Process Management

• Use the process editor to implement ccBPM processes

• Test ccBPM processes

• Monitor ccBPM processes

viii © 2008 SAP AG. All rights reserved. 2008/Q2

Unit 1Business Process Management (BPM)

Motivation and Approach

Unit OverviewThis lesson gives you a general overview of SAP Business Process Management.

Unit ObjectivesAfter completing this unit, you will be able to:

• Explain the implementation of business process management in the SAPNetWeaver environment

• Understand the objectives and tasks of technical process integration with ccBPM

• Explain the basic principles of BPM standards

• Export a business process

• Import a business process

• Describe the main features of ccBPM

• Describe the integration scenario used in BIT430

Unit ContentsLesson: Overview of the Development of Business Process Management inthe SAP NetWeaver Environment . . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . . . . .2Lesson: BPM Standards .. . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . . . 11Lesson: ccBPM as Part of SAP NetWeaver Process Integration Infrastructure. . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . 17

Exercise 1: Answer the Following Questions About ccBPM... . . . . . .. . . . . . 27

2008/Q2 © 2008 SAP AG. All rights reserved. 1

Unit 1: Business Process Management (BPM) Motivation and Approach BIT430

Lesson: Overview of the Development of BusinessProcess Management in the SAP NetWeaverEnvironment

Lesson OverviewIn this lesson we will discuss business process management in SAP NetWeaver andcustomer requirements in the context of business process management. You willalso learn how SAP wants to realize a unified modeling environment for businessprocesses in the future.

Lesson ObjectivesAfter completing this lesson, you will be able to:



Business ExampleYour company wants to adopt an integration process for selling spare parts. The spareparts are selected in a non-SAP catalog/CRM system. The non-SAP catalog/CRMsystem sends the spare part items in individual messages and an integration processstarts with a collect pattern: the order items are merged into a single message. Thismessage is used for preparations taking place in the company's sales and distribution(SD) system. A synchronous call is made to the SD system to check whether missingmaterials have to be created. If so, the materials are created by looping through a list ofmissing materials and sending each material to the receivers, materials management,and the SD system. Then a sales order and a purchase order are created.

Let us image that SAP delivers a standard process for selling spare parts and that yourcompany wants to adapt the process to customer-specific requirements. Participants ofthe “selling spare parts” project want to know everything about the different levels ofBusiness Process Management with SAP NetWeaver and how to implement processes.

BPM - Overview and VisionBusiness Process Management (BPM) helps companies optimize their businessprocesses and thereby decrease their total cost of ownership. With its comprehensiveperspective, BPM fills the gaps between business requirements and the IT world.

2 © 2008 SAP AG. All rights reserved. 2008/Q2

BIT430 Lesson: Overview of the Development of Business Process Managementin the SAP NetWeaver Environment

To maintain its competitiveness over time, a company's process landscape mustremain flexible in the face of changes.

Such changes might include the development of new markets, the introduction of newproducts to the market, changes in laws, the extension of business partner networks,the takeover of other companies, and the outsourcing of processes to service providers.

End-to-end (E2E) business processes can be described as combinations of variousprocess types:

• User-centric composite processes

are designed to support user interaction. This process group is supported using anew BPM modeling tool as part of the SAP NW Composition Environment.

• Kernel application or platform processes

form the SAP standard as an integrative part of the Business Process Platform(BPP).

• System-centric integration processes

describe the integration between applications (A2A) and/or business partners(B2B). This process group is implemented using the SAP NetWeaver ProcessIntegration Platform.

Hint: These different types of business processes communicate with eachother through services and events.



Figure 1: BPM: Modules of the SAP NetWeaver BPM Function

Implementing Business Process Management in theSAP NetWeaver Environment

With SAP NetWeaver, business processes can be defined and implemented ondifferent levels of the architecture. The following figure shows how Business ProcessManagement is integrated in the SAP NetWeaver environment.

Figure 2: Modules of the SAP NetWeaver BPM including Enterprise ModelingApplications



As an optional module, customers can use the SAP Enterprise Modeling Applicationsfrom the IDS Scheer company. The advantages of this modeling level are particularlyevident in large projects on the enterprise level. Enterprise Modeling goes far beyondthe conceptual modeling of business processes. The focuses are planning and controlof an enterprise's entire IT architecture.

Between the enterprise modeling level and the SAP domains, integration andcommunication takes place via the SAP Solution Manager. This provides referencecontent for the process configuration as well as transactional variants of businessprocess scenarios.

The SAP NetWeaver Composition Environment (CE) supports

• A process modeling environment based on standards

• Interaction between integration processes

• Semantic integration with SAP kernel processes

• Management of user interactions

• Management of roles and responsibilities

• Event resolution mechanisms

SAP Application Core Processes are SAP business applications in the SAP BusinessSuite. These processes are predefined and packed and can be adjusted in the differentvarious applications (for example SAP ERP, PLM, CRM or SRM). They are thereforespread across all business areas. These preconfigured process packages are providedby SAP as reference processes.

On the SAP NetWeaver PI 7.1 level, you can create integration processes thatorchestrate message exchange between the systems in your landscape (SAP andnon-SAP systems). Messages that belong to a process instance are identified usingcorrelations based on the message content.

You can connect cross-system and cross-application processes to the applicationprocesses of the individual systems. Integration scenarios and processes which areused for communication between business partners in industry-specific instances (forexample RosettaNet) can also be made available to the complete process architecture.

Beyond facilitating status-based message exchange, another important task performedby ccBPM is error and exception handling.

Technical Process Integration - Challenges andRequirementsThe successful companies of the future will be those that develop business processesflexibly, map them in the IT architecture, and automate them in a cost-effectivemanner.



Traditionally, business process management has been divided into two distinct camps:

• BPM as a management initiative directed towards standardizing and optimizingbusiness processes in an enterprise

• BPM as a technology and software product that supports an enterprise's ITorganization in the development and use of end-to-end integration processes

.

Figure 3: Process Integration: Objectives

Even in this era of new technologies, it remains difficult for IT departments to conveytheir technically-oriented view of data, system and interfaces for the integration ofheterogeneous system landscapes to top management and departments.

Management and the departments define “what” needs to be done, while IT expertsknow “how” to realize the strategy and “with what” tools and systems.

As the concepts, tools and procedures on these two levels often diverge, protractedconsultations are often necessary.

BPM overcomes this communication barrier. Internal and cross-company businessprocesses are regarded holistically - from the design (business strategy), to modeling,configuration and automated execution, down to technical monitoring.



ccBPM is SAP's technical solution for process management in the SAP NetWeaver.It provides the infrastructure for automating business processes spanning differentapplications (A2A scenarios) and company borders (B2B scenarios).

Challenges in the Use of ccBPM

In an ideal world, process integration provides a clean separation between thedefinition of the process in the process model, the execution of the process in theBusiness Process Engine, basic communication, routing and mapping being handledby the Integration Broker and adapters, and the implementation of the individualfunctions in the applications. This separation would allow application functions tobe reused and rearranged in many different processes.

In a real-life situation, however, things look a bit different. Applications typically havean internal process/state model, which is usually implicit and depends on applicationconfiguration. Take the following example: Example: In SAP Supplier RelationshipManagement (SRM), it is possible to create a purchase order (PO), send it out to asupplier and change the PO before having received a response from the supplier. If anSRM customer would like to do business transactions with its suppliers based on theindustry standard protocol RosettaNet, the customer is faced with the problem thatRosettaNet is based on a request/response pattern, that is, a PO request to the suppliermust to be answered by a PO response from the supplier before subsequent processes,such as PO changes, can be initiated. In such cases, process integration must matchthe different process models to allow process automation. Applications, therefore, firstneed to become more flexible and make their internal process/state models explicit inorder to move closer to an ideal world.

Another problematic topic is how automated processes and user-driven processes(workflows) interact. There will always be situations where automated processes arenot sufficient. Such situations occur, for example, when handling exceptions.

An integration strategy that embraces an event-driven approach can deliver consistentinformation across the enterprise far more rapidly. Often, event-driven integration isthe only way to ensure consistency, since many events only have meaning if capturedat the precise moment they occur.

A technical BPM solution faces the following challenges:

• Lack of transparency of integration processes due to a lack of a commonplatform for business and IT

• Fragmentation of integration processes due to individual solutions in thedepartments

• High flexibility of integration processes due to market demands



Tasks in ccBPM

A procedural model for an integrated BPM approach needs to align the businessdepartment with the IT experts. In an “as-is” analysis, a process expert describesthe company process map, defining also the business strategy on this level. Fromvalue chain diagrams to organizational data and functional allocations, the processdescriptions finally lead to a level where business scenarios, processes, and processsteps can be clearly separated.

The IT department usually takes care of the integration tasks in heterogeneous systemlandscapes. Their goal is to integrate and automate system communication andprocess execution within and across systems. Aligning business with IT is one of thechallenges that cross-organizational projects have to face.

Cross-Component Business Process Management inSAP NetWeaverCross-component Business Process Management (ccBPM) in SAP NetWeaver allowscompanies to continuously adapt their integration scenarios and processes to newbusiness strategies and meet the demands of today’s business environment. It allowsIT organizations to react quickly to new requirements and, at the same time, optimizethe system landscape without impacting the overall business processes.

Figure 4: Cross-Component Business Process Management in SAP NetWeaver



ccBPM enables flexible, model-driven design, implementation and execution ofintegration processes within and across different business applications. ccBPMallows companies to model processes with different users performing different rolesand tasks, optimizing the communication between the process owner and IT expert.Process models designed on different abstraction levels of modeling (business levelmodeling, configuration, and execution modeling) are used to configure processesrunning inside business applications and across applications and enterprise boundaries.

A model-driven design enables the deployment of process logic on engines for processexecution or in workflow management systems. This is based on a standard formatsuch as the Business Process Execution Language for Web Services (BPEL4WS).

Technical process monitoring leverages the deployed process model and runningprocess instances of the abstracted model at runtime to monitor interfaces, transactions,throughput of messages, and technical process performance in conjunction withstandard services provided by technical alert monitors.



Lesson Summary

You should now be able to:




BIT430 Lesson: BPM Standards

Lesson: BPM Standards

Lesson OverviewThis lesson will provide you with essential information about BPM standards andtheir use within ccBPM.





Business ExampleYour company uses a special business process that is implemented with ccBPM inthe SAP SAP NW PI 7.1 infrastructure. One of your partners would like to use thesame business process. Your partner does not use SAP NW PI 7.1, but the productis compatible with WS-BPEL. Therefore, you can just export your business processin the WS-BPEL format and hand it over to your partner, who can then import theprocess in his or her modeling tool.

BPM Standards: IntroductionTo enable the portability and interoperability of integration processes, SAP supportsand implements industry standards that apply to those industries. The selection ofthose standards is primarily driven by customer requirements.

Business Process Execution Language (BPEL) is one of the most widely appliedstandards for the design and execution of system-centric business processes.

WS-BPEL is a Web service-based XML language and defines the way in which abusiness process can be executed by the use of Web services. If this standard isused, modeling information can be easily exported into another vendor's modelingtool and vice versa.

WS-BPEL is a standard language for the formal specification of business processesand business interaction protocols. SAP has implemented this standard in versionBPEL4WS1.1 since 2003. This version is still supported in SAP NW PI 7.1 ccBPM.

This standard is currently being developed for version WS-BPEL 2.0. This version isoffered as preliminary version in ccBPM. The deficit in both versions at present is thelack of artifacts for user communication.



Another emerging standard is BPEL4People. SAP defined the standard together withIBM to close the gap in the user communication area.

To bridge the differences between system- and user-focused process definitions, inthe future SAP will also support and deliver Business Process Modeling Notation(BPMN) as a notation for process modeling. BPMN should be independent ofexecution-specific artifacts. This procedure leads to system-independent modeling andallows a transformation of process modeling activities to the needs of the departments.

Figure 5: BPM Standards

Hint: For more information about BPM standard, go tohttps://www.sdn.sap.com/irj/sdn/docs?rid=/webcontent/uuid/b4313088-0901-0010-3d97-9566d764c212.

WS-BPEL in SAP NW PI 7.1 ccBPMWithin SAP NW PI 7.1, WS-BPEL is used as the standard modeling language ofthe business processes in ccBPM. Therefore, you can have a look at the WS-BPELrepresentation at any time in the process editor just by changing into the WS-BPELDisplay view inside the Edit area. The corresponding data type definitions are showninside the Output area when switching to the Web Service Definition Language(WSDL) view. BPWEL4WS can be used as the exchange format for exportingan integration process to a non-SAP system and executing it there. Conversely,WS-BPEL can also be used for importing an integration process from a non-SAPsystem to the SAP Exchange Infrastructure. The exporting and importing is done fromthe BPEL4WS Display view.


https://www.sdn.sap.com/irj/sdn/docs?rid=/webcontent/uuid/b4313088-0901-0010-3d97-9566d764c212


Figure 6: BPEL: SAP PI and ccBPM

Hint: Note that WS-BPEL as an exchange format is designed for exportingand importing integration processes to and from non-SAP/ SAP systems.The WS-BPEL format is not for the import/export of integration processesbetween Enterprise Services Repositories. To do that, use the import functionof the Enterprise Services Repository instead.

WS-BPEL ExportThe Export function exports the integration process definition in the selectedWS-BPEL format. Moreover, data types, message types, and operations that arereferenced in the process definition are exported as a WSDL description. Thereforea .zip file is generated, containing a .bpel and a .wsdl file. The .BPEL file containsthe process definition as displayed in the WS-BPEL view. The .wsdl file contains thereferenced data types, messages types, and operations. You can name the .zip file asyou please. The name will also be used for the .bpel and .wsdl files.

To create a valid WS-BPEL description when exporting an integration process, youhave to define the integration process from the Integration Repository and specify thepartner link type and partner link. A partner link type describes the relationshipbetween two services and the role from each service. A BuyerSellerLink partner linkcan, for example, define the roles Buyer and Seller. The services interacting with anintegration process are defined by the partner link. Each partner link has a partnerlink type and multiple partner links can have the same partner link type. For example,



a particular procurement process can work with multiple providers, and yet use thesame partner link type for all providers. A partner link type is referenced on theabstract interface.

Take into account that messages and, respectively, abstract interfaces can be used indifferent ways since they are inbound and outbound interfaces in one. For example,in one step an interface can be used as a receiver, and in another step it acts as asender. In such a case you should ensure that you enter a meaningful name for thepartner link to avoid confusion when you later import your process. This informationmust be maintained manually since the relationship between the two services andtheir respective roles are configured in the Integration Directory. The information istherefore not part of the integration process and cannot be exported automatically.

WS-BPEL ImportThe WS-BPEL Import imports the WS-BPEL definition of an integration process.The import expects a .zip file, containing a .bpel and a .wsdl file of the same name. Ifan import is started in an existing integration process, this process will be overwritten.Furthermore, the import expects that the data types, message types, and operations(message interfaces) that are referenced in the process definition are already availablein the relevant namespace. This is caused by the fact that the information from the.wsdl file does not import the data types and so on, but is just used to support theimport procedure. Example: The process definition to be imported has a referenceto the message OrderRequest in the namespace http://sap.com/WS-BPEL . Thisdefinition is now imported into the software component version BPEL_SWC. Theimport then expects that the mentioned namespace is available in the SoftwareComponent (SWC) and that it contains the message OrderRequest.


http://sap.com/BPEL4WS


Figure 7: WS-BPEL : Import Wizard

In ccBPM, message-based container elements are used in the properties of certainsteps and in correlations. These container elements correspond to variables withinWS-BPEL. A container element references a message interface, which references amessage type. In spite of this, a BPEL variable references a message type directly.Because of this, the message interface specification is missing when a BPEL variableis imported. Therefore, it is advisable that you create the required message interfacesin the Integration Repository before starting the import. During the import they can beassigned within the import wizard (see the above figure). If the message interfaces arenot created before the import starts, the process definition will still be imported, butthe values between the various properties will be empty and you will have to fill themlater. Otherwise you will not be able to activate the process.



Lesson Summary





Related Information

For more information about restrictions to the WS-BPEL import and export functionssee SAP Note 709650.


BIT430 Lesson: ccBPM as Part of SAP NetWeaver Process Integration Infrastructure

Lesson: ccBPM as Part of SAP NetWeaver ProcessIntegration Infrastructure

Lesson OverviewThe SAP NW Process Integration Infrastructure (SAP PI) enables systems tocommunicate and exchange data with each other by means of XML messages. Themessages are processed statelessly on the Integration Server. In SAP NetWeaver, thiscommunication is represented by the Integration Broker in the process integrationsection.

The following lesson introduces cross-component Business Process Management(ccBPM), which enables you to create process definitions that include multiplesystems in your system landscape (both SAP and non-SAP systems) and whichcan exchange data between the systems. The data is exchanged by means of XMLmessages in SAP PI; however, it is processed statefully with ccBPM. You can definethe following types of processes:

System and cross-application integration processes (scenario variant serviceorchestrating)

Monitoring processes that can monitor events from different applications




Business ExampleYou want to automate a cross-component end-to-end (E2E) business process in yourcompany. Since SAP NW PI is implemented as the integration platform in your ITsystem landscape, you want to acquaint yourself with the principles behind ccBPM inthis environment.

Business Process Management with ccBPMccBPM is available in SAP XI 3.0 and higher and is used to model, execute, andmonitor integration processes that extend beyond system and application boundaries.

Integration processes are part of message-based process integration in SAP NetWeaver.



The following lists the main functions of ccBPM:

• ccBPM enables you to design, execute, and monitor processes across differentapplications.

• ccBPM is an integral part of the SAP NW PI infrastructure.

• ccBPM contains a graphical process editor.

• ccBPM contains a Business Process Engine.

• ccBPM adheres to open modeling standards.

– BPEL4WS 1.1 (Business Process Execution Language for Web Services)

– WS-BPEL 2.0

• ccBPM supports industry standards.

– RosettaNet (RNIF adapter, PIP, and so on)

To define integration processes, you need to have some knowledge of message-basedprocess integration and the Enterprise Services Builder.

By creating an Integration Process in the Enterprise Service Repository, you defineyour business process. An Integration Process is an executable cross-componentprocess, determining the processing of messages at runtime. You define this processin a sequence of steps in a graphical editor. The process editor provides several steptypes for this purpose. The step types can be divides into two sections: Step typesfor processing messages, like the receiving or sending step, and step types to managethe process logic. This may be the loop or switch step.



Figure 8: ccBPM Architecture – Object Relationships

Unlike simple message processing where an inbound message is processed by meansof a receiver determination, mapped to the target format if necessary, and sent tothe target system, in ccBPM the message is processed statefully. The status of anintegration process is persisted on the Integration Server and new inbound messagescan be assigned to a running process instance by means of correlations.

ccBPM is integrated in all components of SAP PI:

you define both integration processes and integration scenarios at design time inthe Enterprise Service Repository. You configure the runtime parameters in theIntegration Directory. On the Integration Server, the Business Process Engineprocesses the BPM messages.

ccBPM Architecture: OverviewThe ccBPM architecture consists of two parts. The design time (Enterprise ServicesBuilder) and the runtime (Integration Server). The design is done in the ES Builder.First, you define your integration process in the Enterprise Service Repository.

This is followed by the configuration of the process in the Integration Directory.

Afterward, all the information is sent to runtime in the Integration Server. Within theIntegration Server, the Integration Engine is responsible for the routing, mapping, andchannel determination. The Business Process Engine (BPE) hosts the correlation



handling and process execution. Therefore, the BPE ensures that different messagesare correlated in the right way and that messages belonging together are executed inthe same process.

Figure 9: ccBPM – Integration in SAP Exchange Infrastructure

The figure above shows this architecture and the interaction between the BusinessProcess Engine and the Integration Engine at runtime in order to send and receivemessages.

1. A message from an arbitrary sender is received by the Integration Engine. Thereceiver determination is looked up in the Integration Directory and, in this case,an integration process is found as receiver. If the interface determination refersto an operation mapping, it is carried out.

2. After the output processing, the message is forwarded to the Business ProcessEngine. First the message is checked to see if it correlates with any othermessage and whether an instance is waiting for this message. However, themessage can also start a new process instance.

3. If the Business Process Engine gets to a sending step, the current message is sentto the Integration Engine, running through the same steps as before.

4. Finally, the Integration Engine determines a receiver that is not an integrationprocess and forwards the message to this receiver.



The relationship among different objects within SAP PI regarding ccBPM is shownin the preceding figure. Within the Enterprise Service Repository, the integrationscenario is represented by swim lanes. The integration process within this scenariorefers to the business process in the software component version (SWCV).

The integration process uses abstract interfaces, context objects, and operationmappings. Abstract interfaces refer again to message types, IDocs, or RemoteFunction Calls (RFCs). Operation mapping refers to message mappings. Integrationprocesses are located in the Integration Directory under the Service Without Partynode. This is the active version of an integration process from the Enterprise ServiceRepository. The process also appears in the lower area, Cache and Runtime, as aworkflow template. The system generates this workflow process using the processdefinition from the Integration Directory the first time the object is activated inthe Integration Directory. During runtime, the process refers to XML objects andcorrelations.

Correlation Between MessagesThe following figure shows an example: The Integration Server is waiting formessages from business systems 1, 2, and 3. Once the Integration Server has receivedall expected messages, it sends a combined message to business system 4.

Figure 10: Correlation Between Messages

But how does the process engine know which messages belong together?



An important feature in the integration process is the correlation you can use to definethe relationship between messages. If messages do not belong to the process, it mustbe ensured that they do not disturb the process. For that reason, a correlation isdefined, combining only messages that belong to each other. For example, an ordercan be correlated with its invoice via the corresponding order number.

Configuration is done in the Integration Directory, as usual. You just have to definereceiver determination for the integration process.

Execution of the integration processes is managed by the Business Process Engine,which is located in the Integration Server. Additional monitor functions for theBusiness Process Engine are provided within the general monitoring.

Example of an Integration Process: Sales OrderProcessingCar dealers could use a non-SAP CRM system to order spare parts. The followingslide shows an overview of a system landscape for the procurement of spare parts.

Figure 11: Integration Scenario – Procurement of Spare Parts

The business case for the complete process is a simplified procurement of spare parts.The spare parts are selected in a non-SAP catalog/CRM system, which is simulated byan HTTP client user interface.



Figure 12: CRM System, Simulated by HTTP Client

Since the non-SAP CRM system sends the spare part items in individual messages,the process starts with a collect pattern. In our integration process, three order itemsare merged into a single message that is sent to the SD system to check the availabilityof the materials. This takes place using a synchronous call, which returns a list ofmissing materials.

If the materials are not in the SD system and need to be created, the list runs thoughthe missing materials. Each material is sent to the consumers (MM and SD system)and the materials are created in the systems.

In the next section, we will generate a sales order in the SD system and a purchaseorder in the MM system. If it is not possible to create both objects successfully, thenneither is generated.

At the end of the process, the supplier receives and confirms the purchase order.



In this class, the different systems are represented by different clients and differentbusiness systems of the same training system:

• CRM system/catalog is an HTTP client (business system DMSCRM)

• Client 800: Integration Server with integration process

• Client 812: SD system (business system Airline_Group_One)

• Client 813: MM system (Business System Airline_Group_Two)

• Client 811: Supplier system (Business System Travel_Agency_Summer)

Figure 13: Integration Scenario – Steps and Systems



The Integration Scenario process is defined as follows:

1. The CRM system sends data item-by-item in a given format to the IntegrationServer.

The receiver of the message is an integration process.

2. The integration process sends a synchronous message to the SD system to checkwhether the materials exist.

3. If the CRM system requests a new material, this is created in the SD and MMsystem.

4. A purchase order and a sales order are created.

5. The purchase order is sent to the supplier, and the order confirmation sent bythe supplier is acknowledged.

We want to concentrate on the modeling of the process. Therefore, we use simplemessage types and there is no mapping between process interfaces and the interfacesused by the business systems.

In fact, we simulate the business objects (for example, create material, create order)using ABAP proxies in the business systems.

The Integration Directory is preconfigured. You use a wizard to apply the integrationprocess.

Implementation and Configuration of the IntegrationProcess in the Integration BuilderIntegration processes add status-based processing of messages to message-basedprocess integration: The status of an integration process is made persistent on theIntegration Server. This means that an integration process can, for example, waitinfinitely until further messages are received or until a particular deadline is reached.Furthermore, messages can be further processed inside an integration process, that is,the messages can be collected and then sent in a particular order.



The integration process of ccBPM retrieves messages from a business system andsends messages to a business system.

• Design time

To aid in the definition of an integration process during the design time,Enterprise Services Builder provides a graphical process editor in the repository.

Integration processes are objects in the Enterprise Services Repository and areintegrated with other objects, such as service interfaces.

Such objects may include interfaces (service interfaces) from systems orprocesses.

Once you have defined the necessary objects in the Enterprise ServicesRepository, you can define your integration process using the process editor.After having finished the integration process, it is useful to define an integrationscenario with the relevant business systems and the integration process.

• Configuration Time

You adjust the PI scenarios and integration processes in the Integration Directoryto your system landscape. At configuration time, you configure (for examplefor the integration process):

– Receiver determination

– Sender and receiver agreement

– Interface determination

You can define these objects manually or you can use an SAP PI tool, theIntegration Scenario Configuration.

To use this tool, you must create a configuration scenario in the IntegrationDirectory by grouping together all configuration objects that result from theconfiguration or that are reused from elsewhere.

• Runtime

The Business Process Engine (BPE) then executes the integration process atruntime. The Business Process Engine is part of the Integration Server. Youcan monitor the execution of integration processes by using the monitoringfunctions of the Integration Engine.

Note: An integration process can use all objects that are available in theSWCV of the process.



Exercise 1: Answer the Following QuestionsAbout ccBPM

Exercise ObjectivesAfter completing this exercise, you will be able to:

• Explain how implementation and configuration is performed in the IntegrationBuilder

• Explain the tasks of the Integration Engine

• Explain the purpose of ccBPM

Business ExampleYou are part of a ccBPM project team and you need to be able to answer the questionsof new team members.

Task:Answer the following questions:

1. What is the purpose of ccBPM?

2. What standards can you use to exchange integration process definitions?ccBPM?

Continued on next page



3. Which object do you use for a cross-system business process?

4. Where do you configure the process?

5. Into approximately how many parts can the ccBPM architecture be divided?Which individual components within this division can you name?

6. Familiarize yourself with the course exercise scenario.

Which adapter does the Integration Server use to receive the message forordering spare parts? The business system is called DMSCRM.





The receiver determination for the first message in the process is defined in theIntegration Directory using the entry DMSCRM | item_out. More than onegroup will be taking part in the scenario in the course. Each group has its ownprocess: SellspareParts_0##. How are the groups distinguished from each other?


Which inbound and outbound interfaces does the process use for spare partprocurement? To answer this question, use the process Solution_5.


Which message type and data type does the service interface item_out use?What does the message content describe?


Which second message type does the software component SellSpareParts containin relation to the spare part procurement scenario? How does this differ to thedata type from the last question?





Which mapping objects does the software component SellSpareParts recognize?



Solution 1: Answer the Following QuestionsAbout ccBPM

Task:Answer the following questions:

1. What is the purpose of ccBPM?

Answer: The purpose of ccBPM is to design, execute, and monitor automatedprocesses across different applications, systems, and company boundaries.

2. What standards can you use to exchange integration process definitions?ccBPM?

Answer: The export/import of process definitions can be done in the standardsBPEL4WS 1.1 and WS-BPEL 2.0.

3. Which object do you use for a cross-system business process?

Answer: You create an integration process in the Enterprise Service Repository.

4. Where do you configure the process?

Answer: You make configuration settings in the Integration Directory.

5. Into approximately how many parts can the ccBPM architecture be divided?Which individual components within this division can you name?

Answer: The ccBPM architecture consists of two parts. The design time(Enterprise Service Builder) and the runtime (Integration Server).


Which adapter does the Integration Server use to receive the message forordering spare parts? The business system is called DMSCRM.

Answer: No communication channel is defined under the business system in theIntegration Directory. The message is sent from the HTTP client directly to theadapter_plain service on the Integration Server, using the sender HTTP adapter.





The receiver determination for the first message in the process is defined in theIntegration Directory using the entry DMSCRM | item_out. More than onegroup will be taking part in the scenario in the course. Each group has its ownprocess: SellspareParts_0##. How are the groups distinguished from each other?

Answer: The message contains a process definition field. This field is connectedto the ProcessID context object in the definition of the message interface. In thereceiver determination, ProcessID stands for the receiver service.


Which inbound and outbound interfaces does the process use for spare partprocurement? To answer this question, use the process Solution_5.

Answer: Receiver interfaces: item_abstract, crea_po_abstract, crea_so_abstract

Sender interfaces: prep_sync_abstract, list_abstract, item_abstract,crea_po_abstract, crea_so_abstract


Which message type and data type does the service interface item_out use?What does the message content describe?

Answer: The message type is called SparePartLineItem. The data type is calledSparePartLineItem.

A single spare part is described in the message.


Which second message type does the software component SellSpareParts containin relation to the spare part procurement scenario? How does this differ to thedata type from the last question?

Answer: The second message type is called SparePartLineItemList. It describesa message with header data and a substructure containing the individual sparepart. This substructure comprises the fields from SparePartLineItem and canoccur more than once (0-unbounded).


Which mapping objects does the software component SellSpareParts recognize?

Answer: The mapping objects are called itemlist2list and list2itemlist. Thesenames apply to the objects of the operation mapping and the message mapping.



Lesson Summary




Related Information

• For more information about SAP NetWeaver Process Integration (SAP PI),see SAP course BIT400 and the SAP NetWeaver Process Integration 7.10.documentation.


Unit Summary BIT430

Unit SummaryYou should now be able to:









Unit 2Business Process Management:

Cross-Component BPM

Unit OverviewThis unit introduces the process editor, the design elements and the basics ofdeveloping integration processes with ccBPM.

At the conclusion of this unit, you will be able to

• Work with the graphical process editor

• Describe and implement the different step types

• Define and use correlation

• Define and use container elements in their context

• Describe common design patterns for integration processes

• Use the process patterns shipped by SAP in your integration processes

• Make targeted use of step groups


• Describe the graphical process editor


• Explain the different meanings of step types

• Explain and define correlations

• Define and use container elements

• Explain the step types transformation, send, control, and wait

• Explain the concept of exception handling in ccBPM

• Define exceptions in integration processes



• Define step groups


Unit 2: Business Process Management: Cross-Component BPM BIT430

• Use configurable parameters to improve the flexibility of your processes

• Explain step type receiver determination

• Explain and use step type fork

• Describe step type switch

• Illustrate step type user decision

• Use the modes ParForEach and ForEach in a block step

• Integrate user decisions into the process flow

Unit ContentsLesson: First Steps in ccBPM ... .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . 37

Exercise 2: Receiving Order Items (Introduction) . . . . . . . . . .. . . . . . . . . . .. . . . . . 51Lesson: Step Types (Part 1) and Correlation . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . 58

Exercise 3: Receiving Order Items (Collecting Items and Saving them inContainers) . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . 67

Lesson: Step Types (Part 2) and Exception Handling . . . . . . . . .. . . . . . . . . . .. . . . . . 76Exercise 4: Checking Materials in the SD System .. . . . . . .. . . . . . . . . . .. . . . . . 89

Lesson: Process Templates and Step Groups .. . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . .104Exercise 5: Creating a Step Group.. . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . 115Exercise 6: Test Your Knowledge .. . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . 119

Lesson: Step Types (Part 3) . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . .122Exercise 7: Creating Missing Materials in the MM and SD Systems .. .135


BIT430 Lesson: First Steps in ccBPM

Lesson: First Steps in ccBPM

Lesson OverviewThis lesson will provide you with a general overview of the graphical process editorand show you how to work with the tool.




Business ExampleYour company asks you to set up an integration process using SAP NetWeaver PI. Inorder to do this, you use the graphical process editor to design the process.

Graphical Process Editor AreasThe process editor is a graphical editor in the Integration Builder that enables you todefine and edit integration processes in the Enterprise Service Repository.

Figure 14: Graphical Process Editor



The editor is divided into individual sections: The sections are:

Main Menu

Shows the main menu and the standard application toolbar of the Enterprise ServicesBuilder.

Header Area

The Header area shows all the important header data, such as name, namespace,software component version, and a short description.

Edit Area

In the Edit area, the whole integration process is composed of several step types. Youcan switch between the following views:

• Graphical Definition

Define and design the integration process. The process flow can be displayedhorizontally or vertically.

• BPEL display

Displays the process as WS-BPEL- or BPWL4WS. Also offers the possibility toimport or export the integration process in this representation.

• Correlation Editor

Define and edit correlations.

Overview Area

The Overview area shows alternative representations of the integration process. Thefollowing views are possible:

• Process Overview

Gives a bird’s-eye view of the whole process. With the help of the orangerectangle, you can select special sections of the process. The size of the rectangle(zooming factor) is controlled by the scroll bar at the top of the overview area.

• Process Outline

Gives a hierarchical representation of the integration process. By right-clickingon a step, you can insert or delete steps.



Properties Area

The Properties area defines the properties of the currently selected step. The propertiesthat can be defined depend on the step type. Properties shown in bold italics can holdmore than one value line. For example, for the Exceptions property, you can definemultiple exceptions. Properties in bold that have a maximize or minimize icon canshow or hide their other entries. Mandatory properties are marked with a questionmark (?).

Output Area

The output area displays messages (errors, warnings, and so on) and the output offunctions. Switching is possible among the following views:

• Processing Log

Messages thrown by designing the process are shown.

• Tasks

Shows the result of the integration process check (F7).

• Search Results

Results of the step search are shown.

• WSDL Display

The Web Services Description Language (WSDL) description of data types,message types, and so on is shown (this view is only available if the BPELview is active in the Edit area).



Object Area

In this area the following views are possible:

• Container

Definition and editing of container elements.

• Correlation List

Used to create correlations.

• Process Signature

References the interfaces of the process.

• Configurable Parameters

Used to define parameters that you can then configure in the IntegrationDirectory. You use parameters like these, for example, to specify the agent fora user decision.

Personalization of the Process Editor

You can personalize the process editor according to your requirements. Your personalsettings become the default settings when the process editor is started. For example,you can show or hide particular screen areas or display the process definition vertically.



Figure 15: Process Editor: Personal Settings

To enlarge the visible part of the process definition, choose Detach and maximize thewindow.

To enlarge the properties area of the screen, choose Tools - Personal Settings. On thesubsequent screen choose Process Editor, Hide Output Area.

To enlarge the object area (container elements) part of the screen, choose Tools -Personal Settings. On the subsequent screen choose Process Editor, Hide Output Area.

Available Step Types and the Block Oriented ModelingParadigmAs mentioned earlier, step types can be divided into two sections: message-relevantsteps and control-relevant steps.



Message-relevant steps are:

• Receive

Receive message; can trigger the process

• Send

Send message synchronous or asynchronous/send acknowledgement

• Transformation

Split, merge, or convert messages

• Receiver determination

Get a list of receivers for subsequent send steps



The following are the control-relevant steps:

• Block

Combines steps that you want to have the same deadline or exception handler,or defines a local correlation.

• Switch

Defines processing branches based on conditions.

• Container Operation

Assigns values to elements / appends values to multiline elements.

• Control

Terminates process / triggers exceptions /triggers alerts.

• Fork

Defines independent processing branches.

• Loop

Repeat steps while a condition is TRUE.

• User Decision

At runtime, the user can decide in which processing branch an integrationprocess is continued.

• 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.

Your integration process is composed with the help of these step types.

The use of these steps will be explained later in more detail, but first we will providesome basic design principles to make it easier to use the design elements in the rightway and to create well-formed and faultless integration processes.

A block-oriented modeling paradigm is used within the tool for process modeling.This paradigm relates to well-known structured programming concepts. It basicallymeans that blocks are used to group several steps and to structure the integrationprocess. A block can be defined in sequence or nested within another block. However,a block cannot extend beyond any existing block boundaries; therefore, the outermostblock of a process is the process itself.



Figure 16: Block-Oriented Design in ccBPM

The block structure helps to design the process in a concise and comprehensible way.It also helps to avoid particular structural modeling errors, for example deadlocks,and permits hierarchical abstraction. Block hierarchy is the basis for the visibility andvalidity of container elements (data) used within a process.

Defining Configurable ParametersA configurable parameter is a parameter whose value you define in the integrationdirectory in the integration process component. This enables you to change thevalue without having to change the definition of the process. You can create severalconfigurations for a process, by specifying different values for a configurableparameter.

You define configurable parameters in a way similar to container elements. Forconfigurable parameters, you can define a default value as well.

Defining ConditionsYou can define conditions at various points in the process editor in order to control theprocessing depending on the event of the condition. At the corresponding points, forexample, in the definition of a multiple condition, the system automatically displaysthe condition editor. To make conditions easy to understand and follow you can insertcomments. Furthermore, you can show a where-used list for certain expressions.



Exception HandlingIn an integration process, situations can occur in which the integration process cannotbe continued normally (for example, when system errors occur) or normal continuationis not desirable. You can take into account situations like these already in the definitionof the process in the form of exceptions and the corresponding exception handlers.

Process Data and Container ManagementSince an integration process not only forwards messages but processes them as well,data needs to be saved. In this respect containers play a decisive role. Containers

• Define the data for a business process and enable data to be transferred betweenthe individual steps of the business process

• Consist of an unlimited number of container elements

• Carry the overall state of the process at runtime – references to messages, loopcounters, and so on

• Allow you to access data by a name relevant within the process

A process has to receive messages, collect them, check conditions, or increasecounters. To do all this, several step types are used. So that the step types can processdifferent data correctly, they need a description of the data; therefore, you define thedata as container elements. Compared to a programming language, container elementsare like variables. They are defined at design time and at runtime they containreferences to the particular data. To fit different types of data, several categories andtypes are available. Container elements can be typed to:

• Simple XSD (XML Schema Definition) types: XSD:date, XSD:time,XSD:integer, XSD:string

• Abstract Interfaces

• Receiver

For a container element that should refer to a message at runtime, you have to declarethe category as abstract interface and the type will refer to the respective abstractinterface. An abstract interface is defined within the service interfaces. It is only usedin integration processes, and the difference between an inbound or outbound messageinterface is that it is bi-directional. This means that it can be used as an outbound orinbound interface , depending on the situation within the integration process.

Hint: An integration process can only reference interfaces of the ownsoftware component version (SWCV).



Another category is the simple type. This category has four possible XSD types:string, integer, date, and time. It is used for process control elements for example, acounter that represents a simple type of XSD:integer.

The third possible category is the receiver. This is used for a receiver list, which isdetermined from a receiver determination step and can be used in a send step.

A container element can also be a list of container elements of the same type. Inthis case, you must set the multiline flag for the container element. An example ofsuch a list would be when you collect multiple messages and want to combine theminto one message.

Figure 17: Containers and Their Elements

The container elements can be assigned to certain blocks or to the whole process. Inthe container area, you define whether the elements belong to a block or a process.If you set the container on process, the container is valid and visible in the wholeprocess and it can be used in each block.



Figure 18: Visibility of Container Elements

If you set the container to a specific block, it would be only visible in this block or inany nested block within the specified block. A container element of an inner blockwould not be visible in the outer block. As soon as the container elements are defined,they can be used from the different step types.

Defining Step GroupsYou can summarize frequently used sequences of steps to a step group.

The grouping of steps to a step group enables you to recognize step groups again andimproves the clarity of the process design.

Correlation of MessagesIf the process contains further receive steps or the first receive step is part of a loop,you must correlate these messages with the message from the first receive step. Todo so, specify the correlations you want to activate. For each correlation, you mustspecify how you want the elements of the correlation container to be filled when thecorrelation is activated. You can use the whole process container for this purpose. Ifyou specify multiple correlations, then the message to be received must satisfy allcorrelations.

What does correlation mean?



During an integration process, it is often the case that messages with a contextare processed. An example may be a booking and a booking confirmation. Theconnection between these messages is described by a correlation.

Figure 19: Definition of Correlations

Figure 20: Use of Correlations



To clarify the need for a correlation, think of the following:

• A flight booking for a flight to Rome gets in the airline system and starts thebooking process. During this, the Business Process Engine creates an instance,holding the state of the process on the Integration Server. After sending the flightbooking request to Rome, the instance waits for a booking confirmation.

• Now a second flight booking is made, this time for a flight to Sydney. TheBusiness Process Engines starts the same process again and again waits for aconfirmation.

• The confirmation for the Rome flight comes back, but now the Business ProcessEngine has to know to which process instance to send this confirmation.

• Therefore a correlation is declared, so that the Business Process Engine canensure the correct delivery of the confirmation. In this case it would make senseif the messages are correlated by their unique booking order number.

Hint: SAP recommends that correlations are based on fields that are part ofthe message payload.

Recapitulation is a correlation is used to assign messages that belong together to thesame process instance. It defines how the Business Process Engine can recognizemessages belonging together. It is, therefore, a loose coupling of messages. To definea correlation, you have to declare all involved messages and the XML elements inwhich the messages match. Activation of a correlation can be done either in a receiveor send step.

Hint: Be sure that the correlation is defined unambiguously. If, for instance,a material number is used in more than one plant, the correlation has to bedefined using material number and the plant.

A correlation can be valid in the entire process and can be activated and used in theentire process.

Hint: However, correlations are usually only valid for a specified period oftime, for example, while messages are being collected. You can define acorrelation such as this as a local correlation; this is, is it assigned to a blockin the process. You will then only be able to activate and use the correlation inthis assigned block.



Start of an Integration ProcessAn integration process starts at runtime with a receiving step, referring to exactly onemessage. This step can be the first step in the process, or a step in a fork, block, orloop. If not starting with a receiving step, the fork, block, or loop must be the firststep in the process. A fork or a loop can be used for multiple receive steps, which arepossible in the following combinations:

• Receive steps arranged in series

The first receive step starts the process; afterwards, the other receive steps canreceive their messages.

The receive step can be the first step of the process or the first step in the firstblock of the process. The prerequisite for this is that the messages are sent fromthe sender systems to the process in exactly the specified order.

• Receive steps in a fork

The first receive step can be part of a step in a fork.

All receive steps that are ordered in parallel can start the process. With thisreceive method, it is possible to start the process with different messages.

• Receive step in a loop

The first receive step can be part of a loop step.

The receive step in the loop starts the process and will collect messages until theloop end condition is fulfilled.



Exercise 2: Receiving Order Items(Introduction)


• Open an integration process

• Check the initial status of an integration process

• Transfer an integration process from the Integration Repository to the IntegrationDirectory

Business ExampleYou want to acquire some spare parts from a non-SAP catalog/CRM system (simulatedin the exercise by an HTTP-client user interface).

You have created a business process and want to test the initial status.

To do so, you send a message from the HTTP-client user interface that is specified inthe Additional Information node in the Integration Builder in your training system.

Ensure that you send the message to your own process. The process ID is part ofthe message.

Task:Find your business process and check the environment.

1. Log on to the Integration Server (client 800) for your training system, call theEnterprises Services Builder, and start the Enterprises Services Repository. Youruser is BIT430-## (where ## is your group number).

The course instructor will provide you with the training system details.

2. Navigate to your business process SellSpareParts_0## in software componentSELLSPAREPARTS and display your process in the process editor. Your groupnumber is ##.

3. Which container elements are defined?

Check the interface of the defined object. What does the interface look like?

4. For an overview of your objects, create configuration scenario BIT430_##.(## stands for your group number).




Transfer your group-specific integration process to the Integration Directory. Asthe name, assign the name that the process has in the Integration Repository:SellSpareParts_0##. ## denotes your group number.

Insert the integration process in the configuration scenario BIT430_##.

5. Use the HTTP client to send an order item to the Integration Server and thencheck whether the order was received and processed correctly by SAP XI.Ensure that your integration process is specified in the Process Definition fieldin the HTTP client.

To access the HTTP Client, in the Integration Builder choose Additional Info→ Tools for BIT430.

Choose Order Spare Part Item.

Change the process definition to the name of your integration process andchoose SendItem.

6. Navigate back to your session with the Integration Repository and delete theDeleteMe receive step in your integration process. Save your integration process.



Solution 2: Receiving Order Items(Introduction)

Task:Find your business process and check the environment.

1. Log on to the Integration Server (client 800) for your training system, call theEnterprises Services Builder, and start the Enterprises Services Repository. Youruser is BIT430-## (where ## is your group number).

The course instructor will provide you with the training system details.

a) Log on to client 800 in your training system. Your user is BIT430-##.

b) Call transaction SXMB_IFR from the Process Integration folder.

c) Choose Enterprise Services Repository in the Enterprise Services Buildercontext.

Java Web Start will then start.

d) In the security warning dialog box choose Start.

e) Enter your user and password (BIT430-## and your changed password)and choose Log On.

2. Navigate to your business process SellSpareParts_0## in software componentSELLSPAREPARTS and display your process in the process editor. Your groupnumber is ##.

a) Once you are logged on to the Integration Repository, open softwarecomponent SELLSPAREPARTS.

b) Open SELLSPAREPARTS and go deeper in the structure untilyou reach your integration process: Choose SELLSPAREPARTS1.0 of education → SELLSPAREPARTS 1.0 of education →http://education.com/xi/BPM/Spareparts → Process IntegrationScenarios→ Integration Processes→ SellSpareParts_0##.

c) Display your integration process in the area on the right of the processeditor by double-clicking.

The graphical definition shows a start and stop step of the process andone receive step: deleteMe.

3. Which container elements are defined?




Check the interface of the defined object. What does the interface look like?

a) The Container part of the process editor contains the item containerelement with the category abstract_interface.

The referenced object is item_abstract.

b) To display the object, expand the Service Interfaces node under theSELLSPAREPARTS software component.

c) Double-click item_abstract. The message type used is SparePartLineItem.

d) Double-click the SparePartLineItem structure, which represents a messagethat relates to particular spare part.

Note that there is one element: ProcessDefinition. This element is used atruntime to define the receiver integration process.

4. For an overview of your objects, create configuration scenario BIT430_##.(## stands for your group number).

Transfer your group-specific integration process to the Integration Directory. Asthe name, assign the name that the process has in the Integration Repository:SellSpareParts_0##. ## denotes your group number.




Insert the integration process in the configuration scenario BIT430_##.

a) If you have not already done so, log on to the Integration Directory. Todo so, choose Integration Directory in the Enterprise Services Builder(transaction SXMB_IFR). Log on with user BIT430-## and your password.

b) Select the tab page Configuration Scenario, select an entry and choose theNew function from the context menu.

c) Enter the following:

Name of Configuration Scenario: BIT430_##

Description: Configuration scenario BIT430_##

Choose Create followed by Save.

d) Select the tab page Communication Component and open the IntegrationProcess section.

e) From the context menu, choose New. The Install Integration Processwizard opens.

Choose Continue.

The wizard shows you the integration processes that are available in theRepository.

f) Select your group-specific integration process SellSpareParts_0## (##stands for your group number). Add the integration process to yourconfiguration scenario BIT430_## and press the button Continue.

g) Accept the suggested process name from the repository. Next, chooseFinish, and once the integration process has been installed choose Close.

h) In the Integration Directory, in folder Communication Component openthe Integration Processes section. Your SellSpareParts_0## integrationprocess is displayed.

i) Open the configuration scenario section and choose BIT430_## from thelist of scenarios. Here, you also see your already assigned integrationprocess SellSpareParts_0##.

j) Navigate to the Change Lists tab page and activate your changes bychoosing Refresh in the context menu.

5. Use the HTTP client to send an order item to the Integration Server and thencheck whether the order was received and processed correctly by SAP XI.Ensure that your integration process is specified in the Process Definition fieldin the HTTP client.




To access the HTTP Client, in the Integration Builder choose Additional Info→ Tools for BIT430.

Choose Order Spare Part Item.

Change the process definition to the name of your integration process andchoose SendItem.

a) Open the HTTP client specified in the exercise.

b) In the Process Definition field in the HTTP client, insert the name of yourintegration process SellSpareParts_0##.

c) Choose SendItem. Your order is then sent to SAP PI.

d) Log on to the ABAP stack of the Integration Server and call transactionSXMB_MONI.

e) Check whether your order was correctly received by SAP PI.

There must be a message with the Sender Component “DMSCRM,” SenderInterface “item_out,” and the Receiver Component “SellSpareParts_0##”.

f) If you have received the message correctly and can see the log for yourintegration process, your integration process does not have any errors.

6. Navigate back to your session with the Integration Repository and delete theDeleteMe receive step in your integration process. Save your integration process.

a) Return to the session with the Integration Repository and the process editor.

Choose Display/Edit in your integration process.

b) Select the DeleteMe receive step.

c) Delete the receive step by choosing Delete in the context menu.

d) Check and save your integration process.

It is now not possible to activate. Activated integration processes requirea receive step.



Lesson Summary






Lesson: Step Types (Part 1) and Correlation

Lesson OverviewThis lesson introduces the step types block, receive, container operation, and loop. Italso explains the concept of correlation.





Business ExampleYou want to procure some spare parts from a non-SAP catalog/CRM system.

Since the non-SAP catalog/CRM system sends the spare part items in individualmessages, the process starts with a collect pattern. Three order items are combined inone message and then processed further in subsequent process steps.

To do this you have to learn the step types block, receive, container operation, andloop. You must also learn how to define and activate correlations.

Block StepBlock steps are basic design elements. Blocks can be nested. That is, you can definea visibility hierarchy of container elements, for example local variables and localcorrelations. Blocks are the basis for exception handling.

You can define the modes ParForEach and For Each. The mode ParForEachgenerates an instance of the block for each line of the multiline container element. Allinstances are processed simultaneously. You can use the ParForEach mode when youwant to send a message to multiple receivers simultaneously, for example.


BIT430 Lesson: Step Types (Part 1) and Correlation

Figure 21: Basic Definition of a Block

Definition of a Container Element and Step TypeContainer OperationA process has to receive messages, collect them, check conditions, or increase counter.So that the step types can process different data correctly, they need a description ofthe data. Therefore, you define the data as container elements.

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. If you assign a value to a single line ormultiline container element, this value overwrites the previous value. You can use thiscontainer operation to create a counter variable, as shown in the following figure.



Figure 22: Creating a Counter

The Attach operation type attaches a value to a multiline container element. Forexample, you can use this container operation to attach individual messages tomultiline container elements when collecting messages.

Definition of a Loop StepYou use a loop to repeat the execution of steps within the loop. The loop continuesto run while the end condition returns TRUE. To specify the end condition, use thecondition editor.

To open the condition editor use the icon from the input help of the Condition field .

Figure 23: Definition of a Loop



Definition of a Receive StepAs you already know, a receive step starts the integration process. It can be the firststep in the process.

Figure 24: Receive Step: Starting a Process

The receive step can also be the first step in a block, loop, or fork step that representsthe first step in the integration process.

Figure 25: Receive Steps in a Fork

A message is only assigned to one receive step, even if multiple receive steps arewaiting for a message from the same service interface.



In the following cases, multiple receive steps can wait for a message from the sameservice interface:

• Receive steps arranged one after the other

The first message that arrives is assigned to the first receive step, the secondmessage is assigned to the second receive step, and so on. Therefore, the firstmessage is not assigned to all receive steps that expect a message from thisservice interface.

• Receive step in a loop

If the process has not reached the receive step by the time the message arrives,the process receives the message and places it in a queue. As soon as the processreaches the receive step and the relevant correlation is active, the system assignsthe receive step to the oldest message in the queue. If the process reaches thereceive step but the queue is empty, 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 serviceinterface, an inbound message is only assigned to one receive step (at random).The remaining receive steps must continue to wait.

The behavior described above is known as the classic behavior of the BPE.

Furthermore, you can configure inbound processing with or without store temporarily.You can differentiate between the following in this Support Package and above:

1. Inbound processing with the With Buffering setting

2. Inbound processing with the Without Buffering setting

The With Buffering setting is the classic setting and also the default setting.

As described above, this means that an inbound message is assigned to a process witha matching correlation regardless of whether a receive step is active or not. If noreceive step is active, the message is 'parked' in a special queue that belongs to theprocess instance. When the corresponding receive step is reached, the system sendsthe first message from the queue that matches the relevant correlation.

In this setting, it can occur that messages from the buffer are not delivered because theprocess does not reach the receive step. This is the case, for example, if you collectmessages in a loop and then in the same block immediately transform the messages.

These messages are displayed under 'Not-Processed XML Messages' in the monitor.



However, if you select Without Buffering as the delivery form, when a messagearrives, the system checks whether it can be delivered or not. It cannot be delivered inthe following instances:

• Process with an active correlation has an error status

• Process with an active correlation is locked (queue is locked)

• Process has an active correlation but no active receive step

In such cases, the system proceeds as follows:

• If a message cannot be delivered as described above, the delivery attempt iscanceled before being retried n number of times following a defined retry period(transaction SMQR).

• If a message cannot be delivered due to an error, an exception is triggered thatstops the process-type-specific qRFC queue until the error has been corrected.

The Without Buffering setting affects the process design. You must note the followingwhen you define a process:

1. If messages can arrive in any order in the process, you must include a fork inthe process definition.

If in inbound processing with buffering you were able to use the parkingof messages to allow messages to be delivered to a process instance out ofsequence, changing the setting to inbound processing without buffering results ina strict interpretation of the receive sequence. Messages that are received tooearly block messages received later.

2. In an asynchronous request-response scenario that is expressed with a sendand subsequent receive step, you must ensure that the system behavior is'synchronous'. This means that the send step must be followed immediately bythe receive step.

3. Loops that collect messages must not contain any step types that interrupt thissynchronous behavior. An example would be if you were to collect messages ina loop and then immediately transform them.

The following step types interrupt synchronous behavior in integration processes:

• Send step

• Receive step

• Transformation

• Wait step

• Receiver determination

• Control step for triggering an alert



You define whether you want to apply inbound processing with or without bufferingin transaction SWF_INB_CONF.

Use transaction SXI_CACHE to locate the process type and then select the deliverymode.

Defining CorrelationsIf an integration process contains further receive steps you can correlate their messageswith the message from the first receive step. To do so, specify the correlations youwant to activate.

You can activate a correlation from either a receive step or a send step.

Figure 26: Defining Correlations

You can active a correlation for the whole process and use it throughout the process,too.

However, you can also restrict the validity of a correlation by assigning it to a blockas a local correlation. The local correlation is then only valid within the block; itcannot be activated or used outside the block to which it is assigned. Imagine thefollowing scenario:



You want to collect messages in a loop and then process them in a mapping in theintegration process. To collect the messages, you require an active correlation thatbecomes invalid when all the relevant messages have arrived. A correlation suchas this must not apply for the whole process and must therefore be assigned to aspecific block. The mapping (step type transformation) is then executed outside theblock that collects the messages.

To sum up, the following applies for correlations:

1. Define the correlation in the correlation editor

• The correlation must have a global name

• Give the required field or fields appropriate names

• Specify which messages are involved

• Specify which field in the message concerned is to be used as the referencepoint for the fields that you have defined in point 2 above

2. Activate the correlation

You can activate either at block level or globally. In the case of a block-localcorrelation, you must specify the name of the correlation in the Local Correlationfield when you define the block.

The correlation is normally activated in a send step, which sends a message andthen waits for a response. However, the correlation must also be activated if youcollect messages in a loop or in a fork.

3. Use the Correlations

Steps that receive response messages use correlations that were activated inthe relevant send step. Steps that collect messages in a loop or in a fork at thebeginning of a process also use correlations that were activated by the step itself.

Depending on how it is defined, the correlation applies either for the entireprocess or locally for a specific block.

4. You can display existing correlations in the system by using reportRSWF_CRL_MAINTAIN.





Exercise 3: Receiving Order Items(Collecting Items and Saving them inContainers)


• Create container elements

• Create block steps

• Create loop steps

• Create receive steps

• Use correlations

Business ExampleYou want to use a receive step to receive messages from a non-SAP catalog/CRMsystem. Three messages must be collected before the process can continue. You mustcollect multiple spare parts from a non-SAP catalog/CRM system and then combinethem in one single message.

Task:In a block with the name ReceiveOrderItemBlock, collect three messages from thecatalog system DMSCRM and bundle them in one single message.

Caution: You must confirm the entries by choosing RETURN.

If you do not do so the entries will be lost and you will have to enter themagain.

1. Insert the ReceiveOrderItemBlock block step in your integration process.

2. You want to receive three items in a loop. Define a container element with thename Counter to count the messages. Next, define the loop step by using thiselement in the end condition.

Set the category of the Counter container element to Simple Type, and the typeto xsd:integer. It is saved in the container of ReceiveOrderItemBlock.

3. Insert a loop step with the name ReceiveOrderItemLoop to receive 3 messages.Use the Counter container element to count the messages.




4. The messages are to be correlated from the Order Item message by means of thecustomer ID. The correlation must have the name CorrCustomer and must beassigned locally to the ReceiveOrderItemBlock block.

Create a correlation with the name CorrCustomer. Change the view for theContainer window and add the correlation. Then use the correlation editor.Insert IDCust of type xsd:string and assign CustomerNo from theitem_abstract interface to it.

5. Define the receive step to receive the message and to activate the correlation.This step starts the process.

Define the ReceiveOrderItem receive step for the Item message. The receivestep uses and activates the CorrCustomer correlation.

6. Increase your counter (+1).

Define a container operation step with the name RecOrderItemsCounterUpdatefor the Counter container element in the loop. The Counter simple variablemust be increased by 1 for each loop step.

7. You want to collect the individual messages in a multiline container element.First, define a multiline container element by using the interface of the message.

Create a multiline container element with the name itemlist, the typeitem_abstract, and the category abstract interface in the Process container.

8. Collect the individual messages in the itemlist container element you justdefined.

Define a container operation with the name RecOrderItemSelect to add a singleitem of the item container element to the item list in the itemlist containerelement.

9. Check, save, and activate the process.

Send three items to your integration process by using the HTTP-client userinterface.

10. Check the workflow log for your process.

Call transaction SXMB_MONI, create the following values, and then chooseExecute:

Section Sender - Service: DMSCRM

Section Receiver - Service: SellSpareParts_0##

Select your message and double-click PE in the Outbound column.




In the Workflow Log view, choose List with Technical Details. The result ofthe last action must be TRUE.



Solution 3: Receiving Order Items(Collecting Items and Saving them inContainers)

Task:In a block with the name ReceiveOrderItemBlock, collect three messages from thecatalog system DMSCRM and bundle them in one single message.

Caution: You must confirm the entries by choosing RETURN.

If you do not do so the entries will be lost and you will have to enter themagain.

1. Insert the ReceiveOrderItemBlock block step in your integration process.

a) Drag a block step to your integration process.

b) Enter theStep Name: ReceiveOrderItemBlock.

2. You want to receive three items in a loop. Define a container element with thename Counter to count the messages. Next, define the loop step by using thiselement in the end condition.

Set the category of the Counter container element to Simple Type, and the typeto xsd:integer. It is saved in the container of ReceiveOrderItemBlock.

a) Choose the Container window.

b) Enter name: counter, category: SimpleType, and type:xsd:integer. The container is ReceiveOrderItemBlock.

3. Insert a loop step with the name ReceiveOrderItemLoop to receive 3 messages.Use the Counter container element to count the messages.

a) Drag a loop step to the ReceiveOrderItemBlock block.

b) Enter the Step Name: ReceiveOrderItemLoop.

c) Use the input help for the Condition field. The condition editor opens.Select the Counter simple variable as the left operand. The right operand isconstant 3, type xsd:integer. Enter Does not equal for the operator.

Hint: Use the drag and drop function in the condition editor.




4. The messages are to be correlated from the Order Item message by means of thecustomer ID. The correlation must have the name CorrCustomer and must beassigned locally to the ReceiveOrderItemBlock block.

Create a correlation with the name CorrCustomer. Change the view for theContainer window and add the correlation. Then use the correlation editor.Insert IDCust of type xsd:string and assign CustomerNo from theitem_abstract interface to it.

a) Change the view for the Container window. Use the icons in on theleft-hand side of the screen at the top. Choose Correlation List. Insert theCorrelation Name: CorrCustomer.

b) Choose the Graphical Definition window. Use the icons in on the left-handside of the screen at the top. Choose Correlation Editor.

c) Insert the Name: IdCust, type: xsd:string in theCorrelationContainer area.

d) Insert the item_abstract service interface in the Involved Messagesarea.

e) Set the Value for IdCust in the Properties area. Use the input help. ChooseInterface Variable and XPath. Choose CustomerNo.

Hint: In the XPath expression, make sure that the Multilineselection field is not selected. This is necessary for all XPathexpressions that you create in correlations, and is also requiredwhen you use or activate a correlation in a send or receive step.

f) Navigate back to the Graphical Editor window.

Display the properties of the ReceiveOrderItemBlock block again. Selectyour correlation in the Local Correlation field.

The correlation is now only valid as long as the block is valid.

5. Define the receive step to receive the message and to activate the correlation.This step starts the process.




Define the ReceiveOrderItem receive step for the Item message. The receivestep uses and activates the CorrCustomer correlation.

a) Drag a receive step to the loop area.

b) Insert the Step Name: ReceiveOrderItem.

• Message: item

• Start Process: set

• Use Correlations: CorrCustomer

• Activate Correlation: CorrCustomer

6. Increase your counter (+1).

Define a container operation step with the name RecOrderItemsCounterUpdatefor the Counter container element in the loop. The Counter simple variablemust be increased by 1 for each loop step.

a) Drag a container operation step to the loop area.

• Step Name: RecOrderItemsCounterUpdate

• Target: Simple Variable counter

• Operation: Assign

• Expression: Simple Variable counter

• Operator: + +

• Expression: '1', Type xsd:integer.

7. You want to collect the individual messages in a multiline container element.First, define a multiline container element by using the interface of the message.

Create a multiline container element with the name itemlist, the typeitem_abstract, and the category abstract interface in the Process container.

a) Choose the Container window.

b) Insert the Name: itemlist, Category: Abstract Interface, Typeitem_abstract , Container: Process, and select the Multiline field.

8. Collect the individual messages in the itemlist container element you justdefined.




Define a container operation with the name RecOrderItemSelect to add a singleitem of the item container element to the item list in the itemlist containerelement.

a) Drag a container operation step to the loop area.

• Step Name: RecOrderItemSelect

• Target: Interface Variable itemlist

• Operation: Append

• Expression: Interface Variable item


Send three items to your integration process by using the HTTP-client userinterface.

a) Choose Integration Process → Check.

Possible errors are displayed in the Tasks area.

b) Use the HTTP-client to send three messages to your integration process.

10. Check the workflow log for your process.

Call transaction SXMB_MONI, create the following values, and then chooseExecute:

Section Sender - Service: DMSCRM

Section Receiver - Service: SellSpareParts_0##

Select your message and double-click PE in the Outbound column.




In the Workflow Log view, choose List with Technical Details. The result ofthe last action must be TRUE.

a) The List with Technical Details must look as follows.

Figure 27: List with Technical Details



Lesson Summary







Lesson: Step Types (Part 2) and Exception Handling

Lesson OverviewIn this lesson, you will learn about the step types transformation, send, control, andwait. We sill also discuss exception handling.





Business ExampleAt the end of this lesson you will check whether an ordered spare part exists in thecustomer's sales and distribution (SD) system. If not, we get back a response messagecontaining the information that the material must be created. The procedures is asfollows:

Once the spare parts have been collected in the itemlist container element, theintegration process converts the item list into a list (list container element), which isthen sent synchronously to the Airline_Group_One system. This represents the salesand distribution system. The response message contains the materials that must becreated.

If an application error occurs, an alert is triggered that you can check in the alert inbox.

If a system error occurs the process is terminated.


BIT430 Lesson: Step Types (Part 2) and Exception Handling

Definition of a Transformation StepYou use a transformation step for:

• 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 intothe individual 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

Figure 28: Step type Transformation

Since it is not very common that a message gets in and out in the same structure, themessage may need to be transformed. In such a case the transformation step is used.An operation mapping has to be defined and specified in the transformation stepfor all transformations.

If the sender and receiver messages need different formats (for example, different dateformats), you have to define an operation mapping with the corresponding valuemapping in the Enterprise Service Repository. The messages can then be processed.



Since no receiver information is available in the transformation step, there can beno value mapping here. If the messages to be transformed give values in differentformats, for example different date formats, you must first “normalize” the valuesbefore the messages can be processed in the process. To do so, define a messagemapping with a corresponding value mapping.

Attachments for n:1 and 1:n Transformation

• If the messages you want to bundle contain attachments, the system collectsthem and appends them to the bundled message. The source system must ensurethat the attachments each have a unique name. If this is not the case, the mostrecently received attachment will overwrite any attachments with the same name.

• If the message you want to split contains attachments, the system replicates theattachments and appends them to all the messages in the split.

Hint: Check, for each mapping, whether you can replace it with a mappingdone by the Integration Server.

In a transformation step, you should only define mappings that need the context ofthe integration process.

Exception Handling

You can enter an exception to be triggered when a system error occurs (permanenterror).

Send a MessageTo send a message, you have to define a sending step. Figure “Send a message -Asynchronous” shows the possible properties that can be set within this step.



Figure 29: Sending a Message: Asynchronous

Step Name and Mode

In a send step, you have to define a step name.

The mode of the send step can:

• Be asynchronous

• Be synchronous

• Send an acknowledgement

• Act as a closing step of a sync/async bridge

When sending in async mode, the step does not wait for a reply message from thereceiver after sending the message. However, you can specify that the asynchronoussend step must wait for a confirmation of receipt from the receiver, in the form of anacknowledgment.



For the acknowledgement you have the following options:

• None

The step is complete when the message has been successfully sent to theIntegration Server pipeline.

• Transport

The step waits for the transport acknowledgement. This shows that the messagefrom the adapter, which forwards the message to the target system was receivedsuccessfully.

• Application

The step waits for an acknowledgement from the application. This ensures thatthe message was processed successfully by the receiver application

Note that application acknowledgments are not possible with all forms ofcommunication. For more information about using acknowledgments togetherwith adapters, see SAP Note 837285.

The message receiver can be a business system or another integration process. Youhave various options for the receiver determination:

• Send Context (default)

The send context is a freely definable string, which you define in the send step.You query the send context in a condition in the receiver determination in theIntegration Directory. You must specify the send context if you want to sendmessages from the same message interfaces to different receivers in differentsend 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 elementthat contains the receiver list. The send step itself does not call the receiverdetermination which is configured in the Integration Directory. Instead it usesthe receiver list.

• Response message in reply to a previously received message

You specify the message to which the send step is to send a response. Thereceiver is determined from the message header of this message. In this case,the receiver determination that is configured in the Integration Directory isnot called.

• Conversation ID



You can specify a conversation ID in an asynchronous send step. You use thisID to indicate messages that semantically belong together. All messages withthe same ID in the message header belong to the same integration process.This mechanism is used together with the JMS adapter in the scenario withthe sync/async bridge.

You define a container element of type String for the conversation ID and thenspecify the element in the properties of the send step.

Caution: If you use the conversation ID in a correlation, theconversation ID must be set when you activate the correlation.

Furthermore, a correlation describes the connection of a receive step toexactly one single response message. One conversation ID is not usuallysufficient to establish this relationship.

• Queuing

You can use the Quality of Service EOIO in asynchronous scenarios. In this caseall the messages with the same queue name are sent in exactly the same orderthat they were sent in by the integration process.

For this purpose, define a queue name in the Queue Name field. A maximum of16 alphanumerical characters are permitted, including /, _ and -.

Figure 30: Sending a Message: Synchronous

Sending in sync mode causes the step to wait for a reply message from the receiverafter sending the request message. In a synchronous send step, you specify thesynchronous abstract interface for sending the request message and receiving the replymessage. Furthermore, you specify the container element referenced by the requestmessage and the container element in which the reply message is to be received. Thecontainer element type for the request message must be the same as the outbound



message interface of the synchronous interface. The container element type used toreceive the reply message must be the same as the inbound message interface of thesynchronous 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 whenthe corresponding fault message is received.

A synchronous send step waits for a reply message to be received. On receipt of thisreply message, correlations can be activated to correlate additional messages.

When sending an acknowledgement, a send step can send a positive or negativeacknowledgement for a particular message. A positive acknowledgement is usuallyused in a branch that defines the normal case. A negative acknowledgement is usuallyused in an exception handler. The receiver of the acknowledgement is automaticallydetermined from the header of the message for which the acknowledgement was sent.

Figure 31: Step Type Send: Acknowledgments

Definition of a Control StepYou can use a control step to:

• Terminate a current process

• Trigger an exception

• Trigger an alert for Alert Management



Figure 32: Step Type: Control

The Action field with the End Process value ends the current process instanceincluding all active steps and sets the status of the process to Logically Deleted. Thiscan be used in exception branches, for example.

The value Throw Exception of the Action property specifies an exception to betriggered. The relevant exception handler must be defined in the same block or in ahigher-level block. The system triggers the specified exception at runtime.

Exception HandlingDuring runtime, situations can arise where it is not possible and not recommendedto continue the integration process normally. You can catch such situations, such assystem errors, when you define exceptions and exception handlers.

The exception handler is the reaction to an exception in a separate processing branchof a block. You can insert a control step in the Exception Handler branch (see figureabove). This can trigger an alert or end the process, for example. The exceptionhandler has read and write access to all data within the block

Figure 33: Exception Handling



If an exception is triggered at runtime, the system first searches for the relevantexception handler in the block itself, then in the next block in the block hierarchy.When the system finds the correct exception handler, it stops all active steps in theblock in which the exception handler is defined and then continues processing in theexception handler branch. Once the exception handler branch has finished processing,the process is continued after the block.

If the system cannot find an exception handler for the triggered exception, it cancelsthe integration process with an error.

You can define multiple exceptions within a block. To trigger an exception, use thecontrol step that throws the corresponding exception. The process is then continued inthe corresponding exception branch. In a block you can define processing branchesas exception handlers. To insert an exception handler branch, call the context menufor the block step.

Note: You can insert every possible step type in an exception branch.

• Send step

Asynchronous or synchronous: can trigger an exception when a permanentsystem error occurs.

With a synchronous send step you can also define an exception for each faultmessage that is defined in the synchronous interface. This exception is thrownwhen the corresponding fault message is received.

• Transformation step

Can trigger an exception when a permanent system error occurs.

• Control step

You can use a control step to terminate the current process, or trigger anexception or an alert for Alert Management.



The following list summarizes how you define exception handling in a ccBPM process.

1. Define the required exceptions

Define the exception or exceptions using meaningful names in the propertiesof the blocks in which they belong.

2. Insert an exception branch

Insert an exception branch in the block for each exception. To do so, select theblock and choose Insert Exception Branch in the context menu.

3. Assign an exception to the exception branch

Select the exception branch and enter one of the exceptions that you definedin the block.

4. Define exception handling

In the exception branch, define the steps that are to be executed when theexception is triggered.

5. Trigger the exception in the process

Trigger the exception in the required step (send, transformation, control).

Alert ManagementWhen a certain situation occurs, an alert is supposed to be triggered by AlertManagement at runtime. To do so, you insert a control step at the requested point inthe definition of an integration process.

If the control step triggers an alert at runtime, Alert Management delivers the alert tothe respective user. The process is not terminated but continued after the control step.The user who is informed through the alert must then decide whether to intervene inthe process or not.

The control step with the value Throw Alert specifies the thrown alert message andthe alert category. The alert category must be defined in Alert Management. Theentered alert message will be displayed in the corresponding alert inbox. The systemtriggers the alert at runtime for the user defined in Alert Management. The processcontinues unchanged. The user who is informed by Alert Management must thendecide whether to intervene in the process or not.



Figure 34: Step Type Control and Viewing an Alert

Before you can trigger an alert, you must prepare accordingly:

• Alert Management must be activated for SAP NetWeaver Process IntegrationInfrastructure (transaction RZ21)

• You must define a corresponding alert category in which you specify alertparameters such as texts, expiry date, and so on. You have the following optionsfor defining alert categories:

– Define the alert category directly in the Enterprise Services Builder (ESBuilder).

The advantage is that you can define an alert container. In the alertcontainer you can specify which data from the integration process the usercan see in the short text of the alert.

– Define alert categories on the alert server

You can only use elements of the process container as variables in alertlong texts. New alert categories for alerts in integration processes shouldtherefore be defined in the Enterprise Services Builder. Alert categoriesthat have already been defined on the alert server can be used further.



Define alert category in the Enterprise Services Builder

1. Create an alert category. To do so, in the main menu, choose Object New.

2. Define the basic data of the alert, for example, the priority. To do so, proceed inthe same way as in the definition of an alert on the alert server.

3. Define the short text and the long text of the alert

To make the texts of the alert easier to understand, you can use containerelements as placeholders. At runtime, the container elements then show thevalues determined from the integration process.

4. Once the change list is activated, the alert category is deployed on the alert server.You can display it using transaction ALRTCATDEF but you cannot change it.

Define alert category on the alert server

An alert has two texts: a short text and a long text. The short text of the alertautomatically displays the ID of the process instance at runtime. You can define thelong text in the alert category or in the control step.

1. Choose transaction ALRTCATDEF.

2. Check whether you want to use an existing alert category or define a new one.

3. Decide whether you want to define the long text for the alert in the alert categoryor in the control step.

If you to specify the long text in the control step, you have to select the DynamicText field in the definition of the alert category.

To make the long text for the alert more meaningful, you can use alert textvariables that you populate with content from the payload. The variables refereither directly to an element in the payload, or to a newly-defined containerelement that a payload value was assigned to.

If you assign users to the alert category, they will receive the alert as soon as it istriggered. You must subscribe to any alerts that are not explicitly assigned toyour user under Alert Inbox in the Runtime Workbench.



This is how you define a control step for triggering an alert:

1. Open the integration process that is supposed to trigger the alert in the processeditor and insert a control step at the desired point in the integration process.

2. For the propertyAction choose the entry Throw Alert

3. Choose Integration Server or Alert Server in the Source field.

4. For the property Alert Category enter the requested alert category from AlertManagement or select it from the displayed container elements.

5. If you want to define the text that is output as an alert in the control step, enterthe desired text for the Alert Message property.

Hint: The prerequisite for displaying this text is that you have selectedthe Dynamic Text field in the definition of the alert category.

6. For alert categories on the Integration Server, the data flow is specified usingthe assignment of the container elements at runtime.

The container element must be defined as a simple XSD type. You cannotinclude tables in alerts.

Insert a container operation in the container element.

Enter the container element as &elementname& in the alert text.

If you want to refer to payload values directly, specify the path to the requiredfield in the alert text: &message.PAYLOAD.attribute&.

7. Specify the recipients for an alert category.

• You specify the recipients for an alert category. To do so, you use transactionALRTCATDEF even if you have defined the alert category in the EnterpriseServices Builder.

• Users subscribe to a certain alert category. You assign the authorization for thisin transaction ALRTCATDEF.

• You can subscribe to any alerts that are not explicitly assigned to your user underAlert Inbox in the Runtime Workbench.

• With the universal worklist of the SAP Enterprise Portal

• By using the application into which it is integrated, such as CRM or the SAP XIRuntime Workbench or the SAP NetWeaver Administrator.

• With SAP GUI by using transaction ALRTINBOX



Exercise 4: Checking Materials in the SDSystem


• Use a transformation step

• Use a synchronous send step

• Use exception branches

Business ExampleIf a material does not exist in the customer's sales system, it must first be created. Inthis exercise you use a synchronous call to check whether the material exists or not.The materials to be created are specified in the response to the synchronous call.

The procedure is as follows:

The order items are collected in the itemlist container element. The Preparation partof the integration process sends the materials to the SD system in a synchronous call.Inbound processing in the SD system checks whether the material exist. Any materialsthat do not exist in the system are specified in the response to the synchronous call.(You will create them in a later exercise.)

Furthermore, if the SD system does not recognize a material, an application erroris triggered in the alert inbox.

If a system error occurs the process is canceled.



Task:Execute a synchronous call to the SD system to check whether the missing materialshave to be created.

The response message contains the materials to be created. If a material does not existin the SD system, an application exception is created, that is, an alert is triggered. Youcan check this in the alert inbox.

Business System Airline_Group_One represents the SD system.

A mapping has already been created that you can use to transfer the Itemlist multilineelement, which contains messages, to the list element that contains header data and theunbounded Lineitems element. The name of the mapping is itemlist2list.

The synchronous prep_sync_abstract interface, which is used for sending for themessage contains a list of materials to be created. The response list is saved in thenew preplist container element.

The receivers of the send step are determined in the context of the SAP ProcessIntegration Infrastructure.

1. Minimize the ReceiveOrderItemBlock block that you created in the exercise inthe Step Types (Part 1) and Correlation lesson.

2. Define a new standard block, Preparation, with two exceptions: SystemErrorand ApplicationError.

3. The order items collected in the itemlist container element are transferred to thelist container element. First, define the new list container element followed bythe transformation step.

Create a new container element with the name list that references thelist_abstract abstract interface and that belongs to the process container.

4. Using the itemlist2list interface mapping, insert a transformation step with thename PrepTransformation. The source message is itemlist, the target message islist.

5. The call to the SD system is a synchronous call. The response, that is, the list ofmaterials that have to be created is saved in the preplist container element. Youhave to define this element.

Create a new container element with the name preplist that references thelist_abstract abstract interface and that belongs to the process container.




6. Insert the SendPreparation send step. Set the mode of the send step tosynchronous. The send step uses the prep_sync_abstract synchronous interface.The request message is list and the response message is preplist. CreateSystemError for the system-error exception, and ApplicationError for theapplication-error exception.

To determine the receiver, use the data for receiver determination that is definedin the Integration Directory.

7. Create the exception handling for the application and the system errors.

Using the context menu, add two exception branches for the SystemError andApplicationError exception handlers.

8. Call transaction ALRTCATDEF in the system and create a new alert categoryPROCESS_##. ## stands for your group number.

Enter Process Alert, Group ## as the alert description.

Assign your user to the alert category as a receiver.

Caution: Since multiple groups need to call transaction ALRTCATDEFat the same time, response times may be longer than expected.

9. In the exception handler, enter the PrepControlAppException controlstep for the ApplicationError exception. The control step should trigger an alertof alert type PROCESS_##. You can choose the alert message yourself. Anexample would be Preparation Checks Group ## failed. ## stands for yourgroup number.

10. In the exception handler branch for the SystemError exception, insert thePrepControlSysError control step to cancel the process.


12. Test the integration process by performing three different tests.

First variant: Test the situation where all three materials do not exist in theSD system.

Use the HTML client to send three individual items to your process. Check yourprocess by calling transaction SXMB_MONI_BPE.

Use the materials 1000, 2000, 3000 to test your process.

13. Second variant: Trigger an application exception. Use material 9999 as oneof your materials.




Open the HTML client again and send three individual items. Ensure that one ofthe items has the spare part number 9999. This causes an application error. Checkthe workflow log and your alert inbox. The workflow log should look as follows:

Figure 35: Workflow Log with Application Error

14. Third variant: Test the material check with two materials that do not exist andtake a look at the request and response message.

Execute the process again with the spare part numbers 2000, 3000, and 4000.Since the materials 1000, 2000, and 3000 are always marked as “missing” inthe system, the preparatory check creates a message that contains the spare partnumbers 2000 and 3000. To check this, call transaction SXMB_MONI andselect all the messages in which your process is the sender service. Select thelast send message and check that all the individual items in the request messagewere transferred to the preparatory check. To check the response, select themessages in transaction SXMB_MONI that have your process as the receiverservice and prep_sync_abstract as the receiver interface. The materials that areto be created in the next exercise are displayed.



Solution 4: Checking Materials in the SDSystem

Task:Execute a synchronous call to the SD system to check whether the missing materialshave to be created.

The response message contains the materials to be created. If a material does not existin the SD system, an application exception is created, that is, an alert is triggered. Youcan check this in the alert inbox.

Business System Airline_Group_One represents the SD system.

A mapping has already been created that you can use to transfer the Itemlist multilineelement, which contains messages, to the list element that contains header data and theunbounded Lineitems element. The name of the mapping is itemlist2list.

The synchronous prep_sync_abstract interface, which is used for sending for themessage contains a list of materials to be created. The response list is saved in thenew preplist container element.

The receivers of the send step are determined in the context of the SAP ProcessIntegration Infrastructure.

1. Minimize the ReceiveOrderItemBlock block that you created in the exercise inthe Step Types (Part 1) and Correlation lesson.

a) Choose ReceiveOrderItemBlock and Minimize from the context menu orchoose the minus sign at the top of the block on the left.

2. Define a new standard block, Preparation, with two exceptions: SystemErrorand ApplicationError.

a) Insert a block step after the minimized ReceiveOrderItemBlock block.

b) Switch to the Properties area.

c) Step Name: Preparation

d) Mode: Default

e) Exceptions: SystemError and, in a new line, ApplicationError

3. The order items collected in the itemlist container element are transferred to thelist container element. First, define the new list container element followed bythe transformation step.




Create a new container element with the name list that references thelist_abstract abstract interface and that belongs to the process container.

a) Switch to the Container view in the Object area.

b) Name: list

c) Category: Abstract Interface

d) Type: list_abstract

e) Multiline: not selected

f) Scope: Process

4. Using the itemlist2list interface mapping, insert a transformation step with thename PrepTransformation. The source message is itemlist, the target message islist.

a) Drag a transformation step to the Preparation block.


c) Step Name: PrepTransformation.

d) Operation Mapping: itemlist2list.

e) Source Messages → item_abstract: itemlist.

f) Target Messages → list_abstract: list.

5. The call to the SD system is a synchronous call. The response, that is, the list ofmaterials that have to be created is saved in the preplist container element. Youhave to define this element.

Create a new container element with the name preplist that references thelist_abstract abstract interface and that belongs to the process container.


b) Name: preplist.

c) Category: Abstract Interface.

d) Type: list_abstract.

e) Multiline: not selected.

f) Scope: Process.




6. Insert the SendPreparation send step. Set the mode of the send step tosynchronous. The send step uses the prep_sync_abstract synchronous interface.The request message is list and the response message is preplist. CreateSystemError for the system-error exception, and ApplicationError for theapplication-error exception.

To determine the receiver, use the data for receiver determination that is definedin the Integration Directory.

a) Insert a send step after the transformation step.


c) Name: SendPreparation.

d) Mode: Synchronous.

e) Synchronous Interface: prep_sync_abstract.

f) Request Message: list.

g) Response Message: preplist.

h) Receiver From: Send Context.

i) Exceptions → System Error: SystemError.

j) Exceptions → ApplicationFault: ApplicationError.

7. Create the exception handling for the application and the system errors.

Using the context menu, add two exception branches for the SystemError andApplicationError exception handlers.

a) Select your Preparation block.

b) Right-click the context menu.

c) Choose Insert→ Exception Branch.

d) Repeat the last step.

e) Select the uppermost exception branch and switch to the Properties area.

f) Enter SystemError as the value for the exception handler.

g) Repeat the last step with the second exception branch and enterApplicationError as the value for the exception handler.

8. Call transaction ALRTCATDEF in the system and create a new alert categoryPROCESS_##. ## stands for your group number.





Assign your user to the alert category as a receiver.

Caution: Since multiple groups need to call transaction ALRTCATDEFat the same time, response times may be longer than expected.

a) Call transaction ALRTCATDEF in the training system and switch tochange mode by choosing Display/Change.

b) Choose the Create Alert Category icon (white sheet of paper on theright-hand side of the screen).

c) Enter PROCESS-## as the alert category. ## stands for your group number.


d) Select the entry and choose the Fixed Recipient icon.

e) Choose New Entries and enter your user BIT430-## as the receiver.

f) Save your entries.

9. In the exception handler, enter the PrepControlAppException controlstep for the ApplicationError exception. The control step should trigger an alertof alert type PROCESS_##. You can choose the alert message yourself. Anexample would be Preparation Checks Group ## failed. ## stands for yourgroup number.

a) Drag a control step to the ApplicationError exception branch.


c) Name: PrepControlAppException.

d) Action: Throw Alert.

e) Alert Category: PROCESS_##.

f) Source: Alert Server

g) Alert Message: Preparation Checks Group ## failed.

10. In the exception handler branch for the SystemError exception, insert thePrepControlSysError control step to cancel the process.

a) Drag a control step to the SystemError exception branch.


c) Name: PrepControlSysError.

d) Action: Cancel Process.





a) Check, save, and activate the process.

12. Test the integration process by performing three different tests.

First variant: Test the situation where all three materials do not exist in theSD system.

Use the HTML client to send three individual items to your process. Check yourprocess by calling transaction SXMB_MONI_BPE.

Use the materials 1000, 2000, 3000 to test your process.

a) Open the HTML client.

b) Ensure that the process definition is SellSpareParts_0## (## stands foryour group number).

c) Send each item three times.

Use the materials 1000, 2000, and 3000.

d) Call transaction SXMB_MONI_BPE. Choose the message for yourSellSpareParts_0##. receiver service.

e) Double-click Process Selection and choose either Execute or press F8.

f) Select your process in the Work Item Type line under (Sub)Workflow, andin the Work Item Text line under SellSpareParts_0##.

g) Select the line by double-clicking. The workflow log should look asfollows:

Figure 36: Workflow Log (change!)

13. Second variant: Trigger an application exception. Use material 9999 as oneof your materials.




Open the HTML client again and send three individual items. Ensure that one ofthe items has the spare part number 9999. This causes an application error. Checkthe workflow log and your alert inbox. The workflow log should look as follows:





a) Open the HTML-Client.

b) make sure that you have choosen the prozess definition SellSpareParts_0##and ## is your group number.

c) Send three positions and change the spare part number at least once to9999.

d) Call the transaktion SXMB_MONI_BPE .

e) Select the Process Selection by Double Click by Double Click and Executeor chose F8.

f) Select your prozess in the line Work Item Type under (Sub)Workflow andin the line Work item text under SellSpareParts_0##.

g) Select the line by Double Clicking. The workflow protocol should lookas followed:


h) Call the Integration Builder (transaction SXMB_IFR) and navigate tothe Runtime Workbench.

i) Open the alert inbox. The alert you triggered is displayed.




14. Third variant: Test the material check with two materials that do not exist andtake a look at the request and response message.

Execute the process again with the spare part numbers 2000, 3000, and 4000.Since the materials 1000, 2000, and 3000 are always marked as “missing” inthe system, the preparatory check creates a message that contains the spare partnumbers 2000 and 3000. To check this, call transaction SXMB_MONI andselect all the messages in which your process is the sender service. Select thelast send message and check that all the individual items in the request messagewere transferred to the preparatory check. To check the response, select themessages in transaction SXMB_MONI that have your process as the receiverservice and prep_sync_abstract as the receiver interface. The materials that areto be created in the next exercise are displayed.

a) Open the HTML client.

b) Ensure that the process definition is SellSpareParts_0## (## stands foryour group number).

c) Send the individual items with the spare part numbers 2000, 3000, and4000 three times.

d) Call transaction SXMB_MONI.

e) Open the Monitor for Processed XML Messages.

f) Enter your process SellSpareParts_0## as the sender service andexecute the query.

g) Select the last message sent and display it.

h) The Maindocument payload of the inbound message should look as follows:




Figure 39: Request Message

i) Return to the Monitor for Processed XML Messages and create theSellSpareParts_0## process as the receiver service. Enterprep_sync_abstract as the name of the receiver interface. Ensurethat the value for the sender service has been deleted.

j) Execute the query.

k) Display the last message sent.

l) The Maindocument payload of the request message mapping should lookas follows:




Figure 40: Response Message and Mapping



Lesson Summary







Lesson: Process Templates and Step Groups

Lesson OverviewParts of an integration process can consist of a certain combination of steps,for example the collecting or sending of messages. For these frequently usedcombinations, SAP provides different patterns, which represent an abstraction fromwidely used integration process cases.

You can also summarize frequently used sequences of steps in a step group.






Business ExampleYou have to define an integration process within ccBPM. The integration processconsists of frequently used combinations of step types. You can save time designingthe process by using process patterns. The thus developed integration process shouldalso be made available to other teams as a reference process.

SAP Process PatternsSAP delivers 10 typical patterns as a standard package. The patterns are located inthe Enterprise Service Repository. Go to http://sap.com/xi/XI/System/Patterns andchoose SAP Basis→ SAP Basis 7.10.

Choose a step from the context menu or from the menu bar of the process editor.Insert→ Business Process After, to use a pattern in your own integration process.


http://sap.com/xi/XI/System/Patterns

BIT430 Lesson: Process Templates and Step Groups

Figure 41: Inserting a Pattern

Hint: SAP also ships example processes. You can use these as the basis fordefining integration processes. . Such an example process is available inSWCV SAP Basis→ SAP Basis 7.10

in namespace http://sap.com/xi/XI/Demo/Agency→MultipleFlightBookingCo-ordination.

Collecting Several Messages

For collecting several messages and merging them into one message, SAP providesthree patterns:

• Payload dependant (pattern: BpmPatternCollectPayload)

• Time dependent (pattern: BpmPatternCollectTime)

• When receiving a certain message (pattern: BpmPatternCollectMessage)

Additionally SAP provides patterns to collect messages from different interfaces.The collecting is stopped:

• If all messages are collected (pattern: BpmPatternCollectMultiIf).

• If a condition is met (pattern: BpmPatternCollectMultiIfCondition).

Stop collection payload-dependent



You have the option to collect multiple messages from one interface and bundle theminto one message, for example, individual purchase order items into one purchaseorder. To do so, you need to define a receive step within a loop.

Figure 42: Pattern BpmPatternCollectPayload

The process receives messages in a loop (see above figure). The first messagereceived triggers the process and activates the Correlation correlation by using an ID.Each subsequent message uses this correlation. The messages are received in thecontainer element CollectMessage. In the loop, the received messages are attachedto the multiline container element CollectMessageList. Once all the messages havebeen received, a transformation step bundles the messages collected in the containerelement CollectMessageList and from them creates a message in the container elementNewMessage. This message is then sent by a subsequent send step.

Each message that is received in the loop contains the number in the payload, whichrepresents the number of messages to be received. In the loop, a container operationcounts the counter Counter for the number of messages received. The loop continueswhile the number of messages received is not equal to the number of messages to bereceived.

Stop collecting time dependant

The loop for receiving the messages is defined as an infinite loop. The infinite loopforms a branch within a block. A deadline has been defined for the d. When thedeadline is reached, the process is redirected into the designated branch. A controlstep then triggers an exception in this branch. The relevant exception handler ends theblock and a subsequent send step sends the merged message.

Stop collecting by receiving a certain message



The loop for receiving the messages is defined as an infinite loop. The infinite loopforms a branch within a fork. A receive step is defined in a parallel branch to receivethe message that ends the process. The fork is complete when both branches returnTRUE. However, since the infinite loop always returns TRUE, the fork is onlycomplete when the message that ends the process is received.

Collecting messages from different interfaces

You have the option of collecting and bundling messages from different interfaces.To do so, define the corresponding receive step in a fork. The process of thepattern BpmPatternCollectMultiIf receives three messages from different interfacesin the container elements FirstMessage, SecondMessage, and ThirdMessage.Correspondingly, three receive steps have been defined within a fork (see figure).Each of the receive steps can start the process. For this reason, the Start Processindicator has been set for each of the receive steps.

Figure 43: Pattern BpmPatternCollectMultiIf

The first message received starts the process and activates the correlation Correlation.Each receive step uses this correlation. Once the messages have been received, atransformation step bundles the messages together and from them creates a messagein the container element NewMessage. This message is then sent by a subsequentsend step. To collect all messages, define that the fork is complete once all brancheshave been processed.

Collecting messages based on a condition

You can also specify that the collecting of messages stops when a particular conditionis fulfilled. Define a relevant end condition for the fork for this purpose. Then the forkis complete when one of the following conditions return TRUE.



Multicasting of Messages

SAP provides two patterns to send message to multiple receivers and wait for aresponse message from each of the receivers.

• Sending simultaneously (pattern: BpmPatternMulticastParallel)

• Sending one after the other (pattern: BpmPatternMulticastSequential)

The receivers are determined at runtime from the receiver D\determination that isconfigured in the Integration Directory. It is not necessary that you know the numberof receivers at design time.

Sequential

The process is started when a message is received in the receive step. A subsequentreceiver determination step calls the receiver determination that is configured in theIntegration Directory and gets the receiver list for the multiline container elementReceivers.

Figure 44: Pattern BpmPatternMulticastSequential

The container element Receivers is defined for dynamic processing. The containerelement Receiver is defined for the current line. This gets the individual receivers forwhich the block will be executed.

The block is defined as ForEach. Within the block, a send step sends the message tothe first receiver in the receiver list and creates the correlation Correlation. A receivestep uses a correlation and receives the response message from the first receiver. Ifthis receive step is complete, the message is sent to the next receiver in the receiverlist. The entire receiver list is processed in this way. So that the separate instancesof the correlations can be processed for each receiver, the correlation is defined as alocal correlation.



Each receiver sends a response message, which is received in the response containerelement. The sent message and the response message are linked by means of acorrelation. For example, the sent message might be a purchase. This purchase orderand the purchase order response might be correlated by a purchase order number.

Parallel

The block is defined as ParForEach. A block instance is generated for each receiverin the receiver list in which the following steps are executed: A send step sends themessage to the receiver and activates the correlation Correlation. So that a separateinstance of the correlation can be processed for the block instance, the correlation isdefined as a local correlation. A receive step uses this correlation and receives theresponse message from the receiver. The block is complete if all block instances thatwere generated in parallel are complete. In other words, the response message hasbeen received by all recipients in the recipient list.

Serialization

Serialization means defining the sequence in which a process sends received messages.

• One start message (pattern: BpmPatternSerializeOneTrigger)

• Multiple start messages (pattern: BpmPatternSerializeMultipleTrigger)

One start message

Three receive steps are defined in the process BpmPatternSerializeOneTrigger. Themessages are received in the container elements FirstMessage, SecondMessage, orThirdMessage. The process starts once the first receive step receives the message.For this reason, the Start Process indicator has been set for the first receive step.When a message is received, the receive step activates the correlation Correlation.This correlation is used by both subsequent receive steps and correlates the messagesby means of an ID.

Once all three messages have been received, the process sends the messages in reverseorder. Once it has sent a message, the process waits for acknowledgment from thereceiver before sending the next message.

Multiple start messages

Three receive steps are defined in the pattern BpmPatternSerializeMultipleTrigger.The corresponding messages are received in the container elements FirstMessage,SecondMessage, or ThirdMessage. Any of the three messages can start the process.For this reason, the Start Process indicator has been set for each of the receive steps.At design time it is not known which of the messages will arrive first. Therefore, thereceive steps are arranged in a fork (see figure). If one of the receive steps receivesits message, it starts the process and activates the correlation Correlation. This



correlation is used by both other receive steps. The fork must be completed as soonas all three messages have been received. Consequently, the number of requiredbranches is set to three.

Figure 45: Pattern BpmPatternSerializeMultipleTrigger

Finally, the process sends the received messages in the specified sequence. Each sendstep waits for corresponding acknowledgment once it has sent its message.

Sync/Async-Bridge Pattern

The pattern BpmPatternSyncAsyncBridge allows communication between asynchronous business system (BS-S) and an asynchronous business system (BS-AS).

Caution: You can only define one sync/async bridge per integration process.



Figure 46: Pattern BpmPatternSyncAsyncBridge

Defining a sync/async bridge:

1. Receive step SyncReceive: Receives the request message from the synchronousbusiness system BS-S and opens the sync/async bridge. The receive stepis the first step in the integration process. The receive step specifies thesynchronous interface BpmPatternBridgeSync for receiving the message fromthe synchronous business system. The integration process is started when themessage is received. The message type of the message to be received and therequest message from the synchronous interface must be identical.

2. Send Step AsyncSend: Sends the received request message asynchronously tothe asynchronous business system BS-AS.

3. Receive Step AsyncReceive: Receives the response message from theasynchronous business system BS-AS.

4. Send Step SyncSend: Sends the response message from the asynchronousbusiness system BS-AS synchronously to the synchronous business systemBS-S and closes the sync/async bridge.

The message type of the message to be sent and that of the response message from thesynchronous interface in the opening receive step SyncReceive must be identical. Inthe send step, enter the name of the receive step that opened the sync/async bridge(in this example, SyncReceive).



You can also reach the sync/async communication via the JMS adapter. If you haveno special monitoring or error handling requirements, we recommend using thesync/async communication of the JMS adapter. That way, an integration processcan be used to achieve significant improvements in performance in the syn/asynccommunication.

Hint: If you want to use a sync/async bridge together with the JMS adapter,you must enter the conversation ID in the send step. For more information,refer to the how-to guide How to Correlate JMS on SAP Service Marketplaceor the corresponding sections in the online help.

Defining Step GroupsGrouping steps to a step group offers the following advantages:

• Reusability

You define a step group once and can then insert it into other processes or use itseveral times within a process. Step groups are available globally (no SWCVrestrictions).

You can limit the changeability of the step group.

• Clarity

In the process definition in the process editor, you can show or hide the stepswithin a step group.



This is how you create a step group:

1. In the main menu, choose the following: Object→ New .

The create dialog is called.

2. In the Process Integration Scenario Objects folder, choose the object type StepGroup,

3. Insert the desired steps in the step group.

You can predefine some simple properties such as step names. However, since astep group does not have a container, you cannot predefine the properties thatreference container elements.

4. Insert the step group in the desired processes.

To do so, choose the step group from the context menu in the definition of therespective process.

Caution: You cannot insert a step group into another step group.

5. Supplement the required properties for the individual steps.

To do so, select the respective step via the menu in the properties pane

Hint: If you change a step group, these changes do not affect existingprocesses. The changes are only effective in the processes in which youinsert the step group after the change.

Defining Configurable ParametersA configurable parameter is a placeholder that is defined in the development of anintegration process. The value of the parameter is configured in the integrationdirectory in the integration process component. This enables you to change thevalue without having to change the definition of the process. You can create severalconfigurations for a process by specifying different values for a configurableparameter.

You define configurable parameters in similar fashion as container elements. Forconfigurable parameters you can define a default value in addition.

This is how you define configurable parameters:



Figure 47: Defining Configurable Parameters

1. In the object area of the process editor, define the configurable parameter view.

2. Define the name of the parameter and choose the selected category and type.

Agent: To specify the agent of a user decision

Simple type: For a configurable parameter that you use in conditions, forexample

Adapter: To specify a communication channel when programming a mappinglookup that you are using in a transformation step

3. Optional: You can define a default value for the configurable parameter.

In the integration directory, the default value is automatically used in theconfiguration of the corresponding process service as long as you are notconfiguring another value.

4. After activating the change list, you can configure the parameter in theintegration directory in the corresponding integration process component.



Exercise 5: Creating a Step Group


• Create a step group

Business ExampleYou want to standardize your development process and make a set of generic referenceprocesses available. These reference processes are defined as step groups.

Task:You want to create a generally usable solution for distributing the material informationto the SD and MM system.


2. Create a step group with the name Broadcast_##.

3. Insert a new SystemBroadcastPerMaterial block. Set the mode of the firststep to Default.

Hint: Please note that the names of the used steps are only updatedwhen the step group is used.

4. Insert a send step with the name SendMaterial in the SystemBroadcastPerMate-rial block. This step should send the message prepitem asynchronously

5. Insert a receive step ReceiveCreateMatResp.

6. Check, save, and activate the step group.



Solution 5: Creating a Step Group

Task:You want to create a generally usable solution for distributing the material informationto the SD and MM system.


a) In your SWCV SELLSPAREPARTS, select namespacehttp://education.com/xi/BPM/Spareparts and, in the context menu, chooseNew→ Process Integration Scenario Objects→ Step Group

2. Create a step group with the name Broadcast_##.

a) In the Name field, enter the name of the step group Broadcast_##.

3. Insert a new SystemBroadcastPerMaterial block. Set the mode of the firststep to Default.

Hint: Please note that the names of the used steps are only updatedwhen the step group is used.

a) Drag a block step into your step group.


c) Name: SystemBroadcastPerMaterial

d) Mode: Default

e) Block Start/End: New Transaction

4. Insert a send step with the name SendMaterial in the SystemBroadcastPerMate-rial block. This step should send the message prepitem asynchronously

a) Insert a send step in the SystemBroadcastPerMaterial block.


c) Name: SendMaterial

d) Mode: Asynchronous

e) All other fields are only filled when the step group is used.




5. Insert a receive step ReceiveCreateMatResp.

a) Insert a receive step after the SendMaterial send step.

b) All other fields are only filled when the step group is used.

6. Check, save, and activate the step group.

a) Save your process.

b) Check the process by pressing F7.

c) If no errors are found, activate the step group.





Exercise 6: Test Your Knowledge


• Insert a pattern into your integration process

• Differentiate between different kinds of SAP patterns

Business ExampleYou have to design an integration process and you have the option to use an SAPpattern.

Task:Answer the following questions.

1. What pattern categories are available for SAP Basis 7.10?

2. How can you insert a pattern in your integration process?

3. What is the function of the pattern BpmPatternCollectMultiIf?



Solution 6: Test Your Knowledge

Task:Answer the following questions.

1. What pattern categories are available for SAP Basis 7.10?

Answer: You can distinguish between collecting messages, sending to multiplereceivers (multicasting), performing serialization, and using a sync/async bridgepattern.

2. How can you insert a pattern in your integration process?

Answer: Choose a step from the context menu or from the menu barof the process editor. Insert → Business Process *, to use a pattern inyour own Integration Process. The pattern is located in the IntegrationRepository under SAP Basis → SAP Basis 7.10 in the namespacehttp://sap.com/xi/XI/System/Patterns.

3. What is the function of the pattern BpmPatternCollectMultiIf?

Answer: The first message type that is received by the integration processstarts the process and activates the corresponding correlation. Each receive stepof this pattern uses this correlation. Once the messages have been received, atransformation step bundles the messages together. This message is then sent bya subsequent send step.


http://sap.com/xi/XI/System/Patterns


Lesson Summary








Lesson: Step Types (Part 3)

Lesson OverviewThis lesson explains the step types switch, fork, and receiver determination, userdecision as well as step groups and the modes ParForEach and ForEach.








Business ExampleYou must create any ordered spare parts that are not in your SD system simultaneouslyin the SD system itself and in the MM system. To do so, you combine a block inParForEach mode with a block in ForEach mode that runs through a receiver list thatyou created previously (MM/SD system) as a loop.

Step Type ForkYou use a fork step when you want to continue a process in branches that areindependent of each other. The branches of the fork join in a union operator. Youcan specify the required number of branches and then define whether the process mustrun through all branches, or just a particular number of branches. You can also definean end condition for the fork.


BIT430 Lesson: Step Types (Part 3)

Figure 48: Step Type Fork

As soon as a branch reaches the union operator at runtime, the system checks thefollowing 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.

Assume, that your integration process contains a fork step with four branches. In eachbranch, a receive step waits for a message from different interfaces. If you wantto check whether a receive step has received its message, you have to compare thecontainer element in which the message is to be received with an empty containerelement.

Step Type SwitchYou use a switch step to define different processing branches for a process. TheOtherwise processing branch is created automatically. You define a condition with thecondition editor for each processing branch.



Figure 49: Step Type Switch

The condition is checked at runtime. The process is continued in the branch that isfirst to return the value true. If no branch returns the value TRUE, then the processis continued in the Otherwise branch. The system checks the conditions in the orderthat they are numbered. This corresponds to the following sequence: Vertical layout,selected in the process editor means from top to bottom, horizontal layout meansfrom left to right.

With the integrated condition editor you can now also use logical expressions asconditions.

Block step with ParForEach and ForEach Mode inCombination with a Send StepBlock steps are basic design elements.

In block steps, you can define the modes ParForEach and ForEach.

ParForEach mode generates an instance of the block for each line of the multilinecontainer element. All instances are processed simultaneously. You can useParForEach mode when you want to send a message to multiple receiverssimultaneously, for example.



Figure 50: Block Mode ParForEach

You use a receiver determination step to determine a multiline container element withthe list of receivers. Then you have to define that the message is sent to these receiversin a block with a send step (see figure). You specify the multiline container element inthe Multiline Element property. In the Current Line field, specify a container elementthat takes the value of the multiline container element for which the block will run.You can also define an end condition for the dynamic mode. The block is complete assoon as one of the lines of the multiline container element returns TRUE for the endcondition, or all lines of the multiline container element have been processed.

Hint: Using the ParForEach mode will not speed up the execution of processsteps. ParforEach mode does not result in different threads.

In ForEach mode, the block is first executed for the first line in the multiline containerelement, then for the send line, and so on. You can use the ForEach mode, forexample, if you want to send a message to multiple receivers one after the other.

Figure 51: Block Mode ForEach



Using a send step within a block with a ParForEach:

In a block with a ParForEach, the elements of a multiline container element areprocessed 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 messagefor each element of the multiline container element, then the send step can activate acorresponding correlation.

Checklist ParForEach Mode

ParForEach Mode is useful if the following conditions are given:

• The message is processed in the different branches.

• The processing of the messages does not overlap.

Receiver DeterminationYou use a receiver determination step to get a list of receivers for a subsequent sendstep. The receiver determination step calls the receiver determination that youconfigured in the Integration Directory and returns the receiver list.

The following figure shows the use of the receiver determination step. The receiverdetermination step gets the receiver list from the Integration Directory and the sendstep sends the messages parallel to the receivers.

Figure 52: Step Type Receiver Determination



In the receiver determination step, you specify the send context and the multilinecontainer element for the receiver list. The send context is an arbitrary string. Youquery this context in a condition in the receiver determination in the IntegrationDirectory. You must specify the send context if you want to send messages from thesame interface to different receivers in different send steps.

You can activate a correlation in a send step, and you can trigger an exception.

User DecisionIn practice, it can be necessary for a user to decide at runtime in which processingbranch an integration process is continued.

Decision Alternatives

To enable a user to make such a decision, insert a step of the user decision typecategory into the definition of the process. You then define the desired decisionoptions. The system inserts a processing branch for each decision option. Insert thedesired processing steps into these processing branches.

Notification at Runtime

At runtime, the intended user receives a dialog work item in the workflow inbox.This shows a corresponding button for each decision option that you have defined.If the user chooses one of the buttons, the system continues the integration processin the corresponding processing branch.

Local Variables

In a fashion similar to the one you know from alert management, you can use variablesin the definition of the texts that are displayed to the user at runtime.

At runtime, the system replaces these with the current data from the process. You canuse existing container elements as variables or define local variables. You use a localvariable to reference a certain field of a message. At runtime, the system replaces thelocal variable with the current content of the field. By specifying a text with thecorresponding local variables, you can illustrate the context of the decision to be madeto the agent, as you can see in the following example:

Note: "Of &msgt_total& requirement notifications only&current_msg_count& messages have been received before adeadline of &deadline&. How should the process be continued?"&msgt_tota&msgt_tota& can be, for example, a local variable that referencesa field of a message.



Caution: Please not that, in texts, you can only access the content of fields ofa message via local variables. You cannot enter an XPath directly in the text.

Configurable Parameters for Specifying the Agent

To specify which user is supposed to be notified at runtime, define a configurableparameter of the agent category and use this for the desired user decisions.

At configuration time, you assign the requested user to this configurable parameter inthe Integration Directory. This user thus becomes the agent for all user decisions inwhich the corresponding configurable parameter is used. This way, you can define theagent assignment centrally and do not have to adjust the individual user decisions ifchanges are made.

Hint: This user that is to be specified as the agent must be defined on theintegration server.

The procedure for defining a user decision is explained below.

1. Insert the User Decision step into your integration process

2. Specify an agent.

In the bottom part of the screen choose the Configurable Parameters view.

Define a parameter for the agent

Name: for example, Decider

Category: Agent

3. Define the texts for the user decision

4. Insert the requested variables at the corresponding points in the text

Hint: You can insert existing container elements into the texts asvariables or define local variables. For variables and local variables intexts, only simple XSD data types are permissible.

Additional Step Types: Undefined and WaitYou use a wait step to incorporate a delay in a process. Usually, you use a delay todefine when the next step in the process is to start. You can define the delay as a pointin time, or as a duration (see figure below). At runtime, the step waits until the pointin time is reached, or the specified duration has been exceeded. The system thencontinues the process by proceeding with the next step.



Figure 53: Step Type Wait

An undefined step has no influence on the process flow. You can use an undefinedstep for the following purposes:

• As a placeholder for a step that has not yet been defined

• As a step with no functions for test purposes

Date Monitoring in an Integration ProcessIf certain steps are supposed to be executed at a certain time, you can use the DeadlineBranch in a Block. A deadline specifies the last point in time that a block can beexecuted.

Figure 54: Deadline Monitoring



You can define the period until the deadline is reached as follows:

• The period and point in time when the step or process is generated

• Period and an arbitrary point in time that you specify as an expression

In a separate processing branch (deadline branch) you also define how the process isto react when a deadline is missed.

The deadline is checked by the system at runtime. If the deadline has been missed, theprocessing branch for the deadline is executed. This has no effect on the steps in theremaining processing branches in the block.

In the deadline branch you can trigger an exception or an alert for Alert Managementby using a control step, for example. The branch has read-from and write-to access toall data within the block.

The procedure for defining deadline monitoring is explained below.

1. Define a time-out exception for the block for which you want to define deadlinemonitoring.

2. Define the processing steps that must have been executed by a specified pointin time.

3. Insert a deadline branch in the block by using the context menu.

4. Define the points of reference (when time is measured from), and define howmuch time is available (deadline branch).

5. Insert a control step in the deadline branch

In the control step, trigger the exception that was defined in point 1.

6. Insert an exception branch that is assigned to the time-out exception.

In this branch, define the steps that are to be executed when the deadline ismissed.

Note: These steps in the monitored block are not performed automatically.

Once the exception branch has been executed, processing continues after themonitored block unless defined otherwise.

User DecisionIt is not always possible to fully automate integration processes. Using the UserDecision step type enables a user to decide at runtime in which processing branch anintegration process continues.

The system opens a new processing branch for each intended decision option. Insertthe desired processing steps into these processing branches.



At runtime, the intended user receives a dialog work item in the workflow inbox.This shows a corresponding button for each decision option that you have defined.If the user chooses one of the buttons, the system continues the integration processin the corresponding processing branch.

User Information at Runtime

In the definition of the texts that the user sees at runtime, you can use variables, justlike in Alert Management. At runtime, the system replaces these with the current datafrom the process. You can use existing container elements as variables or definelocal variables.

You use a local variable to reference a certain field of a message. At runtime, thesystem replaces the local variable with the current content of the field. By specifyinga text with the corresponding local variables, you can illustrate the context of thedecision to be made to the agent, as you can see in the following example:

" Of &msgtotal& requirements messages, only &counter& messages have beenreceived within a period of &deadline&. How should the process be continued?"(&msgtotal& can be, for example, a local variable that references a field of a message)

Hint: Please not that, in texts, you can only access the content of fields of amessage via local variables. You cannot enter an XPath directly in the text.

Procedure for Inserting User Decisions1. Insert a step of the user decision type at the desired point in the process and, in

the Step Name and Step Description fields, enter the texts that are supposed to bedisplayed for the step in the process editor.

2. In the bottom part of the screen, choose the Configurable Parameters view anddefine a parameter for the agent:

a) Name: Enter a name for the configurable parameter, for example,AgentUserDecision

b) Category: Choose Agent.

3. Define the desired texts by opening the text editor via the input help of thecorresponding field and entering the desired text in the upper part of the texteditor.

a) Display title: Text that the agent sees at the title of the user decision inthe dialog work item at runtime.



b) Display description: Text that the agent sees at the description of the userdecision in the dialog work item at runtime. In this text, describe what theuser is supposed to decide in the context of the user decision. You can alsooffer hints for subsequent processing.

c) Decision text: Text that the agent sees at the label of the button for thedecision option at runtime.

d) Outcome name: Texts that you see as the name of the processing branchin the process definition at the time of definition. The agent cannot seethis text at runtime

4. Insert the requested variables at the corresponding points in the text. You caninsert existing container elements into the texts as variables or define localvariables.

Caution: For variables and local variables in texts, only simple XSDdata types are permissible. Make sure that, using texts and variables,you provide the agent with sufficient information for making a decisionat runtime. Local variables that reference certain fields of a message areof particular importance

You have the following options for inserting an existing container element asa variable:

a) User the mouse to drag the container element to the requested point in thetext ○ Use Ctrl + Space to open a dropdown box and choose the containerelement.

b) Enter the name of the container element. In doing so, you have to enclosethe name in &,

To define a local variable, you:

a) Insert a new line into the bottom area of the text editor.

b) Enter a name of the local variable in the Name field and choose anappropriate simple XSD data type in the Type field.

c) You can define a default value that is used if the corresponding field of themessage is blank. To do so, enter the desired value in the Default field.

d) Enter a description for the purpose or use of the variable in the Descriptionfield. The properties pane now shows the local variable under localvariables.

e) In the properties pane, open the input help for the local variable and defineaccess to the respective field in the expression editor.

5. Release the change list and configure the agent of the user decision in theintegration process components in the Integration Directory.







Exercise 7: Creating Missing Materials inthe MM and SD Systems


• Use the condition editor

Business ExampleIn the preparation step in the integration process, the SD system returns a list ofmaterials that must be created in the system. The CreateMaterials element is in thelist_abstract interface. This element is set to YES if a particular material could not befound. You create the materials in the MM and SD systems. The Airline_Group_Onebusiness system is the SD system, and the Airline_Group_Two business system is theMM system. You create the materials by combining a block in ParForEach modewith a block in ForEach mode that runs through a receiver list from the receiverdetermination step type as a loop.

Task:You want to send the material or materials to be created to the SD system and theMM system almost simultaneously. Consequently, you require an independentmaterial with header and other material data. You then transfer the contents of thepreplist element to a multiline prepitemlist container element, which is based on theitem_abstract interface. You make this assignment in the list2itemslist mapping object.

Furthermore, you require the prepitem container element, which references exactlyone work item (which in turn represents a specific material).

Use the new SendmaterialsParallel block in ParForEach mode in combination withyour new prepitemlist and prepitem container elements to send the materials to thevarious different systems specified in the receiver determination step.

Define a correlation to correlate the messages that are returned from the SD and MMsystems. The correlation refers to the customer number and the spare part number.

The responses from the SD and MM systems are received in a receive step that usesthe create_matresp message and the CorrMaterials correlation.

1. Minimize the Preparation block and add a standard block with the nameCreateMaterials to it.




2. Insert a switch step with the name if to check whether materials need to becreated at all. The outcome name is MaterialsCreated.

The condition checks that preplist./p1:SparePartLineItemList/CreateMaterialsis set to YES.

3. You want to send the material to the SD and MM systems. You thereforeneed independent materials with header and business volume data. You musttransfer preplist to a new prepitemlist multiline element that is based on theitem_abstract interface.

Create this element and insert a transformation step in the next step.

In the CreateMaterials container, create a multiline element with the nameprepitemlist that is based on the item_abstract abstract interface.

4. Insert a transformation step with the name MaterialTransformation in branch1 of the switch step. The transformation is based on the list2itemlist operationmapping, the preplist source message, and the prepitemlist target message.

5. After the transformation step, insert a block with the nameSendMaterialsParallel.

Set the block mode of the block in the first step to Standard.

6. You want to send the materials simultaneously to your MM and SD systems. Forthis purpose, use the ParForEach block mode. You require a list of elements tobe processed, and an element that represents the current line each time.

Create a new container element with the name prepitem that is based on theitem_abstract abstract interface in the SendMaterialsParallel container.

7. Set the mode of the SendMaterialsParallel block to ParForEach. Use theprepitemlist container element as a multiline element. Use the prepitem containerelement as the entry for the Current Line.

8. You require a list of receivers to send the materials to.

Create a multiline element with the name Receivers (category Receivers) in thecontainer of the SendMaterialsParallel block.

9. Insert a receiver determination step with the name ReceiverDetermination inthe SendMaterialsParallel block. Set the Message property to prepitem, andthe Receivers property to Receivers.

10. Create a correlation with the name CorrMaterials as illustrated in the figurebelow:




Figure 55: Correlation Editor

11. After the receive step, insert the step group BROADCAST_##.

The step group was created in Default mode and is now adapted to the actual,individual case.

12. To switch to ForEach mode, create a container element with the name Receiver(category Receiver) in the SystemBroadcastPerMaterial block.

13. Now set the SystemBroadcastPerMaterial block to ForEach mode. ChooseReceivers for the Multiline Element property, Receiver for the Current Lineproperty, and CorrMaterials for the correlation.

14. Adjust the SendMaterial send step in the SystemBroadcastPerMaterial block.This step should send the prepitem message asynchronously, and then receivethe receivers from the Receivers list. Use the CorrMaterials correlation andreference CustomerNo and SPAREPART_NO for ID_Cust and ID_Mat.

15. You receive the response from each system in the create_matresp containerelement.

Create a container element with the name create_matresp in theSystemBroadcastPerMaterial container. It references the item_abstract abstractinterface.

16. Using the create_matresp message and the CorrMaterials correlation, adapt aReceiveCreateMatResp receive step.


18. Open your HTML client and send three individual items with the spare partnumbers 2000, 3000, and 4000. The resulting workflow should look as follows:




Figure 56: Workflow Log

Two materials - 2000 and 3000 - were created and the corresponding messagewas sent to two systems.



Solution 7: Creating Missing Materials in theMM and SD Systems

Task:You want to send the material or materials to be created to the SD system and theMM system almost simultaneously. Consequently, you require an independentmaterial with header and other material data. You then transfer the contents of thepreplist element to a multiline prepitemlist container element, which is based on theitem_abstract interface. You make this assignment in the list2itemslist mapping object.

Furthermore, you require the prepitem container element, which references exactlyone work item (which in turn represents a specific material).

Use the new SendmaterialsParallel block in ParForEach mode in combination withyour new prepitemlist and prepitem container elements to send the materials to thevarious different systems specified in the receiver determination step.

Define a correlation to correlate the messages that are returned from the SD and MMsystems. The correlation refers to the customer number and the spare part number.

The responses from the SD and MM systems are received in a receive step that usesthe create_matresp message and the CorrMaterials correlation.

1. Minimize the Preparation block and add a standard block with the nameCreateMaterials to it.

a) Open the integration process and switch to change mode.

b) Select the Preparation block from the last exercise and minimize it eitherby using the context menu or by choosing the minus sign in the topright-hand corner.

c) Insert a block step after the minimized Preparation block.

d) Switch to the Properties area.

e) Name: CreateMaterials

f) Mode: Default

2. Insert a switch step with the name if to check whether materials need to becreated at all. The outcome name is MaterialsCreated.




The condition checks that preplist./p1:SparePartLineItemList/CreateMaterialsis set to YES.

a) Insert a switch step to the CreateMaterials block.


c) Name: if

d) Outcome name: MaterialsCreated

e) Condition: (preplist./p1:SparePartLineItemList/CreateMaterials =YES).

The step should look as follows:

Figure 57: Condition

3. You want to send the material to the SD and MM systems. You thereforeneed independent materials with header and business volume data. You musttransfer preplist to a new prepitemlist multiline element that is based on theitem_abstract interface.

Create this element and insert a transformation step in the next step.




In the CreateMaterials container, create a multiline element with the nameprepitemlist that is based on the item_abstract abstract interface.


b) Name: prepitemlist


d) Type: item_abstract

e) Multiline: marked

f) Scope: CreateMaterials

4. Insert a transformation step with the name MaterialTransformation in branch1 of the switch step. The transformation is based on the list2itemlist operationmapping, the preplist source message, and the prepitemlist target message.

a) Insert a transformation step in branch 1 of the switch step.


c) Name: MaterialTransformation

d) Operation Mapping:list2itemlist

e) Source Message –> list_abstract: preplist

f) Target Messages –> item_abstract: prepitemlist

5. After the transformation step, insert a block with the nameSendMaterialsParallel.

Set the block mode of the block in the first step to Standard.

a) Insert a block step after the transformation step in branch 1.


c) Name: SendMaterialsParallel

d) Mode: Default

6. You want to send the materials simultaneously to your MM and SD systems. Forthis purpose, use the ParForEach block mode. You require a list of elements tobe processed, and an element that represents the current line each time.




Create a new container element with the name prepitem that is based on theitem_abstract abstract interface in the SendMaterialsParallel container.


b) Name: prepitem




f) Scope: SendMaterialsParallel

7. Set the mode of the SendMaterialsParallel block to ParForEach. Use theprepitemlist container element as a multiline element. Use the prepitem containerelement as the entry for the Current Line.

a) Select the SendMaterialsParallel block and switch to theProperties area.

b) Mode: ParForEach

c) Multiline Element: prepitemlist

d) Current Line: prepitem

8. You require a list of receivers to send the materials to.

Create a multiline element with the name Receivers (category Receivers) in thecontainer of the SendMaterialsParallel block.

a) Switch to the Container area.

b) Name: Receivers

c) Category: Receiver

d) Multiline: selected

e) Scope: SendMaterialsParallel




9. Insert a receiver determination step with the name ReceiverDetermination inthe SendMaterialsParallel block. Set the Message property to prepitem, andthe Receivers property to Receivers.

a) Insert a receiver determination step in the SendMaterialsParallel block.


c) Name: ReceiverDetermination

d) Message: prepitem

e) Receiver: Receivers

10. Create a correlation with the name CorrMaterials as illustrated in the figurebelow:




Figure 58: Correlation Editor

a) Switch to the Correlation List view in the Object area.

b) Enter a new correlation name: CorrMaterials.

c) Navigate to the Edit area and switch to the Correlation Editor view.

d) Change the Correlation Name to CorrMaterials.

e) Navigate to the Correlation Container field.

f) Enter two new values: ID_Cust type xsd:string and ID_Mat typexsd:string.

g) Navigate to the Involved Messages field.

h) Select the item_abstract message.

i) Switch to the Properties area.

j) For ID_Cust, select the value Interface./p1:SparePartLineItem/Cus-tomerNo.

k) For ID_Mat, select the value Interface./p1:SparePart-LineItem/SPAREPART_NO.

11. After the receive step, insert the step group BROADCAST_##.

The step group was created in Default mode and is now adapted to the actual,individual case.

a) Select the ReceiverDetermination. Use the context menu (right-click) toinsert the step group BroadCast_##.

b) Name: SystemBroadcastPerMaterial

c) Mode: Default




12. To switch to ForEach mode, create a container element with the name Receiver(category Receiver) in the SystemBroadcastPerMaterial block.

a) Switch back to the Container view in the Object area.

b) Name: Receiver

c) Category: Receiver

d) Multiline: not selected

e) Scope: SystemBroadcastPerMaterial

13. Now set the SystemBroadcastPerMaterial block to ForEach mode. ChooseReceivers for the Multiline Element property, Receiver for the Current Lineproperty, and CorrMaterials for the correlation.

a) Select the SystemBroadcastPerMaterial block and switch to the Propertiesarea.

b) Mode: ForEach

c) Multiline Element: Receivers

d) Current Line: Receiver

e) Local Correlations: CorrMaterials

14. Adjust the SendMaterial send step in the SystemBroadcastPerMaterial block.This step should send the prepitem message asynchronously, and then receivethe receivers from the Receivers list. Use the CorrMaterials correlation andreference CustomerNo and SPAREPART_NO for ID_Cust and ID_Mat.

a) Select the send step in the SystemBroadcastPerMaterial block.


c) Add the message: prepitem.

d) Receiver From: Receivers List

e) Receiver: Receiver

f) Activate Correlation: CorrMaterials

g) ID_Cust: prepitem./p1:SparePartLineItem/CustomerNo

h) ID_Mat: prepitem./p1:SparePartLineItem/SPAREPART_NO

i) Leave the Queue Name (EOIO) and Conversation ID fields empty.

15. You receive the response from each system in the create_matresp containerelement.




Create a container element with the name create_matresp in theSystemBroadcastPerMaterial container. It references the item_abstract abstractinterface.


b) Name: create_matresp




f) Scope: SystemBroadcastPerMaterial

16. Using the create_matresp message and the CorrMaterials correlation, adapt aReceiveCreateMatResp receive step.

a) Select the receive step after the SendMaterial send step.


c) Name: ReceiveCreateMatResp

d) Choose the message: create_matresp

e) Use Correlations: CorrMaterials


a) Save your process.


c) If no errors are found, activate the process.

18. Open your HTML client and send three individual items with the spare partnumbers 2000, 3000, and 4000. The resulting workflow should look as follows:





Two materials - 2000 and 3000 - were created and the corresponding messagewas sent to two systems.

a) Open your HTML client and check that your process is entered in theProcess Definition field.

b) Send three individual items with the spare part numbers 2000, 3000,and 4000.

c) Call transaction SXMB_MONI_BPE.

d) Select the last workflow sent and open the workflow log.



Lesson Summary









BIT430 Unit Summary





















Unit Summary BIT430


Unit 3Business Process Management:

Execution and Troubleshooting

Unit OverviewThis lesson provides fundamental information about the Business Process Engine andthe procedure for monitoring the runtime cache. You will also learn how to use thevarious monitoring transactions in SAP PI.


• Explain the relationship between integration processes in SAP PI and workflowsin SAP Business Workflow

• Check the runtime version of an integration process in the SAP PI Runtime Cache

• Perform process and message monitoring

• Perform basic troubleshooting

• Use transaction SXMB_MONI_BPE

• Monitor workflow executions

• Use the workflow log

• Display and edit work items

• Implement monitoring processes

• Navigate to the involved messages of and

• Check the status of synchronous/asynchronous communication

Unit ContentsLesson: Business Process Engine: Overview and Runtime Cache.. . . .. . . . .153

Exercise 8: Creating a Purchase Order and Sales Order .. . . . . . . . . .. . . . .165Exercise 9: Creating a Purchase Order and Sales Order -Enhancement . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . .177

Lesson: Process Execution Monitoring . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . .185


Unit 3: Business Process Management: Execution and Troubleshooting BIT430

Lesson: Message Monitoring. . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . . .. . . . .198Exercise 10: Sending a Purchase Order to a Supplier . . . .. . . . . . . . . . .. . . . .203


BIT430 Lesson: Business Process Engine: Overview and Runtime Cache

Lesson: Business Process Engine: Overview and RuntimeCache

Lesson OverviewThis lesson will provide you essential information about the Business Process Engineand how to monitor the Runtime Cache.






Business ExampleYou want to know more about the relationship between the Workflow Engine and BPE.

You also want to know which transactions to use to administrate BPE.

Business Process Engine: OverviewThe Business Process Engine (BPE) is part of the Integration Server. The BPE has thefollowing characteristics:

• Provides runtime support for integration processes

• Uses the runtime engine of Web AS 7.10 Business Workflow for ccBPMprocesses (not a Java engine)

An Integration Process defined in SAP PI ccBPM generates an SAP standardworkflow.

Caution: Unique step types in SAP PI ccBPM do not exist in the normalworkflow definition environment. There are also step types that are importantfor business workflows, but which are not available for ccBPM processes.



When an integration process is executed, the system creates corresponding workitems, just like during the execution of an SAP Business Workflow. A work item canrepresent a process or a step in a process.

When an integration process is executed, the system creates corresponding workitems, just like during the execution of an SAP Business Workflow. As in BusinessWorkflow a work item can represent a process or a step in a process. You can use thetransactions for monitoring the Business Process Engine to display the generatedwork items in the workflow log and display detailed information about the status of aprocess or the individual steps.

If SAP PI workflows are triggered by events, the background user (generallyWF_BATCH) logs into the system and starts the workflow.

Figure 60: ccBPM: An Example Process Definition

The figure above shows an example of an integration process in the Enterprise ServiceRepository:

The process collects messages in a loop. As soon as you have added the process to theIntegration Directory and activated it, a workflow is generated.

The following figure shows the workflow that is generated from the ccBPM processdefinition.



Figure 61: Workflow Process Generated from ccBPM Process Definition

You can display this workflow by calling transaction SWDD or SXI_CACHE. It isstored in the database as a workflow template (WS) with a number, for example,WS74900023.

Caution: Some icons are identical whether they are in a ccBPM process ora classic workflow. There are also ccBPM step types that are converted toworkflow step types. These include the transformation step, for example,which becomes an activity step. A receive step becomes Wait for Event.

Runtime Behavior of the BPEThe runtime behavior of the BPE can be controlled using various parameters.

• Delivery mode

is a runtime component that supplies messages to integration processes readyto receive messages or that starts new instances of integration processes ifnecessary.

You can now choose between two settings for delivery mode:

– Classic setting (default): Inbound processing with buffering

– Inbound processing without buffering



• Prioritization

You can configure the qRFC queue that is assigned to a certain process typeindividually. For example, you can specify on which server the qRFC queue of aparticular process type is to be processed. This allows you execute the qRFCqueue of a particularly time-critical process type on a particular server.

• Transactional behavior

You can use the definition of an integration process in the process editor toinfluence the transactional behavior at runtime. This enables you to attainperformance improvements.

A transaction is a sequence of processing steps that is either executed completelyor not at all. If a transaction cannot be executed completely, the system undoesall processing steps within the transaction. This means that the condition beforethe start of the transaction is restored.

• Message Packaging

The message packaging in BPE improves performance by delivering severalmessages to BPE process instances within one transaction.

• Start and stop BPE

To determine whether the BPE is started, or to start or stop it in a controlled way,use transaction SWF_XI_ADM_BPE.

Hint: To display the status of the BPE, you need the roleSAP_XI_BPE_MONITOR_ABAP.

To display the status of the BPE, you need the roleSAP_XI_BPE_ADMINISTRATOR_ABAP.

Hint: For detailed information, see also Unit 4, lesson BPE PerformanceManagement

Deletion of Runtime Versions

When you delete a runtime version, the corresponding workflow task is also deleted.

Caution: You must not delete any runtime versions in a productive system.

Problems will occur if you delete a runtime version of a process instance for a taskthat is running. The system does not perform any checks.



Even in a test system, only delete a runtime version if no process instances exist atthe time.

Runtime cache

You can display and analyze the runtime version of an integration process in theruntime cache. This can be useful in an error situation, for example, when anintegration process could not be started.

In the user menu, choose Process Integration→ Configuration→ SXI Cache→Integration Directory Cache (or use transaction code SXI_CACHE).

If the content of the cache is currently being updated (yellow status traffic light),wait until the cache update is complete. If you do not, you may accidentally lock abusiness process.

The system creates the runtime version from the definition of the integration processin the Integration Repository, and creates the entries for the service and party in theIntegration Directory. This happens as soon as you activate the change list in theIntegration Directory. If the runtime version was created without errors, it is processedby the Business Process Engine.

Figure 62: Creating a Runtime Version in the SAP XI Cache

The Runtime Cache screen shows all the workflows that have been generated. Youcan see the actual WS number that is assigned to the new workflow.



Figure 63: Runtime Cache: Details

To display the process definition, select the runtime version and click the icon withthe quick info Display Active Version. The process definition is displayed in theProcess Builder.

The Process Builder has a similar structure to the SAP Business Workflow WorkflowBuilder. It is specially designed for displaying integration processes. You cannot makeany changes to the process definition in the Process Builder.



The screen area on the right displays the following information for each runtimeversion:

• Partner and service from the Integration Directory.

• XML representation of the runtime version of the integration process. To displaythe XML representation in a clearer, more structured way, double-click a line.

• Workflow task

During processing by the Business Process Engine, the runtime version of theintegration process is represented by a workflow task. You do not normally needto know the number of the task; however, you can use the number to searchfor a task, for example.

• SAP Web AS release that was being used when the cache was updated.

• Date and time of last update.

• Return code for the creation of the runtime version.

The return code 0 of an integration process means the runtime version of the integrationprocess was created without errors. If it does not equal 0, then errors occurred. Youcan update the runtime version and then analyze the error messages. When you do so,the system displays detailed messages about the problems that occurred.

Figure 64: Error Handling in the Cache



You can also save the XML output as a file, which you can then pass on to SAPSupport for further analysis.

If a return code other than 0 is displayed in the runtime cache for a runtime version,update the cache. To do so, click the icon with the quick info Repeat Activation. Whenyou do so, the system displays detailed messages about the problems that occurred.

Figure 65: Error Message: Repeat Activation

Once the change is fixed in the Integration Repository and the changes are activated,the workflow should no longer have syntax errors and transaction code SXI_CACHEshould no longer have a bad return code.

Whenever you have a bad return code, you can do a syntax check on the generatedworkflow. In the workflow definition, there is a Syntax check icon. You can also checkthe syntax by choosing Workflow→ Check Syntax from transaction code SWDD.After the syntax check you will receive any existing errors.

Caution: You cannot make changes to workflows that are generated fromIntegration Builder activities.



If an error code is displayed in the runtime cache, check the integration process in theEnterprise Service Repository for the following possible causes:

• Conditions

Are the defined conditions valid? At present, the condition editor cannot ensurethat a condition does not contain invalid comparisons, such as comparisonsbetween different data types, for example, xsd:date and xsd:time, or comparisonsbetween single and multiple expressions.

• Correlations

Is every activated correlation actually used?

• Customizing

Incomplete customizing check with transaction SWF_XI_CUSTOMIZING.Every customizing item must have status green.

Transactions for Customizing the Business ProcessEngineCustomizing of the BPE is done in ccBPM in two variants:

• Basic customizing of the Business Process Engine (transactionSWF_XI_CUSTOMIZING)

• Advanced customizing of the Business Process Engine (transactionSWF_INB_CONF)

You have to perform basic Customizing of the Business Process Engine to startand execute ccBPM processes in an SAP PI system. The relevant transaction isSWF_XI_CUSTOMIZING. The system can execute customizing almost completelyautomatically (Button Automatic Workflow Customizing). Normally, this Customizingis done in the course of installing SAP PI.

Advanced Customizing refers to the configuration of inbound processing formessages. It takes place in transaction SWF_INB_CONF.

Hint: See also unit 2, lesson Step Types (Part 1) and Correlation

For the delivery mode for messages, you can choose between Buffering Possible(classic setting and default value) and Without Buffering.



Inbound processing delivers an inbound message to a running process instance or usesthe inbound message to start a new process instance. Unless there are process-relatedreasons, we recommend using the Without Buffering setting.

If you select this form of processing, the qRFC entry returns an error if a message isto be delivered to a process, but the process does not contain an active wait step atthe time of delivery. The message stays in the qRFC queue, inbound processing isstopped for the process type, and the qRFC queue is marked as containing an error.

To select the Without Buffering setting, the following prerequisites must be met:

• The process must process messages in the same order that they are delivered.

If you receive messages from different systems at different, unpredictable times,but these messages are to be processed in a particular order, you must pack thereceipt of messages in forks, which must all be processed before the processcan continue.

• If a message has been received, the steps must be executed synchronously beforethe next receive step. This is not the case if you use the following step types:transformation, send, receiver determination.

You can make the setting for inbound processing separately for each process type(workflow template) and client.

Proceed as follows:

1. In transaction SXI_CACHE, determine the internal workflow key of yourccBPM process (WSxxxxxxxx).

2. Make sure that the qRFC queue is locked for the process type and has no entrieswith error status.

Call transaction SMQ2. The name of the queue is composed as follows:QBQO$PE_<task> or XBPE_<task>.

3. Change the entry in transaction SWF_INB_CONF for the required process types.

Once you have saved a new entry, the affected queue (XBPE_<task>) is registeredautomatically.

Caution: Do not use the entry Without Buffering (Obsolete). It refers to aprocessing form which was replaced by the strategy Without Buffering.



Transactions for Administration of Processes in theBusiness Process EngineThe following transactions are for administration in the Business Process Engine:

• Start and stop the BPE: SWF_XI_ADM_BPE

• Restart processes with errors: SWF_XI_SXPR

• Restart processes after system crash: SWF_XI_SWPC

You can use transaction SWF_XI_ADM_BPE to display the status of variouscomponents (such as deadline monitoring, event processing) of the Business ProcessEngine and explicitly stop and start the BPE.

Hint: You need role SAP_XI_BPE_MONITOR_ABAP to display the statusof the BPE components, and role SAP_XI_ADMINISTRTOR_ABAP to startand stop the engine.

If you correct processes with error status, you can restart them. Use transactionSWF_XI_SWPR to do this.

In the basic customizing of BPE, you define an administrator who will be notified ifan integration process has error status. It is not possible to define an administratordepending on the process.

To specify that the administrator receives the internal error notification as an e-mail intheir standard mail inbox, use transaction SO36. (Automatic Forwarding function.)They must have defined an e-mail address in SU01 (user maintenance).

Hint: You can also set automatic forwarding centrally in transaction SO16.To do this, select Send to Home Addresses of Users on the Mail SystemGroup tab page.

Transaction SWF_XI_SWPC is very similar to the Continue Processes FollowingErrors transaction. You use it to display process instances that have crashed as a resultof a system error. These workflows are then continued, not restarted.





Exercise 8: Creating a Purchase Order andSales Order


• Use the switch step

• Use the fork step

• Send a message to your alert inbox

Business ExampleYou want to create a purchase order in the MM system and a sales order in the SDsystem. You want to do this in parallel, using an asynchronous call. The used messageis list. In this case, use a direct routing and enter the send context 'PurchaseOrder' forthe message to MM and 'SalesOrder' for the message to SD.

You request a transport acknowledgment for the message to MM and an applicationacknowledgment for the message to SD. Both systems send you a response in themessages po_resp and so_resp. If creation was not successful, the status field willcontain the value ERROR. Save this field in your process (element status_so orstatus_po).

If creation could not be completed successfully in one of the two systems, send anasynchronous request to both to delete the objects. Use the send contexts CancelPOand CancelSO for the receiver determination for systems MM and SD. The messagefor the message to MM is po_resp (references interface crea_po_abstract). Themessage for the message to SD is so_resp (references interface crea_so_abstract).In both cases, request an application acknowledgment. After cancelation, triggeran alert that the objects could not be created and that the process will be canceled.Cancel the process.

To create an error situation in the purchase order, CustomerNo must contain a “Y”. Tocreate an error in the sales order, CustomerNo must contain a “Z.”



Task:Define a new block to create the sales order and purchase order. Send the sales order toAirline_group_one and the purchase order to Airline_group_two. Only if both ordersare created successfully will the process be processed further. Otherwise an alert isthrown, the process instance is canceled, and the orders in both systems are canceled.

1. The scenario takes place in a new block. Add block stepCreateSalesAndPurchaseOrdersBlock to your integration process.

2. You want to create a sales order and a purchase order in two systems in parallel.You need a fork step.

Insert a step createparallel with step type Fork with two branches into yourblock step CreateSalesAndPurchaseOrdersBlock.

3. The MM and SD systems send back messages when the orders are created.These messages must be correlated with the corresponding send steps, so youhave to define a correlation. The customer number is used for the correlation.

Create the correlation CorrOrder. Add correlation container Cust with typexsd:string. The involved messages are list_abstract, crea_po_abstract, andcrea_so_abstract. In the Properties area, assign CustNo to the correlationcontainer element Cust.

4. Now you can create the send step for the purchase order that activates thecorrelation. The receiver (business system Airline_group_two) is determinedusing a condition defined in the receiver determination on the Integration Server.The condition is determined using the context property PurchaseOrder.

Create asynchronous send step SendPO in the first branch. EnterPurchaseOrder for the Send Context property. The later routing depends on thissend context. Message is list, Acknowledgment is Transport and the correlationCorrOrder must be activated.

5. The MM system sends back a message when the purchase order is defined, soyou have to define a container element for the response message.

Create a container element po_resp in the CreateSalesAndPurchase-OrdersBlock container. This is an abstract interface of type crea_po_abstract.

6. Define a receive step for the message that is sent by the MM system once ithas created the purchase order.

Insert a receive step ReceivePO after the send step. Message is po_resp, usecorrelation CorrOrder.




7. You want to extract one single field of the asynchronous response message: theStatus field. This field tells you whether the purchase order can be created ornot, so you need a container element for this status field.

Create a container element status_po for container CreateSalesAndPurchase-OrdersBlock. Category is Simple Type and Type is xsd:string.

8. Use a container operation to extract the Status field from the message.

Insert container operation step getPOstatus after the receive step. Assigncontainer element status_po. Expression is Interface Variable (po_resp)→XPath → SparePartLineItemList→ Status.

9. Now you can create the send step for the sales order that activates the correlation.The receiver (business system Airline_group_one) is determined using acondition defined in the receiver determination in the Integration Directory. Thecondition is determined using the context property SalesOrder.

Create an asynchronous send step SendSO in the second branch. EnterSalesOrder for the Send Context property. This is important because the routingdepends on this Send Context. Message is list, Acknowledgment is Application,and CorrOrder must be activated.

10. The SD system sends back a message when the sales order is defined. You haveto define a container element for the response message.

Create a container element so_resp in the CreateSalesAndPurchase-OrdersBlock container. It is an abstract interface of type crea_so_abstract.

11. Define a receive step for the message that is sent by the SD system once it hascreated the sales order.

Insert a receive step ReceiveSO after the send step. Message is so_resp, usecorrelation CorrOrder.

12. You want to extract one single field of the asynchronous response message: theStatus field. This field tells you whether the sales order can be created or not.You need a container element for this field.

Create a container element status_so for container CreateSalesAndPurchase-OrdersBlock. Category is Simple Type and Type is xsd:string.


Insert container operation step getSOstatus after the receive step. Assigncontainer element status_so. Expression is Interface Variable (so_resp) →XPath → SparePartLineItemList→ Status.




14. In a new block, you want to check whether the purchase order and sales orderhave been created.

Add a second block step, AutomaticCompensation, in blockCreateSalesAndPurchaseOrdersBlock.

15. If one of the orders could not be created, the Status field shows an ERROR.In this case, delete the purchase order, the sales order, and cancel the processinstance in branch 1 of the switch step.

Insert switch step CancelOrders into your block step AutomaticCompensation.Branch 1 is executed if one of the container elements status_po or status_socontains the value ERROR.

16. To delete the orders, you need two send steps using the message po_resp withacknowledgment application (MM system) and the message so_resp withacknowledgment application (SD system).

Create the asynchronous send step Cancel_PO in branch 1. Enter CancelPOfor the Send Context property. Message is po_resp, Acknowledgment isApplication.


Create the asynchronous send step Cancel_SO in branch 1. Enter CancelSO forthe Send Context property. Message is so_resp, Acknowledgment is Application.

18. Insert control step AlertCancelOrders into branch 1 to throw an alert. The AlertCategory is PROCESS_## and Alert Message could be Group ##: PO and SOcanceled, process canceled, where ## stands for your group number.

19. The process itself is canceled using a control step.

Insert control step OrdersCanceled into branch 1 to cancel the process.

20. Check, save, and activate the integration process.

21. Send three messages to your integration process. For a positive outcome with noalerts, use customer number 1000 and materials 2000, 3000, and 4000.

If you use a customer number containing a Y, like 1000Y, the response messagecorrelated to the CreatePurchaseOrderMessage from Airline_Group_Twoindicates that an error occurred.




If you use a customer number containing a Z, like 1000Z, the response messagefor a sales order message indicates that an error occurred. Check the workflowlog to make sure that in both cases the process is canceled and an alert has beenthrown.

22. Check your alert inbox.



Solution 8: Creating a Purchase Order andSales Order

Task:Define a new block to create the sales order and purchase order. Send the sales order toAirline_group_one and the purchase order to Airline_group_two. Only if both ordersare created successfully will the process be processed further. Otherwise an alert isthrown, the process instance is canceled, and the orders in both systems are canceled.

1. The scenario takes place in a new block. Add block stepCreateSalesAndPurchaseOrdersBlock to your integration process.

a) Drag a block step into your integration process.

b) Enter Name: CreateSalesAndPurchaseOrdersBlock.

2. You want to create a sales order and a purchase order in two systems in parallel.You need a fork step.

Insert a step createparallel with step type Fork with two branches into yourblock step CreateSalesAndPurchaseOrdersBlock.

a) Drag a fork step into the CreateSalesAndPurchaseOrdersBlock.

b) Enter Name: createparallel.

c) Enter value 2 in the Necessary Branches field.

3. The MM and SD systems send back messages when the orders are created.These messages must be correlated with the corresponding send steps, so youhave to define a correlation. The customer number is used for the correlation.




Create the correlation CorrOrder. Add correlation container Cust with typexsd:string. The involved messages are list_abstract, crea_po_abstract, andcrea_so_abstract. In the Properties area, assign CustNo to the correlationcontainer element Cust.

a) Add correlation CorrOrder in the Correlation List window.

b) Switch to the correlation editor.

c) Add correlation container Cust with type xsd:string.

d) Add involved messages list_abstract, crea_po_abstract,and crea_so_abstract.

e) In the Properties area, assign Interface Variable → XPath →SparePartLineItemList→ CustNo to the correlation container elementCust.

4. Now you can create the send step for the purchase order that activates thecorrelation. The receiver (business system Airline_group_two) is determinedusing a condition defined in the receiver determination on the Integration Server.The condition is determined using the context property PurchaseOrder.

Create asynchronous send step SendPO in the first branch. EnterPurchaseOrder for the Send Context property. The later routing depends on thissend context. Message is list, Acknowledgment is Transport and the correlationCorrOrder must be activated.

a) Drag a send step into the first branch.

b) Name: SendPO.

c) Mode: Asynchronous, Message is list, Acknowledgement :Transport.

d) Enter Send Context PurchaseOrder.

e) Activate Correlation is CorrOrder. Assign the following to Cust:Interface Variable (list)→ XPath→ SparePartLineItemList→ CustNo.

5. The MM system sends back a message when the purchase order is defined, soyou have to define a container element for the response message.




Create a container element po_resp in the CreateSalesAndPurchase-OrdersBlock container. This is an abstract interface of type crea_po_abstract.

a) Add container element po_resp to the container list.

b) Category is Abstract Interface and Type is crea_po_abstract.

c) Container: CreateSalesAndPurchaseOrdersBlock

6. Define a receive step for the message that is sent by the MM system once ithas created the purchase order.

Insert a receive step ReceivePO after the send step. Message is po_resp, usecorrelation CorrOrder.

a) Insert the ReceivePO receive step after the SendPO send step.

b) Message is po_resp, use correlation CorrOrder.

7. You want to extract one single field of the asynchronous response message: theStatus field. This field tells you whether the purchase order can be created ornot, so you need a container element for this status field.

Create a container element status_po for container CreateSalesAndPurchase-OrdersBlock. Category is Simple Type and Type is xsd:string.

a) Add container element status_po to the Container list.

b) Category is Simple Type and Type is xsd:string.

c) Choose container CreateSalesAndPurchaseOrdersBlock.


Insert container operation step getPOstatus after the receive step. Assigncontainer element status_po. Expression is Interface Variable (po_resp)→XPath→ SparePartLineItemList→ Status.

a) Insert container operation step getPOstatus after the receive step.

b) Operation is Assign and Container Element is status_po.

c) Expression is Interface Variable (po_resp) → XPath →SparePartLineItemList→ Status.

9. Now you can create the send step for the sales order that activates the correlation.The receiver (business system Airline_group_one) is determined using acondition defined in the receiver determination in the Integration Directory. Thecondition is determined using the context property SalesOrder.




Create an asynchronous send step SendSO in the second branch. EnterSalesOrder for the Send Context property. This is important because the routingdepends on this Send Context. Message is list, Acknowledgment is Application,and CorrOrder must be activated.

a) Drag a send step into the second branch.

b) Step Name: SendSO.

c) Mode: Asynchronous, Message is list, Acknowledgement:Application.

d) Enter send context SalesOrder.

e) Activate Correlation is CorrOrder. Assign the following to Cust:Interface Variable (list)→ XPath→ SparePartLineItemList→ CustNo.

10. The SD system sends back a message when the sales order is defined. You haveto define a container element for the response message.

Create a container element so_resp in the CreateSalesAndPurchase-OrdersBlock container. It is an abstract interface of type crea_so_abstract.

a) Add container element so_resp to the container list.

b) Category is Abstract Interface and Type is crea_so_abstract.

c) Container: CreateSalesAndPurchaseOrdersBlock

11. Define a receive step for the message that is sent by the SD system once it hascreated the sales order.

Insert a receive step ReceiveSO after the send step. Message is so_resp, usecorrelation CorrOrder.

a) Insert receive step ReceiveSO after the send step SendSO.

b) Message is so_resp, use correlation CorrOrder.

12. You want to extract one single field of the asynchronous response message: theStatus field. This field tells you whether the sales order can be created or not.You need a container element for this field.

Create a container element status_so for container CreateSalesAndPurchase-OrdersBlock. Category is Simple Type and Type is xsd:string.

a) Add container element status_so to the container list.

b) Category is Simple Type and Type is xsd:string.

c) Choose container CreateSalesAndPurchaseOrdersBlock.





Insert container operation step getSOstatus after the receive step. Assigncontainer element status_so. Expression is Interface Variable (so_resp)→XPath→ SparePartLineItemList→ Status.

a) Insert container operation step getSOstatus after the receive step.

b) Operation is Assign and Container Element is status_so.

c) Expression is Interface Variable (so_resp) → XPath →SparePartLineItemList→ Status.

14. In a new block, you want to check whether the purchase order and sales orderhave been created.

Add a second block step, AutomaticCompensation, in blockCreateSalesAndPurchaseOrdersBlock.

a) Drag a block step into your integration process.

b) Enter Step Name AutomaticCompensation.

15. If one of the orders could not be created, the Status field shows an ERROR.In this case, delete the purchase order, the sales order, and cancel the processinstance in branch 1 of the switch step.

Insert switch step CancelOrders into your block step AutomaticCompensation.Branch 1 is executed if one of the container elements status_po or status_socontains the value ERROR.

a) Drag a switch step into the block AutomaticCompensation.

b) Enter Step Name CancelOrders.

c) Open the condition editor. Select the simple variables status_po andstatus_so and compare these with the string ERROR. Both simple variablesare connected by an OR.





Create the asynchronous send step Cancel_PO in branch 1. Enter CancelPOfor the Send Context property. Message is po_resp, Acknowledgment isApplication.

a) Drag a send step into branch 1.

Name it Cancel_PO.

b) Mode is Asynchronous, Message is po_resp, and Acknowledgmentis Application.

c) Enter Send Context CancelPO.


Create the asynchronous send step Cancel_SO in branch 1. Enter CancelSO forthe Send Context property. Message is so_resp, Acknowledgment is Application.

a) Drag a send step into branch 1.

Name it Cancel_SO.

b) Mode is Asynchronous, Message is so_resp, and Acknowledgmentis Application.

c) Enter Send Context CancelSO.

18. Insert control step AlertCancelOrders into branch 1 to throw an alert. The AlertCategory is PROCESS_## and Alert Message could be Group ##: PO and SOcanceled, process canceled, where ## stands for your group number.

a) Drag a control step into branch 1.

Name it AlertCancelOrders.

b) The Alert Category is PROCESS_## (## is your group number).

c) Alert Message could be PO and SO order canceled, processcanceled.

19. The process itself is canceled using a control step.

Insert control step OrdersCanceled into branch 1 to cancel the process.

a) Drag a control step into branch 1.

Name it OrdersCanceled.

b) Action is Cancel Process.




20. Check, save, and activate the integration process.

a) To check the integration process, choose Integration Process→ Check. Theresults are displayed in the Processing Log section of the process editor.

b) Save the integration process by choosing Save and go to the Change List.There you have to activate your integration process.

21. Send three messages to your integration process. For a positive outcome with noalerts, use customer number 1000 and materials 2000, 3000, and 4000.

If you use a customer number containing a Y, like 1000Y, the response messagecorrelated to the CreatePurchaseOrderMessage from Airline_Group_Twoindicates that an error occurred.

If you use a customer number containing a Z, like 1000Z, the response messagefor a sales order message indicates that an error occurred. Check the workflowlog to make sure that in both cases the process is canceled and an alert has beenthrown.

a) Send three messages using your HTTP client.

b) Use transaction SXMB_MONI. To select your message and call theworkflow log, click entry PE.

22. Check your alert inbox.

a) Call the Runtime Workbench.

b) Choose Alert Inbox.

Caution: Your user must be assigned to the Alert Category(transaction ALRTCATDEF) to receive an alert in the alert inbox.



Exercise 9: Creating a Purchase Order andSales Order - Enhancement


• Add a manual compensation

Business ExampleThis is possible when creation of a purchase order fails. Application and transportacknowledgments of send messages are used to realize this, and send contexts areused for routing purposes.

Our aim is the following scenario:

The creation of a purchase order is enhanced by a manual compensation option.

If creation of the purchase order fails, use deadline monitoring to have the processwait n minutes (in the test exercise two minutes). If the order can be created in thistime, that is, a corresponding message arrives, the block for canceling the objectsand the process is not to be executed. You perform the correction using reportSPAREPARTS_MANUALCOMPENSATION in client 813 (MM system).

In the process, use an alert to inform the administrator that the purchase order hasfailed and that they should perform the above-mentioned report within n minutes (inthe test exercise two minutes). Then, wait for a message from the MM system andmake sure that the block for canceling SO and PO and for canceling the process isnot executed.

If the report is not run, no message is received. After two minutes a timeout occurs,and the process is continued. In this case, the Response Status field for the purchaseorder remains in ERROR status and the purchase and sales order are canceled in thenext block.

Task:Add a manual compensation to correct the status of the purchase order.

1. Use a switch step to check whether the container element status_po has ERRORstatus

Add the switch step check after the container operation getPOstatus. OutcomeName is ERROR if an error occurs.




2. Use a block in branch 1 of the switch step to define the manual compensationand define the deadline block and the exception handler.

Insert the block ManualCompensation into branch 1 and define the exceptionTimeOut.

3. Add a deadline branch with two minutes. The time starts once the step hasbeen created.

4. Use a control step to throw the TimeOut exception for the deadline branch.

Insert control step NoInteraction into the deadline branch that throws theTimeOut exception.

5. Add an exception branch to the block ManualCompensation to handle theTimeOut exception.

6. In the third branch, throw an alert and then wait to see whether a second messageis sent by the business system (in the form of a report).

Into the third branch of the ManualCompensation block, insert a control step,POErrorControl, to throw an alert of category Process_##. The text couldbe: Group ## : Could not create purchase order. ## is your group number.

7. Insert a receive step ReceivePOAgain after the control step. Message ispo_resp, use correlation CorrOrder.

8. After the message for correction of the purchase order has been received, thecontainer element status_po is assigned the value OK. Automatic compensationis no longer necessary.

Insert container operation step setPOstatus after the receive step. Assigncontainer element status_po. Expression is String OK.

9. Save, check, and activate your process and prepare the test of the manualcompensation step. Log on to client 813 and prepare the run of reportSPAREPARTS_MANUALCOMPENSATION. Send a message with your HTTPclient. Use customer number 1000Y.

Run report SPAREPARTS_MANUALCOMPENSATION in client 813 with thesame customer number within the next 120 seconds to compensate manually.

Check the graphical workflow log and the alert inbox.

The graphical workflow log should look like this:




Figure 66: Graphical Workflow Log: Enhancement



Solution 9: Creating a Purchase Order andSales Order - Enhancement

Task:Add a manual compensation to correct the status of the purchase order.

1. Use a switch step to check whether the container element status_po has ERRORstatus

Add the switch step check after the container operation getPOstatus. OutcomeName is ERROR if an error occurs.

a) Drag a switch step after the container operation getPOstatus.

b) Enter Name: check.

c) Outcome Name is error.

d) Condition is status_po equals ERROR.

2. Use a block in branch 1 of the switch step to define the manual compensationand define the deadline block and the exception handler.

Insert the block ManualCompensation into branch 1 and define the exceptionTimeOut.

a) Drag a block step into branch 1.

b) Enter Step Name ManualCompensation.

c) Mode is Default and Exception is TimeOut.

3. Add a deadline branch with two minutes. The time starts once the step hasbeen created.

a) Select the ManualCompensation block step.

b) Call the context menu and insert a deadline branch.

c) Duration is two minutes.

d) Reference time: Creating the Step

4. Use a control step to throw the TimeOut exception for the deadline branch.




Insert control step NoInteraction into the deadline branch that throws theTimeOut exception.

a) Drag a control step into the deadline branch.

b) Action is Throw Exception.

c) Exception is TimeOut.

5. Add an exception branch to the block ManualCompensation to handle theTimeOut exception.

a) Select the ManualCompensation block.

b) Call the context menu and insert an exception branch.

c) Exception Handler is TimeOut.

6. In the third branch, throw an alert and then wait to see whether a second messageis sent by the business system (in the form of a report).

Into the third branch of the ManualCompensation block, insert a control step,POErrorControl, to throw an alert of category Process_##. The text couldbe: Group ## : Could not create purchase order. ## is your group number.

a) Drag a control step into the third branch of the ManualCompensationblock.

Name it POErrorControl.

b) Action is Throw Alert.

c) Alert Type is PROCESS_##.

d) The Alert Message could be Group ##: Could not createpurchase order, where ## is your group number.

7. Insert a receive step ReceivePOAgain after the control step. Message ispo_resp, use correlation CorrOrder.

a) Drag receive step ReceivePOAgain after the control step POErrorControl.

b) Message is po_resp, use correlation CorrOrder.

8. After the message for correction of the purchase order has been received, thecontainer element status_po is assigned the value OK. Automatic compensationis no longer necessary.




Insert container operation step setPOstatus after the receive step. Assigncontainer element status_po. Expression is String OK.

a) Drag container operation step setPOstatus after the receive step.

b) Operation is Assign and Target is status_po.

c) Expression is the value OK of type xsd:string.

9. Save, check, and activate your process and prepare the test of the manualcompensation step. Log on to client 813 and prepare the run of reportSPAREPARTS_MANUALCOMPENSATION. Send a message with your HTTPclient. Use customer number 1000Y.

Run report SPAREPARTS_MANUALCOMPENSATION in client 813 with thesame customer number within the next 120 seconds to compensate manually.

Check the graphical workflow log and the alert inbox.






a) To check the workflow log, select your message in transactionSXMB_MONI. Click on entry PE.



b) To check the alert inbox, use the Runtime Workbench.



Lesson Summary







BIT430 Lesson: Process Execution Monitoring

Lesson: Process Execution Monitoring

Lesson OverviewIntegration processes are executed at runtime by the Business Process Engine (BPE).A wide range of functions are available to you for administration, monitoring andtroubleshooting. In this lesson you will learn the various possibilities for monitoringintegration processes.







Business ExampleThere are many transaction codes you can use to monitor workflow executions.However, the main entry point for the monitoring workflow is transactionSXMB_MONI_BPE. Almost all of the transaction codes take you to the workflowlog. The workflow log enables you to see exactly what is happening in the workflow.

Monitoring Integration Processes – OverviewWhen executing an integration process, the system generates corresponding workitems in the same way as when executing a SAP Business Workflow. A work item canrepresent a process or a step in a process.



You can monitor the execution of integration processes centrally using the CCMSAlert Monitor or with additional transactions for BPE monitoring.

• BPE Monitoring

Integration processes are executed at runtime by the Business ProcessEngine (BPE). When executing an integration process, the system generatescorresponding work items in the same way as when executing a SAP BusinessWorkflow. A work item can represent a process or a step in a process. You candisplay the generated work items with the BPE Monitoring transactions andobtain detailed information on the status of a process or individual step.

Hint: In addition to using the Runtime Workbench, you can also usethe SAP NetWeaver Administrator for PI to monitor your integrationlandscape.

• CCMS Alert Monitor

The SAP Computing Center Management System (CCMS) provides centralaccess for monitoring the execution of integration processes. There, you can seeat a glance whether processing is running correctly or if problems have occurred.If errors have occurred, the system provides detailed descriptions of the causesand remedies along with well as the appropriate troubleshooting functions.

• Monitoring Processes

You use a monitoring process to chart the milestones of a business process. Hereit is possible that the business process is distributed across multiple applications.When a milestone is reached, an application publishes events to which a centralmonitoring process subscribes. In the monitoring process you can define thatalerts are triggered when certain events occur or when deadlines are exceeded.

Hint: See BAM unit for details.

BPE Monitoring TransactionsThere are many transaction codes you can use to monitor the execution ofworkflows. However, the main entry point for the monitoring workflow is transactionSXMB_MONI_BPE. Almost all of the transaction codes take you to the workflowlog. You can use the workflow log to analyze what is happening in the workflow. Inprocess control transactions, almost all of which can be accessed using transactionSXMB_MONI_BPE, this involves the transactions for monitoring workflows.



Figure 69: Monitoring of Workflow Execution - SXMB_MONI_BPE

Important Process Monitoring Transactions

You can display the generated work items with the BPE Monitoring transactions andobtain detailed information on the status of a process or individual step.

• Process selection: SWF_XI_SWI1

• Processes for one message type: SWF_XI_SWI14

• Processes for a message: SWF_XI_SWI6

• Processes with missed deadline: SWF_XI_SWI2_DEAD

• View of inbound queue of messages: SMQ2

• View of outbound queue of messages: SMQ1

• RFC Monitor: SM58

Process Selection

Via the Process Selection transaction, you are able to find workflows you are interestedin by searching with different criteria. All reports give you the same workflow view;the difference is the filter criteria used for the workflow log. As you can see in thefollowing figure, the search criteria are extensive. You can search, for example, bytype, status, or time of generation of the workflow. Within the Type and Status fields,you have various options in each case. After making your choice, you can executeyour query and the results will be shown.



Figure 70: Select Which Workflows You Want to Monitor

By designating F as the type of work item, you will look at the log for each instanceof your integration process. This is normally easier than looking at each stepindividually. You also may need to change the date/time range to get the processinstances that interest you.

You can change the Status field. You could look only at executions in COMPLETEDstatus, ERROR status, STARTED status, or CANCELLED status.

As a result of the prior query, you get a window with a lot more details, such as ID,workflow number (WS#######), or the workflow status. Double-clicking a processinstance you are interested in takes you to the workflow log and provides furtherdetails.

Workflow Log

The following figure shows the actual workflow log. At the very top the name of theworkflow is shown. This is the exact name of the integration process created in theIntegration Repository. All the steps belonging to this process instance are shown in atree structure, telling which steps were carried out and completed, still in process, orhave an error.



Figure 71: Log of a Completed Workflow Process

By clicking on the Details column, more detailed information shown, such as whoexecuted the work item, when it was executed, or which actions were executed.

Clicking on the Graphic column will lead you to a graphical representation of theworkflow log.

For completeness, the three tab pages of the standard workflow log are listed below.



However, note that these tab pages are less relevant to ccBPM processes that runwithout user interaction and whose objects are messages rather than business objects.

• Workflow Chronicle

This is the default tab page. It shows the different workflow steps that havealready been processed or are in process. If the workflow has a sub-workflowstructure, the sub-workflows are displayed as well. Furthermore, it offers youthe possibility to get more details of the single steps or to switch to the graphicalview.

• Workflow Agents

The first level shows all the employees (users) involved in this workflow up tonow. The second level shows the following information for each employee(user):

– What action was carried out in what step

– When this action was carried out

– Which objects were involved

• Workflow Objects

This tab shows what information was generated and processed, and how. It alsoshows the message GUID for this workflow. The first level lists the objects thatare related to the workflow or that have been addressed up to now during theexecution of the workflow. These objects include.

– The “leading” object of the workflow

– Attachments and objects added in the individual workflow steps

The second level shows the following for each object:

– Who carried out what detailed action for what task

– When this action was carried out

The workflow log displayed shows an end-user view, not a technical view. Therefore,it is unsuitable for problem solving. However, you can branch from the end-user viewto the technical view to get more details. Choose the Technical View icon.

Technical Log

The Technical Log view shows technical information about the execution of a process,as required by workflow system administrators, for instance. The Technical Viewshows technical nodes and control structures and provides additional information,such as the content of container elements.



Figure 72: Technical Workflow Log

The technical workflow log shows all steps of the running process instance, notjust those related to a message.

The settings in the technical log can be personalized:

To do this, choose Utilities - Personal Workflow Settings in the log display. UnderEntries in Technical Workflow Log, you can influence the number of steps displayedand determine whether only the last node is to be displayed in the display of a loopfunction. In both cases, restrictions make the log display quicker.



The log shows the current status of the process instance as a whole and for eachindividual step. The Business Process Engine recognizes four different statuses (theseare not all relevant in ccBPM processes):

• Ready (Ready)

The work item is available for execution. Depending on the type, it can beexecuted by the recipient in his Business Workplace or in the background bythe system.

• Reserved (Selected)

This work item is reserved in the Business Workplace by a recipient. This statusremoves the work item from the Business Workplaces of all other recipients.

• In Process (Started)

This work item is currently being processed. This means that either thetask/method associated with the work item is currently being executed or thatprocessing has not yet been completed.

• Waiting (Waiting)

The work item cannot be executed yet, since it is still waiting for some event.

• Executed (Committed)

The task/method associated with the work item has already been executed once,but processing is not yet completed. The work item can therefore be startedagain (forced into status In Process).

• Completed (Completed)

The work item has been processed successfully.

• Logically Deleted (Cancelled)

The work item no longer has to be processed, since the possible result is nolonger required.

• Error (Error)

An error has occurred during processing of the work item. The work item cannotbe started again. Refer to the work item log for the possible error causes.

• In Preparation (Checked)

The work item can be created, but the condition for the step Create Work Item isnot yet fulfilled.

If you click the ID of a step or process item, this calls the Display Work Item function.



Displaying and Editing – Performing Actions on a Work Item

This view shows further details about the work item and enables you to performactions on the work item.

In certain error situations, it may be necessary that you edit the payload of the messageand then continue the process. In these cases you can switch from the work itemdisplay to an editor for editing the message.

To do this choose Edit –> Change. The system displays a list of services on the leftside of the window. This list contains all available options for manual processing ofthe displayed work items.

Caution: Be aware that your changes might effect the correct execution ofthe integration process and only perform changes if they are really necessary.

Figure 73: Work item display: Available Actions

Important actions in the Work item display view are:

• You can Complete Manually to end the workflow step.

• You can also Logically Delete the workflow, which will also stop the execution.

Note: Normally you should not manually complete or cancel workflowexecutions.



The work item display shows all XML messages that are processed in a process on theXML Messages tab page. This makes the display clearer and faster, in particular forcomplex processes. You can display further information on a particular XML messageon the tab page, for example, the corresponding message proxy.

The XML Messages tab page is visible if you have selected the User View or ClassicUser View in the personalized workflow settings for the work item display.

Monitoring ccBPM Processes in the CCMS MonitorThe SAP Computing Center Management System (CCMS) provides a special alertmonitor for SAP NetWeaver PI. The alert monitor is the central point of access formonitoring the execution of integration processes.

Here, you can identify diverse categories of system errors as well as application errorsin the various interfaces and interface namespaces of the involved components.

Hint: The CCMS Alert Monitoring is not a part of PI; it is a component partof SAP NetWeaver AS. You can find further information on CCMS AlertMonitoring and other CCMS monitors in the corresponding documentationfor the Web AS.

Monitoring of the Business Process Engine is integrated in the CCMS Monitor. Youmust make the following settings:

• If the system group ExchangeInfrastructure_Systems does not exist, create itusing transaction RZ21.

Menu path: Techn. Infrastructure→ Configure Central System→ MaintainSystem Groups

Choose Maintain Groups, choose Create System Group, and enterExchangeInfrastructure_Systems in the New Group field.

• Assign the Exchange Infrastructure system in which the Business Process Engineis running to the system group.

Select the system group ExchangeInfrastructure_Systems and choose AddSystem in the context menu.

• A job determines the CCMS monitoring data.

To schedule this job, choose Techn. Infrastructure→ Configure Central System→ Activate Central System Dispatching.



For more information about CCMS and SAP PI in general and about monitoring BPE,see SAP Notes 662119 and 919744, and the notes mentioned there.

Once you have made the above-mentioned settings, call transaction RZ20, chooseSAP CCMS Monitor Templates, and you will see the entry Exchange Infrastructure.

Figure 74: Business Process Engine in the CCMS Monitor

You can also call the Business Process Engine monitor in transaction RZ20 bychoosing SAP CCMS Technical Expert Monitors and double-clicking All MonitoringContexts.

Monitoring Using the qRFC MonitorIn the qRFC Monitor (SMQ2) you can display information on the process definition,runtime and settings of inbound processing of the process for an LUW that processesan integration process (function module SWF_XI_MSG_RAISE_EVENT).



Figure 75: View of Inbound Queue in Transaction SMQ2

Figure 76: Actions on Queue Entry with Error in Transaction SMQ2

By double-clicking a message ID in the monitor, you can branch to the LUW datascreen and execute functions related to the message. These include design-timefunctions such as Display Process in the Definition section, and also runtime functionssuch as Simulate Message Delivery.



Lesson Summary









Lesson: Message Monitoring

Lesson OverviewThis lesson will show you how to monitor a message and to display the work Itemcontainer.




Business ExampleYour task is the monitoring of a complex integration process. You want to find allinvolved messages of a business process and to control the correct interaction.

Message MonitoringTo call the Monitor for Processed XML Messages, use transaction SXMB_MONI. Todisplay information about persistent XML messages, you have to select the messagesbeforehand using particular criteria.


BIT430 Lesson: Message Monitoring

Figure 77: Message Monitoring

You can find messages invoking an integration process by checking the inbound andoutbound values. PE (process engine) indicates that an integration process is involved.

Status Monitor for Synchronous/AsynchronousCommunicationThe Status Monitor for Synchronous/Asynchronous Communication (transactionSXMS_SAMON) displays status information about messages where a coupling ofsynchronous and asynchronous processing has occurred. The status monitor forsynchronous/asynchronous communication provides:

• The number of active synchronous calls that are still waiting for a response

• The number of canceled processes (synchronous calls) whose status has notyet been deleted

• A table containing status information about the involved synchronous requestmessages



The colors of the status have the following meanings:

• Green: The call is still waiting.

• Yellow: The pipeline timeout has been exceeded, but the call has not yet beencanceled.

• Red: An error has occurred and the call has been canceled.

In the Status Monitor for Synchronous/Asynchronous Communication, you canexecute the following activities:

• Close all canceled processes.

• Update the entire display by choosing Update in the application function bar.

• Update the table of displayed messages by choosing Update in the table symbolbar.

• Navigate from the list of displayed messages to the corresponding workflow log.To do this, click the message ID of the respective message.

Monitoring ExampleThe integration process of this example splits a message and sends several messagesto a target business system.

Figure 78: Display Workflow Log



The workflow log displays the complete process with all work items. The container isin the technical log on the Container tab page.

Figure 79: Display Work Item Container

To display the message before the transformation, choose Table beforeMESSAGES_IN. The table is displayed at the bottom right of the window. Fromthe context menu, choose Nested Table→ MESSAGES to get the XML message. Todisplay the message after the split, select MESSAGES_OUT and perform the samesteps as for MESSAGE_IN.





Exercise 10: Sending a Purchase Order toa Supplier


• Send a purchase order to a supplier

Business ExampleYou send a purchase order to the supplier. An order confirmation is received andacknowledged.

Task:Send the purchase order to the supplier and acknowledge the received response.

1. Minimize the CreateAndPurchaseOrdersBlock block and add aSupplierCommunication block.

2. Insert an asynchronous send step: SendPO2Supplier. Use message po_resp andenter Supplier as the Send Context property.

3. Create a container element po_confirmation based on the abstract interfacecrea_po_abstract, within the SupplierCommunication container.

4. Insert a receive step ReceiveOrderConfirmation, using message po_confirmationand correlation CorrOrder.

5. Insert a positive acknowledgment send step SendAcknowledgment for messagepo_confirmation.

6. Save, check, activate, and test your process by sending three line items usingthe HTML client.

Insert Spare Part No 1000, 2000, and 3000 and the customer 1000.

The workflow log should look like this:







Solution 10: Sending a Purchase Order toa Supplier

Task:Send the purchase order to the supplier and acknowledge the received response.

1. Minimize the CreateAndPurchaseOrdersBlock block and add aSupplierCommunication block.

a) Select CreateAndPurchaseOrdersBlock and minimize the block by usingthe context menu or by clicking the minus icon in the upper-left corner ofthe block.

b) Insert a block step after the block you just minimized and switch to theProperties area.

c) Step Name: SupplierCommunication

2. Insert an asynchronous send step: SendPO2Supplier. Use message po_resp andenter Supplier as the Send Context property.

a) Drag a send step into the SupplierCommunication block.


c) Step Name: SendPO2Supplier

d) Mode: Asynchronous

e) Message: po_resp

f) Acknowledgement: None

g) Receiver From: Send Context

h) Send Context. Supplier




3. Create a container element po_confirmation based on the abstract interfacecrea_po_abstract, within the SupplierCommunication container.


b) Name: po_confirmation


d) Type: crea_po_abstract


f) Container: SupplierCommunication

4. Insert a receive step ReceiveOrderConfirmation, using message po_confirmationand correlation CorrOrder.

a) Insert a receive step after the send step SendPO2Supplier.


c) Step Name: ReceiveOrderConfirmation

d) Message: po_confirmation

e) Use Correlations: CorrOrder

5. Insert a positive acknowledgment send step SendAcknowledgment for messagepo_confirmation.

a) Insert a send step after the ReceiveOrderConfirmation receive step.


c) Step Name: SendAcknowledgement

d) Mode: Acknowledgement

e) For Message: po_confirmation

f) Acknowledgment Type: positive

6. Save, check, activate, and test your process by sending three line items usingthe HTML client.

Insert Spare Part No 1000, 2000, and 3000 and the customer 1000.

The workflow log should look like this:








a) Save the process.


c) If no errors occur, activate the process.

d) Open the HTML client and test the overall process by sending three lineitems to SAP XI.

e) The workflow log should look like this:




Lesson Summary





Unit Summary BIT430














Unit 4Business Activity and Performance

Management

Unit OverviewThe IT scenario known as BAM enables you to respond appropriately to exceptionalcircumstances within a business process. An example of such an exceptional situationmight be the delay or cancellation of a delivery. If such an exception occurs, theresponsible user is automatically notified by an alert. In a portal-based work center,you can access all information needed to analyze the situation. You also receiveproposed solutions and templates which provide assistance while you are processingthe event.

Options for optimizing PI performance are also displayed.


• Explaining the basics of Business Activity Monitoring in SAP NW 7.10

• Explaining the principles for developing the monitoring processes

• Understanding the interaction between integration processes and BusinessWorkflow Management

• Judge whether the use of an integration process would be suitable for yourproblem solution

• Use the Integration Server efficiently

• Make astute use of the options for improving performance

Unit ContentsLesson: Business Activity Monitoring in ccBPM ... . . .. . . . . . . . . . .. . . . . . . . . .. . . . .212Lesson: BPE Performance Management. . .. . . . . . . . . . .. . . . . . . . . . .. . . . . . . . . .. . . . .218

Exercise 11: Answer the following questions about BPE performance .227


Unit 4: Business Activity and Performance Management BIT430

Lesson: Business Activity Monitoring in ccBPM

Lesson OverviewBusiness Activity Monitoring (BAM) in SAP NW 7.1. provides a technicalinfrastructure that allows you to react in a suitable and immediate way to significantevents in your business processes. This puts you in a position to significantly improvethe efficiency of these processes.

In this lesson you will become acquainted with the possibilities of implementingBAM with the aid of CCBPM.





Business ExampleYou wish to be proactive in your company when responding to exceptional situationsin a business process. An example of such an exceptional situation might be the delayor cancellation of a delivery. If such an exception occurs, the responsible user isautomatically notified by an alert. In a portal-based work center, you can access allinformation needed to analyze the situation. You also receive proposed solutions andtemplates which provide assistance while you are processing the event.

Business Activity Monitoring – OverviewBAM is an IT infrastructure that allows users to respond to significant events andalerts in business processes in a suitable and timely manner.

This infrastructure is provided by the following solutions for monitoring, evaluatingand improving the efficiency of business processes.

• SAP Event Infrastructure

• Monitoring milestones

• Process Efficiency Analysis


BIT430 Lesson: Business Activity Monitoring in ccBPM

Figure 83: BAM Infrastructure – Overview

SAP Event Infrastructure

SAP's Event Infrastructure has already been integrated in the business applications.This infrastructure enables the user to collect, filter and publish events in businessprocesses. This can involve business processes of SAP and non-SAP systems.

Milestone Monitoring

You use milestone monitoring when you wish to monitor KPIs of a business process.The business process can be distributed across multiple applications. When amilestone is reached an application publishes events to which a central monitoringprocess subscribes. A monitoring process is a special integration process. In themonitoring process you can use conditions to define that alerts are triggered whencertain events occur or when deadlines are exceeded. You can also include certaininformation in the conditions that provide business intelligence – such as whether acustomer is a priority customer ("Gold Customer").

Process Efficiency Analysis

SAP provides process-specific reports with SAP NetWeaver Business Intelligence.



This predefined content for workflow and process efficiency analysis answersquestions such as:

• How many type “XYZ” process steps are executed by organizational unit“ABC”?

• How long is the average execution time for a process step?

• How many confirmation processes currently have a particular status?

SAP IT Scenarios for Business Activity MonitoringThe following variants are provided as predefined content with the Business ActivityMonitoring scenario:

• Publishing business events

An SAP application publishes events or alerts directly in Alert Management andthereby triggers alerts in the portal.

• Milestone Monitoring

A central monitoring process subscribes to events that are published by one ormore applications. This could involve SAP or non-SAP applications. Non-SAPapplications can be connected via the Adapter Framework of the ProcessIntegration (PI) usage type. The monitoring process uses rules to decide whetheran alert is to be triggered. Business Intelligence data can also be incorporated inthese rules.

Hint: The milestone monitoring scenario variant is based in theBusiness Process Management IT scenario. If you wish to evaluateBusiness Intelligence data as part of Business Activity Monitoring, youneed the Information Broadcasting scenario variant of the EnterpriseReporting, Query and Analysis IT scenario.

Publishing Business Events

You use this scenario variant when you wish to publish events or alerts from anSAP application directly in Alert Management. No changes to the correspondingapplication are required.

Hint: SAP applications can trigger events on the basis of the Business ObjectRepository (BOR) or ABAP Object Oriented Objects. Numerous events aregenerated as standard. However, you can also create your own events.



Figure 84: Publishing Business Events

Milestone Monitoring with ccBPM

A monitoring process is a special form of an integration process. All rules that arevalid for the use of integration processes are are also relevant for monitoring processes.

You can define a monitoring process that can monitor events from differentapplications. A monitoring process can subscribe to events of an SAP or non-SAPsystem. The monitoring process can filter and further process events.

Hint: A monitoring process is a special integration process. Therefore therules for efficient and effective use of integration processes also apply formonitoring processes.



To create a monitoring process, perform the following steps:

1. Create business events

Identify the events in your business process that the monitoring process is tomonitor.

If you would like to monitor events from non-SAP applications in the monitoringprocess, you need to convert the events into event messages which can beprocessed by the monitoring process. For this you use the Adapter Frameworkof the technical usage type Process Integration (PI).

Hint: With SAP applications you can use all events that are based onBOR or ABAP OO objects.

2. Define monitoring events

In Enterprise Service Repository define the required objects for mapping theevent message:

Define an outbound service interface for each event that the monitoring processis to process. You use this outbound service interface later to generate themessage proxies in the application systems.

Define an abstract service interface for each event that the monitoring process isto process. For each abstract service interface, use the same message types as inthe corresponding outbound interface.

In the interface determination in the Integration Directory, assign thecorresponding abstract interface to each outbound interface. Interface mappingis not required.

3. Generate proxies (only for events from SAP applications)

4. Define event linkage (only for events from SAP applications)

In the SAP application, choose the transaction SWF_BAM.

Define the event linkage Application Object for Message Proxy:

5. Define the monitoring process

Define the monitoring process that subscribes to the event message. In themonitoring process you also define the conditions for generating an alert.



Lesson Summary





Related Information

• Use a URL or a cross-reference tag to point out additional information that theparticipants may find useful, such as Web sites or White Papers. Delete this ifit is not relevant.



Lesson: BPE Performance Management

Lesson OverviewIn this lesson you will become acquainted with the various options for optimizing theperformance of integration processes in the design and configuration of the BPE.

The following challenges are posed in terms of the performance of the integrationprocess:

• Increasing the speed for message processing (often in synchronous scenariossuch as database querying)

• Increasing throughput (particularly in asynchronous scenarios)





Business ExampleYou want to automate some business processes in the Application-to-Application(A2A) or Business-to-Business (B2B) environments in your company. You establishthat a simple message exchange between your applications and business partnerscannot provide the necessary information and therefore decide to use integrationprocesses.

Checklist: Using Integration Processes CorrectlyYou can use the following list of considerations to check whether integrationprocesses are the suitable solution for your problem. You can also check whether yourintegration processes are defined efficiently.

• Message-based communication

• Semantic relationships between messages

• Correlations can be defined uniquely

• Defined end condition

• No user action required


BIT430 Lesson: BPE Performance Management

The prerequisite for integration processes is that you can realize communicationbetween the involved partners using XML messages. The messages usually relate toone another, for example a purchase order and its purchase order items. If this is notthe case, check that you will be able to realize the process with the basic functions ofthe Integration Server. The Business Process Engine can only relate the messages toeach other if unique correlations can be defined.

A process instance should not be active over an indefinite period. Therefore, you mustbe able to define an end condition for integration processes.

Integration processes support message processing without user interaction. If youhave to define a process that requires user interaction, check that you will be able torealize this process using Business Workflow or guided procedures.

The following are typical uses of integration processes:

• Sending a message to multiple receivers and waiting for the response message.The number of receivers is determined at runtime.

• Defining the order in which messages are sent to target systems.

• Collecting messages from one or more interfaces, bundling them, and forwardingthem.

• Enabling communication between a business system that makes synchronouscalls and a business system that functions asynchronously.

• Sending messages to multiple receivers synchronously and processing the firstresponse message received.

• A response message should be received within a defined time period.

Hint: Check whether you can handle certain process steps such as datacollection in the sender system rather than in an integration process, especiallyif messages are coming from only one system.

Splitting a message into a large number of individual messages should beperformed in the back end wherever possible.

Checklist: Efficient Use of the Integration ServerThe Business Process Engine executes integration processes at runtime on theIntegration Server. The Integration Server is the central resource to exchange messagesbetween business systems, so you should do everything to avoid performanceproblems.



Use the following list to check whether you are using the Integration Server efficiently:

• Define integration process-saving resources.

Be aware that each message sent to the process engine and each message sent bythe process engine is saved twice. The process instance itself and each step ofthe process creates a work item.

• Do not transfer application logic to the integration process.

• ccBPM on the Integration Server is not a substitute for interfaces that exchangemass data.

Hint: Further information on the performance of BPE can be found in SAPNote 857530.

Configuring Inbound ProcessingInbound processing is a runtime component that supplies messages to integrationprocesses ready to receive messages or that starts new instances of integrationprocesses if necessary. You can configure inbound processing in order to raiseperformance or the message throughout. The suitable configuration depends on thesemantics of the corresponding integration processes.

Inbound processing runs as follows:

1. Determination of the process type to which the message is delivered

Once the process type to which the message is to be delivered has beendetermined, the message is placed in a process type-specific qRFC queueand then processed by inbound processing. You can influence this step byconfiguring the queue assignment.

You can determine that messages for a process type are placed in one qRFCqueue or split across several qRFC queues.

With several qRFC queues you can attain a load distribution: Messages indifferent qRFC queues can be processed in parallel.

If a process is not suitable for load distribution, you can still attain performanceimprovements by configuring the corresponding qRFC queue. For example,you can specify on which server the entries in the qRFC queue of a particularprocess type are to be processed.

Hint: You can set queue assignment and load distribution with theSWF_INB_CONF transaction.



Detailed information on configuring the queue assignment of inboundprocessing can be found under http://help.sap.com/saphelp_nwpi71/help-data/en/44/3a6c6d55e402bfe10000000a11466f/frameset.htm

2. Determination of the process instance to which the message is to be delivered

So that a message can be delivered to a process, the process must have at leastone active correlation for this message. If this is not the case, but the process typecontains one receive step to be started that is suitable for this message, a newprocess instance is started and the message is delivered to this process instance.

3. Delivery of the message to existing process instances or starting a new processinstance.

As already described in detail in Unit 2 in the Step Types (Part 1) and Correlationlesson, you choose between the following settings for the delivery mode andthereby optimize the performance of BPE:

• Classic setting: Inbound processing with buffering (default setting)

With this setting a message is delivered to an existing process instanceif this has a suitable active correlation. This is performed regardless ofwhether a corresponding receive step is active. If no receive step iscurrently active that can receive this message, the message is cached in aseparate, process instance-specific queue. As soon as the correspondingreceive step is reached, the system automatically delivers the first messagereceived from this queue which fulfills the corresponding correlation.

• Inbound processing without buffering

With inbound processing without buffering, the qRFC entry receives anerror status if an message is to be delivered for which no receive stepis active. The message remains in the qRFC queue and the messageprocessing for this process type is stopped. The situation described aboveresults in an incorrect entry in the qRFC queue with inbound processingwithout buffering and can therefore be more easily detected and remedied.

Hint: The delivery mode can be set with the transaction SWF_INB_CONF .

Detailed information on configuring the queue assignment of inboundprocessing can be found under http://help.sap.com/saphelp_nwpi71/help-data/en/ec/aef162c560904abdef3540bc77e522/frameset.htm

Note: You can configure the inbound processing with the SWF_INB_CONFtransaction for each process type and client.


http://help.sap.com/saphelp_nwpi71/helpdata/en/44/3a6c6d55e402bfe10000000a11466f/frameset.htm

http://help.sap.com/saphelp_nwpi71/helpdata/en/ec/aef162c560904abdef3540bc77e522/frameset.htm


Transaction HandlingA transaction is a sequence of processing steps that is either executed completelyor not at all. If a transaction cannot be executed completely, the system undoes allprocessing steps within the transaction. This means that the condition before thestart of the transaction is restored.

When defining an integration process in the process editor, you can influencethe transactional behavior at runtime. This enables you to attain performanceimprovements.

Optimizing Transaction Boundaries

You can specify for a block whether the block start or block end form transactionboundaries:

• You can specify for the block start that the system starts a new transaction.

• For the block end you can specify that the system ends the currently startedtransaction (COMMIT WORK). The system ends the transaction open atthe current time, regardless of where it was started. If, for example, no newtransaction was started at the start of the block, the last started transaction beforethis is continued.

With suitable settings for the start and end of a block you can expand the scope oftransactions. This reduces the number of write accesses to the database, enablingyou to improve performance.

Optimizing Transactional Behavior for Certain Step Types

Usually the system creates a separate transaction at runtime for a step. The scope ofthis transaction covers solely this one step. For certain step types you can influencethe behavior of the transaction.

In the properties of the step, you can specify that the system does not start a newtransaction when executing the step. The system then executes the step in the thetransaction started at the time of execution. This means that no background workitem is created for the step and the number of database accesses is reduced. Thefollowing step types can be optimized:

• Send step

• Transformation step

• Receiver determination step

Optimizing Transactional Behavior

The interdependencies of the necessary settings must be taken into account in order tooptimally configure transactional behavior.



When defining transactional behavior, take note of the following points:

• Main memory requirements

Expanded transactions and executing certain steps without creating a newtransaction can result in increased main memory requirements. If the increasein main memory requirements is too great, you should define transactionboundaries more narrowly or specify that a new transaction is to be createdfor the corresponding steps.

• Error analysis in the workflow log

The technical view of the workflow log does not show any detailed informationfor steps for which no work item was generated. If an error occurs, the workflowlog displays the error information for the last executed step. In such a case themonitoring requirements and performance requirements need to be balanced.

Message PackagingThe message packaging in the Business Process Engine (BPE) improves inboundprocessing performance.

In many cases inbound processing in the Business Process Engine (BPE) takes up thelargest proportion of processing time. With a correspondingly high number of inboundmessages in BPE inbound processing, it can occur that these messages cannot beprocessed with sufficient speed. The qRFC queues grow, thereby causing a backlog.

The message packaging in BPE improves performance by delivering several messagesto BPE process instances within one transaction. This can result in increasedthroughput. In certain cases this can also increase the runtime for individual messages,for example, due to the waiting time required to form a suitable message package.

Message packaging is particularly suitable for applications with great loads. In thesecases the throughput of a large number of messages is critical. For this reason itis necessary to check whether activating message packaging makes sense and isbeneficial for each individual process type. The use cases that can particularly benefitfrom message packaging are the so-called "collect scenarios". These include use casesfor collecting messages using one or several interfaces.



BPE Adapter

The BPE Adapter responds differently, depending on whether message packaging isactive for the process type or not.

• Message packaging is active for the process type:

The message is not directly transferred to inbound processing via qRFC. In thiscase the packaging job transfers the message in a package by calling the qRFCmodule SWF_XI_PROCESS_MSG.

• Message packaging is not active for the process type:

The adapter transfers the message directly to inbound processing by calling theqRFC module SWF_XI_MSG_RAISE_EVENT. This corresponds to the sameAdapter behavior when message packaging is deactivated globally.

Monitoring

If message packaging is globally active, you can use the transactions SWF_INB_MONand SWF_INB_ADM for monitoring, respectively for administering messages.The packaging job forms the message packages in accordance with the configuredparameters and transfers these packages to inbound processing via qRFC. Runtimeinformation for all inbound messages is administered in a central database table. Thisenables consistent processing of the messages across the various components. Allmessage packages formed are also administered in a special database table.



Activating and Configuring Message Packaging

To be able to make use of the benefits of message packaging for integration processes,you must activate it globally for BPE and individually for the process types for whichmessage packaging seems appropriate.

1. Schedule the packaging job of job class A with transactionSWF_XI_CUSTOMIZING.

Caution: To prevent blocking of all batch processes by long-runningbatch jobs of a lower job class, we recommend reserving at least onebatch process for jobs of job class A (transaction RZ04).

2. Schedule the reorganization job with transaction SWF_XI_CUSTOMIZING.

3. You activate message packaging globally for inbound processing with transactionSXMB_ADMIN.

a. Choose Configuration→ Integration Engine Configuration.

b. Under Parameter Categories, choose Category BPE.

c. Add a new entry for Category BPE with Parameter PACKAGING=1.

4. Activate message packaging for individual process types with the transactionSWF_INB_CONF.

5. Choose the process types for which you desire message packaging and underMessage Packaging, choose the Active indicator.

6. Make settings for the following:

a. Maximum Number of Messages – defines the maximum number of messagesin a message package.

b. Maximum Package Size KB – defines the maximum size of a messagepackage (the sum total of message sizes).

c. Maximum Wait Time – defines the maximum time that a message within apackage waits for transfer by the packaging job to inbound processing.

Hint: The first two criteria determine when a message package isregarded as complete, the maximum waiting time serves to restrict thelatency time.

To deactivate a criterion, set the value 0.





Exercise 11: Answer the following questionsabout BPE performance


• Provide a complete picture of the options for improving BPE performance

• Evaluate which of the options are suitable

Business ExampleYou have completed the integration test for newly developed integration processes inyour project. Now you want to optimize the performance of these processes.



Task:Please answer the following questions:

1. When should you use message packaging?

2. Which prerequisites should be met if you are to be able to use ccBPM integrationprocesses? Name at least three possible criteria:

3. With which transaction can you configure inbound processing?

4. Integration processes are used to page out application logic. Give reasons foryour answer.Determine whether this statement is true or false.□ True□ False




5. With which transaction can you set the delivery mode and queue assignment?

6. How can you improve performance with your process design?



Solution 11: Answer the following questionsabout BPE performance

Task:Please answer the following questions:

1. When should you use message packaging?

Answer: Many messages to the same recipient

2. Which prerequisites should be met if you are to be able to use ccBPM integrationprocesses? Name at least three possible criteria:

Answer: The use of ccBPM makes sense if the following prerequisites are met:

• Semantic relationships between messages

• Message-based communication

• Correlations can be defined uniquely

• Defined end condition

3. With which transaction can you configure inbound processing?

Answer: You can configure the inbound processing with the SWF_INB_CONFtransaction for each process type and client.

4. Integration processes are used to page out application logic. Give reasons foryour answer.

Answer: False

The Business Process Engine executes integration processes at runtime on theIntegration Server. The Integration Server is the central resource to exchangemessages between business systems, so you should do everything to avoidperformance problems. Recreating application logic worsens the performance ofBPE and makes monitoring more difficult.

5. With which transaction can you set the delivery mode and queue assignment?

Answer: These settings are made with transaction SWF_INB_CONF.




6. How can you improve performance with your process design?

Answer: With suitable settings for the start and end of a block you can expandthe scope of transactions. This reduces the number of write accesses to thedatabase.

In the properties of a process step, you can specify that the system does not starta new transaction when executing the step. This can also improve performance.



Lesson Summary






BIT430 Unit Summary









Course Summary BIT430

Course SummaryYou should now be able to:

• Describe the components of Business Process Management

• Use the process editor to implement ccBPM processes

• Test ccBPM processes

• Monitor ccBPM processes


Appendix 1Optional Exercise for Pattern - Overall Scenario:

Create Integration Process, Integrated in SAPExchange Infrastructure

Implement the following scenario in a process Z430_##:

Business system BS_BIT430_##_A and BS_BIT430_##_B both use the inboundHTTP adapter to send a message with the interface MI_MATERIAL_OUTB to aprocess.

Which system sends a message first is not specified or known. When both messagesare received, they are sent back to the opposite business system: BS_BIT430_##_Areceives the message from system B and BS_BIT430_##_B receives the messagefrom system A.

The inbound interface in the target systems is MI_MATERIAL_INB. Each messagecreates a file in XML format in the directory //localhost/xitrans/group##. A mappingbetween the message formats is not required.

If both messages are not received by the process within two minutes (test situation),trigger a missed deadline, create an alert, and end the process.

Use the pattern supplied for the process.


Appendix 1: Optional Exercise for Pattern - Overall Scenario: Create IntegrationProcess, Integrated in SAP Exchange Infrastructure BIT430


Appendix 2Solution for Optional Exercise Pattern - Overall

Scenario: Create Integration Process, Integratedin SAP Exchange Infrastructure

Required Actions in the SLD

1. Create two technical systems in the SLD

Type: Third Party

Step Name: TS_BIT430_##_A and TS_BIT430_##_B

host: bit430host##a or bit430host##b.

Product: BPMExercises of SAP. Do not change any software components.

2. Create a business system for each technical system

Step Name: BS_BIT430_##_A or BS_BIT430_##_B

Type: Third-Party System:

Assigned technical system: TS_BIT430_##_A or TS_BIT430_##_B

No logical name

Product remains selected

Assigned Integration Server: Integration Server


Appendix 2: Solution for Optional Exercise Pattern - Overall Scenario: CreateIntegration Process, Integrated in SAP Exchange Infrastructure BIT430

Required Actions in the Integration Directory

1. Import the business systems to the Integration Directory

Do not create any communication channels whilst doing so.

In the Service Without Party node, call the context menu for business systemsand choose New.

2. Create a file-receiver communication channel for both systems

Step Name: File_Receiver_##_A or File_Receiver_##_B

Use the template BIT430_File_Receiver_Template for the parameters of thecommunication channel

(menu Communication Channel - Import Template - see BIT430 template)

3. Change the following parameters:

Target Directory: ersetzen Sie ## durch Ihre Gruppennummer

File Name Schema: set xi_msg_von_B.XML for system A andxi_msg_von_A.XML for system B

File Construction Mode: Replace create with add time stamp

Required Actions in the Integration Repository

In a process Z430_##, realize the required scenario (## stands for your group number).


BIT430 Appendix 2: Solution for Optional Exercise Pattern - Overall Scenario: CreateIntegration Process, Integrated in SAP Exchange Infrastructure

Notes:

1. Work in software component SellSpareParts.

The outbound interface mi_material_outb and the inbound mi_material_inbare available

2. Create two abstract interfaces that are a copy of MI_MATERIAL_OUTB

Name: MI_Material_outb_abs##A or MI_Material_outb_abs##B

3. Create the process

Enter the required container elements MSG_A and MSG_B.

The correlation is based on the material number (MaterialID in interface)

Use the BpmPatternSerializeMultipleTrigger pattern provided.

If both messages are not received within two minutes, trigger a missed deadline.

The missed deadline triggers an alert 'Missed deadline process ZBIT430_## -Process cancelled'. Use the alert category PROCESS_##.

The process is ended once the alert has been triggered.



Further Required Actions in the Integration Directory

1. Transfer process Z430_## to the Integration Directory.

Use the same name

2. Create the receiver determination and the interface determination for the sendcase

Sender system: BS_BIT430_##_A or BS_BIT430_##_B and interfaceMI_MATERIAL_OUTB

Receiver: Process Z430_##

Interface: The abstract interface for the message from system A or B

3. Create the receiver determination, the interface determination, and the receiveragreement for the target system

Sending system: Process Z430_##

Interface: The abstract interface for the message from system A or B

Receiver: BS_BIT430_##_A or BS_BIT430_##_B

Interface: MI_MATERIAL_INB

The receiver agreement references the File_Receiver communication channel ofthe system in each case

Test the Scenario

Use the HTTP client, which is available under Additional Information for BIT430 forthis purpose.

1. Call: Additional Information in Integration Builder – Tools for BIT430 – HTTPClient

2. Details:

• GroupNR: Your group number

• Choose Material

Your material number, which is used for the correlation, is now set in XML

• The sender service in the first test is BS_BIT430_##_A

Choose Send

• In the sender service, replace A with B

Choose Send


BIT430 Appendix 2: Solution for Optional Exercise Pattern - Overall Scenario: CreateIntegration Process, Integrated in SAP Exchange Infrastructure

You have now sent both messages; your process should start and then save themessages as a file in your group directory.

Check your group directory

Process Integration Tools – Training Tools - Tools for BIT430. Choose Connect to PIServer Directory. Maintain the specified data. Choose Open PI Server Directory. Findyour group folder with the relevant files.




Appendix 3Optional: Combining ccBPM and Business

Workflow: Example Coding

Send the Message Data to a Workflow: Example Codingmethod Z_ORDERWFTRIGGER_INB~EXECUTE_ASYNCHRONOUS .

data: combined_so like ZBPMWF_SOC occurs 0 with header line.

combined_so-priority = input-WFDTYPE_MSG-priority.APPEND COMBINED_SO.

CALL FUNCTION ' Z_PROXY_TRIGGER_WORKFLOW '

TABLE

COMBINED_SO = combined_so .

endmethod.

FUNCTION Z_PROXY_TRIGGER_WORKFLOW.

*"----------------------------------------------------------------------

*"*"Local interface:

*" TABLES

*" VALUE(form_data) STRUCTURE …

*"----------------------------------------------------------------------

data: INPUT_CONTAINER LIKE SWR_CONT OCCURS 0 WITH HEADER LINE.

RETURN_CODE LIKE SY-SUBRC,

WORKITEM_ID LIKE SWR_STRUCT-WORKITEMID,

MESSAGE_LINES LIKE SWR_MESSAG OCCURS 0 WITH HEADER LINE.


Appendix 3: Optional: Combining ccBPM and Business Workflow: Example Coding BIT430

Filll input container

INPUT_CONTAINER-ELEMENT = …

INPUT_CONTAINER-VALUE = …

APPEND INPUT_CONTAINER.

* Start the workflow.

CALL FUNCTION 'SAP_WAPI_START_WORKFLOW'

EXPORTING

TASK = 'WS98100119'

IMPORTING

RETURN_CODE = RETURN_CODE

WORKITEM_ID = WORKITEM_ID

TABLES

INPUT_CONTAINER = INPUT_CONTAINER

MESSAGE_LINES = MESSAGE_LINES

EXCEPTIONS

OTHERS = 0.

IF RETURN_CODE <> 0.

* …

ENDIF.

* The WORKITEM_ID is the ID of the freshly triggered process.

ENDFUNCTION.

Transferring Data Back to SAP XI: Example CodingNo business object is included, and only the form data needs to be transferred back toSAP PI.

In the workflow, create a final step for calling the proxy and for returning the results toSAP PI.

method PUSH_ORDER_STATUS .

data: output type ZWFWFDTYPE_MSG,

obj type ref to ZWFCO_ORDERWFTRIGGER_OUT,

lo_sys_exception TYPE REF TO cx_ai_system_fault,

lo_async_messaging TYPE REF TO if_wsprotocol_async_messaging.

output-WFDTYPE_MSG-PRIORITY = sales_order-priority.

output-WFDTYPE_MSG-net_value = sales_order-net_value.

output-WFDTYPE_MSG-transdescription1 = sales_order-transdescription1.


BIT430 Appendix 3: Optional: Combining ccBPM and Business Workflow: Example Coding

output-WFDTYPE_MSG-transdescription2 = sales_order-transdescription2.

output-WFDTYPE_MSG-soldtoparty1 = sales_order-soldtoparty1.

output-WFDTYPE_MSG-soldtoparty2 = sales_order-soldtoparty2.

CREATE OBJECT OBJ.

lo_async_messaging ?= lo_clientProxy->get_protocol( if_wsprotocol=>async_messaging ).

lo_async_messaging->set_serialization_context(‘EG_MY_QUEUE_ID').

TRY.

CALL METHOD ZWFCO_ORDERWFTRIGGER_OUT=>EXECUTE_ASYNCHRONOUS

EXPORTING

OUTPUT = output

.

CATCH CX_AI_SYSTEM_FAULT INTO lo_sys_exception.

ENDTRY.

* Commit work will be executed by the workflow management system when the task is executed

endmethod.


Appendix 3: Optional: Combining ccBPM and Business Workflow: Example Coding BIT430


FeedbackSAP AG has made every effort in the preparation of this course to ensure the accuracyand completeness of the materials. If you have any corrections or suggestions forimprovement, please record them in the appropriate place in the course evaluation.


Date post:	14-Apr-2015
Category:	Documents
Upload:	tioraypiruso
View:	168 times
Download:	2 times

Bit430 en Col74

Documents