Erstellen eines Szenarios HTTP2RFC in XI

Transkript

1 Erstellen eines Szenarios HTTP2RFC in XI 1 Einleitung Grundlagen System Landscape (SLD) Integration Repositoy Mapping Lernziele des Kapitels Warum Mapping? Vorbereitung für das Mapping Das Mapping Das Mapping testen Message Interface anlegen Interface Mapping Integration Directory Lernziele des Kapitels Wozu dient die Konfiguration? Konfigurationsszenario anlegen Konfiguration testen Integrationsszenarien...19 Bitte in der entsprechenden Folie nachschlagen Quellen...19 Bearbeiter: Andreas Hertel Kathrin Dobbrott Entstanden im: SS07 1

2 1 Einleitung Dieses Dokument zeigt wie man eine XML über XI an ein SAP System schickt und wie man einen Prozess aufbaut. Dafür wird folgendes Szenario betrachtet. Die orange Einfärbung zeigt das Beispiel für das Integration Repository und das Integration Directory. Web-Katalog (z.b. Heiler) Kunde (mit SAP 6.40) SAP XI Lieferant 1 (mit SAP 6.20) Lieferant 2 (ohne SAP) Ersatzteilbedarf e Materialbedarf zu Bestellung Bestellung Bestelbestätigung zu Kundenauftrag XOR Kundenauftrag Kundenauftrag Auftragsbestätigung Auftragsbestätigungen sammeln Abbildung 1 Szenario 2

3 2 Grundlagen Der Aufbau des Dokumentes gliedert sich wie XI in diese Bereiche. Technische Systeme anlegen Business- Systeme anlegen Datentypen anlegen Message- Typen anlegen Message- Interfaces anlegen Message- Mapping anlegen Interface- Mapping anlegen Integrations- Szenario anlegen Business- Systeme importieren Konfigurationsaus Integrations- Empfänger- Ermittlung Interface- Ermittlung Kommunikation skanal anlegen Empfänger- Vereinbarung Logisches Routing Technisches Routing Abbildung 2 Vorgehensweise Anmelden an XI Mandant 500 Start des Integration Builders erfolgt über die Benutzersicht im XI unter Start Integration Builder Hinweis: Falls Probleme mit dem Explorer auftreten, dann URL einfach in den Netscape oder Firefox kopieren. Spätestens für das Monitoring wird das notwendig. Generell: Fehlermeldungen sind im Firefox besser zu sehen 3

4 3 System Landscape (SLD) Arbeiten im SLD werden überwiegend von dem Dozenten durchgeführt. Falls hier noch Schritte vom Studenten durchgeführt werden müssen, so ergibt sich dies intuitiv bei der Arbeit im Integration Directory und Einzelheiten zur Erstellung eines technischen Systems und eines Businesssystems sind in der SAP Hilfe nachzulesen. 4 Integration Repositoy Am Beispiel von TR_BPM_PROJEKT werden die benötigten Objekte erläutert. Abbildung 3 Szenario 1. Namensraum - Qualifier für XML-Namen, um Objekte eindeutig zu identifizieren. 2. Message-Interface - Beschreibung des Senders und Empfängers in WSDL, wichtig für das Interface-Mapping, Integrationsszenarien und den Start 3. Message-Typen - Zusammenbau von verschiedenen Datentypen mit einem Wurzelelement 4. Datentypen - Definition von Datentypen in elementar, strukturiert oder geschachtelt 5. Externe Definitionen - Import von XSD beispielsweise 6. Interface Mapping - Festlegen des Senders und Empfängers mit dem entsprechenden Message -Mapping 7. Message-Mapping - Struktur- und Wertemapping von Sender und Empfänger 8. Importierte Objekte - Import von RemoteFunctionControls (SAP interne Funktionen wie Material anlegen) oder Idoc Die genannten Zahlen werden im weiteren Dokument als Referenz zum Integration Repository angegeben. Die Reihenfolge der Bearbeitung für das Beispiel ist: 1, 5, 8, 7, 2, 6 Die Reihenfolge ist teilweise variabel. 4

