enterprise integration patterns für sap netweaver pi

39

4 Modellierungskonzept

Das Modellierungskonzept bildet das Fundament jeden Projekts, das auf SAP NetWeaver Process Integration basiert. Es beschreibt die Organisation der Softwarekomponenten beziehungsweise der einzelnen Objekte, die Namenskonventionen sowie die Vorgehensweise zur Entwicklungszeit(Design Time) und zur Konfigurationszeit (Configuration Time). Erweitert wird das Modellierungskonzept durch das Monitoring-Konzept, das klare Vorga-ben in Bezug auf die Laufzeit (Runtime) und die Überwachung der Systeme definiert.

Je nach Größe des Unternehmens sind die genannten Konzepte und Vorge-hensweisen nicht immer schriftlich festgelegt, wobei in der Praxis zu sehen ist, dass die Namenskonventionen als Minimalanforderung in jedem Unter-nehmen existieren. Generell wird jedoch empfohlen, die Konzepte schrift-lich festzuhalten, da der anfänglichen Zeitinvestition folgende Erträge gegen-überstehen:

� Ein Leitfaden zur Vorgehensweise erhöht die Qualität der Implementie-rung, da ein Schema verfolgt wird, das sich als praxistauglich erwiesen hat (Best Practices).

� Dokumentierte Vorgehensweisen und Konzepte bilden eine bessere Basis für Fragen und Diskussionen.

� Neue Mitarbeiterinnen und Mitarbeiter, die sich in die neue Thematik einarbeiten, werden unterstützt. Zudem reduziert sich der Zeitaufwand für den Know-how-Transfer.

� Der Kommunikationsaufwand bei externer Entwicklung (sowohl near-shore als auch offshore) reduziert sich, da grundlegende Fragen und Vor-gehensweisen dokumentiert sind.

In der gängigen Literatur zum Thema SAP NetWeaver XI/PI sind relativ wenig Informationen zur Organisation von Softwarekomponenten und deren Objekten zu finden. Dies liegt sicherlich auch daran, dass die Vorge-hensweise im Rahmen der Implementierung sehr stark von der Organisation des Unternehmens abhängt. SAP-geprägte Unternehmen wählen beispiels-weise eine andere Vorgehensweise als Unternehmen, die durch eine sehr

Modellierungskonzept4

40

heterogene Systemlandschaft geprägt sind. In Abschnitt 4.1, 4.2 und 4.3 stel-len wir daher drei Softwarekomponentenstrategien vor, die in unterschiedli-chen Kundenprojekten zum Einsatz gekommen sind und, je nach Unterneh-men und Systemlandschaft, ihre Legitimität haben.

Einen Organisationstypen haben wir für unser Demonstrationsbeispiel aufge-griffen, das heißt, dass Abschnitt 4.2, »Dreikomponentenstrategie«, gleichzei-tig das Fundament zur Softwarekomponentenorganisation der in Kapitel 5, »Enterprise Integration Patterns«, beschriebenen Patterns bildet. Ein Großteil der Patterns werden als Demonstrationsbeispiele zum Download bereitge-stellt; daher beinhalten die Abschnitte 4.4, »Vorgehensweise zur Design Time«, und 4.5, »Vorgehensweise zur Configuration Time«, wichtige Informa-tionen zum Verständnis und zur Konfigurierbarkeit der Beispiele.

Die klare Definition einer unternehmensweiten Softwarekomponentenstra-tegie ist generell erforderlich, um folgenden Punkten gerecht zu werden:

� Die Integrationsanforderungen eines Unternehmens müssen auf die ein-gesetzte Software abbildbar sein (IT follows Business).

� Die Verantwortlichkeiten zur Entwicklungszeit müssen klar trennbar sein.

� Die Wiederverwendbarkeit von Objekten muss möglich sein.

� Die Wartbarkeit und das Monitoring der Integrationsszenarien muss unterstützt werden.

� Die Verteilung von Integrationsszenarien auf gegebenenfalls mehrere SAP NetWeaver PI-Systeme muss unterstützt werden.

Um diesen Anforderungen gerecht zu werden, muss die Organisation der Softwarekomponenten beziehungsweise der enthaltenen Entwicklungs-

Hinweis

Um die Lesbarkeit der Fachbegriffe zu vereinfachen, werden wir im Folgenden den Begriff Softwarekomponente verwenden und damit implizit die damit in Verbin-dung stehende Softwarekomponentenversion bezeichnen.

Da wir innerhalb des Enterprise Services Repositorys auf der Ebene von Software-komponenten und Softwarekomponentenversionen arbeiten, werden wir im wei-teren Verlauf nicht auf die Produkte und Produktversionen des System Landscape Directorys (SLD) eingehen.

Es sei jedoch an dieser Stelle erwähnt, dass ein Produkt eine Produktversion und eine Softwarekomponente eine Softwarekomponentenversion referenziert. Die Verbindung zwischen Produktversion und Softwarekomponentenversion wird mit-tels des Software-Feature-Objekts im SLD hergestellt.

Modellierungskonzept 4

41

objekte genau überdacht und geprüft werden. Generell gilt, dass ein Service beziehungsweise Komponenten und Systeme, die an einem Integrations-szenario teilnehmen, zur Designzeit von einer Softwarekomponente bezie-hungsweise von einem Produkt repräsentiert werden. Zur Konfigurationszeit können mehrere Services beziehungsweise Komponenten und Systeme, die durch die Softwarekomponenten repräsentiert werden, konfiguriert werden.

Beispielsweise sendet ein zentrales SAP ERP-System einen Transportauftrag an unterschiedliche lokale Warenwirtschaftssysteme. Da alle Warenwirt-schaftssysteme den gleichen Service implementieren, wird zur Designzeit lediglich ein Warenwirtschaftssystem modelliert, und zur Konfigurationszeit werden entsprechend die Anzahl der lokalen Systeme konfiguriert.

Im Folgenden stellen wir Ihnen drei Softwarekomponentenstrategien aus der Praxis vor, die unterschiedlichen Anforderungen gerecht werden. Gene-rell stellt sich bei den einzelnen Strategien die Frage, wo die einzelnen Objekte der Entwicklungszeit abgelegt werden. Um diese Frage beantworten zu können, sollen im Vorfeld zwei Objektkategorien definiert werden:

1. Objekte, die Eigenschaften von Integrationslogik aufweisen

� Process Integration Scenario

� Integrationsprozess (inklusive Step Group, Alert Category, Monito-ring-Prozess)

� Operation-Mapping

� Message-Mapping (inklusive Functional Library und importierten Archiven sowie Mapping-Template)

2. Objekte, die service- beziehungsweise komponenten-/applikationsspezi-fische Eigenschaften aufzeigen

� Action

� Service-Interface

� Message-Typ (inklusive Fault-Message-Typ)

� Datentyp (inklusive Datentyperweiterungen und externen Definitio-nen)

