BIT430 - 2005-Q4 - A4 - Business Process Management

BIT430Business Process Management

SAP NetWeaver

Date

Training Center

Instructors

Education Website

Participant HandbookCourse Version: 2005 Q4Course Duration: 3 Day(s)Material Number: 50072509

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

Copyright

Copyright © 2005 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purposewithout the express permission of SAP AG. The information contained herein may be changedwithout 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

trademarks of 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 trademarksof Citrix Systems, Inc.

� HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, WorldWide Web 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 for

technology invented and implemented by Netscape.� SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP

EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.comare trademarks or registered trademarks of SAP AG in Germany and in several other countriesall over the world. All other products mentioned are trademarks or registered trademarks oftheir respective companies.

Disclaimer

THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLYDISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDINGWITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR APARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE,INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTSCONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT,INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANYKIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOSTPROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS OR INCLUDEDSOFTWARE COMPONENTS.

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 followingtypographic conventions are also used.

Type Style Description

Example text Words or characters that appear on the screen. Theseinclude field names, screen titles, pushbuttons as wellas menu 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 includereport names, program names, transaction codes, tablenames, and individual key words of a programminglanguage, when surrounded by body text, for exampleSELECT and 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 aprogram.

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.

2005/Q4 © 2005 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 © 2005 SAP AG. All rights reserved. 2005/Q4

ContentsCourse Overview ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

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

Unit 1: Business Process Management (BPM): Motivation andApproach..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Business Process Management � Overview ... . . . . . . . . . . . . . . . . . . . . .2BPEL4WS Import and Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16SAP Business Workflow and Collaborative Tasks in BPM .... . . 21ccBPM as a part of SAP Exchange Infrastructure... . . . . . . . . . . . . . 28

Unit 2: Business Process Management: Cross-CompnentBPM ...... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

First Steps in ccBPM ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Step Types (Part 1) and Correlation.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Step Types (Part 2) and Exception Handling... . . . . . . . . . . . . . . . . . . . 82Step Types (Part 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Process Patterns... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134

Unit 3: Business Process Management: Execution andTroubleshouting..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Business Process Engine: Overview and Runtime Cache .. .. .149Process Execution Monitoring.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185Message Monitoring .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196Event Trace and Troubleshooting... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204

Unit 4: Combining Integration Processes with BusinessWorkflow ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

Combining Business Workflow and ccBPM .... . . . . . . . . . . . . . . . . . .218

Appendix 1: Combining ccBPM and Business Workflow:Example Coding ..... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Appendix 2: BPM Procedural Model 2004 ..... . . . . . . . . . . . . . . . . . 231

2005/Q4 © 2005 SAP AG. All rights reserved. v

Contents BIT430

vi © 2005 SAP AG. All rights reserved. 2005/Q4

Course OverviewThe course provides an overview of Business Process Management (BPM) in SAPNetWeaver. It will discuss BPM in all its different components.

This course will also introduce the implementation of ccBPM processes and theintegration of ccBPM and SAP Business Workflow.

Target AudienceThis course is intended for the following audiences:

� Anyone who is interested in Business Process Management in SAPNetWeaver

� Customers who want to implement cross-component processes� Consultants in the area of Business Process Management� Project managers in the area of Business Process Management

Course PrerequisitesRequired Knowledge

� BIT400 SAP Exchange Infrastructure� Good knowledge of the configuration of SAP Exchange Infrastructure

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� Implement cross-component processes in your system landscape using SAP

Exchange Infrastructure

Course ObjectivesAfter completing this course, you will be able to:

� Describe the components of Business Process Management� Implement ccBPM processes using the process editor� Test ccBPM processes

2005/Q4 © 2005 SAP AG. All rights reserved. vii

Course Overview BIT430

� Monitor ccBPM processes

SAP Software Component InformationThe information in this course pertains to the following SAP Software Componentsand releases:

viii © 2005 SAP AG. All rights reserved. 2005/Q4

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

Unit OverviewThis lesson will provide a general overview of SAP Business Process Management.

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

� Explain the principles of Business Process Management in SAP NetWeaver� Describe the ARIS house� Explain the functions of SAP Solution Manager� Explain the idea of unified process modeling� Explain the basic principles of BPEL4WS� Export a business process� Import a business process� Describe the structure and possible applications of SAP Business Workflow� Define Collaborative Tasks and explain how you can use them� Describe the main features of ccBPM� Describe the integration scenario used in BIT430

Unit ContentsLesson: Business Process Management � Overview.... . . . . . . . . . . . . . . . . . . . . .2Lesson: BPEL4WS Import and Export .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Lesson: SAP Business Workflow and Collaborative Tasks in BPM ... . . . . 21Lesson: ccBPM as a part of SAP Exchange Infrastructure ... . . . . . . . . . . . . . 28

Exercise 1: Answer the following questions about ccBPM... . . . . . . . . . . 39

2005/Q4 © 2005 SAP AG. All rights reserved. 1

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

Lesson: Business Process Management � Overview

Lesson OverviewIn this lesson we will discuss Business Process Management in SAP NetWeaverand customer pain points in the context of Business Process Management. Youwill also learn how SAP wants to realize a unified modeling environment forbusiness processes in the future.

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

� Explain the principles of Business Process Management in SAP NetWeaver� Describe the ARIS house� Explain the functions of SAP Solution Manager� Explain the idea of unified process modeling

Business ExampleYour company wants to adopt an integration process for selling spare parts.The spare parts are selected in a non-SAP catalog/CRM system. The non-SAPcatalog/CRM system sends the spare part items in individual messages and anintegration process starts with a collect pattern: the order items are merged intoa single message. This message is used for preparations taking place in thecompany's sales and distribution (SD) system. A synchronous call is made tothe SD system to check whether missing materials have to be created. If so, thematerials are created by looping through a list of missing materials and sendingeach material to the receivers, materials management, and the SD system. Then asales order and a purchase order are created.

Let us image that SAP delivers a standard process for selling spare parts andthat your company wants to adapt the process to customer-specific requirements.Participants of the �selling spare parts� project want to know everything aboutthe different levels of Business Process Management with SAP NetWeaver andhow to implement processes.

Process Integration Challenges and NeedsDespite new technologies, the realization of innovative ideas is often a difficult,long-winded, and costly undertaking. The final result of many projects aimed atoptimizing processes fails to entirely meet the original expectations. Numerousfactors dictate that a company's process landscape must be flexible to changeover time as new markets are developed, new products are released, laws arechanged, business-partner networks are expanded, other companies are acquired,and processes are outsourced to service providers.

2 © 2005 SAP AG. All rights reserved. 2005/Q4

BIT430 Lesson: Business Process Management � Overview

Figure 1: Process Integration Challenges

It is difficult, however, to get the IT department�s technically-orientatedperspective on data, systems, and interfaces for integrating ever-expandingheterogeneous system landscapes with management and the relevant departments.The inability to bring together the business concepts of the relevant departmentand the viable options open to the IT department to realize these concepts meansthat strategic changes cannot be made on the fly. Management and experts fromthe departments define �what� needs to be done, while IT experts know �how� torealize the strategy and �with what� tools and systems. Over time, IT departmentshave had to face different evolving technologies, standards, and challenges toovercome. Today, process integration has to cover the integration of peer-to-peerconnections within the company boundaries, B2B process integration, androle-based end-user envolvement in processes.

Process integration software provides the infrastructure for automating businessprocesses spanning different applications, so called Application-to-Application(A2A) scenarios and company borders (B2B scenarios).

In an ideal world, process integration provides a clean separation between thedefinition of the process in the process model, the execution of the process inthe Business Process Engine, basic communication, routing and mapping beinghandled by the Integration Broker and adapters, and the implementation of theindividual functions in the applications. This separation would allow applicationfunctions to be reused and rearranged in many different processes.

In a real-life situation, however, things look a bit different. Applications typicallyhave an internal process/state model, which is usually implicit and depends onapplication configuration. Take the following example: In mySAP Supplier



Relationship Management (mySAP SRM), it is possible to create a purchase order(PO), send it out to a supplier and change the PO before having received a responsefrom the supplier. If an SRM customer would like to do business transactionswith its suppliers based on the industry standard protocol RosettaNet, he is facedwith the problem that RosettaNet is based on a request/response pattern, thatis, a PO request to the supplier must to be answered by a PO response from thesupplier before subsequent processes, such as PO changes, can be initiated. Insuch cases, process integration must match the different process models to allowprocess automation. Applications, therefore, first need to become more flexibleand make their internal process/state models explicit in order to move closer to anideal world.

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

An integration strategy that embraces an event-driven approach can deliverconsistent information across the enterprise far more rapidly. Often, event-drivenintegration is the only way to ensure consistency, since many events only havemeaning if captured at the precise moment they occur.

Tasks in Business Process ManagementA 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, andprocess steps can be clearly separated.

The IT department usually takes care of the integration tasks in heterogeneoussystem landscapes. Their goal is to integrate and automate system communicationand process execution within and across systems. Aligning business with IT is oneof the challenges that cross-organizational projects have to face.



One company;s process reality was described at CeBIT 2004 in Hannover. Thefollowing pain points in process management based on customer feedback wereassembled:

� PAIN POINT Process Design and Modeling

� Business owners and IT experts do not speak the same language and donot share the same concepts of processes or use the same tools

� Plethora of tools without linkage of views and objects� Project time lost due to internal alignment needs; projects running

out of budget� PAIN POINT Process Configuration

� Disruption between business logic and technical implementation;missing methodology

� No navigation from model to process configuration� Missing transparency and documentation� No reuse of process knowledge

� PAIN POINT Process Integration

� Hard-coded cross-component integration with a patchwork of solutionsfor A2A, B2B, and industry-specific processes

� No common process repository� Missing process management and control across applications and

enterprise boundaries

What is SAP's answer to this challenges?

SAP NetWeaver Business Process ManagementBusiness Process Management (BPM) in SAP NetWeaver allows companiesto continuously adapt their business scenarios and processes to new businessstrategies and meet the demands of today�s business environment. BPM � witha holistic view from modeling to monitoring � helps to close the gap betweenbusiness and IT. It allows IT organizations to react quickly to new requirementsand, at the same time, optimize the system landscape without impacting theoverall business processes.



Figure 2: Business Process Management in SAP NetWeaver

Business process management enables flexible, model-driven process design,implementation, execution, and support within and across business applications.BPM allows companies to model processes with different users performingdifferent roles and tasks, optimizing the communication between the processowner and IT expert. Process models designed on different abstraction levelsof modeling (business level modeling, configuration, and execution modeling)are used to configure processes running inside business applications and acrossapplications and enterprise boundaries. Model-driven execution allows thedeployment of process logic � abstracted in a standard notation format such as, forexample, Business Process Execution Language for Web Services (BPEL4WS) �on process execution engines or workflow management systems.

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 inconjunction with standard services provided by technical alert monitors.

Business Process Management can be understood as a closed loop, but what arethe tools to implement this loop?

BPM Procedural Models in SAP NetWeaverIn the following figure, you can see three different abstraction types of processmodeling: the process architectural model, the process configuration model, andthe process execution model.



Figure 3: BPM: Components for modeling and implementation

ARIS for SAP NetWeaver enhances BPM with a business modeling function.The joint solution contains a universal and integrated description of the processarchitecture from the business model through to implementation of the process bySAP Solution Manager, and integration of executable processes in SAP XI andthe applications by SAP Business Workflow. At the uppermost level (processarchitecture model), the company's process architecture is structured from astrictly business perspective without any technical references. On the basis of thisarchitecture model, you can flexibly describe the company's process strategy.

The next level (process configuration model) describes the configuration of theprocess down to the individual steps within one or more scenarios. Configurationmodels are used here to describe the processes and process steps beyond thevarious components of mySAP Business Suite. A model of this kind is alsoused to derive customizing activities, to navigate to SAP systems, and to definemonitoring-relevant information (for example, transaction threshold values).For this purpose, SAP Solution Manager provides reference processes that arecustomized during implementation and that can be used for the purposes ofoperations and process monitoring. Process models can be synchronized betweenARIS for SAP NetWeaver and SAP Solution Manager, though SAP referencemodels are placed in the process architecture or, if required, adapted to fitcustomer requirements and then put in a detailed request specification (blueprint),which is loaded into a project in SAP Solution Manager. The model is thenrealized technically there.

On the next level of the process model (process execution model), modeledprocesses are used for execution by SAP Exchange Infrastructure and theapplications. Cross-system, inter-application processes can be flexibly connected



to the application processes of the individual systems, and both individualinterfaces can be orchestrated in a comprehensive process logic. Integrationscenarios and processes, which are partly used for business partner communicationin industry-specific instances (for example, RosettaNet), can also be madeavailable to the complete process architecture in ARIS.

ARIS Integration in SAP NetWeaverWith ARIS Web Designer, you can create, edit, and manage ARIS models. ARISWeb Designer is used to record and graphically describe business processes.These representations, which can be recorded intuitively and also include graphicmethods, allow easy access to the information offered. The various perspectiveson business processes from organizational, data, and function views allow you tofocus on relevant partial aspects, while the process view displays these aspects intheir entirety.

Figure 4: The ARIS House

The ARIS house describes the ARIS methods and diagram types that can beused to describe business processes from a business perspective. This includesorganization views, functional views, data models, control data (process flows),and output views (product, services).

Organizational units/Organizational chartSales, purchasing, accounting, manufacturing, and so on.



Data/Technical terms modelTechnical terms are taken from the company's jargon. A technical term candescribe a group of items or an individual item. A technical term may have arelationship to other technical terms.Examples: Order data, customer data, supplier data, sales data, andproduction data.

Function/Function treeA function is a technical task, a procedure, or an activity performed on anobject to support one or more company goals. A function is a carrier oftimes and costs.Examples: Check customer credit rating, enter receipt of goods, checkcustomer inquiry, and so on.

Control/ProcessCustomer order received, order confirmation, order confirmation created,and so on.Methods: Value-added chain diagram (VACD), Extended Event-DrivenProcess Chain (eEPC), Function Allocation Diagram (FAD).

Output (Product/Service)/Product treeSales services including customer order confirmation.

The design objects above are used to navigate in the process architecture of acompany. ARIS knows three levels to maintain processes.

The highest level describes the process architecture of a company without anytechnical reference. Who does what with whom in what sequence � these are thequestions. The results of this analysis allow you to design the target processes.On this highest level, the overview models, you find value-added chain diagramsand organizational charts. Organizational charts and value added chain diagramsare not related to one another.



Figure 5: ARIS Modeling Levels

On the next level, modeling level 2, rough event-driven process chain (EPC)models describe precisely for what instance a value-added chain diagram object(for instance, sales order processing) looks like in a more detailed way. Modelinglevel 2 refers to designing, optimizing, and controlling business processes.

Even an EPC can be used to describe the architeture in depth. On modeling level 3you find a much more detailed view on such an event-driven process chain with,for instance, added information about IT systems that perform different actionsor data about who is responsible for a process step. This EPC on level 3 can beassigned to other process chains or to functional allocation diagrams that describemore functional information.

Product services/product service trees are other overview models that are notdirectly related to the value-added chain diagrams. What is related to thevalue-added chain diagram and EPC is the function tree. This is necessary if youwant to map functions used in EPCs to SAP functions. For example, a processstep column display in a process chain should be mapped to an SAP process stepthat can also be understood by the SAP Solution Manager.

Therefore you need an integrated modeling tool that not only provides functionsto describe the process flow, but integrates all possible information, includingquestions refering to the company's organizational unit and technical questions.

ARIS for NetWeaver allows a central administration of this process informationusing a multilingual repository.

SAP Solution Manager and ARISAfter the design of business processes, the next step is to transfer the processesinto a technical software environment.



SAP supports the implementation of mySAP Business Suite with the SAPSolution Manager.

Figure 6: SAP Solution Manager: Functions

The SAP Solution Manager is a platform that provides integrated support of thelife cycle of a business solution, from the Business Blueprint via configuration toproduction operation. The SAP Solution Manager provides central access to tools,methods and preconfigured contents, which you can use during the evaluation andimplementation, as well as in operation processing of your systems. The SAPSolution Manager also provides an authoring function with which you can createyour own project templates, which you reuse in an implementation. The SAPSolution Manager is thus also a tool for SAP partners and companies performing aglobal rollout. You can manage and monitor systems and business processes inyour solution landscape in operational processing. You can set up and run yourown solution support with the SAP Solution Manager.



The following list gives you an overview what predefined content is deliveredwith SAP Solution Manager in 2005.

� mySAP CRM

Ninety business scenarios with 280 CRM processes for all CRM keycapabilities (CRM 4.0 � complete coverage)

� mySAP SRM

Six business scenarios for SRM 3.0 (complete coverage)

� mySAP SCM

Demand Planning/Multilevel ATP including SD Sales Order Processing

� mySAP HR

SAP Learning Solution 100 and 200 and Manager Self Service (MSS) 50.1

� mySAP PLM

Collaboration Projects (cProjects Suite 2.0), Design Collaboration withcFolders (cProjects Suite 2.0), Content Consolidation (MDM 2.0), MasterData Harmonization (MDM 2.0), and Central Data Maintenance (MDM 2.0)

The structure of the SAP Solution Manager is based on scenarios, which containbusiness processes. Each process refers to process steps. The scenarios andprocesses can be loaded by the user from the Business Process Repository.

Figure 7: Business Processes in SAP Solution Manager



The above figure shows you one example in the Business Process Repositoryof SAP Solution Manager; you see the scenario Catalog & Order Managementrefering to four business processes. One of the processes (billing) consists of foursteps which are not only listed, but are shown in a graphical mode we know fromSAP Exchange Infrastructure: the swim lanes.

These process models can be exchanged between SAP Solution Manager andARIS. ARIS can import the model, and then it can be changed according thecompany's specific request. At the end, the process model is transfered back to theSAP Solution Manager and can be used in a Business Blueprint.

You create a Business Blueprint during the implementation of your mySAPsolution, to document the business processes in your company, and to decidewhich processes you want to implement in your SAP system.

You use the Business Blueprint in the SAP Solution Manager during the realization(configuration and testing) phase. You reuse the project structure you created inthe Business Blueprint phase to configure and to create test plans. You can alsodisplay, change, and enhance project documentation created during the BusinessBlueprint phase during configuration.

On the Way to a Unified Modeling EnvironmentWe can say that a significant component of the strategic joint development venturebetween SAP and IDS Scheer (the company that invented the ARIS tool) is thedevelopment of methods and tools for consistent process modeling.

Figure 8: The Way to a Unified Modeling Environment

The products and know-how of both companies will be brought even closertogether. Design, modeling, and model-based configuration will take place ina technically integrated solution, in a unified modeling environment as part of



the Enterprise Service Repository in SAP NetWeaver. There, on the basis of anunified metamodel, users will be able to perform various role-specific tasks in aunified modeling environment. By integrating business proces -knowledge withthe technical orchestration of enterprise and application services, it is possible torealize an evolutionary service-orientated architecture on the basis of businessrequirements. New �Next Practice� processes can be specified on a businessbasis, and developed on the basis of existing �Best Practice� applications and theirservices, which are encapsulated as functions, business objects, and applicationlogic. Companies can start today with the universal, methodical integration ofbusiness processes from the business perspective through to technical realization.Any models for process architecture, configuration, and execution developedtoday can also be used in the future, thereby guaranteeing investment security.

Implementation of Business Process ManagementWithin SAP NetWeaver, separate tools are used to define and implement businessprocesses. The following figure shows how Business Process Management isintegrated in SAP NetWeaver.

Figure 9: Implementation of BPM in SAP NetWeaver 04

With SAP Business Workflow, you can define and execute processes runningin a local system.

With cross-component Business Process Management (ccBPM), you can createprocesses that include multiple systems of your system landscape (both SAP andnon-SAP systems) and that can exchange data between the systems.



Lesson Summary

You should now be able to:� Explain the principles of Business Process Management in SAP NetWeaver� Describe the ARIS house� Explain the functions of SAP Solution Manager� Explain the idea of unified process modeling



Lesson: BPEL4WS Import and Export

Lesson OverviewThis lesson will provide you with essential information about the BPEL4WSstandard and its use within ccBPM.


� Explain the basic principles of BPEL4WS� Export a business process� Import a business process

Business ExampleYour company uses a special business process that is implemented with SAPExchange Infrastructure 3.0 ccBPM. One of your partners would like to use thesame business process. He uses SAP Exchange Infrastructure 3.0; however, hisproduct is BPEL4WS compliant. Therefore, you can just export your businessprocess in the BPEL4WS format and hand it over to your partner, who can thenimport the process in his modeling tool.

BPEL4WS IntroductionBPEL4WS stands for Business Process Execution Language for Web Services.It is a standard language for the formal specification of business processesand business interaction protocols. The standard was initiated by BEA, IBM,Microsoft, SAP and Siebel Systems to ensure the interoperability for descriptionand communication of business processes. Everything is therefore based on Webservices. It is an XML language and defines the way in which a business processcan be executed by the use of Web services. If this standard is used, modelinginformation can be easily exported into another vendor's modeling tool and viceversa.

Hint: For more information on BPEL4WS, have a look athttp://ifr.sap.com/bpel4ws.

BPEL4WS in ccBPMWithin SAP XI 3.0, BPEL4WS is used as the standard modeling language of thebusiness processes in ccBPM. Therefore, you can have a look at the BPEL4WSrepresentation at any time just by changing into the BPEL4WS Display viewinside the Edit area. The corresponding data type definitions are shown inside theOutput area when switching to the Web Service Definition Language (WSDL)


http://ifr.sap.com/bpel4ws

BIT430 Lesson: BPEL4WS Import and Export

view. BPWEL4WS can be used as exchange format for exporting an integrationprocess to a non-SAP system and executing it there. Conversely, BPEL4WScan also be used for importing an integration process from a non-SAP system tothe SAP Exchange Infrastructure. The exporting and importing is done fromthe BPEL4WS Display view.

Figure 10: BPEL: SAP XI and ccBPM

Hint: Please consider that BPEL4WS as an exchange format is designedfor exporting and importing integration processes to and from non-SAP/SAP systems. It is not intended for exporting and importing integrationprocesses between Integration Repositories on different SAP XI systems.In such a case, you should use the Integration Repository Import functioninstead.

BPEL4WS ExportThe Export function exports the integration process definition as a BPEL4WSrepresentation. Moreover, data types, message types, and operations thatare referenced in the process definition are exported as a WSDL description.Therefore a .zip file is generated, containing a .bpel and a .wsdl file. The .bpel filecontains the process definition as displayed in the BPEL4WS view. The .wsdl filecontains the referenced data types, messages types, and operations. The name ofthe .zip file is arbitrary and will be used for the .bpel and .wsdl file as well.

To create a valid BPEL4WS description when exporting an integration process,you have to define the integration process from the Integration Repository andspecify the partner link type and partner link. A partner link type describesthe relationship between two services and the role from each service. A partnerlink BuyerSellerLink can, for example, define the roles Buyer and Seller. The



services interacting with an integration process are defined by the partner link.Each partner link has a partner link type, and multiple partner links may have thesame partner link type. Consider, for example, a procurement process that caninteract with different vendors but uses the same partner link type for all vendors.A partner link type is referenced on the abstract interface.

Take into account that messages and, respectively, abstract interfaces can be usedin different ways since they are inbound and outbound interfaces in one. Forexample, in one step an interface can be used as a receiver, and in another stepit acts as a sender. In such a case you should ensure that you enter a meaningfulname for the partner link to avoid confusion when you later import your process.This information has to be maintained manually because the relationship betweenthe two services and the role held by each service is configured in the IntegrationDirectory; therefore, it is not part of the integration process and cannot be exportedautomatically.

BPEL4WS ImportThe BPEL4WS Import imports the BPEL4WS definition of an integration process.The import expects a .zip file, containing a .bpel and a .wsdl file of the samename. If a import is started in an existing integration process, this process will beoverwritten. Furthermore, the import expects that the data types, message types,and operations (message interfaces) that are referenced in the process definitionare already available in the relevant namespace. This is caused by the fact thatthe information from the .wsdl file does not import the data types and so on, butis just used to support the import procedure. For example, the process definitionto be imported has a reference to the message OrderRequest in the namespacehttp://sap.com/BPEL4WS. This definition is now imported into the softwarecomponent version BPEL_SWC. The import then expects that the mentionednamespace is available in the Software Component (SWC) and that it contains themessage OrderRequest.

Figure 11: BPEL4WS: Import Wizard


http://sap.com/BPEL4WS

BIT430 Lesson: BPEL4WS Import and Export

In ccBPM, message-based container elements are used in the properties of certainsteps and in correlations. These container elements correspond to variables withinBPEL4WS. A container element references a message interface, which referencesa message type. In spite of this, a BPEL variable references a message typedirectly. Because of this, the message interface specification is missing when aBPEL variable is imported. Therefore, it is advisable that you create the requiredmessage interfaces in the Integration Repository before starting the import. Duringthe import they can be assigned within the import wizard (see the above figure).If the message interfaces are not created before the import starts, the processdefinition will still be imported, but the values between the various propertied willbe empty and you will have to fill them later. Otherwise you will not be ableto activate the process.



Lesson Summary

You should now be able to:� Explain the basic principles of BPEL4WS� Export a business process� Import a business process

Related InformationFor more information about restrictions to the BPEL4WS import and exportfunctions see SAP Note 709650.


BIT430 Lesson: SAP Business Workflow and Collaborative Tasks in BPM

Lesson: SAP Business Workflow and CollaborativeTasks in BPM

Lesson OverviewThe lesson briefly describes the two other parts of Business Process Management:SAP Business Workflow and Collaborative Tasks (ad hoc workflow).


� Describe the structure and possible applications of SAP Business Workflow� Define Collaborative Tasks and explain how you can use them

Business ExampleBefore starting with the ccBPM project in your company, you want to knowsomething about the other parts of Business Process Management: SAP BusinessWorkflow and Collaborative Tasks.

Application Areas ofSAP Business Workflow in SAPSystemsSAP Business Workflow supports business processes that run in a local SAPsystem. SAP Business Workflow is part of the SAP Web Application Server(SAP Web AS) and, therefore, is available in every SAP system. SAP BusinessWorkflow ensures that work steps are guaranteed to be sent in real time to theresponsible collegues. It can supply the end user with all the information requiredfor the step to be processed.

SAP Business Workflow is not tied to any particular application, but operatesuniformly across all applications.

One of the most common applications of workflow is in approval procedures.Examples are: the approval of a shopping card in SAP Enterprise BuyerProfessional, , the approval of a purchase requisition in materials management, theapproval of a parked invoice in mySAP ERP Financials and so on.



Figure 12: SAP Business Workflow: Application Areas

The workflow that demonstrates the functions of SAP Business Workflow in everysystem is workflow WS30000015: Process notification of absence. WS30000015is the internal key of the workflow. This workflow is started every time anemployee creates a notification of absence. The employee's manager thgen gets awork item and can approve or reject the created notification of absence. Whenhe or she rejects the request, the employee gets back a work item and can updateor delete his or her notification of absence. In case of updating the request, themanager gets another work item and can approve or reject again.

Workflow can be used to optimize the flow of information within an organization,because you can inform staff about all kinds of changes. Workflow also supportserror handling and exception handling by enabling you to trigger subsequentprocesses when threshold values are reached, when errors occur (for exampleduring IDoc processing), or when normal values are deviated from.

You can use deadline monitoring to monitor workflow-controlled processes.In other words, you determine a time and date by which a process step mustbe completed. When the deadline passes, subsequent actions are triggeredautomatically.

SAP components ship standard workflows for predefined business scenarios. Inhuman resources, this might include workflows for travel cost management andrecruitment management. In the area of finance, there is a workflow that archivesincoming documents in a third-party archive system and then creates work itemsfor creating SAP documents. At the end, the document in the SAP system databaseand the paper document in the archive system are linked together, and both can bedisplayed from the SAP system at any time from anywhere in the world.



Basic Principles of Business WorkflowBusiness workflow is defined as: the right work at the right time to the rightagent. What does this mean exactly?

You define who the �right � agents are when you design and model a workflow.In our example above, you use a rule for agent determination to find the correctsupervisor for the person who created the notification of absence. You can alsodefine organizational units, positions, jobs, users, or roles in transaction PFCG.

When you model the workflow, you have to ensure that it starts at the �right�time. Workflows often start when an event is triggered by an application becausesomething special happened in the system. For example, if somebody callstransaction SWXF and creates a notification of absence, a workflow event�created� is triggered by the application. The workflowWS30000015 then startsbecause it is linked to this event.

You have also to ensure that the process steps are modeled in the �right� order. Abusiness process is a sequence of individual steps. Together, these steps form theworkflow definition (the process definition).

Figure 13: Architecture of SAP Business Workflow

At workflow level , the �right� work in a process step stands for the execution of amethod of an object type in the Business Object Repository (BOR) or of an ABAPclass (SAP Web AS 6.40 and higher). The workflow Notification of Absence usesthe object type FORMABSENC and its methods approve, update, delete. Everycoding you can write down in a method can be the content of a step in a workflowprocess. A step in the process can also be used to control the process, for example,



to allow loop processes, to query conditions, or to fill the interface (container) ofa step with values. In the process Notification of Absence, we use a loop andcontainer operations to set the values for the condition which that ends the loop.

Hint: For more information about modeling and starting workflows,finding the relevant agents, or defining work items, attend SAP coursesBIT600, BIT601, and BIT610.

The Universal Worklist in SAP Enterprise PortalThe universal worklist enables SAP Enterprise Portal end users to managetheir work by bringing together assignments from different workflow systems,including SAP R/3 Business Workflow, alerts, and Java ad hoc workflow.

Figure 14: Universal Worklist in SAP Enterprise Portal

The universal worklist:

� Gives users a unified and centralized way to access their work and relevantinformation

� Aggregates workflow task items from multiple and different systems in oneuniversal list from WebFlow and Java ad hoc workflow

� Displays additional information as required from document and objectrepositories, including attachments and other details

� Enables end users to make direct decisions and actions� Supports end users in personalizing the presentation of work items



The universal worklist (UWL) provides task-related lists to assist you to:

� Perform tasks assigned to you� Create tasks and assign them to others� Send task-related information to others� Request information from others� Track the status of task requests

A separate display and user interface is provided for each UWL list view category.The UWL allows you to select which list category to display. Above each list is aPersonalize View link. Select this link to modify the list of categories displayed,sorting, visible attributes, and other options. Many interactive features of theUniversal Worklist iView are the same or similar to other iViews in the portal. Thetext below focuses on those interactions unique to the UWL.

Ad Hoc Workflow/Collaborative Tasks in SAPEnterprise PortalCollaborative Tasks/ad hoc workflow allows users to spontaneously create andtrack tasks through task definition wizards.

The Ad Hoc Workflow Wizard allows an end user to build and initiate customworkflow processes. Each workflow process potentially produces work items thatare displayed in the universal worklist (UWL). The end user can:

� Create processes consisting of a number of tasks that persist until done� Assign individual tasks to separate users

Specifically, ad hoc workflow is deployed as a portal service and is packaged aspart of the Knowledge Management (KM) platform. It uses some KM components,including the scheduling service and the notification service. Leveraging the KMplatform, ad hoc workflow will act as a subcomponent of the UWL. You can buildand initiate ad hoc workflows easily through the wizard, track them, and receivework items generated by ad hoc processes.

Prerequisites to use the ad hoc workflow are:

� You must be a portal user with assigned appropriate portal role to accessthe universal worklist.

� You must know what process you are trying to implement and who theparticipants are.

� As a process initiator, your e-mail address must be properly configured inyour SAP User Management Engine (UME) data.

As a result of the wizard, the process participants (assignees, recipients,nominators, approvers) see the workflow item in their task list. When therecipients execute work items, notifications are sent to those users who were



specified as trackers when the task was created. The trackers can also view thestatus of an workflow under Tasks in the universal worklist and view details ofthe appropriate process. All steps that have been executed in the process so farare displayed. After completion of a process all steps, along with the commentsentered by the process participants, are displayed under Completed Tasks in theprocess initiator's universal worklist.

Integration of ccBPM and SAP Business WorkflowTo automate a complete business process, you will want to make use of thedifferent workflow engines provided by SAP NetWeaver: ccBPM and SAPBusiness Workflow. At the beginning of a project, you have to analyse the processand decide how much of it takes place in one engine or the other. You have todecide which will be the leading engine.

In principle, we can say that if many components are involved, the emphasis willbe on a central SAP XI cross-component process handling the process integrationspawning separate local workflows for the human interaction.

But if the lion's share of the proces is mainly human-task oriented, then the SAPBusiness Workflow will take the driver's seat and spawn small cross-componentprocesses to handle the integration with other components.



Lesson Summary

You should now be able to:� Describe the structure and possible applications of SAP Business Workflow� Define Collaborative Tasks and explain how you can use them



Lesson: ccBPM as a part of SAP Exchange Infrastructure

Lesson OverviewSAP Exchange Infrastructure (SAP XI) enables systems to communicate andexchange data with each other by means of XML messages. The messagesare 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 XI; however, it is processed statefully with ccBPM.


� Describe the main features of ccBPM� Describe the integration scenario used in BIT430

Business ExampleYour company wants to implement a cross-component process and you need tounderstand the principles of ccBPM in SAP Exchange Infrastructure.

Business Process Management with ccBPMccBPM is available in SAP XI 3.0 and higher and is used to model, execute,and monitor automatic processes that extend beyond system and applicationboundaries. With ccBPM, design, configuration, and execution of businessprocesses are completely integrated in the SAP Exchange Infrastructure.


BIT430 Lesson: ccBPM as a part of SAP Exchange Infrastructure

The following lists the main functions of ccBPM:

� With ccBPM you can design, execute, and monitor automated processesacross different applications.

� ccBPM is an integral part of SAP XI.� 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 WebServices)

