Service Interfaces 1

7/31/2019 Service Interfaces 1

1/171SAP NetWeaver Process Integration 7.1

SAP NetWeaver Process In t egrat ion 7 .1

ES Repository Service Interfaces

SAP NetWeaver Regional Implementation Group

SAP NetWeaver Product ManagementDecember 2007



Benef i ts

Af t er read ing th is docum ent , you w i l l be ab le t o :Understand what a Service Interface is, how it has evolved from the MessageInterface, and the main deltas between the two

Understand what an Interface Pattern is, the different types available, andwhich are relevant for PI usage



1. Service Interface Overview

2. Interface Pattern

Agenda





Agenda



Serv ice In te r face Back ground

Transition

Integration Repository

ES Repository Message Interface Service InterfaceSimilar 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 InterfaceMain Deltas

Service Interfaces may contain several Operations

Each Operation describes one communication (synchronous or asynchronous)

Interface Patternsand 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 theEnterprise Services Repository began with SAP NetWeaver 2004s, but still without the termService Interfaces, just Message Interfaces. Now, with a Service Oriented Architecture as abase and SAPs drive toward enterprise SOA, with the next major NetWeaver release, theIntegration Repository and the Message Interface has fully transitioned and evolved into theEnterprise Services Repository and Service Interface.

Many of the guiding principles from the previous NetWeaver releases were also carried forwardto this next major NetWeaver release and still apply. For example, the outside-indesignapproach 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 serviceinterface, even including its name, are primarilydriven by the requirements of the enterprise SOA initiative. Service Interfaces, at least as itrelates to Exchange Infrastructure (XI), fundamentally, has not changed much at all.



Serv ice In te r face 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 (p2pscenarios) 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 asingle operation or multiple operations to be implemented in an application system. SAPapplication systems can leverage proxy generation to facilitate the implementation. TheService Interface can be used in mediated scenarios with the Integration Server and directpoint-to-point (p2p) scenarios via the Web Service Runtime. Each operation of a ServiceInterface is linked to a description of the message structure in the form of an ES RepositoryMessage Type, RFC or IDoc metadata, or an external format in the form of a WSDL, XSD, orDTD.

The general attributes of a service interface still include the category(e.g.inbound/outbound/abstract) and mode(synchronous, asynchronous). Inbound and outboundare still terms from the application perspective. As such, and now with a more service-orientedview, inbound interfaces are portrayed with the provider role and outbound interfaces with theconsumer role.

Probably the key change with the next major NetWeaver release is a new attribute calledinterface patternwhich will significantly dictate how a Service Interface is implemented on the

back-end. The chosen interface pattern drives the available operation patternsoptions thatare available. More details on Interface Pattern will be discussed in later slides.



Serv ice In te r face UI Layou t

Messages of anOperation

OperationsAttributes(Operation

Pattern andMode)

Operation

List

Service InterfaceAttributes

(Category andInterface Pattern)

The Service Interface design screen within the ES Repository has undergone some changes aswell. Here, looking first at a plain template screen, you can see four major areas that make-upor define a service interface:

The main service interface attributes (category and interface pattern) along with the a givenoperation will determine the operation attributes (operation pattern and selectable mode) andthe message associated with a particular operation.

Also, an example screenshot of the actual UI for the Service Interface design screen for theactual look and feel



Serv ice In te r face UI Layou t

Messages of anOperation

OperationsAttributes(Operation

Pattern andMode)

Operation

List

Service InterfaceAttributes

(Category andInterface Pattern)





Agenda



In te r fac e Pa t t e rn

Communication Terms

Stateless communication Stateful communication

Terms relate to state at the providerand not the Integration Server

Not to be confused with stateful Integration Processes (e.g. using messagecorrelation)

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



In ter fac e Pat t erns and Operat ion Pat t erns

AsynchronousCompensate Operation

AsynchronousConfirm Operation

SynchronousTentative-Update Operation

Synchronous or AsynchronousNormal Operation

TU&C/C

SynchronousRollback Operation

SynchronousCommit Operation

SynchronousNormal Operation

Stateful

Synchronous or AsynchronousNormal OperationStateless (XI 3.0 compatible)

Synchronous or AsynchronousNormal OperationStateless

ModeOperation PatternInterface Pattern

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

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



In ter face Pat tern St a te less & St a te less (XI 3.0-compat ib le )

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 withthis interface pattern

