BIT430
SAP NetWeaver PI Business
Process Management
SAP NetWeaver Date Training Center Instructors Education WebsiteParticipant Handbook
Course Version: 74Course Duration: 3 Day(s) Material Number: 50089751
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Trademarks
• Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered 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 trademarks of Citrix Systems, Inc.
• HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide 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.com are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.
Disclaimer
THESE MATERIALS ARE PROVIDED BY SAP ON AN "AS IS" BASIS, AND SAP EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, EXPRESS OR APPLIED, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THESE MATERIALS AND THE SERVICE, INFORMATION, TEXT, GRAPHICS, LINKS, OR ANY OTHER MATERIALS AND PRODUCTS CONTAINED HEREIN. IN NO EVENT SHALL SAP BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES OF ANY KIND WHATSOEVER, INCLUDING WITHOUT LIMITATION LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM
This handbook is intended to complement the instructor-led presentation of this course, and serve as a source of reference. It is not suitable for self-study.
Typographic Conventions
American English is the standard used in this handbook. The following typographic conventions are also used.
Type Style Description
Example text Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths, and options.
Also used for cross-references to other documentation both internal (in this documentation) and external (in other locations, such as SAPNet).
Example text Emphasized words or phrases in body text, titles of graphics, and tables
EXAMPLE TEXT Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example SELECT and INCLUDE.
Example text Screen output. This includes file and directory names
and their paths, messages, names of variables and parameters, and passages of the source text of a program.
Example text Exact user entry. These are words and characters that you enter in the system exactly as they appear in the documentation.
<Example text> Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.
Icons in Body Text
The 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's presentation.
Course Overview ... ... ... ... ... ... vii
Course Goals. . . .. . . .. . . .. . . .. . . .. . . .. . . .. . . vii
Course Objectives . . . .. . . .. . . .. . . .. . . .. . . .. . . .. . . vii
Unit 1: Business Process Management (BPM) Motivation and Approach . ... 1
Overview of the Development of Business Process Management in the SAP NetWeaver Environment . . . .. . . .. . . .. . . .. . . .. . . .. . . 2
BPM Standards . . . .. . . .. . . .. . . .. . . .. . . .. . . .. . . 11
ccBPM as Part of SAP NetWeaver Process Integration Infrastructure . . . .. . . 17
Unit 2: Business Process Management: Cross-Component BPM ... ... 35
First Steps in ccBPM .. . . .. . . .. . . .. . . .. . . .. . . .. . . 37
Step Types (Part 1) and Correlation. . . .. . . .. . . .. . . .. . . .. . . 58
Step Types (Part 2) and Exception Handling . . . .. . . .. . . .. . . .. . . 76
Process Templates and Step Groups . . . .. . . .. . . .. . . .. . . .. . . . 104
Step Types (Part 3) . .. . . .. . . .. . . .. . . .. . . .. . . .. . . . 122
Unit 3: Business Process Management: Execution and Troubleshooting. ....151
Business Process Engine: Overview and Runtime Cache. .. . . .. . . .. . . . 153
Process Execution Monitoring .. . . .. . . .. . . .. . . .. . . .. . . . 185
Message Monitoring . .. . . .. . . .. . . .. . . .. . . .. . . .. . . . 198
Unit 4: Business Activity and Performance Management ... ... .... 211
Business Activity Monitoring in ccBPM . .. . . .. . . .. . . .. . . .. . . . 212
BPE Performance Management . . . .. . . .. . . .. . . .. . . .. . . . 218
Appendix 1: Optional Exercise for Pattern - Overall Scenario: Create Integration Process, Integrated in SAP Exchange Infrastructure ... ... ....235
Appendix 2: Solution for Optional Exercise Pattern - Overall Scenario: Create Integration Process, Integrated in SAP Exchange Infrastructure ... ....237
Appendix 3: Optional: Combining ccBPM and Business Workflow: Example Coding ... ... ... ... ... ... ....243
The course provides an overview of cross-component Business Process Management (ccBPM) in the SAP NetWeaver environment. You will learn about ccBPM and all its components.
The course will also explain how to implement ccBPM processes and introduce Business Activity Monitoring.
Target Audience
This course is intended for the following audiences:
• Consultants in the area of Business Process Management
• Anyone who is interested in Business Process Management in SAP NetWeaver • Customers who want to implement cross-component processes
• Project managers in the area of Business Process Management
Course Prerequisites
Required Knowledge
• BIT400 (SAP NetWeaver Process Integration)
• Good knowledge of the configuration of the SAP Process Integration Infrastructure
Recommended Knowledge
• Knowledge of SAP Business Workflow
Course Goals
This course will prepare you to:
• Understand the concepts of Business Process Management
• Understand the logic of cross-component Business Process Management • Use SAP Exchange Infrastructure to implement cross-component processes in
Course Objectives
After completing this course, you will be able to:
• Describe the components of Business Process Management • Use the process editor to implement ccBPM processes • Test ccBPM processes
Unit 1
Business Process Management (BPM)
Motivation and Approach
Unit Overview
This lesson gives you a general overview of SAP Business Process Management.
Unit Objectives
After completing this unit, you will be able to:
• Explain the implementation of business process management in the SAP NetWeaver environment
• Understand the objectives and tasks of technical process integration with ccBPM • Explain the basic principles of BPM standards
• Export a business process • Import a business process
• Describe the main features of ccBPM
• Describe the integration scenario used in BIT430
Unit Contents
Lesson: Overview of the Development of Business Process Management in the SAP NetWeaver Environment . . . .. . . .. . . .. . . .. . . 2 Lesson: BPM Standards . . . .. . . .. . . .. . . .. . . .. . . 11 Lesson: ccBPM as Part of SAP NetWeaver Process Integration Infrastructure . . . .. . . .. . . .. . . .. . . .. . . .. . . .. . . .. . . 17
Lesson: Overview of the Development of Business
Process Management in the SAP NetWeaver
Environment
Lesson Overview
In this lesson we will discuss business process management in SAP NetWeaver and customer requirements in the context of business process management. You will also learn how SAP wants to realize a unified modeling environment for business processes in the future.
Lesson Objectives
After completing this lesson, you will be able to:
• Explain the implementation of business process management in the SAP NetWeaver environment
• Understand the objectives and tasks of technical process integration with ccBPM
Business Example
Your 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-SAP catalog/CRM system sends the spare part items in individual messages and an integration process starts with a collect pattern: the order items are merged into a single message. This message is used for preparations taking place in the company's sales and distribution (SD) system. A synchronous call is made to the SD system to check whether missing materials have to be created. If so, the materials are created by looping through a list of missing materials and sending each material to the receivers, materials management, and the SD system. Then a sales order and a purchase order are created.
Let us image that SAP delivers a standard process for selling spare parts and that your company wants to adapt the process to customer-specific requirements. Participants of the “selling spare parts” project want to know everything about the different levels of Business Process Management with SAP NetWeaver and how to implement processes.
To maintain its competitiveness over time, a company's process landscape must remain flexible in the face of changes.
Such changes might include the development of new markets, the introduction of new products to the market, changes in laws, the extension of business partner networks, the takeover of other companies, and the outsourcing of processes to service providers. End-to-end (E2E) business processes can be described as combinations of various process types:
• User-centric composite processes
are designed to support user interaction. This process group is supported using a new BPM modeling tool as part of the SAP NW Composition Environment. • Kernel application or platform processes
form the SAP standard as an integrative part of the Business Process Platform (BPP).
• System-centric integration processes
describe the integration between applications (A2A) and/or business partners (B2B). This process group is implemented using the SAP NetWeaver Process Integration Platform.
Hint: These different types of business processes communicate with each
Figure 1: BPM: Modules of the SAP NetWeaver BPM Function
Implementing Business Process Management in the SAP NetWeaver Environment
With SAP NetWeaver, business processes can be defined and implemented on different levels of the architecture. The following figure shows how Business Process Management is integrated in the SAP NetWeaver environment.
As an optional module, customers can use the SAP Enterprise Modeling Applications from the IDS Scheer company. The advantages of this modeling level are particularly evident in large projects on the enterprise level. Enterprise Modeling goes far beyond the conceptual modeling of business processes. The focuses are planning and control of an enterprise's entire IT architecture.
Between the enterprise modeling level and the SAP domains, integration and communication takes place via the SAP Solution Manager. This provides reference content for the process configuration as well as transactional variants of business process scenarios.
The SAP NetWeaver Composition Environment (CE) supports • A process modeling environment based on standards • Interaction between integration processes
• Semantic integration with SAP kernel processes • Management of user interactions
• Management of roles and responsibilities • Event resolution mechanisms
SAP Application Core Processes are SAP business applications in the SAP Business Suite. These processes are predefined and packed and can be adjusted in the different various applications (for example SAP ERP, PLM, CRM or SRM). They are therefore spread across all business areas. These preconfigured process packages are provided by SAP as reference processes.
On the SAP NetWeaver PI 7.1 level, you can create integration processes that orchestrate message exchange between the systems in your landscape (SAP and non-SAP systems). Messages that belong to a process instance are identified using correlations based on the message content.
You can connect cross-system and cross-application processes to the application processes of the individual systems. Integration scenarios and processes which are used for communication between business partners in industry-specific instances (for example RosettaNet) can also be made available to the complete process architecture. Beyond facilitating status-based message exchange, another important task performed by ccBPM is error and exception handling.
Technical Process Integration - Challenges and
Requirements
The successful companies of the future will be those that develop business processes flexibly, map them in the IT architecture, and automate them in a cost-effective manner.
Traditionally, business process management has been divided into two distinct camps: • BPM as a management initiative directed towards standardizing and optimizing
business processes in an enterprise
• BPM as a technology and software product that supports an enterprise's IT organization in the development and use of end-to-end integration processes .
Figure 3: Process Integration: Objectives
Even in this era of new technologies, it remains difficult for IT departments to convey their technically-oriented view of data, system and interfaces for the integration of heterogeneous system landscapes to top management and departments.
Management and the departments define “what” needs to be done, while IT experts know “how” to realize the strategy and “with what” tools and systems.
As the concepts, tools and procedures on these two levels often diverge, protracted consultations are often necessary.
ccBPM is SAP's technical solution for process management in the SAP NetWeaver. It provides the infrastructure for automating business processes spanning different applications (A2A scenarios) and company borders (B2B scenarios).
Challenges in the Use of ccBPM
In an ideal world, process integration provides a clean separation between the definition of the process in the process model, the execution of the process in the Business Process Engine, basic communication, routing and mapping being handled by the Integration Broker and adapters, and the implementation of the individual functions in the applications. This separation would allow application functions to be reused and rearranged in many different processes.
In a real-life situation, however, things look a bit different. Applications typically have an internal process/state model, which is usually implicit and depends on application configuration. Take the following example: Example: In SAP Supplier Relationship Management (SRM), it is possible to create a purchase order (PO), send it out to a supplier and change the PO before having received a response from the supplier. If an SRM customer would like to do business transactions with its suppliers based on the industry standard protocol RosettaNet, the customer is faced with the problem that RosettaNet is based on a request/response pattern, that is, a PO request to the supplier must to be answered by a PO response from the supplier before subsequent processes, such as PO changes, can be initiated. In such cases, process integration must match the different process models to allow process automation. Applications, therefore, first need to become more flexible and make their internal process/state models explicit in order to move closer to an ideal world.
Another problematic topic is how automated processes and user-driven processes (workflows) interact. There will always be situations where automated processes are not sufficient. Such situations occur, for example, when handling exceptions.
An integration strategy that embraces an event-driven approach can deliver consistent information across the enterprise far more rapidly. Often, event-driven integration is the only way to ensure consistency, since many events only have meaning if captured at the precise moment they occur.
A technical BPM solution faces the following challenges:
• Lack of transparency of integration processes due to a lack of a common platform for business and IT
• Fragmentation of integration processes due to individual solutions in the departments
Tasks in ccBPM
A procedural model for an integrated BPM approach needs to align the business department with the IT experts. In an “as-is” analysis, a process expert describes the company process map, defining also the business strategy on this level. From value chain diagrams to organizational data and functional allocations, the process descriptions finally lead to a level where business scenarios, processes, and process steps can be clearly separated.
The IT department usually takes care of the integration tasks in heterogeneous system landscapes. Their goal is to integrate and automate system communication and process execution within and across systems. Aligning business with IT is one of the challenges that cross-organizational projects have to face.
Cross-Component Business Process Management in
SAP NetWeaver
Cross-component Business Process Management (ccBPM) in SAP NetWeaver allows companies to continuously adapt their integration scenarios and processes to new business strategies and meet the demands of today’s business environment. It allows IT organizations to react quickly to new requirements and, at the same time, optimize the system landscape without impacting the overall business processes.
ccBPM enables flexible, model-driven design, implementation and execution of integration processes within and across different business applications. ccBPM allows companies to model processes with different users performing different roles and tasks, optimizing the communication between the process owner and IT expert. Process models designed on different abstraction levels of modeling (business level modeling, configuration, and execution modeling) are used to configure processes running inside business applications and across applications and enterprise boundaries. A model-driven design enables the deployment of process logic on engines for process execution or in workflow management systems. This is based on a standard format such as the Business Process Execution Language for Web Services (BPEL4WS). Technical process monitoring leverages the deployed process model and running process instances of the abstracted model at runtime to monitor interfaces, transactions, throughput of messages, and technical process performance in conjunction with standard services provided by technical alert monitors.
Lesson Summary
You should now be able to:• Explain the implementation of business process management in the SAP NetWeaver environment
Lesson: BPM Standards
Lesson Overview
This lesson will provide you with essential information about BPM standards and their use within ccBPM.
Lesson Objectives
After completing this lesson, you will be able to: • Explain the basic principles of BPM standards • Export a business process
• Import a business process
Business Example
Your company uses a special business process that is implemented with ccBPM in the SAP SAP NW PI 7.1 infrastructure. One of your partners would like to use the same business process. Your partner does not use SAP NW PI 7.1, but the product is compatible with WS-BPEL. Therefore, you can just export your business process in the WS-BPEL format and hand it over to your partner, who can then import the process in his or her modeling tool.
BPM Standards: Introduction
To enable the portability and interoperability of integration processes, SAP supports and implements industry standards that apply to those industries. The selection of those standards is primarily driven by customer requirements.
Business Process Execution Language (BPEL) is one of the most widely applied standards for the design and execution of system-centric business processes. WS-BPEL is a Web service-based XML language and defines the way in which a business process can be executed by the use of Web services. If this standard is used, modeling information can be easily exported into another vendor's modeling tool and vice versa.
WS-BPEL is a standard language for the formal specification of business processes and business interaction protocols. SAP has implemented this standard in version BPEL4WS1.1 since 2003. This version is still supported in SAP NW PI 7.1 ccBPM. This standard is currently being developed for version WS-BPEL 2.0. This version is offered as preliminary version in ccBPM. The deficit in both versions at present is the lack of artifacts for user communication.
Another emerging standard is BPEL4People. SAP defined the standard together with IBM to close the gap in the user communication area.
To bridge the differences between system- and user-focused process definitions, in the future SAP will also support and deliver Business Process Modeling Notation (BPMN) as a notation for process modeling. BPMN should be independent of execution-specific artifacts. This procedure leads to system-independent modeling and allows a transformation of process modeling activities to the needs of the departments.
Figure 5: BPM Standards
Hint: For more information about BPM standard, go to
https://www.sdn.sap.com/irj/sdn/docs?rid=/webcontent/uuid/b4313088-0901-0010-3d97-9566d764c212.
WS-BPEL in SAP NW PI 7.1 ccBPM
Within SAP NW PI 7.1, WS-BPEL is used as the standard modeling language of the business processes in ccBPM. Therefore, you can have a look at the WS-BPEL representation at any time in the process editor just by changing into the WS-BPEL
Display view inside the Edit area. The corresponding data type definitions are shown
inside the Output area when switching to the Web Service Definition Language (WSDL) view. BPWEL4WS can be used as the exchange format for exporting an integration process to a non-SAP system and executing it there. Conversely,
Figure 6: BPEL: SAP PI and ccBPM
Hint: Note that WS-BPEL as an exchange format is designed for exporting
and importing integration processes to and from non-SAP/ SAP systems. The WS-BPEL format is not for the import/export of integration processes between Enterprise Services Repositories. To do that, use the import function of the Enterprise Services Repository instead.
WS-BPEL Export
The Export function exports the integration process definition in the selected WS-BPEL format. Moreover, data types, message types, and operations that are 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 file contains the process definition as displayed in the WS-BPEL view. The .wsdl file contains the referenced data types, messages types, and operations. You can name the .zip file as you please. The name will also be used for the .bpel and .wsdl files.
To create a valid WS-BPEL description when exporting an integration process, you have to define the integration process from the Integration Repository and specify the
partner link type and partner link. A partner link type describes the relationship
between two services and the role from each service. A BuyerSellerLink partner link 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 can have the same partner link type. For example,
a particular procurement process can work with multiple providers, and yet use the same partner link type for all providers. A partner link type is referenced on the abstract interface.
Take into account that messages and, respectively, abstract interfaces can be used in different ways since they are inbound and outbound interfaces in one. For example, in one step an interface can be used as a receiver, and in another step it acts as a sender. In such a case you should ensure that you enter a meaningful name for the partner link to avoid confusion when you later import your process. This information must be maintained manually since the relationship between the two services and their respective roles are configured in the Integration Directory. The information is therefore not part of the integration process and cannot be exported automatically.
WS-BPEL Import
The WS-BPEL Import imports the WS-BPEL definition of an integration process. The import expects a .zip file, containing a .bpel and a .wsdl file of the same name. If an import is started in an existing integration process, this process will be overwritten. Furthermore, the import expects that the data types, message types, and operations (message interfaces) that are referenced in the process definition are already available in the relevant namespace. This is caused by the fact that the information from the .wsdl file does not import the data types and so on, but is just used to support the import procedure. Example: The process definition to be imported has a reference to the message OrderRequest in the namespace http://sap.com/WS-BPEL . This definition is now imported into the software component version BPEL_SWC. The import then expects that the mentioned namespace is available in the Software Component (SWC) and that it contains the message OrderRequest.
Figure 7: WS-BPEL : Import Wizard
In ccBPM, message-based container elements are used in the properties of certain steps and in correlations. These container elements correspond to variables within WS-BPEL. A container element references a message interface, which references a message type. In spite of this, a BPEL variable references a message type directly. Because of this, the message interface specification is missing when a BPEL variable is imported. Therefore, it is advisable that you create the required message interfaces in the Integration Repository before starting the import. During the 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 process definition will still be imported, but the values between the various properties will be empty and you will have to fill them later. Otherwise you will not be able to activate the process.
Lesson Summary
You should now be able to:• Explain the basic principles of BPM standards • Export a business process
• Import a business process
Related Information
For more information about restrictions to the WS-BPEL import and export functions see SAP Note 709650.
Lesson: ccBPM as Part of SAP NetWeaver Process
Integration Infrastructure
Lesson Overview
The SAP NW Process Integration Infrastructure (SAP PI) enables systems to communicate and exchange data with each other by means of XML messages. The messages are processed statelessly on the Integration Server. In SAP NetWeaver, this communication is represented by the Integration Broker in the process integration section.
The following lesson introduces cross-component Business Process Management (ccBPM), which enables you to create process definitions that include multiple systems in your system landscape (both SAP and non-SAP systems) and which can exchange data between the systems. The data is exchanged by means of XML messages in SAP PI; however, it is processed statefully with ccBPM. You can define the following types of processes:
System and cross-application integration processes (scenario variant service
orchestrating)
Monitoring processes that can monitor events from different applications
Lesson Objectives
After completing this lesson, you will be able to: • Describe the main features of ccBPM
• Describe the integration scenario used in BIT430
Business Example
You want to automate a cross-component end-to-end (E2E) business process in your company. Since SAP NW PI is implemented as the integration platform in your IT system landscape, you want to acquaint yourself with the principles behind ccBPM in this environment.
Business Process Management with ccBPM
ccBPM is available in SAP XI 3.0 and higher and is used to model, execute, and monitor integration processes that extend beyond system and application boundaries. Integration processes are part of message-based process integration in SAP NetWeaver.
The following lists the main functions of ccBPM:
• ccBPM enables you to design, execute, and monitor processes across different applications.
• ccBPM is an integral part of the SAP NW PI infrastructure. • ccBPM contains a graphical process editor.
• ccBPM contains a Business Process Engine. • ccBPM adheres to open modeling standards.
– BPEL4WS 1.1 (Business Process Execution Language for Web Services) – WS-BPEL 2.0
• ccBPM supports industry standards.
– RosettaNet (RNIF adapter, PIP, and so on)
To define integration processes, you need to have some knowledge of message-based process integration and the Enterprise Services Builder.
By creating an Integration Process in the Enterprise Service Repository, you define your business process. An Integration Process is an executable cross-component process, determining the processing of messages at runtime. You define this process in a sequence of steps in a graphical editor. The process editor provides several step types for this purpose. The step types can be divides into two sections: Step types for processing messages, like the receiving or sending step, and step types to manage the process logic. This may be the loop or switch step.
Figure 8: ccBPM Architecture – Object Relationships
Unlike simple message processing where an inbound message is processed by means of a receiver determination, mapped to the target format if necessary, and sent to the target system, in ccBPM the message is processed statefully. The status of an integration process is persisted on the Integration Server and new inbound messages can be assigned to a running process instance by means of correlations.
ccBPM is integrated in all components of SAP PI:
you define both integration processes and integration scenarios at design time in the Enterprise Service Repository. You configure the runtime parameters in the Integration Directory. On the Integration Server, the Business Process Engine processes the BPM messages.
ccBPM Architecture: Overview
The ccBPM architecture consists of two parts. The design time (Enterprise Services Builder) and the runtime (Integration Server). The design is done in the ES Builder. First, you define your integration process in the Enterprise Service Repository. This is followed by the configuration of the process in the Integration Directory. Afterward, all the information is sent to runtime in the Integration Server. Within the Integration Server, the Integration Engine is responsible for the routing, mapping, and
handling and process execution. Therefore, the BPE ensures that different messages are correlated in the right way and that messages belonging together are executed in the same process.
Figure 9: ccBPM – Integration in SAP Exchange Infrastructure
The figure above shows this architecture and the interaction between the Business Process Engine and the Integration Engine at runtime in order to send and receive messages.
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 interface determination refers to an operation mapping, it is carried out.
2. After the output processing, the message is forwarded to the Business Process Engine. First the message is checked to see if it correlates with any other message and whether an instance is waiting for this message. However, the message can also start a new process instance.
3. If the Business Process Engine gets to a sending step, the current message is sent to the Integration Engine, running through the same steps as before.
The relationship among different objects within SAP PI regarding ccBPM is shown in the preceding figure. Within the Enterprise Service Repository, the integration scenario is represented by swim lanes. The integration process within this scenario refers to the business process in the software component version (SWCV).
The integration process uses abstract interfaces, context objects, and operation mappings. Abstract interfaces refer again to message types, IDocs, or Remote Function Calls (RFCs). Operation mapping refers to message mappings. Integration processes are located in the Integration Directory under the Service Without Party node. This is the active version of an integration process from the Enterprise Service Repository. The process also appears in the lower area, Cache and Runtime, as a workflow template. The system generates this workflow process using the process definition from the Integration Directory the first time the object is activated in the Integration Directory. During runtime, the process refers to XML objects and correlations.
Correlation Between Messages
The following figure shows an example: The Integration Server is waiting for messages from business systems 1, 2, and 3. Once the Integration Server has received all expected messages, it sends a combined message to business system 4.
Figure 10: Correlation Between Messages
An important feature in the integration process is the correlation you can use to define the relationship between messages. If messages do not belong to the process, it must be ensured that they do not disturb the process. For that reason, a correlation is defined, combining only messages that belong to each other. For example, an order can be correlated with its invoice via the corresponding order number.
Configuration is done in the Integration Directory, as usual. You just have to define 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 the Business Process Engine are provided within the general monitoring.
Example of an Integration Process: Sales Order
Processing
Car dealers could use a non-SAP CRM system to order spare parts. The following slide shows an overview of a system landscape for the procurement of spare parts.
Figure 12: CRM System, Simulated by HTTP Client
Since the non-SAP CRM system sends the spare part items in individual messages, the process starts with a collect pattern. In our integration process, three order items are merged into a single message that is sent to the SD system to check the availability of the materials. This takes place using a synchronous call, which returns a list of missing materials.
If the materials are not in the SD system and need to be created, the list runs though the missing materials. Each material is sent to the consumers (MM and SD system) and the materials are created in the systems.
In the next section, we will generate a sales order in the SD system and a purchase order in the MM system. If it is not possible to create both objects successfully, then neither is generated.
In this class, the different systems are represented by different clients and different business systems of the same training system:
• CRM system/catalog is an HTTP client (business system DMSCRM) • Client 800: Integration Server with integration process
• Client 812: SD system (business system Airline_Group_One) • Client 813: MM system (Business System Airline_Group_Two)
• Client 811: Supplier system (Business System Travel_Agency_Summer)
The Integration Scenario process is defined as follows:
1. The CRM system sends data item-by-item in a given format to the Integration Server.
The receiver of the message is an integration process.
2. The integration process sends a synchronous message to the SD system to check whether the materials exist.
3. If the CRM system requests a new material, this is created in the SD and MM system.
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.
We want to concentrate on the modeling of the process. Therefore, we use simple message types and there is no mapping between process interfaces and the interfaces used by the business systems.
In fact, we simulate the business objects (for example, create material, create order) using ABAP proxies in the business systems.
The Integration Directory is preconfigured. You use a wizard to apply the integration process.
Implementation and Configuration of the Integration
Process in the Integration Builder
Integration processes add status-based processing of messages to message-based process integration: The status of an integration process is made persistent on the Integration Server. This means that an integration process can, for example, wait infinitely until further messages are received or until a particular deadline is reached. Furthermore, messages can be further processed inside an integration process, that is, the messages can be collected and then sent in a particular order.
The integration process of ccBPM retrieves messages from a business system and sends messages to a business system.
• Design time
To aid in the definition of an integration process during the design time, Enterprise Services Builder provides a graphical process editor in the repository. Integration processes are objects in the Enterprise Services Repository and are integrated with other objects, such as service interfaces.
Such objects may include interfaces (service interfaces) from systems or processes.
Once you have defined the necessary objects in the Enterprise Services Repository, you can define your integration process using the process editor. After having finished the integration process, it is useful to define an integration scenario with the relevant business systems and the integration process.
• Configuration Time
You adjust the PI scenarios and integration processes in the Integration Directory to your system landscape. At configuration time, you configure (for example for the integration process):
– Receiver determination – Sender and receiver agreement – Interface determination
You can define these objects manually or you can use an SAP PI tool, the Integration Scenario Configuration.
To use this tool, you must create a configuration scenario in the Integration Directory by grouping together all configuration objects that result from the configuration or that are reused from elsewhere.
• Runtime
The Business Process Engine (BPE) then executes the integration process at runtime. The Business Process Engine is part of the Integration Server. You can monitor the execution of integration processes by using the monitoring functions of the Integration Engine.
Exercise 1: Answer the Following Questions
About ccBPM
Exercise Objectives
After 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 Example
You are part of a ccBPM project team and you need to be able to answer the questions of new team members.
Task:
Answer the following questions:
1. What is the purpose of ccBPM?
2. What standards can you use to exchange integration process definitions? ccBPM?
3. Which object do you use for a cross-system business process?
4. Where do you configure the process?
5. Into approximately how many parts can the ccBPM architecture be divided? Which individual components within this division can you name?
6. Familiarize yourself with the course exercise scenario.
Which adapter does the Integration Server use to receive the message for ordering spare parts? The business system is called DMSCRM.
The receiver determination for the first message in the process is defined in the Integration Directory using the entry DMSCRM | item_out. More than one group will be taking part in the scenario in the course. Each group has its own process: SellspareParts_0##. How are the groups distinguished from each other?
8. Familiarize yourself with the course exercise scenario.
Which inbound and outbound interfaces does the process use for spare part procurement? To answer this question, use the process Solution_5.
9. Familiarize yourself with the course exercise scenario.
Which message type and data type does the service interface item_out use? What does the message content describe?
10. Familiarize yourself with the course exercise scenario.
Which second message type does the software component SellSpareParts contain in relation to the spare part procurement scenario? How does this differ to the data type from the last question?
11. Familiarize yourself with the course exercise scenario.
Solution 1: Answer the Following Questions
About ccBPM
Task:
Answer the following questions: 1. What is the purpose of ccBPM?
Answer: The purpose of ccBPM is to design, execute, and monitor automated
processes across different applications, systems, and company boundaries. 2. What standards can you use to exchange integration process definitions?
ccBPM?
Answer: The export/import of process definitions can be done in the standards
BPEL4WS 1.1 and WS-BPEL 2.0.
3. Which object do you use for a cross-system business process?
Answer: You create an integration process in the Enterprise Service Repository.
4. Where do you configure the process?
Answer: You make configuration settings in the Integration Directory.
5. Into approximately how many parts can the ccBPM architecture be divided? Which individual components within this division can you name?
Answer: The ccBPM architecture consists of two parts. The design time
(Enterprise Service Builder) and the runtime (Integration Server). 6. Familiarize yourself with the course exercise scenario.
Which adapter does the Integration Server use to receive the message for ordering spare parts? The business system is called DMSCRM.
Answer: No communication channel is defined under the business system in the
Integration Directory. The message is sent from the HTTP client directly to the adapter_plain service on the Integration Server, using the sender HTTP adapter.
7. Familiarize yourself with the course exercise scenario.
The receiver determination for the first message in the process is defined in the Integration Directory using the entry DMSCRM | item_out. More than one group will be taking part in the scenario in the course. Each group has its own process: SellspareParts_0##. How are the groups distinguished from each other?
Answer: The message contains a process definition field. This field is connected
to the ProcessID context object in the definition of the message interface. In the receiver determination, ProcessID stands for the receiver service.
8. Familiarize yourself with the course exercise scenario.
Which inbound and outbound interfaces does the process use for spare part procurement? To answer this question, use the process Solution_5.
Answer: Receiver interfaces: item_abstract, crea_po_abstract, crea_so_abstract
Sender interfaces: prep_sync_abstract, list_abstract, item_abstract, crea_po_abstract, crea_so_abstract
9. Familiarize yourself with the course exercise scenario.
Which message type and data type does the service interface item_out use? What does the message content describe?
Answer: The message type is called SparePartLineItem. The data type is called
SparePartLineItem.
A single spare part is described in the message. 10. Familiarize yourself with the course exercise scenario.
Which second message type does the software component SellSpareParts contain in relation to the spare part procurement scenario? How does this differ to the data type from the last question?
Answer: The second message type is called SparePartLineItemList. It describes
a message with header data and a substructure containing the individual spare part. This substructure comprises the fields from SparePartLineItem and can occur more than once (0-unbounded).
11. Familiarize yourself with the course exercise scenario.
Lesson Summary
You should now be able to:• Describe the main features of ccBPM
• Describe the integration scenario used in BIT430
Related Information
• For more information about SAP NetWeaver Process Integration (SAP PI), see SAP course BIT400 and the SAP NetWeaver Process Integration 7.10. documentation.
Unit Summary
You should now be able to:• Explain the implementation of business process management in the SAP NetWeaver environment
• Understand the objectives and tasks of technical process integration with ccBPM • Explain the basic principles of BPM standards
• Export a business process • Import a business process
• Describe the main features of ccBPM
Unit 2
Business Process Management:
Cross-Component BPM
Unit Overview
This unit introduces the process editor, the design elements and the basics of developing integration processes with ccBPM.
At the conclusion of this unit, you will be able to • Work with the graphical process editor
• Describe and implement the different step types • Define and use correlation
• Define and use container elements in their context
• Describe common design patterns for integration processes
• Use the process patterns shipped by SAP in your integration processes • Make targeted use of step groups
Unit Objectives
After completing this unit, you will 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 • Explain the concept of exception handling in ccBPM
• Define exceptions in integration processes
• Describe common design patterns for integration processes
• Use the process patterns shipped by SAP in your integration processes • Define step groups
• Use configurable parameters to improve the flexibility of your processes • Explain step type receiver determination
• Explain and use step type fork • Describe step type switch • Illustrate step type user decision
• Use the modes ParForEach and ForEach in a block step • Integrate user decisions into the process flow
Unit Contents
Lesson: First Steps in ccBPM . . . .. . . .. . . .. . . .. . . .. . . 37 Exercise 2: Receiving Order Items (Introduction) . . . .. . . .. . . 51 Lesson: Step Types (Part 1) and Correlation . . . .. . . .. . . .. . . 58
Exercise 3: Receiving Order Items (Collecting Items and Saving them in Containers) . . . .. . . .. . . .. . . .. . . .. . . .. . . 67 Lesson: Step Types (Part 2) and Exception Handling . . . .. . . .. . . 76 Exercise 4: Checking Materials in the SD System . . . .. . . .. . . 89 Lesson: Process Templates and Step Groups . . . .. . . .. . . .. . . 104 Exercise 5: Creating a Step Group. . . . .. . . .. . . .. . . .. . . 115 Exercise 6: Test Your Knowledge . . . .. . . .. . . .. . . .. . . 119 Lesson: Step Types (Part 3) . . . . .. . . .. . . .. . . .. . . .. . . 122 Exercise 7: Creating Missing Materials in the MM and SD Systems . . . 135
Lesson: First Steps in ccBPM
Lesson Overview
This lesson will provide you with a general overview of the graphical process editor and show you how to work with the tool.
Lesson Objectives
After completing this lesson, you will be able to: • Describe the graphical process editor • Work with the graphical process editor
Business Example
Your company asks you to set up an integration process using SAP NetWeaver PI. In order to do this, you use the graphical process editor to design the process.
Graphical Process Editor Areas
The process editor is a graphical editor in the Integration Builder that enables you to define and edit integration processes in the Enterprise Service Repository.
The editor is divided into individual sections: The sections are:
Main Menu
Shows the main menu and the standard application toolbar of the Enterprise Services Builder.
Header Area
The Header area shows all the important header data, such as name, namespace, software component version, and a short description.
Edit Area
In the Edit area, the whole integration process is composed of several step types. You can switch between the following views:
• Graphical Definition
Define and design the integration process. The process flow can be displayed horizontally or vertically.
• BPEL display
Displays the process as WS-BPEL- or BPWL4WS. Also offers the possibility to import or export the integration process in this representation.
• Correlation Editor
Define and edit correlations.
Overview Area
The Overview area shows alternative representations of the integration process. The following views are possible:
• Process Overview
Gives a bird’s-eye view of the whole process. With the help of the orange rectangle, you can select special sections of the process. The size of the rectangle (zooming factor) is controlled by the scroll bar at the top of the overview area. • Process Outline
Properties Area
The Properties area defines the properties of the currently selected step. The properties that can be defined depend on the step type. Properties shown in bold italics can hold more than one value line. For example, for the Exceptions property, you can define multiple exceptions. Properties in bold that have a maximize or minimize icon can show or hide their other entries. Mandatory properties are marked with a question mark (?).
Output Area
The output area displays messages (errors, warnings, and so on) and the output of functions. Switching is possible among the following views:
• Processing Log
Messages thrown by designing the process are shown. • Tasks
Shows the result of the integration process check (F7). • Search Results
Results of the step search are shown. • WSDL Display
The Web Services Description Language (WSDL) description of data types, message types, and so on is shown (this view is only available if the BPEL view is active in the Edit area).
Object Area
In this area the following views are possible: • Container
Definition and editing of container elements. • Correlation List
Used to create correlations. • Process Signature
References the interfaces of the process. • Configurable Parameters
Used to define parameters that you can then configure in the Integration Directory. You use parameters like these, for example, to specify the agent for a user decision.
Personalization of the Process Editor
You can personalize the process editor according to your requirements. Your personal settings become the default settings when the process editor is started. For example, you can show or hide particular screen areas or display the process definition vertically.
Figure 15: Process Editor: Personal Settings
To enlarge the visible part of the process definition, choose Detach and maximize the window.
To enlarge the properties area of the screen, choose Tools - Personal Settings. On the subsequent screen choose Process Editor, Hide Output Area.
To enlarge the object area (container elements) part of the screen, choose Tools
-Personal Settings. On the subsequent screen choose Process Editor, Hide Output Area.
Available Step Types and the Block Oriented Modeling
Paradigm
As mentioned earlier, step types can be divided into two sections: message-relevant steps and control-relevant steps.
Message-relevant steps are:
• Receive
Receive message; can trigger the process • Send
Send message synchronous or asynchronous/send acknowledgement • Transformation
Split, merge, or convert messages • Receiver determination
The following are the control-relevant steps:
• Block
Combines steps that you want to have the same deadline or exception handler, or defines a local correlation.
• Switch
Defines processing branches based on conditions. • Container Operation
Assigns values to elements / appends values to multiline elements. • Control
Terminates process / triggers exceptions /triggers alerts. • Fork
Defines independent processing branches. • Loop
Repeat steps while a condition is TRUE. • User Decision
At runtime, the user can decide in which processing branch an integration process is continued.
• Wait
Incorporate delay; usually used to set start time for next step. • Undefined
No function; can be used as place holder or for test purposes. Your integration process is composed with the help of these step types.
The use of these steps will be explained later in more detail, but first we will provide some basic design principles to make it easier to use the design elements in the right way and to create well-formed and faultless integration processes.
A block-oriented modeling paradigm is used within the tool for process modeling. This paradigm relates to well-known structured programming concepts. It basically means that blocks are used to group several steps and to structure the integration process. A block can be defined in sequence or nested within another block. However, a block cannot extend beyond any existing block boundaries; therefore, the outermost block of a process is the process itself.
Figure 16: Block-Oriented Design in ccBPM
The block structure helps to design the process in a concise and comprehensible way. It also helps to avoid particular structural modeling errors, for example deadlocks, and permits hierarchical abstraction. Block hierarchy is the basis for the visibility and validity of container elements (data) used within a process.
Defining Configurable Parameters
A configurable parameter is a parameter whose value you define in the integration directory in the integration process component. This enables you to change the value without having to change the definition of the process. You can create several configurations for a process, by specifying different values for a configurable parameter.
You define configurable parameters in a way similar to container elements. For configurable parameters, you can define a default value as well.
Defining Conditions
You can define conditions at various points in the process editor in order to control the processing depending on the event of the condition. At the corresponding points, for example, in the definition of a multiple condition, the system automatically displays the condition editor. To make conditions easy to understand and follow you can insert comments. Furthermore, you can show a where-used list for certain expressions.
Exception Handling
In an integration process, situations can occur in which the integration process cannot be continued normally (for example, when system errors occur) or normal continuation is not desirable. You can take into account situations like these already in the definition of the process in the form of exceptions and the corresponding exception handlers.
Process Data and Container Management
Since an integration process not only forwards messages but processes them as well, data needs to be saved. In this respect containers play a decisive role. Containers • Define the data for a business process and enable data to be transferred between
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 increase counters. To do all this, several step types are used. So that the step types can process different data correctly, they need a description of the data; therefore, you define the data as container elements. Compared to a programming language, container elements are like variables. They are defined at design time and at runtime 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 to declare the category as abstract interface and the type will refer to the respective abstract interface. An abstract interface is defined within the service interfaces. It is only used in integration processes, and the difference between an inbound or outbound message interface is that it is bi-directional. This means that it can be used as an outbound or inbound interface , depending on the situation within the integration process.
Hint: An integration process can only reference interfaces of the own
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 represents a simple type of XSD:integer.
The third possible category is the receiver. This is used for a receiver list, which is determined from a receiver determination step and can be used in a send step. A container element can also be a list of container elements of the same type. In this case, you must set the multiline flag for the container element. An example of such a list would be when you collect multiple messages and want to combine them into one message.
Figure 17: Containers and Their Elements
The container elements can be assigned to certain blocks or to the whole process. In the container area, you define whether the elements belong to a block or a process. If you set the container on process, the container is valid and visible in the whole process and it can be used in each block.
Figure 18: Visibility of Container Elements
If you set the container to a specific block, it would be only visible in this block or in any nested block within the specified block. A container element of an inner block would not be visible in the outer block. As soon as the container elements are defined, they can be used from the different step types.
Defining Step Groups
You can summarize frequently used sequences of steps to a step group.
The grouping of steps to a step group enables you to recognize step groups again and improves the clarity of the process design.
Correlation of Messages
If the process contains further receive steps or the first receive step is part of a loop, you must correlate these messages with the message from the first receive step. To do so, specify the correlations you want to activate. For each correlation, you must specify how you want the elements of the correlation container to be filled when the correlation is activated. You can use the whole process container for this purpose. If you specify multiple correlations, then the message to be received must satisfy all correlations.
During an integration process, it is often the case that messages with a context are processed. An example may be a booking and a booking confirmation. The connection between these messages is described by a correlation.
To clarify the need for a correlation, think of the following:
• A flight booking for a flight to Rome gets in the airline system and starts the booking process. During this, the Business Process Engine creates an instance, holding the state of the process on the Integration Server. After sending the flight booking request to Rome, the instance waits for a booking confirmation.
• Now a second flight booking is made, this time for a flight to Sydney. The Business Process Engines starts the same process again and again waits for a confirmation.
• The confirmation for the Rome flight comes back, but now the Business Process Engine has to know to which process instance to send this confirmation.
• Therefore a correlation is declared, so that the Business Process Engine can ensure the correct delivery of the confirmation. In this case it would make sense if the messages are correlated by their unique booking order number.
Hint: SAP recommends that correlations are based on fields that are part of
the message payload.
Recapitulation is a correlation is used to assign messages that belong together to the
same process instance. It defines how the Business Process Engine can recognize messages belonging together. It is, therefore, a loose coupling of messages. To define a correlation, you have to declare all involved messages and the XML elements in which the messages match. Activation of a correlation can be done either in a receive or send step.
Hint: Be sure that the correlation is defined unambiguously. If, for instance,
a material number is used in more than one plant, the correlation has to be defined using material number and the plant.
A correlation can be valid in the entire process and can be activated and used in the entire process.
Hint: However, correlations are usually only valid for a specified period of
time, for example, while messages are being collected. You can define a correlation such as this as a local correlation; this is, is it assigned to a block in the process. You will then only be able to activate and use the correlation in this assigned block.
Start of an Integration Process
An integration process starts at runtime with a receiving step, referring to exactly one message. This step can be the first step in the process, or a step in a fork, block, or loop. If not starting with a receiving step, the fork, block, or loop must be the first step in the process. A fork or a loop can be used for multiple receive steps, which are possible in the following combinations:
• Receive steps arranged in series
The first receive step starts the process; afterwards, the other receive steps can receive their messages.
The receive step can be the first step of the process or the first step in the first block of the process. The prerequisite for this is that the messages are sent from the sender systems to the process in exactly the specified order.
• Receive steps in a fork
The first receive step can be part of a step in a fork.
All receive steps that are ordered in parallel can start the process. With this receive method, it is possible to start the process with different messages. • Receive step in a loop
The first receive step can be part of a loop step.
The receive step in the loop starts the process and will collect messages until the loop end condition is fulfilled.
Exercise 2: Receiving Order Items
(Introduction)
Exercise Objectives
After completing this exercise, you will be able to: • Open an integration process
• Check the initial status of an integration process
• Transfer an integration process from the Integration Repository to the Integration Directory
Business Example
You want to acquire some spare parts from a non-SAP catalog/CRM system (simulated in the exercise by an HTTP-client user interface).
You have created a business process and want to test the initial status.
To do so, you send a message from the HTTP-client user interface that is specified in the Additional Information node in the Integration Builder in your training system. Ensure that you send the message to your own process. The process ID is part of the message.
Task:
Find your business process and check the environment.
1. Log on to the Integration Server (client 800) for your training system, call the Enterprises Services Builder, and start the Enterprises Services Repository. Your user is BIT430-## (where ## is your group number).
The course instructor will provide you with the training system details.
2. Navigate to your business process SellSpareParts_0## in software component
SELLSPAREPARTS and display your process in the process editor. Your group
number is ##.
3. Which container elements are defined?
Check the interface of the defined object. What does the interface look like? 4. For an overview of your objects, create configuration scenario BIT430_##.
(## stands for your group number).
Transfer your group-specific integration process to the Integration Directory. As the name, assign the name that the process has in the Integration Repository: SellSpareParts_0##. ## denotes your group number.
Insert the integration process in the configuration scenario BIT430_##. 5. Use the HTTP client to send an order item to the Integration Server and then
check whether the order was received and processed correctly by SAP XI. Ensure that your integration process is specified in the Process Definition field in the HTTP client.
To access the HTTP Client, in the Integration Builder choose Additional Info
→ Tools for BIT430.
Choose Order Spare Part Item.
Change the process definition to the name of your integration process and choose SendItem.
6. Navigate back to your session with the Integration Repository and delete the
Solution 2: Receiving Order Items
(Introduction)
Task:
Find your business process and check the environment.
1. Log on to the Integration Server (client 800) for your training system, call the Enterprises Services Builder, and start the Enterprises Services Repository. Your user is BIT430-## (where ## is your group number).
The course instructor will provide you with the training system details. a) Log on to client 800 in your training system. Your user is BIT430-##. b) Call transaction SXMB_IFR from the Process Integration folder.
c) Choose Enterprise Services Repository in the Enterprise Services Builder context.
Java Web Start will then start.
d) In the security warning dialog box choose Start.
e) Enter your user and password (BIT430-## and your changed password) and choose Log On.
2. Navigate to your business process SellSpareParts_0## in software component
SELLSPAREPARTS and display your process in the process editor. Your group
number is ##.
a) Once you are logged on to the Integration Repository, open software component SELLSPAREPARTS.
b) Open SELLSPAREPARTS and go deeper in the structure until you reach your integration process: Choose SELLSPAREPARTS
1.0 of education → SELLSPAREPARTS 1.0 of education → http://education.com/xi/BPM/Spareparts → Process Integration Scenarios→ Integration Processes → SellSpareParts_0##.
c) Display your integration process in the area on the right of the process editor by double-clicking.
The graphical definition shows a start and stop step of the process and one receive step: deleteMe.
3. Which container elements are defined?