5 5 Mapping 5.1 Lernziele des Kapitels In diesem Kapitel wird das Mapping erklärt. Am Ende dieses Kapitels können Sie Wozu Mapping notwendig ist die verwendeten Messages aufbauen die Schritte benennen, die nötig sind, um ein Mapping durchzuführen Testen des Mappings Schema anlegen, sollte jeder Student mal anlegen (XSD wichtig: Nameraum) Daraus ergibt sich, dass jeder sich eine eigene XML baut 5.2 Warum Mapping? Zwei grundlegende Probleme bei der Kommunikation zwischen Systemen drängen sich bei dieser Frage in den Vordergrund: 1. Zwischen verschieden Herstellern oder Releases werden unterschiedliche Technologien verwendet. 2. Gleiche Signaturen, Schlüssel, Objekte oder Werte können in unterschiedlichen Systemen unterschiedlich identifiziert sein, aber die gleiche Bedeutung haben. Das Mapping hilft Strukturen und Werte zu vereinen, durch: 1. Strukturmapping die Transformation einer Ebene in beispielsweise 3 Ebenen 2. Wertemapping die Transformation von Werten Struktur und Werte der Ein- & Ausgangsschnittstellen müssen mit Mapping-Regeln abgebildet werden. 5.3 Vorbereitung für das Mapping Eingangs- und Ausgangsschnittstellen werden im Integration Repository als XML-Schemata definiert. Die Eingangsschnittstelle kann über folgende Möglichkeiten definiert werden: 1. Mit XSD über SAP Mapping Editor (grafisch, gut zu modellieren) 2. JAVA, ABAP, XSLT (programmiertechnisch) Die Erstellung einer XSD kann über den XSD Editor erfolgen mit: a) Datentyp definieren (4) b) Messagetyp definieren (3) Oder über einen anderen Editor. In diesem Beispiel wurde sich für eine eigene XSD im SAP Mapping Editor entschieden. Dafür müssen folgende Schritte durchgeführt werden: 1. eigene XSD erzeugen (NotePad) 2. im Integrationserver (Design) Namensraum (1) erzeugen Import von Objekten 3. externe Definitionen (5) Import der eigenen XSD 4. importierte Objekte (8): RFC importieren anwendungsserver: f39, system: 06 User: JC-PRO-12 Passwort: trdemo 5

6 Die Funktion zum Anlegen einer Bestellung heißt BAPI_PO_CREATE Gewünschte Funktion mit Hilfe des BAPI-Explorers im SAP System raussuchen (Transaktion: BAPI). Abbildung 4 Ausschnitt BAPI-Explorer Importierte und geänderte Objekte müssen über die Änderungshistorie aktiviert werden. Aktivierung nicht vergessen!!!! zu 1. Beispiel für eine XSD Bestellung: <?xml version="1.0" encoding="utf-8"?> <xsd:schema targetnamespace=" xmlns:trp=" xmlns:xsd=" <xsd:element name="treinzelbedarfe" type="trp:treinzelbedarfe" /> <xsd:complextype name="treinzelbedarf"> <xsd:sequence> <xsd:element name="trartnummer" type="xsd:string" /> <xsd:element name="trartbez" type="xsd:string" /> <xsd:element name="trmenge" type="xsd:integer" /> <xsd:element name="treinheit" type="xsd:string" minoccurs="0" /> <xsd:element name="trpreis" type="xsd:decimal" minoccurs="0" /> <xsd:element name="trpostext" type="xsd:string" minoccurs="0" /> <xsd:element name="trpreiseinheit" type="xsd:string" /> <xsd:element name="trwerk" type="xsd:string" /> <xsd:element name="trlieferdatum" type="xsd:date" /> </xsd:sequence> <xsd:attribute name="trposition" type="xsd:integer" /> </xsd:complextype> <xsd:complextype name="treinzelbedarfe"> <xsd:sequence> <xsd:element name="treinkaufsorganisation" type="xsd:string" /> <xsd:element name="treinkaeufergruppe" type="xsd:string" /> <xsd:element name="trkontonummer_des_lieferanten" type="xsd:integer" /> <xsd:element name="treinkaufsbelegart" type="xsd:string" /> <xsd:element name="treinzelbedarf" type="trp:treinzelbedarf" maxoccurs="unbounded" /> </xsd:sequence> </xsd:complextype> </xsd:schema> 6

