SAP NetWeaver Process Integration 7.

1 ES Repository Service Interfaces

SAP NetWeaver Regional Implementation Group SAP NetWeaver Product Management December 2007

SAP NetWeaver Process Integration 7.1

Benefits

After reading this document, you will be able to: Understand what a Service Interface is, how it has evolved from the Message Interface, and the main deltas between the two Understand what an Interface Pattern is, the different types available, and which are relevant for PI usage

SAP NetWeaver Process Integration 7.1

Agenda

1. Service Interface Overview 2. Interface Pattern

SAP NetWeaver Process Integration 7.1

Agenda

1. Service Interface Overview 2. Interface Pattern

SAP NetWeaver Process Integration 7.1

Service Interface Background

Transition Integration Repository ES Repository Message Interface Service Interface Similar guiding principles still apply Outside-in interface design approach still applies Interface Category Inbound, Outbound, Abstract Interface Mode Asynchronous, Synchronous Design Data Type, Message Type Service Interface Main Deltas Service Interfaces may contain several Operations Each Operation describes one communication (synchronous or asynchronous) Interface Patterns and Operation Patterns Matching Service Interfaces Changes driven by enterprise SOA initiatives (but not all changes relevant for PI usage)

With SAP NetWeaver 2004, only the Integration Repository existed. The transition to the Enterprise Services Repository began with SAP NetWeaver 2004s, but still without the term Service Interfaces, just Message Interfaces. Now, with a Service Oriented Architecture as a base and SAPs drive toward enterprise SOA, with the next major NetWeaver release, the Integration Repository and the Message Interface has fully transitioned and evolved into the Enterprise Services Repository and Service Interface. Many of the guiding principles from the previous NetWeaver releases were also carried forward to this next major NetWeaver release and still apply. For example, the outside-in design approach still holds and many of the service interface attributes such as the category, mode, and data type/message type still remain the building blocks of the service interface. The main deltas or new aspects of the service interface, even including its name, are primarily driven by the requirements of the enterprise SOA initiative. Service Interfaces, at least as it relates to Exchange Infrastructure (XI), fundamentally, has not changed much at all.

SAP NetWeaver Process Integration 7.1

Service Interface Overview

Service Interface Platform and language independent Describe operations to be implemented (e.g. leveraging proxy generation) in an application system Used in mediated scenarios via Integration Server or Direct Connection (p2p scenarios) via Web Service Runtime Constructed with: Message Types, Data Types, and Fault Message Types (optional) RFC or IDoc metadata External Definitions (e.g. WSDL, XSD, DTD) Attributes Category - Inbound (Provider), Outbound (Consumer), Abstract (Enhanced/Mediated communication using Integration Process) Can only have interface patterns Stateless and Stateless (XI 3.0 compatible); for inbound/outbound, all interface patterns apply Mode (synchronous, asynchronous) Interface Patterns (stateless, stateless (XI 3.0-compatible), stateful, tu&c/c) Operation Patterns (depends on interface pattern; e.g. Normal, Confirm, etc.)

The Service Interface remains platform and language independent and basically describes a single operation or multiple operations to be implemented in an application system. SAP application systems can leverage proxy generation to facilitate the implementation. The Service Interface can be used in mediated scenarios with the Integration Server and direct point-to-point (p2p) scenarios via the Web Service Runtime. Each operation of a Service Interface is linked to a description of the message structure in the form of an ES Repository Message Type, RFC or IDoc metadata, or an external format in the form of a WSDL, XSD, or DTD. The general attributes of a service interface still include the category (e.g. inbound/outbound/abstract) and mode (synchronous, asynchronous). Inbound and outbound are still terms from the application perspective. As such, and now with a more service-oriented view, inbound interfaces are portrayed with the provider role and outbound interfaces with the consumer role. Probably the key change with the next major NetWeaver release is a new attribute called interface pattern which will significantly dictate how a Service Interface is implemented on the back-end. The chosen interface pattern drives the available operation patterns options that are available. More details on Interface Pattern will be discussed in later slides.

SAP NetWeaver Process Integration 7.1

Service Interface UI Layout

Service Interface Attributes (Category and Interface Pattern)

Operation List

Operations Attributes (Operation Pattern and Mode)

Messages of an Operation