� Kontextobjekte

� Importierte Objekte

� Kommunikationskanalvorlagen

Um die Begrifflichkeit zu vereinfachen, werden die beiden Objektkategorien im Folgenden als Integrationslogikobjekte und Serviceobjekte bezeichnet. Je


42

nach gewählter Strategie erfolgt eine unterschiedliche Zuordnung der Objekte innerhalb der Softwarekomponenten.

4.1 Zweikomponentenstrategie

Die Zweikomponentenstrategie ist die einfachste Form der Softwarekompo-nentenorganisation, und sie orientiert sich an den Sender- und Empfänger-applikationen. Sowohl das Sendersystem als auch das Empfängersystem wer-den hierbei von einer Softwarekomponente repräsentiert, die die Services des jeweiligen Systems beschreibt.

Während bei dieser Strategie die Frage nach der Zuordnung der Serviceob-jekte klar zu beantworten ist – jede applikationsspezifische Softwarekompo-nente enthält die entsprechenden Serviceobjekte der jeweiligen Applikation – gestaltet sich die Frage nach der Zuordnung der Integrationslogikobjekte wesentlich schwieriger. Es ist nicht immer klar, welcher Softwarekompo-nente zum Beispiel ein Process Integration Scenario, ein Integrationsprozess oder das Mapping zwischen Sender- und Empfängerapplikation zugeordnet werden soll. In der Projektpraxis wird die Zweikomponentenstrategie insbe-sondere von Unternehmen eingesetzt, die ein harmonisiertes beziehungs-weise konsolidiertes ERP-System betreiben. Die Problematik der Integra-tionslogik wird folgendermaßen geklärt: Die Softwarekomponente des ERP-Systems wird als führende Komponente klassifiziert und beinhaltet daher die Integrationslogikobjekte. Abbildung 4.1 zeigt die Verteilung der Entwick-lungsobjekte in den jeweiligen Softwarekomponenten (SCs):

Die Zweikomponentenstrategie hat folgende Vor- und Nachteile:

� Vorteile:

� Sie ist für Unternehmen mit weniger komplexen Systemlandschaften und einem führenden System geeignet, da dieses die Platzierung der Integrationslogik vorgibt.

Hinweis

Der Fokus dieses Buches liegt auf dem Bereich Process Integration Scenario und der damit einhergehenden Entwicklung von Application-to-Application-(A2A-) und Business-to-Business-(B2B-)Szenarien. Themen wie die Modellierung von Pro-cess Components oder Businessobjekte würden den Rahmen dieses Buches spren-gen. Wir verweisen daher auf das bei SAP PRESS erschienene Buch Anwendungs-entwicklung mit Enterprise SOA von Martin Huvar et al.

Dreikomponentenstrategie 4.2

43

� Eine führende Softwarekomponente enthält die Integrationslogik, das heißt, dass die Verteilung der Logik auf mehrere Softwarekomponen-ten nicht notwendig ist.

� Sie ist weniger komplex.

� Nachteile:

� Einer führenden Softwarekomponente kann im Laufe der Zeit diese führende Eigenschaft entzogen werden (zum Beispiel im Falle einer Unternehmensfusion oder des Verkaufs von Unternehmensteilen).

� Process Integration Scenarios, die nicht die führende Softwarekompo-nente beinhalten, müssen als Ausnahmefall behandelt werden, was zur Verteilung der Integrationslogik führt.

� Dieser Ansatz ist für die Kommunikation zweier SAP NetWeaver PI-Systeme (PI-PI-Kommunikation) suboptimal.

� Sie ist für das Canonical Data Model Pattern (siehe Abschnitt 5.2, »Canonical Data Model«) ungeeignet, da dieses Pattern grundsätzlich auf drei Softwarekomponenten beruht.

4.2 Dreikomponentenstrategie

Die Dreikomponentenstrategie erweitert das Konzept der Zweikomponenten-strategie um eine weitere Softwarekomponente. Diese kann als abstrakte Soft-warekomponente gesehen werden, da ihr kein konkreter Service und keine konkrete Applikation zugewiesen werden kann. Vielmehr wird diese als

Abbildung 4.1 Zweikomponentenstrategie

Senderprodukt*

»Führende«(Nicht-)SAP-SC

NamensräumeProcess Integration ScenariosActionsIntegrationsprozesseService-InterfacesMessage-TypenDatentypenOperation-MappingsMessage-MappingsKontextobjekteImportierte IDocs/RFCs Komm.-Kanal-Vorlage

Empfängerprodukt*

(Nicht-)SAP-SC

NamensräumeActionsService-InterfacesMessage-TypenDatentypenKontextobjekteImportierte IDocs/RFCs Komm.-Kanal-Vorlage

*Sender und Empfänger sind austauschbar.


44

COMMON bezeichnete Komponente für die zentrale Ablage der Integrations-logikobjekte genutzt. Die gesonderte Stellung einer führenden applikations-spezifischen Softwarekomponente fällt daher weg. Abbildung 4.2 zeigt die Verteilung der Entwicklungsobjekte in den jeweiligen Softwarekomponenten (Software Components, SCs).

Die zentrale COMMON-Softwarekomponente orientiert sich hierbei an kon-kreten Integrationsprojekten. Das heißt, dass für ein spezifisches (Teil-)Pro-jekt eine COMMON-Softwarekomponente angelegt wird, in der sich die Integrationslogik der einzelnen Integrationsszenarien dieses Projekts befin-det. Für neue Projekte werden eigene Softwarekomponenten angelegt, um unabhängig von anderen Projekten arbeiten zu können (Trennung von Ver-antwortlichkeiten). Die applikationsspezifischen Softwarekomponenten ent-halten in diesem Fall eine Projekt-ID, die Aufschluss über die Zugehörigkeit zur COMMON-Komponente gibt, das heißt, dass eine konkrete Applikation von unterschiedlichen projektbasierten Softwarekomponenten repräsentiert werden kann. Je nach Unternehmensorganisation kann alternativ zur Pro-jekt-ID auch eine Funktions-ID verwendet werden, um eine klare Trennung zwischen einzelnen Softwarekomponenten zu ermöglichen.

Die Dreikomponentenstrategie bietet folgende Vor- und Nachteile:

� Vorteile:

� Die Verantwortlichkeiten sind klar getrennt, da die Integrationslogik unabhängig von den zu integrierenden Softwarekomponenten vorge-halten wird.

� Es handelt sich um einen flexiblen Ansatz. Unternehmensfusionen können ohne Migrationsprobleme abgebildet werden.

Abbildung 4.2 Dreikomponentenstrategie

Senderprodukt*

(Nicht-)SAP-SC

Empfängerprodukt*

(Nicht-)SAP-SC

COMMON-Produkt

COMMON-SC


NamensräumeActionsService-InterfacesMessage-TypenDatentypenKontextobjekteImportierte IDocs/RFCs Komm.-Kanal-Vorlage(Process Integration Scenarios)


