Enterprise Integration Patterns for SAP NetWeaver PI: SAP PRESS Essentials 35 [1 ed.] 1592291759, 9781592291755

Citation preview



Notes on Usage This e-book is protected by copyright. By purchasing this e-book, you have agreed to accept and adhere to the copyrights. You are entitled to use this e-book for personal purposes. You may print and copy it, too, but also only for personal use. Sharing an electronic or printed copy with others, however, is not permitted, neither as a whole nor in parts. Of course, making them available on the Internet or in a company network is illegal as well. For detailed and legally binding usage conditions, please refer to the section Legal Notes.

René de Daniel, Hermann Steinrötter

Enterprise Integration Patterns for SAP NetWeaver PI ®

Bonn � Boston

175 BOOK.indb 3

10/2/08 8:55:25 AM

Imprint This e-book is a publication many contributed to, specifically: Editor Mirja Werner English Edition Editor Jon Franke Translation Lemoine International, Inc., Salt Lake City UT Copyeditor Jutta VanStean Cover Design Silke Braun Photo Credit Getty Images/George F. Mobley Production E-Book Graham Geary Typesetting E-Book Publishers’ Design and Production Services, Inc. We hope that you liked this e-book. Please share your feedback with us and read the Service Pages to find out how to contact us.

ISBN 978-1-59229-175-5 © 2009 by Galileo Press Inc., Boston (MA) 1st edition 2009

Contents 1 Introduction  ............................................................................... 1.1 1.2

Contents  . .................................................................................... Acknowledgements  .....................................................................

9 10 12

2 Integration Tools  . ...................................................................... 13 2.1

Classification  . .............................................................................. 2.1.1 Managed File Transfer (MFT)  . ........................................... 2.1.2 Extract, Transform and Load (ETL)  ..................................... 2.1.3 Enterprise Information Integration (EII)  ............................. 2.1.4 Enterprise Application Integration (EAI)  ............................ 2.1.5 Business Process Management (BPM)  ................................ 2.2 Selecting a Tool  ........................................................................... 2.3 Uses of SAP NetWeaver PI  ........................................................... 2.4 The Structure of SAP NetWeaver PI  .............................................

15 16 17 17 18 19 20 22 25

3 Benefits of Using Patterns to Solve Integration Problems  ....... 29 3.1 A Standardized Approach  ............................................................ 3.2 Patterns for Assessing Complexity  ................................................

29 34

4 Modeling Concept  ..................................................................... 37 4.1 4.2 4.3 4.4

Two-Component Strategy  ............................................................ Three-Component Strategy  .......................................................... Process-Oriented Component Strategy  ........................................ Procedure at Design Time  ............................................................ 4.4.1 Defining Namespaces  ........................................................ 4.4.2 Top-Down Approach  ......................................................... 4.5 Procedure at Configuration Time  . ................................................ 4.5.1 Overview of the Configuration Scenario  . ........................... 4.5.2 Model Configurator  ...........................................................

40 41 44 47 47 48 52 53 55

5

175 BOOK.indb 5

10/2/08 8:55:25 AM

Contents

5 Enterprise Integration Patterns  . ............................................... 65 5.1

Aggregator  .................................................................................. 5.1.1 Short Description  .............................................................. 5.1.2 Related Patterns  ................................................................ 5.1.3 Problem  ............................................................................ 5.1.4 Description  ....................................................................... 5.1.5 Use Case  ........................................................................... 5.1.6 SAP NetWeaver PI-Specific Implementation  ...................... 5.1.7 Design Time  ...................................................................... 5.1.8 Configuration Time  . .......................................................... 5.1.9 Runtime  ............................................................................ 5.2 Canonical Data Model  ................................................................. 5.2.1 Short Description  .............................................................. 5.2.2 Related Patterns  ................................................................ 5.2.3 Problem  ............................................................................ 5.2.4 Description  ....................................................................... 5.2.5 Use Case  ........................................................................... 5.2.6 PI-Specific Implementation  ............................................... 5.2.7 Design Time  ...................................................................... 5.2.8 Configuration Time  . .......................................................... 5.2.9 Runtime  ............................................................................ 5.3 Content Enricher  ......................................................................... 5.3.1 Short Description  .............................................................. 5.3.2 Related Patterns  ................................................................ 5.3.3 Problem  ............................................................................ 5.3.4 Description  ....................................................................... 5.3.5 Use Case  ........................................................................... 5.3.6 SAP NetWeaver PI-Specific Implementation  ...................... 5.3.7 Design time  . ..................................................................... 5.3.8 Configuration Time  . .......................................................... 5.3.9 Runtime  ............................................................................ 5.4 Content Filter  .............................................................................. 5.4.1 Short Description  .............................................................. 5.4.2 Related Patterns  ................................................................ 5.4.3 Problem  ............................................................................ 5.4.4 Description  ....................................................................... 5.4.5 Use Case  ........................................................................... 5.4.6 SAP NetWeaver PI-Specific Implementation  ......................

66 66 66 66 67 67 67 69 71 75 76 76 76 76 76 79 79 82 84 86 87 87 87 87 87 87 88 93 96 100 101 101 101 101 101 101 102

6

175 BOOK.indb 6

10/2/08 8:55:25 AM

Contents

5.5

5.6

5.7

5.8

5.4.7 Design Time  ...................................................................... 5.4.8 Configuration Time  . .......................................................... 5.4.9 Runtime  ............................................................................ Content Based Router  . ................................................................ 5.5.1 Short Description  .............................................................. 5.5.2 Related Patterns  ................................................................ 5.5.3 Problem  ............................................................................ 5.5.4 Description  ....................................................................... 5.5.5 Use Case  ........................................................................... 5.5.6 SAP NetWeaver PI-Specific Implementation  ...................... 5.5.7 Design Time  ...................................................................... 5.5.8 Configuration Time  . .......................................................... 5.5.9 Runtime  ............................................................................ Dynamic Router  . ......................................................................... 5.6.1 Short Description  .............................................................. 5.6.2 Related Patterns  ................................................................ 5.6.3 Problem  ............................................................................ 5.6.4 Description  ....................................................................... 5.6.5 Use Case  ........................................................................... 5.6.6 SAP NetWeaver PI-Specific Implementation  ...................... 5.6.7 Design Time  ...................................................................... 5.6.8 Configuration Time  . .......................................................... 5.6.9 Runtime  ............................................................................ Guaranteed Delivery  .................................................................... 5.7.1 Short Description  .............................................................. 5.7.2 Related Patterns  ................................................................ 5.7.3 Problem  ............................................................................ 5.7.4 Description  ....................................................................... 5.7.5 Use Case  ........................................................................... 5.7.6 SAP NetWeaver PI-Specific Implementation  ...................... 5.7.7 Design Time  ...................................................................... 5.7.8 Configuration Time  . .......................................................... 5.7.9 Runtime  ............................................................................ Message Expiration  . .................................................................... 5.8.1 Short Description  .............................................................. 5.8.2 Related Patterns  ................................................................ 5.8.3 Problem  ............................................................................ 5.8.4 Description  ....................................................................... 5.8.5 Use Case  ...........................................................................

103 106 108 108 108 108 108 108 109 110 110 111 116 116 116 117 117 117 117 118 119 122 128 128 128 128 128 129 129 130 132 136 138 139 139 139 139 140 140

7

175 BOOK.indb 7

10/2/08 8:55:25 AM

Contents

5.9

5.10

5.11

5.12

5.8.6 SAP NetWeaver PI-Specific Implementation  .................... 5.8.7 Design Time  .................................................................... 5.8.8 Configuration Time  ......................................................... 5.8.9 Runtime  .......................................................................... Message Translator  ...................................................................... 5.9.1 Short Description  ............................................................ 5.9.2 Related Patterns  . ............................................................ 5.9.3 Problem  .......................................................................... 5.9.4 Description  ..................................................................... 5.9.5 Use Case  ......................................................................... 5.9.6 SAP NetWeaver PI-Specific Implementation  .................... Message Bridge  ........................................................................... 5.10.1 Short Description  ............................................................ 5.10.2 Related Patterns  . ............................................................ 5.10.3 Problem  .......................................................................... 5.10.4 Description  ..................................................................... 5.10.5 Use Case  ......................................................................... 5.10.6 SAP NetWeaver PI-Specific Implementation  .................... 5.10.7 Design Time  .................................................................... 5.10.8 Configuration Time  ......................................................... 5.10.9 Runtime  .......................................................................... Request/Reply  ............................................................................. 5.11.1 Short Description  ............................................................ 5.11.2 Related Patterns  . ............................................................ 5.11.3 Problem  .......................................................................... 5.11.4 Description  ..................................................................... 5.11.5 Use Case  ......................................................................... 5.11.6 SAP NetWeaver PI-Specific Implementation  .................... 5.11.7 Design Time  .................................................................... 5.11.8 Configuration Time  ......................................................... 5.11.9 Runtime  .......................................................................... Splitter  ........................................................................................ 5.12.1 Short Description  ............................................................ 5.12.2 Related Patterns  . ............................................................ 5.12.3 Problem  .......................................................................... 5.12.4 Description  ..................................................................... 5.12.5 Use Case  ......................................................................... 5.12.6 SAP NetWeaver PI-Specific Implementation  .................... 5.12.7 Design Time  ....................................................................

140 143 146 151 151 151 151 151 151 152 152 160 160 160 160 161 161 162 164 165 173 173 173 173 174 174 175 175 177 179 182 183 183 183 183 184 184 184 186

8

175 BOOK.indb 8

10/2/08 8:55:26 AM

Contents

5.12.8 Configuration Time  ......................................................... 189 5.12.9 Runtime  .......................................................................... 194 5.13 Summary  ..................................................................................... 195

6 Installing and Configuring Downloads  . .................................... 197 6.1 Downloading the Software  .......................................................... 6.2 Importing the SLD Objects  .......................................................... 6.2.1 Importing the CIM Content  . ........................................... 6.2.2 Defining Usage Dependency  ........................................... 6.3 Defining the SLD Objects  . ........................................................... 6.3.1 Creating Technical Systems  . ............................................ 6.3.2 Creating Business Systems  ............................................... 6.3.3 Importing the Business Systems into the Integration Directory  . ....................................................................... 6.4 Importing the ESR Objects  . ......................................................... 6.5 Deploying the Java Proxy  .............................................................

197 198 198 199 200 201 202 204 205 207

7 Conclusion  ................................................................................. 209

Appendices A Authors  . ............................................................................................... 213 B Bibliography  . ........................................................................................ 215 Index............................................................................................................ 219

9

175 BOOK.indb 9

10/2/08 8:55:26 AM

175 BOOK.indb 10

10/2/08 8:55:26 AM

1

Introduction

The concept of patterns gained popularity in 1995 thanks to the publication of the book called Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, also known as the “Gang of Four” (or GoF for short). A pattern describes a solution to a specific design problem. Like a template, the approach to solving the problem can be used again and again. The approach that constitutes a pattern is based on best-practice guidelines and has already been put to the test in an actual implementation. Each pattern has a unique name to simplify and standardize communication between developers and architects. This book introduces commonly used patterns for integrating heterogeneous services and systems in an enterprise. We will identify and explain appropriate patterns based on integration scenarios. We will then demonstrate how each pattern is implemented in practice based on SAP NetWeaver Process Integration (SAP NetWeaver PI) 7.1. The implementation methods used in this book can also be applied to earlier versions of SAP NetWeaver PI (or SAP NetWeaver XI), with the exception of some SAP NetWeaver PI 7.1-specific functions. We describe in detail the approach used in the Enterprise Services Repository (ESR) and in the Integration Directory (ID). Additional test files required for SAP NetWeaver PI version 7.1 are provided on the website dedicated to this book at www.sap-press.com. These will allow you to reproduce the scenario discussed in this book in your own system. The book is aimed at two target audiences: EE

Integration architects who are interested in patterns in general and, in particular, in how patterns can be implemented with SAP NetWeaver PI 7.1.

EE

Developers who are interested in solving integration issues in general, and who want to implement and test the solutions in their system.

Since the book authored by the GoF was published (and became established as the authoritative work on patterns), a range of other books has also become available,

11

175 BOOK.indb 11

10/2/08 8:55:26 AM

1

Introduction

providing solutions to problems encountered by software architects on a daily basis. The most famous of those dealing with solutions to integration problems in particular is Enterprise Integration Patterns, written by Gregor Hohpe und Bobby Woolf and published by Addison-Wesley in 2003. It describes some 65 patterns and discusses these in relation to the use of messaging systems, such as Java Messaging Service (JMS), Microsoft Message Queuing (MSMQ), TIBCO and .NET. The idea for the current book took shape while we were setting up an integration competence center (ICC) with a focus on Extract, Transform, Load (ETL) and Enterprise Application Integration (EAI) for a global corporation. Because collaboration in global and virtual teams and offshore development are increasingly becoming the norm, the definition of clear guidelines is essential when it comes to solving integration issues. These guidelines should allow the solution to be implemented in a consistent and professional manner. In formulating guidelines for this specific project, we pinpointed and defined the 12 most prevalent patterns, and identified the specific ways in which these could be implemented using SAP NetWeaver PI 7.1. It became apparent to us as part of the internal knowledge exchange program — and in discussions with integration architects and developers — that the subject of design patterns had sparked a great deal of interest. This inspired us to share our knowledge in this area in the form of a book.

1.1

Contents

This book describes the 12 design patterns most frequently required to integrate services, systems, and applications in an enterprise, and their tangible implementation based on SAP NetWeaver PI 7.1. In Chapter 2, Integration Tools, we discuss the various categories of information tools, namely ETL, Managed File Transfer (MFT), Enterprise Information Integration (EII), Enterprise Application Integration (EAI), and Business Process Management (BPM), and their different applications. We then classify SAP NetWeaver PI 7.1 according to these categories and discuss the structure and intended applications of the newest version (7.1) of SAP NetWeaver PI.

In Chapter 3, Benefits of Using Patterns to Solve Integration Problems, we demonstrate a standardized approach to implementing integration scenarios and define

12

175 BOOK.indb 12

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:26 AM

Contents

1.1

the various roles of the groups involved. We also discuss the degree to which design patterns can be used to evaluate the complexity of an integration scenario. The level of complexity helps integration architects decide how to proceed with risk assessment and cost estimation, as well as with quality assurance during the implementation process. Chapter 4, Modeling Concept, contains fundamental considerations and approaches with respect to modeling and organizing objects within software components. These fundamentals serve as a basis for subsequent chapters. Because object modeling and organization have not yet been covered in the literature, it is one of our specific objectives to create such a foundation. The key strategies that have proven successful in practice are a two-component strategy, three-component strategy, or process-oriented structuring of objects (the choice of strategy depends on the individual enterprise and its organizational structure). All three approaches are described and compared here. This chapter also contains important information regarding the procedures involved in the design time and configuration time of the patterns described in Chapter 5, and the naming conventions used. Chapter 5, Enterprise Integration Patterns, describes the 12 most prevalent patterns and builds on the foundations established in Chapter 4. Each pattern is described in detail, and a concrete integration problem and its solution is provided by way of illustration. In this chapter, we pay particular attention to the implementation of patterns in the ESR, and on configurability in the ID. Our focus shifts slightly with each design pattern, to be able to fully demonstrate the actual implementation options with SAP NetWeaver PI 7.1.

All software components discussed in this book are available for download. Refer to Chapter 6 for more information about installing and configuring downloads. You will find everything you need to know to configure individual patters in your SAP NetWeaver PI 7.1 system in the section called “Configuration Time.” The necessary test files are also available on the book’s website at www.sap-press.com. This will minimize the time it will take to simulate the patterns. Each pattern is independent of the others and does not build on previous patterns. In other words, you are not required to work through the patterns in any particular sequence. In fact, the fundamental considerations and approaches described in Chapters 3 and 4 should equip you with sufficient knowledge to identify actual problems and their design patterns, and implement them in your system.

13

175 BOOK.indb 13

10/2/08 8:55:26 AM

1

Introduction

1.2

Acknowledgements

We would like to thank Karoline Kastner, Priya Thyagaraj, Chris Curtis, Ken B. Dunn, James L. Ginsburgh, Holger Himmelmann, Johannes Hurnik, Irfan Iltaf, Uwe Knöfel, Daniel Möllenbeck, Virgil Perenzee, Richard Pittard, Andreas Schmidtsberger, Alan Seddon, Andrew Shaw, Andreas Skubski, Dan Smith, Krishna Rao Tamminani, Thomas Vögel, Andy J. Walker, and Joseph Wright, whose many indepth discussions with us contributed to the successful completion of this book. We would also like to thank Mirja Werner, Florian Zimniak, Jon Franke, and Jutta VanStean at Galileo Press, who supported and encouraged us in the creation of this book with the utmost professionalism. A final word of thanks must go to our families, who supported us at every step of the creation process. So, thank you Carmen, Susanne, Philipp, and Tim. René de Daniel Hermann Steinrötter

14

175 BOOK.indb 14

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:26 AM

2

Integration Tools

With respect to integrating IT systems, we can distinguish between two primary integration scenarios: internal (application-to-application [A2A]) and external (business-to-business [B2B]). In internal scenarios, the systems to be integrated share the same fundamental infrastructure and are controlled by the enterprise. This type of integration has no technical restrictions. This category of scenario includes LAN, WAN, VAN, and even Internet communication depending on the infrastructure setup of the enterprise. External integration scenarios, on the other hand, are characterized by communication with third-party systems whose technical communication requirements frequently differ from those of the internal systems. As a result of the necessary coordination between partners, external integration scenarios tend to be much more complex than internal integration scenarios. This chapter describes the various categories of integration tools and their properties, and presents the selection criteria to be applied where both functional and non-functional business process requirements must be fulfilled. It then classifies SAP NetWeaver PI 7.1 according to the categories described, and explains the basic structure of SAP’s integration tool SAP NetWeaver PI 7.1 Many companies face three fundamental problems with respect to the integration of IT systems. These affect both internal and external scenarios and are explained in the following list: EE

Heterogeneous and complex IT systems EE

Often, a multitude of applications from different manufacturers exist along the value chain. These tend to be operated at various data centers with different service level agreements (SLAs) and diverse operational standards and procedures.

EE

IT systems are integrated at the level of specific projects and problems, without taking the processes involved or the underlying data structures into account.

15

175 BOOK.indb 15

10/2/08 8:55:26 AM

2

Integration Tools

EE

EE

Lack of flexibility and agility EE

The implemented systems are primarily conventional batch interfaces. This results in a lack of real time integration and does not meet the increasing — and today more challenging — requirements of business departments.

EE

Development cycles are costly and time-consuming.

EE

Source code is copied and reused only to a limited extent. No ongoing processes of development and improvement are in place.

EE

Inadequate use is made of internal and external services.

High cost of operation and adjustment EE

A multitude of point-to-point interfaces — implemented with a range of technologies that are never or hardly ever reused — results in IT landscapes that are nothing short of a tangled mess.

EE

Documentation is inadequate or obsolete.

EE

Adjustments necessitate high upgrade and testing costs.

EE

Specialized support personnel are needed for different technologies.

EE

Opportunities for end-to-end monitoring, logging, and auditing are limited.

The underlying reasons for the challenges encountered in integration scenarios are many, and vary from one enterprise to the next. However, the following causes can be isolated in many cases: mergers and acquisitions completed under time pressure, fast-paced global expansion, short-term cost pressures, varying or lacking IT strategies in different areas of the enterprise, project-specific implementations, no enterprise-internal standards, and no across-the-board governance over implementations. For years, manufacturers of integration tools have been promising to solve the integration dilemma of high maintenance costs, low flexibility, and a crawling speed of adjustment. Many different types of integration tools are now on offer.

2.1

Classification

In the software industry, we currently distinguish between five basic categories of integration tools:

16

175 BOOK.indb 16

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:26 AM

Classification

EE

Managed File Transfer (MFT)

EE

Extract, Transform, and Load (ETL)

EE

Enterprise Information Integration (EII)

EE

Enterprise Application Integration (EAI)

EE

Business Process Management (BPM)

2.1

All five categories are commonly known as middleware. Middleware refers to application-neutral systems that act as brokers between various applications so that the individual properties and complexities of these applications — and the corresponding infrastructure — remain transparent. Each category has a different primary use and is characterized by specific properties: EE

MFT Providers of MFT tools focus on simple file transfer and integration, predominantly in batch mode. MFT tools offer various file transfer protocols and simple routing, without complex transformations or mapping of data formats. Filebased B2B scenarios are supported by encrypted transfer protocols and certificate based authentication

EE

ETL Providers of ETL tools originally specialized in the extraction, transformation, and loading of large datasets in data warehouses. Although many manufacturers have since added real time properties to their tools, most products are still batch, mass- and volume-based, rather than transaction-oriented.

EE

EII The primarily focus of EII tools is online reporting. It’s a relatively new category of products that enable simultaneous real time access to various systems, without data replication. Virtual objects in sophisticated data models enable the simultaneous creation, modification, and deletion of data in various systems.

EE

EAI Providers of EAI tools focus on individual transactions and integration at the level of business processes. EAI tools comprise transfer protocols, intelligent routing, transformation and adaptors, programming interfaces (APIs), and, in many cases, B2B capabilities.

17

175 BOOK.indb 17

10/2/08 8:55:26 AM

2

Integration Tools

EE

BPM The defining characteristic of BPM tools is the integration and orchestration of a wide range of services for new business processes. These tools focus in particular on processes that require interactive communication across system boundaries (i.e. human workflows).

We will examine these categories in more detail in the following sections.

2.1.1

Managed File Transfer (MFT)

MFT tools provide enterprises with support for control and all other aspects of data transfer per file. Often, though not always, their use is limited to the periodic transfer of large quantities of data between two or more systems (batch operations). MFT tools have the following properties: EE

Secure communication, and assured delivery This generally comprises standard protocols for transporting files, such as sFTP, FTPs, FTP, or any encrypted transfer. These protocols ensure the authentication, authorization, and secure transfer of files between two or more systems and provide assured delivery.

EE

Administration, alerting, and management capabilities This property refers to the monitoring, alerting, and control of file transfers (regardless of file size) during and after the transfer. For example, control points can be defined and file transfers repeated. File patterns can be used for the retrieval and delivery of files.

EE

Auditing and logging The systems log all transfers, including the transfer details such as timestamps, transfer time, user privileges, etc., and provide auditing functionality.

EE

Integration properties These tools have adaptors or Application Programming Interfaces (APIs).

EE

Compression Compression allows file transfers to be optimized, and overcomes physical or operation system-specific limitations.

18

175 BOOK.indb 18

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:26 AM

Classification

2.1