� ccBPM supports industry standards.

� RosettaNet (RNIF adapter, PIP, and so on)� ccBPM provides technical process monitoring.

By creating an Integration Process in the Integration Repository, you designyour business process. An Integration Process is an executable cross-componentprocess, determining the processing of messages at runtime. In order to definesuch a process, single step types are set up together in a graphical editor. For thatpurpose, the editor provides several step types. The step types can be divides intotwo sections: step types for processing messages, like the receiving or sendingstep, and step types to manage the process flow. This may be the loop or switchstep.



Figure 15: ccBPM Architecture: Relationship Among Objects

It should be stated that the messages are processed statefully. The process state ispersistent on the Integration Server. Therefore, an integration process can wait foran arbitrarily long time for an event, or have a controlled react time. Furthermore,messages can be processed inside an integration process, for example, theintegration process can collect messages and send them in a defined order.

Unlike simply processing an inbound message by means of a receiverdetermination followed by a mapping to the target format, in ccBPM, the messageis processed statefully. The status of the integration process is persisted on theIntegration Server to await the arrival of further messages. Messages that belongtogether are put in correlations so that messages that arrive later can be assigned toan instance of the integration process.

ccBPM is integrated in all components of SAP XI: you define both integrationprocesses and integration scenarios at design time in the Integration Repository.You configure the BPM parameters in the Integration Directory. At runtime, theIntergration Engine determines whether the message needs to be saved so that thecorrelation can be used later to further process the message. On the IntegrationServer, the Business Process Engine processes the BPM messages.



Correlation Between MessagesThe following figure shows an example: The Integration Server waits formessages arriving from business systems #1, #2, and #3. When all awaitedmessages arrived at the Integration Server, a combined message will be send tobusiness system #4. This can only be achieved if the information about messagesalready arrived at the server (the business process), is deposited as a state.

Figure 16: Correlation Between Messages

But how does the process engine know which messages belong together? Animportant feature in the integration process is the correlation you can use to definethe relationship between messages. If messages do not belong to the process, itmust be ensured that they do not disturb the process. For that reason, a correlationis defined, combining only messages that belong to each other. For example, anorder can be correlated with its invoice via the corresponding order number.

Configuration is done in the Integration Directory, as usual. You just have todefine receiver 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.

ccBPM Architecture OverviewThe ccBPM architecture consist of two parts: the design time (Integration Builder)and the runtime (Integration Server). The design is done in the Integration Builder.First, you define your integration process in the Integration 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. Withinthe Integration Server, the Integration Engine is responsible for the routing,mapping, and channel determination. The Business Process Engine (BPE) hoststhe correlation handling and process execution. Therefore, the BPE ensures thatdifferent messages are correlated in the right way and that messages belongingtogether are executed in the same process.

Figure 17: 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.The receiver determination is looked up in the Integration Directory and,in this case, an integration process is found as receiver. If the interfacedetermination refers to an interface mapping, it would be carried out.

2. After the output processing, the message is forwarded to the BusinessProcess Engine. First the message is checked to see if it correlates with anyother message and whether an instance is waiting for this message. Thismessage can start a process as well.

3. If the Business Process Engine gets to a sending step, the current message issent to 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 XI regarding ccBPM isshown in the following figure. Within the Integration 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, in turn, refers to abstract interfaces, context objects, andinterface mappings. Abstract interfaces refer again to message types, IDocs, orRemote Function Calls (RFCs). The interface mapping refer to message mappings.Looking at the Integration Directory, the integration process is arranged within aparty and refers to the active version of a process from the Integration Repository.Moreover, routing and mapping relations are referred to this process. Looking atthe bottom, the cache and runtime, there is again the process, this time referring tothe process definition out of the Integration Directory. During runtime, the processrefers to XML objects and correlations.

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 18: Integration Scenario: Procurement of Spare Parts

The business case for the complete process is a simplified procurement of spareparts. The spare parts are selected in a non-SAP catalog/CRM system, which issimulated by a Web Dynpro user interface.



Figure 19: CRM System: Simulated by a WebDynpro

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 orderitems are merged into a single message that is sent to the SD system to check theavailability of the materials. This is done using a synchronous call.