7 Hier ist gut zu erkennen, dass der Namensraum (1) übereinstimmen muss, um eine eindeutige Zuordnung zu gewährleisten. Auf weitere Erklärung zum Aufbau einer XSD wird an dieser Stelle nicht weiter eingegangen, da es dafür viele Internetquellen gibt. XSD-Kurzeinführung Es sind folgende XSD-Datentypen zu unterscheiden: XSD stellt zahlreiche eingebaute Datentypen (zum Beispiel xsd:decimal) zur Verfügung und legt einen klar definierten Wertebereich fest. Sie sind global verwendbar. Viele dieser Datentypen können nur deshalb nicht exakt auf ABAP Datentypen abgebildet werden, weil der Wertebereich nicht übereinstimmt. In solchen Fällen müssen Sie selbst prüfen, ob ein empfangener Wert im Wertebereich des Datentyps in der jeweiligen Zielsprache ist. Aus eingebauten Datentypen lassen sich mit Hilfe des Tags <simpletype> neue konstruieren. Zum Beispiel können Sie für xsd:string ein Pattern für Telefonnummern definieren. Die Proxy-Laufzeit prüft solche Erweiterungen nicht, weil solche Dinge bei der Validierung eines XML-Dokuments geprüft werden. Mit Hilfe des Tags <complextype> lassen sich dann strukturierte Datentypen definieren. Elemente, die zwischen diesem und dem dazugehörigen schließenden Tag stehen, sind lokal und können nur über den übergeordneten Typ angesprochen werden. An Stelle dieser Schachtelung können Sie beim complextype-tag auf andere strukturierte oder einfache Datentypen verweisen. 1 TREinzelbedarf ist maxoccurs="unbounded", um mehrere Einzelbedarfe zu erzeugen. Eine passende XML muss dann so aussehen: <?xml version="1.0" encoding="utf-8"?> <ns0:treinzelbedarfe xmlns:ns0=" <TREinzelbedarf TRPosition="10"> <TRArtNummer>DG-1000</TRArtNummer> <TRArtBez/> <TRMenge>11</TRMenge> <TRWerk>1000</TRWerk> <TRLieferdatum/> </TREinzelbedarf> <TREinzelbedarf TRPosition="30"> <TRArtNummer>PA-1000</TRArtNummer> <TRArtBez/> <TRMenge>4</TRMenge> <TRWerk>1000</TRWerk> <TRLieferdatum/> </TREinzelbedarf> <TREinkaufsorganisation>1000</TREinkaufsorganisation> <TREinkaeufergruppe>001</TREinkaeufergruppe> <TRKontonummer_des_Lieferanten> </TRKontonummer_des_Lieferanten> <TREinkaufsbelegart>NB</TREinkaufsbelegart> </ns0:treinzelbedarfe> 1 SAP Hilfe 7

8 5.4 Das Mapping Das Mapping findet unter dem Punkt Message Mapping (7) statt. Strukturmapping und darauf aufbauend Wertemapping Schema der Eingangs- und Ausgangsstruktur laden 1:n Mappings lassen sich am besten per Datenfluss-Editor grafisch modellieren (Verkettung von Feldern, Formatänderungen, Rechenoperationen) Abbildung 5 Das Mapping Grüne Felder sind korrekt bearbeitet, gelbe: da fehlt etwas und rote: da ist etwas falsch Pflichtfelder mit Konstanten versorgen! In der unteren Leiste Funktionen wählen. Manche Pflichtfelder ergeben sich. 8

9 Abbildung 6 Aufbau Mapping Editor 2 Beispiele: Vendor = (die 6 Nullen davor sind äußerst wichtig!!!) Datum = yyyy/mm/dd yyyymmdd (SAP konform) Mussfelder erkennbar über den BAPI-Explorer im Mandanten 900 oder 901 oder die Häufigkeit (wird beim Mapping angezeigt): 1..1 = muss 0..1 = optional Die Häufigkeit sagt jedoch nichts darüber aus, welche Felder nun wirklich von SAP verlangt werden, um das zum Beispiel eine Bestellung eine Bestellung ist. Hierfür ist es ratsam den Bestellvorgang noch einmal am SAP-System nachzuvollziehen und daran die wirklichen Mussfelder ermitteln. 2 Quelle: SAP Hilfe 9

10 5.5 Das Mapping testen Abbildung 7 Das Mapping testen Bereits vordefinierte XML aus Kapitel 5.3 für das Testen einfach reinladen über das entsprechende Symbol und auf das Symbol klicken, wo der Pfeil drauf zeigt. Abbildung 8 Laden der vordefinierten XML 10

11 5.6 Message Interface anlegen Message-Interface wird nur einmal erstellt und dann von allen immer wieder benutzt. (Idealvorstellung)# Neues Message-Interface (2) anlegen Abbildung 9 Message Interface anlegen Outbound ist der Sender, also unser INPUT und Inbound ist unser Empfänger, also unser OUTPUT 5.7 Interface Mapping Interface-Mapping (6) Neues Interface-Mapping Objekt anlegen Ausgangs- und Zielschnittstellen anlegen Abbildung 10 Interface Mapping 11