Examples of manufacturers of tools that fall into the MFT category include Connect:Direct (see http://www.sterlingcommerce.com), Synchrony Transfer (http://www. axway.com/) and Intranect (http://ers-technology.com/).

2.1.2

Extract, Transform and Load (ETL)

ETL tools are predominantly designed to assist with the control and implementation of integration scenarios for batch and mass data. These frequently arise when data marts or data warehouses are filled with data, or when operational data stores (ODS) are used that have no real time requirements, but are characterized by large volumes of data. Many ETL tools also offer a considerable variety of options for implementing data transformations. The gap between the EAI and ETL categories is drawing ever closer in today’s market. ETL providers are adding more and more real time properties to their tools, and EAI tools are capable of processing increasingly larger data volumes. The convergence of these categories also means that it conceivable for standards such as Extensible Stylesheet Language Transformation (XSLT) to be used in the area of transformation to achieve a certain degree of tool independence. This enables switching between tools, or the use of components (for example, standard mappings) in a number of different tools. Examples of ETL tools include Oracle Warehouse Builder (see http://www.oracle.com), Power Center (http://www.informatica.com), Pentaho Data Integration (http://www.pentaho.org) and SQL Server 2005 Integration Services (http://www.microsoft.com/sql/technologies/integration/default.mspx ). For an extensive overview of ETL tools currently available in the market, refer to http:// www.etltool.com.

2.1.3

Enterprise Information Integration (EII)

EII solutions are defined by a metadata-driven virtual database view, which enables the execution of database queries across several systems in real time. These systems may be relational or object-oriented databases, or applications such as SAP ERP, SAP SRM, or proprietary developments. Most solutions today are based on the use of a relational access model (SQL). However, some solutions based on web services and XML are also available. These approaches offer various benefits, which depend on internal, enterprise-specific standards.

19

175 BOOK.indb 19

10/2/08 8:55:26 AM

2

Integration Tools

Due to the growing demand for the display of data views of unstructured datasets in relational or XML databases, integration is becoming a much more complex task, and some ETL and EAI concepts are approaching the limits of what they can achieve. EII tools, on the other hand, are largely considered an option for online reporting. Tools that fall into the EII category include Stylus Studio (see http://www.stylusstudio. com), Composite Data Integration (http://www.compositesw.com) and AquaLogic Data Services Platform (see http://www.bea.com).

2.1.4

Enterprise Application Integration (EAI)

EAI tools are distinguished by event-oriented and real time-oriented architectures for internal and external application scenarios. EAI tools are based on a communication level that enables queue-based, asynchronous communication similar to message-oriented middleware (MOM). As shown in detail in Figure 2.1, these tools usually cover the following functional areas: EE

Connectivity to other systems

EE

BPM and workflow

EE

Mapping and transformation

EE

Quality of service (QoS)

EE

Routing and addressing

EE

Administration

EE

Messaging and security

Tools that fall into this category include SAP NetWeaver Process Integration (SAP NetWeaver PI) (see http://www.sap.com), Business Works (see http://www.tibco.com) and BizTalk (see http://www.microsoft.com). A particularly large number of providers of tools in this category exist in today’s market, and the choice of one over the others must always be based on enterprise-specific requirements because there is no such thing as a “one size fits all” EAI solution.

20

175 BOOK.indb 20

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:26 AM

Classification

2.1

EAI-Hub/Broker Capabilities Connectivity

BPM/Workflow

Mapping/Transformation

Technical Adapters

Orchestration

Graphical Mapping

Application Adapters

Modeling

XSLT-Mapping

Standard Adapters

HumanWorkflows

API-Mapping

APIs

Threshold Monitoring

Quality of Service

Routing and Addressing

Administration

Dynamical Routing

Monitoring

Availability Load Balancing

Content-based Routing

Failover

Subject-based Routing

Scalability

Alerting Interface Restart Backup/Recovery

Messaging

Security

Assured Delivery (EOIO,..)

Authentication

Message Priorities

Authorization

Message Sequencing

Audit

Message Persistence

Encryption

Housekeeping/Archiving Version Management Logging Search Reporting

Figure 2.1  Properties of EAI Tools

2.1.5

Business Process Management (BPM)

A standard definition for BPM has not yet emerged in the industry. BPM fundamentally comprises the design and — above all — the optimization of business processes. The distinguishing features of BPM tools are: EE

Business processes with human integration/human workflows

EE

Real time integration

EE

Orchestration of business processes through the integration of services from various systems

EE

Introspection of third-party systems

21

175 BOOK.indb 21

10/2/08 8:55:29 AM

2

Integration Tools

Tools that fall into the BPM category include Galaxy from SAP (see http://www. sap.com), Intalio (see http://www.intalio.com), Appian (see http://www.appian.com/), Pegasystems (see http://www.pega.com/), Webmethods BPMS from Software AG (see http://www.softwareag.com), and the BPM Suite from IBM (see http://www.ibm.com). However, the defining feature of the market is that it still contains a large number of small companies that will very likely be consolidated in the coming years.

2.2

Selecting a Tool

The tools in all of the previously mentioned categories are optimized for their specific areas of application. However, a considerable degree of overlaps exists between the tools (see Figure 2.2). Additional categories of integration tools also exist (such as an enterprise service bus [ESB]). These can be described as supersets or subsets of EAI and BPM tools or as logical concepts of these tools. Data

Integration Spectrum

Process

Real-Time Mode

Integration Spectrum

Business Process Management (BPM)

Batch Mode

Enterprise Information Integration (EII) Enterprise Application Integration (EAI) Extract, Transform and Load (ETL)

Managed File Transfer (MFT)

Figure 2.2  Classification of Integration Tools

Many integration scenarios can be implemented using multiple tools from different categories. In other words, several tools may be suitable for use in any one scenario. For this reason, clear specifications are essential to the implementation

22

175 BOOK.indb 22

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:29 AM

Selecting a Tool

2.2

process. In any scenario, many different enterprise-specific criteria must be taken into account when deciding on a tool. These include existing licenses, instances, support organizations, and strategies with respect to service-oriented architectures (SOA). In addition, there are the usual criteria that apply to the selection of any piece of software, including the provider’s market presence, roadmap, implementation support, and so on. Figure 2.3 and Figure 2.4 illustrate the primary strengths and weaknesses of the different tools. This should help you select the correct tool in any actual integration scenario. The non-functional requirements (e.g., batch or real time) listed in Figure 2.3 must be pinned down as part of the functional design phase. The specific technical requirements (e.g., web service consumption) must then be defined in the subsequent technical design phase. Based on these requirements, the most suitable tool from a technical perspective can be selected. MFT

ETL

EII

EAI

BPM

Integration Category

Data Integration

Data Integration

Data Integration

Application Integration

Application and Human Workflow Integration

Primary Focus

Batch Transfer

Decision Support/ Data Warehouse Systems

Real-Time Data Integration

Integration of Applications

Process Integration

Primary Technology

File Transfer

Relational Databases

Databases

Applications, Message Bus

Applications, Message Bus, Workflow

Speed of Integration

Latent/Batch/ Minutes

Latent/Batch

Real Time

Real Time

Real Time

Source Systems

Files

Databases, Files, Apps

Databases

Applications

Applications

Target Systems

Files

Warehouse, Mart, Operational DataStore

Query-Based Applications

TransactionOriented Applications

TransactionOriented Applications, Workflow-Oriented Applications

Data Formats

Nearly Unrestricted

Nearly Unrestricted

Nearly Unrestricted

Nearly Unrestricted

Nearly Unrestricted

Initiation

Pull and Push

Pull, QueryDriven

Pull, QueryDriven

Push, Pull, Event-Oriented

Push, Pull, Event-Oriented

Business Processes

No

No

No

Yes

Yes

MetadataDriven, Simple Data Flow

MetadataDriven, Complex Data Flow

MetadataDriven, Simple Data Flow

Business Rules, Workflow-Oriented

Control

Business Rules, Workflow-Oriented, Interactive

Figure 2.3  Differences Between Integration Tools

23

175 BOOK.indb 23

10/2/08 8:55:30 AM

2

Integration Tools

Source Data Connectivity Implementation Effort

5 4,5

Data Target Connectivity

ETL

4

Delivery to Multiple Targets

3,5

MFT

Physical Bulk Movement

3

EII EAI BPM

2,5 2

Web Service Publishing

Federated Views

1,5 1 0,5 0

Web Service Consumption

Message-Oriented Movement

Replication

Changed-Data Capture

Transformation Real-Time Delivery

Scheduled Execution Event-Driven Execution

Figure 2.4  Key Uses of Integration Tools

2.3

Uses of SAP NetWeaver PI

SAP entered the market for integration tools at a relatively late stage (2002) with its Exchange Infrastructure (XI). The initial version of XI was aimed predominantly at the implementation of integration scenarios in the SAP environment and had limited functional scope. However, from the very start it was positioned firmly in the EAI category as a real time tool for process support. Version 3.0, which was released for general use based on the NetWeaver 2004 platform, included essential functions such as cross-component business process management (ccBPM) for orchestrating business processes, and the Java Connectivity Adapter Engine (JCA). Support Packages for this product subsequently delivered — at three-month intervals — bug fixes and often significant functional enhancements. This played an important role in creating market acceptance of XI. The ccBPM function marked a clear distinction between XI and BPM tools. It is strongly recommended not to use XI in conjunction with interactive business pro-

24

175 BOOK.indb 24

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:30 AM

Uses of SAP NetWeaver PI

2.3

cesses (see William Li; Peter Ludwig: Design Patterns for SAP NetWeaver Exchange Infrastructure. SAP Teched, 2006. Session EPI204, pg. 34). With version 7.0, XI was reborn as SAP NetWeaver Process Integration (SAP NetWeaver PI). SAP NetWeaver PI 7.0 is a minor release, because the functions available in version 3.0 were preserved in version 7.0, with the exception of those in the last support packages. SAP NetWeaver PI 7.0 runs on NetWeaver 7.0. SAP has now become well-established in the market for integration tools (see, for example Sindhu Gangadharan; Prasad Illapani: TechEd 2007. Session EPI210, pg. 8). A survey conducted by the DSAG (German-Speaking SAP Users’ Group) and ASUG (Americas’ SAP Users’ Group) also indicates that SAP NetWeaver PI is now used globally on a large scale for mission-critical processes in high-availability IT landscapes (see Hermann Steinrötter; Christoph Liebig: DSAG Technology Days: Dresden 2008, http://www.dsag.de). Furthermore, it emerged that several reference customers currently use SAP NetWeaver PI to process more than 20 million messages a month, or to process messages with very large file sizes (see Figure 2.5).

Scalability/Message Throughput Number of Messages per Month between 80 and 100,000,000 Number of Messages per Day between 10 and 3,000,000 File Sizes between 20 KB and 120 MB Figure 2.5  Customer Survey on the Use of SAP NetWeaver PI

According to this survey, the majority of customers judged the performance and stability of the tool as acceptable, with 21% rating performance and stability as “excellent” and 64% rating these as “good.” The main bottlenecks mentioned were large message sizes (> 50MB), ccBPM, and memory consumption. It is in exactly these areas that SAP has made improvements with version 7.1. In addition, the acceptance of ccBPM is higher than expected. Two-thirds of all customers interviewed in the survey use ccBPM, albeit largely for technical inte-

25

175 BOOK.indb 25

10/2/08 8:55:30 AM

2

Integration Tools

gration. The use of integration tools for a true orchestration of business processes is still the exception rather than the rule. Figure 2.6 shows the development of SAP NetWeaver PI over time in terms of functionality, flexibility, and support for SOA.

Flexibility/Functionality

2003

2005

2006

2008

PI 7.1 PI 7.0 XI 3.0 XI 2.0

EPs SPs

SPs SPs

Integration

Enterprise SOA Total Cost of Ownership

Figure 2.6  Development of SAP NetWeaver XI/PI

The new release, SAP NetWeaver PI 7.1, marks another milestone in the development of SAP’s integration tool. The new version includes significant improvements in almost all areas of EAI functionality, and also brings the tool a big step closer to SOA. The key new features are as follows: EE

The Enterprise Services Registry, which is compatible with Universal Description, Discovery and Integration (UDDI) version 3.0

EE

Improved web service standard support

EE

WS ReliableMessaging (WS-RM)

EE

WS Security und Security Assertion Markup Language (SAML)

EE

Support for direct web service connections between service consumers and service providers

EE

Improved design and modeling capabilities, including BPEL modeling

EE

XML validation

26

175 BOOK.indb 26

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:30 AM

The Structure of SAP NetWeaver PI

EE

Support for the event infrastructure/business activity monitoring (BAM)

EE

Improved support for mass data processing

EE

Local processing in the Adapter Engine

EE

Grouping of messages with message bulking

EE

Optimized execution of ccBPM

EE

Reduced hardware requirements

2.4

2.4

The Structure of SAP NetWeaver PI

No major changes have been made to the basic structure of SAP NetWeaver PI since the first version (see Jens Stumpe; Joachim Orb: SAP Exchange Infrastructure. SAP PRESS, 2005). This structure is shown in Figure 2.7. We can distinguish between the following components: EE

System Landscape Directory (SLD) All information about the IT system landscape in the SAP environment is stored in the SLD. It provides a basis for the design and runtime environment, and is used for central administration of the technical and logical systems. All information relating to products and software components are stored in the SLD, together with the technical properties of the systems. All IT systems of an enterprise are stored in the business landscape area, together with details of the systems used (for example QA and development systems).

EE

Enterprise Services Repository (ESR) The ESR is a metadata store that contains information used to describe data. The following data is stored in the ESR: EE

Web Services Definition Language (WSDL) files WSDL files describe the service interfaces of enterprise services. They describe, in particular, the operations that can be executed externally, as well as the parameters and return values. These are usually data types, functions, and the exchange logs of a web service. These descriptions are then used by development tools at runtime.

EE

Business object descriptions Business objects are used during the design and modeling phases to describe structures in applications.

27

175 BOOK.indb 27

10/2/08 8:55:31 AM

2

Integration Tools

EE

Process component models These models describe how complete processes are created through the composition of enterprise services. They show how a service is used, and which business objects use the service.

The ESR is a metadata store, which means that it stores data that describes other data. This metadata describes services implemented in other applications. The ESR is an enhancement of the Integration Repository (IR) used in previous versions. EE

Integration Directory (ID) The ID is the central tool for configuring integration processes. For example, it is here that you define which internal systems or external partners defined in the SLD are involved in a process, which message types are used, and which message mappings, routing rules and adapters are applied.

EE

Integration Builder (IB) The IB is the central development environment for SAP NetWeaver PI. At design time, all objects are developed for the ESR. At configuration time, all objects are defined in the ID.

EE

Integration Server (IS) The IS represents the runtime environment of SAP NetWeaver PI. Its role is to receive, process, and forward messages. The IS incorporates the following components: the Business Process Engine (BPE — for executing ccBPM), the Integration Engine (IE — for providing central services of the IS, including mapping and routing), and the Advanced Adapter Engine (AAE). The AAE is new in Version 7.1 and represents an enhancement of the Adapter Engine (AE). The configuration determines whether the new features of the AAE can be used (for example, end-to-end message processing without the IE).

EE

Runtime Workbench (RW) The RW is a browser-based tool for accessing SAP NetWeaver PI administration and monitoring of message processing and performance.

As shown in Figure 2.8, no major changes have been made to internal pipeline processing or the sharing of tasks between the Java Engine and the ABAP Engine of SAP NetWeaver PI since the previous version.

28

175 BOOK.indb 28

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:31 AM

The Structure of SAP NetWeaver PI

2.4

Central Monitoring

Design Time Integration Builder/ ES Builder

XI Protocol

Runtime Runtime Workbench

Partner Connectivity Kit

Business Partner/Routing Hub CDIX, RosettaNet

Integration Server Enterprise Services Repository

Integration Directory

(Small) Business Partner

Third Party Applications

File, RDBMS,JMS,SOAP

Business Process Engine

RFC... IDoc,

Integration Engine

http

XI Protocol

Advanced Adapter Engine

SAP System SAP or Non-SAP System Local Integration Engine Proxy Runtime Proxy SAP Web AS ≥ 6.20

System Landscape Directory (SLD)

Pipeline Processing Receiver Determination

Interface Determination

Message Split

J2EE Engine ABAP Engine • Internet Communication Manager (ICM) • Pipeline Processing • Inbound, Outbound Queues

Mapping Request

Call Adapter

Adapter Framework

Adapter Framework

Figure 2.7  Structure of SAP NetWeaver PI 7.1

Mapping Engine J2EE Engine • Adapter • Adapter Framework • Mapping

Figure 2.8  Pipeline Processing and the J2EE and ABAP Engines

29

175 BOOK.indb 29

10/2/08 8:55:32 AM

2

Integration Tools

The Enterprise Services Registry is, alongside the ESR described previously, the central system for registering, defining, and describing enterprise services. The registry is a standardized directory service with the following distinguishing characteristics: EE

“Yellow Pages” for finding services

EE

Service management

EE

Compatibility with UDDI version 3.0

The interaction between SAP NetWeaver PI, the ESR, and the registry is shown in Figure 2.9.

Repository Tools Enterprise Services Repository

Consumer Tools Registry

Find

Published Service Models Publish

Published Service End Points

Direct Connection

Service Provider Service Implementation

Service Consumer

Service End Point

Consumer Application

Process Integration (PI) BPM Routing/Mapping Transformation

Service Call

Figure 2.9  Registry, Repository and SAP NetWeaver PI 7.1 Engine

Now that we have introduced you to the various integration tools and the technical principles on which SAP NetWeaver PI 7.1 is based, we will dedicate the next chapter to a detailed description of the processes used to implement integration scenarios with design patterns.

30

175 BOOK.indb 30

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:32 AM

3

Benefits of Using Patterns to Solve Integration Problems

It is advisable to use a standardized approach to development to implement integration scenarios effectively, rather than ending up with a multitude of point-to-point integration scenarios. Such an approach allows you to identify relevant design patterns and standardize and optimize these patterns within your enterprise. This chapter presents one possible standardized approach to the implementation of integration scenarios. Individual project steps — and the various roles and responsibilities involved — are described in detail. Based on this, we then show you how patterns can be used to assess the degree of complexity of individual scenarios, which in turn allows you to estimate the costs of implementation and testing.

3.1

A Standardized Approach

At all stages of a standardized software lifecycle, a strict schema should be adhered to (see Figure 3.1). The development lifecycle as documented in the IT Infrastructure Library (ITIL; see http://www.itil.org) is a generally accepted model. The individual phases are as follows: EE

Analysis This phase serves to analyze functional and non-functional requirements. Functional requirements specify what is needed from a business perspective. Nonfunctional requirements convey the service management view. Several software quality models have already been worked out, including ISO/IEC 9126 and DIN 66272. These provide metrics for non-functional requirements. Non-functional requirements include reliability (error tolerance and robustness), efficiency (time responses and consumption patterns), transferability (installability and adaptability), and security requirements (authorization and authentication).

31

175 BOOK.indb 31

10/2/08 8:55:33 AM

3

Benefits of Using Patterns to Solve Integration Problems

Analysis Optimization

Planning

Portion of Business Dpt. Involvement

ProduktionsProduction support Support

Application Lifecycle Management

Go-Live

Design

Development

Test

Figure 3.1  Lifecycle Management EE

Planning Planning comprises conventional project management for software developments (resources, costs, schedules, etc.). Note, however, that it is essential to take the entire system landscape into account when implementing integration scenarios. Integration platforms are usually live platforms, and changes therefore need to be planned in advance and agreed to by the relevant business departments.

EE

Design The design phase is based on the technical integration requirements, and also depends on the operational environment to fulfill the non-functional requirements. Service level agreements (SLAs) must be defined to meet the operational requirements. During this phase, it is essential that the technical requirements and SLAs be reconciled with the requirements determined in the analysis phase.

32

175 BOOK.indb 32

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:33 AM

A Standardized Approach

EE

Development Development comprises not only the actual programming of the source code and the necessary configuration, but also the preparation required before the solution can go live and operate in a live environment.

EE

Testing In integration scenarios, failure is not an option. A large part of implementation is therefore dedicated to test scenarios. The test phase is divided into the unit test by developers, the integration test, and the user acceptance test. The business departments are involved in the last two of these tests, where the test cases defined during the analysis are executed and documented. An additional test to verify performance and stability is also required, in particular if an enterprise has a shared integration platform. To define worst-case scenarios, all new and live scenarios must be analyzed. The development and test environments must replicate the production landscape exactly. Compromises are frequently required with respect to this because communication with legacy systems that have no test systems is often necessary, and a performance test with the production system is not possible. Note also that end-to-end tests must be performed to detect bottlenecks at any point along the integration chain as early as possible.

EE

Go-live In the Go-live phase, the programs and operational procedures of the integration scenarios are transferred to production simultaneously.

EE

Production support Operational support secures SLAs, operates active monitoring and solves problems as they arise (see Marcus Banner and Heinz-Peter Klein: Mastering SAP XI – Administration, SAP PRESS 2005).

EE

Optimization/continuous improvement This phase involves optimizing the implementation from both a technical and a business perspective.

3.1

We can distinguish between the following roles associated with the implementation of integration scenarios: EE

The business department as the end customer of all IT projects EE

Key user/power user This person has thorough knowledge of the integration process from a business process perspective. This user defines the functional and non-functional requirements and is involved in integration and end-user testing. During the

33

175 BOOK.indb 33

10/2/08 8:55:33 AM

3

Benefits of Using Patterns to Solve Integration Problems

analysis and design phases, a wide variety of business department-specific test cases are defined and documented for later testing. EE

EE

IT integration team EE

Integration architect The integration architect has sound knowledge of the integration technologies and the applications used in the enterprise, and is responsible for the technical design of integration scenarios.

EE

Developer A developer implements the integration scenario. Developers are responsible for developing the solution in the Integration Repository and for configuring the solution as required.

EE

Application team(s), comprising application architects and application developers The Integration Engine generally acts as a mediator between several systems. To implement integration scenarios between the various systems, functional and technical expertise with respect to the source and target systems is often required. This is provided by architects and developers of third-party systems.

EE

Technical/infrastructure team(s)

EE

34

175 BOOK.indb 34

Business process analyst/functional architect This person collaborates with the business department, understands the various business processes, and has in-depth knowledge of the application landscape.

EE

SAP NetWeaver PI/SAP Basis The classic SAP Basis unit that takes care of installation and basic operations, including transport management. Specialist knowledge of the SAP NetWeaver PI integration platform is essential, for example operation of the Java Web Application Server (Java Web AS), and queue management.

EE

Hardware/operating system/network/security In addition to SAP Basis, the infrastructure must have a stable environment provided by either internal or external services.

Service manager/landscape manager The landscape manager coordinates all activities in a certain area, which may be technology-specific or business department-specific. The landscape manager has responsibility for release planning, and for ensuring a silent running operation.

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:33 AM

A Standardized Approach

3.1

The responsibilities in the individual project phases are defined in accordance with the RACI matrix (see Figure 3.2), which is a simple method for representing a variety of roles and responsibilities. The following terms are used in this model: EE

Responsible (R) This refers to responsibility for the implementation. It is used to describe the person who performs the implementation directly or initiates the action through a third party. In other words, this person is responsible in a disciplinary sense.

EE

Accountable (A) This means being responsible for authorizing, approving, or signing off on the implementation. It is used to describe the person who is responsible in a managerial sense.

EE

Consulted (C) This refers to responsibility in the sense of having one’s opinion sought on the matter. It is used to describe the person whose advice is sought or who provides an expert opinion.

EE

Informed (I) This refers to people who need to be kept in the loop with progress. Business Department

Key User

IT Integra�on Team

Applica�on Team(s)

Business IntegraProcess �on Applica�on DeveloAnalyst Architect Developer Architect per

Technology/ Infrastructure Team(s) Hardware/ Opera�ng SAP Net- System/ Weaver PI/ Network/ SAP Basis Security

Landscape Management Service Manager/ Landscape Manager

Analysis

A

R

C

I

C

I

I

I

I

Planning

C

I

C

I

C

I

I

I

A,R

Design

I

I

A,R

C

R

C

C

C

I

A

R

A

R

C

C

C

Development Test

C

A

R

A

R

C

C

I

Go-Live

C

R

C

R

C

C

C

A

Produc�on Support

I

C

C

A,R

Op�miza�on

A

C

C

I

C

A

A

Figure 3.2  RACI Responsibilities During Standard Lifecycle Management

35

175 BOOK.indb 35

10/2/08 8:55:33 AM

3

Benefits of Using Patterns to Solve Integration Problems

3.2

Patterns for Assessing Complexity

Patterns facilitate communication with the business department and are also an excellent tool for defining internal standards and assessing the complexity — and therefore the cost — of an implementation scenario. Complexity depends on a range of factors that can be used to not only assess the implementation cost, but also to determine the risk involved and what resources need to be scheduled for testing. The criteria listed in Figure 3.3 can be used to assess complexity. These criteria are based on the non-functional requirements of a business process, the complexity of the integration scenario itself, the technical requirements, and how much experience the project team has with comparable technical implementations.

Business Process

• Relevance/Required SLA • Security Requirements • # Business Departments Involved/# Time Zones • # External/Internal

Scenario

• # Steps Integration Process/# Standard Patterns • Data Volume • Frequency (Permanent/Daily/Hourly/Monthly) • # Involved Systems Source/Target Systems • # Non-Standard/Legacy Systems

Implementation

Project Team

• # Adapter • # Mappings/Mapping Complexity • ccBPM/Dynamical Routing

• Experience • Existing Standards

Figure 3.3  Complexity and the Cost of Implementation

If many integration scenarios need to be implemented and a large number of project and implementation teams are involved, it is advisable to use characteristics to assess the complexity of an interface. Figure 3.4 shows how this can be done. For each criterion, quantifiable units of measure are defined for low, medium, and high. For data volume, for example, a throughput of fewer than 1,000 messages per hour is rated as low, while the number of systems involved is deemed to be high in a scenario of four systems. Each criterion is also assigned a weighting factor and

36

175 BOOK.indb 36

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:34 AM

Patterns for Assessing Complexity

3.2

each rating is assigned an index. In a real-life scenario, the individual values are calculated and the corresponding complexity factor for the scenario is calculated by multiplying the weighting factor by the index.

1. Business Process 1.1

1.2

Service Level Agreement

External/ Internal

Factor

High (7x24 SLA Required) Average (5x24 SLA Required) Low (5x8 SLA Required) High (External and Internal Business/IT Departments are Involved) Average (Processes within the Enterprise but with Different Business Departments) Low (All Processes within One Business Department and IT Department)

1.3

...

Factor: Business Process

Index

X/Blank

Result= IF(GX="X";EX*FX;0)

4

2

0

4

1

4

1

0

4

2

0

4

1

4

1

X

X

4

4

0

0

8

Figure 3.4  Complexity Matrix

It is important to use standardized metrics that can be understood and accepted by all persons involved in the implementation. Complexity should be determined during the analysis phase, using defined criteria. Based on the complexity determined, resource planning and scheduling should take place during the planning phase (for example, in relation to the involvement of senior architects, the number of test cycles, the amount of time allowed for implementation and testing). After the implementation, estimates should be reviewed briefly to enable greater accuracy going forward. During the analysis phase, business process analysts and the integration architect must decide on the pattern to be used for the implementation. If a pattern has already been successfully applied in the past, it is very important that this same pattern be reused to ensure conformity of implementations. An enterprise should

37

175 BOOK.indb 37

10/2/08 8:55:34 AM

3

Benefits of Using Patterns to Solve Integration Problems

put in place a repository for the implementation of patterns. This type of repository enables the standardization of implementations, and the execution of monitoring and error handling routines. Patterns are, first and foremost, a comprehensible means of communication that facilitates greater understanding among the individuals involved in an implementation. Now that we have examined the fundamental principles and procedures for implementing integration scenarios, in the next chapter we will turn our attention to considerations and approaches to the modeling and organization of objects within software components based on SAP NetWeaver PI.

38

175 BOOK.indb 38

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:34 AM

4

Modeling Concept

The modeling concept provides the foundation for any integration project based on SAP NetWeaver Process Integration. It describes the organization of software components and individual objects, as well as the definition of naming conventions and the overall implementation approach both at design time and configuration time. The modeling concept is enhanced by the monitoring concept, which defines specific requirements in relation to runtime and monitoring of systems. Depending on the size of the enterprise, the concepts and procedures may not necessarily be defined in writing, although experience shows that naming conventions are a minimum requirement in any enterprise. As a rule, it is recommended that the concepts are documented as guidelines, the initial time invested in doing so will pay off with the following benefits: EE

A procedural guideline improves the quality of the implementation because the approach taken is one that has already proven itself in practice (best practices).

EE

Documented approaches and concepts provide a more solid basis for questions and discussions.

EE

Support is provided for new employees who become involved in the subject matter. The transfer of knowledge takes less time.

EE

For external development (both near-shore and offshore), communication costs are significantly reduced because the basic questions and procedures are documented.

In the current literature that discusses SAP NetWeaver PI/XI, relatively little information is provided about how software components and their objects are organized. This is related to the fact that the approach to an implementation depends very much on how the enterprise itself is organized. For example, the approach adopted in an SAP-dominated system landscape would differ from that used in a very heterogeneous environment. Sections 4.1, 4.2 and 4.3 introduce you to three

39

175 BOOK.indb 39

10/2/08 8:55:34 AM

4

Modeling Concept

different software component strategies that have been used in various customer projects. Each of these is equally legitimate, based on the individual enterprise and system landscape. We’ve adopted one of these organizational types for our demo example. Therefore, Section 4.2, Three-Component Strategy, also provides a basis for organizing the software components of the patterns described in Chapter 5, Enterprise Integration Patterns. Most of the patterns are available for download as demo examples. Section 4.4, Procedure at Design Time, and Section 4.5, Procedure at Configuration Time, therefore provide important information to help you understand and configure the examples. Note For the sake of readability, the term software component is used throughout this chapter to also implicitly referr to software component versions. Because we work at the level of software components and software component versions within the ESR, we don’t refer to the products or product versions of the System Landscape Directory (SLD) from this point on. Note, however, that a product refers to a product version, and a software component refers to a software component version. The software feature object in the SLD is used to create a link between a product version and a software component version.

A clear definition of an enterprise-wide software component strategy is usually a prerequisite for the following additional requirements: EE

It must be possible to map the integration requirements of an enterprise in the software it uses (IT follows business).

EE

The responsibilities at design time must be clearly defined.

EE

It must be possible to reuse objects.

EE

Support must be provided for maintenance and monitoring of the integration scenarios.

EE

Support must be provided for the distribution of integration scenarios across several SAP NetWeaver PI systems, if necessary.

In order to fulfill these requirements, the organization of the software components and the development objects they contain must be carefully considered and scrutinized. As a rule, at design time a service (or components or systems), involved

40

175 BOOK.indb 40

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:34 AM

Modeling Concept

4

in an integration scenario is represented by a software component and its related product. At configuration time, several services (or components or systems) that are represented by the software components can be configured. For example, a central SAP ERP system sends a transport request to various local retailing systems. Because all retailing systems implement the same service, only one is modeled at design time, while the corresponding number of local systems is configured at configuration time. The following sections introduce you to three different software component strategies that fulfill different requirements, taken from real-life scenarios. When formulating a strategy, the question is always where the individual design-time objects should be stored. Before we can answer this question, two object categories must be defined: 1. Objects that reflect properties of integration logic EE

Process Integration Scenario

EE

Integration Process (including Step Group, Alert Category, and Monitoring Process)

EE

Operation Mapping

EE

Message Mapping (including a Functional Library, imported archives, and a Mapping Template)

2. Objects with service-specific or component- or application-specific properties EE

Action

EE

Service Interface

EE

Message Type (including Fault Message Type)

EE

Data Type (including Data Type Enhancement and External Definition)

EE

Context Object

EE

Imported Object

EE

Communication Channel Template

To simplify matters, we refer to these two object categories as integration-logic objects and service objects. The assignment of objects within a software component is determined by the strategy selected.

41

175 BOOK.indb 41

10/2/08 8:55:34 AM

4

Modeling Concept

Note This book focuses on the area of process integration scenarios and the associated development of application-to-application (A2A) and business-to-business (B2B) scenarios. Topics such as the modeling of process components or business objects are beyond the scope of this book. We can, however, refer you to the book called Developing Applications with Enterprise SOA by Martin Huvar et al., also published by SAP PRESS.

4.1

Two-Component Strategy

A two-component strategy is the simplest way to organize software components, and is suited to sender and receiver applications. In this case, the sender and the receiver system are each represented by a software component, which describes the services of the relevant system. Although it is very easy to assign service objects with this strategy (each application-specific software component contains the corresponding service objects of the relevant application), it is much more difficult to answer the question of how the integration objects should be assigned. For example, the software component to which a process integration scenario, an integration process, or the mapping between sender and receiver applications should be assigned is not always obvious. In real-life projects, the two-component strategy tends to be used by enterprises with a harmonized or consolidated ERP system. In this case, the problem of integration logic is solved as follows: The software component of the ERP system is classified as the leading component, and therefore contains the integration objects. Figure 4.1 shows the distribution of development objects among the relevant software components (SCs). The benefits and drawbacks of the two-component strategy are as follows: EE

42

175 BOOK.indb 42

Benefits EE

The strategy is suited to enterprises with relatively simple system landscapes and one leading system that determines where the integration logic is stored.

EE

One leading software component contains the integration logic. In other words, the logic does not need to be distributed among various software components.

EE

The strategy is less complex.

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:34 AM

Three-Component Strategy

EE

4.2

Drawbacks EE

A main software component may not hold this status forever (for example in case of a merger, or if divisions of the enterprise are sold).

EE

Process integration scenarios that do not include the leading software component must be treated as exceptions, which results in a distribution of integration logic.

EE

This is not the best approach for communication between two SAP NetWeaver PI systems (PI-PI communication).

EE

This strategy is not suitable for the canonical data model pattern (see Section 5.2, Canonical Data Model) because this pattern is based on the concept of three software components. Sender Product * “Leading” (Non-)SAP SC

NameSpaces Process Integration Scenarios Actions Integration Processes Service Interfaces Message Types Data Types Operation Mappings Message Mappings Context Objects Imported IDocs/RFCs Comm. Channel Template

Receiver Product* (Non-)SAP SC NameSpaces Actions Service Interfaces Message Types Data Types Context Objects Imported IDocs/RFCs Comm. Channel Template

*Sender and receiver can be exchanged.

Figure 4.1  Two-Component Strategy

4.2

Three-Component Strategy

The three-component strategy takes the two-component strategy a step further by adding a additional software component. This can be regarded as an abstract software component because no specific services or applications can be assigned to it. Instead, this component (called a COMMON component) is used as a central storage location for integration-logic objects. Therefore, a leading application-specific software component is no longer required. Figure 4.2 shows the distribution of development objects among the relevant Software Components (SCs).

43

175 BOOK.indb 43

10/2/08 8:55:34 AM

4

Modeling Concept

Sender Product *

COMMON Product

Receiver Product*

(Non-)SAP SC

COMMON SC

(Non-)SAP SC

NameSpaces Actions Service Interfaces Message Types Data Types Context Objects Imported IDocs/RFCs Comm. Channel Template

NameSpaces Process Integration Scenarios Actions (IP) Integration Processes Operation Mappings Message Mappings Context Objects

NameSpaces Actions Service Interfaces Message Types Data Types Context Objects Imported IDocs/RFCs Comm. Channel Template

(Process Integration Scenarios)

(Process Integration Scenarios)

*Sender and receiver can be exchanged.

Figure 4.2  Three-Component Strategy

In this case, the central COMMON software component is geared towards specific integration projects. In other words, a COMMON software component is created for a specific (sub) project to store the integration logic of the individual integration scenarios in that project. Separate software components are created for new projects so that individual projects can be worked on independently of one another (separation of responsibilities). The application-specific software components are each assigned a project ID that indicates that they belong to the COMMON component. In other words, a specific application can be represented by various project-based software components. Depending on how the enterprise is organized, a functional ID may be used as an alternative to the project ID to ensure a clear distinction between software components. The benefits and drawbacks of the three-component strategy are as follows: EE

44

175 BOOK.indb 44

Benefits EE

There is a clear separation of responsibilities because the integration logic is stored independently of the software components that should be integrated.

EE

The approach is flexible. Company mergers can be mapped without migration problems.

EE

The strategy is suited to complex organizations.

EE

The strategy provides a basic architecture for the canonical data model pattern (see Section 5.2, Canonical Data Model).

EE

The strategy can be used for PI-PI communication.

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:35 AM

Three-Component Strategy

EE

4.2

Drawbacks EE

The strategy is more complex due to the additional COMMON software component. For example, three software components have to be released in order to transport a process integration scenario.

EE

A risk exists that the separation of responsibility is not ensured in the case where parallel projects are implementing identical integration scenarios.

EE

The strategy does not offer a process-based perspective. The abstraction of the integration logic is based on individual projects rather than business processes.

By separating software components based on projects, you ensure that different development teams can work on project-based integration scenarios. As a result, the channels of communication within the team can be used, for example, to trigger transports or transfer individual software components to production. In addition, read and write access can be controlled on the basis of individual software components. However, overlapping may occur with this approach if global objects are required that should be used by several projects at the same time. In cases like this, it has proven useful to define a global software component to allow objects to be reused (see Section 5.2, Canonical Data Model). The sample scenarios discussed in this book are based on the three-component strategy. For the components provided, we assume that the system landscape of patterns is based on one ERP system and several LEGACY systems of the same application type. Therefore, the ERP system and the LEGACY systems are each represented by one software component, while the integration logic is stored in a central COMMON software component. The naming convention used for the software component has the following structure: _ 

For the purposes of our demo project, these placeholders are filled with the following fictional values: Placeholder

Value

Company

PI-Patterns

Project ID

EIP (Enterprise Integration Patterns)

Product name 1

ERP

Product name 2

LEGACY

45

175 BOOK.indb 45

10/2/08 8:55:35 AM

4

Modeling Concept

We’ve deliberately chosen abstract product names to ensure that our examples are application-independent, and to improve readability. Following the naming convention above, our software components are as follows: EE

PI-PATTERNS_EIP COMMON

EE

PI-PATTERNS_EIP ERP

EE

PI-PATTERNS_EIP LEGACY

Note As already explained, the term software component is used here as a collective term for the individual objects in the SLD, that is, the product, product version, software component (SC), and software component version (SCV). In fact, both a product and a software component were created in the SLD using this naming convention. Each object also has the corresponding Version 1.0. All SLD objects are available for download. The relationships between the objects may be more complex in practice, depending on the product and software components involved. For example, the SAP R/3 Enterprise product in product version 47X200 contains the software component SAP APPL in version 4.70.

4.3

Process-Oriented Component Strategy

The process-oriented component strategy leverages the benefits of the three-component strategy, and, in addition, bridges the gap between an enterprise’s business processes and how they are mapped in SAP NetWeaver PI. CORE process components are defined on the basis of an enterprise’s process documentation. These are comparable with the COMMON component in the three-component strategy, which contains the integration logic of a process area. The organization of objects within the software components is identical to the three-component strategy. However, the semantics of a project-based COMMON component become those of a process-based CORE component. Figure 4.3 shows how the individual objects are organized. In this case, the level of detail of the CORE component depends on the existing process description. Figure 4.4 shows a modeling example taken from a real-life scenario.

46

175 BOOK.indb 46

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:35 AM

Process-Oriented Component Strategy

Sender Product*

CORE Product

Receiver Product*

(Non-)SAP SC

CORE SC

(Non-)SAP SC

NameSpaces Actions Service Interfaces Message Types Data Types Context Objects Imported IDocs/RFCs Comm. Channel Template

NameSpaces Process Integration Scenarios Actions (IP) Integration Processes Operation Mappings Message Mappings Context Objects

(Process Integration Scenarios)

4.3

NameSpaces Actions Service Interfaces Message Types Data Types Context Objects Imported IDocs/RFCs Comm. Channel Template (Process Integration Scenarios)

*Sender and receiver can be exchanged.

Figure 4.3  Process-Oriented Component Strategy

SAP ERP

PI-PATTERNS CORE FIN

Exchange Rate System

PI-PATTERNS CORE OTC DISTRIBUTION

Transport Service Provider

Figure 4.4  Process-Oriented Component Strategy – Example

Figure 4.4 shows two sample CORE process components: 1. PI-PATTERNS CORE FIN, which represents the integration logic for financials 2. PI-PATTERNS CORE OTC DISTRIBUTION, which represents the integration logic for order-to-cash distribution This illustrates how the CORE components represent a 1:1 mapping of the business processes. In this example, the order-to-cash process was divided into several subprocesses, such as distribution and transport and warehouse management, and the financials process was kept generic. Modeling of the CORE software components is thus based on the granularity of the business processes. The application-specific

47

175 BOOK.indb 47

10/2/08 8:55:35 AM

4

Modeling Concept

software components (SAP ERP, EXCHANGE RATE SERVICE, and TRANSPORT SERVICE PROVIDER) are modeled independently and may be used by various processes. In this example, daily exchange rate information is provided by an external system (exchange rate service). The integration logic for this information is stored in the PI CORE FIN component. This provides, for example, the mapping to a target structure in the SAP ERP component, which is a consumer of this information. The PI-PATTERNS CORE OTC DISTRIBUTION component contains a process for integrating the SAP ERP system with a transport service provider application. Individual transport notifications created within the SAP ERP system are transferred to the transport service provider application, which determines the suitable logistics companies and calculates the shipping costs. This information is immediately sent back to the SAP ERP system. Because shipping costs are calculated on the basis of daily exchange rates, the transport service provider application is also “supplied” with exchange rates. The integration logic used for this purpose is already stored in the familiar PI-PATTERNS CORE FIN component. Tip Before business processes are mapped as CORE components, it is advisable to decide which level of detail to use. Mapping at the subprocess level (for example, the distribution process of the OTC process) has proven useful in this context. Projects that use the ARIS Enterprise Activity Model (EAM) as a reference have, for example, selected ArisLevel 3 as their level of detail.

The benefits and drawbacks of the process-oriented strategy are as follows: EE

48

175 BOOK.indb 48

Benefits EE

A process-based perspective with clear mapping of business processes makes it easier to visualize integration processes and can be used as a vehicle for communication.

EE

The approach is flexible, which is well-suited for the mapping of business process outsourcing (BPO) requirements.

EE

This strategy is suitable for relatively complex organizations.

EE

The strategy provides the basic architecture for the canonical data model pattern (see Section 5.2, Canonical Data Model).

EE

This strategy can be used for PI-PI communication.

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:35 AM

Procedure at Design Time

EE

4.4

Drawbacks: EE

The strategy is more complex because of the additional CORE software component. For example, three software components have to be released to transport a process integration scenario.

EE

The reorganization of processes has direct implications for the organization of software components.

4.4

Procedure at Design Time

This section focuses on the procedure used in the Enterprise Services Repository (ESR) and, as such, is intended to facilitate an understanding of the patterns described in Chapter 5, Enterprise Integration Patterns. A schematic explanation of the top-down approach is provided because this is used in all sample patterns provided with this book. The objective of this chapter is not to provide the individual steps to be followed. Rather, it proposes one possible approach that can be taken. Therefore, it uses the top-down strategy to demonstrate all required objects that can be created, based on the process integration scenario. As already mentioned, the enterprise integration pattern project is based on the three-component strategy, which was described in detail in the previous section.

4.4.1

Defining Namespaces

Before we can begin to describe the process of implementing integration scenarios, we must define the namespace as an additional organizational object. To do so, we‘ll apply the naming convention from our demo project: urn::pi::::

According to the three-component strategy, a process integration scenario involves at least three software components. Each software component contains a namespace that uniquely identifies a specific pattern. However, each namespace is used only once because of the different software component names (). Figure 4.5 shows the naming convention that applies to the namespaces in all three software components. For readability, the first three namespaces of the individual software components are listed:

49

175 BOOK.indb 49

10/2/08 8:55:36 AM

4

ModelingConcept

Figure 4.5 Organization of Namespaces

Note The naming convention used here for the namespace has been simplified. In practice, the pattern placeholder () would be replaced by a business object (), which could have additional granularity, for example, granularity based on a functional grouping (:). The release placeholder () does not refer to the software component version. Instead, it allows you to implement several parallel versions of the same interface within one software component version. This approach has particular benefits for migration projects.

4.4.2 Top-Down Approach To implement the process integration scenario of individual patterns, we’ve strictly adhered to the top-down approach. The defining feature of the top-down approach is that the most abstract object is modeled first and provides the basis for creating all of the other, hierarchically subordinate objects.

50

175 BOOK.indb 50

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:36 AM

Procedure at Design Time

4.4

This approach is well-supported within the Enterprise Services Repository, where new objects to be referenced can be created at any time using the context menu (right mouse button). The structure of the top-down approach is shown in Figure 4.6. Process Integration Scenario Actions

Operation Mappings

Service Interface

Message Mappings

Message Types Data Types Figure 4.6  Top-Down Approach

The highest level in the top-down approach is the Process Integration Scenario, which provides a starting point for modeling other objects. Figure 4.6 provides a schematic overview of the approach, which does not show each individual object. Strictly speaking, the Process Integration Scenario is not essential for the functioning during runtime. However, it is recommended that you define a Process Integration Scenario, which offers the following benefits: EE

A unified, end-to-end view of a scenario

EE

Support for the top-down approach

EE

Enabling forward navigation for the referenced objects. (You can double-click on an object to navigate to its subordinate objects in the hierarchy, which saves you having to search for individual objects in various software components.)

EE

A basis for Configuration Time (see Section 4.5, Procedure at Configuration Time)

We use the following naming convention to create a new process integration scenario within the specific namespace of the PI-PATTERNS_EIP COMMON software component:

51

175 BOOK.indb 51

10/2/08 8:55:36 AM

4

ModelingConcept

Pattern (for example: AggregatorPattern)

Within the Process Integration Scenario, the required application components (PIPATTERNS_EIP ERP or PI-PATTERNS_EIP LEGACY) are added, together with a meaningful description of their roles. In other words, the names you assign to the components should clearly reflect the purpose they serve. If the Process Integration Scenario contains an Integration Process, this is represented by the PI-PATTERNS_EIP COMMON software component (in this case, the Integration Process must be created first). Each application component referenced in a Process Integration Scenario forms a swimlane, within which one or more actions can be defined. Like a process flow diagram, a swimlane comprises all activities (or Actions) within an application component. You can use the context menu to create an Action belonging to an application component in a swimlane (see Figure 4.7).

Figure 4.7 Creating Actions

The following naming convention is used when creating actions: Message object (for example: SendContractSample)

Following the top-down approach shown in Figure 4.6, an Action forms the basis for the definition of a corresponding Service Interface (see Figure 4.8) and the

52

175 BOOK.indb 52

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:37 AM

ProcedureatDesignTime

4.4

required Message Types, Data Types, and so on. These are defined hierarchically, from the top down. The following naming conventions apply: EE

Service Interface _ | no postfix for abstract service interfaces>

(for example: ContractSample_OB or ContractStatusSample_IB) EE

Message Types (for example: ContractSample)

EE

Fault Message Types Fault (for example: ContractStatusSampleFault)

EE

Data Types (for example: ContractSample)

Figure 4.8 Creating a Service Interface Within an Action

The same procedure is applied to all Actions of the individual application components in the Process Integration Scenario. To define the flow of messages between individual Actions, connections are generated between the Actions in question. If necessary, an Operation Mapping is also defined in accordance with the top-down approach. A new Operation Mapping based on the connection is created, which references the corresponding Message Mapping. The following naming conventions apply:

53

175 BOOK.indb 53

10/2/08 8:55:37 AM

4

Modeling Concept

EE

Operation Mapping OB_​ _TO_ (for example: Initiator_​ TO_​ GuaranteedDelivery_IB)

EE

Message Mapping: _TO_

(for

example:

Initiator_​ TO_​

GuaranteedDelivery)

Communication Channel Templates are also assigned to the individual connections to later facilitate configuration in the Integration Directory. Communication Channel Templates use the following naming convention: ____TMPL

(for example: File_SND_PI_PATTERNS_EIP_LEGACY_Customer​ MasterData_TMPL) As mentioned previously, the top-down approach is used to implement the patterns described in Chapter 5, Enterprise Integration Patterns. The relevant Process Integration Scenario and its namespace are specified in the Design Time section of each pattern description in that chapter. For example, the following information about the Process Integration Scenario is provided with regard to the Aggregator pattern in Section 5.1: Process Integration Scenario

AggregationPattern

Namespace

urn:pi-patterns:pi:eip:common: Aggregator:100

This information allows you to analyze the sample implementation in the PI-PATTERNS_EIP COMMON software components, and to use forward navigation to jump to the subordinate objects in the hierarchy.

4.5

Procedure at Configuration Time

This section provides information for all readers who want to configure and test the various patterns in their own system environment. To minimize the effort involved in configuring individual patterns, we’ve taken a number of preparatory steps to ensure that the procedure is relatively simple. Each of the patterns

54

175 BOOK.indb 54

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:38 AM

Procedure at Configuration Time

4.5

provided has its own Process Integration Scenario, which serves as a template at Configuration Time. The individual patterns can therefore be configured quickly and independently of one another using the Model Configurator. The Model Configurator is a wizard that can automatically generate the objects required in a Configuration Scenario. It uses the design time Process Integration Scenario as a template, and generates the relevant objects after you enter the configuration-relevant information (such as the sender and receiver components, communication channels, and so on). If you create a template for the communication channel at design time, this can, in turn, be used as a template for the wizard. The following requirements must be fulfilled before you can configure any of the patterns in your system: EE

The SLD content provided with this book has been imported into the SLD of your system landscape (see Chapter 6, Section 6.2, Importing the SLD Objects).

EE

The Business Systems required for configuration have been created in the SLD and imported into the Integration Directory (see Chapter 6, Section 6.3, Defining the SLD Objects).

EE

The software components provided with this book have been imported into your ESR (see Chapter 6, Section 6.4, Importing the ESR Objects).

EE

Because the Model Configurator is used to configure the pattern scenarios, each of the patterns is configured according to the same schema. The Configuration Time section in the descriptions of the patterns in Chapter 5, Enterprise Integration Patterns, contains detailed information about the objects to be used and possible parameters for Communication Channels. Any additional manual steps that may be required are also described. The next section describes each step in the configuration procedure.

4.5.1

Overview of the Configuration Scenario

To move our discussion of the step-by-step configuration procedure from the abstract to the concrete, we use the example of the Aggregator pattern by way of illustration. The Configuration Time section within Section 5.1 includes the following information:

55

175 BOOK.indb 55

10/2/08 8:55:38 AM

4

Modeling Concept

Configuration Scenario

PI_PATTERNS_EIP_AggregatorPattern

The Model Configurator facilitates the configuration process. Use the AggregatorPattern Process Integration Scenario described previously. A schematic configuration overview is provided in the graphic in this box. Templates are provided for the individual Communication Channels, which can be used in the Model Configurator. The sender services use a file adapter and access the .csv files. A single message is generated for each entry to simulate the parallelism of multiple processes. It is therefore necessary to configure the file adapter in accordance with the information provided in the tables that follow. EIP_DEV_LEGACY_3RD_001 EIP_DEV_LEGACY_3RD_002

AggregatorPatternProcess

EIP_DEV_R3E_EIP_100

The first piece of information you receive is, therefore, how to name the Configuration Scenario. This is provided for information purposes only and may differ, depending on the individual naming convention used in each case. We’ve followed the naming convention below to set up the scenarios: __Pattern

You are also told which Process Integration Scenario from the ESR should be used as a template. This scenario is explained in detail in each of the Design Time sections in Chapter 5. Furthermore, you are informed that you can use templates to create the Communication Channels in the Model Configurator. Information that is specific to each Configuration Scenario of a pattern is also supplied. In this case, for example, you learn that the file adapter will process a .csv file. Finally, an overview of the Configuration Scenario is provided in the form of a graphic. In this case, the graphic shows that the two business systems, EIP_DEV_LEGACY_3RD_001 and EIP_DEV_LEGACY_3RD_002, are used as sender systems, while the EIP_DEV_ R3E_EIP_100 business system occupies the role of the receiver system. Between these is an Integration Process called AggregatorPatternProcess. We’ve used the following naming convention for the business systems: EIP____

56

175 BOOK.indb 56

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:38 AM

Procedure at Configuration Time

4.5

The information in Table 4.1 will help you replace the placeholders. Placeholder

Value/Description

ENVIRONMENT

An abbreviation indicating the environment: DEV = Development QAS = Quality assurance PRD = Production

TYPE

System type: LEGACY = Abstract name for this project R3E = R/3 Enterprise

SID

System ID: EIP = A fictional system 3RD = For all non-SAP systems

Client Number

Client: 100 = Client 100 00n = ID for various LEGACY systems

Table 4.1  Naming Conventions

In the demo examples, the LEGACY-based systems 001 – 003 (suffix) are generally used, while the EIP_DEV_R3E_EIP_100 business system represents the ERP software component. The additional information provided in the Configuration Time sections for the individual patterns include details of how to configure the Communication Channel.

4.5.2 Model Configurator To generate a Configuration Scenario based on the Process Integration Scenario from the ESR, follow the steps below: 1. In the ID, choose Tools • Apply Model from ES Repository. 2. Select Process Integration Scenario as the ESR model type. Use the input help ((F4)) to select the relevant process integration scenario under ES Repository Model Reference(s). In our example, this is the scenario named AggregatorPattern in the urn:pi-patterns:pi:eip:common:Aggregator:100 namespace of the PI-PATTERNS_EIP COMMON 1.0 software component version (see Figure 4.9).

57

175 BOOK.indb 57

10/2/08 8:55:38 AM

4

ModelingConcept

Figure 4.9 Selecting a Process Integration Scenario

3. Click on Continue and enter the name of the relevant configuration scenario. According to the naming convention in our example, this is PI_PATTERNS_EIP_AggregatorPattern. 4. Click on Finish (see Figure 4.10). A dialog box appears that informs you that the configuration scenario has been created and that the Model Configurator has been started. Click on Close.

Figure 4.10 Creating a Configuration Scenario

58

175 BOOK.indb 58

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:39 AM

Procedure at Configuration Time

4.5

The Model Configurator then opens in a new window. Four steps are required to configure a scenario. These are shown on the navigation bar (on the right) in the Model Configurator: 1. Select Model This step is only necessary if a Process Integration Scenario contains more than one component view. If this is the case, you are instructed accordingly. 2. Assign Components In this step, you assign the relevant communication components of your system landscape to the individual application components. If an Integration Process is required, it can be created now. 3. Configure Connections Here you configure the connections between the individual actions. The necessary mappings are assigned on the basis of the Process Integration Scenario, while the necessary Communication Channels can be generated with the Model Configurator. 4. Generate Configuration Objects Finally, the required objects are generated. Optionally, you can simulate the generation process first. The steps involved in our example are as follows: 1. You don’t need to select a component view because the example contains only one view. 2. Within the Process Integration Scenario, click on the application component with the Legacy Contract System role to select it. An editing area in which you can assign the components appears below the Process Integration Scenarios. You can use the arrows to navigate to the other application components (the currently active application is highlighted). Select the first application component with the Legacy Contract System role (this appears initially), and use the input help ((F4)) to assign the EIP_DEV_LEGACY_3RD_001 business system shown in the figure for the Configuration Scenario. Click on the right arrow and assign the EIP_DEV_LEGACY_3RD_002 business system to the application component with the Legacy Confirmation System role that is now highlighted (see Figure 4.11).

59

175 BOOK.indb 59

10/2/08 8:55:39 AM

4

ModelingConcept

Figure 4.11 Assigning Services to the Application Component

3. Click on the right arrow again so that the third application component (with the Aggregation Pattern role) is highlighted. An Integration Process must now be generated before it can be assigned. You can generate the process in the Model Configurator. Simply select the dropdown input help for the Party field and select the Transfer Integration Process to Integration Directory option. A wizard starts in a new dialog box to help you generate the integration process. After the introduction, click on Continue to confirm. Enter “AggregatorPatternProcess” as the name of the Integration Process and click on Finish. Click on Close to confirm the generation. The newly generated process is then copied into the Communication Component field in the editing area (see Figure 4.12).

60

175 BOOK.indb 60

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:40 AM

ProcedureatConfigurationTime

4.5

Figure 4.12 Assigning the Integration Process

4. Click on the right arrow again so that the application component with the ERP role is highlighted. Use the input help ((F4)) to assign the EIP_DEV_R3E_ EIP_100 business system. Finally, click on Assign. The dialog box closes. 5. Select the outbound connection of the first action. An editor opens in the editing area, in which you can assign the required Communication Channels. The actions relevant for each connection are highlighted in color in the Process Integration Scenario. You can use the arrows to navigate between the individual connections. When you select the first connection, the connection between the EIP_DEV_LEGACY_3RD_001 component and the AggregationPatternProcess appears in the editing area. The Communication Channel for the EIP_DEV_ LEGACY_3RD_001 business system is not specified (see Figure 4.13).

61

175 BOOK.indb 61

10/2/08 8:55:41 AM

4

ModelingConcept

Figure 4.13 Configuring Connections

6. To create a Communication Channel, follow these steps: Select the Communication Channel field of the component for which you want to create the Communication Channel. Select the drop-down menu of the blank-page icon in the header bar of the editing area. A menu appears. Select Create Communication Channel with Template (see Figure 4.14).

Figure 4.14 Creating a Communication Channel with a Template

7. The wizard for creating Communication Channels appears. After the introduction, click on Continue to confirm. The preselected Communication Channel Template is displayed. Click on Continue to confirm the template. The communication component and the name of the communication channel are then displayed. In the Communication Channel field, delete the _TMPL suffix because this is the suffix for the template. To complete the process, click on Finish (see Figure 4.15). The wizard closes and the newly created Communication Channel is accepted. In rare instances, this may not happen, in which case you must use the input help ((F4)) to select the Communication Channel.

Figure 4.15 Creating a New Communication Channel

62

175 BOOK.indb 62

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:41 AM

ProcedureatConfigurationTime

4.5

8. Repeat this step for all other connections to create and assign the necessary Communication Channels (indicated by blank fields). 9. After you have completed the assignment of components and configuration of the connections, click on the red-and-white button at the bottom of the Model Configurator. A new dialog box opens in which you can generate the required configuration objects. Under General, select Generation. Do not change the other parameters. Then click on Start (see Figure 4.16). The configuration objects are then generated. A progress bar indicates how many objects have already been generated. Detailed information is provided in a log. Select File • Exit to discard the log or File • Save as … to save the log.

Figure 4.16 Generating the Configuration Objects

10. Finally, click on APPLY to accept the changes and exit the Model Configurator. 63

175 BOOK.indb 63

10/2/08 8:55:42 AM

4

Modeling Concept

The objects you generated are now shown within the objects of the Configuration Scenario. Before these can be activated, the Communication Channels must be fully maintained. The Configuration Time section in the descriptions of the individual patterns in Chapter 5, Enterprise Integration Patterns, provides detailed information about how to do this. Here, we explain how to configure the File_ SND_PI_PATTERNS_EIP_LEGACY_ContractSample Communication Channel of the EIP_DEV_LEGACY_3RD_001 Service. The Configuration Time section of the description of the Aggregator pattern in Section 5.1, Aggregator, provides the following adapter-specific parameters for this Communication Channel: Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

Conversion of file content

Source

File Name

01_ContractSample.csv

Processing

Quality of Service

Exactly Once

Content Conversion

Document Name

ContractSample

Document Namespace

urn:pi-patterns:pi:eip:common:Aggregator:100

Recordset Structure

Data, 1

Recordset Sequence

Ascending

Recordset per Message

1

Data.fieldSeparator *

,

Data.fieldNames *

CorrelationId, BusinessObjectId, Data1, Data2, Data3, Data4, Data5

ignoreRecordsetName *

True

Table 4.2  Adapter Configuration – Aggregation Pattern

To maintain the communication channel, follow these steps:

64

175 BOOK.indb 64

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:42 AM

ProcedureatConfigurationTime

4.5

1. Double-click to select the EIP_DEV_LEGACY_3RD_001 | File_SND_PI_PATTERNS_ EIP_LEGACY_ContractSample communication pattern in the Objects area of the Configuration Scenario you have just generated. The communication channel opens in a new window. 2. Select Communication Channel • Display/Change. Check that the entries in the Communication Channel match the values provided in Table 4.2, and change them if required. Note that environment-specific parameters, such as the source directory, must be defined according to your system environment. Parameters marked with an asterisk (*) are name/value combinations, which must be specified in the table of parameters for content conversion. Use the plus-sign icon to create new entries in this table (see Figure 4.17).

Figure 4.17 Adjusting the Parameters of a Communication Channel

3. Select Communication Channel the process.

•

Save to save your changes and complete

65

175 BOOK.indb 65

10/2/08 8:55:43 AM

4

Modeling Concept

4. Adjust the parameters of the other communication channels in accordance with the Configuration Time requirements. 5. Finally, activate the generated objects and the Communication Channels that you have maintained manually. To do this, select Change Lists • Change List of • Standard Change List • Activate in the context menu. 6. You have now finished configuring the Configuration Scenario. The next step is to make the relevant sample files available in the directory you defined in your environment to test the scenario. You are now familiar with the steps involved in modeling and know how to use the Model Configurator to simplify the configuration of enterprise integration patterns. In Chapter 5, we will examine each of the enterprise integration patterns in turn.

66

175 BOOK.indb 66

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:43 AM

5

Enterprise Integration Patterns

This chapter introduces twelve patterns that are used in day-to-day work scenarios. Which pattern you should use depends on the specific requirements of your integration scenario, which must be analyzed in detail first. In most cases, a single pattern does not provide a complete solution. Instead, a combination of patterns is usually required to successfully solve a complex problem. Not all problems can be solved by development. Often, the architecture is the key to the solution. Due to the decoupling of Design Time and Configuration Time, Configuration Time must also be explicitly incorporated into the solution. Whereas the Canonical Data Model pattern, for example, addresses issues surrounding the modeling of canonical data transformation, the Content Based Router pattern tackles the issue of what procedure to adopt at Configuration Time. On the other hand, Integration Process-based patterns (such as Aggregator or Splitter) focus on design time. The pattern names used in this chapter are taken from Gregor Hohpe and Bobby Woolf’s book entitled Enterprise Integration Patterns. We’ve adopted these names with a view to creating consistency and avoiding misunderstandings in day-to-day work on international projects. The twelve sections in this chapter are structured as follows: EE

Each section begins with a short description of the purpose of the pattern introduced. A list of related patterns is also provided.

EE

In the sections Problem, Description, and Use Case, the practical application of the pattern is explained using a tangible example at an implementationindependent level.

EE

The section SAP NetWeaver PI-Specific Implementation, discusses in concrete terms the implementation of the patterns, based on SAP NetWeaver PI 7.1. It also provides important background information relating to the implementation possibilities of the relevant pattern.

67

175 BOOK.indb 67

10/2/08 8:55:43 AM

5

Enterprise Integration Patterns

EE

A description of the actual implementation is provided in the Design Time section. A step-by step guide to implementation is not provided; instead, we describe the Process Integration Scenario and possible additional developments that are not part of the top-down approach (see Chapter 4, Section 4.4.2, TopDown Approach). By taking this approach, we hope to ensure that you will able to use an executable pattern in your system environment immediately after configuration, and that you will be able to draw your own conclusions with regard to any forthcoming integration projects in your enterprise. A step-bystep guide would fall outside of the scope of this book.

EE

The Configuration Time section provides important information about configuring the individual patterns. This section will be of particular interest to readers who want to test the pattern in their system environment. All of the patterns can be configured as described in Chapter 4, Section 4.5, Procedure at Configuration Time. Any additional information required is provided in the relevant Configuration Time section.

EE

The Runtime section refers to the required test files, and provides a short description of these.

All patterns are available for download (wherever an implementation was required) at www.sap-press.com. A detailed guide to downloading and installing the patterns is provided in Chapter 6.

5.1

Aggregator

5.1.1

Short Description

The Aggregator pattern collects and persists individual messages until a complete set of information has been received. It publishes a single message based on the information received.

5.1.2

Related Patterns

None.

5.1.3

Problem

Messages from various systems should be grouped together in a single message.

68

175 BOOK.indb 68

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:43 AM

Aggregator

5.1.4

5.1

Description

The Aggregator pattern aggregates individual but semantically related messages to create a single target message. For this purpose, the messages must be persisted and semantically correlated because they are received by the integration broker independently of one another. You also need to define how and when the collection process should end. Various strategies are available, based on the requirements of the integration scenario. The following approaches are widely known: EE

Time-based scheduling

EE

Message-based scheduling

EE

Message type-based scheduling

5.1.5

Use Case

In a heterogeneous system landscape, goods issues should be checked again existing contract volumes. A service sends contract information relating to the monitoring of goods deliveries to the information broker. The shipment of the goods is handled by another service, which generates a confirmation for each goods issue completed. The integration broker correlates the contract information with the goods issues and informs a third service about the open contract volume. This use case is shown in Figure 5.1.

Contract Contract Status Confirmation Figure 5.1  Aggregator Pattern – Use Case

5.1.6

SAP NetWeaver PI-Specific Implementation

From an SAP NetWeaver PI perspective, the Aggregator pattern requires the use of an Integration Process because messages are received independently of one

69

175 BOOK.indb 69

10/2/08 8:55:44 AM

5

Enterprise Integration Patterns

another and at different times. This means that they need to be persisted. In addition, semantic associations between messages must be ensured using a unique correlation. The Aggregator pattern can be implemented in a number of different ways, depending on the integration requirements. These approaches can be divided into the following three main groups: EE

Time-based aggregation Messages belonging to a Message Type are collected during a specific period of time. A deadline branch is used for scheduling.

EE

Message-based aggregation Messages belonging to a Message Type are collected up to a certain threshold value, which is identified using the message content. For example, this could be the number of messages to be collected, or STOP information such as the total number of messages received specified within an individual message.

EE

Message type-based aggregation Messages belonging to various Message Types are collected. Scheduling is based on the arrival of a certain message (such as a STOP message), or the successful receipt of expected messages of various types.

It is also possible to combine the properties of the Aggregator pattern belonging to these main groups. Note that all forms of the Aggregator pattern are based on the use of a correlation, to ensure the semantic dependency of messages belonging to a specific process. The implementation of the use case outlined previously is described in more detail in the sections that follow. Additional examples are provided in the Collection Patterns provided by SAP in the SAP BASIS 7.10 software component (http://sap.com/ xi/XI/System/Patterns namespace). Note The Aggregator pattern is not recommended for processing mass data. For this — if possible — a collection process should be implemented in the sending service.

70

175 BOOK.indb 70

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:44 AM

Aggregator

5.1.7

5.1

Design Time

Overview – Process Integration Scenario Process Integration Scenario

AggregationPattern

Namespace

urn:pi-patterns:pi:eip:common: Aggregator:100

Software Component

PI-PATTERNS_EIP COMMON

The use case (see Section 5.1.5) has been mapped in the system as follows (see Figure 5.2):

Figure 5.2 Aggregator Pattern – Process Integration Scenario EE

The first component — that is, the legacy contract system — sends a message of the ContractSample type, and represents the contract service.

EE

The second component — that is, the legacy confirmation system — sends a message of the ConfirmationSample type and represents the goods issue service, which sends one confirmation for each goods issue.

71

175 BOOK.indb 71

10/2/08 8:55:44 AM

5

Enterprise Integration Patterns

EE

The third component contains the Aggregator pattern, and references an Integration Process.

EE

The SAP ERP component represents an ERP service, which receives messages of the ContractStatusSample, which keeps it informed about the current volume of a contract.

Overview – Integration Process Integration Process

AggregationPattern

Namespace

urn:pi-patterns:pi:eip:common:Aggregator:100

Software Component

PI-PATTERNS_EIP COMMON

A separate process instance is opened for each message of the ContractSample type. EE

The correlation between the ContractSample message and the ConfirmationSample message is set up using the CorrelationID and ConfirmationID fields. In both messages a context object CorrelationID was assigned to these fields, based on the Service Interface. This facilitates the definition in the ccBPM (Integration Process) because complex XPath expressions are not required.

EE

The two inbound messages are transformed into one ContractStatusSample message within a multi-mapping (2:1).

The individual steps involved in the Aggregator process are as follows (see Figure 5.3): 1 Receive step for the ContractSample message and opening of the correlation 2 Extraction of the correlation ID for exception handling 3 Receive step for the corresponding ConfirmationSample message, based on the

activated correlation 4 Call of the n:1 mapping 5 Send step for the merged ConfirmationStatusSample message U A Deadline branch with generation of a transport exception (R U B ). U B Handler for the transport exception (R 5, U A ), generates an alert U C Handler for the mapping exception (R 4), generates an alert

72

175 BOOK.indb 72

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:44 AM

Aggregator

5.1

A

B

C

1

2

3

4

5

Figure 5.3  Aggregator Pattern – Integration Process

5.1.8

Configuration Time

Overview – Configuration Scenario Configuration Scenario

PI_PATTERNS_EIP_AggregatorPattern

The Model Configurator facilitates the configuration process. Use the AggregatorPattern Process Integration Scenario (described previously) as a template. A schematic overview of the configuration is provided in Figure 5.4. Templates that can be used in the Model Configurator are provided for the individual Communication Channels. The sender services use a file adapter and access the csv files. A single message is generated for each entry to simulate the parallelism of multiple processes. It is therefore necessary to configure the file adapter in accordance with the information provided in the tables that follow.

73

175 BOOK.indb 73

10/2/08 8:55:45 AM

5

Enterprise Integration Patterns

EIP_DEV_LEGACY_3RD_001 EIP_DEV_LEGACY_3RD_002

AggregatorPatternProcess

EIP_DEV_R3E_EIP_100 Figure 5.4  Aggregator Pattern – Configuration Scenario

Sender Communication Component 1 Communication Component (Business System)

EIP_DEV_LEGACY_3RD_001

Communication Channel

File_SND_PI_PATTERNS_EIP_LEGACY_ ContractSample

Table 5.1 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

Conversion of file content

Source

File Name

01_ContractSample.csv

Processing

Quality of Service

Exactly Once

Content Conversion

Document Name

ContractSample

Document Namespace

urn:pi-patterns:pi:eip:common:Aggregator:100

Recordset Structure

Data, 1

Table 5.1  Aggregator Pattern – Configuration Parameters for Sender 1

74

175 BOOK.indb 74

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:45 AM

Aggregator

5.1

Parameter Recordset Sequence

Ascending

Recordset per Message

1

Data.fieldSeparator *

,

Data.fieldNames *

CorrelationId, BusinessObjectId, Data1, Data2, Data3, Data4, Data5

ignoreRecordsetName *

True

Table 5.1  Aggregator Pattern – Configuration Parameters for Sender 1 (Cont.)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file). Parameters indicated by an asterisk (*) are name/value combinations, which must be entered manually in the content conversion table. Sender Communication Component 2 Communication Component (Business System)

EIP_DEV_LEGACY_3RD_002

Communication Channel

File_SND_PI_PATTERNS_EIP_LEGACY_ ConfirmationSample

Table 5.2 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

Conversion of file content

Source File Name

01_ConfirmationSample.csv

Processing Quality of Service

Exactly Once

Table 5.2  Aggregator Pattern – Configuration Parameters for Sender 2

75

175 BOOK.indb 75

10/2/08 8:55:46 AM

5

Enterprise Integration Patterns

Parameter Content Conversion Document Name

ConfirmationSample

Document Namespace

urn:pi-patterns:pi:eip:common:Aggregator:100

Recordset Structure

Confirmation, 1

Recordset Sequence

Ascending

Recordset per Message

1

Confirmation. fieldSeparator *

,

Confirmation. fieldNames *

ConfirmationID, ConfirmationInfo

ignoreRecordsetName *

True

Table 5.2  Aggregator Pattern – Configuration Parameters for Sender 2 (Cont.)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file). Parameters indicated by an asterisk (*) are name/value combinations, which must be entered manually in the content conversion table. Integration Process Communication Component

AggregationPatternProcess

Wizard-based generation

The aggregation pattern Integration Process can be configured (generated) using the Model Configurator. Use the AggregatorPattern process as a reference.

Receiver Communication Component Communication Component (Business System)

EIP_DEV_R3E_EIP_100

Communication Channel

File_RCV_PI_PATTERNS_EIP_ERP_ ContractStatusSample

Table 5.3 provides detailed information for specific parameters of the Communication Channel.

76

175 BOOK.indb 76

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:46 AM

Aggregator

5.1

Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name Schema

01_ContractStatusSample.xml

Processing File Generation Mode

Add time stamp

Table 5.3  Aggregator Pattern – Receiver Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory).

5.1.9

Runtime

You will find the test files for both sender Business Systems in the following directory in the download archive: Test file

01_ContractSample.csv

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_LEGACY_3RD_001

The csv test file contains five sample entries (lines). A contract message is generated for each line and sent to the Integration Server (IS). The correlation is based on the value in column A, which appears as the CorrelationID in the XML document. Test file

01_ConfirmationSample.csv

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_LEGACY_3RD_002

77

175 BOOK.indb 77

10/2/08 8:55:46 AM

5

Enterprise Integration Patterns

The csv test file contains five sample entries (lines). A confirmation message is generated for each line and sent to the Integration Server (IS). The correlation is based on the value in column A, which appears as the ConfirmationID in the XML document. Note Note that the values in both test files must contain a semantic relationship in column A. If this is not the case, they cannot be assigned correctly to the processes. The file belonging to the EIP_DEV_LEGACY_3RD_001 service must be processed first for the process instances to be created.

5.2

Canonical Data Model

5.2.1

Short Description

The Canonical Data Model pattern provides an additional indirection level between the data formats of various services.

5.2.2

Related Patterns

Message Translator (see Section 5.9).

5.2.3

Problem

In a heterogeneous system landscape, it cannot be guaranteed that existing mappings can be reused. In addition, the integration of new services is associated with very high costs.

5.2.4 Description By defining canonical data formats for business objects and interfaces — which can be used again and again by various services — you can reduce the cost of implementing new interfaces as well as the TCO for maintaining existing interfaces. In this case, the basic concept is the definition of a metadata model or the use of an industry standard as a central interface description. This means that you require only a one-off mapping of the interface structure of a sender or receiver service to the canonical data format.

78

175 BOOK.indb 78

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:46 AM

Canonical Data Model

5.2

The number of services required may vary widely, depending on the number of source and target services for the business object in question. If you have several source systems and a single target system, or several target systems and a single source system, for example, the introduction of a canonical data format seems as if it would be an oversized solution. As shown in Figure 5.5, the result would be three point-to-point mappings rather than a canonical data format used for mapping to the target structure. If an additional target system were required in this case, up to three new mappings would have to be created, depending on the number of source systems used.

Source A

Mapping

Source B

Mapping

Source C

Mapping

1:N or N:1

Target A

Figure 5.5  Canonical Data Model Pattern – Direct Mapping

Figure 5.6 shows the use of the canonical data format for the same scenario outlined in Figure 5.5. With indirect mapping using the canonical data format, you initially require four mappings to connect the three source systems to the target system. However, if you then require a connection to a new target system, the initial effort invested starts to pay off because you only require one additional mapping between the canonical format and the target format. Figure 5.7 shows another example of direct mapping in a complex environment. Here, a total of nine point-to-point mappings are required to connect three source systems with three target systems. A change to the structure of any one system requires a change to three of the mappings. Figure 5.8 shows the same scenario using the canonical data format. Now, when a change is made to any of the systems, you only need to adjust a single mapping.

79

175 BOOK.indb 79

10/2/08 8:55:46 AM

5

Enterprise Integration Patterns

This reduces the TCO because changes in a production environment minimize the effort involved in modification and regression testing.

Source A

Mapping

Source B

Mapping

Source C

Mapping

1:N or N:1

Canonical Data Model

Mapping

Target A

Figure 5.6  Canonical Data Model Pattern – Indirect Mapping

N:M Source A

Mapping

Target A

Source B

Mapping

Target B

Source C

Mapping

Target A

Figure 5.7  Canonical Data Model Pattern – Direct Mapping in a Complex Environment

N:M Source A

Mapping

Source B

Mapping

Source C

Mapping

Canonical Data Model

Mapping

Target A

Mapping

Target B

Mapping

Target C

Figure 5.8  Canonical Data Model Pattern – Indirect Mapping in a Complex Environment

80

175 BOOK.indb 80

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:47 AM

Canonical Data Model

5.2

5.2.5 Use Case Because the Canonical Data Model pattern is an abstract pattern, we will also draw on an abstract use case in this section. However, another concrete example of where this pattern could be used is an order-to-cash scenario, where orders are generated by various systems and transformed into a vendor-specific format (see Figure 5.9).

Legacy-Proprietary Data Model

ERP-Proprietary Data Model Mapping via Canonical Data Model

Figure 5.9  Canonical Data Model Pattern – Abstract Use Case

In practice, the question that is usually asked is which industry standard or which format should be used as a Canonical Data Model pattern. The answer may differ, depending on the industry and the enterprise. In addition to industry standards, SAP IDoc formats are also frequently used as a de-facto standard. This is particularly likely to be the case where a pragmatic solution is sought in an SAP-dominated landscape. The time you would need to invest in implementing a manufacturer-independent standard would be disproportionate to the additional benefit that could ultimately be derived.

5.2.6 PI-Specific Implementation The Canonical Data Model Pattern is based on the three-component strategy described in Chapter 4, Modeling Concepts. The benefits of using a Canonical Data Model pattern are the easy extensibility and enhanced maintainability of mappings. With the project-based three-component strategy, however, you run the risk of identical canonical data formats being created several times in different project-based components. To prevent this, and to provide a central area for all global objects, you should create a project-independent CANONICAL software component (and CANONICAL product). After a canonical data format is created, it can then be reused in various project-based COMMON software components. To reuse objects of the canonical software component, you must define a usage dependency (see Chapter 6, Section 6.2, Importing the SLD Objects) between the

81

175 BOOK.indb 81

10/2/08 8:55:47 AM

5

Enterprise Integration Patterns

project-based COMMON software component and the CANONICAL software component in the SLD. In Figure 5.10, the three-component strategy is enhanced with the CANONICAL software component.

Sender Product*

COMMON Product

Receiver Product*

(Non-)SAP SC

COMMON SC

(Non-)SAP SW

NameSpaces Actions Service Interfaces Message Types Data Types Context Objects Imported IDocs/RFCs Comm. Channel Template

NameSpaces Process Integration Scenarios Actions (IP) Integration Processes Operation Mappings Message Mappings

NameSpaces Actions Service Interfaces Message Types Data Types Context Objects Imported IDocs/RFCs Comm. Channel Template

(Process Integration Scenarios)

CANONICAL Product

(Process Integration Scenarios)

CANONICAL SC Name Spaces Service Interfaces Message Types Data Types Operation Mappings Message Mappings Context Objects *Sender and receiver can be exchanged.

Figure 5.10  Enhancement of the Three-Component Strategy

The organization of the individual objects must be clarified at this point. For example, where are Message Mappings stored, and how can the Canonical Data Model pattern be mapped in SAP NetWeaver PI? Before we can answer these questions, we must distinguish between two different implementation scenarios: EE

Scenarios based on Integration Processes (cross-component Business Process Management [ccBPM])

EE

Scenarios not based on Integration Processes

For an A2A or B2B scenario that is not based on an Integration Process, two mapping steps are required according to our model:

82

175 BOOK.indb 82

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:47 AM

Canonical Data Model

5.2

1. Mapping from the proprietary sender format to the canonical format 2. Mapping from the canonical format to the target structure It is not possible to call two Operation Mappings in SAP NetWeaver Process Integration 7.1. The solution is to define an Operation Mapping that references two Message Mappings, called in sequence. From the Operation Mapping perspective, a dedicated Operation Mapping is required for each sender-receiver combination, which is reminiscent of a point-to-point approach. However, this is of no consequence to us because the Operation Mapping constitutes a logical grouping of several Message Mappings in which the actual mapping is independent of the sender-receiver combination. As for the organization of individual design objects, all objects required to define the canonical Message Type are stored within the canonical software component. The main objects are as follows: EE

Message Types

EE

Data Types

EE

Data Type Extensions

EE

External Definitions

The canonical software component also contains the Message Mappings from the sender-specific Message Type to the canonical format (Message Type), and from the canonical Message Type to the receiver-specific format (Message Type). In addition, it stores the Operation Mappings, which ensures reusability and provides a central point of access. Because the canonical format (Message Type) serves as an intermediate format and is only referenced within the Message Mapping, you do not need to define a canonical Service Interface. In a scenario based on an Integration Process, an Integration Process functions as a separate system. You should therefore use the canonical data format as an interface with an Integration Process. In this case, the Integration Process works internally with canonical business objects. The sender-specific or receiver-specific data format is therefore already mapped to the canonical format outside of the Integration Process, and in this case, is represented by a conventional Operation Mapping. The Operation Mapping only contains a Message Mapping (proprietary sender format R canonical format; or, canonical format R proprietary receiver format).

83

175 BOOK.indb 83

10/2/08 8:55:48 AM

5

Enterprise Integration Patterns

In addition to the objects in the canonical software component listed previously in reference to scenarios not based on Integration Processes, the abstract Service Interface is also mapped within the canonical software component in scenarios based on Integration Processes. Note The double mapping used in scenarios not based on Integration Processes requires more resources than direct mapping. You should therefore consider using an Integration Process-based approach as an exception for interfaces with large volumes and high frequency of messages. Not all interfaces of an Integration Process are required to be in a canonical format. Non-canonical objects are therefore stored in the COMMON component as usual.

5.2.7

Design Time

Overview – Process Integration Scenario Process Integration Scenario

CanonicalDataModelPattern

Namespace

urn:pi-patterns:pi:eip:common:CanonicalDat aModel:100

Software Component

PI-PATTERNS_EIP COMMON

As already discussed in relation to the use case (see Section 5.2.5), the sample Process Integration Scenario is based on an abstract approach. In this case, a canonical data model is used to transform the proprietary sender message (LegacyProprietaryDataModel) into the receiver-specific ERPProprietaryDataModel. The legacy and ERP objects represent a real business object. The Process Integration Scenario is structured as follows (see Figure 5.11): EE

The LEGACY component sends a message of the LegacyProprietaryDataModel type.

EE

The ERP component receives a message of the ERPProprietaryDataModel type.

EE

The canonical data model is used for mapping (not shown in Figure 5.11).

The procedure for implementing the Canonical Data Model pattern in the Process Integration Scenario is not obvious, and is therefore explained in detail in this section.

84

175 BOOK.indb 84

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:48 AM

CanonicalDataModel

5.2

Figure 5.11 Canonical Data Model Pattern – Process Integration Scenario

The implementation begins with the creation of the Process Integration Scenario within the COMMON software component. The Process Integration Scenario contains the LEGACY component and ERP component, as well as their Actions (which are created automatically within the LEGACY/ERP component). In addition, the relevant Operation Interfaces are created with the corresponding Message Type and Data Type within the corresponding LEGACY and ERP component. Up to this point, the top-down approach described in Section 4.4.2 is applied. However, a different approach is used to create the mappings. The objects in the canonical data model are defined as part of the CANONICAL software component to ensure their reusability for various project-based COMMON components. Figure 5.12 shows the canonical component’s Message Type and Data Type. In addition, the Operation Mapping and the two Message Mappings are created within the CANONICAL software component. Based on the naming convention, the implemented mapping logic can be delivered (see Figure 5.13). The mapping logic between the legacy-specific Message Types (LegacyProprietaryDataModel) and the canonical format (CanonicalDataModel), and between the canonical format and the ERP Message Types (ERPProprietaryDataModel) are thus kept separate, and are maintained independently and can be referenced in additional Operation Mappings.

85

175 BOOK.indb 85

10/2/08 8:55:48 AM

5

EnterpriseIntegrationPatterns

Figure 5.12 Canonical Message Objects

Figure 5.13 Canonical Mapping Objects

5.2.8 Configuration Time Overview – Configuration Scenario Configuration Scenario

PI_PATTERNS_EIP_CanonicalDataModelPattern

The Model Configurator facilitates the configuration process. Use the CanonicalDataModelPattern Process Integration Scenario (described previously) as a template. A schematic overview of the configuration is provided in Figure 5.14. Templates that can be used in the Model Configurator are provided for the individual Communication Channel.

86

175 BOOK.indb 86

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:49 AM

Canonical Data Model

5.2

EIP_DEV_LEGACY_3RD_003 EIP_DEV_R3E_EIP_100

Figure 5.14  Canonical Data Model Pattern – Configuration Scenario

Sender Communication Component Communication Component (Business System)

EIP_DEV_LEGACY_3RD_003

Communication Channel

File_SND_PI_PATTERNS_EIP_LEGACY _LegacyProprietaryDataModel

Table 5.4 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

File

Source File Name

02_LegacyProprietaryDataModel.xml

Processing Quality of Service

Exactly Once

Table 5.4  Canonical Data Model Pattern – Sender Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file). Receiver Communication Component Communication Component (Business System)

EIP_DEV_R3E_EIP_100

Communication Channel

File_RCV_PI_PATTERNS_EIP_ERP_ ERPProprietaryDataModel

87

175 BOOK.indb 87

10/2/08 8:55:49 AM

5

Enterprise Integration Patterns

Table 5.5 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name Schema

02_ERPProprietaryDataModel.xml

Processing File Generation Mode

Add time stamp

Table 5.5  Canonical Data Model Pattern – Receiver Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory).

5.2.9 Runtime You will find the test files for the sender Business System in the following directory in the download archive: Test file

02_LegacyProprietaryDataModel.xml

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_LEGACY_3RD_003

The 02_LegacyProprietaryDataModel.xml test file contains an abstracted business object. It represents the sender-specific format, which is transformed into the receiver-specific format using a canonical format at runtime.

88

175 BOOK.indb 88

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:49 AM

Content Enricher

5.3

Content Enricher

5.3.1

Short Description

5.3

The Content Enricher pattern uses a special transformer called a content enricher to access an external data source to augment or enrich a message with additional information.

5.3.2

Related Patterns

Message Translator (see Section 5.9).

5.3.3 Problem A sender service does not provide all of the information required for processing in a receiver service.

5.3.4 Description The purpose of the Content Enricher pattern is to enrich messages with additional information. A simple example of this could be the generation of a time stamp or a GUID. The additional information is usually read from external data sources. The external data source is called synchronously, with information from the message that is to be enriched serving as key values. The information used to retrieve the external values may be a single value (such as a customer number) or a combination of several keys (for example, plant and number range).

5.3.5 Use Case We will use an abstract example to illustrate how the Content Enricher pattern is used. Information about a truck driver is provided by a LEGACY system and transferred to an ERP system. To uniquely identify the driver information in the target system, a lookup against an external data source is required to add the essential information to the original message. This use case is shown in Figure 5.15.

Driver Master Data

Driver Master Data (Enriched)

Figure 5.15  Content Enricher Pattern – Use Case

89

175 BOOK.indb 89

10/2/08 8:55:49 AM

5

Enterprise Integration Patterns

5.3.6 SAP NetWeaver PI-Specific Implementation When we speak of enrichment, we are referring to a data lookup against an external data source for the purpose of retrieving information. If the information contained in a message is not sufficient to meet the receiver’s information requirement, additional information must be retrieved. SAP NetWeaver PI lets you do this using either a standard function or by connecting to external data sources. To select the correct data lookup option, you have to balance a trade-off between complexity, flexibility, and long-term maintainability. In many cases, existing datasets must also be taken into account. It may be tempting to use fixed-value mapping due to its simplicity. However, the lack of maintainability seriously limits its usability. If you use local mapping tables, flexible access is a given but special UIs, role concepts, cache mechanisms etc. must be implemented to make this a maintainable solution. The options discussed in the text that follows are all readily available in day-today project work and must be evaluated on the basis of an integration scenario’s specific requirements. Fixed-Value Mapping Fixed-value mapping represents the simplest form of value mapping. It is based on key-value pairs, which means that each key value is paired with a target value. This function is offered as standard within graphical mapping and is referred to as hard-coded mapping because the value pairs are hard-wired into the source code. This approach is particularly suitable for mapping values that are not subject to change. If you make a change to a value mapping, you will also have to change the graphical mapping and transport the changed mapping into the production system. PI Value Mapping A more flexible solution is offered by PI value mapping, which is supported by standard functions in graphical mapping. Based on a combination of agency, scheme, and value information (that is, a key based on the combination of an agency, a

90

175 BOOK.indb 90

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:49 AM

Content Enricher

5.3

scheme, and a value), source and target values are defined at design time as part of graphical mapping. At Configuration Time, the source and target values are then configured with real values, and are executed at Runtime. A sample application of this solution is discussed in Section 5.6, Dynamic Router, where PI value mapping is used to determine the receiver of a message. In practice, PI value mapping has limited application. For example, it does not allow for 1:n mappings, and access to the Integration Directory (ID) is required for maintenance. However, it can be an option if the responsibility for maintenance lies with the PI teams/Integration Competence Center (ICC). Local Mapping Tables Local mapping tables are particularly useful if no global data client exists (see next paragraph) and if the options mentioned previously are insufficient. In general, a decision must be made in favor of either ABAP or JEE because different database schemas are used in each case. This decision is based on an analysis of the existing level of expertise and available resources because, in addition to the tables themselves, maintenance UIs — and possibly also input help tables — must be implemented. SAP NetWeaver PI offers standard functions for lookups of external data sources based on RFC, SOAP, or Java Database Connectivity (JDBC). Global Data Client The term global data client refers to a system that provides the mapping information required for lookups, and which is already considered a key component of the enterprise’s application landscape. This is often a master data management (MDM) system that is responsible for mapping between LEGACY and standard systems. In most cases database schemas, maintenance UIs, workflows for changing information, role concepts, and so on are already in place. However, a connection is still required. As with the local mapping tables described previously, SAP NetWeaver PI offers a connection to RFC, SOAP, and JDBC data sources as a standard function. However, experience shows that the standard functions may not be sufficient for performance reasons, in particular when it comes to integration scenarios that are intensive in terms of data lookups. In this case, the mapping tables can be connected by JDBC, and the processing logic (including

91

175 BOOK.indb 91

10/2/08 8:55:50 AM

5

Enterprise Integration Patterns

connection pooling via DataSource) can be moved to the JEE server. Performance is also improved thanks to the caching of mapping tables. Within the PI mapping (in this case, Java mapping), only methods that execute the code on the JEE server are used. Unified Key Mapping Service (UKMS) The Unified Key Mapping Service (UKMS) is a key mapping service from the SAP standard system, and was delivered for the first time with SAP NetWeaver 7.0. The Key Mapping Service architecture, which is based on the ABAP stack, offers several encapsulation layers to ensure that keys from various environments can be reused. RFC access is provided in addition to an ABAP-OO interface. A Java API, which can be used in an XSLT include or Java-based mapping, is also supplied. Figure 5.16 provides a graphical representation of the encapsulation layers.

XSLT Includes Java API RFC Function Modules ABAP-OO Interface

UKM Engine DB

Figure 5.16  UKMS Encapsulation Layers (Source: SAP AG)

92

175 BOOK.indb 92

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:50 AM

Content Enricher

5.3

The UKMS offers the following scope of functions (source: SAP AG, http://help. sap.com/saphelp_nwpi71/helpdata/en/43/d4ced6ea780cd4e10000000a1553f7/frame set.htm): EE

UKMS offers a simple ABAP-OO interface that supports reading, writing, deleting, and saving mappings as well as their clean-up. There are also wrappers in the form of RFC-enabled function modules for reading, writing, and deleting mappings.

EE

PI Operation Mappings (XSLT transformations) can access mappings of the UKMS using a Java API. The Java API is stored in SAP Basis as SAP NetWeaver PI content.

EE

A mapping consists of pairs of keys that are stored in the database as a grouped mapping of objects. This means that more than two keys are supported for each mapping group.

EE

UKMS fully supports the Core Component Type Identifier for identifying keys.

EE

UKMS supports transactional behavior and transaction-dependent buffering.

EE

All interfaces are mass-enabled.

EE

UKMS does not need any customizing.

EE

If there are multiple mapping objects in a system, you can designate one object as the client default.

EE

UKMS can manage multiple independent mapping instances to support an intentional separation. For example, you may want a separate instance for each master data object type (business partner, product master). A mapping instance is identified by the mapping context. Each mapping context has its own set of database tables. Approximately 1.5 million different mapping contexts are supported.

UKMS key mapping is based on the following concept: An object, for example, the truck driver ID from our use case, may be represented differently in various systems and components (SAP, LEGACY system, etc.). Key mapping (which in this case is synonymous with ID mapping) is required because a unified view is lacking. A set of attributes is required in addition to the key value, to identify and define the object within a certain context (system or component). The Core Component Type Identifier (CCTI) (CCT:Identifier), which is structured as shown in Table 5.6, is used for this purpose.

93

175 BOOK.indb 93

10/2/08 8:55:50 AM

5

Enterprise Integration Patterns

Name

Type

Description

Identifier

Element

Object ID

schemeID

Optional attribute

Identification scheme of the identifier

schemeVersionID

Optional attribute

Version of the identification scheme

schemeAgencyID

Optional attribute

ID of the agency that manages the identification scheme of the identifier

schemeAgencySchemeID

Optional attribute

Identification scheme of the agency

schemeAgencySchemeAgencyID

Optional attribute

ID of the agency (from DE3055) that manages the identification scheme of the agency

Table 5.6  Structure of the Core Component Type Identifier (CCTI)

If we apply the CCT:Identifier concept to the area of process integration, the schemeID attribute provides information about the object type; schemeAgenyID represents the Business System (without the system environment), and schemeAgencySchemeAgencyID has the default value ZZZ, provided that it is a proprietary identification (that is, no official code list, such as DUNS, is used). By way of example, the following listing shows the driver ID in various contexts as a representation in XML:        123456789           987654321   

94

175 BOOK.indb 94

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:50 AM

ContentEnricher

5.3

UKMS does not currently offer user-friendly UIs, workflow concepts, or standard validation logic. In customer projects, a portal-based UI with validation logic has therefore proven useful. Practically speaking, the UKMS-based solution is still a very new approach. We will therefore use it to demonstrate external data enrichment with the Content Enricher pattern.

5.3.7 Design time Overview – Process Integration Scenario Process Integration Scenario

ContentEnricherPattern

Namespace

urn:pi-patterns:pi:eip:common:ContentEnric her:100

Software Component

PI-PATTERNS_EIP COMMON

The sender system from the use case (see Section 5.3.5) is represented in the Process Integration Scenario by the LEGACY component, and it sends a DriverMasterData message. The receiver system is represented by the ERP component, and it receives a message of the DriverMasterData type. The UKMS lookup function — explained in more detail in the text that follows — is executed in the Message Mapping. The Process Integration Scenario is shown in Figure 5.17.

Figure 5.17 Content Enricher Pattern – Process Integration Scenario

95

175 BOOK.indb 95

10/2/08 8:55:50 AM

5

Enterprise Integration Patterns

Operation Mapping The Content Enricher pattern is implemented in the following Operation Mapping: Operation Mapping

DriverMasterData_OB_TO_DriverMasterData_IB

Namespace

urn:pi-patterns:pi:eip:common:ContentEnricher:100

Software Component

PI-PATTERNS_EIP COMMON

The Operation Mapping contains the following graphical Message Mapping: Message Mapping

DriverMasterData_TO_DriverMasterData

Namespace

urn:pi-patterns:pi:eip:common:ContentEnricher:100

Software Component

PI-PATTERNS_EIP COMMON

The structure mapping of the source structure to the target structure is executed within the Message Mapping, as is the UKMS lookup function for the SAPDriverID target field, with the LegacyDriverID field in the source structure serving as the key value. To allow the user-defined function to be reused for further UKMS lookups, we have defined the parameters required for the UKMS lookup as inbound parameters of the user-defined function. The value assignment builds on the parameterized mapping programs function that was introduced with SAP NetWeaver PI 7.1, and enables flexible assignment of values at Configuration Time. The lookup uses the UKMService user-defined function. Within this function, the UKMS classes provided by SAP BASIS software component are used to execute the lookup via UKMS. To provide detailed information, we have added comments to the source code in our example. The target field mapping is shown in Figure 5.18.

96

175 BOOK.indb 96

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:50 AM

ContentEnricher

5.3

Figure 5.18 Content Enricher Pattern – Lookup Mapping

The parameters shown in Table 5.7 are passed to the user-defined function: Parameter

Description

MAIN_CONTEXT_ID

UKM main context

SOURCE_SCHEME_ID

Identification scheme of the source identifier

SOURCE_SCHEME_AGENCY_ID

ID of the source agency that manages the identification scheme of the identifier

TARGET_SCHEME_ID

Identification scheme of the target identifier

TARGET_SCHEME_AGENCY_ID

ID of the target agency that manages the identification scheme of the identifier

Table 5.7 Parameters of the User-Defined Function

97

175 BOOK.indb 97

10/2/08 8:55:51 AM

5

Enterprise Integration Patterns

The parameters in Table 5.7 are defined in both the Message Mapping and the Operation Mapping, and are linked by a 1:1 binding. They are defined within the Interface Determination at Configuration Time. In the example shown, the SOURCE_SCHEME_AGENCY_ID and TARGET_SCHEME_AGENCY_ID parameters are defined using external parameters to ensure greater testability of the pattern. These parameters would normally be defined as a constant within the relevant target field mapping. Note At the time this book was going to print, the Java classes of the SAP UKMS were not available in the components of SAP BASIS 7.1. It was therefore necessary to define a usage dependency (see Section 6.2.2) on the components of SAP BASIS 7.0. Refer to the latest information on the book’s website (www.sap-press.com).

5.3.8 Configuration Time Overview – Configuration Scenario Configuration Scenario

PI_PATTERNS_EIP_ContentEnricherPattern

The Model Configurator facilitates the configuration process. Use the ContentEnricherPattern Process Integration Scenario as a template. A schematic overview of the configuration is provided in Figure 5.19. Templates that can be used in the Model Configurator are provided for the individual Communication Channel. The EIP_DEV_LEGACY_3RD_003 system sends the DriverMasterData message to the EIP_DEV_R3E_EIP_100 system. The lookup function is executed within the Operation Mapping. Because the Process Integration Scenario is used as a template for configuration, the necessary Operation Mapping is automatically assigned to the Interface Determination. EIP_DEV_LEGACY_3RD_003 EIP_DEV_R3E_EIP_100 Figure 5.19  Content Enricher Pattern – Configuration Scenario

98

175 BOOK.indb 98

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:51 AM

Content Enricher

5.3

Sender Communication Component Communication Component (Business System)

EIP_DEV_LEGACY_3RD_003

Communication Channel

File_SND_PI_PATTERNS_EIP_LEGACY_ DriverMasterData

Table 5.8 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

File

Source File Name

03_DriverMasterData.xml

Processing Quality of Service

Exactly Once

Table 5.8  Content Enricher Pattern – Sender Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file). Receiver Communication Component Communication Component (Business System)

EIP_DEV_R3E_EIP_100

Communication Channel

File_RCV_PI_PATTERNS_EIP_ERP_ DriverMasterData

Table 5.9 provides detailed information for specific parameters of the Communication Channel.

99

175 BOOK.indb 99

10/2/08 8:55:52 AM

5

Enterprise Integration Patterns

Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name Schema

03_ExchangeRatesEnriched.xml

Processing File Generation Mode

Add time stamp

Table 5.9  Content Enricher Pattern – Receiver Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory). Interface Determination Communication Component (Business System)

EIP_DEV_LEGACY_3RD_003

Interface

DriverMasterData_OB

Namespace

urn:pi-patterns:pi:eip:legacy:ContentEnri cher:100

The UKMS parameters required for the user-defined function are assigned to the Operation Mapping within the Interface Determination (see Table 5.10). Use the valid UKMS mapping context ID in your system environment as the MAIN_CONTEXT_ID. Configuration of the UKMS mapping is described later. Parameters for Operation Mapping

Values According to UKMS Mapping Examples

MAIN_CONTEXT_ID

SOURCE_SCHEME_AGENCY_ID

EIP_LEGACY_3RD_003

Table 5.10  Content Enricher Pattern – Parameters of the Interface Determination

100

175 BOOK.indb 100

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:52 AM

Content Enricher

Parameters for Operation Mapping

Values According to UKMS Mapping Examples

SOURCE_SCHEME_ID

DRIVERMASTER_LEGACY_ID

TARGET_SCHEME_AGENCY_ID

EIP_R3E_EIP_100

TARGET_SCHEME_ID

DRIVERMASTER_SAP_ID

5.3

Table 5.10  Content Enricher Pattern – Parameters of the Interface Determination (Cont.)

UKMS Service An RFC connection must also be configured to connect the UKMS system (for example, the ABAP stack of the SAP NetWeaver PI 7.1 system). Communication Component (Business Component)

LookupService

Communication Channel

RFC_RCV_LookupService

Note The name of the Communication Channel is specified in the user-defined function and can be changed if required.

Table 5.11 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

RFC Receiver

Transport Protocol

RFC

Message Protocol

RFC (XML)

Target RFC server type

SAP system

Authentication mode

Use logon data for the SAP system

Table 5.11  Content Enricher Pattern – Lookup Service Configuration Parameters

101

175 BOOK.indb 101

10/2/08 8:55:52 AM

5

Enterprise Integration Patterns

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, application server, system ID etc.). UKMS Mappings Before you can create ID mappings within the UKMS, you must configure a mapping context. You can do this in the Define Mapping Contexts IMG activity (refer to the Implementation Guide under SAP NetWeaver • Application Server • Basis Services • Unified Key Mapping Service (UKMS) • Define Mapping Contexts). The identification mapping context is specified when creating and reading mapping information. You can then use the UKM_ADD_KEY_MAPPINGS function module to create ID mappings. Alternatively, these can be read with UKM_GET_KEY_MAPPINGS, or deleted with UKM_DELETE_KEY_MAPPING. For more detailed information, which falls outside the scope of this book, refer to the SAP Help Portal under Unified Key Mapping Service.

5.3.9 Runtime You will find the test file for the sender services in the following directory in the download archive: Test file

03_DriverMasterData.xml

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_LEGACY_3RD_003

The lookup function is based on the LegacyDriverID field, and it determines the relevant SAPDriverID in the target structure. Modify this field in accordance with the ID mapping you have maintained.

102

175 BOOK.indb 102

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:52 AM

Content Filter

5.4

Content Filter

5.4.1

Short Description

5.4

The Content Filter pattern removes unnecessary information from a message.

5.4.2 Related Patterns Message Translator (see Section 5.9).

5.4.3 Problem You do no not want a receiver service to receive all information sent by a sender service. Instead, you want portions of the message to be filtered. This requirement may exist for business or technical reasons. Business-wise, for example, information held by the HR department about a certain employee may be required for a certain service, whereas another receiver should have only limited access to the same information. From a technical standpoint, filtering information is particularly useful to reduce the volume of messages and also contributes to simplified monitoring.

5.4.4 Description The objective of the Content Filter is reducing the information in a message in accordance with the information required by the receiver. The filter criteria may be defined statically or dynamically. The dynamic variant provides greater flexibility by using a filter table. In this case, key values are read from the message at runtime and are used to call a filter table (see Section 5.3, Content Enricher). The information retrieved then forms the filter criteria, which serve as input for the filter logic.

5.4.5 Use Case In a distribution scenario involving exchange rates each individual receiver service does not need to receive all information, and only the information relevant for each target system should be transferred. If this is not a requirement, and if data throughput is not a consideration, the complete dataset may

103

175 BOOK.indb 103

10/2/08 8:55:52 AM

5

Enterprise Integration Patterns

also be sent. In this case, it is the role of the receiver to process the relevant information. We will take the filtering of exchange rates as a use case for the Content Filter pattern. For example, daily exchange rates (based, for example, on Bloomberg or Reuters) are provided by a LEGACY system. In addition to calculating the daily exchange rate (standard exchange at the median rate), this system also stores weekly or monthly average values. A combination of various currencies and exchange rate types results in large data volume (in practice, we‘ve seen exchange rate data reaching volumes of 4 MB), and it proves very useful to transfer only relevant data to a target system. Our use case therefore provides for the filtering of daily exchange rates. An overview is provided in Figure 5.20. Additional target systems may be subject to different conditions. However, our use case explicitly excludes the distribution of exchange rates because the focus is strictly on the filter function.

Exchange Rates

Exchange Rates (Daily Exchange Rates)

Figure 5.20  Content Filter Pattern – Use Case

5.4.6 SAP NetWeaver PI-Specific Implementation Preferably, information is filtered within an Operation Mapping that is decoupled from any structure mapping that may exist. This approach reduces complexity and enhances the reusability of filter and structure mappings. On the other hand, resource consumption increases because two mappings are executed in sequence. Our selection of a mapping technology is based on a bestof-breed approach (see Section 5.9, Message Translator), involving an XSLT mapping used as a filter function and a graphical mapping used as a structure mapping. The XSLT language allows you to fulfill complex filtering requirements. If you do not currently have the requisite level of expertise in this area, you should still consider using this mapping technology. This is because it will be worth putting the effort into an initial intensive training period to gain access to the significant functional possibilities you could create with just a few lines of XSL code.

104

175 BOOK.indb 104

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:52 AM

ContentFilter

5.4

5.4.7 Design Time Overview – Process Integration Scenario Process Integration Scenario

ContentFilterPattern

Namespace

urn:pi-patterns:pi:eip:common:ContentFilter:100

Software Component

PI-PATTERNS_EIP COMMON

The sender system from the use case is represented in the Process Integration Scenario by the LEGACY component, and it sends an ExchangeRates message. The receiver system is represented by the ERP component, and it receives a message of the ExchangeRates type. The filter function is executed in the Operation Mapping. This is discussed in greater detail in the Operation Mapping section. The Process Integration Scenario is shown in Figure 5.21.

Figure 5.21 Content Filter Pattern – Process Integration Scenario

Operation Mapping The Content Filter pattern is implemented in the following Operation Mapping:

105

175 BOOK.indb 105

10/2/08 8:55:53 AM

5

EnterpriseIntegrationPatterns

Name

ExchangeRate_OB_TO_ExchangeRate_IB

Namespace

urn:pi-patterns:pi:eip:common:ContentFilter:100

Software Component

PI-PATTERNS_EIP COMMON

The Operation Mapping contains two mapping programs: 1. The XSL-based DailyRateFilter mapping, which contains the actual filter function. 2. A graphical Message Mapping, which provides for the transformation of the source structure into the target structure, and which uses the filtered information as input. In this case, the structure mapping maps a proprietary structure to the TCURR_01 IDoc structure. The separation of the filter mapping logic and structure mapping logic enables more flexible handling of the mapping objects. If, for example, you need to supply another system with daily exchange rates, you only need to implement a new structure mapping to suit the target structure of the additional system. The filter mapping could thus be reused. Figure 5.22 shows the Operation Mapping, together with the mapping programs it contains.

Figure 5.22 Content Filter Pattern – Filter Operation Mapping

XSL Mapping Name

DailyRateFilter

Imported archive

PI-PATTERNS ContentFilterPattern

106

175 BOOK.indb 106

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:53 AM

Content Filter

Namespace

urn:pi-patterns:pi:eip:common:ContentFilter:100

Software Component

PI-PATTERNS_EIP COMMON

5.4

To fully explain the XSL filter function, we must examine the source structure of the LEGACY system in more detail. It contains individual exchange rates, structured as follows:

  01   CHF   EUR   BOOK   01032008   120000   0.620922   1   1

In addition to the currency types (CurrencyFrom, CurrencyTo), the currency conversion units (CurrencyFromUnit, CurrencyToUnit), time reference (ReportingDate, ReportingTime), exchange rate (ExchangeRate), and exchange rate type (Type) are described, among other information. The XSL mapping provides a filter function based on the M exchange rate type of the standard conversion at the median rate. The XSL stylesheet therefore contains a copy function for the complete XML document, which uses a check routine for the value M in the Type field of the row structure. The normalize-space statement serves only to identify any unwanted blank spaces (see Figure 5.23).











Copy Function for XML Document

Filter Function Based on Field “Type”

Figure 5.23  Content Filter Pattern – Filter Mapping

107

175 BOOK.indb 107

10/2/08 8:55:54 AM

5

Enterprise Integration Patterns

5.4.8 Configuration Time Overview – Configuration Scenario Configuration Scenario

PI_PATTERNS_EIP_ContentFilterPattern

The Model Configurator facilitates the configuration process. Use the ContentFilterPattern Process Integration Scenario (described previously) as a template. A schematic overview of the configuration is provided in Figure 5.24. EIP_DEV_LEGACY_3RD_002 EIP_DEV_R3E_EIP_100

Figure 5.24  Content Filter Pattern – Configuration Scenario

Templates that can be used in the Model Configurator are provided for the individual Communication Channel. The EIP_DEV_LEGACY_3RD_002 system sends the ExchangeRateData message to the EIP_DEV_R3E_EIP_100 system. The filter function is executed within the Operation Mapping. Because the Process Integration Scenario is used as a template for configuration, the necessary Operation Mapping is automatically assigned to the Interface Determination. Sender Communication Component Communication Component (Business System)

EIP_DEV_LEGACY_3RD_002

Communication Channel

File_SND_PI_PATTERNS_EIP_LEGACY_ ExchangeRates

Table 5.12 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Sender

Table 5.12  Content Filter Pattern – Sender Configuration Parameters

108

175 BOOK.indb 108

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:54 AM

Content Filter

5.4

Parameter Transport Protocol

File system (NFS)

Message Protocol

File

Source File Name

04_ExchangeRates.xml

Processing Quality of Service

Exactly Once

Table 5.12  Content Filter Pattern – Sender Configuration Parameters (Cont.)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file). Receiver Communication Component Communication Component (Business System)