If the materials have to be created, the materials are created by looping througha list of missing materials and sending each material to the receivers (MM andSD systems), which are found using a receiver determination step. Then a salesorder and a purchase order are created. It must be possible to create both orders; ifthis is not possible, no order is created.

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: Web Dynpro (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 20: 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 synchronously sends a message to the SAP system tocheck whether the materials exist.

3. If the CRM system sends a new material, the material will be created intwo other systems.

4. A purchase order and a sales order are created.5. The purchase order is sent to the supplier, and the order confirmation sent by

the supplier is acknowledged.

In order to focus on the modeling of the process, we hide complexity. Therefore,we have simple message types and there are no mappings between processinterfaces and the interfaces used by the business systems.

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

The Integration Directory is preconfigured.



Implementation and Configuration of the IntegrationProcess in the Integration BuilderThe integration process of ccBPM retrieves messages from a business systemand sends messages to a business system. Therefore, the following objects arenecessary or can be used:

� Outbound interface of a business system (sender)� Retrieving interface of the process� Sending interface(s) of the process� Inbound interface of a business system (target)� If necessary, mapping information

Message interfaces in integration scenarios without an integration process arealways defined as inbound or outbound; that is, they represent an inbound oroutbound interface.

Message interfaces used in an integration process are defined as abstract interfaces;they are not linked explicitely to an inbound or outbound message.

After having defined the necessary objects in the Integration Repository you candefine your integration process using the process editor. After having finished theintegration process, it is useful to define an integration scenario with the relevantbusiness systems and the integration process.

An integration scenario can be used to configure the scenario in the IntegrationDirectory.

You perform the following steps when you configure an integration scenario,which contains an integration process:

� Define the integration process in the Services without Party section.� Define services for the relevant business systems.� Create receiver and interface determination, which can be used to send a

message from the sender system to the integration process.� Create receiver and interface determination(s), which can be used to send

a message from the integration process to one or n target systems. Youhave to define such a determination for each different send step in yourintegration process.

� If necessary, define additional conditions in the receiver determinations.� Create collaboration agreements for the messages that are sent by the

integration process.



You can define these objects manually or you can use an SAP XI tool, theIntegration Scenario Configurator. To use this tool, you must create a configurationscenario in the Integration Directory by grouping together all configuration objectsthat result from the configuration or that are reused from elsewhere.

Note: An integration process can use all objects that are available inthe SWCV of the process.

Reasonable Use of Integration ProcessesPlease note the following requirements for sensible use of integration processes:

� The communication between the involved business systems can be realizedusing XML messages.

� The XML messages can be correlated; that is, there are relations between themessages (for example, sales order messages and items of the sales order).

The correlation must be an unambiguous one.

� No user interaction is necessary in the integration process.

Note, however, that integration processes can be combined with businessprocesses.

� The integration process should have an end condition.

To avoid neverending processes, you should define an end condition for anintegration process.



Exercise 1: Answer the followingquestions about ccBPM

Exercise ObjectivesAfter completing this exercise, you will be able to:� Explain how implementation and configuration is performed in the

Integration Builder� Explain the tasks of the Integration Engine� Explain the purpose of ccBPM

Business ExampleYou are member in a ccBPM project and you need to be able to answer thequestions of some new members.

Task:Answer the following questions.

1. What modeling standard is supported by ccBPM?

2. What is the purpose of ccBPM?

3. How is a business process implemented?

Continued on next page



4. Where is the configuration performed?

5. Into how many parts can the ccBPM architecture be divided?

6. What are the tasks of the Integration Engine?



Solution 1: Answer the followingquestions about ccBPMTask:Answer the following questions.

1. What modeling standard is supported by ccBPM?

Answer: The modeling standard supported by ccBPM in order to easilyexchange business processes is BPEL4WS 1.1.

2. What is the purpose of ccBPM?

Answer: The purpose of ccBPM is to design, execute, and monitorautomated processes across different applications or different businesspartners.

3. How is a business process implemented?

Answer: A business process is designed by creating an integration processwithin the Integration Repository.

4. Where is the configuration performed?

Answer: Configuration is performed as usual in the Integration Directory.

5. Into how many parts can the ccBPM architecture be divided?

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

6. What are the tasks of the Integration Engine?

Answer: The Integration Engine, which is located within the IntegrationServer, is responsible for routing, mapping, and channel determination.



Lesson Summary

You should now be able to:� Describe the main features of ccBPM� Describe the integration scenario used in BIT430

Related Information

� For further information about the configuration of ccBPM processes seethe units about BPM in SAP course BIT400 and the relatedSAP ExchangeInfrastructure documentation.


BIT430 Unit Summary

Unit SummaryYou should now be able to:� Explain the principles of Business Process Management in SAP NetWeaver� Describe the ARIS house� Explain the functions of SAP Solution Manager� Explain the idea of unified process modeling� Explain the basic principles of BPEL4WS� Export a business process� Import a business process� Describe the structure and possible applications of SAP Business Workflow� Define Collaborative Tasks and explain how you can use them� Describe the main features of ccBPM� Describe the integration scenario used in BIT430


Unit Summary BIT430


Unit 2Business Process Management:

Cross-Compnent BPM

Unit OverviewIn this unit, you will learn about the process editor and step types.


� Describe the graphical process editor� Work with 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� eExplain the concept of exception handling in ccBPM� Define exceptions in integration processes� Explain and use step type fork� Explain and use step type switch� Explain and use step type Receiver Determination� Explain and use the modes ParForEach and ForEach in a block step� Describe common design patterns for integration processes� Use the process patterns shipped by SAP in your integration processes

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

Exercise 2: Receive Order Items (Part 1) .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Lesson: Step Types (Part 1) and Correlation .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Exercise 3: Receive Order Items (Part II) - Exercise and extendedsolution - usable as a tutorial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71


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

Exercise 4: Receive Order Items (Part II) - Exercise and Short solutionrefer to the example solution Solution_1 in the Integration Repository,software component SellSpareParts .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Lesson: Step Types (Part 2) and Exception Handling ... . . . . . . . . . . . . . . . . . . . 82Exercise 5: Preparations: Material Check in SD System - Exercise andextended solution - usable as a tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Exercise 6: Preparations: Material Check in SD System - Exercise andshort solution refer to the example solution Solution_2 in the IntegrationRepository, software component SellSpareParts.. . . . . . . . . . . . . . . . . . . . . .103

Lesson: Step Types (Part 3) .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113Exercise 7: Create Materials - Exercise and extended solution - usableas a tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119Exercise 8: Create Materials - Exercise and short solution refer to theexample solution Solution_3 in the Integration Repository, softwarecomponent SellSpareParts ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .129

Lesson: Process Patterns .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134Exercise 9: Test Your Knowledge ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .143


BIT430 Lesson: First Steps in ccBPM

Lesson: First Steps in ccBPM

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


� Describe the graphical process editor� Work with the graphical process editor

Business ExampleYour company asks you to set up an integration process using SAP XI. In order todo 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 youto define and edit integration processes in the Integration Repository.

Figure 21: Graphical Process Editor

The editor is divided into six sections, as shown in the above figure. The sectionsare:



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

Edit AreaIn the Edit area, the whole integration process is composed of several step types.It is possible to switch between the following views:

� Graphical Definition

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

� BPEL4WS Display

Shows the process as BPEL4WS coding. Also offers the possibility to importor export the integration process as a BPEL4WS representation.

� Correlation Editor

Define and edit correlations.

Overview AreaThe Overview area shows alternative representations of the integration process.The following 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 therectangle (zooming factor) is controlled by the scroll bar at the top of theoverview area.

� Process Outline

Gives a hierarchical representation of the integration process. Byright-clicking on a step, you can insert or delete steps.

Properties AreaThe Properties area defines the properties of the currently selected step. Theproperties that can be defined depend on the step type. Properties shown inbold italics can hold more than one value line. For example, for the Exceptionsproperty, you can define multiple exceptions. Properties in bold that have anexpand or collapse icon can show or hide their other entries. Mandatory propertiesare marked with a question mark (?).



Output AreaThe Output area shows messages (error, warning, and so on) and 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 datatypes, message types, and so on is shown (this view is only available if theBPEL4WS view is active in the Edit area).

Object AreaIn this area the following views are possible:

� Container

Definition and editing of container elements.

� Correlation List

Used to create correlations.

� Process Signature

Shows an abstract interface in the integration process. It is used as aninbound or outbound interface.

Personalization of the Process EditorYou can personalize the process editor according to your requirements. Yourpersonal settings become the default settings when the process editor is started.For example, you can show or hide particular screen areas or display the processdefinition vertically.



Figure 22: Process Editor: Personal Settings

To increase the visible part of the process definition, choose the Detach icon andmaximize the window.

To increase the default space for the Properties area, choose the Personal Settingsicon and, on the Process Editor page, choose Hide Output Area.

To increase the default space for the Object area (container elements), choose thePersonal Settings icon and, on the Process Editor page, choose Hide Output Area.

Available Step Types and the Block Oriented ModelingParadigmAs mentioned earlier, step types can be divided into two sections: message-relevantsteps and flow-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

Flow-relevant steps are:

� Block

Combines steps that you want to have the same deadline or exceptionhandler, 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.

� While Loop

Repeat steps while a condition is TRUE.

� Wait

Incorporate delay; usually used to set start time for next step.

� Empty (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 willprovide some basic design principles to make it easier to use the design elementsin the right way and to create well-formed and faultless integration processes.



Within the business process modeling tool, a block-oriented modeling paradigmis used. This paradigm relates to well-known structured programming concepts. Itbasically means that blocks are used to group several steps and to structure theintegration process. A block can be defined in sequence or nested within anotherblock. However, a block cannot extend beyond any existing block boundaries;therefore, the outermost block of a process is the process itself.

Figure 23: Block-Oriented Design in ccBPM

The block structure helps to design the process in a concise and comprehensibleway. Moreover, it helps to prevent special structural modeling errors, for example,deadlocks, and it allows hierarchical abstraction. Block hierarchy is the basis forthe visibility and validity of container elements (data) used within a process.

Process Data and Container ManagementSince an integration process should not just forward messages but handle messagesas well, it is necessary to process data.

� Define the data for a business process and enable data to be transferredbetween the 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,

loop counters, 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 canprocess different data correctly, they need a description of the data; therefore, youdefine the data as container elements. Compared to a programming language,



container elements are like variables. They are defined at design time and atruntime they contain references to the particular data. To fit different types of data,several categories and types 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 todeclare the category as abstract interface and the type will refer to the respectiveabstract interface. An abstract interface is defined within the message interfaces.It is only used in integration processes, and the difference between an inboundor outbound message interface is that it is bi-directional. This means that it canbe used as an outbound or inbound interface , depending on the situation withinthe integration process.

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,a counter that would be a simple type of XSD:integer.

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

A container element can be a list of container elements of the same type. To usethis functionality, mark the multiline box for this container element. An examplefor the use of such a list is if you like to collect several messages first and then putthem together into one single message.

Figure 24: Containers and Their Elements



The container elements can be assigned to certain blocks or to the whole process.This is done in the container area where you define the according block. If you setthe container on process, the container is valid and visible in the whole processand it can be used in each block.

Figure 25: Visibility of Container Elements

If you set the container to a specific block, it would be only visible in this block orin any nested block within the specified block. A container element of an innerblock would not be visible in the outer block. As soon as the container elementsare defined, they can be used from the different step types.



Start of an Integration ProcessAn integration process starts at runtime with a receiving step, referring to exactlyone message. This step can be the first step of the process or a step in a fork, ablock, or a loop. If not starting with a receiving step, the fork, block, or loop mustbe the first step in the process. A fork or a loop can be used for multiple receivesteps, which are possible in the following combinations:

� Receive steps arranged in series

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

The receive step can be the first step of the process or the first step in the firstblock of the process.

� Receive step in a loop

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

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

� Receive steps in a fork

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

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.

Correlation of MessagesIf the process contains further receive steps or if the first receive step is part ofa loop, you can correlate their messages with the message from the first receivestep. To do so, specify the correlations you want to activate. For each correlation,you must specify how you want the elements of the correlation container to befilled when the correlation is activated. You can use the whole process containerfor this purpose. If you specify multiple correlations, then the message to bereceived must satisfy all correlations.

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 26: Definition of Correlations

Figure 27: 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 startsthe booking process. During this, the Business Process Engine creates aninstance, holding the state of the process on the Integration Server. Aftersending the flight booking request to Rome, the instance waits for a bookingconfirmation.

� 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 fora confirmation.

� The confirmation for the Rome flight comes back, but now the BusinessProcess Engine has to know to which process instance to send thisconfirmation.

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

Hint: Correlations should be based on fields that are part of the messagepayload.

Recapitulation is a correlation is used to assign messages that belong togetherto the same process instance. It defines how the Business Process Engine canrecognize messages belonging together. It is, therefore, a loose coupling ofmessages. To define a correlation, you have to declare all involved messages andthe XML elements in which the messages match. Activation of a correlation canbe done either in a receive or send step.

Hint: Be sure that the correlation is defined unambiguously. If, forinstance, a material number is used in more than one plant, the correlationhas to be defined using material number and the plant.

A correlation can be valid in the entire process and can be activated and used inthe entire process. Nevertheless, a correlation can be defined as a local correlationas well. This is done by just assigning the correlation to a particular block. Youwill then only be able to activate and use the correlation in this assigned block.

Hint: Using local correlations, you can avoid messages being assigned tothe process when the correlation should be inactive.





Exercise 2: Receive Order Items (Part 1)

Exercise ObjectivesAfter completing this exercise, you will be able to:� Open an integration process� Check the initial state of an integration process

Business ExampleYou wan to procure some spare parts from a non-SAP catalog/CRM system, whichis in our exercises simulated by a Web Dynpro user interface.

You have set up an business process and would like to test the initial state of it.

For testing, you send a message out of the Web Dynpro user interface you find inthe section additional info in the Integration Builder of your training system.

Be careful that you send the message to your process! The ProcessID is part ofthe message.

Task:Find your own business process and check the environment.

1. Log on to the Integration Server (client 800) of your training system, call theIntegration Builder and start the Integration Repository. Use user BIT430-xx.(xx refers to your group number)

Your trainer will give you the relevant information about the training system.

2. Navigate to your business process SellSpareParts_0XX within the softwarecomponent SELLSPAREPARTS and show your process in the process editor.XX refers to your group number.

3. Which container elements are defined?

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

4. Send an order item via the HTML client to the XI Integration Server andcheck whether the order item is received and processed correctly by SAPXI. Within the HTML client, make sure that your integration process isstated in the Process Definition field.

You will find the HTML client in the Integration Builder by choosingAdditional Information→ Tools for BIT430.

Choose Order Spare Part Item.

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




5. Go back in the Integration Repository and delete the receive step DeleteMeof your integration process. Save the integration process.



Solution 2: Receive Order Items (Part 1)Task:Find your own business process and check the environment.

1. Log on to the Integration Server (client 800) of your training system, call theIntegration Builder and start the Integration Repository. Use user BIT430-xx.(xx refers to your group number)

Your trainer will give you the relevant information about the training system.

a) Log on to client 800 of your training system. Use user BIT430-xx.

b) Call transaction SXMB_IFR out of the SAP XI Exchange Infrastructurefolder.

c) Choose Integration Repository in the context Integration Builder:Design.

Java Web Start is loaded.

d) In the security warning dialog box, choose Start.

e) Enter your user and password (BIT430-xx and your changed password)and choose Log on.

2. Navigate to your business process SellSpareParts_0XX within the softwarecomponent SELLSPAREPARTS and show your process in the process editor.XX refers to your group number.

a) After logging on the Integration Repository, go to the SoftwareComponent SELLSPAREPARTS.

b) Open SELLSPAREPARTS and go deeper in the structure until youreach your integration process: Choose SELLSPAREPARTS →SELLSPAREPARTS, 1.0 of SAP→ http://sap.com/xi/BPM/Spareparts→ Business Scenarios & Integration Processes → IntegrationProcesses→ your integration process SellSpareParts_0XX.

c) Double-click on your integration process to see it in the right panel inthe process editor.

The graphical definition shows a start and stop step of the processand one receive step: deleteMe.

3. Which container elements are defined?




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

a) In the Container section of the process editor, you see a containerelement ITEM with the category abstract_interface.

The referred object is item_abstract.

b) To show the object, open the Interface Objects section within thesoftware component SELLSPAREPARTS.

c) Open Message Interfaces and double-click on item_abstract. The usedmessage type is SparePartLineItem.

d) Double-click on the SparePartLineItem structure, which represents onemessage refering to a spare part.

Note that there is one element: Processdefinition. At runtime, thiselement will identify the receiving integration process.

4. Send an order item via the HTML client to the XI Integration Server andcheck whether the order item is received and processed correctly by SAPXI. Within the HTML client, make sure that your integration process isstated in the Process Definition field.

You will find the HTML client in the Integration Builder by choosingAdditional Information→ Tools for BIT430.

Choose Order Spare Part Item.

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

a) Open the HTML client as defined in the exercise.

b) Insert your integration process name SellSpareParts_0XX in theProcess Definition field within the HTML client.

c) Choose SendItem. Your order item will then be submitted to SAP XI.

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

e) Check whether your order item was sucessfully received by SAP XI.

In this case, there should be a message with Sender Service�DMSCRM,� Sender Interface �item_out,� and Receiver Service�SellSpareParts_0XX.�

f) If you sucessfully received the message and you can see the protocol ofyour integration process, your integration process is running fine.




5. Go back in the Integration Repository and delete the receive step DeleteMeof your integration process. Save the integration process.

a) Go back in your mode with the Integration Repository and the processeditor.

Choose Edit Mode of your integration process.

b) Choose the receive step DeleteMe.

c) Use the context menu and delete to delete the receive step.

d) Check and save your integration process.



Lesson Summary

You should now be able to:� Describe the graphical process editor� Work with the graphical process editor


BIT430 Lesson: Step Types (Part 1) and Correlation

Lesson: Step Types (Part 1) and Correlation

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


� Explain the different meanings of step types� Explain and define correlations� Define and use container elements

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 mergedinto a single message, which will be used in the next steps of the integrationprocess.

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

Block StepBlock steps are basic design elements. Blocks can be nested, which means youcan define a hierarchy of the visibility of container elements like local variablesand local correlations. 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.All instances are processed simultaneously. You can use the ParForEach modewhen you want to send a message to multiple receivers simultaneously, forexample.



Figure 28: Basic Definition of a Block

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

You use a container operation to set a value for a target container element atruntime. The target container element and the assigned value must have the samedata type. Use the expression editor to specify the value. If you assign a valueto a single line or multiline container element, this value overwrites the previousvalue. You can use this container operation to create a counter variable, as shownin the following figure.



Figure 29: Creating a Counter

The operation type Append appends 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 30: Definition of a Loop

Definition of a Receive StepAs mentioned before, a receive step starts the integration process. It can be thefirst step in the process.



Figure 31: Receive Step: Starting a Process

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

Figure 32: Receive Steps in a Fork

A receive step waits for a message as soon as the process has reached the receivestep and the relevant correlation has been activated. If a message arrives for whichthere is no waiting receive step, the message is received by the process and stored.As soon as the relevant receive step is activated, the system automatically assignsit to the message that was first received for the relevant message interface, whichsatisfies the correlation used in the receive step.

Caution: A message is only assigned to one receive step, even if multiplereceive steps are waiting for a message from the same message interface.



In the following cases, multiple receive steps can wait for a message from thesame message 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. The first messageis not assigned to all receive steps that are waiting for a message from thismessage interface.

� Receive step in a loop

If the process has not reached the receive step by the time the messagearrives, the process receives the message and places it in a queue. As soon asthe process reaches the receive step and the relevant correlation is active,the system assigns the receive step to the oldest message in the queue. If theprocess reaches the receive step but the queue is empty, the process waitsuntil a new message arrives.

� Multiple receive steps in a fork

If multiple receive steps in forks are waiting for messages from the samemessage interface, an inbound message is only assigned to one receive step(at random). The remaining receive steps must continue to wait.

Defining CorrelationsIf an integration process contains further receive steps you can correlate theirmessages with the message from the first receive step. To do so, specify thecorrelations you want to activate.

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



Figure 33: Defining Correlations

A correlation is valid within the entire process and can be activated and used for theentire process. For example, if a correlation is activated for a particular purchaseorder number, this correlation cannot be used for other purchase order numbers.

However, you can restrict where a correlation is valid by assigning the correlationto a block as a local correlation. The local correlation is then only valid within theblock; it cannot be activated or used outside the block to which it is assigned. Forexample, you can use a local correlation in ParForEach mode to create and use acorrelation with its own unique key (GUID) for each instance created at runtime.This enables each block instance to process a different purchase order number.



Exercise 3: Receive Order Items (Part II) -Exercise and extended solution - usableas a tutorial

Exercise ObjectivesAfter completing this exercise, you will be able to:� Create container elements� Create a block step� Create a loop step� Create a receive step� Use correlations

Business ExampleYou want to use the receive step to receive messages from a non-SAP catalog/CRMsystem. Three messages should be collected and then the process will go on. Youhave to collect several spare part items from a non-SAP catalog/CRM systemand merge them into a single message.

Task:Receive three messages and merge them to one message.

Caution: You must confirm the entries in the Properties section bypressing RETURN.

If you forget this, the entries will disappear and you will have to do itagain.

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

2. You want to receive three items in a loop. Define a container element tocount the messages. Then define the loop step using this element in theend condition.

Define a container element counter of category simple type and typexsd:integer. It is stored in the container of the ReceiveOrderItemBlock.

3. Insert a loop step ReceiveOrderItemLoop for receiving 3 messages. Usethe container element counter to count the messages.

4. The messages should be correlated using the CostumerID out of the OrderItem message.




Create a correlation CorrCustomer. Switch the view of the Containerwindow and add the correlation. Then use the correlation editor. InsertIdCust type xsd:string and assign CustomerNo from the item_abstractinterface.

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

Define receive step ReceiveOrderItem for message item. The receive stepuses and activates the correlation CorrCustomer.

6. Increase your counter (+1).

Define a container operation step RecOrderItemsCounterUpdate for thecontainer element counter in the loop. The simple variable counter must beincreased by an increment of 1 for each loop step.

7. You want to collect the single message in a multiline container element. Firstdefine a multiline container element using the same interface as the message.

Create a multiline container element itemlist of type item_abstract,category abstract interface and container process.

8. Collect the single message in the newly defined container elementitemlist.

Define container operation RecOrderItemSelect to append a single itemfrom container element item to the list of items in container element itemlist.

9. Check, save, and activate your process.

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

10. Check the workflow log of your process.

Use transaction SXMB_MONI, enter the following values, and chooseExecute:

Section Sender - Service: DMSCRM

Section Receiver - Service: SellSpareParts_0XX

Select your message and click on PE in the Outbound column.

In the workflow log view, choose the List with technical details icon. Theresult of the last action must be TRUE.



Solution 3: Receive Order Items (Part II) -Exercise and extended solution - usableas a tutorialTask:Receive three messages and merge them to one message.

Caution: You must confirm the entries in the Properties section bypressing RETURN.

If you forget this, the entries will disappear and you will have to do itagain.

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

a) Drag a block step into your integration process.

b) Enter Step Name: ReceiveOrderItemBlock.

2. You want to receive three items in a loop. Define a container element tocount the messages. Then define the loop step using this element in theend condition.

Define a container element counter of category simple type and typexsd:integer. It is stored in the container of the ReceiveOrderItemBlock.

a) Select the Container window.

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

3. Insert a loop step ReceiveOrderItemLoop for receiving 3 messages. Usethe container element counter to count the messages.

a) Drag a loop step into the block ReceiveOrderItemBlock.

b) Enter Step Name: ReceiveOrderItemLoop.

c) Use the input help of the Condition field. This opens the conditioneditor. Choose as left operand the simple variable counter. The rightoperand is constant 3, type xsd:integer. For the operator, choosenot equals.

4. The messages should be correlated using the CostumerID out of the OrderItem message.




Create a correlation CorrCustomer. Switch the view of the Containerwindow and add the correlation. Then use the correlation editor. InsertIdCust type xsd:string and assign CustomerNo from the item_abstractinterface.

a) Switch the view of theContainer window . Use the icon on the upperleft corner. Choose Correlation List. Insert Correlation Name:CorrCustomer.

b) Select the Graphical Definition window . Choose the icon in the upperleft corner of this area. Choose Correlation Editor.

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

d) Insert message interface item_abstract in the Involved Messagesarea.

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

Hint: Make sure that in the XPath expression, the Multilinecheck box (lower right corner) is deselected. This is necessaryfor all XPath expressions you create in correlations or if youuse/activate a correlation in a send or a receive step.

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

Define receive step ReceiveOrderItem for message item. The receive stepuses and activates the correlation CorrCustomer.

a) Switch to theGraphical Editor window .

b) Drag a receive step into the loop area.

c) Insert Step Name: ReceiveOrderItem.

� Message: item� Start Process: checked� Use Correlations: CorrCustomer� Activate Correlation: CorrCustomer

6. Increase your counter (+1).




Define a container operation step RecOrderItemsCounterUpdate for thecontainer element counter in the loop. The simple variable counter must beincreased by an increment of 1 for each loop step.

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