NamensräumeProcess Integration ScenariosActions (IP)IntegrationsprozesseOperation-MappingsMessage-MappingsKontextobjekte

Dreikomponentenstrategie 4.2

45

� Die Strategie eignet sich für komplexe Organisationen.

� Die Strategie dient als Basisarchitektur für das Canonical Data ModelPattern (siehe Abschnitt 5.2, »Canonical Data Model«).

� Die Strategie ist für eine PI-PI-Kommunikation nutzbar.

� Nachteile:

� Die Komplexität ist aufgrund einer zusätzlichen COMMON-Software-komponente höher; beispielsweise erfordert der Transport eines Pro-cess Integration Scenarios die Freigabe von drei Softwarekomponen-ten.

� Es besteht die Gefahr der Überschneidung von Integrationsprojekten, wenn in parallelen Projekten an ähnlichen Integrationsszenarien gear-beitet wird.

� Die Sichtweise ist nicht prozessbasiert. Die Abstraktion der Integra-tionslogik bezieht sich auf einzelne Projekte und nicht auf die Unter-nehmensprozesse.

Durch die Trennung der Softwarekomponenten nach Projekten wird sicher-gestellt, dass unterschiedliche Entwicklungsteams an projektbasierten Inte-grationsszenarien arbeiten. Dabei reicht die teaminterne Kommunikation aus, um zum Beispiel Transporte anzustoßen oder einzelne Softwarekompo-nenten in die Produktion zu überführen. Zudem kann das Zugriffs- und Änderungsrecht auf Basis einzelner Softwarekomponenten kontrolliert wer-den. Überschneidungen können bei diesem Vorgehen jedoch dann auftre-ten, wenn globale Objekte benötigt werden, die von mehreren Projekten genutzt werden sollen. Hierbei hat sich die Definition einer globalen Soft-warekomponente als hilfreich erwiesen, um die Wiederverwendbarkeit von Objekten zu ermöglichen (siehe Abschnitt 5.2, »Canonical Data Model«).

Die im Rahmen dieses Buches erstellten Beispielszenarien wurden auf Basis der Dreikomponentenstrategie angelegt. Bei den zur Verfügung gestellten Komponenten gehen wir davon aus, dass die Systemlandschaft der Patterns auf einem ERP-System sowie auf mehreren LEGACY-Systemen gleichen Applikationstyps beruht. Sowohl das ERP-System als auch die LEGACY-Sys-teme werden daher von jeweils einer Softwarekomponente repräsentiert, während die Integrationslogik in der zentralen COMMON-Softwarekompo-nente vorzufinden ist. Die Namenskonvention der Softwarekomponente ist dabei wie folgt aufgebaut:

<COMPANY>_<PROJECT-ID> <PRODUCT NAME | COMMON>


46

Für unser Demoprojekt ergeben sich folgende fiktive Ausprägungen:

Bei den Produktnamen haben wir gezielt abstrakte Namen gewählt, um die Beispiele applikationsunabhängig aufzubauen und eine einfache Lesbarkeit zu ermöglichen.

Gemäß der Namenskonvention ergeben sich folgende Softwarekomponen-ten:

� PI-PATTERNS_EIP COMMON

� PI-PATTERNS_EIP ERP

� PI-PATTERNS_EIP LEGACY

4.3 Prozessorientierte Komponentenstrategie

Die prozessorientierte Komponentenstrategie nutzt die Vorteile der Dreikom-ponentenstrategie und schafft den Brückenschlag zwischen den Geschäfts-prozessen eines Unternehmens und deren Abbildung in SAP NetWeaver PI. Ausgehend von der Prozessdokumentation eines Unternehmens werden sogenannte CORE-Prozesskomponenten definiert, die, vergleichbar mit der COMMON-Komponente der Dreikomponentenstrategie, die Integrationslo-gik eines Prozessbereiches beinhalten. Die Organisation der Objekte inner-

Platzhalter Wert

Company PI-Patterns

Projekt-ID EIP (Enterprise Integration Patterns)

Produktname 1 ERP

Produktname 2 LEGACY

Hinweis

Wie bereits erwähnt, verwenden wir den Begriff Softwarekomponente als Sammel-begriff für die einzelnen Objekte des SLDs: Produkt, Produktversion, Software-komponente (SC), Softwarekomponentenversion (SCV). Tatsächlich wurde im SLD sowohl ein Produkt als auch eine Softwarekomponente gemäß dieser Namenskon-vention angelegt. Zudem enthält jedes Objekt eine entsprechende Version 1.0. Alle SLD-Objekte stehen als Download zur Verfügung.

Je nach Produkt und Softwarekomponenten ist dieser Sachverhalt in der Praxis komplexer. Das SAP R/3 Enterprise-Produkt in Produktversion 47X200 enthält beispielsweise die Softwarekomponente SAP APPL in Version 4.70.

Prozessorientierte Komponentenstrategie 4.3

47

halb der Softwarekomponenten ist hierbei mit der Dreikomponentenstrate-gie identisch; jedoch ändert sich die Semantik einer projektbasierten COMMON-Komponente zu einer prozessbasierten CORE-Komponente. Abbildung 4.3 zeigt die Organisation der einzelnen Objekte auf. Der Detail-lierungsgrad der CORE-Komponente ist hierbei abhängig von der bestehen-den Prozessbeschreibung. Abbildung 4.4 zeigt eine beispielhafte Modellie-rung aus der Praxis.

Abbildung 4.4 beinhaltet zwei beispielhafte CORE-Prozesskomponenten:

1. PI-PATTERNS CORE FIR als Repräsentant der Financial-Reporting-Integra-tionslogik

2. PI-PATTERNS CORE OTC DISTRIBUTION als Repräsentant der Order-to-Cash-Distribution-Integrationslogik

Abbildung 4.3 Prozessorientierte Komponentenstrategie

Abbildung 4.4 Prozessorientierte Komponentenstrategie – Beispiel

Senderprodukt*

(Nicht-)SAP-SC

Empfängerprodukt*

(Nicht-)SAP-SC

CORE-Produkt

CORE-SC



NamensräumeActionsService-InterfacesMessage-TypenDatentypenKontextobjekteImportierte IDocs/RFCs Komm.-Kanal -Vorlage(Process Integration Scenarios)

NamensräumeProcess Integration ScenariosActions (IP)IntegrationsprozesseOperation-MappingsMessage-MappingsKontextobjekte

SAP ERP PI-PATTERNSCORE FIR

PI-PATTERNSCORE OTC

DISTRIBUTION

Exchange RateSystem

Transport Service Provider


48