EIP_DEV_R3E_EIP_100

Communication Channel

File_RCV_PI_PATTERNS_EIP_ERP_ExchangeRates

Table 5.13 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name Schema

04_ExchangeRatesFiltered.xml

Processing File Generation Mode

Add time stamp

Table 5.13  Content Filter Pattern – Receiver Configuration Parameters

109

175 BOOK.indb 109

10/2/08 8:55:54 AM

5

Enterprise Integration Patterns

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory).

5.4.9 Runtime You will find the test file for the sender services in the following directory in the download archive: Test file

04_ExchangeRates.xml

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_LEGACY_3RD_002

The filter function is based on the Type field of the row structure. Only exchange rates with type “M” are transferred to the target system. To test system behavior, modify the Type field according to your specific requirements.

5.5

Content Based Router

5.5.1

Short Description

The Content Based Router pattern is used to determine the message receiver, based on the message content.

5.5.2 Related Patterns Dynamic Router (see Section 5.6); Splitter (see Section 5.12).

5.5.3 Problem The receiver of a message cannot be determined from the Message Type alone. The message content is also relevant for identifying the receiver.

5.5.4 Description The Content Based Router pattern is a basic integration pattern that can be used to determine the receiver of a message, based on the message content. The con-

110

175 BOOK.indb 110

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:54 AM