� Step Name: RecOrderItemsCounterUpdate� Target: Simple Variable counter� Operation: Assign� Expression: Simple Variable counter� Operator: +� Expression: '1'

7. You want to collect the single message in a multiline container element. Firstdefine a multiline container element using the same interface as the message.

Create a multiline container element itemlist of type item_abstract,category abstract interface and container process.

a) Select the Container window.

b) Insert Name: itemlist, Category: Abstract Interface, Typeitem_abstract , Container: Process, and check the Multilinebox.

8. Collect the single message in the newly defined container elementitemlist.

Define container operation RecOrderItemSelect to append a single itemfrom container element item to the list of items in container element itemlist.

a) Drag a container operation step into 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 listed in the Tasks section.

b) Use the provided http-client and send three messages to your integrationprocess. The SenderService is DMSCRM and the SenderInterface isitem_out.





Use transaction SXMB_MONI, enter the following values, and chooseExecute:



Select your message and click on PE in the Outbound column.

In the workflow log view, choose the List with technical details icon. Theresult of the last action must be TRUE.

a) The List with technical details should look like the following figure.

Figure 34: List with Technical Details



Exercise 4: Receive Order Items (PartII) - Exercise and Short solution referto the example solution Solution_1 inthe Integration Repository, softwarecomponent SellSpareParts

Exercise ObjectivesAfter completing this exercise, you will be able to:� Create container elements� Create a block step� Create a loop step� Create a receive step� Use correlations

Business ExampleIn exercise Receive Order Items - Part II you use the Receive Step for receivingmessages from a non-SAP Catalog/CRM-System. Three messages should becollected and then the process will go on. You have to collect several sparepart items from a non-SAP Catalog/CRM-System and merge them into a singlemessage.



Task:Receive three order item messages. The messages are based on the item_abstractinterface and are transferred to the existing container element item.

Collect the messages in a container element itemlist.

Think about the necessary steps of the process and create them. The wholeexercise should be done in a block step.

Recommended names (because of the solutions you want to use, perhaps) of thenecessary elements are:

Block step: ReceiveOrderItemBlock

Counter: counter

Loop step: ReceiveOrderItemLoop

Correlation name: IDCust

1. Receive three order item messages in a block step ReceiveOrderItemBlockin an integration process. The correlation should be done using theCustomerID out of the message.

Collect the items in a container element itemlist.

Use the names listed above to create new container elements and steps.


Then send three items to your integration process by using the http-clientuser interface.


Use transaction SXMB_MONI, enter the following values, and chooseExecute.



Select your message and choose PE from the Outbound column.

In the workflow log, view choose the List with technical details icon. Theresult of the last action must be TRUE.



Solution 4: Receive Order Items (PartII) - Exercise and Short solution referto the example solution Solution_1 inthe Integration Repository, softwarecomponent SellSparePartsTask:Receive three order item messages. The messages are based on the item_abstractinterface and are transferred to the existing container element item.

Collect the messages in a container element itemlist.

Think about the necessary steps of the process and create them. The wholeexercise should be done in a block step.

Recommended names (because of the solutions you want to use, perhaps) of thenecessary elements are:

Block step: ReceiveOrderItemBlock

Counter: counter

Loop step: ReceiveOrderItemLoop

Correlation name: IDCust

1. Receive three order item messages in a block step ReceiveOrderItemBlockin an integration process. The correlation should be done using theCustomerID out of the message.

Collect the items in a container element itemlist.

Use the names listed above to create new container elements and steps.

a) See Solution_1 in the Integration Directory, software componentSellSpareParts if you have problems implementing yourintegrationprocess.


Then send three items to your integration process by using the http-clientuser interface.

a) Choose Integration Process→ Check.

Possible errors are listed in the Tasks section.

b) Use the provided http-client and send three messages to your integrationprocess. SenderService is DMSCRM and the SenderInterface isitem_out.





Use transaction SXMB_MONI, enter the following values, and chooseExecute.



Select your message and choose PE from the Outbound column.

In the workflow log, view choose the List with technical details icon. Theresult of the last action must be TRUE.

a) The List with technical details should look like the following figure.

Figure 35: List with Technical Details



Lesson Summary

You should now be able to:� Explain the different meanings of step types� Explain and define correlations� Define and use container elements



Lesson: Step Types (Part 2) and Exception Handling

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


� Explain the step types transformation, send, control, and wait� eExplain the concept of exception handling in ccBPM� Define exceptions in integration processes

Business ExampleAt the end of this lesson we want to check whether a spare part exists in the salesbusiness system of the customer or not. If not, we get back a response messagecontaining the information that the material must be created. The proceduresis as follows:

After having collected the spare parts in the container element itemlist, theintegration process transforms the itemlist to a to a �list� (container element list),which is sent synchronously to the business system Airline_Group_One, whichrepresents the sales business system. The response message contains the materialsthat must be created.

In the case of an application exception, an alert is thrown, which can then bereviewed in the alert inbox.

We have to learn some more step types to implement the scenario.


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, individualpurchase order 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 isdefined by interface A is converted to message that is defined by interface B

Figure 36: Step type Transformation

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

If the sender and receiver messages need different formats (for example, differentdate formats), you have to define an interface mapping with the correspondingvalue mapping in the Integration Repository. The messages can then be processed.



Since no receiver information is available in the transformation step, there can beno value mappinghere. 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 mustensure that the attachments each have a unique name. If this is not the case,the most recently received attachment will overwrite any attachments withthe same name.

� If the message you want to split contains attachments, the system replicatesthe attachments and appends them to all the messages in the split.

Hint: Check, for each mapping, whether you can replace it with amapping done 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 37: Send a Message: Asynchronous

Step Name and ModeIn 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 fromthe receiver after sending the message. However, you can specify that theasynchronous send step must wait for a confirmation of receipt from the receiver,in the form of an acknowledgment.



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 indicates that themessage was received successfully.

� Application

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

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

� Send Context (default)

The send context is a freely definable string that you specify in the send step.You query the send context in a condition in the receiver determination inthe Integration Directory. You must specify the send context if you want tosend messages from the same message interfaces to different receivers indifferent send steps.

� Receiver list

You determine the list of receivers in a preceding receiver determinationstep. 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 that 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 Directoryis not called.

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 thereply message. Furthermore, you specify the container element referenced by therequest message and the container element in which the reply message is to bereceived. The container element type for the request message must be the sameas the outbound message interface of the synchronous interface. The containerelement type used to receive the reply message must be the same as the inboundmessage interface of the synchronous interface.



In a synchronous send step you can define additional exceptions for applicationerrors, provided the corresponding fault messages are defined in the synchronousinterface. You can define an exception for each fault message. This exception isthrown when the corresponding fault message is received.

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

Figure 38: Send a Message: Synchronous

When sending an acknowledgement, a send step can send a positive or negativeacknowledgement for a particular message. A positive acknowledgementis usually used in a branch that defines the normal case. A negativeacknowledgement is usually used in an exception handler. The receiver of theacknowledgement is automatically determined from the header of the message forwhich the acknowledgement was sent.

Figure 39: Step Type Send: Acknowledgements



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 40: Step Type: Control

The Action field with the value Cancel Process terminates the current processinstance, including all active steps, and sets the status for the process to logicallydeleted. This can be used in exception branches, for example.

The value Throw Exception of the Action property specifies an exception to betriggered. The corresponding exception handler must be defined in the same blockor super block. The system triggers the specified exception at runtime.

The control step with the value Throw Alert specifies the thrown alert messageand the alert category. The alert category must be defined in Alert Management.The entered alert message will be displayed in the corresponding alert inbox. Thesystem triggers the alert at runtime for the user defined in Alert Management. Theprocess continues unchanged. The user who is informed by Alert Managementmust then decide whether to intervene in the process or not.

Figure 41: Step Type Control and Viewing an Alert



The alert inbox can be viewed as follows:

� With the universal worklist of the SAP Enterprise Portal (as of SAPNetWeaver �04)

� By using the application into which it is integrated, such as CRM or theSAP XI Runtime Workbench

� With SAP GUI by using transaction ALRTINBOX

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

The exception handler is the reaction to an exception in a separate processingbranch of a block. In the exception hndler branch, you can insert a control step(see above figure) triggering an alert or canceling the process, for example. Theexception handler has read and write access to all data within the block

Figure 42: 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 inthe block in which the exception handler is defined and then continues processingin the exception handler branch. Once the exception handler branch has finishedprocessing, the process is continued after the block.

If the system fails to find an exception handler, it terminates the integrationprocess with an error.



You can define multiple exceptions within a block. To trigger an exception, usethe control step that throws the corresponding exception. The process is thencontinued in the corresponding exception branch. In a block you can defineprocessing branches as exception handlers. To insert an exception handler branch,call the context menu for the block step.

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

Exceptions can be triggered with a:

� 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 eachfault message that is defined in the synchronous interface. This exception isthrown when the corresponding fault message is received.

� Transformation step

Can trigger an exception when a permanent system error occurs.

� Control step

The exception is triggered when the control step is received.



Exercise 5: Preparations: Material Checkin SD System - Exercise and extendedsolution - usable as a tutorial

Exercise ObjectivesAfter completing this exercise, you will be able to:� Use the transformation step� Use a synchronous send step� Use exception branches

Business ExampleIf a material does not exist in the sales business system of the customer it must becreated. In this exercise you will check whether the materials exist or not.

The procedure for this is as follows.

The order items have been collected in the container element itemlist. ThePreparations: Material Check section of the integration process consists of asynchronous call to the SD system to check whether missing materials have tobe created. The materials that have to be created are sent back in the response ofthe synchronous call.

If the SD system does not know a material, an application error is triggeredin the alert inbox.

If a system error occurs, the process is canceled.



Task:The response message contains the materials that must be created. If one materialdoes not exist in the SD system, an application exception is created, that is, an alertis thrown, which can then be reviewed in the alert inbox.

Business System Airline_Group_One represents the SD system.

There is a mapping object for transferring the multiline element itemlist ( thismulitline element contains messages) to an element list ( this element containsheader data and an unbounded element lineitems) . The name of the mappingobject is itemlist2list.

The synchronous interface prep_sync_abstract to send the message gives a list ofmaterials that have to be created. This reponse list is stored in a new containerelement preplist.

The receivers of the send step are found using the context of SAP ExchangeInfrastructure.

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

1. Collapse the ReceiveOrderItemBlock block you created in the excerciseReceive Order Items Part II of lesson Step Types (Part 1) and Correlation.

2. Define a new block, Preparation, with two exceptions: SystemError andApplicationError.

3. The order items collected in container element itemlist are transferred to acontainer element list. You have to define a new container element andthen the transformation step.

Create a new container element list refering to the abstract interfacelist_abstract and belonging to the process container.

4. Insert a transformation step PrepTransformation using the interface mappingitemlist2list. The source message is itemlist, the target message is list.

5. The call to the SD system is a synchronous call. The response, the list ofmaterials that have to be created, will be stored in a container elementpreplist. You have to define this element.

Create a new container element preplist refering to the abstract interfacelist_abstract and belonging to the process container.

6. Insert a send step SendPreparation. Set the mode of the send stepto synchronous. The send step uses the synchronous interfaceprep_sync_abstract. The request message is list and the response messageis preplist. For the Exception System Error, enter SystemError; for theexception Application Fault enter ApplicationError.

7. Create the exception handling for application and system errors.Continued on next page



Add two exception branches for the exception handlers SystemError andApplicationError by calling the context menu.

8. Add a control step PrepControlAppException into the exception handlerfor the exception ApplicationError. The control step should throw an alertwithin the alert category PROCESS ALERT. You are free to choose thealert message. An example would be Preparation Checks Group xx failed.xx refers to your group number.

Make sure that you are subscribed to the Alert Catergory, so that you willreceive the alerts later.

9. In the exception handler branch for the SystemError exception, insert acontrol step PrepControlSysError to cancel the process.


11. Test your integration process in three variants.

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

Send three line items to your process using your HTML client. Check yourprocess by calling transaction SXMB_MONI_BPE.

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

12. Second variant: Trigger an application exception. Use material 9999 asone of your materials.

Open the HTML client again and send three line items. This time make surethat at least one line item has the spare part number 9999, which will causean application error. Afterwards check the workflow log and your AlertInbox. The workflow log should then look as follows:

Figure 43: Workflow Log with Application Error

13. Third variant: Test the material check with two materials that do not existand have a look at the request and response message.

Run the process again with spare part numbers 2000, 3000, and 4000. Sincematerials 1000, 2000, and 3000 are always marked �missing� in the system,the preparation check will return a message with the spare part numbers




2000 and 3000. To check this, call transaction SXMB_MONI and select anymessages where the sender service is your process. Choose your last sendmessage and have a look at the request message, where you should see allspare part items, transferred to the preparation check. If you then select themessages in SXMB_MONI where the receiver service is your process andthe receiver interface is prep_sync_abstract, you can check the response.There you will see the materials that will be created in the next exercise.



Solution 5: Preparations: Material Checkin SD System - Exercise and extendedsolution - usable as a tutorialTask:The response message contains the materials that must be created. If one materialdoes not exist in the SD system, an application exception is created, that is, an alertis thrown, which can then be reviewed in the alert inbox.


There is a mapping object for transferring the multiline element itemlist ( thismulitline element contains messages) to an element list ( this element containsheader data and an unbounded element lineitems) . The name of the mappingobject is itemlist2list.





a) Select the ReceiveOrderItemBlock and choose collapse from thecontext menu or click on the minus in the upper left corner of the block.

2. Define a new block, Preparation, with two exceptions: SystemError andApplicationError.

a) Drag a block step behind the just-collapsed ReceiveOrderItemBlockblock.

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 container element itemlist are transferred to acontainer element list. You have to define a new container element andthen the transformation step.




Create a new container element list refering to the abstract interfacelist_abstract and belonging 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: unmarked

f) Container: Process

4. Insert a transformation step PrepTransformation using the interface mappingitemlist2list. The source message is itemlist, the target message is list.

a) Drag a transformation step into the Preparation block.


c) Step Name: PrepTransformation.

d) Interface 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, the list ofmaterials that have to be created, will be stored in a container elementpreplist. You have to define this element.

Create a new container element preplist refering to the abstract interfacelist_abstract and belonging to the process container.


b) Name: preplist.

c) Category: Abstract Interface.

d) Type: list_abstract.

e) Multiline:unmarked.

f) Container: Process.




6. Insert a send step SendPreparation. Set the mode of the send stepto synchronous. The send step uses the synchronous interfaceprep_sync_abstract. The request message is list and the response messageis preplist. For the Exception System Error, enter SystemError; for theexception Application Fault enter ApplicationError.

a) Drag a send step behind 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 �> Application Fault: ApplicationError.

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

Add two exception branches for the exception handlers SystemError andApplicationError by calling the context menu.

a) Mark your Preparation block.

b) Right-click on the context menu.

c) Choose Insert→ Exception Branch.

d) Repeat the last step.

e) Select the upper-most exception branch and switch to the Propertiesarea.

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

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

8. Add a control step PrepControlAppException into the exception handlerfor the exception ApplicationError. The control step should throw an alertwithin the alert category PROCESS ALERT. You are free to choose thealert message. An example would be Preparation Checks Group xx failed.xx refers to your group number.




Make sure that you are subscribed to the Alert Catergory, so that you willreceive the alerts later.

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


c) Name: PrepControlAppException.

d) Action: Throw Alert.

e) Alert Category: PROCESS ALERT.

f) Alert Message: Preparation Checks Group xx failed.

g) Call the Integration Builder (sxmb_ifr) and switch to the RuntimeWorkbench.

h) Open the Alert Inbox.

i) Choose Subscription.

j) If you see a gray light bulb for theWebflow Alerts, you should mark theappropiate check box and subscribe to the alert. You should then geta switched-on light bulb.

9. In the exception handler branch for the SystemError exception, insert acontrol step PrepControlSysError to cancel the process.

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


c) Name: PrepControlSysError.

d) Action: Cancel Process.


a) Check, save, and activate your process.

11. Test your integration process in three variants.

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






a) Open the HTML client.

b) Make sure the process definition is SellSpareParts_0XX, where XX isyour group number.

c) Send the line items three times.

Use the materials 1000, 2000, and 3000.

d) Call transaction SXMB_MONI_BPE. Select the messages of yourreceiver service SellSpareParts_0XX.

e) Double-clickProcess Selection and then choose Execute or F8.

f) Choose your process by looking at the row Work Item Type for(Sub)Workflow and Work item text for SellSpareParts_0XX.

g) Double-click on this line. The workflow log should then look asfollows:

Figure 44: Workflow Log

12. Second variant: Trigger an application exception. Use material 9999 asone of your materials.

Open the HTML client again and send three line items. This time make surethat at least one line item has the spare part number 9999, which will causean application error. Afterwards check the workflow log and your AlertInbox. The workflow log should then look as follows:






b) Make sure the process definition is SellSpareParts_0XY, where XY isyour group number.

c) Send three line items, but change the spare part number to 9999at least once.

d) Call transaction SXMB_MONI_BPE.

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

f) Choose your process by looking at the row Work Item Type for(Sub)Workflow and Work item text for SellSpareParts_0XY.



h) Call the Integration Builder (sxmb_ifr) and switch to the RuntimeWorkbench.

i) Open the Alert Inbox. You should now see your thrown alert.


Run the process again with spare part numbers 2000, 3000, and 4000. Sincematerials 1000, 2000, and 3000 are always marked �missing� in the system,the preparation check will return a message with the spare part numbers2000 and 3000. To check this, call transaction SXMB_MONI and select any




messages where the sender service is your process. Choose your last sendmessage and have a look at the request message, where you should see allspare part items, transferred to the preparation check. If you then select themessages in SXMB_MONI where the receiver service is your process andthe receiver interface is prep_sync_abstract, you can check the response.There you will see the materials that will be created in the next exercise.


b) Make sure the process definition is SellSpareParts_0XX, where XX isyour group number.

c) Send the line items three times with the spare part numbers 2000, 3000,and 4000.

d) Call transaction SXMB_MONI.

e) Open Monitor for Processed XML Messages.

f) As sender service, enter your process SellSpareParts_0XX andexecute the query.

g) Choose you last send message and display it.

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

Figure 47: Request Message




i) Go back to the Monitor for Processed XML Messages and enteryour process, SellSpareParts_0XX, as receiver service. Enterprep_sync_abstract as reciever interface name. Make sure thatthe value for the sender service is deleted.

j) Execute the query.

k) Display your last send message.

l) The Maindocument payload of the Request Message Mapping shouldlook as follows:

Figure 48: Response Message and Mapping



Exercise 6: Preparations: Material Checkin SD System - Exercise and short solutionrefer to the example solution Solution_2in the Integration Repository, softwarecomponent SellSpareParts

Exercise ObjectivesAfter completing this exercise, you will be able to:� Use the D� Use a synchronousD� Use D

Business ExampleIf a material does not exist in the sales business system of the customer it must becreated. In this exercise you will check whether the materials exist or not.

The procedure for this is as follows.

The order items have been collected in the container element itemlist. ThePreparations - Material Check section of the integration process consists of asynchronous call to the SD system to check whether missing materials have tobe created. The materials that have to be created are sent back in the response tothe synchronous call.

If the SD system does not know a material, an application error is triggered in theAlert Inbox.

If a system error occurs, the process is canceled.



Task:. The response message contains the materials that must be created in the exercise.If one material does not exist in the SD system, an application exception is createdandis an alert is thrown, which can then be reviewed in the Alert Inbox.


There is a mapping object for ransferring a multiline element itemlist(this multilineelement contains messages) to a list element (this element contains header data andan unbounded element lineitems) . The name of the mapping object is itemlist2list.




Recommended names of the new elements are:

New block: Preparation

Container element (target) in the process container to store the order items: list(referring to abstract interface list_abstract)

Mapping: itemlist2list

Container element in the process container to store the materials out of the responseof the synchrounous call: preplist (referring to abstract interface list_abstract)

Send step: SendPreparation

Exception System Error: SystemError

Exception ApplicationError: ApplicationError

Control step to throw the alert of the application error: PrepControlAppExceptionwith category PROCESS ALERT

You may choose any alert message, for example: Preparation Check Group XXfailed, where XX refers to your group number.

Make sure that you are subscribed to the Alert Catergory, so that you will receivethe alerts later.


Define a new block, Preparation, with two exceptions: SystemError andApplicationError.




Transfer the message in the preparation block and call a synchronous sendstep with interface prep_sync_abstract.

Trigger the application error and the system error. The application errorshould trigger an alert. The system error should cancel the process.


3. Test your integration process. Test it in three variants.

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



4. Second variant: Trigger an application exception.

Use material 9999 as one of your materials.

Open the HTML client again and send again three line items. This timemake sure that at least one line item has the spare part number 9999, whichwill cause an application error. Afterwards check the workflow log and yourAlert Inbox. The workflow log should look as follows:



Run the process again with spare part numbers 2000, 3000, and 4000. Sincethe materials 1000, 2000, and 3000 are always marked missing in the system,the preparation check will return a message with the spare part numbers2000 and 3000. To check this, call transaction SXMB_MONI and select anymessages where the sender service is your process. Choose your last sendmessage and have a look at the request message where you should see allspare part items, transferred to the preparation check. If you then select themessages in SXMB_MONI where the receiver service is your process andthe receiver interface is prep_sync_abstract, you can check the response.