The Service Interface design screen within the ES Repository has undergone some changes as well. Here, looking first at a plain template screen, you can see four major areas that make-up or define a service interface: The main service interface attributes (category and interface pattern) along with the a given operation will determine the operation attributes (operation pattern and selectable mode) and the message associated with a particular operation. Also, an example screenshot of the actual UI for the Service Interface design screen for the actual look and feel

SAP NetWeaver Process Integration 7.1

Service Interface UI Layout

Service Interface Attributes (Category and Interface Pattern)

Operation List

Operations Attributes (Operation Pattern and Mode)

Messages of an Operation

SAP NetWeaver Process Integration 7.1

Agenda

1. Service Interface Overview 2. Interface Pattern

SAP NetWeaver Process Integration 7.1

Interface Pattern

Communication Terms
Stateless communication Stateful communication Terms relate to state at the provider and not the Integration Server Not to be confused with stateful Integration Processes (e.g. using message correlation)

Interface Patterns using XI Runtime and XI Adapter

Stateless (XI 3.0 Compatible)

Interface Patterns using Web Service Runtime

Stateless (via WS adapter in mediated scenarios) Stateful (mediated scenarios not supported) TU&C/C (via WS adapter in mediated scenarios)

Note: Interface Pattern is tightly coupled to the application communication

Each service interface must be assigned an interface pattern. The interface pattern basically describes the type of communication that is to be executed on the message. When referring to stateless communication, this is a type of communication in which the messaging runtime does not support the saving of a status of a message at the provider once the messaging runtime has completed the message exchange successfully. In contrast, when we refer to stateful communication, this is a type of communication in which the messaging runtime does support the saving of a status at the provider once the messaging runtime has completed the message exchange successfully. Note that the messaging runtime can explicitly support or not support such a procedure. If the messaging runtime supports stateful communication, the application programmer can use the corresponding methods of the messaging runtime. Furthermore, when talking about interface patterns of a service interface, these terms (stateless and stateful) relate to the state at the provider and not on the Integration Server (in the case of enhanced communication). Therefore, when selecting a stateless interface pattern you can still enhance the communication using the Integration Server to include the execution of a stateful integration process that permits message correlation. So this is to say that these terms are not to be confused when the Integration Server is involved in mediated communication, especially when a stateless interface pattern and a stateful integration process (e.g. using message correlation) is used in the same scenario. In terms of how an interface pattern is related to which runtime is used, the stateless (XI 3.0-compatible) pattern uses the XI runtime via the XI adapter and the rest of the interface patterns (stateless, stateful, and tu&c/c) use the web service runtime (and WS adapter in mediated scenarios). Note that the stateful interface pattern is never supported in mediated scenarios via the Integration Server. Finally, the selected interface pattern determines how an application developer programs communication in the back end, thus the interface pattern is tightly coupled to the application communication. If you change the interface pattern, the application program in the back end must also be changed. For example, this applies if the interface pattern is changed from Stateless (XI 3.0-Compatible) to Stateless, and for any other interface pattern change.

SAP NetWeaver Process Integration 7.1

10

Interface Patterns and Operation Patterns

Each Interface Pattern has specific Operation Pattern(s) and Mode(s)
Interface Pattern
Stateless

Operation Pattern
Normal Operation

Mode
Synchronous or Asynchronous

Stateless (XI 3.0 compatible)

Normal Operation

Synchronous or Asynchronous

Normal Operation Stateful Commit Operation Rollback Operation

Synchronous Synchronous Synchronous

Normal Operation

Synchronous or Asynchronous

Tentative-Update Operation TU&C/C Confirm Operation Compensate Operation

Synchronous Asynchronous Asynchronous

This table summarizes the relationship between interface pattern, operation pattern, and mode.

SAP NetWeaver Process Integration 7.1

11

Interface Pattern Stateless & Stateless (XI 3.0compatible)

Stateless
Single or multiple operations can be defined WS Runtime via WS adapter Point-to-Point communication using web services

Stateless (XI 3.0-compatible)

Message Interfaces from NetWeaver 2004s are migrated to service interfaces with this interface pattern Current recommended interface pattern for XI/PI specific scenarios via existing technical adapters (not using WS adapter) Only one operation allowed and name of service interface and operation must be identical XI runtime and XI adapter

Additional Notes
For most enhanced/mediated scenarios, stateless or stateless (XI 3.0-compatible) pattern should be used Abstract interfaces can only use stateless or stateless (XI 3.0-compatible)