Content Based Router

5.5

tent may be key values (for example, plant number), or specific number ranges. A combination of several values is another possibility. Using special routing conditions, you define conditions for the individual receivers. The defined rules of the Content Based Router pattern are static and are applied to the content of a message at runtime. It is assumed that the value of a rule will not change for the foreseeable future — in other words, the rule will remain valid long term. If this is not the case, a dynamic approach should be used instead (see Section 5.6, Dynamic Router). Depending on the definition of the routing conditions, several receivers may be defined for a single message. In this case, the message is duplicated and sent, with the same structure, to the receivers that have been identified. This logic corresponds to how the Splitter pattern functions, as described in Section 5.12. In a content-based router, however, messages are duplicated as messages rather than being put together from fragmented information in new Message Types, as is the case in the Splitter pattern.

5.5.5 Use Case Because the Content Based Router pattern is a basic integration pattern, a whole range of use cases is conceivable. One example is sending purchase orders from an SRM system to a supplier, where the supplier is determined by the supplier number on the order. In master data distribution scenarios, a material master record may be sent to the relevant system, based on the plant ID, for example. Figure 5.25 shows an abstract representation of the Content Based Router pattern. Here, an inbound message from Sender 1 can be sent to various receivers (1..n).

Receiver 1 Sender 1