Solution 6: Preparations: Material Checkin SD System - Exercise and short solutionrefer to the example solution Solution_2in the Integration Repository, softwarecomponent SellSparePartsTask:. The response message contains the materials that must be created in the exercise.If one material does not exist in the SD system, an application exception is createdandis an alert is thrown, which can then be reviewed in the Alert Inbox.


There is a mapping object for ransferring a multiline element itemlist(this multilineelement contains messages) to a list element (this element contains header data andan unbounded element lineitems) . The name of the mapping object is itemlist2list.




Recommended names of the new elements are:

New block: Preparation

Container element (target) in the process container to store the order items: list(referring to abstract interface list_abstract)

Mapping: itemlist2list

Container element in the process container to store the materials out of the responseof the synchrounous call: preplist (referring to abstract interface list_abstract)

Send step: SendPreparation

Exception System Error: SystemError

Exception ApplicationError: ApplicationError

Control step to throw the alert of the application error: PrepControlAppExceptionwith category PROCESS ALERT




You may choose any alert message, for example: Preparation Check Group XXfailed, where XX refers to your group number.

Make sure that you are subscribed to the Alert Catergory, so that you will receivethe alerts later.


Define a new block, Preparation, with two exceptions: SystemError andApplicationError.

Transfer the message in the preparation block and call a synchronous sendstep with interface prep_sync_abstract.

Trigger the application error and the system error. The application errorshould trigger an alert. The system error should cancel the process.

a) See Solution_2 in the Integration Repository, software componentSellSpareParts if you have questions about implementing your process.


a) Check, save, and activate your process.

3. Test your integration process. Test it in three variants.

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







b) Make sure the Process Definition is SellSpareParts_0XX, where XX isyour group number.

c) Send the line items three times. Use the materials 1000, 2000, and 3000.

d) Call transaction SXMB_MONI_BPE. Select the messages of yourreceiver service SellSpareParts_0XX.


f) Choose your process by looking at the row Work Item Type for(Sub)Workflow and Work item text for SellSpareParts_0XX.



4. Second variant: Trigger an application exception.

Use material 9999 as one of your materials.

Open the HTML client again and send again three line items. This timemake sure that at least one line item has the spare part number 9999, whichwill cause an application error. Afterwards check the workflow log and yourAlert Inbox. The workflow log should look as follows:






b) Make sure the Process Definition is SellSpareParts_0XY, where XY isyour group number.

c) Send three line items but change the spare part number to 9999 atleast once.

d) Call transaction SXMB_MONI_BPE.


f) Choose your process by looking at the row Work Item Type for(Sub)Workflow and Work item text for SellSpareParts_0XY.



h) Call the Integration Builder (sxmb_ifr) and switch to the RuntimeWorkbench.

i) Open the Alert Inbox. You should now see your thrown alert.


Run the process again with spare part numbers 2000, 3000, and 4000. Sincethe materials 1000, 2000, and 3000 are always marked missing in the system,the preparation check will return a message with the spare part numbers2000 and 3000. To check this, call transaction SXMB_MONI and select any




messages where the sender service is your process. Choose your last sendmessage and have a look at the request message where you should see allspare part items, transferred to the preparation check. If you then select themessages in SXMB_MONI where the receiver service is your process andthe receiver interface is prep_sync_abstract, you can check the response.


b) Make sure the Process Definition is SellSpareParts_0XX, where XX isyour group number.

c) Send the line items three times with the spare part numbers 2000, 3000,and 4000.

d) Call transaction SXMB_MONI.

e) Open Monitor for Processed XML Messages.

f) As sender service, enter your process SellSpareParts_0XX andexecute the query.

g) Choose you last send message and display it.

h) The Maindocument payload of the Inbound Message should look asfollows:

Figure 53: Request Message




i) Go back to the Monitor for Processed XML Messages and enter yourprocess SellSpareParts_0XX as receiver service. Furthermoreenter prep_sync_abstract as reciever interface name. Make surethat the value for the sender service is deleted.

j) Execute the query.

k) Display your last send message.

l) The Maindocument payload of the Request Message Mapping shouldlook as follows:

Figure 54: Response Message and Mapping



Lesson Summary

You should now be able to:� Explain the step types transformation, send, control, and wait� eExplain the concept of exception handling in ccBPM� Define exceptions in integration processes


BIT430 Lesson: Step Types (Part 3)

Lesson: Step Types (Part 3)

Lesson OverviewThe lesson explains the step types switch, fork, and receiver determination, andthe modes ParForEach and ForEach.


� Explain and use step type fork� Explain and use step type switch� Explain and use step type Receiver Determination� Explain and use the modes ParForEach and ForEach in a block step

Business ExampleOne step in your integration process is: materials that do not exist in your salesand MM systems should be created. This is done by combining a block inParallelForEach mode with a block in ForEach mode, which loops over the listof receivers determined beforehand.

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 processmust run through all branches, or just a particular number of branches. You canalso define an end condition for the fork.

Figure 55: 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 each branch, a receive step waits for a message from different interfaces. Ifyou want to check whether a receive step has received its message, you haveto compare the container element in which the message is to be received withan empty container element.

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 withthe condition editor for each processing branch.

Figure 56: Step Type Switch

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



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 57: Block Mode ParForEach

You use a receiver determination step to determine a multiline container elementwith the list of receivers. Then you have to define that the message is sent tothese receivers in a block with a send step (see figure). You specify the multilinecontainer element in the Multiline Element property. In the Current Line field,specify a container element that takes the value of the multiline container elementfor which the block will run. You can also define an end condition for the dynamicmode. The block is complete as soon as one of the lines of the multiline containerelement returns TRUE for the end condition, or all lines of the multiline containerelement have been processed.

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

In ForEach mode, the block first runs through for the first line of the multilinecontainer element, then for the second, and so on. You can use ForEach modewhen you want to send a message to multiple receivers one after the other, forexample.



Figure 58: 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 thismessage for each element of the multiline container element, then the send stepcan activate a corresponding correlation.

Checklist ParForEach ModeParForEach 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.� There are no more than 999 forks, that is, the multiline container element

does not have more than 999 entries at runtime.Try to use ForEach Mode if you have more than 999 entries in your containerelement.

Receiver DeterminationYou use a receiver determination step to get a list of receivers for a subsequentsend step. The receiver determination step calls the receiver determination thatyou configured in the Integration Directory and returns the receiver list.

The following figure shows the use of the receiver determination step. Thereceiver determination step gets the receiver list from the Integration Directoryand the send step sends the messages parallel to the receivers.



Figure 59: 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 fromthe same interface to different receivers in different send steps.

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

Additional Step Types: Undefined and WaitYou use a wait step to incorporate a delay in a process. Usually, you use a delayto define when the next step in the process is to start. You can define a delay aseither a point in time or a period of time (see figure below). At runtime, the stepwaits until the specified point in time is reached or the specified period of time haspassed. The system then continues the process by proceeding with the next step.



Figure 60: 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



Exercise 7: Create Materials - Exercise andextended solution - usable as a tutorial

Exercise ObjectivesAfter completing this exercise, you will be able to:� Use the condition editor

Business ExampleIn the preparation step of the integration process, the SD system transfers backa list of materials that should be created. You find the element CreateMaterialsin the interface list_abstract. This element is set to YES, if a material was notfound. The materials are created in the SD and MM systems. Business systemAirline_Group_One refers to the SD system and Airline_Group_Two refers to theMM system. This is done by combining a block in ParForEach mode with a blockin ForEach mode, which loops over the list of receivers determined beforehandwith the step type receiver determination.

Task:You want to send the materials to the SD and MM systems. Therefore, youneed independent materials with header and line item data. You have to transferthe preplist to a new multiline element, prepitemlist, based on the interfaceitem_abstract. The mapping is done in the mapping object list2itemslist.

Furthermore you need a single container element, prepitem, which refers toexactly one item (representing a material).

Use a new block SendmaterialsParallel in parforeach mode combined with yournew container elements prepitemlist and prepitem to send the materials to thedifferent systems determined in the receiver determination step.

Define a correlation to correlate the messages coming back from the SD and MMsystems. The correlation should refer to the customer number and the spare partnumber.

TThe SD and MM systems' answer is received in a receive step using the messagecreate_matresp and the correlation CorrMaterials.

1. Collapse the Preparation block and add a CreateMaterials block.

2. Insert a switch step to check if materials need to be created.The step should be called if the Outcome name should be calledMaterialsCreated, and for the condition, it should be checked thatpreplist./p1:SparePartLineItemList/CreateMaterials is YES.




3. You want to send the materials to the SD and MM systems. Therefore youneed independent materials with header and line item data. You have totransfer the preplist to a new multiline element prepitemlist based on theinterface item_abstract.

Create this element and then insert a transformation step.

Create a multiline element prepitemlist in the CreateMaterials container,which is based on the abstract interface item_abstract.

4. Insert a transformation step MaterialTransformation into branch1 ofthe switch step. The transformation is based on the interface mappinglist2itemlist, the source message preplist and the target message prepitemlist.

5. After the transformation step, insert a block named SendMaterialsParallel.

6. Create a new container element prepitem, based on the abstract interfaceitem_abstract in the container SendMaterialsParallel.

7. Set the mode of the SendMaterialsParallel block to ParForEach. For themultiline property, select the container element prepitemlist. For the currentline property, select the container element prepitem.

8. Create a multiline element Receivers (category Receiver) for theSendMaterialsParallel container.

9. Insert a receiver determination step ReceiverDetermination into theSendMaterialsParallel block. Select prepitem for the message property andReceivers for the receivers property.

10. Create a correlation CorrMaterials as shown in the following graphic:

Figure 61: Correlation Editor

11. Insert a new block SystemBroadcastPerMaterial after the receiverdetermination step.

12. Create a container element Receiver (Category Receiver) within the createdSystemBroadcastPerMaterial block.

13. For the SystemBroadcastPerMaterial block, set ForEach mode. For theMultiline Element property, select Receivers, for the current Line property,select Receiver, and for the correlation select CorrMaterials.




14. Insert a send step SendMaterial in the SystemBroadcastPerMaterial block.This step should send the message prepitem asynchronously and get thereceivers from the Receiver list. Use correlation CorrMaterials and refer toCustomerNo and SPAREPART_NO for the ID_Cust and ID_Mat.

15. Create the container element create_matresp in the SystemBroadcastPer-Material container. It should refer to the abstract interface item_abstract.

16. Insert a receive step ReceiveCreateMatResp using message create_matrespand correlation CorrMaterials.

17. Save, check, and activate your process.

18. Open your HTML client and send three line items with spare part numbers2000, 3000, and 4000. The resulting workflow should look as follows:


Two materials, 2000 and 3000, have been created and broadcasted to twosystems each.



Solution 7: Create Materials - Exercise andextended solution - usable as a tutorialTask:You want to send the materials to the SD and MM systems. Therefore, youneed independent materials with header and line item data. You have to transferthe preplist to a new multiline element, prepitemlist, based on the interfaceitem_abstract. The mapping is done in the mapping object list2itemslist.

Furthermore you need a single container element, prepitem, which refers toexactly one item (representing a material).



TThe SD and MM systems' answer is received in a receive step using the messagecreate_matresp and the correlation CorrMaterials.


a) Open your integration process and switch to change mode.

b) Click on the Preparation block from the last exercise and collapse itwith the help of the context menu or by clicking on the minus iconin the upper-left corner.

c) Drag a block step behind the collapsed Preparation block.

d) Switch to the Properties area.

e) Name: CreateMaterials

f) Mode: Default




2. Insert a switch step to check if materials need to be created.The step should be called if the Outcome name should be calledMaterialsCreated, and for the condition, it should be checked thatpreplist./p1:SparePartLineItemList/CreateMaterials is YES.

a) Drag a switch step inside the CreateMaterials block.


c) Name: if

d) Outcome Name: MaterialsCreated

e) Condition: (preplist./p1:SparePartLineItemList/CreateMaterials =YES).

The step should look as follows:

Figure 63: Condition

3. You want to send the materials to the SD and MM systems. Therefore youneed independent materials with header and line item data. You have totransfer the preplist to a new multiline element prepitemlist based on theinterface item_abstract.

Create this element and then insert a transformation step.




Create a multiline element prepitemlist in the CreateMaterials container,which is based on the abstract interface item_abstract.


b) Name: prepitemlist


d) Type: item_abstract

e) Multiline: marked

f) Container: CreateMaterials

4. Insert a transformation step MaterialTransformation into branch1 ofthe switch step. The transformation is based on the interface mappinglist2itemlist, the source message preplist and the target message prepitemlist.

a) Drag a transformation step into branch1 of the switch step.


c) Name: MaterialTransformation

d) Interface Mapping:list2itemlist

e) Source Message �> list_abstract: preplist

f) Target Messages �> item_abstract: prepitemlist

5. After the transformation step, insert a block named SendMaterialsParallel.

a) Drag a block step behind the transformation step in branch 1.


c) Name: SendMaterialsParallel

d) Mode: Default

6. Create a new container element prepitem, based on the abstract interfaceitem_abstract in the container SendMaterialsParallel.


b) Name: prepitem




f) Container: SendMaterialsParallel




7. Set the mode of the SendMaterialsParallel block to ParForEach. For themultiline property, select the container element prepitemlist. For the currentline property, select the container element prepitem.

a) Mark the send step and switch to the Properties area.

b) Mode: ParForEach

c) Multiline Element: prepitemlist

d) Current Line: prepitem

8. Create a multiline element Receivers (category Receiver) for theSendMaterialsParallel container.

a) Switch to the Container area.

b) Name: Receivers

c) Category: Receiver

d) Multiline: marked

e) Container: SendMaterialsParallel

9. Insert a receiver determination step ReceiverDetermination into theSendMaterialsParallel block. Select prepitem for the message property andReceivers for the receivers property.

a) Drag a receiver determination step into the SendMaterialsParallelblock.


c) Name: Receiver Determination

d) Message: prepitem

e) Receivers: Receivers

10. Create a correlation CorrMaterials as shown in the following graphic:




Figure 64: Correlation Editor

a) Switch to the Correlation List View in theObject area.

b) Enter a new correlation name: CorrMaterials.

c) Switch to the Edit area and change to the Correlation Editor view.

d) Change the Correlation Name to CorrMaterials.

e) Switch to the Correlation container box.

f) Enter two new values: ID_Cust type xsd:string and ID_Mattype xsd:string.

g) Switch to the Involved Messages box.

h) Choose the message item_abstract.

i) Switch to the Properties area.

j) For ID_Cust, choose the value Interface./p1:SparePartLineItem/Cus-tomerNo.

k) For ID_Mat, choose the value Interface./p1:SparePart-LineItem/SPAREPART_NO.

11. Insert a new block SystemBroadcastPerMaterial after the receiverdetermination step.

a) Drag a new block step after the receiver determination step.


c) Name: SystemBroadcastPerMaterial

d) Mode: Default

12. Create a container element Receiver (Category Receiver) within the createdSystemBroadcastPerMaterial block.

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

b) Name: Receiver

c) Category: Receiver

d) Multiline: unmarked

e) Container: SystemBroadcastPerMaterial




13. For the SystemBroadcastPerMaterial block, set ForEach mode. For theMultiline Element property, select Receivers, for the current Line property,select Receiver, and for the correlation select CorrMaterials.

a) Mark the SystemBroadcastPerMaterial block and switch to theProperties area.

b) Mode: ForEach

c) Multiline Element: Receivers

d) Current Line: Receiver

e) Local Correlations: CorrMaterials

14. Insert a send step SendMaterial in the SystemBroadcastPerMaterial block.This step should send the message prepitem asynchronously and get thereceivers from the Receiver list. Use correlation CorrMaterials and refer toCustomerNo and SPAREPART_NO for the ID_Cust and ID_Mat.

a) Drag a send step into the block SystemBroadcastPerMaterial.


c) Name: SendMaterial

d) Mode: Asynchronous

e) Message: prepitem

f) Receiver From: Receivers List

g) Receivers: Receiver

h) Activate Correlation: CorrMaterials

i) ID_Cust: prepitem./p1:SparePartLineItem/CustomerNo

j) ID_Mat: prepitem./p1:SparePart-LineItem/SPAREPART_NO

15. Create the container element create_matresp in the SystemBroadcastPer-Material container. It should refer to the abstract interface item_abstract.


b) Name: create_matresp




f) Container: SystemBroadcastPerMaterial




16. Insert a receive step ReceiveCreateMatResp using message create_matrespand correlation CorrMaterials.

a) Drag a receive step behind the send step SendMaterial.


c) Name: ReceiveCreateMatResp

d) Message: create_matresp

e) Use Correlations: CorrMaterials


a) Save your process.

b) Check the process by pressing F7.

c) If no errors are found, activate your process.




a) Open your HTML client and make sure your process is entered in theProcess Definition field.

b) Send three line items with spare part numbers 2000, 3000, and 4000.

c) Call transaction SXMB_MONI_BPE.

d) Choose your last-sent workflow and open the workflow log.



Exercise 8: Create Materials - Exercise andshort solution refer to the example solutionSolution_3 in the Integration Repository,software component SellSpareParts

Exercise ObjectivesAfter completing this exercise, you will be able to:� Use the condition editor

Business ExampleIn the preparation step of the integration process the SD system transfers back alist of materials which should be created. You find the element CreateMaterialsin the interface list_abstract. This element is set to YES if a material was found.The materials are created in the SD and MM systems.

Business System Airline_Group_One refers to the SD system andAirline_Group_Two refers to the MM system. This is done by combining a blockin ParForEach mode with a block in ForEach mode, which loops over the list ofreceivers determined beforehand with the step type receiver determination.

Task:You want to send the materials to the SD and MM systems. Therefore you needindependent materials with header and line item data. So you have to transferthe preplist to a new multiline element, prepitemlist, based on the interfaceitem_abstract. The mapping is done in the mapping object list2itemslist.

Furthermore you need a single container element, prepitem, that refers to exactlyone item (representing a material).



The SD and MM systems' answer is received in a D using the messagecreate_matresp and the correlation CorrMaterials.











Solution 8: Create Materials - Exercise andshort solution refer to the example solutionSolution_3 in the Integration Repository,software component SellSparePartsTask:You want to send the materials to the SD and MM systems. Therefore you needindependent materials with header and line item data. So you have to transferthe preplist to a new multiline element, prepitemlist, based on the interfaceitem_abstract. The mapping is done in the mapping object list2itemslist.

Furthermore you need a single container element, prepitem, that refers to exactlyone item (representing a material).



The SD and MM systems' answer is received in a D using the messagecreate_matresp and the correlation CorrMaterials.


a) See Solution_3 in the Integration Repository, software componentSellSpareParts if you have questions about implementing yourintegration process.


a) Save your process.


c) If no errors are found, activate your process.







a) Open your HTML client and make sure your process is entered in theProcess Definition field.

b) Send three line items with spare part numbers 2000, 3000, and 4000.

c) Call transaction SXMB_MONI_BPE.

d) Choose your last-sent workflow and open the workflow log.



Lesson Summary

You should now be able to:� Explain and use step type fork� Explain and use step type switch� Explain and use step type Receiver Determination� Explain and use the modes ParForEach and ForEach in a block step



Lesson: Process Patterns

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 abstractionfrom widely used integration process cases.


� Describe common design patterns for integration processes� Use the process patterns shipped by SAP in your integration processes

Business ExampleYou have to define an integration process within ccBPM. The integration processconsists of frequently used combinations of step types. You can save timedesigning the process by using process patterns.

SAP Process PatternsSAP delivers 10 typical patterns as a standard package. The patternsare located in the Integration Repository. You will find them athttp://sap.com/xi/XI/System/Patterns by choosing SAP Basis→ SAP Basis 6.40.

To use a pattern in your own integration process, choose Insert→ IntegrationProcess After from the context menu of a step or from the menu bar of the processeditor.


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

BIT430 Lesson: Process Patterns

Figure 68: Inserting a Pattern

Hint: SAP also ships example processes. These forms the basisfor the definition of integration processes. One example process ishttp://sap.com/xi/XI/Demo/Agency→MultipleFlightBookingCoordination.

Collecting Several MessagesFor collecting several messages and merging them into one message, SAPprovides three patterns:

� Payload dependant (Pattern: BpmPatternCollectPayload)� Time dependent (Pattern: BpmPatternCollectTime)� 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 fullfilled (Pattern: BpmPatternCollectMultiIfCondition).

Stop collecting payload dependant

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



Figure 69: Pattern BpmPatternCollectPayload

The process receives messages in a loop (see above figure). The first message thatis received starts the process and activates the correlation Correlation by using anID. Each subsequent message uses this correlation. The messages are receivedin the container element CollectMessage. In the loop, the received messagesare attached to the multiline container element CollectMessageList. Once allthe messages have been received, a transformation step bundles the messagescollected in the container element CollectMessageList and from them creates amessage in the container element NewMessage. This message is then sent by asubsequent send step.