During service interface design, if it is known that an integration scenario is to be mediated via the Integration Server, the most likely interface patterns to use are stateless or stateless (XI 3.0-compatible). These two interface patterns should account for the vast majority of integration scenarios that require mediated services within the integration server. The stateless interface pattern is also used in point-topoint (p2p) communication using web services. As listed here, the stateless interface pattern allows for single or multiple operations. It leverages the WS runtime and WS adapter in p2p and mediated communication. The stateless (XI 3.0-compatible) interface pattern is used for all existing NetWeaver 2004 and NetWeaver 2004s messages interfaces that are to be migrated to service interfaces. It is currently the recommended pattern for the XI/PI specific scenarios that use the common technical adapters such as file, jdbc, jms, etc. basically all the adapters except the WS adapter. However, this pattern is limited to operation and the name of the service interface and operation must be identical. And of course, the XI runtime is used. The XI adapter is used certain scenarios as in the past for example, when proxies are involved. As mentioned, most enhanced/mediated scenarios will use the stateless and stateless (XI 3.0compatible) pattern. Also note that these are the only two interface patterns allowed for abstract interfaces.

SAP NetWeaver Process Integration 7.1

12

Proxy Generation Stateless (XI 3.0-compatible)

Proxy Generation Comparison
Stateless (XI30Compatible Pattern

One Operation

One Proxy Method

When multiple operations of a service interface are defined, proxy generation accounts for each of the operations as separate interface methods in the generated proxy definition. Stateless (XI30-compatible) interface pattern with one operation: This pattern only allows for, at most, one operation. Plus, the operation name must be equal to the service interface name When a proxy is generated, one corresponding proxy method is generated for the one operation within the service interface.

SAP NetWeaver Process Integration 7.1

13

Proxy Generation Stateless

Proxy Generation Comparison

Stateless Pattern

Multiple Operations

Multiple Proxy Methods

When multiple operations of a service interface are defined, proxy generation accounts for each of the operations as separate interface methods in the generated proxy definition. Stateless interface pattern with four operations: When the proxy is generated for this service interface, four separate proxy methods also get generated corresponding to each operation defined. No major surprise here, but mainly an illustration of what the proxy generation might look like for a service interface with multiple operations.

SAP NetWeaver Process Integration 7.1

14

Interface Pattern TU&C/C

Tentative Update & Confirm/Compensate (TU&C/C)

Reliable means to make synchronous update calls Single or multiple update calls treated as one transaction Based on guaranteed delivery concept/mechanism for asynchronous messages Requires at least three messages: one or more for the Tentative Update calls (synchronous) exactly one Compensate (asynchronous) exactly one Confirm (asynchronous) additional Normal operations can be added (asynchronous or synchronous) Synchronous update calls are tentatively recorded until one of either Confirm (COMMIT) or Compensate (ROLLBACK) message is finally received. Web Service Runtime ensures delivery of Compensate message in all error or failure situations compensate message registered before the first call of tentative update operation Both provider and consumer must understand protocol Only suitable in A2A scenarios, not B2B

In terms of significance to PI, the interface patterns TU&C/C and, especially Stateful, are not very important. Nevertheless, its helpful to at least touch on these interface patterns since these options are readily available in the UI. TU&C/C stands for Tentative Update & Confirm/Compensate. This pattern has been developed to fill the gap in transactional behavior that currently exist today with synchronous messages. Synchronous messages, by their nature, cannot provide guaranteed delivery in and of themselves in cases of system or communication failure the way asynchronous messages can. Leveraging the guaranteed delivery capabilities of asynchronous messages, the TU&C/C pattern provides a reliable means to make one of more synchronous update calls in a transactional context. At its most basic level, the TU&C/C interface pattern requires three message: one for the Tentative Update calls (synchronous) exactly one Compensate (asynchronous) exactly one Confirm (asynchronous) There can be more than one Tentative Update call. In addition, Normal operations can be added (asynchronous or synchronous). The way it works is the following: One or more synchronous update calls are tentatively recorded until one of either a Confirm (COMMIT) or Compensate (ROLLBACK) message is finally received. Web Service Runtime ensures delivery of Compensate message in all error or failure situations - compensate message registered before the first call of tentative update operation Both provider and consumer must 7.1 SAP NetWeaver Process Integrationunderstand protocol, only suitable in A2A scenarios, not B2B 15

Interface Pattern Stateful

General
Successive calls use a state at the provider No guarantee of a common update of data at the receiver This interface pattern is only needed for a few special technical scenarios. This interface pattern cannot be used for enhanced/mediated communication using the Integration Server Only synchronous calls supported

As mentioned, the stateful interface pattern is also not of much use within XI and consequently will not be discussed in detail. It will suffice to mention, in general, the following characteristics of this pattern: Successive calls use a state at the provider No guarantee of a common update of data at the receiver This interface pattern is only needed for a few special technical scenarios. This interface pattern cannot be used for enhanced/mediated communication using the Integration Server Only synchronous calls supported

SAP NetWeaver Process Integration 7.1

16

Copyright 2007 SAP AG All rights reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Duet, Business ByDesign, ByDesign, PartnerEdge and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned and associated logos displayed are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. The information in this document is proprietary to SAP. This document is a preliminary version and not subject to your license agreement or any other agreement with SAP. This document contains only intended strategies, developments, and functionalities of the SAP product and is not intended to be binding upon SAP to any particular course of business, product strategy, and/or development. SAP assumes no responsibility for errors or omissions in this document. SAP does not warrant the accuracy or completeness of the information, text, graphics, links, or other items contained within this material. This document is provided without a warranty of any kind, either express or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. This limitation shall not apply in cases of intent or gross negligence. The statutory liability for personal injury and defective products is not affected. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third-party Web pages nor provide any warranty whatsoever relating to third-party Web pages

Weitergabe und Vervielfltigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrckliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation enthaltene Informationen knnen ohne vorherige Ankndigung gendert werden. Einige von der SAP AG und deren Vertriebspartnern vertriebene Softwareprodukte knnen Softwarekomponenten umfassen, die Eigentum anderer Softwarehersteller sind. SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, Duet, Business ByDesign, ByDesign, PartnerEdge und andere in diesem Dokument erwhnte SAP-Produkte und Services sowie die dazugehrigen Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und in mehreren anderen Lndern weltweit. Alle anderen in diesem Dokument erwhnten Namen von Produkten und Services sowie die damit verbundenen Firmenlogos sind Marken der jeweiligen Unternehmen. Die Angaben im Text sind unverbindlich und dienen lediglich zu Informationszwecken. Produkte knnen lnderspezifische Unterschiede aufweisen. Die in diesem Dokument enthaltenen Informationen sind Eigentum von SAP. Dieses Dokument ist eine Vorabversion und unterliegt nicht Ihrer Lizenzvereinbarung oder einer anderen Vereinbarung mit SAP. Dieses Dokument enthlt nur vorgesehene Strategien, Entwicklungen und Funktionen des SAP-Produkts und ist fr SAP nicht bindend, einen bestimmten Geschftsweg, eine Produktstrategie bzw. -entwicklung einzuschlagen. SAP bernimmt keine Verantwortung fr Fehler oder Auslassungen in diesen Materialien. SAP garantiert nicht die Richtigkeit oder Vollstndigkeit der Informationen, Texte, Grafiken, Links oder anderer in diesen Materialien enthaltenen Elemente. Diese Publikation wird ohne jegliche Gewhr, weder ausdrcklich noch stillschweigend, bereitgestellt. Dies gilt u. a., aber nicht ausschlielich, hinsichtlich der Gewhrleistung der Marktgngigkeit und der Eignung fr einen bestimmten Zweck sowie fr die Gewhrleistung der Nichtverletzung geltenden Rechts. SAP bernimmt keine Haftung fr Schden jeglicher Art, einschlielich und ohne Einschrnkung fr direkte, spezielle, indirekte oder Folgeschden im Zusammenhang mit der Verwendung dieser Unterlagen. Diese Einschrnkung gilt nicht bei Vorsatz oder grober Fahrlssigkeit. Die gesetzliche Haftung bei Personenschden oder die Produkthaftung bleibt unberhrt. Die Informationen, auf die Sie mglicherweise ber die in diesem Material enthaltenen Hotlinks zugreifen, unterliegen nicht dem Einfluss von SAP, und SAP untersttzt nicht die Nutzung von Internetseiten Dritter durch Sie und gibt keinerlei Gewhrleistungen oder Zusagen ber Internetseiten Dritter ab. Alle Rechte vorbehalten.

SAP NetWeaver Process Integration 7.1

17