Receiver 2 Receiver n

Figure 5.25  Content Based Router Pattern – Use Case

111

175 BOOK.indb 111

10/2/08 8:55:55 AM

5

Enterprise Integration Patterns

5.5.6 SAP NetWeaver PI-Specific Implementation The Content Based Router pattern does not require an SAP NetWeaver PI-specific implementation because the definition of routing conditions is provided within the Receiver Determination at Configuration Time. The routing rule is defined on the basis of one or more fields in the Receiver Determination. It is applied to the content of the specific message at runtime, to identify one or more receiver services. The definition of the routing conditions is based on XPath expressions. XPath also lets you define complex rules. If the receiver is unknown or does not behave statically at Configuration Time, you should consider using the Dynamic Router pattern (see Section 5.6). Note The time you will need to spend maintaining routing conditions depends on the number of receivers and the complexity of the rules to be defined. In this case, context objects may simplify the definition of rules.

5.5.7 Design Time Overview – Process Integration Scenario Process Integration Scenario

ContentBasedRouterPattern

Namespace

urn:pi-patterns:pi: eip:common:ContentBasedRouter:100

Software Component

PI-PATTERNS_EIP COMMON

The Content Based Router pattern does not have specific implications for Design Time because the receiver system is not configured until Runtime. The sender system from the use case is represented in the Process Integration Scenario by the ERP component, and it sends a ContentBasedRouter message. The receiver systems are represented by the LEGACY component, and they receive a message of the ContentBasedRouter type. For the sake of clarity, all receiver systems in this example are based on the LEGACY component. The actual number of receivers is determined at Configuration Time. The Process Integration Scenario is shown in Figure 5.26.

112

175 BOOK.indb 112

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:55 AM

ContentBasedRouter

5.5

Figure 5.26 Content Based Router Pattern – Process Integration Scenario

5.5.8 Configuration Time Overview – Configuration Scenario Configuration Scenario

PI_PATTERNS_EIP_ContentBasedRouterPattern

The Model Configurator facilitates the configuration process. Use the ContentBasedRouterPattern Process Integration Scenario (described previously) as a template. A schematic overview of the configuration is provided in Figure 5.27.

EIP_DEV_R3E_EIP_100 EIP_DEV_LEGACY_3RD_001 EIP_DEV_LEGACY_3RD_002 EIP_DEV_LEGACY_3RD_003

Figure 5.27 Content Based Router Pattern – Configuration Scenario

113

175 BOOK.indb 113

10/2/08 8:55:55 AM

5

Enterprise Integration Patterns

Templates that can be used in the Model Configurator are provided for the individual Communication Channel. The EIP_DEV_R3E_EIP_100 system sends the ContentBasedRouter message to one or more LEGACY-based systems. The message is sent to the relevant target system, based on the routing condition. The Receiver Determination in this example is explained in detail in the next section. Sender Communication Component Communication Component (Business System)

EIP_DEV_R3E_EIP_100

Communication Channel

File_SND_PI_PATTERNS_EIP_ERP_ContentBasedRouter

Table 5.14 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

File

Source File Name

05_ContentBasedRouter.xml

Processing Quality of Service

Exactly Once

Table 5.14  Content Based Router Pattern – Sender Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file).

114

175 BOOK.indb 114

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:55 AM

Content Based Router

5.5

Receiver Communication Component 1 Communication Component (Business System)

EIP_DEV_LEGACY_3RD_001

Communication Channel

File_RCV_PI_PATTERNS_EIP_LEGACY_ ContentBasedRouter

Table 5.15 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name Schema

05_ContentBasedRouter_LEGACY_3RD_001.xml

Processing File Generation Mode

Add time stamp

Table 5.15  Content Based Router Pattern – Receiver 1 Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file). Receiver Communication Component 2 Communication Component (Business System)

EIP_DEV_LEGACY_3RD_002

Communication Channel

File_RCV_PI_PATTERNS_EIP_LEGACY_ ContentBasedRouter

Table 5.16 provides detailed information for specific parameters of the Communication Channel.

115

175 BOOK.indb 115

10/2/08 8:55:55 AM

5

Enterprise Integration Patterns

Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name Schema

05_ContentBasedRouter_LEGACY_3RD_002.xml

Processing File Generation Mode

Add time stamp

Table 5.16  Content Based Router Pattern – Receiver 2 Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory). Receiver Communication Component 3 Communication Component (Business System)

EIP_DEV_LEGACY_3RD_003

Communication Channel

File_RCV_PI_PATTERNS_EIP_LEGACY_ ContentBasedRouter

Table 5.17 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name Schema

05_ContentBasedRouter_LEGACY_3RD_003.xml

Table 5.17  Content Based Router Pattern – Receiver 3 Configuration Parameters

116

175 BOOK.indb 116

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:56 AM

Content Based Router

5.5

Parameter Processing File Generation Mode

Add time stamp

Table 5.17  Content Based Router Pattern – Receiver 3 Configuration Parameters (Cont.)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory). In a subsequent step, the generated Receiver Determination must be enhanced manually with the routing conditions. Two examples of conditions for the Receiver Determination are provided in the text that follows. In this case, a complex XPath expression is used in addition to a simple condition. Receiver Determination Service

EIP_DEV_R3E_EIP_100

Interface

ContentBasedRouter_OB

Namespace

urn:pi-patterns:pi:eip:erp:ContentBasedRouter:100

The message should be sent to the EIP_DEV_LEGACY_3RD_001 service if the value in the Plant field in the message header contains the value 4711. Operand

Value

Left operand

/p1:ContentBasedRouter/Header/Plant

Middle operand

=

Right operand

4711

Table 5.18  Simple Routing Condition

The message should be sent to the EIP_DEV_LEGACY_3RD_002 service if the value in the NumberRange field in the message header contains the interval 200,000 – 299,999.

117

175 BOOK.indb 117

10/2/08 8:55:56 AM

5

Enterprise Integration Patterns

Operand

Value

Left operand

/p1:ContentBasedRouter[substring(/ p1:ContentBasedRouter/Header/NumberRange,1,1)=’2’]

Middle operand

EX

Right operand

Not required.

Table 5.19  Simple Routing Condition

We will use a little trick to define this routing condition. Based on the XPath substring function, we will read the first character in the NumberRange field and check whether this is equal to 2 (that is, whether it is a value in the range 200,000 – 299,999). As you can see, the XPath language offers a wide range of options for definition routing conditions. Formulate your own rule and define it for the EIP_DEV_ LEGACY_3RD_003 service.

5.5.9 Runtime You will find the test file for the sender services in the following directory in the download archive: Test file

05_ContentBasedRouter.xml

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_R3E_EIP_100

In our example, we used the Plant and NumberRange fields in the message header structure. To test system behavior, modify these according to your specific requirements.

5.6

Dynamic Router

5.6.1

Short Description

The Dynamic Router pattern dynamically controls the sending of messages at Runtime.

118

175 BOOK.indb 118

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:56 AM

Dynamic Router

5.6

5.6.2 Related Patterns Content Based Router (see Section 5.5).

5.6.3 Problem The receiver of a message cannot be determined from the Message Type alone; the message content is also relevant. In addition, receivers cannot be statically defined because they change periodically.

5.6.4 Description The Dynamic Router pattern is an advanced approach to routing, and provides an alternative to the Content Based Routing pattern described in Section 5.5. Whereas the Content Based Routing pattern defines receivers based on static routing conditions, the Dynamic Routing pattern determines message receivers using external data sources or through a recipient list that is part of the message. In both cases, the data basis is subject to change. In other words, the recipient list contains a varying number of target systems or a key value that enables conversion into a specific target system. Alternatively, the receiver systems returned by the external data source change over time. The external data source may be a simple lookup table or a more complex data service that identifies the receiver based on several key values. In both cases, the data is stored in a persistent status and can also be maintained. Note In a broader sense, the Dynamic Router pattern can also be used as a publish and subscribe solution. Receiver services that want to subscribe to messages can register with the external data source (by sending a subscribe/unsubscribe message).

5.6.5 Use Case As with the Content Based Router pattern described earlier, a master data distribution scenario can be taken as our use case for this pattern. In this case, new systems that should receive certain master data objects can be registered dynamically. It is also possible for systems to automatically subscribe to or unsubscribe from the external data source or service.

119

175 BOOK.indb 119

10/2/08 8:55:56 AM

5

EnterpriseIntegrationPatterns

An abstract representation of the Dynamic Router pattern is provided in Figure 5.28. An inbound message from sender 1 can be sent to various receivers (1..n). The information is determined on the basis of key values.

Receiver 1 Receiver 2

Sender 1

Receiver n Figure 5.28 Dynamic Router Pattern – Use Case

5.6.6 SAP NetWeaver PI-Specific Implementation The implementation of the Dynamic Router pattern is based on an Operation Mapping, which is developed at Design Time and assigned to a Receiver Determination at Configuration Time. The inbound message of the operation is the actual message that should be sent because key values must be read from the message content. The target structure must comply with a predefined convention so that the IS can process the information accordingly. The target structure is based on the following ReceiverDetermination Service Interface and is structured as shown in Figure 5.29: Name

ReceiverDetermination

Namespace

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

Software Component version

SAP BASIS 7.10

Figure 5.29 Target Structure – Dynamic Routing

120

175 BOOK.indb 120

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:57 AM

Dynamic Router

5.6

Depending on the configuration scenario (A2A or B2B), the Receiver Determination may be based on a Service (or Services) or on a combination of Parties and Services. Development of the Operation Mapping is no different from the creation of “normal” mappings. The Operation Mapping usually contains a lookup for a mapping table, an external data source, or a service that determines the receiving systems at runtime. Decoding values in conjunction with using recipient lists is also conceivable. Note Because the receiving systems are identified at runtime and may change dynamically over time, monitoring is more complex with the Dynamic Router pattern than it is the case with the static approach used in the Content Based Router pattern.

5.6.7 Design Time Overview – Process Integration Scenario Process Integration Scenario

DynamicRouterPattern

Namespace

urn:pi-patterns:pi:eip:common:DynamicRouter:100

Software Component

PI-PATTERNS_EIP COMMON

The sender system from the use case is represented in the Process Integration Scenario by the ERP component, and it sends a DynamicRouter message. The receiver systems are represented by the LEGACY component, and they receive a message of the DynamicRouter type. For the sake of clarity, all receiver systems in this example are based on the LEGACY component. The actual number of receivers is determined at Runtime. The Operation Mapping for the dynamic identification of the receiver services cannot be referenced within the Process Integration Scenario. The Process Integration Scenario is shown in Figure 5.30.

121

175 BOOK.indb 121

10/2/08 8:55:57 AM

5

EnterpriseIntegrationPatterns

Figure 5.30 Dynamic Router Pattern – Process Integration Scenario

The Operation Mapping must be created in the ESR at Design Time, together with the corresponding Message Mapping. We created the following objects to demonstrate the Dynamic Router pattern: Operation Mapping Name

DynamicRouter_OB_TO_ReceiverDetermination

Namespace

urn:pi-patterns:pi:eip:common:DynamicRouter:100

Software Component

PI-PATTERNS_EIP COMMON

The Operation Mapping contains the DynamicRouter_OB Service Interface as an inbound message, which represents the message from the ERP system. The ReceiverDetermination Service Interface of the SAP Basis component (see Section 5.6.6, SAP NetWeaver PI-Specific Implementation) must be used as the target message to enable processing of the dynamically determined receivers. The receivers are determined within the Message Mapping, which contains the relevant Message Types of the Service Interface.

122

175 BOOK.indb 122

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:57 AM

DynamicRouter

5.6

Message Mapping Name

DynamicRouter_TO_ReceiverDetermination

Namespace

urn:pi-patterns:pi:eip:common:DynamicRouter:100

Software Component

PI-PATTERNS_EIP COMMON

To minimize the effort involved in configuring the Dynamic Router pattern for the purposes of demonstration, we will not use an external data source in our sample Message Mapping. Instead, we will demonstrate the following logic: The XML document of the sending ERP system contains both the message data and a distribution list (DistributionList XML field) that is used by the sending service to identify the receivers of the message. Figure 5.31 shows the XML substructure. To keep our example flexible for various configuration environments, the ERP system sends an ID to identify the target system as a value within the DistributionList. However, because the IS requires the actual Business System as a result of the mapping at runtime, the ID is converted in our example using a value mapping. Figure 5.32 shows the target field mapping for the Service field of the target message in detail.

Figure 5.31 Dynamic Router Pattern – XML Structure

Figure 5.32 Dynamic Router Pattern – Value Conversion

123

175 BOOK.indb 123

10/2/08 8:55:58 AM

5

Enterprise Integration Patterns

In this case, the value mapping uses the following agencies and schemes: Value assignment context

http://sap.com/xi/XI

Agency

SENDER

Schema

DynamicRouter

Agency

RECEIVER

Scheme

DynamicRouter

The conversion of values means that this example could be configured for any system environment. The steps involved are explained in the following sections.

5.6.8 Configuration Time Overview – Configuration Scenario Configuration Scenario

PI_PATTERNS_EIP_DynamicRouterPattern

The Model Configurator facilitates the configuration process. Use the DynamicRouter pattern Process Integration Scenario (described previously) as a template, and assign the relevant receiver services. In a subsequent step, the dynamic routing must be maintained manually, as described in detail in the Receiver Determination section that follows. A schematic overview of the configuration is provided in Figure 5.33. EIP_DEV_R3E_EIP_100 EIP_DEV_LEGACY_3RD_001 EIP_DEV_LEGACY_3RD_002 EIP_DEV_LEGACY_3RD_003

Figure 5.33  Dynamic Router Pattern – Configuration Scenario

Templates that can be used in the Model Configurator are provided for the individual Communication Channel. The EIP_DEV_R3E_EIP_100 system sends the DynamicRouter message to one or more LEGACY-based systems. The message is sent to the relevant target system, based on the routing condition.

124

175 BOOK.indb 124

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:58 AM

Dynamic Router

5.6

Sender Communication Component Communication Component (Business System)

EIP_DEV_R3E_EIP_100

Communication Channel

File_SND_PI_PATTERNS_EIP_ERP_ DynamicRouter

Table 5.20 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

File

Source File Name

06_DynamicRouter.xml

Processing Quality of Service

Exactly Once

Table 5.20  Dynamic Router Pattern – Sender Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file). Receiver Communication Component 1 Communication Component (Business System)

EIP_DEV_LEGACY_3RD_001

Communication Channel

File_RCV_PI_PATTERNS_EIP_LEGACY_ DynamicRouter

Table 5.21 provides detailed information for specific parameters of the Communication Channel.

125

175 BOOK.indb 125

10/2/08 8:55:58 AM

5

Enterprise Integration Patterns

Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name Schema

06_DynamicRouter_LEGACY_3RD_001.xml

Processing File Generation Mode

Add time stamp

Table 5.21  Dynamic Router Pattern – Receiver 1 Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory). Receiver Communication Component 2 Communication Component (Business System)

EIP_DEV_LEGACY_3RD_002

Communication Channel

File_RCV_PI_PATTERNS_EIP_LEGACY_ DynamicRouter

Table 5.22 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name Schema

06_DynamicRouter_LEGACY_3RD_002.xml

Processing File Generation Mode

Add time stamp

Table 5.22  Dynamic Router Pattern – Receiver 2 Configuration Parameters

126

175 BOOK.indb 126

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:58 AM

Dynamic Router

5.6

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory). Receiver Communication Component 3 Communication Component (Business System)

EIP_DEV_LEGACY_3RD_003

Communication Channel

File_RCV_PI_PATTERNS_EIP_LEGACY_ DynamicRouter

Table 5.23 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name Schema

06_DynamicRouter_LEGACY_3RD_003.xml

Processing File Generation Mode

Add time stamp

Table 5.23  Dynamic Router Pattern – Receiver 3 Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory). In a subsequent step, the generated Receiver Determination must be manually modified. In this step, the Operation Mapping for the dynamic determination of receiver systems is assigned. The following object must be modified for this purpose:

127

175 BOOK.indb 127

10/2/08 8:55:58 AM

5

EnterpriseIntegrationPatterns

Receiver Determination Communication Component

EIP_DEV_R3E_EIP_100

Interface

DynamicRouter_OB

Namespace

urn:pi-patterns:pi:eip:erp:DynamicRouter:100

Change the Receiver Determination type from standard to enhanced so that the dynamic Operation Mapping can be assigned. You can then use (F4) help to assign the following Operation Mapping: Operation Mapping Name

DynamicRouter_OB_TO_ReceiverDetermination

Namespace

urn:pi-patterns:pi:eip:common:DynamicRouter:100

Software Component

PI-PATTERNS_EIP COMMON

The modified receiver determination is shown in Figure 5.34.

Figure 5.34 Dynamic Router Pattern – Dynamic Receiver Determination

128

175 BOOK.indb 128

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:55:59 AM

DynamicRouter

5.6

Note The Model Configurator enables the automatic generation of all required configuration objects (Interface Determination, Receiver Agreement etc.). Within an enhanced Receiver Agreement, the configured receivers and their corresponding objects are no longer visible. However, the individual objects are also required for a dynamic Receiver Determination.

Finally, the value mapping must be configured to enable conversion of the receiver IDs of the source XML message into the names of the target Business Systems. You maintain the value mapping in the Integration Directory under Tools • Value Mapping. Use the values specified previously for the agencies and schemes (see Figure 5.35).

Figure 5.35 Dynamic Router Pattern – Value Mapping Agencies

The display function opens a new window where you can maintain the value mapping agencies. Here you must maintain the appropriate SENDER and RECEIVER values. Figure 5.36 shows the correct values for our demo example:

Figure 5.36 Dynamic Router Pattern – Maintaining the Value Mapping

Change the values in the RECEIVER column in accordance with the Business Systems in your system landscape if these differ from those in the example.

129

175 BOOK.indb 129

10/2/08 8:55:59 AM

5

Enterprise Integration Patterns

5.6.9 Runtime You will find the test file for the sender services in the following directory in the download archive: Test file

06_DynamicRouter.xml

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_R3E_EIP_100

The sending service provides the message data and a distribution list within the XML structure. The distribution list is used to dynamically determine the receiver systems (Business Systems). To test the Dynamic Router pattern, modify these values. However, you should first ensure that the value mapping has been maintained (see Section 5.6.8, Configuration Time). The following listing shows the subarea of the XML document that is used to identify the receiving systems:           001       002       003    

100%

5.7

Guaranteed Delivery

5.7.1

Short Description

The Guaranteed Delivery pattern persists messages so that they are not lost if the messaging system fails.

5.7.2

Related Patterns

Request/Reply (see Section 5.11).

5.7.3

Problem

Message transfer cannot be guaranteed because individual components are unavailable when the message is processed and message sending is therefore interrupted. 130

175 BOOK.indb 130

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:00 AM

Guaranteed Delivery

5.7.4

5.7

Description

The Guaranteed Delivery pattern is based on the Quality of Service (QoS) principle. To enable a guaranteed transfer of messages between various services, you must use asynchronous message transfer with the Exactly Once (EO) or Exactly Once In Order (EOIO) QoS. In these cases, the messaging system provides basic services to enable guaranteed message transfer. The message transferred from the sender service to the messaging system is placed in a queue and is persisted, and the sender service receives a positive status code (for example, HTTP 200). Each processing step in the message system (mapping, routing, or calling the receiver service) is followed by persistence of the current message version. This way you can ensure that, in the case of a failure of one of the components (for example, mapping runtime), further processing of the message can continue at a later stage. An individual message has a processing status at all times (delivering, system error, etc.), which, for example, enables reprocessing of messages that could not be delivered. Because the QoS options specified involve asynchronous communication, the sender service is only informed whether the message was successfully delivered to the messaging system. The success or failure of the delivery to the receiver system, and of the message processing, remains transparent for the sender service (fire and forget principle). Confirmation may need to be sent to the sender service, depending on the relevance of the service call. Therefore, acknowledgement messages were introduced to inform the sender service about the status of a message. Acknowledgement messages are based on an asynchronous communication model.

5.7.5

Use Case

Figure 5.37 provides an abstract representation of a typical GuaranteedDeliveryPattern use case. A sender service (not shown) sends an asynchronous message to the messaging system (represented by 100% in the figure), which is responsible for further processing and acknowledgement of the message whose delivery we want to guarantee. Depending on the integration scenario, responsibility for guaranteeing delivery of the message may lie with the sender service or, in a more complex scenario, with an orchestration service that communicates with several services and provides the initiating service with information about the overall processing status. In contrast to the Request/Reply pattern (see Section 5.11), an acknowl-

131

175 BOOK.indb 131

10/2/08 8:56:00 AM

5

Enterprise Integration Patterns

edgement does not contain any message data. Instead, it only contains status information that indicates how message processing is progressing.

100%

Guaranteed Delivery Message Positive/Negative Acknowledgement

Figure 5.37  Guaranteed Delivery Pattern – Use Case

5.7.6

SAP NetWeaver PI-Specific Implementation

As described in the previous section, the Guaranteed Delivery pattern is based on an asynchronous communication model, which allows the message to be persisted in the messaging layer. Because SAP NetWeaver PI message processing takes place within several components (IS, and central and local AEs), each component contains a persistence layer and mechanisms for reprocessing messages to guarantee delivery. Asynchronous communication is defined at Design Time, a Service Interface is defined as asynchronous and the QoS is determined at Configuration Time. Note The Exactly Once in Order (EOIO) QoS will not be discussed further from this point on. Note that this QoS is not supported by all adapters.

To ensure that a sender service is kept informed about the current processing status of an asynchronous message, the service must explicitly request an acknowledgement when it sends the message. In general, acknowledgements fall into one of the following two groups: EE

System acknowledgements

EE

Application acknowledgements

Whereas system acknowledgements specify the status of the technical transfer, application acknowledgements provide information about the processing status of

132

175 BOOK.indb 132

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:00 AM

Guaranteed Delivery

5.7

the message in the receiver system. Table 5.24 provides an overview of the various types of acknowledgement in these acknowledgement groups. Acknowledgement type

Acknowledgement description

Positive system acknowledgement (SystemAck)

Message was delivered technically to the receiver service.

Negative system acknowledgement (SystemErrAck)

A system error occurred during the message transfer.

Positive application acknowledgement (ApplicationAck)

The message was successfully processed by the receiver service.

Negative application acknowledgement (ApplicationErrAck)

An error occurred during processing of the message in the receiver service.

Table 5.24  Overview – Acknowledgement Types

Note that negative acknowledgements may have two statuses: EE

Permanent Message processing terminated with a serious error; processing failed.

EE

Transient Message processing was stopped due to a temporary error. However, the message processing status may change to a positive acknowledgement or to a permanent negative acknowledgement at the next reprocessing attempt.

As mentioned previously, an acknowledgement must be explicitly requested by a sender service. This functionality is currently limited to the following adapters: EE

IDoc-based sender services

EE

ABAP proxy- and Java proxy-based sender services

EE

Integration processes (ccBPM)

Both the sender service and the receiver service must support the type of acknowledgement requested. In principle, all adapters support the system acknowledgement, although the provision of application acknowledgements is limited. Table 5.25 shows a comparison of the different adapter types and the support they offer for application acknowledgement. Application acknowledgements are also supported by Java proxies, ABAP proxies, and ccBPMs.

133

175 BOOK.indb 133

10/2/08 8:56:00 AM

5

Enterprise Integration Patterns

Adapter Type

Application Acknowledgement

IDoc

Supported

Plain HTTP

Not supported

XI

Supported

RNIF, CIDX

Supported (scenario-dependent)

File/FTP, JDBC, Java Message Service (JMS), SOAP, Marketplace, Mail, SAP Business Connector

Not supported – technical adapters send an “AckRequestNotSupported” acknowledgement

Table 5.25  Overview – Support for Application Acknowledgements

The Process Integration Scenario described in the following section illustrates the Guaranteed Delivery Pattern using a ccBPM and a Java Proxy implementation.

5.7.7

Design Time

Overview – Process Integration Scenario Process Integration Scenario

GuaranteedDeliveryPattern

Namespace

urn:pi-patterns:pi:eip:common: GuaranteedDelivery:100

Software Component

PI-PATTERNS_EIP COMMON

Because the Guaranteed Delivery pattern addresses a general problem, the following Process Integration Scenario is structured from an abstract perspective: EE

The LEGACY component initiates the orchestration process with an initiator message.

EE

The GuaranteedDeliveryPatternProcess is initiated.

EE

The GuaranteedDelivery message is sent asynchronously from the GuaranteedDeliveryPatternProcess to the ERP components.

EE

The ERP component receives and processes the GuaranteedDelivery message. An acknowledgement is sent transparently to the sender service (GuaranteedDeliveryPatternProcess).

EE

The GuaranteedDeliveryPatternProcess receives the acknowledgement and responds accordingly.

134

175 BOOK.indb 134

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:00 AM

GuaranteedDelivery

5.7

The Process Integration Scenario is shown in Figure 5.28.

Figure 5.38 Guaranteed Delivery Pattern – Process Integration Scenario

Sending the initiator message is required for the purpose of demonstrating the Guaranteed Delivery pattern only. The pattern starts with the Integration Process (ccBPM), which sends an asynchronous GuaranteedDelivery message to the ERP system. The acknowledgement messages (system or application acknowledgements) are transparent within the Process Integration Scenario, and explicit modeling is therefore not required. The acknowledgement provided by the ERP component (positive or negative) determines further processing within the Integration Process (GuaranteedDeliveryPatternProcess). A detailed description of ccBPM and the implementation of the Java proxy that simulates the ERP components are provided in the next section.

135

175 BOOK.indb 135

10/2/08 8:56:01 AM

5

Enterprise Integration Patterns

Integration Process Integration Process

GuaranteedDeliveryPattern

Namespace

urn:pi-patterns:pi:eip:common:GuaranteedDelivery:100

Software Component

PI-PATTERNS_EIP COMMON

To demonstrate the Guaranteed Delivery pattern, we have set up the integration in such a way that both system and application acknowledgements can be requested. An error simulation of the application acknowledgement is also supported. Figure 5.39 shows the Guaranteed Delivery pattern Integration Process.

A

4 1

2

3 5

Figure 5.39  Guaranteed Delivery Pattern – Integration Process 1 Preparation: The initiator message starts the process and is used to build the

GuaranteedDelivery message, which is generated within a dummy mapping. All fields in the initiator message serve to structure the GuaranteedDelivery message. This message contains the following fields, which are required for the subsequent process flow: EE