Each message that is received in the loop contains the number in the payload,which represents the number of messages to be received. In the loop, a containeroperation counts the counter Counter for the number of messages received. Theloop continues while the number of messages received is not equal to the numberof messages to be received.

Stop collecting time dependant

The loop for receiving the messages is defined as an infinite loop. The infiniteloop forms a branch within a block. A deadline has been defined for the d. Whenthe deadline is reached, the process is redirected into the designated branch. Acontrol step then triggers an exception in this branch. The relevant exceptionhandler ends the block 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 infiniteloop forms a branch within a fork. A receive step is defined in a parallel branchto receive the message that ends the process. The fork is complete when bothbranches return TRUE. However, since the infinite loop always returnsTRUE, thefork is only complete 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 the patternBpmPatternCollectMultiIf receives three messages from different interfaces in thecontainer elements FirstMessage, SecondMessage, and ThirdMessage. Threereceive steps have been defined correspondingly within a fork (see figure). Any ofthe receive steps can start the process. For this reason, the Start Process indicatorhas been set for each of the receive steps.

Figure 70: Pattern BpmPatternCollectMultiIf

The first message received starts the process and activates the correlationCorrelation. Each receive step uses this correlation. Once the messages havebeen received, a transformation step bundles the messages together and fromthem creates a message in the container element NewMessage. This message isthen sent by a subsequent send step. To collect all messages, define that the forkis complete once all branches have been processed.

Collecting messages based on a condition

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

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

� Sending simustaneously (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. You do not need to know the number ofreceivers at design time.

Sequential



The process is started when a message is received in the receive step. Asubsequent receiver determination step calls the receiver determination that isconfigured in the Integration Directory and gets the receiver list for the multilinecontainer element Receivers.

Figure 71: Pattern BpmPatternMulticastSequential

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

The block is defined as ForEach. Within the block, a send step sends the messageto the first receiver in the receiver list and creates the correlation Correlation. Areceive step uses a correlation and receives the response message from the firstreceiver. If this receive step is complete, the message is sent to the next receiverin the receiver list. The entire receiver list is processed in this way. So that theseparate instances of the correlations can be processed for each receiver, thecorrelation is defined as a local correlation.

Each receiver sends a response message, which is received in the responsecontainer element. The sent message and the response message are linked bymeans of a correlation. For example, the sent message might be a purchase. Thispurchase order and the purchase order response might be correlated by a purchaseorder number.

Parallel

The block is defined as ParForEach. A block instance is generated for eachreceiver in the receiver list in which the following steps are executed: A send stepsends the message to the receiver and activates the correlation Correlation. So thata separate instance of the correlation can be processed for the block instance, thecorrelation is defined as a local correlation. A receive step uses this correlationand receives the response message from the receiver. The block is complete if allblock instances that were generated in parallel are complete. In other words, theresponse message has been received from all receivers in the receiver list.



SerializationSerialization means defining the sequence in which a process sends receivedmessages.

� One start message (Pattern: BpmPatternSerializeOneTrigger)� Multiple start messages (Pattern: BpmPatternSerializeMultipleTrigger)

One start message

Three receive steps are defined in the process BpmPatternSerializeOneTrigger.The messages are received in the container elements FirstMessage,SecondMessage, or ThirdMessage. The process starts once the first receive stepreceives the message. For this reason, the Start Process indicator has been set forthe first receive step. When a message is received, the receive step activates thecorrelation Correlation. This correlation is used by both subsequent receive stepsand correlates the messages by means of an ID.

Once all three messages have been received, the process sends the messages inreverse order. Once it has sent a message, the process waits for acknowledgmentfrom the receiver 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 theprocess. For this reason, the Start Process indicator has been set for each of thereceive steps. At design time it is not known which of the messages will arrivefirst. Therefore, the receive steps are arranged in a fork (see figure). If one of thereceive steps receives its message, it starts the process and activates the correlationCorrelation. This correlation is used by both other receive steps. The fork shouldbe complete once all three messages have been received; therefore, the number ofrequired branches is set to three.



Figure 72: Pattern BpmPatternSerializeMultipleTrigger

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

Sync/Async-Bridge PatternThe 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 integrationprocess.



Figure 73: Pattern BpmPatternSyncAsyncBridge

Defining a Sync/Async Bridge:

1. Receive step SyncReceive: Receives the request message from thesynchronous business system BS-S and opens the sync/async bridge. Thereceive step is the first step in the integration process. The receive stepspecifies the synchronous interface BpmPatternBridgeSyncI for receivingthe message from the synchronous business system. The integration processis started when the message is received. The message type of the message tobe received and the request message from the synchronous interface mustbe identical.

2. Send Step AsyncSend: Sends the received request message asynchronouslyto the 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 reply message from thesynchronous interface in the opening receive step SyncReceive must be identical.In the send step, enter the name of the receive step that opened the sync/asyncbridge (in this example, SyncReceive).





Exercise 9: Test Your Knowledge

Exercise ObjectivesAfter completing this exercise, you will be able to:� 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 6.40?

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

3. What is the function of the pattern BpmPatternCollectMultiIf?



Solution 9: Test Your KnowledgeTask:Answer the following questions.

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

Answer: You can distinguish between collecting messages, multicasting ofmessages, performing serialization, and using a sync/async-bridge pattern.

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

Answer: To use a pattern in your own integration processd, chooseInsert→ Integration Process After from the context menu for a step orfrom the menu bar of the process editor. The pattern is located in theIntegration Repository under SAP Basis→SAP Basis 6.40 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 corressponding correlation. Each receivestep of this pattern uses this correlation. Once the messages have beenreceived, a transformation step bundles the messages together. This messageis then sent by a subsequent send step.


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


Lesson Summary

You should now be able to:� Describe common design patterns for integration processes� Use the process patterns shipped by SAP in your integration processes


Unit Summary BIT430

Unit SummaryYou should now be able to:� Describe the graphical process editor� Work with 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� eExplain the concept of exception handling in ccBPM� Define exceptions in integration processes� Explain and use step type fork� Explain and use step type switch� Explain and use step type Receiver Determination� Explain and use the modes ParForEach and ForEach in a block step� Describe common design patterns for integration processes� Use the process patterns shipped by SAP in your integration processes


Unit 3Business Process Management:Execution and Troubleshouting

Unit OverviewThis unit will provide you essential information about the Business Process Engineand how to monitor the Runtime Cache. It will also inform you how to use thedifferent monitoring transactions in SAP XI and what the event log refers to.


� Explain the relationship between integration processes in SAP XI andworkflows in SAP Business Workflow

� Check the runtime version of an integration process in the SAP XI RuntimeCache

� Perform process and message monitoring� Perform basic troubleshooting� Use transaction SXMB_MONI_BPE� Monitor workflow executions� Use the workflow log� Navigate to the involved messages of and� Check the status of synchronous/asynchronous communication� Perform basic troubleshooting

Unit ContentsLesson: Business Process Engine: Overview and Runtime Cache.. . . . .149

Exercise 10: Create Orders - Exercise and extended solution - usableas a tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159Exercise 11: Create Orders- Exercise and short solution refer to theexample solution Solution_4 in the Integration Repository, softwarecomponent SellSpareParts .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171Exercise 12: Extension .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .177

Lesson: Process Execution Monitoring .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .185


Unit 3: Business Process Management: Execution and Troubleshouting BIT430

Lesson: Message Monitoring.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .196Exercise 13: Test Your Knowledge.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201

Lesson: Event Trace and Troubleshooting .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204Exercise 14: Send Purchase Order to Supplier . . . . . . . . . . . . . . . . . . . . . . . .209


BIT430 Lesson: Business Process Engine: Overview and Runtime Cache

Lesson: Business Process Engine: Overview andRuntime Cache

Lesson OverviewThis lesson will provide you essential information about the Business ProcessEngine and how to monitor the Runtime Cache.


� Explain the relationship between integration processes in SAP XI andworkflows in SAP Business Workflow

� Check the runtime version of an integration process in the SAP XI RuntimeCache

� Perform process and message monitoring� Perform basic troubleshooting

Business ExampleAn integration process was not processed successfully. Your task is to find theposition in your integration process that caused the error.

Business Process Engine OverviewThe Business Process Engine (BPE) is part of the Integration Server. The BPEprovides functions to monitor the execution of integration processes. The BPE hasthe following characteristics:

� Provides runtime support for SAP XI integration processes� Uses the Web AS 6.40 Business Workflow runtime engine (it is not a Java

engine)� Supports all integration processes defined in the Integration Builder

When an integration process is executed, the system creates corresponding workitems, just like during the execution of an SAP Business Workflow. A work itemcan represent a process or a step in a process.

� ccBPM and Business Workflow use the same engine.� An Integration Process defined in SAP XI ccBPMgenerates a workflow.� Unique step types in SAP XI ccBPM do not exist in the normal workflow

definition environment.� SAP XI workflows are triggered by events.



The Business Process Engine is simular to the workflow engine. SAP XI providesunique step types that are not a part of the workflow definition environment, eventhough the design layer of workflows has unique features for SAP XI.

When an integration process is executed, the system creates correspondingwork items, just like during the execution of an SAP Business Workflow. As inBusiness Workflow a work item can represent a process or a step in a process. Youcan use the transactions for monitoring the Business Process Engine to displaythe generated work items in the workflow log and display detailed informationabout the status of a process or the individual steps.

If SAP XI workflows are triggered by events, the background user (generallyWF_BATCH ) logs into the system and starts the workflow.

Caution: Prerequisite is that the automatic customizing of the BusinessProcess Engine (transaction SWF_XI_CUSTOMIZING) was executedwithout errors.

This normally takes place during installation.

Figure 74: ccBPM: An Example Process Definition

The figure above shows an example of an integration process. The first �start�step becomes the triggering event. The second �receive� step enables us to waitfor a specific message to arrive. The third �mapping� enables us to transform fromone message to another. The fourth �send� step enables us to send the messageout. The process is built in the Integration Repository and generates a workflow.



Figure 75: ccBPM Process and the Generated Workflow Process

The figure above shows the workflow generated from the integration processshown on the previous figure.

The actual generated workflow can be seen with transaction SWDD. When aworkflow is created, it is stored on the database as a workflow template (WS) anda number, for example, WS74900023.

You can see that some icons are the same as in the Integration Repository. Thestart step becomes the triggering event step. The receive step becomes a wait forevent step. The mapping step becomes an activity step; this is the most commontype of step in a workflow. Behind this step type is normally a call to a businessobject or an ABAP class. The send step calls another workflow.

Runtime Cache: Transaction SXI_CACHEYou 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 Exchange Infrastructure→ Configuration→ XI CacheRefresh (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 integrationprocess in the Integration Repository, and creates the entries for the service andparty in the Integration Directory. This happens as soon as you activate the changelist in the Integration Directory. If the runtime version was created without errors,it is processed by the Business Process Engine.



Figure 76: 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 77: Runtime Cache: Details



To display the process definition, select the runtime version and click the iconwith the quick info Display Active Version. The process definition is displayedin the Process Builder. The Process Builder has a similar structure to the SAPBusiness Workflow Workflow Builder. It is specially designed for displayingintegration processes. You cannot make any changes to the process definitionin 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 display the XML representation in a clearer, more structured way,double-click a line.

� Workflow task

During processing by the Business Process Engine, the runtime versionof the integration process is represented by a workflow task. You do notnormally need to know the number of the task; however, you can use thenumber to search for 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 theintegration process was created without errors. If it does not equal 0, then errorsoccurred. You can update the runtime version and then analyze the error messages.When you do so, the system displays detailed messages about the problems thatoccurred.



Figure 78: 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.

Figure 79: Error Message: Repeat Activation

Once the change is fixed in the Integration Repository and the changes areactivated, the workflow should no longer have syntax errors and transaction codeSXI_CACHE should no longer have a bad return code. The workflow is notgenerated when the integration process is created in the Integration Repository.



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 alsocheck the syntax by choosing Workflow→ Check Syntax from transaction codeSWDD. After the syntax check you will receive any existing errors.

Caution: You cannot make changes to workflows that are generatedfrom Integration Builder activities.

Error AnalysisIf error code is displayed in the Runtime Cache, check the following in theIntegration Repository:

� Conditions

Are the defined conditions valid? At present, the condition editor cannotensure that a condition does not contain invalid comparisons, such ascomparisons between different data types, for example, xsd:date andxsd:time, or comparisons between 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.

Deletion of Runtime VersionsWhen you delete a runtime version, the corresponding workflow task is alsodeleted.

Caution: You must not delete any runtime versions in a productivesystem.

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 there are no processinstances running at the time.

Definition of Deadlines in an Integration ProcessA deadline specifies the last point in time that a block can be executed.



Figure 80: Deadline Monitoring

The time to run before the deadline is reached can be defined as follows:

� Time and point in time when the step or process is generated� Time and an arbitrary point in time that you specify as an expression

You also define how you want the process to react if the deadline is exceeded ina separate branch (deadline branch).

The system checks the deadline at runtime. If the deadline has been exceeded,the processing branch is executed for the deadline. The steps in the remainingprocessing branches in the block are not affected by this.

Note: These steps within a block are not automatically completed.

In the deadline branch, you can trigger an exception or an alert for AlertManagement by using a control step, for example. The branch has read andwrite-to access to all data within the block. To insert a deadline branch, call thecontext menu for that particular block.

Checklist: Efficient Use of the Integration ServerThe Integration Server is the central ressource to exchange messages betweenbusiness systems, so you should do everything to avoid performance problems.



Use the following 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 messagesent by the process engine is doubled. The process instance itself and eachstep of the process creates a work item.

� Do not transfer application logic to the integration process.� ccBPM on the Integration Server does not substitute interfaces that exchange

mass data.





Exercise 10: Create Orders - Exercise andextended solution - usable as a tutorial

Exercise ObjectivesAfter completing this exercise, you will be able to:� Use the switch step� use the fork step� Send a message to your Alert Inbox

Business ExampleA sales and purchase order are created in parallel in your integration processin a new block . The sales order is sent to the SD system (business systemairline_group_one) and the purchase order is sent to the MM system (businesssystem airline_group_two). If one fails, both orders are canceled, an alert isthrown, and the process itself is cancelled.

You can force the error situation for the purchase order if CustomerNo contains a�Y�. To create an error in the sales order, CustomerNo must contain a �Z.�

Task:Define a new block to create the sales and purchase order. Send the sales orderto airline_group_one and the purchase order to airline_group_two. Only ifboth orders are created successfully will the process be processed in the future.Otherwise an alert is thrown, the process is canceled, and the orders in bothsystems are canceled.

1. The whole scenario takes place in a new block.

Add block step CreateSalesAndPurchaseOrdersBlock to your integrationprocess.

2. You want to create a sales order and a purchase order in two systems inparallel. You need a fork step.

Insert fork step createparallel with two branches into your block stepCreateSalesAndPurchaseOrdersBlock .

3. The MM and SD systems send back messages when the orders are created.These messages must be correlated with the corresponding send steps, soyou have to define a correlation. The Customer Number is used for thecorrelation.




Create the correlation CorrOrder. Add correlation container Cust typexsd:string. 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 foundusing a condition defined in the receiver determination. The condition isdetermined using the context property PurchaseOrder.

Create asynchron send step SendPO in the first branch. EnterPurchaseOrder for the Send Context property. This is important because therouting depends on this Send Context. Message is list, Acknowledgement isTransport and activate correlation CorrOrder.

5. The MM system sends back a message when the purchase order is defined,so you have to define a container element for the response message.

Create a container element po_resp in the Process Container . It is anabstract interface of type crea_po_abstract.

6. Define a receive step for the message that is sent by the MM system afterhaving created the purchase order.

Insert a receive step ReceivePO after the send step. Message is po_resp anduse correlation CorrOrder.

7. You want to extract one single field of the asynchronous response message:the Status field. In this field you find whether the purchase order can becreated or not, so you need a container element for this status field.

Create a container element status_po for container CreateSalesAndPur-chaseOrdersBlock. Category is Simple Type and Type is xsd:string.

8. Use a container operation to extract the Status field out of the message.

Insert container operation step, getPOstatus, after the receive step. Assigncontainer element status_po. Expression is Interface Variable (po_resp)→XPath→ SparPartLineItemList→ Status.

9. Now you can create the send step for the sales order that activates thecorrelation. The receiver (business system airline_group_one) is found usinga condition defined in the receiver determination in the Integration Directory.The condition 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 therouting depends on this Send Context. Message is list, Acknowledgement isApplication, and activate correlation CorrOrder.

10. The SD system sends back a message when the sales order is defined. Youhave to define a container element for the response message.




Create a container element so_resp in the container Process. It is an abstractinterface of type crea_so_abstract.

11. Define a receive step for the message that is sent by the SD system afterhaving created the sales order.

Insert a receive step, ReceiveSO, after the send step. Message is so_respand use correlation CorrOrder.

12. You want to extract one single field of the asynchronous response message:the Status field. In this field you find whether the purchase order can becreated or not. You need a container element for this field.

Create a container element status_so for container CreateSalesAndPur-chaseOrdersBlock. 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→ SparPartLineItemList→ Status.

14. In a new block, you want to check whether the purchase order and salesorder have been created.

Add a second block step, AutomaticCompensation, in blockCreateSalesAndPurchaseOrdersBlock.

15. If one of the orders could not be created, the Ftatus field shows an ERROR.Then you cancel the purchase order, the sales order, and the process itself inbranch1 of the switch step.

Insert switch step CancelOrders into your block step AutomaticCompen-sation. Branch 1 is executed if one of the container elements status_po orstatus_so contains the value ERROR.

16. To delete the orders you need two send steps using the message po_resp withacknowledgement application (MM system) and the message so_resp withacknowledgement application (SD system).

Create asynchronous send step Cancel_PO in the Branch 1. Enter CancelPOfor the Send Context property. Message is po_resp, and Acknowledgementis Application.


Create an asynchronous send step, Cancel_SO, in Branch 1. EnterCancelSO for the Send Context property. Message is so_resp, andAcknowledgement Application.




18. Insert control step AlertCancelOrders into Branch1 to throw an alert. TheAlert Category is PROCESS ALERT and Alert Messsage could be GroupXX: PO and SO canceled, process canceled, where XX stands for yourgroup number.

19. The process itself is canceled using a control step.

Insert control step OrdersCanceled into Branch1 to cancel the process.

20. Check, save, and activate the integration process.

21. Send three messages to your integration process. Edit your XML messageto test the process with Customer 1000 and the materials 2000, 3000, and4000. Then no alert should be thrown.

If you use a customer number containing a Y, like 1000Y, theresponse message correlated to the CreatePurchaseOrderMessage fromAirline_Group_two indicates that an error occurred.

If you use a customer number containing a Z, like 1000Z, the responsemessage for a sales order message indicates that an error occured. Checkthe workflow log to make sure that in both cases the process is canceledand an alert has been thrown.

22. Check your Alert Inbox.



Solution 10: Create Orders - Exercise andextended solution - usable as a tutorialTask:Define a new block to create the sales and purchase order. Send the sales orderto airline_group_one and the purchase order to airline_group_two. Only ifboth orders are created successfully will the process be processed in the future.Otherwise an alert is thrown, the process is canceled, and the orders in bothsystems are canceled.




b) Enter Name: CreateSalesAndPurchaseOrdersBlock

2. You want to create a sales order and a purchase order in two systems inparallel. You need a fork step.

Insert fork step createparallel with two branches into your block stepCreateSalesAndPurchaseOrdersBlock .

a) Drag a fork step into the CreateSalesAndPurchaseOrdersBlock.

b) Enter Name :createparallel.

c) Enter value 2 in the Necassary 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, soyou have to define a correlation. The Customer Number is used for thecorrelation.




Create the correlation CorrOrder. Add correlation container Cust typexsd:string. 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 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 →SparPartLineItemList→ 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 foundusing a condition defined in the receiver determination. The condition isdetermined using the context property PurchaseOrder.

Create asynchron send step SendPO in the first branch. EnterPurchaseOrder for the Send Context property. This is important because therouting depends on this Send Context. Message is list, Acknowledgement isTransport and activate correlation CorrOrder.

a) Drag a send step into the first branch.

b) Name: SendPO.

c) Mode : Asynchronous, Message is list, Acknowledgement :Transport.

d) Enter send context PurchcaseOrder.

e) Activate Correlation is CorrOrder. Assign to Cust Interface Variable(list)→ XPath→ SparPartLineItemList→ CustNo.

5. The MM system sends back a message when the purchase order is defined,so you have to define a container element for the response message.

Create a container element po_resp in the Process Container . It is anabstract interface of type crea_po_abstract.

a) Add container element po_resp to the container list.

b) Category is Abstract Interface and Type iscrea_po_abstract.

6. Define a receive step for the message that is sent by the MM system afterhaving created the purchase order.




Insert a receive step ReceivePO after the send step. Message is po_resp anduse correlation CorrOrder.

a) Drag receive step ReceivePO after the send step SendPO.

b) Message is po_resp and use correlation CorrOrder.

7. You want to extract one single field of the asynchronous response message:the Status field. In this field you find whether the purchase order can becreated or not, so you need a container element for this status field.