Current recommended interface pattern for XI/PI specific scenarios via existingtechnical adapters (not using WS adapter)

Only one operation allowed and name of service interface and operation must beidentical

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 statelessor 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 statelessinterface pattern is also used in point-to-

point (p2p) communication using web services.

As listed here, the statelessinterface 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 andNetWeaver 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.0-

compatible) pattern. Also note that these are the only two interface patterns allowed for abstract

interfaces.



Proxy Generation Comparison

Prox y Generat i on St at e less (XI 3 .0-c ompat ib le)

Stateless(XI30-

Compatible

Pattern

One

Operation

One ProxyMethod

When multiple operations of a service interface are defined, proxy generation accounts for each ofthe operations as separate interface methodsin 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 tothe service interface name

When a proxy is generated, one corresponding proxy method is generated for the oneoperation within the service interface.



Proxy Generation Comparison

Proxy Genera t ion Sta t e less

StatelessPattern

Multiple

Operations

Multiple Proxy

Methods

When multiple operations of a service interface are defined, proxy generation accounts for each ofthe operations as separate interface methodsin the generated proxy definition.

Stateless interface pattern with four operations:

When the proxy is generated for this service interface, four separate proxy methods also getgenerated corresponding to each operation defined.

No major surprise here, but mainly an illustration of what the proxy generation might look likefor a service interface with multiple operations.



In te r face Pa t t e rn 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 orfailure situations

compensate message registered before the first call of tentative updateoperation

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 Updatecalls (synchronous)

exactly one Compensate(asynchronous)

exactly one Confirm(asynchronous)

There can be more than one Tentative Update call. In addition, Normaloperations 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 understand protocol, only suitable in A2A scenarios, not B2B



I nte r fac e Pa t t e rn Sta t e fu l

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

This interface pattern cannot be used for enhanced/mediatedcommunication using the Integration Server

Only synchronous calls supported

As mentioned, the statefulinterface pattern is also not of much use within XI and consequentlywill not be discussed in detail. It will suffice to mention, in general, the following characteristicsof 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 theIntegration Server

Only synchronous calls supported


17/17

Copyr ight 2007 SAP AGAl l r igh ts 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. T he information contained herein may be changedwithout prior notice.

Some software products marketed by SAP AG a nd 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 theirrespective 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 andassociated 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 versio n and not subject to your license agreement or any other agreement with SAP. This documentcontains 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, orother 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 ofmerchantability, fitness for a particular purpose, or non-infringement.

SAP shall have no liability for damages of any kind i ncluding without limitation direct, special, indirect, or consequential damages that may result from t he use of these materials. This limitationshall 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 thesematerials and does not endorse your use of t hird-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 durchSAP 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 Servicessowie die dazugehrigen Logos sind Marken oder eingetragene Marken der SAP AG in Deutschland und in mehreren anderen Lndern weltweit. Alle anderen in diesem Dokument erwhntenNamen von Produkten und Services sowie die damit verbundenen Firmenlogos sind Marken der jeweiligen Unternehmen. Die Angaben im Text sind unverbindlich und dienen lediglich zuInformationszwecken. Produkte knnen lnderspezifische Unterschiede aufweisen.

Die in diesem Dokument enthaltenen Informationen sind Eigentum von SAP. Dieses Dokument ist eine Vora bversion 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 bestimmtenGeschftsweg, eine Produktstrategie bzw. -entwicklung einzuschlagen. SAP bernimmt keine Verantwortung fr Fehler oder Auslassungen in diesen Materialien. SAP garantiert nicht dieRichtigkeit oder Vollstndigkeit der Informationen, Texte, Grafiken, Links oder anderer in diesen Materialien enthaltenen Elemente. Diese Publikation wird ohne jegliche Gewhr, wederausdrcklich noch stillschweigend, bereitgestellt. Dies gilt u. a., aber nicht ausschlielich, hinsichtlich der Gewhrleistung der Marktgngigkeit und der Eignung fr einen bestimmten Zwecksowie 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 Verwendungdieser 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 e nthaltenen Hotlinkszugreifen, unterliegen nicht dem Einfluss von SAP, und SAP untersttzt nicht die Nutzung von Internetseiten Dritter durch Sie und gibt keinerlei Gewhrleistungen oder Zusagen berInternetseiten Dritter ab.

Alle Rechte vorbehalten.

Service Interfaces 1

Documents

Transcript of Service Interfaces 1