A ). TransactionId: Transaction ID for ccBPM error handling (R 2, U

EE

RequestApplicationAck: Boolean field for controlling the process flow. This value is checked within the switch statement in step 3.

136

175 BOOK.indb 136

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:01 AM

Guaranteed Delivery

EE

5.7

ProvokeAckError: Boolean field for controlling the Java proxy of the ERP component. If this value is set to true, the Java proxy simulates an application error.

2 The transaction ID is extracted for exception handling. 3 The RequestApplicationAck field is evaluated within the switch statement. If

this contains the value true, ccBPM proceeds with step 4 (application acknowledgement). Otherwise, it proceeds with step 5 (system acknowledgement). 4 The GuaranteedDelivery message is sent asynchronously and an application

acknowledgement is requested. A generic AcknowledgementException is used A ). for error handling (R U 5 The GuaranteedDelivery message is sent asynchronously and a system acknowl-

edgement is requested. A generic AcknowledgementException is used for error A ). handling (R U U A The exception handler for the AcknowledgementException (R 4, 5) generates

an alert. EE

Because additional steps are required to simulate the various acknowledgement types and to structure the GuaranteedDelivery message, the pattern itself A. (including exception handling) only comprises steps 2 and 4 or 5 and U

Java Proxy Message interface

GuaranteedDelivery_IB

Namespace

urn:pi-patterns:pi:eip:erp:GuaranteedDelivery:100

Based on the GuaranteedDelivery_IB asynchronous inbound interface, a Java proxy was created to simulate the receiver service of the ERP component. The Java proxy logic was kept very simple: EE

The fields (TransactionId, RequestApplicationAck, and ProvokeAckErr) of the inbound GuaranteedDelivery message are extracted and written to the default trace with the debug log level.

EE

If the ProvokeAckError field is set to true, an exception is generated that results in a negative application acknowledgement.

137

175 BOOK.indb 137

10/2/08 8:56:02 AM

5

Enterprise Integration Patterns

5.7.8

Configuration Time

Overview – Configuration Scenario Configuration Scenario

PI_PATTERNS_EIP_GuaranteedDeliveryPattern

The Model Configurator facilitates the configuration process. Use the GuaranteedDeliveryPattern Process Integration Scenario (described previously) as a template, and assign the relevant receiver services. A schematic overview of the configuration is provided in Figure 5.40. Templates that can be used in the Model Configurator are provided for the individual Communication Channels. The EIP_DEV_LEGACY_3RD_002 component sends the XML-based Initiator message via file adapter to start the GuaranteedDeliveryPatternProcess (for a detailed description of the individual fields see Section 5.7.10, Runtime). The GuaranteedDeliveryPatternProcess sends a GuaranteedDelivery message to the EIP_DEV_R3E_EIP_100 ERP system. The EIP_DEV_R3E_EIP_100 ERP component is represented by the Java proxy and delivers a positive or negative acknowledgement to the GuaranteedDeliveryPatternProcess. Depending on the acknowledgement received, the GuaranteedDeliveryPatternProcess ends processing successfully or generates an alert. EIP_DEV_LEGACY_3RD_002

GuaranteedDeliveryPatternProcess EIP_DEV_R3E_EIP_100

Figure 5.40  Guaranteed Delivery Pattern – Configuration Scenario

Sender Communication Component Communication Component (Business System)

EIP_DEV_LEGACY_3RD_002

Communication Channel

File_SND_PI_PATTERNS_EIP_LEGACY_Initiator

138

175 BOOK.indb 138

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:02 AM

Guaranteed Delivery

5.7

Table 5.26 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

File

Source File Name

07_Initiator.xml

Processing Quality of Service

Exactly Once

Table 5.26  Guaranteed Delivery Pattern – Sender Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file). Integration Process Communication Component

GuaranteedDeliveryPatternProcess

Wizard-based generation

The Guaranteed Delivery pattern Integration Process can be configured (generated) using the Model Configurator. Reference the GuaranteedDeliveryPatternProcess.

Receiver Communication Component Communication Component (Business System)

EIP_DEV_R3E_EIP_100

Communication Channel

XI_RCV_PI_PATTERNS_EIP_ERP_ GuaranteedDelivery

Table 5.27 provides detailed information for specific parameters of the Communication Channel.

139

175 BOOK.indb 139

10/2/08 8:56:02 AM

5

Enterprise Integration Patterns

Parameter Adapter Type

XI Receiver

Transport Protocol

HTTP 1.0

Message Protocol

XI 3.0

Path

/MessagingSystem/receive/JPR/XI

Table 5.27  Guaranteed Delivery Pattern – Receiver Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory). Deploying the Java Proxy You can download the required Java proxy as a deployable SDA file (GuaranteedDeliveryPattern.sda) from the page for this book on the publisher’s website (see www.sap-press.com). After deployment of the SDA file using the Java Support Package Manager (JSPM), one-off registration of the Java proxy is required. Use the following link to do this: http://:/ProxyServer/Register?ns=urn:pi-patterns:pi:eip:erp:GuaranteedDe livery:100&interface=GuaranteedDelivery_IB&bean=localejbs/pi/patterns/GuaranteedD eliveryIB&method=guaranteedDeliveryIB

5.7.9

Runtime

You will find the test file for the sender services in the following directory in the download archive: Test file

07_Initiator.xml

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_LEGACY_3RD_002

140

175 BOOK.indb 140

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:02 AM

Message Expiration

5.6

The ccBPM process flow and the error simulation of the Java proxy are controlled using the information provided in the Initiator.xml file. Therefore, the following fields must be set correctly: EE

1234567890

EE

true

EE

false

The process flow is supported by the following fields: EE

The TransactionId field is used for exception handling within the ccBPM. The Java proxy also writes this information to the default trace so that individual calls of the GuaranteedDeliveryPattern process can be identified.

EE

Set the value of the RequestApplicationAck field to true or false to request an application or system acknowledgement.

EE

Set the value of the ProvokeAckError field to true to receive a negative application acknowledgement from the Java proxy.

5.8

Message Expiration

5.8.1

Short Description

The Message Expiration pattern controls the validity period of a message.

5.8.2 Related Patterns Dynamic Router (see Section 5.6).

5.8.3 Problem The asynchronous communication model guarantees message processing between a sender and receiver service. Because this is a loosely coupled process, the receiver component does not necessarily have to be available when the message is sent. Therefore, if delivery of the message is delayed, the sender service cannot guarantee that the message content is still valid when it is processed in the receiver system.

141

175 BOOK.indb 141

10/2/08 8:56:02 AM

5

Enterprise Integration Patterns

5.8.4 Description The Message Expiration pattern allows the validity of a message to be monitored within the messaging system. To prevent further processing of obsolete messages or of messages that are no longer relevant, the sender system adds information to a message, specifying its validity, which can, in turn, be checked by the messaging system. The validity specified may be relative or absolute: EE

If validity is absolute, an explicit time stamp is used (for example, the date and time in the message header). A UTC time stamp should be used to counteract the problem of different time zones.

EE

With relative validity, the life time (time to live) of a message is defined. In this case, the validity is calculated by adding the message’s time to live to the time it is created or sent. The creation time is normally indicated by a time stamp within the message, whereas the send time is the time at which the message is transmitted to the messaging system.

In both cases, the messaging system checks the validity of the information in the message and, after the validity expires, prevents the message from being sent to one or more receiver services. Optionally the message can be stored for later analysis in a dead letter queue of the messaging system.

5.8.5 Use Case The validity of the information in a message is heavily dependent on the business objects it represents. A typical use case involves foreign exchange rates that are valid for a day, or share prices that change from one minute to the next, or even by the second. One such use case is shown in Figure 5.41.

Exchange Rate

Valid

Exchange Rate

Figure 5.41  Message Expiration Pattern – Use Case

5.8.6 SAP NetWeaver PI-Specific Implementation The validity of a message can only be defined in the technical JMS Adapter as standard. You can specify the message expiry period in the receiver channel. To use this

142

175 BOOK.indb 142

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:03 AM

Message Expiration

5.6

pattern in scenarios that are not JMS-based, you need an individual implementation, which is conceivable in the following components: Adapter Engine The Adapter Engine (AE) provides the technical start and end points for services and applications in many integration scenarios. It allows the validity of inbound and outbound messages to be thoroughly checked before any further processing occurs. The implementation is based on an adapter module that can be used by JEE-based adapters. The adapter module supports both the absolute and the relative approach. The necessary information, such as the creation time, expire time, or expire period can be indicated by an XPath expression within the parameter configuration of the adapter module. An exception is generated if a message is invalid. Integration Process – ccBPM The Message Expiration pattern is particularly useful if the runtime of a ccBPM needs to be controlled using the information from a specific message. The use case for the Aggregator pattern outlined in Section 5.1 is also a suitable scenario for the use of a Message Expiration pattern. The runtime of the ccBPM can be controlled using the expiry time of the contract that starts the AggregatorProcess. After the contract expires, the ccBPM stops, and a ContractStatus message referring to the contract’s expiry is sent to the receiver system. Dead Letter Queue The dead letter queue is a feature of the messaging system. It is used to store messages that could not be delivered or are no longer valid. A similar approach can be implemented with SAP NetWeaver PI using the Dynamic Router pattern described in Section 5.6. The mapping executed within the receiver determination checks the validity of a message (relative or absolute) and specifies the relevant receiver service as a return value. If a message is invalid, a dead letter queue receiver is returned.

143

175 BOOK.indb 143

10/2/08 8:56:03 AM

5

Enterprise Integration Patterns

Note SAP NetWeaver PI does not explicitly support dead letter queues. Instead, the dead letter queue is based on a standard queue where messages cannot be triggered again after successful processing.

SOAP Adapter The OASIS Web Service Security Standard (OASIS Standard 200401) defines the expiry of signatures in SOAP-based communication. In this case, the sender service defines the creation time and expiry time of a message within the Security header. The receiver service, on the other hand, checks the defined values in the signature and processes the message if it is valid or rejects it if it is not. This is shown in the sample section of source code that follows: ...

       2008-09-13T08:42:00Z    2008-10-13T09:00:00Z

...

...

SAP NetWeaver PI supports the definition of message validity and the checking of inbound messages in accordance with the OASIS Web Service Security Standard. To use these functions, you must activate the web service security profile within the sender or receiver Communication Channel. For messages that should be sent to a receiver service, the creation time (and, as an additional option, the expiry time, specified in seconds) can be activated in the Receiver Agreement. For inbound messages, activate the checks for the time stamp and the expiry period in the Sender Agreement. Note If you use the OASIS Web Service Security Standard as a Message Expiration pattern, the check is based on the time stamp of the signature and not on the creation time of the message content.

144

175 BOOK.indb 144

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:03 AM

Message Expiration

5.6

The choice of implementation method (AE, ccBPM, dead letter queue, SOAP adapter) ultimately depends on the specific requirements in each case. The Process Integration Scenario described in the text that follows demonstrates the Message Expiration pattern based on the dead letter queue logic described earlier.

5.8.7 Design Time Overview – Process Integration Scenario Process Integration Scenario

MessageExpirationPattern

Namespace

urn:pi-patterns:pi:eip:common: MessageExpiration:100

Software Component

PI-PATTERNS_EIP COMMON

The sender system from the use case (see Section 5.8.5) is represented in the Process Integration Scenario by the LEGACY component, and it sends a CurrencyExchangeRate message. The receiver systems are represented by the LEGACY component, and receive a message of type CurrencyExchangeRate. The Operation Mapping with the Message Expiration logic cannot be referenced within the Process Integration Scenario, and is therefore assigned at Configuration Time. The Process Integration Scenario is shown in Figure 5.42. The Operation Mapping must be created in the ESR at Design Time, together with the corresponding Message Mapping containing the Message Expiration logic. The implementation of the Message Mapping involves enhancing the procedure described in Section 5.6, Dynamic Router, to include the message expiration logic. According to the Message Mapping, the output is the message receiver. Therefore, both the standard receiver for valid messages and the dead letter queue receiver for invalid messages must be made known at Configuration Time, to enable a flexible implementation of the pattern. In addition, the relative validity ( retention period) of a message, and the time zone of the sender, must be specified. The parameterized mapping function introduced with SAP NetWeaver PI 7.1 enables this flexible approach.

145

175 BOOK.indb 145

10/2/08 8:56:03 AM

5

EnterpriseIntegrationPatterns

Figure 5.42 Message Expiration Pattern – Process Integration Scenario

We created the following objects to demonstrate the Message Expiration pattern: Operation Mapping Name

CurrencyExchangeRate_OB_TO_ReceiverDetermination

Namespace

urn:pi-patterns:pi:eip:common:MessageExpiration:100

Software Component

PI-PATTERNS_EIP COMMON

The Operation Mapping contains the CurrencyExchangeRate_OB Service Interface as an inbound message, which represents the message from the ERP system. The Service Interface ReceiverDetermination of the SAP Basis component (see Section 5.6, Dynamic Router) must be used as the outbound message. If the message is valid, this contains the standard receiver and, if the message is invalid, it specifies the dead letter queue receiver. The message expiration logic itself is contained in the Message Mapping, which also contains the relevant Message Types of the Ser-

146

175 BOOK.indb 146

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:03 AM

Message Expiration

5.6

vice Interfaces. The Operation Mapping contains the following parameters, which are transferred to the Message Mapping 1:1: Parameter

Description

STANDARD_RECEIVER

Receiver system for valid messages

DEAD_LETTER_QUEUE

Receiver system for invalid messages

RETENTION_PERIOD

Validity of a message, in seconds

SOURCE_TIMEZONE

Time zone of the target system

Message Mapping Name

CurrencyExchangeRate_TO_ReceiverDetermination

Namespace

urn:pi-patterns:pi:eip:common:MessageExpiratio n:100

Software Component

PI-PATTERNS_EIP COMMON

The Message Mapping contains the logic for the validity check. The target field mapping for the service field of the ReceiverDetermination target structure is set up as follows (see Figure 5.43):

�

�

�

Figure 5.43  Message Expiration Pattern – Message Mapping 1 First, the ValidityDateTime field of the target structure is concatenated with the

time zone specification (the external parameter SOURCE_TIMEZONE). 2 The concatenated string serves as an input parameter for the user-defined

messageExpiration function. The external parameter RETENTION_PERIOD is a second input parameter for this function. This information provides a basis for calculating the validity in comparison with the current time. For more information about the user-defined function, refer to the source code. If the

147

175 BOOK.indb 147

10/2/08 8:56:04 AM

5

Enterprise Integration Patterns

message is valid, the function returns the value true. Otherwise, the return value is false. 3 The Boolean value of the messageExpiration function is used for an If query.

If the message is valid (true), the external parameter value STANDARD_RECEIVER (or the external parameter value DEAD_LETTER_QUEUE if the message is invalid) is assigned to the service target field in this query.

5.8.8 Configuration Time Overview – Configuration Scenario Configuration Scenario

PI_PATTERNS_EIP_MessageExpirationPattern

The Model Configurator facilitates the configuration process. Use the MessageExpirationPattern Process Integration Scenario (described previously) as a template. In a subsequent step, the dynamic routing must be maintained manually, as described in detail in the Receiver Determination section that follows. A schematic overview of the configuration is provided in Figure 5.44. EIP_DEV_LEGACY_3RD_002

EIP_DEV_LEGACY_3RD_003

Figure 5.44  Message Expiration Pattern – Configuration Scenario

Templates that can be used in the Model Configurator are provided for the individual Communication Channel. The EIP_DEV_LEGACY_3RD_002 system sends the CurrencyExchangeRate message to the EIP_DEV_LEGACY_3RD_003 system. The validity is checked in the Receiver Determination. If no longer valid, the message is sent to the dead letter queue receiver. Sender Communication Component Communication Component (Business System)

EIP_DEV_LEGACY_3RD_002

Communication Channel

File_SND_PI_PATTERNS_EIP_LEGACY_ CurrencyExchangeRate

148

175 BOOK.indb 148

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:04 AM

Message Expiration

5.6

Table 5.28 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

File

Source File Name

08_CurrencyExchangeRate.xml

Processing Quality of Service

Exactly Once

Table 5.28  Message Expiration Pattern – Sender Configuration Parameters

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file). Receiver Communication Component Communication Component (Business System)

EIP_DEV_LEGACY_3RD_003

Communication Channel

File_RCV_PI_PATTERNS_EIP_LEGACY_ CurrencyExchangeRate

Table 5.29 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Table 5.29  Message Expiration Pattern – Receiver Configuration Parameters

149

175 BOOK.indb 149

10/2/08 8:56:04 AM

5

Enterprise Integration Patterns

Parameter Target File Name Schema

08_CurrencyExchangeRate_valid.xml

Processing File Generation Mode

Add time stamp

Table 5.29  Message Expiration Pattern – Receiver Configuration Parameters (Cont.)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory). In a subsequent step, the generated Receiver Determination must be manually modified. In this step, the Operation Mapping for the dynamic determination of receiver systems is assigned. The following object must be modified for this purpose: Receiver Determination Communication Component

EIP_DEV_LEGACY_3RD_002

Interface

CurrencyExchangeRate_OB

Namespace

urn:pi-patterns:pi:eip:legacy:MessageExpiration:100

Change the receiver determination type from standard to enhanced so that the Operation Mapping for the Message Expiration pattern can be assigned. You can then use (F4) help to assign the following Operation Mapping: Operation Mapping Name

CurrencyExchangeRate_OB_TO_ReceiverDetermination

Namespace

urn:pi-patterns:pi:eip:common:MessageExpiration:100

Software Component

PI-PATTERNS_EIP COMMON

Also define the parameters of the Operation Mapping:

150

175 BOOK.indb 150

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:04 AM

MessageExpiration

Parameter

Value

STANDARD_RECEIVER

EIP_DEV_LEGACY_3RD_003

DEAD_LETTER_QUEUE

DEAD_LETTER_QUEUE

RETENTION_PERIOD

600

SOURCE_TIMEZONE

+0200

5.6

Figure 5.45 shows an overview of the Receiver Determination.

Figure 5.45 Message Expiration Pattern – Receiver Determination

If a message is invalid, the DEAD_LETTER_QUEUE receiver is identified. Note that this is a generic component that is as yet unknown to the configuration. Because a DEAD_ LETTER_QUEUE can be used by various scenarios, we will now discuss the required configuration objects that have to be manually created. As an alternative to the abstract DEAD_LETTER_QUEUE object, you can also use an existing Business System. DEAD_LETTER_QUEUE Business Component Business component

DEAD_LETTER_QUEUE

151

175 BOOK.indb 151

10/2/08 8:56:05 AM

5

Enterprise Integration Patterns

DEAD_LETTER_QUEUE Receiver Agreement EIP_DEV_LEGACY_3RD_002

Sender Communication Component

DEAD_LETTER_QUEUE

Receiver Communication Component Interface

CurrencyExchangeRate_OB

Namespace

urn:pi-patterns:pi:eip:legacy:MessageExp iration:100

Receiver Communication Channel

File_RCV_PI_PATTERNS_DEAD_LETTER_QUEUE

DEAD_LETTER_QUEUE Communication Channel Communication Component (Business System)

DEAD_LETTER_QUEUE

Communication Channel

File_RCV_PI_PATTERNS_DEAD_LETTER_QUEUE

Table 5.30 provides detailed information for specific parameters of the Communication Channel. Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory). Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name Schema

08_DeadLetters.xml

Processing File Generation Mode

Add time stamp

Table 5.30  Message Expiration Pattern – Dead Letter Queue Configuration Parameter

152

175 BOOK.indb 152

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:05 AM

Message Translator

5.9

5.8.9 Runtime You will find the test file for the sender services in the following directory in the download archive: Test file

08_CurrencyExchangeRate.xml

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_LEGACY_3RD_002

The Message Expiration pattern requires the time stamp specified in the ValidityDateTime field, as well as the retention period (in seconds), which is specified at Configuration Time. Modify these values as required to test the Message Expiration pattern.

5.9

Message Translator

5.9.1

Short Description

The Message Translator pattern (a special converter) translates data formats between various applications and services.

5.9.2 Related Patterns Content Enricher (see Section 5.3), and Content Filter (see Section 5.4).

5.9.3 Problem Applications and services in heterogeneous system landscapes support different data structures, data types, data formats, or protocols that are incompatible with one another.

5.9.4 Description In practically all integration scenarios involving one or more heterogeneous services or systems, it is necessary to translate data structures, data types, data representations, or protocols. This translation is a major task of the integration broker. In this case, the layers shown in Table 5.31 are relevant from the perspective of the OSI reference model:

153

175 BOOK.indb 153

10/2/08 8:56:05 AM

5

Enterprise Integration Patterns

Layer

Focus

Example

Tools/Technologies

Data structures

Entities, cardinality, and association

Compression of n:m relationships for aggregation

Structural mapping patterns, and proprietary development

Data types

Field names, data types, value domains, and code values

Conversion of numerical values into strings; concatenation, or replacement of strings

Visual transformation editors, XSL, DB lookups, and proprietary development

Data representation

Data formats (XML, EDI), character set (ASCII, Unicode), encryption, and compression

Parsing of data representations and rendering in various target formats

XML parsers, EDI parsers, and proprietary APIs

Protocol

Communication protocols: TCP/IP socket, HTTP, SOAP, JMS, etc.

Transfer of message content into various protocols

Technical adapters (see Communication Channels)

Table 5.31  Message Translator Pattern – OSI reference model

5.9.5 Use Case The Message Translator pattern is abstract and concerns the translation layers within an integration broker. We will therefore explain in detail how this translation or conversion works in SAP NetWeaver PI. We will not, however, discuss a specific use case. Instead, we will provide some information to help with decisionmaking, based on best practices.

5.9.6 SAP NetWeaver PI-Specific Implementation SAP NetWeaver provides various technologies and methods for transforming data structures and data types. We will discuss the benefits and drawbacks of the following supported technologies: EE

Graphical Mapping

EE

Java XSLT Mapping

EE

ABAP XSLT Mapping

154

175 BOOK.indb 154

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:05 AM

Message Translator

EE

Java Mapping

EE

ABAP Mapping

5.9

Note The topics value mapping and external data lookups are discussed in detail in Section 5.3, Content Enricher.

Graphical Mapping SAP NetWeaver PI provides graphical mapping in the form of an editor that performs mapping based on target fields and their structures. This editor uses a range of standard functions that can be enhanced with user-defined functions and functional libraries, if required. An integrated test environment is also provided. The benefits and drawbacks of graphical mapping are as follows: EE

EE

Benefits EE

Easy handling and fast implementation of relatively simple mappings.

EE

High performance.

EE

Optional enhancement with user-defined Java functions.

Drawbacks EE

Complex mappings may become unmanageable because a large number of standard functions with concatenations are required for individual target fields.

EE

Functionality is limited in terms of totals calculation and group changes.

EE

No easy-to-use sort function; this function has to be used for each individual target field.

EE

Not standards-based.

Java-Based XSLT Mapping SAP NetWeaver PI supports XSLT mapping in the Java stack. An XSLT editor is not provided, which means that tools such as XMLSpy have to be used instead. The benefits and drawbacks of Java-based XSLT mapping are as follows:

155

175 BOOK.indb 155

10/2/08 8:56:05 AM

5

Enterprise Integration Patterns

EE

EE

Benefits EE

Standards-based approach.

EE

Advanced navigation with an XML tree.

EE

Well-suited to meet complex structural transformation and sorting requirements.

EE

Accaptable performance for small and medium-sized messages.

EE

Existing mappings from other integration solutions can be reused.

Drawbacks EE

No XSLT editor in the IB.

EE

Limited functionality in terms of complex calculations.

EE

Poor performance when processing large messages: It takes five to ten times more resources to process large messages than with graphical mapping.

ABAP-Based XSLT Mapping SAP NetWeaver PI supports XSLT mapping in the ABAP stack. The benefits and drawbacks of ABAP-based XSLT mapping are as follows: EE

EE

Benefits EE

Standards-based approach.

EE

High performance for small and medium-sized messages.

EE

Java functions can be called from XSLT.

EE

Advanced navigation with an XML tree.

EE

Well-suited to meeting complex structural transformation and sorting requirements.

EE

An XSLT editor is provided in the ABAP Workbench.

EE

Existing mappings from other integration solutions can be reused.

Drawbacks EE

The XSLT editor is not integrated into the IB, and the ABAP Workbench offers limited functionality compared with commercial XSLT editors.

EE

Limited functionality in terms of complex calculations.

EE

XI value mappings cannot be used.

156

175 BOOK.indb 156

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:05 AM

Message Translator

5.9

Java Mapping SAP NetWeaver PI supports the execution of externally defined Java mappings that implement a predefined interface. The benefits and drawbacks of Java mapping are as follows: EE

EE

Benefits EE

Reuse of the SAP XML toolkit.

EE

J2EE and Java functions can be reused.

EE

High performance.

Drawbacks EE

There is no integrated Java editor in the IB; the SAP NetWeaver Developer Studio is used for development.

EE

Implementation of a user-defined Java mapping framework is recom­ mended.

ABAP Mapping SAP NetWeaver PI supports the execution of ABAP-based mappings in the IE. The benefits and drawbacks of ABAP mapping are as follows: EE

EE

Benefits EE

Usage of ABAP XML API for simplified IDoc conversion.

EE

Full ABAP functionality is provided.

EE

High performance.

Drawbacks EE

Fields have to be extracted using the ABAP XML API.

EE

ABAP mapping is not currently propagated as a strategic SAP mapping tool (for example, SAP does not deliver ABAP-based standard mappings, and support for ABAP mappings is deactivated by default).

EE

PI value mappings cannot be used.

EE

It is tempting to migrate existing, file-based upload and download logic into ABAP mapping, rather than choosing an integrated approach.

157

175 BOOK.indb 157

10/2/08 8:56:05 AM

5

Enterprise Integration Patterns

EE

ABAP mapping transports are handled the same way as conventional ABAP transports, and therefore run in parallel with IB transports. Thus, a coordinated transport is only possible using OTO (one transport order) control.

Each type of mapping has its strengths and weaknesses. In addition to the requirements of a specific integration scenario, the existing level of expertise in an enterprise is an important criteria to consider when deciding which mapping technology to use. Figure 5.46 shows a comparison of mapping technologies based on general mapping requirements.

High Performance Required

Structural Number of Mappings and Target Field Mappings 1–40 Sort Functions

PI Value Mapping Required

Complex Calculations

Graphical Mapping Java XSLT Mapping ABAP XSLT Mapping

Java Mapping

ABAP Mapping Legend:

= Positive

= Neutral

= Not Supported

Figure 5.46  Mapping Technologies

Data Representations In SAP NetWeaver PI, the transformation of data representations refers to the conversion of the message protocol mapped within a technical adapter. Each adapter converts its specific or proprietary message protocol from or into the PI-internal XML document format. Different adapters are used, depending on the various receiver and sender systems in a heterogeneous system landscape. Although SAP

158

175 BOOK.indb 158

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:06 AM

Message Translator

5.9

NetWeaver PI standard adapters are used as much as possible in the area of A2A integration, special Electronic Data Interchange (EDI) or industry-specific adapters are often required in the B2B environment and these are normally provided by SAP partners. If a specific requirement cannot be fulfilled with standard adapters or adapters from SAP partners, the PI Adapter Framework is available, in which you can develop your own adapters. Table 5.32 shows an overview of the adapters and message protocols used. Adapter Type

Transport Protocol

Message Protocol

IDoc

Sender adapters:

IDoc-XML

EE

tRFC

EE

File

Receiver adapter: EE

tRFC

RFC

RFC

RFC-XML

Plain HTTP

HTTP(S) 1.0

XI payload in the HTTP body

SAP Business Connector (BC)

HTTP(S)

EE

RFC XML with envelope

EE

IDoc-XML

File/FTP

EE

File system (NFS)

EE

File

EE

FTP/FTP using SSL/TLS

EE

File with content conversion

JDBC

JDBC 2.0

Sender adapter: EE

JDBC 2.0

Receiver adapters:

JMS

EE

SonicMQ JMS Provider

EE

WebSphereMQ (non-JMS)

EE

Access to JMS Provider via JNDI

EE

(Read) JMS Provider administered objects from file

EE

Generic JMS Provider access

EE

XML SQL format

EE

Native SQL string

JMS 1.x

Table 5.32  Technical Protocols of the Adapters (Source: SAP AG)

159

175 BOOK.indb 159

10/2/08 8:56:06 AM

5

Enterprise Integration Patterns

Adapter Type

Transport Protocol

Message Protocol

SOAP

Sender adapters:

SOAP 1.1

EE

HTTP

Receiver adapters:

Marketplace

EE

HTTP(S)

EE

SMTP(S)

HTTP(S)

MML

JMS Sonic MQ 3.5 Sender adapters:

Mail

EE

IMAP4

EE

POP3

IXALL XIPAYLOAD

Receiver adapters:

RNIF20 RNIF11 CIDX

EE

IMAP4

EE

SMTP

EE

HTTP 1.1

EE

HTTPS

EE

HTTP 1.1

EE

HTTPS

EE

HTTP 1.1

EE

HTTPS

RNIF 2.0 RNIF 1.1 RNIF 1.1

WS

HTTP(S) 1.0

WS 1.0

XI

HTTP(S) 1.0

EE

XI 2.0

EE

XI 3.0

Table 5.32  Technical Protocols of the Adapters (Source: SAP AG) (Cont.)

Transport Protocols Technical protocols (such as JDBC, HTTP, or FTP) are implemented by technical adapters. SAP NetWeaver PI contains all of the usual technical protocols in the form of standard adapters. More complex technical protocols and specific industry standards are supported by SAP partners. Alternatively, the PI Adapter Framework can be used to implement unsupported technical protocols.

160

175 BOOK.indb 160

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:06 AM

Message Translator

5.9