12 6 Integration Directory 6.1 Lernziele des Kapitels In diesem Kapitel wird die Konfiguration erklärt. Am Ende dieses Kapitels können Sie Ein neues Konfigurationsszenario anlegen Eine Konfiguration testen Die Schritte und Elemente bzw. Objekte benennen, die nötig sind, um eine Konfiguration durchzuführen 6.2 Wozu dient die Konfiguration? Durch die Konfiguration wird der Nachrichtenfluss für konkrete Systeme bestimmt. Dafür werden die beteiligten Kommunikationspartner, die Empfängerermittlung und weitere relevante Daten hinterlegt. Die Konfiguration wird im Integration Directory vorgenommen. 6.3 Konfigurationsszenario anlegen Ein Konfigurationsszenario fungiert als Objekt zur Gruppierung von Konfigurationsobjekten im Integration Directory. Es lässt sich mit wenigen Klicks anlegen; lediglich der Name des angelegten Szenarios ist zunächst obligatorisch. Abbildung 11: Neu angelegtes Konfigurationsszenario (ohne konfigurierte Elemente) Um die Konfiguration vollständig vornehmen zu können sind zuvor die konkreten Business Systeme, Services sowie Schnittstellen zu definieren. 12

13 Nachdem das Konfigurationsszenario angelegt wurde, sind diesem die konkreten Business Systeme aus dem System Landscape Directory zuzuordnen. Bei der Konfiguration ist die Zuhilfenahme des Konfigurationsassistenten ratsam. Er hilft bei der Definition der Nachrichtenverarbeitung vom Sender zum Empfänger. Der Konfigurationsassistent kann mit der Ikone aufgerufen werden. Er leitet den Anwender durch den Konfigurationsprozess. Dabei sind folgende Angaben erforderlich: Szenario Angaben zum Sender (der eingehenden Nachricht) Angaben zum Empfänger (der ausgehenden Nachricht) Sendervereinbarung Empfängerermittlung Interface-Ermittlung und Mapping Empfängervereinbarung Bei dem hier beschriebenen Szenario handelt es sich um eine Partner-Kommunikation, da Nachrichten auch mit externen Partnern ausgetauscht werden (vgl. Kapitel 1 13

14 Einleitung). Um eingehende Messages verarbeiten zu können, sind Service-Typ des Senders, sein konkreter Service sowie dessen spezifische Schnittstelle und der Namensraum anzugeben. Darüber hinaus ist der Typ des Adapters zuzuordnen. Für ausgehende Messages sind Service-Typ, konkreter Service sowie die spezifische Schnittstelle und der Namensraum des Empfängers anzugeben. Zudem ist die Auswahl des Adaptertyps vorzunehmen. Gegebenenfalls ist eine Sendervereinbarung für die Zuordnung des Kommunikationskanals der eingehenden Nachricht zu deklarieren. Dies ist in unserem Szenario jedoch nicht erforderlich. In der Empfängerermittlung wird der Empfänger der Nachricht benannt. Für Interface-Ermittlung und Mapping das Mapping-Objekt sowie Name und Namensraum der Nachricht anzugeben. In der Senderermittlung wird der Sender der Nachricht und der verwendete Kommunikationskanal benannt. Im letzten Schritt werden die generierten Objekte dem zuvor angelegten Konfigurationsszenario hinzugefügt. Dieses muss gesichert und aktiviert werden bevor es genutzt werden kann. 14

15 Abbildung 12: Konfigurationsszenario (mit konfigurierten Elementen) - Objektsicht 15

16 Abbildung 13: Konfigurationsszenario (mit konfigurierten Elementen) - Konfigurationssicht 6.4 Konfiguration testen Das Integration Directory bietet die Möglichkeit, angelegte Konfigurationen zu testen (Menü Werkzeuge ==> Konfiguration testen). 16

17 Abbildung 14: Konfiguration testen Vor dem Test sind folgende Angaben erforderlich: Senderservice Sender-Interface Namensraum des Senders Empfängerservice Payload Die Payload repräsentiert den eigentlichen Inhalt (Geschäftsdaten) einer Nachricht, die über die Exchange Infrastructure ausgetauscht wird, in XML-Syntax. Für den Test ist die Payload in unserem Szenario mit Beispieldaten gefüllt (vgl. Abbildung 14: Konfiguration testen). Der Test der Konfiguration kann sowohl komplett als auch sequentiell durchgeführt werden. Insbesondere für die Suche nach Fehlern ist die sequentielle Testdurchführung empfehlenswert. Ein Konfigurationsszenario ist erfolgreich getestet wenn die Sendervereinbarung, die Empfängerermittlung, Interface-Ermittlung und Mapping sowie die Empfängervereinbarung erfolgreich ausgeführt werden konnten (vgl. Abbildung 15). 17

18 Abbildung 15: Konfiguration erfolgreich getestet 18

19 7 Integrationsszenarien Bitte in der entsprechenden Folie nachschlagen 8 Quellen Marcus Banner, Heinzpeter Klein: Praxisleitfaden SAP XI 3.0 Administration, Galileo Press; Auflage: 1, Bonn 2005 Burkhardt Funk, Matthias Heiler, Valentin Nicolescu, Peter Niemeyer: Entwicklerbuch SAP Exchange Infrastructure, Galileo Press, Bonn