Anhand dieses Beispiels kann sehr gut aufgezeigt werden, dass die CORE-Komponenten eine 1:1-Abbildung der Geschäftsprozesse darstellen. In die-sem, aus der Praxis abgeleiteten Beispiel wurde der Order-to-Cash-Prozess in mehrere Subprozesses untergliedert, wie zum Beispiel Distribution andTransport oder Warehouse-Management, während der Financial-Reporting-Prozess generisch gehalten wurde. Die Modellierung der CORE-Software-komponenten folgt hier also dem Granulierungsgrad der Geschäftsprozesse. Die applikationsspezifischen Softwarekomponenten (SAP ERP, EXCHANGE RATE SERVICE, TRANSPORT SERVICE PROVIDER) werden unabhängig modelliert und können von unterschiedlichen Prozessen verwendet werden.

Im Beispiel werden täglich Wechselkursinformationen von einem externen System (Exchange Rate Service) zur Verfügung gestellt. Die Integrationslogik für diese Informationen wird innerhalb der PI CORE FIR-Komponente vor-gehalten. Beispielweise wird hierin das Mapping auf der Zielstruktur der SAP ERP-Komponente bereitgestellt, die ein Konsument dieser Informatio-nen ist. Die PI-PATTERNS CORE OTC DISTRIBUTION-Komponente beinhal-tet einen Prozess zur Integration des SAP ERP-Systems mit einer Transport-Service-Provider-Applikation. Einzelne Transportanzeigen, die innerhalb des SAP ERP-Systems angelegt werden, werden hierbei an den Transport Service Provider übertragen, der das geeignete Logistikunternehmen und die Fracht-kosten kalkuliert. Diese Informationen werden umgehend an das SAP ERP-System übermittelt. Da die Kalkulation der Frachtkosten auf Basis tagesaktu-eller Wechselkurse erfolgt, wird auch die Transport-Service-Provider-Appli-kation mit den Wechselkursen »versorgt«. Die Integrationslogik hierzu ist in der bereits bekannten PI-PATTERNS CORE FIR-Komponente vorzufinden.

Die prozessorientierte Komponentenstrategie bietet folgende Vor- und Nachteile:

� Vorteile:� Die prozessbasierte Sichtweise mit klarer Abbildung der Geschäftspro-

zesse vereinfacht die Lesbarkeit der Integrationsprozesse und kann als Kommunikationsvehikel genutzt werden.

Tipp

Bevor die Abbildung der Geschäftsprozesse in Form von CORE-Komponenten stattfindet, ist es ratsam zu klären, mit welchem Detaillierungsgrad zu arbeiten ist. Als sinnvoll hat sich hierbei die Abbildung auf Subprozessebene erwiesen (zum Beispiel Subprozess Distribution des OTC-Prozesses). Projekte die das ARIS Enter-prise Activity Model (EAM) als Referenz verwenden, haben beispielweise ArisLevel 3 als Detaillierungsgrad gewählt.

Vorgehensweise zur Design Time 4.4

49

� Der Ansatz ist flexibel: Business-Process-Outsourcing-(BPO-)Anforde-rungen können sehr gut abgebildet werden.

� Diese Strategie ist für komplexe Organisationen geeignet.

� Es ist die Basisarchitektur für das Canonical Data Model Pattern (siehe Abschnitt 5.2, »Canonical Data Model«).

� Sie ist für eine PI-PI-Kommunikation nutzbar.

� Nachteile:

� Die Komplexität ist aufgrund einer zusätzlichen CORE-Softwarekom-ponente höher; beispielsweise erfordert der Transport eines Process Integration Scenarios die Freigabe von drei Softwarekomponenten.

� Die Reorganisation von Prozessen hat direkte Auswirkungen auf die Organisation der Softwarekomponenten.

4.4 Vorgehensweise zur Design Time

Der Fokus dieses Abschnitts richtet sich auf die Vorgehensweise im Enter-prise Services Repository und unterstützt so das Verständnis der in Kapitel 5, »Enterprise Integration Patterns«, beschriebenen Patterns. Wir erläutern den Top-down-Ansatz schematisch, da diese Vorgehensweise für alle als Beispiel ausgelieferten Patterns befolgt wurde. Ziel dieses Kapitels ist es jedoch nicht, jeden einzelnen Schritt darzulegen, sondern vielmehr dem Leser eine mögli-che Vorgehensweise aufzuzeigen. Im Folgenden zeigen wir daher, wie, aus-gehend vom Process Integration Scenario, unter Verwendung der Top-down-Strategie, alle erforderlichen Objekte angelegt werden können.

Wie zuvor erwähnt, basiert das Enterprise-Integration-Pattern-Projekt auf der Dreikomponentenstrategie, die im vorangegangenen Abschnitt detail-liert beschrieben wurde.

4.4.1 Definition von Namensräumen

Bevor wir mit der Beschreibung der Vorgehensweise zur Implementierung von Integrationsszenarien beginnen können, müssen wir jedoch als weiteres Organisationsobjekt den Namensraum klären. Hierbei folgen wir in unserem Demoprojekt folgender Namenskonvention:

urn:<company>:pi:<project-id>:<sc name>:<pattern>:<release>

Da sich ein Process Integration Scenario gemäß der beschriebenen Dreikom-ponentenstrategie über mindestens drei Softwarekomponenten erstreckt,

67

5 Enterprise Integration Patterns

In diesem Kapitel finden Sie 12 Patterns, die in der täglichen Praxis einge-setzt werden. Der Einsatz der jeweiligen Patterns richtet sich nach den indi-viduellen Anforderungen eines Integrationsszenarios, die im Vorfeld detail-liert analysiert werden müssen. Im Normalfall führt ein einzelnes Pattern nicht zur vollständigen Lösung. Vielmehr ist eine Kombination mehrerer Patterns notwendig, um eine komplexe Problemstellung erfolgreich lösen zu können.

Nicht alle Problemstellungen können in Form von Entwicklungsaufgaben gelöst werden; oftmals ist die Architektur für eine Lösung entscheidend. Auf-grund der Entkopplung von Entwicklungszeit (Design Time) und Konfigura-tionszeit (Configuration Time) muss Letztere zudem explizit in die Lösung einbezogen werden. Während beispielsweise das Canonical Data Model Pat-tern Fragestellungen zur Modellierung der kanonischen Datentransforma-tion adressiert, setzt sich das Content Based Router Pattern mit der Vorge-hensweise im Rahmen der Configuration Time auseinander. Hingegen haben integrationsprozessbasierte Patterns (zum Beispiel Aggregator oder Splitter) ihren Schwerpunkt zur Design Time.

Wir verwenden die englischen Bezeichnungen für die Patterns, die dem Buch Enterprise Integration Patterns von Gregor Hohpe und Bobby Woolf entnommen wurden. Ziel ist ein einheitlicher Gebrauch der Bezeichnungen, um Missverständnisse im internationalen Projektalltag zu reduzieren.

Die 12 Abschnitte dieses Kapitels sind nach folgendem Schema aufgebaut:

� Einleitend wird in einer Kurzbeschreibung der Zweck des jeweiligen Pat-terns erfasst, und es werden verwandte Patterns genannt.