Table 5.32 provided an overview of the adapters and the technical protocols used (source: http://help.sap.com/saphelp_nwpi71/helpdata/en/0d/5ab43b274a960de1000 0000a114084/frameset.htm). EDI Solutions SAP NetWeaver PI 7.1 does not offer a standard method for EDI solutions. SAP’s strategy is instead to offer these solutions through an extensive partner network. Because numerous solutions are currently available on the market, Table 5.33 provides an overview of providers and their solutions. Note that at the time of going to press, it wasn’t possible to test the ease of implementation of these solutions based on SAP NetWeaver PI 7.1. For more information, contact the providers directly. Provider

Solution

Remarks

Resource Informatik AG

R-EDI Adapter/Solution

–

Axway Software GmbH

XML-EDI Transform Module OFTP adapter Package for Automotive

–

Intelligence AG

it.x-change

–

Corporate Business Solutions GmbH

cbs PI industry solutions for EDIFACT; Open PI conversion module for EDIFACT (open source)

–

Seeburger AG

SEEBURGER EDI/B2B industry and technical adapters for SAP XI/PI

–

Crossgate AG

B2B 360° services for SAP solutions

Transaction network

AEDAPTIVe Solutions BV

EDI/AS2 adapters

–

CAS AG

EDIX

–

Web Federation GmbH and others

B2B by Practice

Open-source solution; can be deployed on SAP J2EE and integrated as an adapter module; currently geared towards energy suppliers

Table 5.33  Overview of EDIT Solutions (Source: DSAG)

161

175 BOOK.indb 161

10/2/08 8:56:06 AM

5

Enterprise Integration Patterns

Provider

Solution

Remarks

Informatica

Conversion agent

Conversion tool with EDIFACT support

DataDirect technologies

DataDirect XML converter

Java framework for XML conversion

Cormeta AG

Cormeta XI solution for electricity suppliers

XI content only

Table 5.33  Overview of EDIT Solutions (Source: DSAG) (Cont.)

EDI solutions generally combine data representation in the form of PI-specific mappings (PI content), with the transport protocol in the form of a technical adapter. When choosing an EDI solution, you should therefore begin by analyzing exactly which type of solution is required. One interesting approach is being taken by the Open PI Initiative (OPI2) opensource project, which was established in the spring of 2008 (see: https://sourceforge. net/projects/opi2). As part of the GNU General Public License, it offers an adapter module based on the PI Adapter Framework, which supports bidirectional conversion between EDIFACT and EDIFACT XML. An AS2 adapter is also provided as part of the OPI2 project.

5.10 Message Bridge 5.10.1 Short Description The Message Bridge pattern is used to link several messaging systems.

5.10.2 Related Patterns None.

5.10.3 Problem Large international enterprises with decentralized organizational structures need to connect the messaging systems of individual business segments or divisions to obtain global information.

162

175 BOOK.indb 162

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:06 AM

Message Bridge

5.10

5.10.4 Description The Message Bridge pattern described in this section is based on the Messaging Bridge Pattern originally defined by Gregor Hohpe and Bobby Wolf to integrate messaging systems from different manufacturers. However, we want to apply our Message Bridge Pattern to the integration of several SAP NetWeaver PI systems, and address issues around design and configuration. Our Message Bridge Pattern therefore describes the procedure for implementing integration scenarios across several SAP NetWeaver PI systems. In practice, global functions (such as financial accounting) require information from various business segments to provide a complete, company-wide perspective. Abstractly speaking, this produces a 1:n relationship between a global system and several local systems. In this context, the global function usually plays the role of consumer, with the local functions serving as information providers. This allocation of roles leads us to the following conclusions: EE

The complexity of the integration in the local SAP NetWeaver PI systems should be minimized.

EE

The integration logic is contained in the global SAP NetWeaver PI system.

EE

Ideally, all systems use the same business objects (de facto standard).

These points are illustrated in the use case described in the next section.

5.10.5 Use Case Travel expense accounting in a global enterprise needs to be transferred from decentralized processing in the individual business segments to centralized processing. For this purpose, the individual local applications send business segment-relevant information to a global clearing system. Because the business segments are separate entities in terms of both organization and responsibility, the local applications cannot be connected directly to the global integration platform. Integration is therefore based on PI-to-PI communication. In other words, from the perspective of the business segments, the global integration platform can be seen as an external application. This use case is shown in Figure 5.47.

163

175 BOOK.indb 163

10/2/08 8:56:07 AM

5

Enterprise Integration Patterns

Local

Global

Travel Expenses Travel Expenses Travel Expenses

Organizational Boundary = Individual PI Instances

Figure 5.47  Message Bridge Pattern – Use Case

5.10.6 SAP NetWeaver PI-Specific Implementation The SAP NetWeaver PI-specific implementation of the Message Bridge Pattern can take a number of different forms. Below, we describe a best-practice approach, which takes into account additional requirements in terms of cost and maintainability: 1. The global organizational unit is the consumer, and, as such, is responsible for implementing the SAP NetWeaver PI content. 2. The SAP NetWeaver PI content must be transparent and easy to install for the individual local systems. 3. To reduce maintenance and monitoring costs, the central integration logic (that is, mappings and ccBPMs) are located in the global system only. A distribution of mappings or ccBPMs among several SAP NetWeaver PI systems must be avoided. 4. The design of the integration solutions must support a multi-system landscape. The individual business segments do not use a conventional three-system landscape (DEV-QAS-PRD). Instead, they contain additional cut-over and integration systems (DEV-QAS-CUT-PPR-PRD), which need to be integrated with a minimum of effort. 5. Technical restrictions must also be taken into account, in particular the fact that the Business Systems specified in the SLD may only be assigned to one IS. To meet these extensive requirements, the three-component strategy or a processoriented software component strategy must also be applied to this pattern:

164

175 BOOK.indb 164

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:07 AM

Message Bridge

EE

In this pattern, the COMMON software component plays the role of central component, which supplies the integration logic (Requirement 3).

EE

The ERP software component represents the local financial systems of the individual business segments.

EE

The LEGACY software component represents the global clearing system for expense accounting.

5.10

However, all three software components are implemented within the global consumer SAP NetWeaver PI system (Requirement 1) because this ensures that the integration logic is stored centrally and that an integrated (end-to-end) view can be modeled in the Process Integration Scenario. Up to this step, the procedure is not different from a standard Process Integration Scenario based on an SAP NetWeaver PI platform. To fulfill Requirement 2 (transparent SAP NetWeaver PI content that is easy to install), we will select a service delivery approach: The global organization is responsible for implementing a complete solution in the form of a software component (ERP). This software component is delivered to the business segments that need to be integrated, is imported, and then is configured within the local SAP NetWeaver PI system. To minimize the effort that may be required as a result of monitoring, the ERP software component does not contain any integration logic, and routes the message generated in the ERP backend system to the global integration platform. To provide the persons responsible for the local SAP NetWeaver PI platforms with the most user-friendly solution possible, the ERP software component contains a simplified Process Integration Scenario that allows the local SAP NetWeaver PI system to be connected to the global SAP NetWeaver PI platform for configuration. In practice, the individual software components are accompanied by a detailed configuration guide, supplied by the global organization. The PI-to-PI scenario is configured as a B2B configuration both in the local SAP NetWeaver PI systems and the global SAP NetWeaver PI system. Each business segment is represented as a B2B partner whose specific application landscape is not apparent. Depending on the integration scenario, a B2B partner may assume the role of service provider or service consumer, with the technical connection of the B2B partner backend system remaining transparent.

165

175 BOOK.indb 165

10/2/08 8:56:07 AM

5

EnterpriseIntegrationPatterns

5.10.7 Design Time Overview – Process Integration Scenario Within the Message Bridge pattern, we use both Process Integration Scenarios described in the following text. Process Integration Scenario

MessageBridgePattern

Namespace

urn:pi-patterns:pi:eip:common:MessageBridge:100

Software Component

PI-PATTERNS_EIP COMMON

The end-to-end Process Integration Scenario of the COMMON component contains the integration and mapping logic and is used later as a template for configuring the global SAP NetWeaver PI instance. The ERP software component represents all local SAP NetWeaver PI instances, and it sends the expense accounting information (expenses sample) to the receiver LEGACY component, which represents the global clearing system. Because the local ERP systems are transparent from the perspective of the global SAP NetWeaver PI instance, the ERP component is defined as a B2B communication type. This is a prerequisite for B2B communication at Configuration Time. The LEGACY component known to the global SAP NetWeaver PI instance is defined as an A2A communication type. Figure 5.48 shows the Process Integration Scenario to be used within the global SAP NetWeaver PI instance.

Figure 5.48 Message Bridge Pattern – Global Process Integration Scenario

166

175 BOOK.indb 166

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:07 AM

MessageBridge

Process Integration Scenario

MessageBridgePattern

Namespace

urn:pi-patterns:pi:erp:common:MessageBridge:100

Software Component

PI-PATTERNS_EIP ERP

5.10

The Message Bridge pattern of the ERP components, which is used to support the local configurations, contains no integration logic and can be described as a “dummy” Process Integration Scenario. This is because its only objective is to route local messages to the global integration platform. When defining the communication type of the components, the exact opposite of the procedure used in the global Process Integration Scenario applies: The communication type of the ERP component is defined as A2A, and the communication type of the receiver component is defined as B2B. In day-to-day work scenarios, only the ERP component is delivered to the local SAP NetWeaver PI integration platform; the LEGACY component is unknown. For this reason, the receiver component is defined as a template. The local Process Integration Scenario is shown in Figure 5.49.

Figure 5.49 Message Bridge Pattern – Local Process Integration Scenario

5.10.8 Configuration Time As already stated with regard to the Process Integration Scenario, both global and local configurations are required (and both are described in this section). To uniquely identify each of these Configuration Scenarios, we have used the suffixes

167

175 BOOK.indb 167

10/2/08 8:56:08 AM

5

Enterprise Integration Patterns

Global and Local when naming the scenarios. We’ll begin by looking at the global configuration.

Overview – Configuration Scenario – Global Configuration Scenario

PI_PATTERNS_EIP_MessageBridgePattern_Global

The Model Configurator facilitates configuration of the global SAP NetWeaver PI instance. Use the Message Bridge pattern Process Integration Scenario of the COMMON component (described previously). Before you can start the process of configuration within the global configuration platform, you need to create the B2B parties EIP_LOCAL and EIP_GLOBAL, each with an ExpensesService business component. Party

EIP_GLOBAL

(Party) Business-Component

ExpensesService

Party

EIP_LOCAL

(Party) Business-Component

ExpensesService

Figure 5.50 shows the global configuration in its overall context.

Local System Landscape EIP_LOCAL ExpensesService

EIP_GLOBAL

EIP_DEV_R3E_EIP_100

ExpensesService

EIP_LOCAL ExpensesService

EIP_GLOBAL ExpensesService

Global System Landscape

EIP_DEV_LEGACY_3RD_003

Figure 5.50  Message Bridge Pattern – Global Configuration

168

175 BOOK.indb 168

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:08 AM

MessageBridge

5.10

The EIP_LOCAL partner with the ExpensesService business component is used to configure the sender component. Because the sender component was defined as the B2B communication type at Design Time, the Model Configurator wizard automatically detects that the configuration is of type Business Components for B2B (see Figure 5.51).

Figure 5.51 Configuration of the Global Sender Service

To configure the A2A receiver service (which, in this case, is the clearing system of the global integration platform), you must specify the Business System component and assign a business component for external communication. This is illustrated in Figure 5.52. The following configuration settings are used: Business System Component

EIP_DEV_LEGACY_3RD_003

Party

EIP_GLOBAL

(Party) Business-Component

ExpensesService

Figure 5.52 Configuration of the Global Receiver Service

Templates that can be used in the Model Configurator are provided for the individual Communication Channels. Communication between the local and global PI instances is based on the XI protocol. A file adapter is used to communicate with the global clearing system.

169

175 BOOK.indb 169

10/2/08 8:56:08 AM

5

Enterprise Integration Patterns

Sender Communication Component Party

EIP_LOCAL

Communication Component (Business Component)

ExpensesService

Communication Channel

XI_SND_PI_PATTERNS_EIP_ERP_ ExpensesSample

Table 5.34 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

XI Sender

Transport Protocol

HTTP 1.0

Message Protocol

XI 3.0

HTTP Security-Level

HTTP

Table 5.34  Message Bridge Pattern – Sender Configuration Parameters (Global Configuration)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file). Receiver Communication Component Party

EIP_GLOBAL

Communication Component (Business Component)

ExpensesService

Communication Component (Business System)

EIP_DEV_LEGACY_3RD_003

Communication Channel

File_RCV_PI_PATTERNS_EIP_LEGACY_ ExpensesSample

Table 5.35 provides detailed information for specific parameters of the Communication Channel.

170

175 BOOK.indb 170

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:09 AM

Message Bridge

5.10

Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File Content Conversion

Target File Name Schema

10_ExpensesSample_GL.csv

File type

Binary

Content Conversion Recordset structure

Record

Recordset.fieldSeparator

;

Record.endSeparator

‘nl’

Table 5.35  Message Bridge Pattern – Receiver Configuration Parameters (Global Configuration)

The file conversion function transforms the original XML message into a .csv structure. One line is generated for each XML record. Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory). Overview – Configuration Scenario – Local Configuration Scenario

PI_PATTERNS_EIP_MessageBridgePattern_Local

The Model Configurator facilitates configuration of the local PI instance(s). Use the MessageBridgePattern Process Integration Scenario of the ERP component (described previously) as a template. Before you can start the process of configuration within the local configuration platform, you need to create the B2B parties EIP_ LOCAL and EIP_GLOBAL, each with an ExpensesService business component.

171

175 BOOK.indb 171

10/2/08 8:56:09 AM

5

Enterprise Integration Patterns

Party

EIP_GLOBAL

(Party) Business-Component

ExpensesService

Party

EIP_LOCAL

(Party) Business-Component

ExpensesService

Figure 5.53 shows the local configuration in its overall context.

Local System Landscape EIP_LOCAL ExpensesService

EIP_GLOBAL

EIP_DEV_R3E_EIP_100

ExpensesService

EIP_LOCAL ExpensesService

EIP_GLOBAL ExpensesService

Global System Landscape

EIP_DEV_LEGACY_3RD_003

Figure 5.53  Message Bridge Pattern – Local Configuration

To configure the A2A sender service (in this case, the ERP system of the local integration platform), you must specify the Business System component and assign a business component for external communication (see Figure 5.54). The following configuration settings are used: Business System Component

EIP_DEV_R3E_EIP_100

Party

EIP_LOCAL

Business Component

ExpensesService

172

175 BOOK.indb 172

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:09 AM

MessageBridge

5.10

Figure 5.54 Configuration of the Local Sender Service

The EIP_GLOBAL partner with the ExpensesService configuration component is used to configure the receiver component. Because the receiver component was defined as the B2B communication type at Design Time, the Model Configurator wizard automatically detects that the configuration is of type Business Components for B2B (see Figure 5.55).

Figure 5.55 Configuration of the Local Receiver Service

Templates that can be used in the Model Configurator are provided for the individual Communication Channel. Communication between the local and global SAP NetWeaver PI instances is based on the XI protocol. A file adapter is used to communicate with the ERP system. Sender Communication Component Communication Component (Business System)

EIP_DEV_R3E_EIP_100

Communication Channel

File_SND_PI_PATTERNS_EIP_ERP_ ExpensesSample

Table 5.36 provides detailed information for specific parameters of the Communication Channel.

173

175 BOOK.indb 173

10/2/08 8:56:10 AM

5

Enterprise Integration Patterns

Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

File

Source File Name Schema

10_ExpensesSample_LO.xml

Processing Quality of Service

Exactly Once

Table 5.36  Table 5.36 Message Bridge Pattern – Sender Configuration Parameters (Local Configuration)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file). Receiver Communication Component Partner

EIP_GLOBAL

Communication Component

ExpensesService

(Business Component) Communication Channel

XI_RCV_PI_PATTERNS_EIP_ERP_ExpensesSample

Table 5.37 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

XI Receiver

Transport Protocol

HTTP 1.0

Message Protocol

XI 3.0

Table 5.37  Message Bridge Pattern – Receiver Configuration Parameters (Local Configuration)

174

175 BOOK.indb 174

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:10 AM

Request/Reply

5.11

Parameter Addressing Type

URL address of the global PI instance. Alternatively, an HTTP destination can be referenced. This is created in Transaction SM59.

Target Host

Host of the global PI instance

Service Number

HTTP port of the global PI instance

Path

/sap/xi/engine?type=entry

Table 5.37  Message Bridge Pattern – Receiver Configuration Parameters (Local Configuration) (Cont.)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values.

5.10.9 Runtime You will find the test file for the sender services of the local ERP systems in the following directory in the download archive: Test file

10_ExpensesSample_LO.xml

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_R3E_EIP_100

The sample file contains a travel expense report with two items.

5.11

Request/Reply

5.11.1

Short Description

The Request/Reply pattern represents an asynchronous, decoupled message processing solution.

5.11.2 Related Patterns Guaranteed Delivery (see Section 5.7).

175

175 BOOK.indb 175

10/2/08 8:56:10 AM

5

Enterprise Integration Patterns

5.11.3 Problem When a service is called, the sending service cannot proceed with processing. If a large number of parallel calls are executed (as is the case, for example, when stress testing), it is identified that the architecture needs to be changed.

5.11.4 Description Synchronous communication between two services represents the best known form of the Request/Reply pattern. The sender service sends a message (request) to the target service and waits for a response (reply). During the synchronous call, the sender service does not execute any further actions. Instead, it waits for the reply from the component that was called, to continue processing based on the information it receives. Both the sender and receiver service must be available at the time of the request/reply. Although the calling service receives an immediate confirmation if there is an error, the error handling routine in synchronous communication is complex. Messages are not persisted within synchronous communication (also referred to as stateless communication). This means that few resources are used, but also that an automatic repeat of the call is not possible should an error occur. Furthermore, failure of an intermediate component results in incorrect information. For example, if the reply to a synchronous call reaches the sender service after the timeout period has ended, it is assumed that the call was not successful, even though the business object to be transferred was successfully delivered to the target system. As a rule, you should avoid the synchronous communication model for update or insert/create operations. The asynchronous Request/Reply pattern, on the other hand, is based on loosely coupled, stateful methods. For example, the receiver service does not need to be available when the sender service sends a request to a target service (and then simply continues processing). The messaging system persists messages and resends them if delivery fails. Messages can also be sent in serial order, or at specific intervals (bulk messaging). The reply is sent independently of the message that was originally sent, and must be uniquely identifiable in the sender system so that further information can be uniquely assigned to it. In day-to-day project work, and within spot consulting activities in particular, we often find that the initial design of interfaces is built on the synchronous communication model. Not until weaknesses are detected (often when mass tests are performed) is the communication model switched to an asynchronous approach.

176

175 BOOK.indb 176

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:10 AM

Request/Reply

5.11

The asynchronous model has been increasingly gaining acceptance. However, it is unsuitable for some types of communication, the most obvious example being lookups of mapping values to an external data source. Also, certain technical protocols do not support asynchronous communication.

5.11.5 Use Case In practice, synchronous communication is often the primary model of communication, in particular when orchestration components (ccBPM) are used. For example, synchronous communication may be used predominantly to call a web service-based application because the HTTP protocol is synchronous. However, integration tests and stress tests may then detect that the performance of the web service-based application is suboptimal because of the large number of parallel calls. The Request/Reply pattern can then be introduced to solve the problem. Because the problem scenario described previously is frequently encountered, we will make it our use case for this pattern. An orchestrating component (in this case, a ccBPM) sends an asynchronous request to a service, and receives an independent, asynchronous reply. The information in the reply message enables a unique assignment to the request message. This use case is shown in Figure 5.56.

Request Message Reply Message Figure 5.56  Request/Reply Pattern – Use Case

5.11.6 SAP NetWeaver PI-Specific Implementation The use case described in Section 5.11.5 usually consists of just one subarea of an orchestration component (ccBPM) that contains numerous systems. The Integration Process sends a request to a backend system, and identifies the reply based on a correlation that is unique across all systems. The correlation must be unique because other ccBPMs running in parallel may also be waiting for a reply from the same backend system. A send step is created within the ccBPM, which activates

177

175 BOOK.indb 177

10/2/08 8:56:10 AM

5

Enterprise Integration Patterns

a previously defined correlation (reference to a specific field in the request message). The BPE then ensures that the asynchronous response message is delivered to the correct ccBPM (reference to a specific field in the reply message). The value of the correlation in the request must match that in the reply message, and must also be uniquely identifiable at runtime. In addition, the send step must request a technical acknowledgement so that it can handle any technical errors that may occur in the communication. The use of the asynchronous Request/Reply pattern is determined by the technical protocol, among other things. For example, the JDBC protocol supports the asynchronous communication model only under certain conditions. Thus, synchronous communication is required to call a stored procedure in order to receive processing information from the database. Insert/Update statements, in contrast, can use the asynchronous approach. Of particular interest is the use of the Request/Reply patterns with HTTP-based protocols in synchronous/asynchronous scenarios. In this case, a “mapping” of the synchronous protocol to an asynchronous protocol is required. Although the HTTP protocol is synchronous, an asynchronous model can be constructed within SAP NetWeaver PI. For example, a sender service only receives the information that a message was technically received when the SOAP adapter is called. Within SAP NetWeaver PI, the previously synchronous web service call is simultaneously persisted as an asynchronous message and forwarded to the target components. Finally, the reply message sent back to the original sender service is transferred synchronously in a SOAP call. However, this message is also set up asynchronously internally within SAP NetWeaver PI and is only transferred synchronously from the SOAP adapter. The alternative use of a synchronous/asynchronous bridge (ccBPM), where the web service calls the bridge and waits for a reply, has frequently proven problematic because a timeout occurs. A similar problem occurs in asynchronous/synchronous scenarios, for example in a JMS-JDBC scenario where a SELECT statement should be executed on a database. In this case, a ccBPM can usually be of assistance by forwarding the inbound asynchronous request to the database as a synchronous call, and returning the response as a reply message by JMS. However, mass testing reveals that a ccBPM is also excessively resource-intensive. As a solution, an adapter module can be used to replace the asynchronous/synchronous bridge function of the ccBPM. Today, a relevant adapter module is provided standard with the JMS adapter.

178

175 BOOK.indb 178

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:10 AM

Request/Reply

5.11

5.11.7 Design Time Overview – Process Integration Scenario Process Integration Scenario

RequestReplyPattern

Namespace

urn:pi-patterns:pi:eip:common:RequestReply:100

Software Component

PI-PATTERNS_EIP COMMON

The Request/Reply pattern usually forms only one part of a ccBPM. Thus, for demonstration purposes, an initiator message that is sent by the ERP system component and that starts the RequestReplyPatternProcess is required. The pattern begins with the asynchronous send-request action and ends with the asynchronous receive-reply action. The LEGACY system component receives the request message and returns an asynchronous reply message. The request and reply messages are correlated via a unique transaction ID, which, for the purposes of simulation, is made known to the RequestReplyPatternProcess in the initiator message. The Process Integration Scenario is shown in Figure 5.57.

Figure 5.57 Request/Reply Pattern – Process Integration Scenario

179

175 BOOK.indb 179

10/2/08 8:56:11 AM

5

Enterprise Integration Patterns

Overview – Integration Process Integration Process

RequestReplyPattern

Namespace

urn:pi-patterns:pi:eip:common:RequestReply:100

Software Component

PI-PATTERNS_EIP COMMON

Before the Request/Reply pattern can be demonstrated, some preparatory steps are required so that the initiator message can be received and a request message created. A transaction ID, which is delivered to the RequestReplyPatternProcess in the initiator message, is used for the purpose of correlation. The pattern consists of steps 2–4, which are explained in detail in the list that follows (Figure 5.58 provides an overview of the Integration Process):

A

B

C

1

2

3

4

5

Figure 5.58  Request/Reply Pattern – Integration Process 1 Preparation: The initiator message is received (or it initializes an instance of

the ccBPM Request/Reply pattern) and the request message is generated within a dummy mapping. The TransactionID field in the initiator message is then assigned to the request message, which is used as a basis for correlating the entire process. 180

175 BOOK.indb 180

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:12 AM

Request/Reply

5.11

2 The transaction ID is extracted to a variable for error handling purposes. 3 The request message is sent asynchronously. This activates the correlation, and

a transport acknowledgement is requested so that any technical exceptions that may occur can be handled. 4 The correlating reply message is received. 5 Further processing of the information received can now begin. For simula-

tion purposes, a status text visible within ccBPM Monitoring is extracted to a variable. U A The TransportExceptionHandler (R 3) generates an alert. U B The TimeoutExceptionHandler (R U C ) generates an alert. U C The deadline branch generates a TimeoutException (R U B ).

5.11.8 Configuration Time Overview – Configuration Scenario Configuration Scenario

PI_PATTERNS_EIP_RequestReplyPattern

The Model Configurator facilitates the configuration process. Use the RequestReplyPattern Process Integration Scenario of the COMMON component (described previously) as a template. The schematic configuration is shown in Figure 5.59. The EIP_DEV_R3E_EIP_100 sender Business System sends an XML-based message via file adapter to the RequestReplyPatternProcess for initialization. The message contains a transaction ID, which is used for correlating the process as a whole. The RequestReplyPatternProcess sends the request message to the LEGACY system. The LEGACY system receives the request message as a file-based XML message. The LEGACY system sends the reply message via file adapter to the RequestReplyPatternProcess. Before the message is sent, the transaction ID in the XML document must be modified in accordance with the request or initiator message. Templates that can be used in the Model Configurator are provided for the individual Communication Channels.

181

175 BOOK.indb 181

10/2/08 8:56:12 AM

5

Enterprise Integration Patterns

EIP_DEV_R3E_EIP_100

RequestReplyPatternProcess EIP_DEV_LEGACY_3RD_003

Figure 5.59  Request/Reply Pattern – Configuration Scenario

Sender Communication Component: Initiator Communication Component (Business System)

EIP_DEV_R3E_EIP_100

Communication Channel

File_SND_PI_PATTERNS_EIP_ERP_Initiator

Table 5.38 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

File

Source File Name Schema

11_Initiator.xml

Processing Quality of Service

Exactly Once

Table 5.38  Request/Reply Pattern – Sender Configuration Parameters (Initiator)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file).

182

175 BOOK.indb 182

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:12 AM

Request/Reply

5.11

Integration Process Communication Component

RequestReplyPatternProcess

Wizard-based generation

The Integration Process of the Request/Reply pattern can be configured (generated) using the Model Configurator. Use the RequestReplyPatternProcess as a reference.

Receiver Communication Component: Legacy Communication Component (Business System)

EIP_DEV_LEGACY_3RD_003

Communication Channel

File_RCV_PI_PATTERNS_EIP_LEGACY_Request

Table 5.39 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name Schema

11_Request.xml

Processing File creation mode

Create

Table 5.39  Request/Reply Pattern – Sender Configuration Parameters (Legacy)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory). Sender Communication Component: Legacy Communication Component (Business System)

EIP_DEV_LEGACY_3RD_003

Communication Channel

File_RCV_PI_PATTERNS_EIP_LEGACY_Reply

183

175 BOOK.indb 183

10/2/08 8:56:12 AM

5

Enterprise Integration Patterns

Table 5.40 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

File

Source File Name Schema

11_Reply.xml

Processing Quality of Service

Exactly Once

Table 5.40  Request/Reply Pattern – Sender Configuration Parameters (Legacy)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file).

5.11.9 Runtime You will find the test file for the sender services of the ERP systems in the following directory in the download archive: Test file

11_Initiator.xml

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_R3E_EIP_100

Change the TransactionID to simulate parallel process instances. You will find the test file for the sender services of the LEGACY systems in the following directory in the download archive: Test file

11_Reply.xml

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_LEGACY_3RD_003

184

175 BOOK.indb 184

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:12 AM

Splitter

5.12

This file simulates the reply message from the LEGACY component, sent to the RequestReplyPatternProcess after the request message is received:

       1234567890     9876543210     SUCCESS     Request processed successfully   

Change the TransactionID in accordance with the TransactionID of the initiator message. You can also change the text in the StatusInfo field, which is visible in ccBPM Monitoring.

5.12

Splitter

5.12.1 Short Description The Splitter pattern divides a composite message into a series of individual messages.

5.12.2 Related Patterns Message Translator (see Section 5.9).

5.12.3 Problem Various problem scenarios may make it necessary to split a composite message: EE

Different parts of the message need to be processed in different backend systems.

EE

The backend system processes the composite message in various business objects; therefore, the service granularity differs between the sending and receiving systems.

EE

Restrictions apply at a technical level (for example, an existing shared procedure can only process parts of the message).

185

175 BOOK.indb 185

10/2/08 8:56:12 AM

5

Enterprise Integration Patterns

5.12.4 Description The purpose of the Splitter pattern is to divide a composite message into several individual messages to enable further processing in one or more target systems. Unlike the Content Based Router pattern (see Section 5.5) or the Dynamic Router pattern (see Section 5.6), the Splitter pattern does not replicate the message as a whole. Instead, it divides the original message into a number of individual messages. A data structure mapping (see Section 5.9, Message Translator) is used to divide the composite message into individual messages (1:n multi-mapping). Note Note that an asynchronous communication model is an essential prerequisite for the Splitter pattern.

5.12.5 Use Case A commonly occurring example concerns a customer master object that is generated in an MDM system and processed in an SAP ERP backend system. A schematic overview of this use case is shown in Figure 5.60.

Customer Customer Master Address Figure 5.60  Splitter Pattern – Use Case

The Splitter pattern must be used here because the MDM customer master object is processed in the SAP ERP backend system in two different IDocs: EE

DEBMAS.DEBMAS06 – Customer master

EE

ADRMAS.ADRMAS02 – Address data

5.12.6 SAP NetWeaver PI-Specific Implementation The Splitter pattern can be implemented in SAP NetWeaver PI 7.1 in two different ways:

186

175 BOOK.indb 186

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:13 AM

Splitter

EE

The classic approach is to use a ccBPM. A composite message is split into individual message within a ccBPM using a 1:n multi-mapping. The ccBPM has no orchestrating function and is purely functional.

EE

The alternative is to use the message bulking enhancement. Within the interface determination you can select the Enhanced Interface Determination option, which allows you to specify an Operation Mapping. A 1:n multi-mapping is used here as well.

5.12

Although two implementation options are available, to select the correct variant you must consider the integration scenario that needs to be implemented. The following criteria must be fulfilled for the message bulking variant: EE

An asynchronous communication model is used.

EE

The technical end points (adapters) are based on the AE.

EE

The messages to be sent are processed by the same J2EE AE.

EE

The end points are not Java proxies based.

If these criteria are fulfilled, the resource-saving message bulking variant can be used instead. Note, however, that future changes with regard to technical connections within the system landscape may apply. A re-implementation based on ccBPM may be required if an exception to the following supported adapters is encountered: EE

RFC

EE

SAP Business Connector

EE

File/FTP

EE

JDBC

EE

JMS

EE

SOAP

EE

Marketplace

EE

Mail

EE

RNIF

EE

CIDX

EE

Adapters from third-party providers that are not based on the AE

187

175 BOOK.indb 187

10/2/08 8:56:13 AM

5

EnterpriseIntegrationPatterns

5.12.7 Design Time Overview – Process Integration Scenario Process Integration Scenario

SplitterPattern

Namespace

urn:pi-patterns:pi:eip:common:Splitter:100

Software Component

PI-PATTERNS_EIP COMMON

To demonstrate both implementation variants, we have included two component views in the Process Integration Scenario. The first component view contains the ccBPM-based SplitterPattern scenario, and is structured as shown in Figure 5.61:

Figure 5.61 Splitter-Pattern – ccBPM-Based Process Integration Scenario EE

The first component, MDM System, sends the composite message of the CustomerMasterData type, and represents an MDM system.

EE

The second component represents the Splitter pattern in the form of a ccBPM. The composite CustomerMasterData message is split into individual customer master and address master messages and forwarded to the ERP system. The processing steps within the ccBPM are described in detail in the next section.

188

175 BOOK.indb 188

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:13 AM

Splitter

EE

5.12

The ERP System component receives and processes the DebitorMasterData DEBMAS.DEBMAS06 and AdressMasterData ADRMAS.ADRMAS02 messages.

The second component view of the process integration scenario contains the Integration Scenario of the message bulking-based approach, and is structured as shown in Figure 5.62: EE

The first component, MDM system, sends the composite message of the CustomerMasterData type, and represents an MDM system.

EE

The ERP System component receives and processes the DebitorMasterData DEBMAS.DEBMAS06 and AdressMasterData ADRMAS.ADRMAS02 messages.

Figure 5.62 Splitter Pattern – Message Bulking-Based Process Integration Scenario

The Splitter pattern is not visible within the Process Integration Scenario because the message bulking function is defined at Configuration Time. The 1:n mapping is executed within the AE at runtime. Overview – Integration Process Integration Process

SplitterPattern

Namespace

urn:pi-patterns:pi:eip:common:Splitter:100

Software Component

PI-PATTERNS_EIP COMMON

189

175 BOOK.indb 189

10/2/08 8:56:14 AM

5

Enterprise Integration Patterns

For each customer master message of the MDM system, a process instance of the SplitterPattern ccBPM is opened, which generates a debtor master message and an address master message from the inbound customer master message within a 1:n multi-mapping, and sends these to the ERP system (see Figure 5.63). The Splitter pattern Integration Process is structured as follows: 1 Receive step for the CustomerMasterData message 2 Extraction of the CustomerNumber for exception handling 3 Call of the n:1 mapping 4 Send step for sending the DEBMAS_DEBMAS06 message 5 Send step for sending the ADRMAS_ADRMAS02 message U A Handler for MappingException (R 3), generates an alert U B Handler for TransportException (R 4,5), generates an alert

A

B

1

2

3

4

5

Figure 5.63  Splitter Pattern – Integration Process

190

175 BOOK.indb 190

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:14 AM

Splitter

5.12

5.12.8 Configuration Time As already explained in relation to Design Time (see Section 5.12.7), the Process Integration Scenario contains two component views, which we will configure separately. To uniquely identify each of these Configuration Scenarios, we‘ve used the suffixes ccBPM and MessageBulking when naming the scenarios. Let’s start with the ccBPM-based scenario. Overview – Configuration Scenario – ccBPM-Based Configuration Scenario

PI_PATTERNS_EIP_SPLITTERPattern_ccBPM

The Model Configurator facilitates the configuration process. Use the SplitterPattern Process Integration Scenario of the COMMON component (described previously) and the first component view it contains (the ccBPM-based approach) as a template. A schematic overview of the configuration is provided in Figure 5.64. Templates that can be used in the Model Configurator are provided for the individual Communication Channels. The sender service uses a file adapter and accesses an XML file. The XML file contains a customer master record. The receiver service uses an IDoc adapter to send the data to the SAP ERP system. EIP_DEV_LEGACY_3RD_001

SplitterPatternProcess

EIP_DEV_R3E_EIP_100

Figure 5.64  Splitter-Pattern – ccBPM-Based Configuration Scenario

Sender Communication Component Communication Component (Business System)

EIP_DEV_LEGACY_3RD_001

Communication Channel

File_SND_PI_PATTERNS_EIP_LEGACY_ CustomerMasterData

191

175 BOOK.indb 191

10/2/08 8:56:15 AM

5

Enterprise Integration Patterns

Table 5.41 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

File

Source File Name

12_CustomerMasterData_PB.csv

Processing Quality of Service

Exactly Once

Table 5.41  Splitter-Pattern – Sender Configuration Parameters (ccBPM)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file). Integration Process Communication Component

SplitterPatternProcess

Wizard-based generation

The Splitter pattern Integration Process can be configured (generated) using the Model Configurator. Use the SplitterPatternProcess as a reference.

Receiver Communication Component Communication Component (Business System)

EIP_DEV_R3E_EIP_100

Communication Channel

IDoc_RCV_PI_PATTERNS_EIP_ERP

Table 5.42 provides detailed information for specific parameters of the Communication Channel.

192

175 BOOK.indb 192

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:15 AM

Splitter

5.12

Parameter Adapter Type

IDoc Receiver

Transport Protocol

IDoc

Message Protocol

IDoc

Table 5.42  Splitter-Pattern – Receiver Configuration Parameters (ccBPM)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values. Overview – Configuration Scenario – Message Bulking-Based Configuration Scenario

PI_PATTERNS_EIP_SPLITTERPattern_Bulking

The Model Configurator facilitates the configuration process. Use the SplitterPattern Process Integration Scenario of the COMMON component (described previously) and the second component view it contains (the message bulking-based approach) as a template. A schematic overview of the configuration is provided in Figure 5.65. EIP_DEV_LEGACY_3RD_002

EIP_DEV_R3E_EIP_100

Figure 5.65  Splitter Pattern – Message Bulking-Based Configuration Scenario

Templates that can be used in the Model Configurator are provided for the individual Communication Channels. The sender service uses a file adapter and accesses an XML file. The XML file contains a customer master record. For demonstration purposes, the IDoc-XML-based messages are sent to two file adapters that support the message bulking function. Because it is not possible to define the use of the message bulking function within the Process Integration Scenario at Design Time, the generated interface determination must be adjusted manually.