Create a container element status_po for container CreateSalesAndPur-chaseOrdersBlock. 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→ SparPartLineItemList→ Status.

a) Drag container operation step getPOstatus after the receive step.

b) Operation is Assign and Container Element status_po.

c) Expression is Interface Variable (po_resp) → XPath →SparPartLineItemList→ Status.

9. Now you can create the send step for the sales order that activates thecorrelation. The receiver (business system airline_group_one) is found usinga condition defined in the receiver determination in the Integration Directory.The condition 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 therouting depends on this Send Context. Message is list, Acknowledgement isApplication, and activate correlation CorrOrder.

a) Drag a send step into the second branch.

b) Name: SendSO.

c) Mode: Asynchronous, Message is list, Acknowledgement:Application.

d) Enter send context SalesOrder.

e) Activate Correlation is CorrOrder. Assign to Cust Interface Variable(list)→ XPath→ SparPartLineItemList→ CustNo.




10. The SD system sends back a message when the sales order is defined. Youhave to define a container element for the response message.

Create a container element so_resp in the container Process. It is an abstractinterface of type crea_so_abstract.

a) Add container element so_resp to the container list.

b) Category is Abstract Interface and Type iscrea_so_abstract.

11. Define a receive step for the message that is sent by the SD system afterhaving created the sales order.

Insert a receive step, ReceiveSO, after the send step. Message is so_respand use correlation CorrOrder.

a) Drag receive step ReceiveSO after the send step SendPO.

b) Message is so_resp and use correlation CorrOrder.

12. You want to extract one single field of the asynchronous response message:the Status field. In this field you find whether the purchase order can becreated or not. You need a container element for this field.

Create a container element status_so for container CreateSalesAndPur-chaseOrdersBlock. 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→ SparPartLineItemList→ Status.

a) Drag container operation step getSOstatus after the receive step.

b) Operation is Assign and Container Element status_so.

c) Expression is Interface Variable (so_resp) → XPath →SparPartLineItemList→ Status.

14. In a new block, you want to check whether the purchase order and salesorder have been created.

Add a second block step, AutomaticCompensation, in blockCreateSalesAndPurchaseOrdersBlock.


b) Enter Step Name AutomaticCompensation .Continued on next page



15. If one of the orders could not be created, the Ftatus field shows an ERROR.Then you cancel the purchase order, the sales order, and the process itself inbranch1 of the switch step.

Insert switch step CancelOrders into your block step AutomaticCompen-sation. Branch 1 is executed if one of the container elements status_po orstatus_so contains 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 simplevariables are connected by an OR.


Create asynchronous send step Cancel_PO in the Branch 1. Enter CancelPOfor the Send Context property. Message is po_resp, and Acknowledgementis Application.

a) Drag a send step into Branch 1.

Name it Cancel_PO.

b) Mode is Asynchronous, Message is po_resp, andAcknowledgement is Application.

c) Enter send context CancelPO.


Create an asynchronous send step, Cancel_SO, in Branch 1. EnterCancelSO for the Send Context property. Message is so_resp, andAcknowledgement Application.

a) Drag a send step into Branch 1.

Name it Cancel_SO.

b) Mode is Asynchronous, Message is so_resp, andAcknowledgement is Application.

c) Enter Send context CancelSO.




18. Insert control step AlertCancelOrders into Branch1 to throw an alert. TheAlert Category is PROCESS ALERT and Alert Messsage could be GroupXX: PO and SO canceled, process canceled, where XX stands for yourgroup number.

a) Drag a control step into Branch1.

Name it AlertCancelOrders.

b) Alert Category is Process Alert.

c) Alert Messsage could be PO and SO order canceled,process canceled.

19. The process itself is canceled using a control step.

Insert control step OrdersCanceled into Branch1 to cancel the process.

a) Drag a control step into Branch1.

Name it OrdersCanceled.

b) Action is Cancel Process.


a) Check the integration process by choosingIntegration Process→Check. The results are displayed in the processing log section of theprocess editor.

b) Save the integration process with the Save button and go to the ChangeList. There you have to activate your integration process.

21. Send three messages to your integration process. Edit your XML messageto test the process with Customer 1000 and the materials 2000, 3000, and4000. Then no alert should be thrown.

If you use a customer number containing a Y, like 1000Y, theresponse message correlated to the CreatePurchaseOrderMessage fromAirline_Group_two indicates that an error occurred.

If you use a customer number containing a Z, like 1000Z, the responsemessage for a sales order message indicates that an error occured. Checkthe workflow log to make sure that in both cases the process is canceledand an alert has been thrown.

a) Send three messages with your http- client.

b) Use transaction SXMB_MONI. Select your message and call theworkflow log by clicking on entry PE.





a) Call the Runtime Workbench.

b) Select Alert-Inbox.

Caution: Your user must be assigned to the alert-category(transaction ALRTCATDEF) to receive an alert in the AlertInbox.





Exercise 11: Create Orders- Exercise andshort solution refer to the example solutionSolution_4 in the Integration Repository,software component SellSpareParts

Exercise ObjectivesAfter completing this exercise, you will be able to:� Use the switch step� Use the fork step� Send a message to your Alert Inbox

Business ExampleSales and purchase orders are created in parallel in your integration processin a new block. The sales order is sent to the SD system (business systemairline_group_one) and the purchase order is sent to the MM system (businesssystem airline_group_two). If one fails, both orders are canceled, an alert isthrown, and the process itself is cancelled.

You can force the ERROR situation for the purchase order if CustomerNo containsa �Y�. To create an error in the sales order, CustomerNo must contain a �Z.�



Task:Define a new block to create the sales and purchase order. Send the sales orderto airline_group_one and the purchase order to airline_group_two. Only if bothorders are created successfully, the process will be processed. Otherwise, an alertis thrown and the process is canceled.

The whole scenario takes place in a new block.

You want to create a sales order and a purchase order in two systems in parallel, soyou need a fork step.

The MM and SD systems send back messages when the orders are created. Thesemessages must be correlated with the corresponding send step. You have to definea correlation. The Customer Number is used for the correlation.

Now you can create the send steps for the purchase order and the sales order thatactivates the correlation. The receivers (business system airline_group_two andbusiness system airline_group_one) are found using conditions defined in thereceiver determination in the Integration Directory for the message interface. Theconditions are determined using the context properties PurchaseOrder (sendPO) and SalesOrder (send SO).

The MM and SD systems send back a message when the purchase order andthe sales order are defined, so you have to define a container element for eachresponse message. Then define a receive step for the message that is sent by theMM system after having created the purchase order, and define a receive stepfor the message sent by the SD system.

Because we want to cancel the orders if it isn't possible to create both, we needto know the status of each create order step. The status is found in the Statusfield of the asynchronous response message. We need to transfer this field in acontainer element of the integration process.

In a new block we check whether purchase order and sales order had been created.If not (Status field = ERROR), we cancel the purchase order, the sales order, andthe process itself. We also thow an alert with alert category PROCESSALERT.One possible alert text can be: Group xx: PO and SO canceled. Processcanceled. Therefore we need two send steps using the message po_resp withacknowledgement application (MM system) and the message so_resp withacknowledgement application (SD system).

Cancel process and throw alert are performed with control steps.







3. Send an message to your integration process. Edit your XMLmessage to testthe process. If you use a Customer Number containing a Y, like 1000Y, theresponse message correlated to the CreatePurchaseOrderMessage fromAirline_Group_two indicates that an error occurred. If you use Z, theresponse message for a sales order message indicates that an error occured.

Check the workflow log. It should look as follows:

Figure 81: Graphical Workflow Log




Solution 11: Create Orders- Exercise andshort solution refer to the example solutionSolution_4 in the Integration Repository,software component SellSparePartsTask:Define a new block to create the sales and purchase order. Send the sales orderto airline_group_one and the purchase order to airline_group_two. Only if bothorders are created successfully, the process will be processed. Otherwise, an alertis thrown and the process is canceled.

The whole scenario takes place in a new block.

You want to create a sales order and a purchase order in two systems in parallel, soyou need a fork step.

The MM and SD systems send back messages when the orders are created. Thesemessages must be correlated with the corresponding send step. You have to definea correlation. The Customer Number is used for the correlation.

Now you can create the send steps for the purchase order and the sales order thatactivates the correlation. The receivers (business system airline_group_two andbusiness system airline_group_one) are found using conditions defined in thereceiver determination in the Integration Directory for the message interface. Theconditions are determined using the context properties PurchaseOrder (sendPO) and SalesOrder (send SO).

The MM and SD systems send back a message when the purchase order andthe sales order are defined, so you have to define a container element for eachresponse message. Then define a receive step for the message that is sent by theMM system after having created the purchase order, and define a receive stepfor the message sent by the SD system.

Because we want to cancel the orders if it isn't possible to create both, we needto know the status of each create order step. The status is found in the Statusfield of the asynchronous response message. We need to transfer this field in acontainer element of the integration process.

In a new block we check whether purchase order and sales order had been created.If not (Status field = ERROR), we cancel the purchase order, the sales order, andthe process itself. We also thow an alert with alert category PROCESSALERT.One possible alert text can be: Group xx: PO and SO canceled. Processcanceled. Therefore we need two send steps using the message po_resp withacknowledgement application (MM system) and the message so_resp withacknowledgement application (SD system).




Cancel process and throw alert are performed with control steps.



a) See Solution_4 in the Integration Repository, software componentSellSpareParts if you have questions about implementing your process.


a) Check the integration process by choosing Integration Process→Check. The results are displayed in the processing log section of theprocess editor.

b) Save the integration process with the Save button and go to the ChangeList. There you have to activate your integration process.

3. Send an message to your integration process. Edit your XMLmessage to testthe process. If you use a Customer Number containing a Y, like 1000Y, theresponse message correlated to the CreatePurchaseOrderMessage fromAirline_Group_two indicates that an error occurred. If you use Z, theresponse message for a sales order message indicates that an error occured.

Check the workflow log. It should look as follows:





a) Send three messages with your http client.

b) Use transaction SXMB_MONI. Select your message and call theworkflow log by clicking on entry PE.

The graphical workflow log should look as follows:



a) Call the Runtime Workbench.

b) Select Alert-Inbox.

Caution: Your user must be assigned to the alert category(transaction ALRTCATDEF) to receive an alert in the AlertInbox.



Exercise 12: Extension

Exercise ObjectivesAfter completing this exercise, you will be able to:� Add a manual compensation

Business ExampleAs an extension, the creation of a purchase order is enhanced by a manualcompensation in case the creation of the purchase order fails. Application andtransport acknowledgments of send messages are used to realize this, and sendcontexts are used for routing purposes.

The following scenario should happen:

If the Response Status field for the purchase order shows ERROR, the processwaits for two minutes. If the error was corrected and a OK message is raisedmanually, the Response Status field is set to OK. This indicates that the purchaseorder has been manually corrected.

The correction can be done with report SPAREPARTS_MANUALCOMPENSA-TION in client 813 (!) of your SAP XI training system.

If you don�t run the report, no message is received, a timeout occures after twominutes, and the process is continued. In this case, the Response Status field for thepurchase order remains on ERROR and both orders are cancelled in the next block.

Task:Add a manual compensation to correct the status of the purchase order.

1. Check whether the container element status_po equals ERROR with a switchstep.

Add a switch step, check, after the container operation getPOstatus.Outcome Name 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 a block, ManualCompensation, into Branch 1 and define theexception TimeOut.

3. Add a deadline branch with one minute.

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 blockManualCompensation to handle theTimeOut exception.

6. In this branch, you throw an alert and then wait to see whether a secondmessage is sent by the business system (realized by a report).

Into the third branch of theManualCompensation block, insert a controlstep, POErrorControl, to throw the alert Group xx: PurchaseOrder couldnot be created, where xx stands for your group number.

7. Insert a receive step, ReceivePOAgain, after the control step. Message ispo_resp and use correlation CorrOrder.

8. After having received a message about the correction of the purchaseorder. the Status field is transferred to the container element status_po. Noautomatic compensation will be 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 yourhttp client, where the customer number contains a Y.

Run report SPAREPARTS_MANUALCOMPENSATION in client 813 withthe same customer number within the next 120 seconds to compensatemanually.

Check the graphical workflow log and the Alert Inbox.





Figure 84: Graphical Workflow Log: Extension



Solution 12: ExtensionTask:Add a manual compensation to correct the status of the purchase order.

1. Check whether the container element status_po equals ERROR with a switchstep.

Add a switch step, check, after the container operation getPOstatus.Outcome Name 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 a block, ManualCompensation, into Branch 1 and define theexception TimeOut.

a) Drag a block step into Branch 1.

b) Enter Step Name ManualCompensation.

c) Mode is Default and Exceptions is TimeOut.

3. Add a deadline branch with one minute.

a) Select the block step.

b) Call the context menu and insert a deadline branch.

c) Duration isone minute.

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 blockManualCompensation to handle theTimeOut exception.

a) Select theManualCompensation block.

b) Call the context menu and insert an exception branch.

c) Exception Handler is TimeOut.

6. In this branch, you throw an alert and then wait to see whether a secondmessage is sent by the business system (realized by a report).

Into the third branch of theManualCompensation block, insert a controlstep, POErrorControl, to throw the alert Group xx: PurchaseOrder couldnot be created, where xx stands for your group number.

a) Drag a control step into the third branch of theManualCompensationblock.

Name it POErrorControl.

b) Action is Throw Alert.

c) Alert Category is ProcessControl.

d) Alert Messsage could be Group xx: PurchaseOrder couldnot be created, where xx stands for your group number.

7. Insert a receive step, ReceivePOAgain, after the control step. Message ispo_resp and use correlation CorrOrder.

a) Drag receive step ReceivePOAgain after the control stepPOErrorControl.

b) Message is po_resp and use correlation CorrOrder.

8. After having received a message about the correction of the purchaseorder. the Status field is transferred to the container element status_po. Noautomatic compensation will be 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 yourhttp client, where the customer number contains a Y.




Run report SPAREPARTS_MANUALCOMPENSATION in client 813 withthe same customer number within the next 120 seconds to compensatemanually.

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.

The graphical weorkflow log should look as follows:


b) To check the Alert Inbox, use the Runtime Workbench.



Lesson Summary

You should now be able to:� Explain the relationship between integration processes in SAP XI and

workflows in SAP Business Workflow� Check the runtime version of an integration process in the SAP XI Runtime

Cache� Perform process and message monitoring� Perform basic troubleshooting


BIT430 Lesson: Process Execution Monitoring

Lesson: Process Execution Monitoring

Lesson OverviewThis lesson will have a look at the business process workflow from differentangles. You will learn the use of transaction SXMB_MONI_BPE to monitorworkflow executions.


� Use transaction SXMB_MONI_BPE� Monitor workflow executions� Use the workflow log

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

Monitor Workflow ExecutionThere 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 theworkflow. The focus in this lesson will be on the following five transactions:

� Process Selection: SWF_XI_SWI1� Processes for One Message Type: SWF_XI_SWI14� Processes for a Message: SWF_XI_SWI6� Diagnosis Processes with Errors: SWF_XI_SWI2_DIAG� Continue Processes Following Errors: SWF_XI_SWPR



Figure 87: Monitoring Workflow Execution

Process SelectionVia the Process Selection transaction, you are able to find workflows you areinterested in by searching with different criteria. All reports will lead to the sameworkflow view; the difference is the selection criteria used to get to the workflowlog. As seen in the above figure, the criteria to search for are quite extensive. Youcan search, for example, for the type, status, priority, or the time the workflowis created. Within the type and status fields, you have 11 choices in each case.Furthermore you can search for nine different priorities and five different deadlinestatuses. After making your choice, you can execute your query and the resultswill be shown.



Figure 88: Select Which Workflows You Want to Monitor

By designating F as the type of work item, you will look at the log for eachinstance of your integration process. This is normally easier than looking at eachstep individually. You also may need to change the date/time range to get theexecutions that interest you. You could also change the Status field. You couldlook only at executions in COMPLETED status, ERROR status, STARTED status,or CANCELLED status.