� In den Abschnitten »Problemstellung«, »Beschreibung« und »Anwen-dungsfall« wird auf einer implementierungsunabhängigen Ebene der Ein-satz des jeweiligen Patterns anhand eines konkreten Beispiels erläutert.

� Der Abschnitt »PI-spezifische Implementierung« konkretisiert die Umset-zung auf Basis von SAP NetWeaver Process Integration 7.1 und liefert wichtige Hintergrundinformationen in Bezug auf die Implementierungs-möglichkeiten des betreffenden Patterns.

Enterprise Integration Patterns5

68

� Die Beschreibung der tatsächlichen Implementierung ist Teil des Abschnitts »Design Time«. Es handelt sich hierbei nicht um eine Schritt-für-Schritt-Anleitung zur Implementierung, sondern um die Beschreibung des Process Integration Scenarios und eventueller Zusatzentwicklungen, die nicht Teil des Top-down-Ansatzes sind (siehe Abschnitt 4.4.2, »Top-down-Ansatz«). Mit dieser Vorgehensweise möchten wir sicherstellen, dass ein lauffähiges Pattern in Ihrer Systemumgebung sofort nach der Konfiguration eingesetzt werden kann und Sie hieraus Ihre Schlüsse für anstehende Integrationsprojekte ziehen können. Eine Schritt-für-Schritt-Anleitung würde zudem den Rahmen dieses Buches sprengen.

� Der Abschnitt »Configuration Time« beinhaltet wichtige Informationen zur Konfiguration der einzelnen Patterns. Für Leser, die die Patterns im Rahmen ihrer Systemumgebung testen möchten, ist dieser Abschnitt von besonderem Interesse. Alle Patterns sind nach dem in Abschnitt 4.5 »Vor-gehensweise zur Configuration Time«, beschriebenen Ansatz konfigurier-bar. Notwendige Zusatzinformationen sind innerhalb des jeweiligen Abschnitts »Configuration Time« aufgeführt.

� Der Abschnitt »Runtime« verweist auf notwendige Testdateien und bein-haltet eine kurze Beschreibung dieser.

Generell werden alle Patterns (sofern eine Implementierung notwendig war) zum Download angeboten (www.sap-press.de/1620). Eine genaue Anleitung zum Download und zur Installation finden Sie in Kapitel 6.

5.1 Aggregator

5.1.1 Kurzbeschreibung

Das Aggregator Pattern sammelt und persistiert individuelle Nachrichten bis ein vollständiges Set an Informationen empfangen wurde. Es veröffentlicht eine einzelne Nachricht auf Basis der eingegangenen Informationen.

5.1.2 Verwandte Patterns

Keine.

5.1.3 Problemstellung

Nachrichten aus unterschiedlichen Systemen sollen zu einer einzelnen Nach-richt zusammengefasst werden.

Aggregator 5.1

69

5.1.4 Beschreibung

Das Aggregator Pattern aggregiert individuelle, allerdings semantisch zusam-mengehörige Nachrichten, um diese zu einer einzelnen Zielnachricht zusam-menzufassen. Hierzu müssen die eingehenden Nachrichten persistiert und semantisch korreliert werden, da sie den Integration Broker unabhängig voneinander erreichen. Ferner muss definiert werden, wie und wann der Sammelprozess beendet werden soll. Hierzu stehen unterschiedliche Strate-gien zur Verfügung, die sich aus den Anforderungen des Integrationsszena-rios ergeben. Folgende Lösungsansätze sind weithin bekannt:

� Zeitbasierte Terminierung

� Nachrichteninhaltbasierte Terminierung

� Nachrichtentypbasierte Terminierung

5.1.5 Anwendungsfall

Im Rahmen einer heterogenen Systemlandschaft soll der Warenausgang auf Basis im Vorfeld geschlossener Verträge kontrolliert werden. Hierbei sendet ein Service Kontraktinformationen (Kontraktnachrichten) bezüglich der Überwachung von Warenlieferungen an den Integration Broker. Der tatsäch-liche Warenversand wird von einem weiteren Service gehandhabt, der für jeden erfolgten Warenausgang eine Bestätigung (Bestätigungsnachricht) generiert. Der Integration Broker korreliert die Kontraktinformationen mit den Warenausgängen und informiert einen dritten Service über das offene Kontraktvolumen (Kontrakt-Status-Nachricht). Abbildung 5.1 zeigt den Anwendungsfall.

5.1.6 PI-spezifische Implementierung

Das Aggregator-Pattern erfordert aus Sicht von SAP NetWeaver PI den Ein-satz eines Integrationsprozesses, da Nachrichten unabhängig voneinander und zeitlich versetzt eintreffen und somit das Persistieren von Nachrichten

Abbildung 5.1 Aggregator Pattern – Anwendungsfall

Kontrakt

Kontrakt-status

Bestätigung


70

notwendig ist. Außerdem muss die semantische Zusammengehörigkeit von Nachrichten sichergestellt werden, was über eine eineindeutige Korrelation erfolgt.

Abhängig von den Integrationsanforderungen können unterschiedliche Ansätze zur Implementierung des Aggregator Patterns verfolgt werden. Die drei Hauptgruppen untergliedern sich hierbei in:

� Zeitbasierte Aggregation Nachrichten eines Nachrichtentyps werden über einen bestimmten Zeit-raum gesammelt. Die Terminierung erfolgt über einen Fristzweig.

� Nachrichteninhaltbasierte Aggregation Nachrichten eines Nachrichtentyps werden so lange gesammelt, bis ein bestimmter Schwellenwert eintritt, der über den Nachrichteninhalt selbst identifiziert wird. Dies kann zum Beispiel die Anzahl der zu sammelnden Nachrichten selbst oder eine STOP-Information, beispielsweise die Angabe der Summe der zu empfangenden Nachrichten innerhalb der Nachricht, sein.

� Nachrichtentypbasierte Aggregation Nachrichten unterschiedlicher Nachrichtentypen werden gesammelt. Die Terminierung erfolgt hierbei durch das Eintreffen einer bestimmten Nachricht, zum Beispiel einer STOP-Nachricht, beziehungsweise über den erfolgten Empfang erwarteter Nachrichten unterschiedlichen Typs.

Darüber hinaus können die in den Hauptgruppen genannten Eigenschaften des Aggregator Patterns kombiniert werden. Allen Aggregator-Ausprägun-gen liegt dabei zugrunde, dass eine Korrelation genutzt wird, um die seman-tische Abhängigkeit von Nachrichten, die einem bestimmten Prozess ange-hören, sicherzustellen.