193

175 BOOK.indb 193

10/2/08 8:56:15 AM

5

Enterprise Integration Patterns

Sender Communication Component Communication Component (Business System)

EIP_DEV_LEGACY_3RD_002

Communication Channel

File_SND_PI_PATTERNS_EIP_LEGACY_ CustomerMasterData

Table 5.43 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Sender

Transport Protocol

File system (NFS)

Message Protocol

File

Source File Name

12_CustomerMasterData_MB.csv

Processing Quality of Service

Exactly Once

Table 5.43  Splitter Pattern – Receiver Configuration Parameters (Message Bulking)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, to access the test file). Receiver Communication Component 1 Communication Component (Business System)

EIP_DEV_R3E_EIP_100

Communication Channel

File_RCV_PI_PATTERNS_EIP_ERP_DEBMAS_ DEBMAS06

Table 5.44 provides detailed information for specific parameters of the Communication Channel.

194

175 BOOK.indb 194

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:15 AM

Splitter

5.12

Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name

12_DEBMAS_DEBMAS06_MB

Processing File Generation Mode

Add time stamp

Table 5.44  Splitter Pattern – Receiver 1 Configuration Parameters (Message Bulking)

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory). Receiver Communication Component 2 Communication Component (Business System)

EIP_DEV_R3E_EIP_100

Communication Channel

File_RCV_PI_PATTERNS_EIP_ERP_ADRMAS_ ADRMAS02

Table 5.45 provides detailed information for specific parameters of the Communication Channel. Parameter Adapter Type

File Receiver

Transport Protocol

File system (NFS)

Message Protocol

File

Target File Name

12_ADRMAS_ADRMAS02_MB

Processing File Generation Mode

Add time stamp

Table 5.45  Splitter-Pattern – Receiver 2 Configuration Parameters (Message Bulking)

195

175 BOOK.indb 195

10/2/08 8:56:15 AM

5

Enterprise Integration Patterns

Use default values for any parameters not specified here, or — if required — use system- and environment-specific values (for example, for the generated file’s target directory). Interface Determination After the wizard-based configuration of the Configuration Scenario is completed, you must manually specify the n:1 mapping within the Interface Determination to configure message bulking. Open the generated Interface Determination and change its type from standard to enhanced. You can then select an Operation Mapping. Select the following Operation Mapping and save and activate your changes: Name

IM_CustomerMasterData_OB_TO_DEBMAS_DEBMAS06_AND_ ADRMAS_ADRMAS02

Namespace

urn:pi-patterns:pi:eip:common:Splitter:100

5.12.9 Runtime You will find test files for both implementation approaches in the download directory that follows. The content of both files is identical, but they require different names to prevent the sender file adapters from attempting to access them concurrently. Test file

12_CustomerMasterData_PB.xml

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_LEGACY_3RD_001

The XML file contains a customer master record for ccBPM-based processing. Test file

12_CustomerMasterData_MB.xml

Directory

04 Sample Files

Communication Component (Business System)

EIP_DEV_LEGACY_3RD_001

196

175 BOOK.indb 196

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:15 AM

Summary

5.13

The XML file contains a customer master record for message bulking-based processing.

5.13

Summary

This chapter has described twelve frequently used enterprise integration patterns, each of which focuses on one specific aspect of integration. In day-to-day work scenarios, a combination of several patterns is often required to solve a certain problem. The next chapter provides a detailed introduction to installing and configuring the files that can be downloaded with this book.

197

175 BOOK.indb 197

10/2/08 8:56:16 AM

© 2014 by Galileo Press Inc., Boston (MA)

175 BOOK.indb 198

10/2/08 8:56:16 AM

6

Installing and Configuring Downloads

This chapter describes in detail how to install the software supplied with this book in your SAP NetWeaver PI system. To install this software, follow these steps: 1. Download the software. 2. Import the SLD objects. 3. Define the SLD objects. 4. Import the ESR objects. 5. Deploy the Java proxy.

6.1

Downloading the Software

The current version of the software supplied with this book is available on the book’s dedicated website (www.sap-press.com). Under Book Updates, you can download the zip archive called Enterprise Integration Patterns (registration is required before downloading for the first time). The software download is organized into the following subdirectories (see Figure 6.1): EE

The 01 SLD Content directory contains the CIM models of the required SLD objects. The import is described in Section 6.2, Importing the SLD Objects.

EE

The 02 ESR Content directory contains the objects of the software components, which are imported as described in Section 6.4, Importing the ESR Objects.

EE

In the 03 Java Proxy directory, you will find the Java proxy required for the Guaranteed Delivery pattern described in Section 5.7, Guaranteed Delivery Pattern. The Java proxy is provided in the form of a deployable SDA. The deployment is described in Section 6.5, Deploying the Java Proxy.

EE

The sample files of the various patterns are contained in the 04 Sample Files directory.

199

175 BOOK.indb 199

10/2/08 8:56:16 AM

6

InstallingandConfiguringDownloads

Figure 6.1 Directory Structure of the Software Download

6.2

Importing the SLD Objects

Before you can use the software components provided, you must first load these as CIM data into the SLD. The relevant files are in the 01 SLD Content subdirectory.

6.2.1

Importing the CIM Content

To import the SLD objects, follow these steps: 1. Log on to the SLD. Before you do this, check that your SAP NetWeaver PI profile has the administrator rights required to access the SLD. Alternatively, complete the following steps together with your SLD administrator. 2. Select Administration and then select Import in the Content area of the menu that appears. Select the first zip file to be imported (PI-PATTERNS_EIP COMMON.zip) and start the import (Import…). Figure 6.2 shows the import of the CIM content.

Figure 6.2 Importing the CIM Content

200

175 BOOK.indb 200

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:16 AM

Importing the SLD Objects

6.2

3. A new window opens, informing you that you are performing a special import. Click on Continue Import to confirm. 4. Repeat these steps to import the following files: EE

PI-PATTERNS_EIP ERP.zip

EE

PI-PATTERNS_EIP LEGACY.zip

EE

PI-PATTERNS CANONICAL.zip

6.2.2 Defining Usage Dependency To reuse objects within the PI-PATTERNS_EIP COMMON component, you must define usage dependencies. To do this, proceed as follows: 1. Click on Home to go to the SLD Homepage. 2. Under Software Catalog, select the Software Components menu option. 3. Enter “PI-PATTERNS” as a search string in the filter field and select Go. The four software components you imported earlier are shown. 4. Select the PI-PATTERNS_EIP COMMON software component. Detailed information about this component is displayed in the Web Dynpro area in the lower part of the screen. 5. Select the Dependencies tab. Next, select Define Prerequisite Software Component Versions. A new Web Dynpro appears, which you can use to search for software components. 6. Leave InstallationTime as the context selection and search for PI-PATTERNS in the filter area. To do this, enter the search term and click on the filter icon. Select the three components (you can use the [Shift] key for multiple selections). Select Define Prerequisite Software Component Versions to confirm your selection. 7. Repeat these steps for the SAP BASIS (Version 7.10) software component. The dependency definition appears, as shown in Figure 6.3.

201

175 BOOK.indb 201

10/2/08 8:56:16 AM

6

InstallingandConfiguringDownloads

Figure 6.3 Dependency Definition

6.3

Defining the SLD Objects

To simplify the configuration of individual scenarios, the Configuration Wizard is used for the configuration of the pattern examples. The wizard allows the configuration based on business systems for A2A scenarios. Therefore, create the following technical systems (see Table 6.1) and business systems (see Table 6.2), as well as their references to the objects in the software catalog. This will minimize the effort involved in configuration. Technical System

Installed Software Component

EIP_DEV_R3E_EIP_100

PI-PATTERNS_EIP ERP 1.0

EIP_DEV_LEGACY_3RD_001

PI-PATTERNS_EIP LEGACY 1.0

EIP_DEV_LEGACY_3RD_002

PI-PATTERNS_EIP LEGACY 1.0

EIP_DEV_LEGACY_3RD_003

PI-PATTERNS_EIP LEGACY 1.0

Table 6.1 Technical Systems for This Book

202

175 BOOK.indb 202

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:17 AM

Defining the SLD Objects

Business System

SWC Reference

EIP_DEV_R3E_EIP_100

PI-PATTERNS_EIP ERP 1.0

EIP_DEV_LEGACY_3RD_001

PI-PATTERNS_EIP LEGACY 1.0

EIP_DEV_LEGACY_3RD_002

PI-PATTERNS_EIP LEGACY 1.0

EIP_DEV_LEGACY_3RD_003

PI-PATTERNS_EIP LEGACY 1.0

6.3

Table 6.2  Business Systems for This Book

Note To simplify the configuration process, the same name is used for technical and business systems. This would not be the case in a real-life implementation because an infrastructure component serves as a technical system, while a logical view defines a business system. Alternatively, you can define your own systems. If you do so, simply replace the systems named in the configuration instructions with your own systems.

The following sections explain how to create technical and business systems.

6.3.1

Creating Technical Systems

To create technical systems, follow these steps: 1. Log on to the SLD and select Technical Systems in the Landscape area. 2. To create a new system, select New Technical System... in the new Web Dynpro. 3. Select Third-Party as the system type and click Next to continue. 4. Enter the name of the technical system as the system name (in this example, EIP_DEV_LEGACY_3RD_001). As the host name you can, for example, enter “unknown” if you do not know the name of the host. Figure 6.4 shows the definition of a technical system. Click on Next to continue. 5. Select the installed software component via the product, and click on Finish to assign it. You can use the filter function to simplify the search. Figure 6.5 shows the assignment of a software component to a technical system.

203

175 BOOK.indb 203

10/2/08 8:56:17 AM

6

InstallingandConfiguringDownloads

Figure 6.4 Creating a Technical System

Figure 6.5 Assigning the Installed Software Components

Repeat these steps for the other technical systems shown in Table 6.1.

6.3.2 Creating Business Systems To create the business systems listed in Table 6.2, follow these steps: 1. Log on to the SLD and select Business Systems in the Landscape area. 2. To create a new system, select New Business System... in the new Web Dynpro.

204

175 BOOK.indb 204

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:18 AM

Defining the SLD Objects

6.3

3. Select Third-Party as the system type and click on Next to continue. 4. Select the corresponding technical system from the dropdown list. In our example, we want to define the business system called EIP_DEV_LEGACY_3RD_001, and so we select the technical system with the same name. It is not necessary to specify a logical system to configure the pattern. Therefore, click on Next to continue. 5. Enter the name of the business system (for example, EIP_DEV_LEGACY_​ 3RD_001), and click on Next to continue. 6. Click on Next again to continue and confirm the installed software component that is preselected. 7. Finally, select the integration server assigned to the business system and click on Finish to complete the creation of the business system. The newly created business system is shown in Figure 6.6.

Figure 6.6  Defining a Business System

Repeat these steps for the other business systems shown in Table 6.2.

205

175 BOOK.indb 205

10/2/08 8:56:18 AM

6

InstallingandConfiguringDownloads

6.3.3 Importing the Business Systems into the Integration Directory The final step is to import the newly defined business systems into the Integration Directory so that they are available at Configuration Time. To do this, proceed as follows: 1. Log on to the Integration Directory. 2. Select Communication Component to navigate to Business System and select Assign Business System… in the context menu. A wizard appears. 3. To continue after the introduction, click on continue. 4. Click on Continue without defining a partner. 5. Select the business systems to be imported from the list shown and deactivate the Create Communication Channels Automatically checkbox. Figure 6.7 shows the selection of business systems from the SLD.

Figure 6.7 Selecting the Business Systems

206

175 BOOK.indb 206

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:19 AM

Importing the ESR Objects

6.4

6. Click on Finish. The business systems are now listed under Communication Component • Business System. 7. Finally, activate the change list. The business systems can now be used to configure the pattern scenarios. Note If the business systems to be imported do not appear in the selection list, refresh the SLD cache. To do this, select Environment • Clear SLD Data Cache.

6.4

Importing the ESR Objects

Before you can start to download the software components supplied with this book, you must execute the actions in the SLD that are specified in Section 6.2. To then import the software components into the ESR, follow these steps: 1. Log on to the ESR. 2. Select Tools • Import Design Objects… 3. Select client as the source for the import. 4. Select the relevant tpz file. You will find the following import files in the 02 ESR Content directory: EE

XI7_1_PI-PATTERNS_EIP_COMMON_1.0.tpz

EE

XI7_1_PI-PATTERNS_EIP_ERP_1.0.tpz

EE

XI7_1_PI-PATTERNS_EIP_LEGACY_1.0.tpz

EE

XI7_1_PI-PATTERNS_CANONICAL_1.0.tpz

5. Next, check that the settings defined in the SLD have been transferred without any errors. The usage dependencies defined in Section 6.2, Importing the SLD Objects, are visible in the ESR as Basis Object references. 6. Open the Basis objects of PI-PATTERNS_EIP COMMON, and check that all referenced software component versions are visible (see Figure 6.8).

207

175 BOOK.indb 207

10/2/08 8:56:19 AM

6

InstallingandConfiguringDownloads

Figure 6.8 Basis Components

If this is not the case, you can synchronize the SLD information manually, as follows: 1. Select the PI-PATTERNS_EIP COMMON 1.0 software component version and switch to change mode. 2. To update the SLD information, select Tools • Update SLD Information. The underlying software component versions should then be displayed, as shown in Figure 6.9.

Figure 6.9 Updating the SLD Information

208

175 BOOK.indb 208

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:19 AM

Deploying the Java Proxy

6.5

6.5

Deploying the Java Proxy

A Java proxy must be deployed on the JEE server to demonstrate the Guaranteed Delivery pattern (see Chapter 5, Section 5.7). The Java proxy is provided in the form of an SDA archive, and can be deployed using the Java Support Package Manager (JSPM). Contact your system administrator to obtain information about the deployment. The steps involved are not specified here because this is a standard procedure and an administrator profile is normally required. The file to be deployed is called GuaranteedDeliveryPattern.sda, and is contained in the 03 Java Proxy directory of the download archive. After deployment, the Java proxy must be registered. To do this, open a browser window and enter the following URL: http://:/ProxyServer/Register?ns=urn:pi-patterns:pi:eip:erp:GuaranteedDe livery:100&interface=GuaranteedDelivery_IB&bean=localejbs/pi/patterns/GuaranteedD eliveryIB&method=guaranteedDeliveryIB

209

175 BOOK.indb 209

10/2/08 8:56:19 AM

© 2014 by Galileo Press Inc., Boston (MA)

175 BOOK.indb 210

10/2/08 8:56:19 AM

7

Conclusion

A focus on patterns, which are initially independent of tools and technologies, enables you to simplify the analysis process and represent it in a way that can be understood by all involved in implementing an integration scenario. In many cases, patterns can be used to bring the often heated discussions that are part and parcel of most integration projects back to a functional and objective level. They do this by breaking functional problems down into smaller parts that can be understood by all involved. When this is achieved, the tool-dependent, standardized implementation of patterns can then, almost imperceptibly, create a reusability of components and procedures because, in essence, the same approach can be used again and again. However, the approach needs to be reviewed and revised as necessary on an ongoing basis. New versions of implementation tools often offer new functions, which may improve the approach, and these need to be documented and communicated. Because patterns refer to small, defined parts of an integration scenario — and a scenario is usually comprised of several patterns — there is a risk that the bigger picture may be lost during implementation. An experienced integration architect should therefore always have responsibility for checking the implementation as a whole. All of the integration requirements an enterprise may have cannot be covered by the twelve patterns described in this book. However, these patterns can also be combined to fulfill a wide range of requirements. There are other patterns in addition to those described here that could also be considered and standardized within an enterprise. The patterns don’t necessarily have to be implemented exactly as they’ve been described in this book. It is much more important to remain consistent within an integration landscape. In addition to the implementation of patterns and lifecycle management, several other areas within an integration landscape also need to be standardized to optimize development and, above all, ensure smooth operation. These include: EE

Canonical data formats

EE

Security and authorizations

EE

High availability and disaster recovery

211

175 BOOK.indb 211

10/2/08 8:56:20 AM

7

Conclusion

EE

Performance tuning

EE

Sizing

EE

Archiving

EE

Mapping approaches

EE

Change management

EE

Testing

EE

System monitoring, end-to-end monitoring

EE

Operational procedures for error resolution, etc.

To develop and manage a standardized approach within an integration environment, while taking account of non-functional business process requirements, is surely one of the greatest challenges to be faced in today’s global and heterogeneous IT landscapes. We hope that the procedures discussed in this book have provided some helpful approaches for the implementation and management of integration scenarios.

212

175 BOOK.indb 212

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:20 AM

Appendices A

Authors...................................................................................... 215

B

Bibliography............................................................................... 217

213

175 BOOK.indb 213

10/2/08 8:56:20 AM

© 2014 by Galileo Press Inc., Boston (MA)

175 BOOK.indb 214

10/2/08 8:56:20 AM

A

Authors

René de Daniel studied Information Management at the University of Furtwangen in Germany. Even as a student, he was actively involved in global integration projects. Since 2003, he has worked as a consultant on many SAP NetWeaver XI projects. He was involved in setting up the Integration Competence Center at a global oil company in London, one of SAP’s ramp-up customers. Key elements of this project included the definition of an enterprise-wide XI/PI architecture, master SLD strategy, naming conventions, and the definition of methods for implementation; as well as enterprise integration patterns.

He is currently working as Technical Enterprise Architect for a global chemical company, with responsibility for enterprise-wide integration, SAP Roadmap, and application portfolio management. Hermann Steinrötter holds a degree in Computer Science, and works as Manager of ERP Integration at a global oil company. As Head of Technical Architecture for Enterprise Systems, he is responsible for IT architecture in global SAP projects. In addition, he presides over the Integration Competence Center, which implements integration scenarios for global SAP rollouts. For the past ten years, he has been working on ERP integration scenarios and, since the ramp-up of SAP XI 3.0 (2004), developing standards and best practices for implementing integration scenarios based on SAP NetWeaver PI.

215

175 BOOK.indb 215

10/2/08 8:56:20 AM

© 2014 by Galileo Press Inc., Boston (MA)

175 BOOK.indb 216

10/2/08 8:56:20 AM

B EE

Bibliography

Banner, Marcus; Klein, Heinzpeter: Mastering SAP XI 3.0 – Administration. SAP Press Essentials 21. SAP PRESS, Bonn 2005. The authors describe the underlying principles of SAP XI administration, covering everything from configuration to sizing, authorizations, and monitoring.

EE

de Daniel, René: Enterprise Application Integration – Entwicklung eines Integrationskonzepts in der chemischen Industrie. Freiburg 2003. Outlines a blueprint for an integration infrastructure and automation of the order-to-cash process in the context of mergers.

EE

Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (also known as the “Gang of Four”): Design Patterns – Elements of Reusable Object-Oriented Software. Addison-Wesley Longman, Amsterdam 1995. In times like these, when technology is constantly evolving, it is rare for any book to become required reading. This is one of those books and is an essential reference for anyone involved in the development of object-oriented software.

EE

Gangadharan, Sindhu; Illapani, Prasad: “SAP NetWeaver Process Integration 7.1. – an Overview.” In: SAP TechEd 2007, Session EPI210. The authors provide a detailed overview of the new features in NetWeaver PI 7.1, including a roadmap for the future.

EE

Hohpe, Gregor; Woolf, Bobby: Enterprise Integration Patterns. Addison-Wesley Longman, Amsterdam 2003. This book describes in detail 65 design patterns and their applications. The descriptions are abstract but are illustrated by practical examples to explain which packages and modules are required for integration to work. Java and C# source code examples are provided in many cases.

EE

Li, William; Ludwig, Peter: “Design Patterns for SAP NetWeaver Exchange Infrastructure.” In: SAP Teched 2006, Session EPI204. The authors provide easy-to-understand recommendations for various aspects of implementations with SAP NetWeaver PI (ccBPM, mappings, adapters etc.).

EE

Nicolescu, Valentin; Funk, Burkhardt; Niemeyer, Peter: SAP Exchange Infrastructure for Developers. SAP PRESS, Bonn 2006.

217

175 BOOK.indb 217

10/2/08 8:56:20 AM

B

Bibliography

This developer manual for SAP XI begins with an overview of SAP’s serviceoriented architecture, before discussing integration processes in relation to a fictitious retail enterprise. It also describes the interaction between SAP XI and composite applications EE

SAP Library documentation: Unified Key Mapping. Describes the basic principles and APIs of the Unified Key Mapping service.

EE

Steinrötter, Hermann; Liebig, Christoph: SAP PI Performance Survey. DSAG Technology Day. Dresden 2008. In Q1 2008, DSAG (German-Speaking SAP Users’ Group) and ASUG (Americas’ SAP Users’ Group) conducted a global survey on the use of NetWeaver PI. This presentation analyzes the responses to the survey’s 72 questions.

EE

Stumpe, Jens; Orb, Joachim: SAP Exchange Infrastructure. SAP PRESS, Bonn 2005. This book discusses the configuration of SAP XI 3.0, various mappings, integration and a number of basic scenarios. It is considered a standard work on the subject and provides an in-depth insight into the structure and use of SAP XI 3.0.

218

175 BOOK.indb 218

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:20 AM

Index A ABAP Mapping, 155 Stack, 92, 156 XSLT mapping, 154 Absolute validity, 142 Abstract service interface, 84 Abstract software component, 43 Acknowledgement messages, 131 Actions, 52 Adapter Module, 143 Type, 133 Adapter-specific parameters, 64 Advanced Adapter Engine (AAE), 28 Aggregator pattern, 68, 69 Analysis, 31 Application acknowledgement, 132 Application architect, 34 Application-to-application (A2A), 15, 159 Approach, 39 Architecture, 67 ARIS, 48 ASUG, 25 Asynchronous communication, 131, 176

B Batch interfaces, 16 Best practices, 154, 164 Binding, 98 Bulk messaging, 176 Business activity monitoring (BAM), 27 Business object descriptions, 27 Business process, 46, 47 Business process analyst, 34 Business Process Engine (BPE), 28 Business Process Execution Language (BPEL), 26

Business Process Management (BPM), 17, 20, 21, 22, 24 Business system, 202 Business-to-business (B2B), 15, 159

C Caching, 92 Canonical data format, 78, 84 Canonical data model, 44 Canonical data model pattern, 78 Canonical software component, 83 CIDX, 187 CIM data, 200 COMMON software component, 45 Communication channel template, 54, 62 Complexity, 36, 90 Component Assignment, 59 View, 59 Configuration Individual patterns, 55 Scenario, 56 System environment, 54 Time, 39, 68 Content Based Router pattern, 110 Content Enricher pattern, 89 Content Filter pattern, 103 Core Component Type Identifier (CCTI), 93 CORE process component, 46 Correlation, 178 Creation time, 143 Cross-component business process management (ccBPM), 24, 25, 27, 28, 82

D Data Lookup, 90

219

175 BOOK.indb 219

10/2/08 8:56:20 AM

Index

Representation, 153, 158 Structure, 153, 154 Type, 153, 154 Database schemas, 91 Data mart, 19 DataSource, 92 Data warehouse, 19 Dead letter queue, 142, 143 De-facto standard, 81 Deployment, 209 Design, 32 Design time, 39, 68 Developer, 34 Development, 33 Distribution list, 123 Division of responsibilities, 44 DSAG, 25 DUNS, 94 Dynamic receiver determination, 129 Dynamic router pattern, 118

E Electronic Data Interchange (EDI), 159 Encapsulation layer, 92 Enrich, 89 Enterprise Application Integration (EAI), 12, 17, 20, 21, 22 Enterprise Information Integration (EII), 17, 19 Enterprise integration patterns, 12, 67 Enterprise service bus (ESB), 22 Enterprise services, 27 Enterprise Services Repository (ESR), 27, 30 Content, 207 Object, 199 Exactly Once (EO), 131 Exactly Once In Order (EOIO), 131 Exchange Infrastructure (XI), 24 Expiry period, 143 Expiry time, 143 Extensibility, 81 Extensible Stylesheet Language Transformation (XSLT), 19

220

175 BOOK.indb 220

External data source, 89, 119 Extract, Transform, and Load (ETL), 12, 17, 19

F File/FTP, 187 Filter Criteria, 103 Function, 106 Mapping, 104 Fire and forget principle, 131 Fixed-value mapping, 90 Flexibility, 90 FTP, 18 Functional architect, 34 Function module, 93

G Gang of Four (GoF), 11 Generation of configuration objects, 63 Global objects, 81 Global SAP NetWeaver PI instance, 163, 166 Global software component, 45 Go-live, 33 Graphical mapping, 154, 155 Grouped mapping, 93 Guaranteed Delivery pattern, 130 GUID, 89

H Heterogeneous services, 153 HTTP protocol, 178 Human workflows, 21

I IDoc, 133 Conversion, 157 Indirection level, 78

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:20 AM

Index

Indirect mapping, 79 Industry standard, 78, 81 Information reduction, 103 Insert/create operation, 176 Integration Architect, 34 Builder, 28 Directory, 28 Logic objects, 41 Process, 60, 69 Repository, 28 Server, 28 Tools, 23, 24 Integration Competence Center (ICC), 12 IT follows business, 40 IT Infrastructure Library (ITIL), 31

J Java API, 93 Mapping, 155 Proxy, 140 XSLT mapping, 154 Java Connectivity Adapter Engine (JCA), 24 Java Database Connectivity (JDBC), 187 Java Message Service (JMS), 187 Adapter, 142, 178 Java proxy Deployment, 199 Registration, 209 JEE stack, 155

K Key Pairs, 93 User, 33 Value, 89, 90, 111 Value pairs, 90

L Local SAP NetWeaver PI instance, 166

M Mail, 187 Maintainability, 81, 90 Maintenance responsibility, 91 Managed File Transfer (MFT), 17, 18 Mapping Context, 93, 102 Group, 93 Logic, 85 Requirements, 158 Technologies, 158 Marketplace, 187 Master data management (MDM), 91 Message Bulking, 27, 187 Expiry period, 142 Filter, 103 Mapping, 53 Protocol, 158 Message-based aggregation, 70 Message Bridge pattern, 162 Message Expiration pattern, 141 Message-oriented middleware (MOM), 20 Message Translator pattern, 153 Message type-based aggregation, 70 Messaging Bridge pattern, 163 Messaging layer, 132 Metadata model, 78 Metadata store, 28 Metrics, 37 Model Configurator, 55, 57 Modeling concept, 39

N n multi-mapping, 186, 190 Namespace, 49

221

175 BOOK.indb 221

10/2/08 8:56:20 AM

Index

Naming convention, 39, 45, 56 NetWeaver 2004, 24 Non-functional requirements, 36

O OASIS Web Service Security Standard, 144 Open PI Initiative (OPI2), 162 Open-source project, 162 Operation mapping, 53, 83 Optimization, 33 Orchestration components, 177 Order-to-cash, 47 Organization of software components, 39 OSI reference model, 153

P Parameterized mapping programs, 96, 145 Pattern, 36, 67 Aggregator, 68 Canonical Data Model, 78 Content Based Router, 110 Content Enricher, 89, 103 Dynamic Router, 118 Guaranteed Delivery, 130 Message Bridge, 162 Message Expiration, 141 Message Translator, 153 Request/Reply, 175 Splitter, 185 Performance, 25, 155 Permanent acknowledgement, 133 Persistence, 70, 131 PI Adapter Framework, 160 PI-PATTERNS_EIP COMMON, 54 PI-to-PI communication, 163 PI-to-PI scenario, 165 PI value mapping, 91 Planning, 32 Power user, 33 Problem, 67

222

175 BOOK.indb 222

Process component model, 28 Process integration scenario, 49, 51 Process-oriented component strategy, 46 Production support, 33 Protocol, 153 Proxy, 133 Publish and subscribe, 119

Q Quality of Service (QoS), 20, 131 Queue, 131

R RACI, 35 Real time, 19 Receiver determination, 112, 117, 120 Recipient list, 119 Registry, 30 Regression test, 80 Relative validity, 142 Reliability, 31 Reply message, 178 Reprocessing, 131, 132 Request message, 178 Request/Reply pattern, 175, 176 Reusability, 83 RFC, 187 RNIF, 187 Routing Conditions, 111 Rule, 112 Runtime, 39, 68 Runtime Workbench (RW), 28

S Sample scenarios, 45 SAP Basis, 34 SAP Business Connector, 187

© 2014 by Galileo Press Inc., Boston (MA)

10/2/08 8:56:20 AM

Index

SAP NetWeaver PI, 24, 25, 26, 28, 30 SAP NetWeaver PI-specific implementation, 67 Security Assertion Markup Language (SAML), 26 Security requirements, 31 Semantic association, 70 Semantic dependency, 70 Serial order, 176 Service delivery, 165 Service level agreement (SLA), 33 Service objects, 41 sFTP, 18 SLD content, 55 SOAP, 187 Software component strategy, 40, 41 Software download, 199 Sorting requirements, 156 Splitter, 186 Splitter pattern, 185 Stability, 25 Stateful, 176 Stateless, 176 Step-by-step configuration, 55 Stored procedure, 178 Swimlane, 52 Synchronous communication, 176 System acknowledgement, 132 System Landscape Directory (SLD), 27, 164 Object, 199

T Target field mapping, 96 Technical systems, 202 Test environment, 155 Testing, 33 Three-component strategy, 43, 49, 81 Time-based aggregation, 70 Time to live, 142

Top-down approach, 49, 50, 52 Total cost of ownership (TCO), 78 Transferability, 31 Transformation, 154 Transient acknowledgement, 133 Two-component strategy, 42

U UKM_ADD_KEY_MAPPINGS, 102 UKM_DELETE_KEY_MAPPING, 102 UKM_GET_KEY_MAPPINGS, 102 Unified Key Mapping Service (UKMS), 92 Lookup function, 96 Universal Description, Discovery, and Integration (UDDI), 26, 30 Update operation, 176 Usage dependency, 81, 98, 201

V Validity, 141 Value mapping, 90, 123 Value mapping agencies, 129

W Web Services Definition Language (WSDL), 27 Workflow, 20 WS-RM, 26

X XPath, 112 XSL stylesheet, 107 XSLT, 104

223

175 BOOK.indb 223

10/2/08 8:56:20 AM

Service Pages The following sections contain notes on how you can contact us.

Praise and Criticism We hope that you enjoyed reading this book. If it met your expectations, please do recommend it, for example, by writing a review on http://www.sap-press.com. If you think there is room for improvement, please get in touch with the editor of the book: [email protected]. We welcome every suggestion for improvement but, of course, also any praise!

Technical Issues If you experience technical issues with your e-book or e-book account at SAP PRESS, please feel free to contact our reader service: [email protected].

About Us and Our Program The website http://www.sap-press.com provides detailed and first-hand information on our current publishing program. Here, you can also easily order all of our books and e-books. For information on Galileo Press Inc. and for additional contact options please refer to our company website: http://www.galileo-press.com.

Legal Notes This section contains the detailed and legally binding usage conditions for this e-book.

Copyright Note This publication is protected by copyright in its entirety. All usage and exploitation rights are reserved by the author and Galileo Press; in particular the right of reproduction and the right of distribution, be it in printed or electronic form. © 2009 by Galileo Press Inc., Boston (MA)

Trademarks The common names, trade names, descriptions of goods, and so on used in this publication may be trademarks without special identification and subject to legal regulations as such. All of the screenshots and graphics reproduced in this book are subject to copyright © SAP AG, Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany. SAP, the SAP logo, mySAP, mySAP.com, SAP Business Suite, SAP NetWeaver, SAP R/3, SAP R/2, SAP B2B, SAPtronic, SAPscript, SAP BW, SAP CRM, SAP EarlyWatch, SAP ArchiveLink, SAP HANA, SAP GUI, SAP Business Workflow, SAP Business Engineer, SAP Business Navigator, SAP Business Framework, SAP Business Information Warehouse, SAP interenterprise solutions, SAP APO, AcceleratedSAP, InterSAP, SAPoffice, SAPfind, SAPfile, SAPtime, SAPmail, SAP-access, SAP-EDI, R/3 Retail, Accelerated HR, Accelerated HiTech, Accelerated Consumer Products, ABAP, ABAP/4, ALE/WEB, Alloy, BAPI, Business Framework, BW Explorer, Duet, Enjoy-SAP, mySAP.com e-business platform, mySAP Enterprise Portals, RIVA, SAPPHIRE, TeamSAP, Webflow, and SAP PRESS are registered or unregistered trademarks of SAP AG, Walldorf, Germany.

Limitation of Liability Regardless of the care that has been taken in creating texts, figures, and programs, neither the publisher nor the author, editor, or translator assume any legal responsibility or any liability for possible errors and their consequences.