As a result of the prior query, you get a window with a lot more details, such asID, workflow number (WS#######), or the workflow status. Double-clickingon a process instance you are interested in leads you to the workflow log andprovides even more details.

Workflow LogThe following figure shows the actual workflow log. At the very top the name ofthe workflow is shown. This is the exact name of the integration process createdin the Integration Repository. All the steps belonging to this process instance areshown in a tree structure, telling which steps were carried out and completed, stillin process, or have an error.



Figure 89: 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 ofthe workflow log.



Moreover the Workflow Log provides three tabs:

� Workflow Chronicle

This is the standard tab, showing you the different workflow steps thathave already been processed or are currently pending. If the workflowhas a sub-workflow structure, the sub-workflows are displayed as well.Furthermore, it offers you the possibility to get more details of the singlesteps or to switch to the graphical view.

� Workflow Agents

The first level shows all the employees (users) involved in this workflowup to now. The second level shows the following information for eachemployee (user):

� What action was carried out in what step� When the action was carried out� Which objects were involved

� Workflow Objects

This tab shows what information was generated and processed, and how. Italso shows the message GUID for this workflow. The first level lists theobjects that are related to the workflow or that have been addressed up tonow during the execution 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

Since this workflow log is non-technical, researching or solving problems in thisview is not possible in many cases. To get more details it is necessary to drill intothe technical view of the log. This is done by choosing the Technical view icon.

Technical LogThe technical log view shows technical information for the execution of aworkflow, as required by workflow systems administrators, for instance.TheTechnical view shows technical nodes and control structures and makesadditional data available, such as container elements, employee (user) data, andworkflow data.



Figure 90: Technical Workflow Log



The status of the work item is also displayed. There are nine different statusespossible:

� Ready (Ready)

The work item is available for execution. Depending on the type, it can beexecuted by the receipient in his Business Workplace or in the backgroundby the system.

� Reserved (Selected)

This work item is reserved in the Business Workplace by a receipient. Thisstatus removes the work item from the Business Workplaces of all otherreceipients.

� In Process (Started)

The work item is currently being processed.This means that either thetask/method associated with the work item is currently being executed or atthat processing 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 executedonce, but processing is not yet completed. The work item can therefore bestarted again (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 itemcannot be started again. Refer to the work item log for the possible errorcauses.

� In Preparation (Checked)

The work item can be created, but the condition for the step Create WorkItem is not yet fulfilled.

To get more detail or to manually change the status, click on the ID or on the StepDescription, which will lead you to the Display work item window.



Display Work ItemThis view provides you more information on the work item and let you change thestatus manually. To do this choose Edit �> Change. On the left-hand side of thewindow, a list with services for administration will appear. In this list you thensee all available possibilities for manually changing the work item. Be aware thatyour changes might effect the correct execution of the integration process and onlyperform changes if they are really necessary.

Figure 91: 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.� Depending on the status and type of type, sometimes Complete Manually

will work, and sometimes it will not.

In this particular case we have a wait step. A wait step means the workflow iswaiting for something to happen (perhaps waiting on a message confirmation).Often Complete Manually does not work with a wait step. In this situation youmight have to Logically Delete. Logically delete will end the execution and set thestatus of the workflow to CANCELLED.

Note: Normally you should not manually complete or cancel workflowexecutions.



More Important Reporting TransactionsThe following are important reporting transactions:

� Processes for One Message Type

Transaction code: SWF_XI_SWI14

� Processes for a Message

Transaction code: SWF_XI_SWI6

� Diagnosis Processes with Errors

Transaction code: SWF_SI_SWI2_DIAG

� Continue Processes Following Errors

Transaction code: SWF_XI_SXPR

� Continue Processes

Transaction code: SWF_XI_SWPC

� Workflows from a Message Log

Transaction code: SXMB_MONI

� RFC Monitor

Transaction code: \SM58

� Processes with Missed Deadline

Transaction code: SWF_XI_SWI2_DEAD

Transaction SWF_XI_SWI14 is designedto find the workflow log by the interfacename and interface namespace.

In addition to the transaction Processes for One Message Type, you can querythe GUID in processes for a message.

Executing transaction diagnosis processes with errors will query all workflowswith errors. In the result list you might highlight any of them and select RestartWorkflow. You can also double-click on each work item and research the error. Ifyou choose to restart the workflow, it starts from the point of the error.

Transaction SWF_XI_SXPR is another way to restart workflows with errors. Youcan either select workflows with errors depending on your query criteria andthen restart particular ones by selecting them in the result list, or you may chooseRestart immediately. By selecting this option, all workflows found on your criteriawill be restarted immediately all at once.

Similar to the Continue Processes Following Errors transaction is transactionSWF_XI_SWPC. The difference is that workflows are selected that crashed due toa system error. These workflows will be continued, and not restarted.



Transaction SWF_XI_SWI2_DEAD lets you choose work items with a misseddeadline.

You can display the log files of the transactional RFC with transaction code SM58.

Workflows from Message LogAnotherway to get to the workflow log is by using XML monitoring (transactionSXMB_MONI). If you have a message starting an integration process you mightgo to the Outbound column and click on PE. You will then be directed to theworkflow log. Moreover you can take the Message ID for a particular workflow,go to transaction code SWF_XI_SWI6 (Processes for a Message), and find allspecific workflow executions for this message ID (GUID). To get the MessageID, go to the Queue_ID column in XML Monitoring and take the ID out of thespecific row.



Lesson Summary

You should now be able to:� Use transaction SXMB_MONI_BPE� Monitor workflow executions� Use the workflow log



Lesson: Message Monitoring

Lesson OverviewThis lesson will show you how to monitor a message and to display the workItem container.


� Navigate to the involved messages of and� Check the status of synchronous/asynchronous communication

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 MonitoringMonitor for Processed XML Messages is called with transaction SXMB_MONI.To display information about persistent XML messages, you have to select themessages beforehand using particular criteria.


BIT430 Lesson: Message Monitoring

Figure 92: Message Monitoring

You can find messages invoking an integration process by checking the inboundand outbound values. PE (process engine) indicates that an integration process isinvolved.

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

not yet been deleted� A table containing status information about the involved synchronous

request messages



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

been canceled.� 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

symbol bar.� 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 severalmessages to a target business system.

Figure 93: Display Workflow Log



The workflow log displays the complete process with all work items. To displaythe container and the XML message used in this work item, click the ShowContainer icon.

Figure 94: Display Work Item Container

To display the message before transformation, select the Table icon precedingMESSAGES_IN. The table is displayed in the lower-right window. From thecontext 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 13: Test Your Knowledge

Exercise ObjectivesAfter completing this exercise, you will be able to:� Explain the characteristics of the BPE� Avoid mistakes during design

Business ExampleYou have to explain the characteristics of the Business Process Engine (BPE) andto show your colleguages how to monitor the Runtime Cache.

Task:Answer the following questions

1. What are the characteristics of the BPE?

2. When is a workflow of an integration process generated for the first time?

3. What are some possible mistakes during design time that can cause errorsduring runtime?



Solution 13: Test Your KnowledgeTask:Answer the following questions

1. What are the characteristics of the BPE?

Answer: The BPE provides runtime support for SAP XI integrationprocesses. It uses the Web AS 6.40 business workflow Runtime Engine andsupports all integration processes defined in the Integration Builder.

2. When is a workflow of an integration process generated for the first time?

Answer: A workflow is generated whenever an integration process is usedin the Integration Directory and the change list is activated.

3. What are some possible mistakes during design time that can cause errorsduring runtime?

Answer: Invalid conditions or the use of non-activated correlations.



Lesson Summary

You should now be able to:� Navigate to the involved messages of and� Check the status of synchronous/asynchronous communication



Lesson: Event Trace and Troubleshooting

Lesson OverviewThis lesson will give an overview of the event trace and of troubleshootingcommon errors while working with ccBPM.


� Perform basic troubleshooting

Business ExampleYou activated your integration process, performed the configuration in theIntegration Directory and tested your process. While testing, some errors occuredand now you want to do some troubleshooting to localize the error.

Event TraceThe event trace logs all correctly created events, irrespective of whether potentialreceivers exist. If a receiver is entered in the event trace, it does not necessarilymean that this receiver was called successfully.

An event is an occurrence of a change of state in an object, which is publishedthroughout the system. An event is an object type component. The list of possibleevents is defined with the relevant object type in the Business Object Repository.This list can be extended according to customer requirements using the delegationconcept. The actual creation of the events added must be catered for. Eventscan start, terminate, or continue tasks and workflows. An example of an eventwould be an entered invoice.

To use the event trace, you have to make sure that the event trace is activated. Ifthe event trace is not switched on and you want to trace an event, you have toswitch on the event trace and restart the event you want to trace.

To switch on the event trace, call transaction SWELS. In addition to switching onand off the event trace you can also define restrictions for the trace. This has theadvantage of logging only special events instead of logging all events.


BIT430 Lesson: Event Trace and Troubleshooting

Figure 95: Event Trace: Start and Stop

The following data is logged in the event trace:

� Event data

� Triggering object type, triggering object� Event ID� Triggering program� Trigger date and time

� Receiver and linkage data

� Receiver function module� Receiver type� Receiver instance� Linkage status

To display the event trace, transaction SWEL is used. The event trace display canalso be restricted using a selection screen. In addition to the criteria for eventdata, receiver data, and event linkage data, the display can also be restricted tolinkages with errors.



Figure 96: Event Trace: Selection Screen

If the event trace should be deleted, transaction RSWELOGD is used. Again thedeletion of events can be controlled using selection criteria. The function does nottherefore always delete the entire event trace automatically. By marking the Onlydisplay list field, the events you select are not deleted but displayed in a list.

TroubleshootingIn the following, some common errors and their causes � as well as their removalproposals � are shown.

Messages sent to a process go to error state

� Cause 1: Customizing not complete

� Check SWF_XI_CUSTOMIZING: All entries must have the statusgreen.

� Cause 2: Cache refresh not completed

� Check SXI_CACHE: Cache content has to be up-to-date (green trafficlight). As well, check whether all components used in your process areavailable in your cache. In any case, you may start a cache refresh.

� Cause 3: Runtime version of the process could not be created

� Check SXI_CACHE: Return code of the process has to be 0.� Cause 4: Invalid condition (for example, comparison between xsd: date

and xsd: time)

� Check SXI_CACHE: Return code of the process has to be 0.



Messages sent to a process are delivered successfully butthere is no corresponding process instance

� Cause: Communication between messaging pipeline and process engine isnot completed (messages are sent asynchronously to the process enginebased on tRFC)

� Check SWU2: There should be no tRFC entries waiting or in ERRORstate.

Process does not start

� Cause: Start correlation is not active

� Check SXI_CACHE: Display integration process in Process Builder(mark the integration process and click on the glasses icon) and chooseBasic Data→ Start Events→ Check if Start Events are active (theprocess is started via events).

Process does not start or message is not deliv-ered to started process

� Causes: Event queue background job not running. Messages are deliveredto process instances via events.If events cannot be delivered, the event isput into the event queue (if active).

� Check SWEQADM: Event queue background job must be running.Use event browser to check errors.

Message does not arrive in target system

� Cause: Outbound message queues are blocked due to high system load

� Check SMQ1: Check sender system outbound queues.

Message sent to a process shows PE indicator, but clickingon it does not display process instances

� Cause: The inbound queues of the process engine are not processed. Severalmessages are sent to the process and the messages are queued in a qRFCqueue. This is to ensure that messages are serialized correctly (for example,if a message activates a correlation that should be used by another message)

� Use SXMB_MONI to check messages.� Check SXMB_ADM→ Manage Queues. The XBQO* queues have

to be activated.



Message sent to a process has adapter status red

� Cause: Correlation failed, no process instance found (message that activatesthe correlation arrives after the message that uses the correlation)

� Check SXMB_MONI.� Use SWELS to switch on event trace and re-run the message.� Use SWEL to check the event trace.� Check SWEQADM.

Useful Transactions and ReportsTransactions

� SXI_CACHE: Runtime cache� SXMB_MONI_BPE: Process monitoring� SXMB_MONI: Message monitoring� SWI1: Processes and work items� SWELS: Switch on event trace� SWEL: Display event trace� RSWELOGD: Delete event trace� SWEQADM: Check events

Reports

� Report RSWF_CRL_MAINTAIN: Check active correlations



Exercise 14: Send Purchase Order toSupplier

Exercise ObjectivesAfter completing this exercise, you will be able to:� Send a purchase order to a supplier

Business ExampleYou send a purchase order to the supplier. An order response is received andacknowledged.

Task:Send the purchase order to the supplier and acknowledge the received orderresponse.

1. Collapse the CreateAndPurchaseOrdersBlock block and add aSupplierCommunication block.

2. Insert an asynchronous send step: SendPO2Supplier. Use message po_respand enter Supplier as 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 messagepo_confirmation and correlation CorrOrder.

5. Insert a positive acknowledgement send step, SendAcknowledgement, formessage po_confirmation.

6. Save, check, activate, and test your process by sending three line items viathe HTML client.

Use the materials 1000, 2000, and 3000 and the customer 1000.

The workflow log should look as follows:







Solution 14: Send Purchase Order toSupplierTask:Send the purchase order to the supplier and acknowledge the received orderresponse.

1. Collapse the CreateAndPurchaseOrdersBlock block and add aSupplierCommunication block.

a) Select CreateAndPurchaseOrdersBlock and collapse the block viathe context menu or by clicking on the minus icon in the upper-leftcorner of the block.

b) Drag a block step behind the just-collapsed block and switch to theProperties area.

c) Step Name: SupplierCommunication

2. Insert an asynchronous send step: SendPO2Supplier. Use message po_respand enter Supplier as Send Context property.

a) Drag a send step into the SupplierCommunication block.

b) Switch to the Properties Aarea.

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 messagepo_confirmation and correlation CorrOrder.

a) Drag a receive step behind the send step SendPO2Supplier.


c) Step Name: ReceiveOrderConfirmation

d) Message: po_confirmation

e) Use Correlations: CorrOrder

5. Insert a positive acknowledgement send step, SendAcknowledgement, formessage po_confirmation.

a) Drag a send step behind the receive step ReceiveOrderConfirmation.


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 viathe HTML client.

Use the materials 1000, 2000, and 3000 and the customer 1000.

The workflow log should look as follows:








a) Save the process.


c) If no errors occur, activate the process.

d) Open the HTML client and test the overall process by seding threeline items to SAP XI.

e) The workflow log should display as follows:




Lesson Summary

You should now be able to:� Perform basic troubleshooting


Unit Summary BIT430

Unit SummaryYou should now be able to:� Explain the relationship between integration processes in SAP XI and

workflows in SAP Business Workflow� Check the runtime version of an integration process in the SAP XI Runtime

Cache� Perform process and message monitoring� Perform basic troubleshooting� Use transaction SXMB_MONI_BPE� Monitor workflow executions� Use the workflow log� Navigate to the involved messages of and� Check the status of synchronous/asynchronous communication� Perform basic troubleshooting


Unit 4Combining Integration Processes with

Business Workflow

Unit OverviewThe unit explains how a customer can combine a process implemented as abusiness workflow with a cross-component process implemented using ccBPM.


� Distinguish between the object-based SAP business workflow and themessage-based integration processes

� Explain the different methods to start a workflow using an SAP XI message

Unit ContentsLesson: Combining Business Workflow and ccBPM... . . . . . . . . . . . . . . . . . . . .218


Unit 4: Combining Integration Processes with Business Workflow BIT430

Lesson: Combining Business Workflow and ccBPM

Lesson OverviewThe lesson provides an overview how processes implemented in ccBPM can becombined with processes running in a local system or application and are executedby SAP Business Workflow.


� Distinguish between the object-based SAP business workflow and themessage-based integration processes

� Explain the different methods to start a workflow using an SAP XI message

Business ExampleYou want to start a business workflow in the target system when an SAP XImessage arrives.

The Question to AnswerWithin SAP NetWeaver, separate tools are used to define integration processesand human workflow processes.

� Integration processes:

� Are message-based� Are interface-focused� Are inter-application (cross-component) oriented� Have no support for human interaction� Are enabled with SAP XI

� SAP Business Workflow processes:

� Are object-based� Are human-focused� Are intra-application oriented� Have no support for mapping, routing, or message transformations� Are enabled with SAP Web AS

A lot of automated business processes involve a combination of the two and thereare some hurdles to overcome.


BIT430 Lesson: Combining Business Workflow and ccBPM

Combining integration processes with SAP Business Workflow requires mergingthe message-oriented approach of SAP XI with the object-orientated approachof SAP Business Workflow.

Hurdles to Leap

� Hurdle 1: How do you correlate a message with a payload consisting of rawdata tags to a single instance of a business object (integration process→workflow)?

� Hurdle 2: How do you convert a business object consisting of a virtuallyinfinite tree of data attributes to a single message (workflow→ integrationprocess)?

In the following you see three best-practice mechanisms to leap these hurdles.

� Determine a unique object key from a message tag and trigger the workflow.� Allow the application to trigger a business workflow indirectly via an event.� Convert the message data to workflow container data and use the workflow

to manipulate forms instead of business objects.

Mechanism 1: Determine a Unique Object KeyMechanism one can be described as follows:

� Use the SAP XI mapping to determine the business object key from themessage and generate a new message, which is sent to the destinationcomponent to trigger a workflow based on this business object.

� This can be done by coding this into the proxy itself or by using mappingwithin SAP XI to determine the object key.

Advantages of the mechanism are:

� Simple to implement� Error-handling (such as when the tag is missing) can be handled within XI

Disadvantages of the mechanism are:

� The problem is that the ccBPM process assumes that the message will berouted to a component where the business object exists. This will only be thecase when there is very static routing

� A representation of the business object must exist and the instance itselfmust reside in the workflow component. Often there is no business objectrepresentation of the message data, so forms processing is required ratherthan business object methods.



The ccBPM process transmits a message containing the data for an event tobe triggered. A proxy receives the message and triggers the correspondingevent using the function module (API) SAP_WAPI_CREATE_EVENT orSAP_WAPI_START_WORKFLOW. The event method is preferable becausedifferent workflows can be switched on and off via the event linkage in thecomponent without touching the XI server.

The data passed to the API is the object type, event name, object key and, ifnecessary, a container holding supplementary information.

Data is returned to the XI process via a step in the workflow or via a destructormethod.

Hint: The transfer mechanism can be done via proxy in SAP Web AS6.20+. In earlier releases, the RFC adaptor can be used.

This scencario will be the exception rather than the rule.

Mechanism 2: Trigger a Business Workflow IndirectlyMechanism two can be described as follows:

� Send a message to the target system and allow the application to trigger abusiness workflow indirectly.

� For instance, send an object status to the system and the workflowcan be triggered via standard component customizing such asstatus/change-document workflow triggering.


� No special development necessary and no customizing in SAP XI� Different components can follow their own policies, for example, one could

choose to trigger a workflow, whereas another could handle the scenario withcustom transactions

Disadvantage of the mechanism is:

� The process loses transparency.

In terms of adaptability and agility, this is better than mechanism one.



Mechanism 3: Send the Message Data to a WorkflowMechanism three can be described as follows:

� Convert the message data to workflow container data and use the workflowto manipulate forms instead of business objects.

� The data is transferred from SAP XI via a proxy, which calls an API tostart the workflow directly.

This is pure process-to-process implementation. The workflow can useforms to process the data.

� Variation of this method: Write the message data to a database cluster andaccess it via your own business object, which you have developed yourself.

The data is transferred from SAP XI via a proxy, which transfers the datato the cluster and then calls an API to start the workflow directly. Theworkflow can access the data via the object that you have created and, afterthe workflow finishes, the database entry can be deleted.


� There is no need to correlate the data to a business object. The data canbe processed independently.

� The variation allows complex data structures to be accessed in the workflow.� Process transparency is retained.

Disadvantages of the mechanism are:

� Workflow performance suffers if a lot of data is carried in the d.

The variation of the message using a database cluster and an object avoidsthis by storing the data locally.

� Forms processing in workflow is not optimized for the Web. Developmentwork is required for web-based forms (for example, WebDynpro, HTMLforms, or WebFlow services).

� Standard applications and transactions cannot be used, so more developmenteffort is required (particularly if you use a database cluster and an object ofyour own).

This is the preferred method for starting a workflow from SAP XI.

The required skills are: Knowledge of ABAP/ABAP OO, SAP BusinessWorkflow, and SAP Exchange Infrastructure.



Sending Message Data to a Workflow and SendingData Back to SAP XISending message data to a workflow means:

� Generate a proxy in the workflow component. This generates an ABAPfunction module which can then be edited. If the workflow component isbased on a release earlier than Web AS 6.20, use the RFC Adaptor instead.

� Develop a short routine that fills a workflow container and triggers theworkflow.

Start the workflow using function module SAP_WAPI_START_WORK-FLOW (variation using a local object) or function moduleSAP_WAPI_CREATE_EVENT (variation using an event).

� Develop the forms and the workflow.

Notice that the workflow is not triggered via an event because there is nounderlying business object. A generic event (for example, forms created) isdifficult to maintain because each forms scenario would need a different interfaceor a special mechanism for collecting the different data structures relating todifferent forms.

SAP_WAPI_START_WORKFLOW is the standard API for starting workflows.

Hint: If you are using simple forms (requiring structures) you may haveto use the function SWW_WI_START_SIMPLE instead of the preferredSAP_WAPI_START_WORKFLOW API so that a container element canbe passed to the workflow. If you are using another forms technique(such as Adobe via WebDynpro or ITS HTML forms) then you shoulduse the standard API.

If you want to transfer data back to SAP XI, proceed as follows:

� No business object is involved and only the forms data needs to betransferred back to SAP XI.

� Create a final step in the workflow to call the proxy and return the resultsto SAP XI



Lesson Summary

You should now be able to:� Distinguish between the object-based SAP business workflow and the

message-based integration processes� Explain the different methods to start a workflow using an SAP XI message

Related InformationIn the Appendix, you will find example coding for both sending a message andtransferring data.


Unit Summary BIT430

Unit SummaryYou should now be able to:� Distinguish between the object-based SAP business workflow and the

message-based integration processes� Explain the different methods to start a workflow using an SAP XI message


BIT430 Course Summary

Course SummaryYou should now be able to:

� Describe the components of Business Process Management� Implement ccBPM processes using the process editor� Test ccBPM processes� Monitor ccBPM processes


Course Summary BIT430


Appendix 1Combining ccBPM and Business Workflow:

Example Coding

Send the Message Data to a Workflow: ExampleCodingmethod 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 1: 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.

Transfering Data Back to SAP XI: Example CodingNo business object is involved and only the forms data needs to be transferredback to SAP XI.

Create a final step in the workflow to call the proxy and return the results toSAP XI.

method PUSH_ORDER_STATUS .

data: output type ZWFWFDTYPE_MSG,

obj type ref to ZWFCO_ORDERWFTRIGGER_OUT, lo_sys_exception TYPE REF TO

output-WFDTYPE_MSG-PRIORITY = sales_order-priority.

output-WFDTYPE_MSG-net_value = sales_order-net_value.

output-WFDTYPE_MSG-transdescription1 = sales_order-transdescription1.

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=>a

TRY.

CALL METHOD ZWFCO_ORDERWFTRIGGER_OUT=>EXECUTE_ASYNCHRONOUS

EXPORTING


BIT430 Appendix 1: Combining ccBPM and Business Workflow: Example Coding

OUTPUT = output

.

CATCH CX_AI_SYSTEM_FAULT INTO lo_sys_exception.

ENDTRY.

* Commit work will be executed by the workflow management system whenever the task is exec

endmethod.


Appendix 1: Combining ccBPM and Business Workflow: Example Coding BIT430


Appendix 2BPM Procedural Model 2004

The following figures explain the BPM procedural model.

The described procedural model is a recommendation of how to leverage thetechnologies and business process knowledge of SAP and IDS Scheer in anend-to-end BPM implementation in 2004. Independent implementation of thedescribed software components is also possible.

Figure 100: BPM Procedural Model 2004


Appendix 2: BPM Procedural Model 2004 BIT430

Figure 101: BPM Procedural Model

Figure 102: Phases of Procedural Model (Customer Engagement Lifecycle)


BIT430 Appendix 2: BPM Procedural Model 2004

Figure 103: Phases of Procedural Model (Configuration / Integration)

Figure 104: Phase 1: Create a Company Process Map



Figure 105: Phase 1: Analyze Current Processes

Figure 106: Phase 2: Scoping of Future Business Processes



Figure 107: Phase 2: Design a Reference-Based Model

Figure 108: Phase 3: Configure the Application Components



Figure 109: Phase 3: Model Process Integration Scenarios

Figure 110: Phase 3: Maintain Integration Metadata



Figure 111: Phase 3: Model Integration Processes

Figure 112: Phase 3: Process Integration Configuration



Figure 113: Use Case BPM Procedural Model 2004

Figure 114: Solution Map: High Tech: Business, Medical, and ConsumerOEMs (v 1.0)



Figure 115: Solution Map: Scenario Detail High Tech: Business, Medical,and Consumer OEMs (v 1.0)

Figure 116: USE CASE: Sales Order Processing



Figure 117: Phase 1: Company Process Map

Figure 118: Phase 2: Scoping



Figure 119: Phase 2: Design Reference-Based Model (1)

Figure 120: Phase 2: Design Reference-Based Model (2)



Figure 121: Phase 3: Component Configuration

Figure 122: SAP Exchange Infrastructure: Integration Builder



Figure 123: Phase 3: Model Integration Scenario

Figure 124: Integration Scenario Design



Figure 125: Phase 3: Maintain Integration Metadata

Figure 126: Phase 3: Model Integration Process



Figure 127: Phase 3: Model Integration Process (Detail View)

Figure 128: Phase 3: Process Integration Configuration (1)



Figure 129: Phase 3: Process Integration Configuration (2)

Figure 130: Phase 4: Operations (1)



Figure 131: Phase 4: Operations (2)




FeedbackSAP AG has made every effort in the preparation of this course to ensure theaccuracy and completeness of the materials. If you have any corrections orsuggestions for improvement, please record them in the appropriate place in thecourse evaluation.


Documents

BIT430 - 2005-Q4 - A4 - Business Process Management