In den folgenden Abschnitten wird die Implementierung des oben genann-ten Anwendungsfalls genauer beschrieben. Als weitere Beispiele können die von SAP ausgelieferten Collection Patterns in der Softwarekomponente SAP BASIS 7.10 (Namensraum http://sap.com/xi/XI/System/Patterns) dienen.

Hinweis

Zur Verarbeitung von Massendaten wird der Einsatz des Aggregation Patterns nicht empfohlen. In einem solchen Fall sollte, falls möglich, ein Sammelprozess in den sendenden Service implementiert werden.

Aggregator 5.1

71

5.1.7 Design Time

Übersicht – Process Integration Scenario

Der Anwendungsfall (siehe Abschnitt 5.1.5) wurde im System wie folgt abge-bildet (siehe Abbildung 5.2):

� Die erste Komponente Legacy Contract System sendet eine Nachricht vom Typ ContractSample und repräsentiert den Kontraktservice.

� Die zweite Komponente Legacy Confirmation System sendet eine Nach-richt vom Typ ConfirmationSample und repräsentiert den Warenaus-gangsservice, der eine Bestätigung pro Warenausgang sendet.

� Die dritte Komponente beinhaltet das Aggregator Pattern und referenziert einen Integrationsprozess.

� Die Komponente SAP ERP repräsentiert einen ERP-Service, der Nachrich-ten vom Typ ContractStatusSample empfängt, um über das aktuelle Kon-traktvolumen informiert zu sein.

Process Integration Scenario AggregationPattern

Namensraum urn:pi-patterns:pi:eip:common:Aggrega-tor:100

Softwarekomponente PI-PATTERNS_EIP COMMON

Abbildung 5.2 Aggregator Pattern – Process Integration Scenario


72

Übersicht – Integrationsprozess

� Für jede Nachricht vom Typ ContractSample wird eine eigene Prozessin-stanz eröffnet.

� Die Korrelation zwischen der ContractSample-Nachricht und der Confir-mationSample-Nachricht wird über die Felder CorrelationID und Confir-mationID aufgebaut. In beiden Nachrichten wurde diesen Feldern ein Kontextobjekt CorrelationID auf Basis des Service-Interfaces zugewiesen. Dies erleichtert die Definition im ccBPM (Integrationsprozess), da keine komplexen XPath-Ausdrücke notwendig sind.

� Innerhalb eines Multi-Mappings (2:1) werden die beiden eingehenden Nachrichten zu einer ContractStatusSample-Nachricht transformiert.

Der Aggregator-Prozess ist im Detail wie folgt aufgebaut (siehe Abbildung 5.3):

Empfangsschritt für die ContractSample-Nachricht und Eröffnung der Korrelation

Extraktion der CorrelationId für die Ausnahmebehandlung

Empfangsschritt für die korrespondierende ConfirmationSample-Nach-richt, basierend auf der aktivierten Korrelation

Aufruf des n:1-Mappings

Sendeschritt für die gemergte ConfirmationStatusSample-Nachricht

Fristzweig mit Erzeugung einer Transport Exception (� ).

Handler für die Transport Exception (� , ), generiert einen Alert

Handler für die Mapping-Exception (� ), generiert einen Alert

Integrationsprozess AggregationPattern

Namensraum urn:pi-patterns:pi:eip:common:Aggrega-tor:100

Softwarekomponente PI-PATTERNS_EIP COMMON

�1

�2

�3

�4

�5

�A �B

�B �5 �A

�C �4

Aggregator 5.1

73

5.1.8 Configuration Time

Übersicht – Konfigurationsszenario

Die Konfiguration wird durch den Modellkonfigurator erleichtert. Verwen-den Sie das oben beschriebene Process Integration Scenario AggregatorPat-tern als Vorlage. Abbildung 5.4 zeigt eine schematische Übersicht der Konfi-guration.

Für die einzelnen Kommunikationskanäle werden Templates bereitgestellt, die innerhalb des Modellkonfigurators zum Einsatz kommen.

Die Sendeservices verwenden einen File-Adapter und greifen auf die .csv-Dateien zu. Pro Eintrag wird hierbei eine einzelne Nachricht erzeugt, um die Parallelität mehrerer Prozesse zu simulieren. Die Konfiguration des File-Adapters ist daher gemäß den in den folgenden Tabellen dargestellten Infor-mationen notwendig.

Abbildung 5.3 Aggregator Pattern – Integrationsprozess

Konfigurationsszenario PI_PATTERNS_EIP_AggregatorPattern

1 2 3 4 5

A

B

C


74

Sender-Kommunikationskomponente 1

In Tabelle 5.1 finden Sie Detailinformationen zu spezifischen Parametern des Kommunikationskanals.

Abbildung 5.4 Aggregator Pattern – Konfigurationsszenario

Kommunikationskompo-nente (Business-System)

EIP_DEV_LEGACY_3RD_001

Kommunikationskanal File_SND_PI_PATTERNS_EIP_LEGACY_Con-tractSample

Parameter

Adaptertyp File

Sender

Transportprotokoll Dateisystem (NFS)

Message-Protokoll Umwandlung des Dateiinhalts

Quelle

Dateiname 01_ContractSample.csv

Verarbeitung

Quality of Service Exactly Once

Content-Konvertierung

Dokumentname ContractSample

Dokumentnamensraum urn:pi-patterns:pi:eip:common:Aggrega-tor:100

Recordset-Struktur Data, 1

Recordset-Reihenfolge Aufsteigend

Tabelle 5.1 Aggregator Pattern – Konfigurationsparameter Sender 1

AggregatorPatternProcess



EIP_DEV_R3E_EIP_100

Aggregator 5.1

75

Für Parameter, die hier nicht genannt sind, verwenden Sie die standardmä-ßig gesetzten Werte beziehungsweise system- und umgebungsabhängige Werte, falls erforderlich (zum Beispiel für den Zugriff auf die Testdatei). Die mit * bezeichneten Parameter sind Name/Wert-Kombinationen, die als manuelle Einträge in die Tabelle der Inhaltskonvertierung eingetragen wer-den müssen.

Sender-Kommunikationskomponente 2

In Tabelle 5.2 finden Sie Detailinformationen zu den spezifischen Parame-tern des Kommunikationskanals.

Recordsets pro Nachricht 1

Data.fieldSeparator * ,

Data.fieldNames * CorrelationId, BusinessObjectId, Data1, Data2, Data3, Data4, Data5

ignoreRecordsetName * True



Kommunikationskanal File_SND_PI_PATTERNS_EIP_LEGACY_Confirma-tionSample

Parameter

Adaptertyp File

Sender


Message-Protokoll Umwandlung des Dateiinhalts

Quelle

Dateiname 01_ConfirmationSample.csv

Verarbeitung

Quality of Service Exactly Once

Tabelle 5.2 Aggegator Pattern – Konfigurationsparameter Sender 2

Parameter

Tabelle 5.1 Aggregator Pattern – Konfigurationsparameter Sender 1 (Forts.)


76

Für Parameter, die hier nicht genannt sind, verwenden Sie die standardmä-ßig gesetzten Werte beziehungsweise system- und umgebungsabhängige Werte, falls erforderlich (zum Beispiel für den Zugriff auf die Testdatei). Die mit * bezeichneten Parameter sind Name/Wert-Kombinationen, die als manuelle Einträge in die Tabelle der Inhaltskonvertierung eingetragen wer-den müssen.

Integrationsprozess

Empfänger-Kommunikationskomponente

Content-Konvertierung

Dokumentname ConfirmationSample

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

Recordset-Struktur Confirmation, 1

Recordset-Reihenfolge Aufsteigend

Recordsets pro Nachricht 1

Confirmation. fieldSeparator *

,

Confirmation. fieldNames *

ConfirmationID, ConfirmationInfo

ignoreRecordsetName * True

Kommunikationskomponente AggregationPatternProcess

Wizard-basierte Genereriung Die Konfiguration (Erzeugung) des Aggregation-Pattern-Integrationsprozesses kann im Rahmen des Modellkonfigurators vorgenommen werden. Referenzieren Sie den AggregatorPattern-Prozess.


EIP_DEV_R3E_EIP_100

Kommunikationskanal File_RCV_PI_PATTERNS_EIP_ERP_Contract-StatusSample

Parameter

Tabelle 5.2 Aggegator Pattern – Konfigurationsparameter Sender 2 (Forts.)

Aggregator 5.1

77

In Tabelle 5.3 finden Sie Detailinformationen zu spezifischen Parametern des Kommunikationskanals.

Für Parameter, die hier nicht genannt sind, verwenden Sie die standardmä-ßig gesetzten Werte beziehungsweise system- und umgebungsabhängige Werte, falls erforderlich (zum Beispiel für das Zielverzeichnis der zu erzeu-genden Datei).

5.1.9 Runtime

Sie finden die Testdateien für beide Sender-Business-Systeme im folgenden Verzeichnis des Downloadangebots:

Die csv-Testdatei beinhaltet fünf beispielhafte Einträge (Zeilen). Pro Zeile wird eine Contract-Nachricht erzeugt und an den Integration Server gesen-det. Die Korrelation basiert auf dem Wert in Spalte A, der im XML-Doku-ment als CorrelationID auftaucht.

Parameter

Adaptertyp File

Empfänger


Message-Protokoll Datei

Ziel

Dateinamenschema 01_ContractStatusSample.xml

Verarbeitung

Dateierzeugungsmodus Zeitstempel hinzufügen

Tabelle 5.3 Aggegator Pattern – Konfigurationsparameter Empfänger

Testdatei 01_ContractSample.csv

Verzeichnis 04 Sample Files




78

Die csv-Testdatei beinhaltet fünf beispielhafte Einträge (Zeilen). Pro Zeile wird eine Confirmation-Nachricht erzeugt und an den Integration Server gesendet. Die Korrelation basiert auf dem Wert in Spalte A, der im XML-Dokument als ConfirmationID auftaucht.

5.2 Canonical Data Model

5.2.1 Kurzbeschreibung

Das Canonical Data Model Pattern stellt eine zusätzliche Indirektionsebene zwischen Formaten unterschiedlicher Services zur Verfügung.

5.2.2 Verwandte Patterns

Message Translator (siehe Abschnitt 5.9).

5.2.3 Problemstellung

In einer heterogenen Systemlandschaft ist die Wiederverwendung bestehen-der Mappings nicht gewährleistet. Außerdem ist die Integration neuer Ser-vices mit sehr hohem Aufwand verbunden.

5.2.4 Beschreibung

Durch die Definition kanonischer Datenformate für Geschäftsobjekte und Schnittstellen, die häufig von unterschiedlichen Services verwendet werden, kann nicht nur der Aufwand zur Implementierung neuer Interfaces, sondern es können auch die Total Cost of Ownership (TCO) zur Wartung bestehender Interfaces gesenkt werden.

Testdatei 01_ConfirmationSample.csv

Verzeichnis 04 Sample Files



Hinweis

Beachten Sie, dass die Werte beider Testdateien in Spalte A eine semantische Beziehung aufweisen müssen. Sollte dies nicht der Fall sein, so kann keine korrekte Zuordnung zu den Prozessen erfolgen. Damit die Prozessinstanzen angelegt wer-den, muss die Verarbeitung der Datei des Services EIP_DEV_LEGACY_3RD_001 als Erstes erfolgen.

219

Index

1:n-Multi-Mapping 187, 191

A

A2A (Application-to-Application) 15, 159

AAE (Advanced Adapter Engine) 28ABAP-Mapping 155ABAP-Stack 92, 156ABAP-XSLT-Mapping 154absolute Gültigkeit 142abstrakte Softwarekomponente 43abstraktes Service-Interface 84Acknowledgement-Nachrichten 131Actions 52Adaptermodul 143adapterspezifische Parameter 63Adaptertyp 134Aggregator 68, 69Analyse 31Anreicherung 89Applikationarchitekt 34Applikations-Acknowledgement 132Architektur 67ARIS 48ASUG 25asynchrone Kommunikation 131, 176

B

B2B (Business-to-Business) 15, 159BAM (Business Activity Monitoring) 27Batch-Schnittstellen 16Beispielszenarien 45Beschreibungen von Geschäftsobjekten

28Best Practices 154, 164Binding 98BPEL (Business Process Execution Langu-

age) 26BPM (Business Process Management)

17, 18, 20, 21, 22, 24Branchenstandard 81

Bulk Messaging 177Business Process Engine 28Business Process Management � BPMBusiness-System 202

C

Caching 92Canonical Data Model 45, 78CANONICAL-Softwarekomponente 81ccBPM (Cross-Component Business Pro-

cess Management) 24, 25, 27, 28, 82CCTI (Core Component Type Identifier)

94CIDX 188CIM-Daten 200COMMON- Softwarekomponente 45Component View 59Configuration Time 39, 68Content Based Router 110Content Enricher 89Content Filter 103CORE-Prozesskomponente 46Cross-Component Business Process

Management � ccBPM

D

Data Mart 19Data Warehouse 19DataSource 92Datenbankschemata 91Daten-Lookup 90Datenrepräsentation 153, 158Datenstruktur 153, 154Datentyp 153, 154Dead Letter Queue 142, 143De-facto-Standard 81Deployment 208Design 32Design Time 39, 68Distributionsliste 123Dreikomponentenstrategie 43, 49, 81

220

Index

DSAG 25DUNS 94Dynamic Router 118dynamische Empfängerermittlung 128

E

EAI (Enterprise Application Integration) 12, 17, 18, 20, 21, 22

Echtzeit 19EDI (Electronic Data Interchange) 159EDIFACT 161EII (Enterprise Information Integration)

17, 19Empfängerermittlung 112, 117Empfängerliste 119Enterprise Application Integration � EAIEnterprise Information Integration � EIIEnterprise Integration Patterns 12, 67Enterprise Service Bus � ESBEnterprise Services 27Enterprise Services Repository � ESREntwickler 34Entwicklung 32Entwicklungszeit 39Erstellungszeitpunkt 143Erweiterbarkeit 81ESB (Enterprise Service Bus) 22ESR (Enterprise Services Repository) 27,

30ESR Content 207ESR-Objekt 199ETL (Extract, Transform and Load) 12,

17, 19Exactly Once 131Exactly Once In Order 131externe Datenquelle 89, 119Extract, Transform and Load � ETL

F

File/FTP 188Filterfunktion 106Filterkriterien 103Filter-Mapping 104Fire-and-Forget-Prinzip 131

Fixed-Value-Mapping 90Flexibilität 90FTP 18FTPs 18Functional Architect 34Funktionsbausteine 92

G

Gang of Four 11Generierung von Konfigurationsobjekten

62Geschäftsprozess 46, 48Geschäftsprozessanalyst 34globale Objekte 81globale PI-Instanz 166globale Softwarekomponente 45globales PI-System 163grafisches Mapping 154, 155gruppiertes Mapping 93Guaranteed Delivery 130GUID 89Gültigkeit 141

H

heterogene Services 153HTTP-Protokoll 178Human Workflows 21

I

IDoc 133IDoc-Konvertierung 157indirektes Mapping 79Indirektionsebene 78Industriestandard 79Informationsreduktion 103Insert/Create Operation 176Integration

Architect 34Builder 28Competence Center (ICC) 12Directory 28Repository 28

221

Index

Integration (Forts.)Server 28

Integrationslogikobjekte 41Integrationsprozess 60, 69Integrationstools 23, 24IT follows Business 40ITIL 31

J

Java Connectivity Adapter Engine � JCAJava-API 92Java-Mapping 155Java-Proxy 140Java-Proxy-Deployment 199Java-Proxy-Registrierung 209Java-XSLT-Mapping 154JCA (Java Connectivity Adapter Engine)

24JDBC (Java Database Connectivity) 188JEE-Stack 155JMS (Java Message Service) 188JMS-Adapter 143, 179

K

kanonische Datenformate 78, 84kanonische Softwarekomponente 83Kapselungsschicht 92Key-User 33Key-Value-Paare 90Kommunikationskanalvorlage 54, 61Komplexität 36, 90Konfiguration einzelner Patterns 55Konfigurationsszenario 56Konfigurationszeit 39Korrelation 178

L

Laufzeit 39Lebenszeit 142lokale PI-Instanz 166

M

Mail 188Managed File Transfer � MFTMapping

Anforderungen 158Gruppe 93Kontext 93, 102Logik 85Technologien 158

Marketplace 188Master Data Management 91Message

Bridge 162Bulking 27, 188Expiration 141Expiry Period 143Mapping 53Oriented Middleware � MOMTranslator 153

Messaging Bridge 163Messaging Layer 132Metadatenablage 28Metadatenmodell 79Metriken 37MFT (Managed File Transfer) 17, 18Modellierungskonzept 39Modellkonfigurator 54, 57MOM (Message-Oriented Middleware)

20

N

Nachrichtenfilter 103nachrichteninhaltbasierte Aggregation

70Nachrichtenprotokoll 158nachrichtentypbasierte Aggregation 70Namenskonvention 39, 45, 56Namensraum 49NetWeaver 2004 24nicht-funktionale Anforderungen 36

222

Index

O

OASIS Web Service Security Standard 144

Open PI Initiative 162Open-Source-Projekt 162Operation-Mapping 53, 83OPI2 162Optimierung 33Orchestrierungskomponenten 177Order-to-Cash 47Organisation von Softwarekomponen-

ten 39OSI-Referenzmodell 153

P

parametrisierte Mapping-Programme 96, 146

Pattern 36, 67Performance 25, 155Permanentes Acknowledgement 133Persistieren 69Persistierung 131PI-Adapter-Framework 160PI-PATTERNS_EIP COMMON 54PI-spezifische Implementierung 67PI-Value-Mapping 91PI-zu-PI-Kommunikation 163PI-zu-PI-Szenario 165Planung 32Power-User 33Problemstellung 67Process Integration Scenario 49, 51Produktionssupport 33Produktionsübergabe 33Protokolle 153Proxy 133Prozess-Komponenten-Modelle 28prozessorientierte Komponentenstrategie

46Publish-and-Subscribe 119

Q

Quality of Service (QoS) 20, 131Queue 131

R

RACI 35Receiver Determination 120Registry 30Regressionstest 80relative Gültigkeit 142Reply-Nachricht 178Reprozessierung 131, 132Request/Reply 175, 176Request-Nachricht 178RFC 188RNIF 188Routing-Konditionen 111Routing-Regel 112Runtime 39, 68Runtime Workbench 28

S

SAML (Security Assertion Markup Langu-age) 26

SAP Business Connector 188SAP NetWeaver PI 24, 25, 26, 28, 30SAP-Basis 34Schlüsselpaare 93Schlüsselwerte 89, 90, 111Schritt-für-Schritt-Konfiguration 55SDM 208semantische Abhängigkeit 70semantische Zusammengehörigkeit 70serielle Reihenfolge 176Service Delivery 165Serviceobjekte 41sFTP 18Sicherheitsanforderungen 31SLA (Service Level Agreement) 33SLD (System Landscape Directory) 27,

164, 200SLD-Content 55SLD-Objekt 199

223

Index

SOAP 188Softwaredownload 199Softwarekomponentenstrategie 40, 41Sortieranforderungen 156Splitter 186Stabilität 25stateful 176stateless 176Stored-Procedure 178Swimlane 52synchrone Kommunikation 176System-Acknowledgement 132Systemumgebung konfigurieren 54

T

technische Systeme 202Test 33Testumgebung 155Top-down-Ansatz 49, 50, 52Total Cost of Ownership 78Transformation 154transientes Acknowledgement 133Trennung von Verantwortlichkeiten 44

U

Übertragbarkeit 31UDDI 30UDDI (Universal Description, Discovery

and Integration) 26UKM_ADD_KEY_MAPPINGS 102UKM_DELETE_KEY_MAPPING 102UKM_GET_KEY_MAPPINGS 102UKMS-Lookup-Funktion 96Unified Key Mapping Service 92

Update Operation 176Usage Dependency 82, 98, 201

V

Verfallsperiode 143Verfallszeitpunkt 143Vorgehensweise 39

W

Wartbarkeit 81, 90Wartungsverantwortlichkeit 91Werte-Mapping 90, 123Werte-Mapping-Agenturen 128Wiederverwendbarkeit 83Workflow 20WSDL (Web Services Definition

Language) 27WS-RM 26

X

XI (Exchange Infrastructure) 24XPath 112XSL-Stylesheet 107XSLT 19, 104

Z

zeitbasierte Aggregation 70Zielfeld-Mapping 97Zuordnung von Komponenten 59Zuverlässigkeit 31Zweikomponentenstrategie 42

enterprise integration patterns für sap netweaver pi

Documents