Leseprobe - Store & Retrieve Data Anywhere · Wenn Sie Ihre IDoc-Segmente später in einem...

LeseprobeWas ist »Application Link Enabling«, und wie funktioniert es?In dieser Leseprobe zeigen Ihnen Michael Wegelin und Michael Englbrecht, was hinter der Integrationstechnologie steckt undwie die beteiligten Anwendungen ihre Daten mittels IDocs aus-tauschen.

Michael Wegelin, Michael Englbrecht

SAP-Schnittstellenprogrammierung548 Seiten, gebunden, 3. Auflage 2014 69,90 €, ISBN 978-3-8362-2675-2

www.sap-press.de/3496

Kapitel6:»IDocsundApplicationLinkEnabling«

Inhalt

Index

DieAutoren

Wissen aus erster Hand.

http://www.sap-press.de/3496?GPP=lpn

361

In diesem Kapitel stellen wir Ihnen die Werkzeuge vor, die zur Entwicklung von ALE-Szenarien, in denen Anwendungen ihre Daten in Form von IDocs austauschen, notwendig sind. Sie lernen, wie Sie IDocs definieren, die ALE-Schicht konfigurieren und ALE-Szenarien in ABAP, C/C++, Java und C# implementieren.

6 IDocs und Application Link Enabling

In diesem Kapitel beschreiben wir das Application Link Enabling(ALE). Bei dieser Integrationstechnologie tauschen die beteiligten Anwendungen ihre Daten in Form von Intermediate Documents(IDocs) aus. Die Kommunikation erfolgt asynchron, das heißt, der Sender einer Nachricht wartet nicht auf eine direkte Antwort des Empfängers, sondern fährt nach dem Senden des Dokuments mit sei-ner Arbeit fort.

Wir werden ALE-Szenarien in den Programmiersprachen ABAP (in den Abschnitten 6.1, »IDocs«, und 6.2, »Application Link Enabling«), C/C++ (in Abschnitt 6.3, »IDoc-Programmierung mit dem SAP Net-Weaver RFC SDK«), Java (Abschnitt 6.4, »IDoc-Programmierung mit Java und dem Java Connector«) und C# (Abschnitt 6.5, »IDoc-Pro-grammierung mit dem SAP .NET-Connector«) entwickeln.

6.1 IDocs

In diesem Abschnitt lernen Sie anhand eines Beispiels, wie Sie die notwendigen Definitionen, Reports und Funktionsbausteine für die IDoc-Kommunikation in SAP NetWeaver erstellen können. In dem gewählten Szenario sollen Bestelldaten vom Mandanten 001 in den Mandanten 002 desselben SAP-Systems geschickt werden. In weite-ren Abschnitten werden wir dieses Szenario für externe Systeme erweitern.

362

IDocs und Application Link Enabling6

Vier Realisierungs-schritte

Um das Szenario zu realisieren, sind die folgenden Schritte erforder-lich:

1. Definition des IDoc-Typs Zunächst wird in Abschnitt 6.1.1, »Entwicklung von IDocs«, ein IDoc-Typ definiert. Dieser Typ legt die Struktur des IDocs fest, das versendet wird.

2. Entwicklung eines Reports für den Versand Dieser Report wird in Abschnitt 6.1.2, »Erzeugung von IDocs«, entwickelt und holt die Daten aus den Anwendungstabellen ein, baut das IDoc auf und übergibt es an das ALE-Subsystem zum Ver-sand.

3. Entwicklung eines Funktionsbausteins für den Empfang Der Funktionsbaustein, den wir in Abschnitt 6.1.3, »Eingangsver-arbeitung von IDocs«, entwickeln, nimmt das empfangene IDoc vom ALE-Subsystem entgegen und schreibt die Daten in die An-wendungstabellen.

4. Customizing des ALE-Subsystems Das ALE-Subsystem muss so eingerichtet werden, dass das ausge-hende IDoc über einen transaktionalen RFC an das Empfangssys-tem weitergeleitet und das eingehende IDoc an den richtigen Funktionsbaustein übergeben wird. Dies zeigen wir in Abschnitt 6.2, »Application Link Enabling«.

In den genannten Abschnitten werden diese vier Schritte detailliert beschrieben, bevor in den darauffolgenden Abschnitten die Realisie-rung in C/C++, Java und C# erfolgt.

6.1.1 Entwicklung von IDocs

Segmente IDocs sind Dokumente, die aus einzelnen Zeilen bestehen, die Seg-mente heißen. Der Aufbau eines Segments wird durch seinen Seg-menttyp festgelegt. Segmenttypen werden mit Transaktion WE31definiert. SAP spricht in dieser Transaktion allerdings nicht von Seg-menttypen, sondern von Segmenten.

IDoc-Segmente

Für das angesprochene Szenario müssen Sie zwei Segmente definie-ren: eines für die Kopfdaten und eines für die Positionsdaten einer Bestellung. Um ein Segment zu definieren, das die Kopfdaten für eine

363

IDocs 6.1

Bestellung aufnehmen kann, starten Sie Transaktion WE31 und geben als Namen für den Segmenttyp Z1ORDHD an. Die Namen von SAP-Segmenten beginnen mit dem Kürzel E1, kundendefinierte Seg-mente dagegen beginnen mit Z1.

DatenelementeÜber den Menüpfad Bearbeiten � Anlegen können Sie die einzelnen Feldnamen in der Segmentdefinition definieren. Dazu nehmen Sie in den Spalten Feldname und Datenelement die notwendigen Anga-ben vor (siehe Abbildung 6.1). Das System vergibt automatisch einen Namen für die Segmentdefinition, in diesem Fall Z2ORDHD000. Der Name für die Definition beginnt mit dem Namen für das Segment und endet mit einer dreistelligen Versionsnummer. Speichern Sie diese Segmentdefinition, und ordnen Sie sie dabei einem Entwick-lungspaket zu. Sobald Sie die Definition abgeschlossen haben, kön-nen Sie sie über den Menüpfad Bearbeiten � Freigabe freigeben.

Abbildung 6.1 Version 000 des Segments Z1ORDHD

Um Daten für die Positionsdaten in IDocs versenden zu können, müssen Sie zusätzlich das Segment Z1ORDPS definieren (siehe Abbil-dung 6.2).

364


Abbildung 6.2 Version 000 des Segments Z1ORDPS

IDoc-Typen

Nach der Definition der Segmente können Sie mit Transaktion WE30den IDoc-Typ ZORDER01 definieren. Mit IDocs dieses Typs werden Bestellungen transportiert.

IDoc-Typ definieren

Geben Sie im Feld Objektname den Namen für den IDoc-Typ ein, belassen Sie die Selektion des Optionsfeldes bei Basistyp, und folgen

Versionierung von Segmenten

Noch ein Wort zu den Namenskonventionen, die die Entwicklungsumge-bung hier erzwingt: Die Namen von Segmenttypen beginnen immer mit Z1(für kundendefinierte Segmente) bzw. E1 (für SAP-definierte Segmente). Die Namen von Segmentdefinitionen beginnen immer mit Z2 bzw. E2.

Wenn Sie Ihre IDoc-Segmente später in einem SAP-System mit höherer Versionsnummer weiterentwickeln möchten, können Sie dem Segmenttyp eine weitere Version mit einer erweiterten Segmentdefinition hinzufügen. Diese erweiterte Segmentdefinition enthält zusätzliche Felder. Beste-hende Felder können nicht entfernt oder geändert werden. Segmenttyp und Version der SAP-Basis legen demnach eindeutig die zugehörige Seg-mentdefinition fest.

365

IDocs 6.1

Sie dem Pfad Entwicklungsobjekt � Anlegen ((F5)). Im folgenden Dialog belassen Sie die Selektion des Optionsfeldes bei Neu anlegen

und geben dann eine Beschreibung für den IDoc-Typ an. Danach kön-nen Sie den Basistyp ZORDER01 anlegen. Wählen Sie Bearbeiten � Seg-

ment Anlegen... ((ª)+(F6)). Geben Sie an, dass es sich um ein Muss-Segment handelt, und bestimmen Sie die minimale und die maximale Anzahl für das Vorkommen dieses Segments im IDoc (siehe Abbil-dung 6.3).

Abbildung 6.3 Attribute des Segments Z1ORDHD im IDoc ZORDER01

Hierarchische IDoc-Struktur

Wählen Sie dann mit einem Mausklick das soeben eingefügte Seg-ment aus, und fügen Sie das Segment Z1ORDPS als Kind des Segments Z1ORDHD hinzu. Der IDoc-Typ ZORDER01 sieht dann aus wie in Abbil-dung 6.4.

Abbildung 6.4 IDoc-Typ ZORDER01

Nach der Definition geben Sie den IDoc-Typ im Einstiegsbild von Transaktion WE31 über Bearbeiten � Freigabe setzen frei.

366


Nachrichtentyp

Der nächste Schritt besteht aus der Definition eines Nachrichtentypsmit Transaktion WE81. Nachrichtentypen legen die Bedeutung einer Nachricht fest, deren Inhalt durch ein IDoc transportiert wird. Dabei können verschiedene Nachrichtentypen durchaus mithilfe desselben IDoc-Typs transportiert werden. Zum Beispiel entsprechen Anfragen nach Stammdaten an verschiedene SAP-Anwendungen unterschiedli-chen Nachrichtentypen. Sie werden aber meistens durch den IDoc-Typ ALEREQ01 transportiert. Für die Zwecke der Bestellanwendung legen Sie den Nachrichtentyp ZORDER mit der Kurzbeschreibung Bestellung an.

IDoc-Typ für einen Nachrichtentyp

Als letzter Entwicklungsschritt muss diesem Nachrichtentyp ein IDoc-Typ zugeordnet werden. Dies geschieht mittels Transaktion WE82. Ordnen Sie dort dem Nachrichtentyp ZORDER den Basistyp ZORDER01 für Ihr aktuelles SAP-Basis-Release zu. Auch hier können Sie in einem späteren Release eine Zuordnung für einen neuen IDoc-Typ anlegen, der dieselbe Nachricht transportiert. Dieser IDoc-Typ sollte dann natürlich eine Erweiterung des bisherigen Typs sein.

6.1.2 Erzeugung von IDocs

Report zur Datenselektion

Für das Anlegen von IDocs und deren Übergabe an die ALE-Schicht ist die Anwendung verantwortlich. Im einfachsten Fall stellt sie dazu einen Report zur Verfügung, in dem Sie als Anwender die zu versen-denden Daten selektieren. Listing 6.1 zeigt einen solchen Report für das Anwendungsbeispiel.

REPORT zifp_send_idoc. DATA: wa_hdr TYPE zifporder, " Bestellkopf wa_pos TYPE zifporderpos, " Bestellposition rec_control TYPE edidc, " Control-Record it_control TYPE TABLE OF edidc, " Control-Records it_data TYPE TABLE OF edidd, " IDoc-Zeilen wa_data TYPE edidd, " IDoc-Zeile wa_idoc_hdr TYPE z1ordhd, " IDoc-Daten Kopf wa_idoc_pos TYPE z1ordps, " IDoc-Daten Position segnum TYPE i, " Segmentnummer psgnum TYPE i. " Eltern- Segmentnummer

367

IDocs 6.1

PARAMETERS: pa_ord TYPE zifporderid. START-OF-SELECTION. * Prüfen, ob überhaupt Empfänger existieren CALL FUNCTION 'ALE_MODEL_INFO_GET' EXPORTING message_type = 'ZORDER' EXCEPTIONS no_model_info_found = 1 own_system_not_defined = 2 OTHERS = 3. IF sy-subrc <> 0. MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. ENDIF. * Kontrollsatz erzeugen rec_control-mestyp = 'ZORDER'. rec_control-idoctp = 'ZORDER01'. * IDoc aufbauen segnum = 1. SELECT SINGLE * FROM zifporder INTO wa_hdr WHERE orderid = pa_ord AND type = 'PO'. MOVE-CORRESPONDING wa_hdr TO wa_idoc_hdr. CLEAR wa_data. wa_data-segnum = segnum. wa_data-psgnum = 0. wa_data-segnam = 'Z1ORDHD'. wa_data-mandt = sy-mandt. wa_data-sdata = wa_idoc_hdr. APPEND wa_data TO it_data. ADD 1 TO segnum. psgnum = wa_data-segnum. SELECT * FROM zifporderpos INTO wa_pos WHERE orderid = wa_hdr-orderid. MOVE-CORRESPONDING wa_pos TO wa_idoc_pos. wa_data-segnum = segnum. wa_data-psgnum = psgnum. wa_data-segnam = 'Z1ORDPS'. wa_data-mandt = sy-mandt. wa_data-sdata = wa_idoc_pos. APPEND wa_data TO it_data. ADD 1 TO segnum. ENDSELECT. * IDoc verschicken

368


CALL FUNCTION 'MASTER_IDOC_DISTRIBUTE' EXPORTING master_idoc_control = rec_control TABLES communication_idoc_control = it_control master_idoc_data = it_data EXCEPTIONS error_in_idoc_control = 1 error_writing_idoc_status = 2 error_in_idoc_data = 3 sending_logical_system_unknown = 4 OTHERS = 5. IF sy-subrc <> 0. MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. ENDIF. COMMIT WORK. WRITE:/ 'IDoc verschickt.'.

Listing 6.1 Programm ZEAI_SEND_IDOC

Funktionsbaustein ALE_MODEL_

INFO_GET

Der Report überprüft zunächst, ob überhaupt ein Empfangssystem existiert, das sich für die Nachricht ZORDER interessiert. Dazu verwen-det er den Funktionsbaustein ALE_MODEL_INFO_GET und übergibt dem Importparameter message_type den Wert ZORDER.

Im Erfolgsfall füllt der Report zuerst einmal die Felder mestyp und idoctp des Kontrollsatzes rec_control mit den Werten ZORDER bzw. ZORDER01. Anhand dieses Kontrollsatzes ermittelt das ALE-Subsystem die Empfänger aus dem Verteilungsmodell, das im ALE-Customizing angelegt wird. Tabelle 6.1 zeigt einige Felder des Kontrollsatzes. Die Applikation muss dabei nur wenige Felder füllen, der Rest wird vom ALE-Subsystem erledigt.

Feld Inhalt

MANDT Mandant

DOCNUM Nummer des IDocs

DOCREL SAP-Release des IDocs

STATUS Status des IDocs

Tabelle 6.1 Komponenten des IDoc-Kontrollsatzes EDIDC

369

IDocs 6.1

KontrollsegmentDanach baut der Report das IDoc auf. Für jeden selektierten Satz der Tabelle ZIFPORDERHEADER schreibt er eine Zeile in die interne Tabelle it_data. Diese Zeile ist vom Typ EDIDD und enthält Informationen über das Segment sowie die eigentlichen Anwendungsdaten (siehe Tabelle 6.2). Das Feld SEGNAM wird dabei auf Z1ORDHD gesetzt, und in das Feld SDATA werden die Daten des Bestellkopfes kopiert.

DatensegmenteFür jede Bestellung liest der Report alle Positionen dieser Bestellung und schreibt für jede Position eine Zeile in das IDoc. Das Feld SEGNAMwird dabei natürlich auf Z1ORDPS gesetzt, und in das Feld SDATA wer-den die Positionsdaten kopiert. Schließlich übergibt der Report das aufgebaute IDoc an das ALE-Subsystem, indem er den Funktionsbau-stein MASTER_IDOC_DISTRIBUTE aufruft.

DOCTYP IDoc-Typ

DIRECT Richtung der Übertragung (1 = Ausgang, 2 = Eingang)

RCVPOR Empfängerport

RCVPRT Partnerart Empfänger

RCVPRN Partnernummer des Empfängers

SNDPOR Senderport

SNDPRT Partnerart Sender

SNDPRN Partnernummer des Senders

Feld Inhalt

Tabelle 6.1 Komponenten des IDoc-Kontrollsatzes EDIDC (Forts.)

Feld Inhalt

MANDT Mandant

DOCNUM Nummer des IDocs

SEGNUM Segmentnummer innerhalb des Dokuments

SEGNAM Segmentname

PSGNUM Nummer des Elternsegments

HLEVEL Hierarchieebene

SDATA Anwendungsdaten

Tabelle 6.2 Komponenten eines IDoc-Datensatzes EDIDD

370


6.1.3 Eingangsverarbeitung von IDocs

Funktionsbaustein zum Empfang des

IDocs

Auf Empfängerseite nimmt ein Funktionsbaustein das IDoc vom ALE-Subsystem entgegen. Der Name dieses Funktionsbausteins sollteZ_IDOC_INPUT_ZORDER sein. Zum Anlegen kopieren Sie am einfachs-ten den Funktionsbaustein ALE_INPUT_ALEAUD, da er dann sofort die richtige Schnittstelle hat (siehe Listing 6.2).

FUNCTION z_idoc_input_zorder. *"---------------------------------------------------------- *"*"Lokale Schnittstelle: *" IMPORTING *" VALUE(INPUT_METHOD) LIKE BDWFAP_PAR-INPUTMETHD *" VALUE(MASS_PROCESSING) LIKE BDWFAP_PAR-MASS_PROC *" EXPORTING *" VALUE(WORKFLOW_RESULT) LIKE BDWF_PARAM-RESULT *" VALUE(APPLICATION_VARIABLE) LIKE BDWF_PARAM-APPL_VAR *" VALUE(IN_UPDATE_TASK) LIKE BDWFAP_PAR-UPDATETASK *" VALUE(CALL_TRANSACTION_DONE) LIKE BDWFAP_PAR- *" CALLTRANS *" TABLES *" IDOC_CONTRL STRUCTURE EDIDC *" IDOC_DATA STRUCTURE EDIDD *" IDOC_STATUS STRUCTURE BDIDOCSTAT *" RETURN_VARIABLES STRUCTURE BDWFRETVAR *" SERIALIZATION_INFO STRUCTURE BDI_SER *" EXCEPTIONS *" WRONG_FUNCTION_CALLED *"---------------------------------------------------------- INCLUDE mbdconwf. " Konstanten des ALE-Subsystems DATA: wa_data TYPE edidd, " IDoc-Datenzeile wa_control TYPE edidc, " Kontrolldatensatz wa_idoc_hdr TYPE z1ordhd, " Kopfdaten aus IDoc wa_idoc_pos TYPE z1ordps, " Positionsdaten aus IDoc wa_hdr TYPE zifporder, " Kopfdaten für DB wa_hdr_old TYPE zifporder, " Alte Kopfdaten wa_pos TYPE zifporderpos. " Positionsdaten für DB * Kontrolldatensatz lesen READ TABLE idoc_contrl INTO wa_control INDEX 1. LOOP AT idoc_data INTO wa_data WHERE docnum = wa_control-docnum. IF wa_data-segnam ='Z1ORDHD'. * Bestelldatensatz einfügen oder modifizieren wa_idoc_hdr = wa_data-sdata. MOVE-CORRESPONDING wa_idoc_hdr TO wa_hdr. wa_hdr-refid = wa_hdr-orderid.

371

IDocs 6.1

wa_hdr-type = 'SO'. * Neuanlage oder Update? SELECT SINGLE * FROM zifporder INTO wa_hdr_old WHERE refid = wa_hdr-orderid. IF sy-subrc EQ 0. wa_hdr-orderid = wa_hdr_old-orderid. ELSE. CALL FUNCTION 'NUMBER_GET_NEXT' EXPORTING nr_range_nr = '01' object = 'ZIFPORDER' IMPORTING number = wa_hdr-orderid EXCEPTIONS OTHERS = 1. ENDIF. MODIFY zifporder FROM wa_hdr. IF sy-subrc NE 0. EXIT. ENDIF. ELSEIF wa_data-segnam = 'Z1ORDPS'. * Positionsdatensatz einfügen oder aktualisieren wa_idoc_pos = wa_data-sdata. MOVE-CORRESPONDING wa_idoc_pos TO wa_pos. wa_idoc_pos = wa_data-sdata. MODIFY zifporderpos FROM wa_pos. IF sy-subrc NE 0. EXIT. ENDIF. ENDIF. ENDLOOP. * Rückmeldung schreiben IF sy-subrc NE 0. idoc_status-status = c_idoc_status_error. idoc_status-msgty = sy-msgty. idoc_status-msgid = sy-msgid. idoc_status-msgno = sy-msgno. idoc_status-msgv1 = sy-msgv1. idoc_status-msgv2 = sy-msgv2. idoc_status-msgv3 = sy-msgv3. idoc_status-msgv4 = sy-msgv4. workflow_result = c_wf_result_error. return_variables-wf_param = c_wf_par_error_idocs. ELSE. idoc_status-status = c_idoc_status_ok. idoc_status-msgty = 'S'. idoc_status-msgid = 'ZIFP'.

372


idoc_status-msgno = 150. workflow_result = c_wf_result_ok. return_variables-wf_param = c_wf_par_processed_idocs. ENDIF. idoc_status-docnum = wa_control-docnum. idoc_status-repid = sy-repid. APPEND idoc_status. return_variables-doc_number = wa_control-docnum. APPEND return_variables. ENDFUNCTION.

Listing 6.2 Funktionsbaustein Z_IDOC_INPUT_ZORDER

Parameter der Schnittstelle

Die Schnittstelle des Funktionsbausteins hat elf Parameter. Diese Parameter haben folgende Bedeutung:

� IDOC_CONTRL

Diese Tabelle enthält einen Kontrolldatensatz für jedes übergebene IDoc. Von ihr benötigt der Funktionsbaustein die Spalten Docnumund Idoctp, die die Nummern und IDoc-Typen der übergebenen IDocs enthalten.

� IDOC_DATA

Diese Tabelle enthält die Segmente der IDocs, die an den Funkti-onsbaustein übergeben wurden. Aus dieser Tabelle sind die Spal-ten Docnum, Segnam und Sdata relevant, die die IDoc-Nummer, den Segmentnamen und die Anwendungsdaten enthalten.

� INPUT_METHOD

Soll der Funktionsbaustein im Hintergrund ablaufen, ist dieser Parameter initial. Falls der Funktionsbaustein als dialogfähig mar-kiert wurde, das heißt, wenn er Eingabebildschirme anzeigt, kann er die Werte 'A' oder 'E' annehmen. Im ersten Fall soll er alle Ein-gabebildschirme anzeigen, im zweiten nur dann, wenn ein Fehler auftritt.

� MASS_PROCESSING

Dieser Parameter wird nicht mehr verwendet. Er wurde aus Grün-den der Rückwärtskompatibilität mit alten Clients nicht entfernt.

� IN_UPDATE_TASK

Der Funktionsbaustein bewertet diesen Exportparameter mit 'X', wenn er die Verbuchung über Verbuchungsbausteine mit dem Zusatz IN UPDATE TASK vornimmt.

373

IDocs 6.1

� CALL_TRANSACTION_DONE

Der Funktionsbaustein füllt diesen Exportparameter mit 'X', wenn er CALL TRANSACTION verwendet, um den IDoc-Status zu schreiben.

� WORKFLOW_RESULT

Über diesen Exportparameter steuert der Funktionsbaustein, ob Ereignisse ausgelöst werden sollen.

� APPLICATION_VARIABLE

Dies ist ein optionaler Parameter, der dem Workflow übergeben werden kann.

� IDOC_STATUS Diese Tabelle enthält für jedes IDoc, das der Funktionsbaustein verarbeitet hat, einen Eintrag. Das Feld Status kann dabei die Werte 53 im Erfolgs- und 51 im Fehlerfall annehmen.

� RETURN_VARIABLES

Diese Tabelle enthält die IDoc-Nummern und die zugehörigen Nummern der verarbeiteten Anwendungsobjekte. Diese Informa-tionen werden dazu verwendet, das IDoc mit dem entsprechenden Anwendungsobjekt zu verknüpfen.

� SERIALIZATION_INFO

Dieser Parameter wird nicht mehr verwendet.

Der Funktionsbaustein Z_IDOC_INPUT_ZORDER geht davon aus, dass ihm nur ein IDoc übergeben wird. Dessen Nummer ermittelt er über READ TABLE aus der Tabelle IDOC_CONTRL. Danach macht er eine Schleife über alle Segmente des IDocs in der Tabelle IDOC_DATA. Je nachdem, ob es sich um ein Segment Z1ORDHD oder Z1ORDPS handelt, nimmt er Änderungen an den Daten der Datenbanktabelle ZIFPORDERoder ZIFPORDERPOS vor. Bei einem Fehler bricht der Funktionsbau-stein die Verarbeitung des IDocs ab. Sowohl im Fehler- als auch im Erfolgsfall füllt er zum Schluss die Parameter IDOC_STATUS, RETURN_VARIABLES und WORKFLOW_RESULT.

RegistrierungNach der Entwicklung müssen Sie den Funktionsbaustein mit Trans-aktion BD51 als Eingangsbaustein für die ALE-Verarbeitung registrie-ren. Da er nur ein IDoc verarbeiten kann, setzen Sie dabei den Input-Typ auf 1. Mit Transaktion WE57 legen Sie dann noch fest, dass der Funktionsbaustein dem Nachrichtentyp ZORDER und dem IDoc-Basis-

typ ZORDER01 für die Eingangsverarbeitung zugeordnet ist (siehe Abbildung 6.5).

374


Abbildung 6.5 Transaktion WE57

Vorgangscodes Damit der Funktionsbaustein tatsächlich für die Eingangsverarbei-tung verwendet wird, müssen Sie im empfangenden System noch einen Vorgangscode ZORDER für den Eingang mittels Transaktion WE42 hinzufügen. Wie in Abbildung 6.6 zu sehen ist, wird in diesem Vorgangscode hinterlegt, wie das eingehende IDoc zu verarbeiten ist. Der Vorgangscode wird später im ALE-Customizing bei der Festle-gung der Eingangsparameter für den Nachrichtentyp ZORDER verwen-det (siehe Abschnitt 6.2.1, »Konfiguration von ALE«).

Abbildung 6.6 Transaktion WE42 zur Pflege von Vorgangscodes

375

Application Link Enabling 6.2

6.2 Application Link Enabling

Application Link Enabling (ALE) ist ein Basisdienst innerhalb des SAP NetWeaver Application Servers ABAP, mit dem Anwendungen IDocs versenden und empfangen können. In diesem Abschnitt erläutern wir Ihnen die Konfiguration dieses Subsystems. Wir werden ALE so konfigurieren, dass wir ein IDoc vom Typ ZORDER01 vom Mandanten 001 zum Mandanten 002 senden können.

6.2.1 Konfiguration von ALE

Transaktion SALEDamit IDocs versendet und empfangen werden können, muss das ALE-Subsystem entsprechend eingerichtet werden. Dazu können Sie Transaktion SALE verwenden, die die notwendigen Schritte in der richtigen Reihenfolge auflistet, dokumentiert und Verknüpfungen zu den benötigten Transaktionen bereitstellt. Abbildung 6.7 zeigt einen Ausschnitt aus der von Transaktion SALE angezeigten Liste.

Abbildung 6.7 Transaktion SALE

376


Schritte der Konfiguration

Folgende Schritte sind erforderlich:

� Logische Systeme benennen Jedes an ALE teilnehmende System wird durch einen logischen Namen identifiziert. Diese Namen werden in die Datenbanktabelle TBDLS eingetragen.

� Mandanten die logischen Systeme zuordnen Jedem Mandanten in einem SAP-System wird ein logisches System zugeordnet. Dies geschieht bei der Pflege der Stammdaten des Mandanten.

� Zielsysteme für RFC-Aufrufe definieren Im sendenden System müssen Sie mit Transaktion SM59 tRFC-Destinationen für die Zielsysteme anlegen. Hat die tRFC-Destina-tion den gleichen Namen wie das Zielsystem, können im letzten Schritt einige Definitionen automatisch generiert werden.

� Verteilungsmodell pflegen Hier wird festgelegt, welche Nachrichten vom sendenden System an welche Empfangssysteme verschickt werden. Dieser Schritt wird im sendenden System durchgeführt.

� Partnervereinbarungen pflegen Schließlich wird festgelegt, wie ausgehende IDocs an die Emp-fangssysteme geschickt und eingehende IDocs im Empfangssystem verarbeitet werden.

Logische Systeme benennen

Um die Namen der logischen Systeme in die Datenbanktabelle TBDLSeinzutragen, klicken Sie in Transaktion SALE auf den Knoten Logi-

sches System benennen. Dies führt Sie in die Tabellenpflege der Tabelle TBDLS. Für jeden der am Szenario beteiligten Mandanten tra-gen Sie ein logisches System mit einer Bezeichnung ein. Typischer-weise wird das logische System des Mandanten <xxx> mit der Sys-tem-ID <SID> im SAP-System <SID>CLNT<xxx> benannt. Für das vorliegende Szenario benötigen Sie die beiden logischen Systeme AOUCLNT001 und AOUCLNT002.

Logisches System eines Mandanten

Um das logische System einem Mandanten zuzuordnen, klicken Sie in Transaktion SALE auf den Knoten Logisches System einem Man-

danten zuordnen. Wählen Sie den Mandanten aus, und navigieren Sie in die Detailansicht, um zur Stammdatenpflege zu gelangen. Dort tragen Sie das logische System für den ausgewählten Mandanten ein, wie es Abbildung 6.8 zeigt. Diese Zuordnung eines logischen Systems

377


zum Mandanten müssen Sie sowohl für den sendenden als auch für den empfangenden Mandanten vornehmen.

Abbildung 6.8 Logisches System eines SAP-Mandanten

RFC-Destination für den Empfänger

Im dritten Schritt pflegen Sie eine tRFC-Destination für das Emp-fangssystem. Dazu führen Sie in Transaktion SALE den Knoten RFC-

Verbindungen anlegen aus. Dies führt Sie in Transaktion SM59, mit der Sie eine neue RFC-Destination für das Zielsystem anlegen kön-nen (siehe Abbildung 6.9). Die RFC-Destination sollten Sie genauso benennen wie das logische System des Empfängers, damit im nächs-ten Schritt die Partnervereinbarungen automatisch generiert werden können.

Abbildung 6.9 RFC-Destination für ein logisches System

378


Stellen Sie sicher, dass Sie auf der Registerkarte Anmeldung &

Sicherheit ein Konto angeben, mit dem eine Anmeldung am Zielsys-tem möglich ist. Außerdem sollten Sie die tRFC-Optionen unter dem Menüpunkt Bearbeiten � tRFC-Optionen pflegen. Wenn es bei der Übertragung des IDocs zum Empfangssystem einen Kommunikati-onsfehler gibt, plant ALE automatisch einen Hintergrundjob ein, der den Versand des IDocs erneut vornimmt. Bei den tRFC-Optionen können Sie angeben, wie viele Verbindungsversuche das System maximal vornehmen und wie lange zwischen zwei Verbindungsver-suchen gewartet werden soll. Sie können die Einplanung dieses Hin-tergrundjobs aber auch ganz unterdrücken.

Verteilungsmodell pflegen

Um das Verteilungsmodell zu pflegen, müssen Sie am Mandanten für das sendende logische System angemeldet sein. Wählen Sie in Trans-aktion SALE den Knoten Verteilungsmodell pflegen und Sichten

verteilen. Legen Sie eine neue Modellsicht mit dem Kurztext »Bestel-lungen« und dem technischen Namen ZORDER an. Fügen Sie in diese Modellsicht einen Nachrichtentyp ein. Legen Sie dabei fest, dass der Sender AOUCLNT001 an den Empfänger AOUCLNT002 den Nachrichten-typ ZORDER schickt. Abbildung 6.10 zeigt das fertige Verteilungsmo-dell.

Abbildung 6.10 Verteilungsmodell

Partnerverein-barungen

generieren

Vom Verteilungsmodell aus können Sie anschließend über den Menüpfad Umfeld � Partnervereinbarung generieren die Partner-vereinbarungen erzeugen. Dabei legt das System Partnervereinbarun-gen für das sendende und empfangende System, einen Port mit der

379


vorher angelegten tRFC-Destination sowie Ausgangsparameter zum Nachrichtentyp ZORDER an.

Partnerverein-barungen prüfen

Sie können den Anlegevorgang kontrollieren, indem Sie im Vertei-lungsmodell den Menüpunkt Umfeld � Partnervereinbarung

ändern wählen. Dies führt Sie zur Transaktion WE20 (siehe Abbil-dung 6.11). Dort sehen Sie, dass unter der Partnerart Logisches Sys-

tem (LS) sowohl das Sende- als auch das Empfangssystem eingetragen worden sind. Für das Empfangssystem wurden außerdem Ausgangs-parameter für den Nachrichtentyp ZORDER angelegt.

Abbildung 6.11 Partnervereinbarungen

Ausgangs-parameter pflegen

Abbildung 6.12 zeigt die Ausgangsparameter für den Nachrichtentyp ZORDER. Dort ist als Empfängerport der generierte Port eingetragen, der seinerseits auf die zuvor angelegte tRFC-Destination verweist. Als Ausgabemodus wurde auf der Registerkarte Ausgangsoptionen das Kennzeichen für IDoc sofort übergeben gesetzt. Alternativ könnten die IDocs vor dem Übergeben zunächst gesammelt und dann als Paket übergeben werden. Im Eingabefeld Paketgröße kann die Anzahl der zu sammelnden IDocs festgelegt werden. Schließlich ist im Feld Basistyp auch noch der IDoc-Typ angegeben.

380


Abbildung 6.12 Ausgangsparameter

Eingangs- parameter

pflegen

Um die Eingangsparameter zu pflegen, müssen Sie sich am empfan-genden System anmelden. Zuerst müssen Sie mit Transaktion WE42den Vorgangscode ZORDER für den Eingang hinzufügen. Wie bereits beschrieben, wird im Vorgangscode hinterlegt, wie das eingehende IDoc zu verarbeiten ist (siehe Abbildung 6.6). Danach rufen Sie Trans-aktion WE20 zur manuellen Pflege der Eingangsparameter auf. Legen Sie zunächst unter dem Knoten Partnerart LS einen Eintrag für das logische System des Senders an.

Fügen Sie dann bei den Eingangsparametern einen Eintrag für den Nachrichtentyp ZORDER hinzu. Durch einen Doppelklick auf diesen Eintrag gelangen Sie zur Pflege der Eingangsparameter. Tragen Sie als Vorgangscode ZORDER ein, das heißt den Vorgangscode, den Sie zuvor mit der Transaktion angelegt haben. Abbildung 6.13 zeigt die konfi-gurierten Eingangsparameter. Durch einen Doppelklick auf den Vor-gangscode sehen Sie, dass er mit dem Funktionsbaustein Z_IDOC_INPUT_ZORDER verknüpft ist, der zur individuellen Verarbeitung von eingehenden IDocs dient.

381


Abbildung 6.13 Eingangsparameter

6.2.2 Test und Monitoring

Szenario testenNachdem dieses Szenario fertiggestellt ist, können Sie es testen. Mel-den Sie sich dazu an dem Mandanten an, der dem sendenden System zugeordnet ist. Führen Sie dann den Report ZIFP_SEND_IDOC aus, um Bestellungen an das empfangende System zu verschicken. Sollte der Report einen Fehler melden, können Sie sich mit dem Statusmonitorfür ALE-Nachrichten (Transaktion BD87) eine Liste der IDocs anzei-gen lassen (siehe Abbildung 6.14). Diese Liste ist nach dem Status der IDocs sortiert. Durch einen Doppelklick auf einen Eintrag zeigt die Transaktion die Liste der zugehörigen IDocs an. Durch einen Dop-pelklick auf ein IDoc können Sie sich die Details des IDocs anzeigen lassen (siehe Abbildung 6.15).

Abbildung 6.14 Statusmonitor für ALE-Nachrichten (Transaktion BD87)

382


Abbildung 6.15 IDoc im Statusmonitor für ALE-Nachrichten

Nachverarbeitung bei Fehlern

Mit Transaktion BD87 können Sie IDocs auch erneut verarbeiten, nachdem Fehler beseitigt wurden. Wenn Sie sich am Mandanten des empfangenden Systems anmelden, sollten Sie dort bei einer fehler-freien Verarbeitung die übertragenen Daten vorfinden. Auch hier können Sie sich wieder mit Transaktion BD87 eine Liste der empfan-genen IDocs anzeigen lassen, Fehler finden und IDocs nach der Feh-lerbeseitigung nochmals verarbeiten.

6.2.3 ALE-Schnittstelle für BAPIs

Damit beim Aufruf von BAPIs in einem anderen System auch die ALE-Infrastruktur genutzt werden kann, bietet Transaktion BDBG die Möglichkeit, eine ALE-Schnittstelle für ein BAPI zu generieren und zu pflegen. Im Eingangsbild von Transaktion BDBG geben Sie den Objekttyp und die Methode an, für die Sie eine ALE-Schnittstelle erzeugen lassen möchten.

Schnittstellen-objekte generieren

Die Transaktion erzeugt dann folgende Objekte, die auch in Abbil-dung 6.16 dargestellt sind:

� Nachrichtentyp Diesen Nachrichtentyp können Sie in ALE-Szenarien verwenden, um den Aufruf des entsprechenden BAPIs im Zielsystem zu veran-lassen.

383


� IDoc-Typ IDocs dieses Typs können die Export- und Tabellenparameter des BAPIs aufnehmen und diese zum Zielsystem transportieren. Für den IDoc-Typ werden die zugehörigen Segmenttypen automatisch generiert. Nach der Erzeugung müssen Sie sie lediglich freigeben. Der IDoc-Typ wird auch mit dem generierten Nachrichtentyp ver-knüpft.

� Funktionsbaustein für den ALE-Ausgang Dieser Funktionsbaustein wird von der sendenden Anwendung aufgerufen. Seine Schnittstelle entspricht der des BAPIs, das heißt, die sendende Anwendung ruft diesen Funktionsbaustein fast genauso auf wie das BAPI. Es werden lediglich noch ALE-spezifi-sche Parameter zum Objekttyp und zu den Empfängern mitgege-ben. Nach einem erfolgreichen Aufruf gibt der Funktionsbaustein eine Tabelle der Nummern der erzeugten IDocs zurück.

� Funktionsbaustein für den ALE-Eingang Dieser Funktionsbaustein dient im empfangenden System zur Ver-arbeitung des eingehenden IDocs. Er extrahiert die Daten aus dem IDoc und ruft das BAPI mit diesen Daten im empfangenden System auf.

Abbildung 6.16 Erzeugung einer ALE-Schnittstelle für das BAPI CreateFromData

Mit dieser ALE-Schnittstelle für BAPIs können Sie die Funktionen nutzen, die ALE für verteilte Prozesse bietet. Allerdings erhalten Sie

384


nicht die Rückgabeparameter des so gerufenen BAPIs, da die Kommu-nikation asynchron verläuft.

Verteilungsmodell mit BAPI

Um die generierte ALE-Schnittstelle zu verwenden, müssen Sie wie zuvor ein ALE-Verteilungsmodell pflegen. In dieses ALE-Verteilungs-modell fügen Sie nun aber keinen Nachrichtentyp, sondern ein BAPI ein (siehe Abbildung 6.17). Nachdem Sie das Verteilungsmodell gesi-chert haben, können Sie wie üblich die Partnervereinbarungen gene-rieren lassen. Für das Zielsystem wird ein neuer Ausgangsparameter zum generierten Nachrichtentyp erzeugt.

Abbildung 6.17 ALE-Verteilungsmodell für ein BAPI

Eingangsparameter Im empfangenden System müssen Sie erneut Eingangsparameter für das sendende System zum generierten Nachrichtentyp hinzufügen.In den Eingangsoptionen verknüpfen Sie den Nachrichtentyp mit dem Vorgangscode BAPI, wie es in Abbildung 6.18 dargestellt ist. Dieser Vorgangscode verweist auf den Funktionsbaustein BAPI_IDOC_INPUT1.

Empfänger-ermittlung

Das IDoc wird beim Eingang vom ALE-Subsystem an diesen Funkti-onsbaustein übergeben. Er schlägt in der Tabelle TBDE den Namen des generierten Funktionsbausteins nach. Als Selektionskriterium dient der Nachrichtentyp. Bei der Generierung der ALE-Schnittstelle hat Transaktion BDBG eine entsprechende Zeile in die Tabelle TBDE ein-getragen. An den so ermittelten Funktionsbaustein wird nun das IDoc übergeben, und er ruft, wie schon beschrieben, das BAPI mit den übergebenen Daten auf.

Zielsysteme ermitteln

Listing 6.3 zeigt einen Report, der den generierten Funktionsbaustein verwendet, um Bestellungen in den Zielsystemen zu erzeugen. Um die Zielsysteme zu ermitteln, ruft der Report zunächst den Funktions-baustein ALE_BAPI_GET_MODEL_DATA auf.

385


Abbildung 6.18 Eingangsparameter für ein BAPI

In dem zurückgegebenen Tabellenparameter bapi_model_data sind in der Spalte rcvsystem die Empfangssysteme aufgelistet, die sich auf-grund der Verteilungsmodelle für diese Daten aus dem sendenden System interessieren. Mit diesen Informationen baut der Report die interne Tabelle it_receivers auf, die er im anschließenden Aufruf des generierten Ausgangsbausteins übergibt.

REPORT zifp_send_bapi_idoc. DATA: it_model_data TYPE STANDARD TABLE OF bdi_bmodel, wa_model_data TYPE bdi_bmodel, it_log_system TYPE STANDARD TABLE OF bdi_logsys, it_receivers TYPE STANDARD TABLE OF bdi_logsys, wa_receivers TYPE bdi_logsys, orderheader TYPE zifporder, it_orderpos TYPE STANDARD TABLE OF zifporderpos, msg_text(80) TYPE c. PARAMETERS: pa_id TYPE zifporder-orderid. AT SELECTION-SCREEN. SELECT SINGLE * FROM zifporder INTO orderheader WHERE

386


orderid = pa_id AND type = 'PO'. IF sy-subrc <> 0. MESSAGE e001(zifp). ELSE. orderheader-refid = pa_id. orderheader-type = 'SO'. ENDIF. START-OF-SELECTION. SELECT * FROM zifporderpos INTO TABLE it_orderpos WHERE orderid = pa_id. CALL FUNCTION 'ALE_BAPI_GET_MODEL_DATA' EXPORTING object = 'Z_BUS4500' method = 'CREATEFROMDATA' TABLES log_system = it_log_system bapi_model_data = it_model_data EXCEPTIONS own_logical_system_not_defined = 1 OTHERS = 2. IF sy-subrc <> 0. MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. ENDIF. LOOP AT it_model_data INTO wa_model_data. APPEND wa_model_data-rcvsystem TO it_receivers. ENDLOOP. CALL FUNCTION 'ZZ_ALE_ORDER_CREATEFROMDATA' EXPORTING imorderheader = orderheader TABLES taorderpos = it_orderpos receivers = it_receivers EXCEPTIONS error_creating_idocs = 1 OTHERS = 2. IF sy-subrc <> 0. MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. ENDIF. COMMIT WORK.

Listing 6.3 Report zum Testen der ALE-Schnittstelle für ein BAPI

387

IDoc-Programmierung mit dem SAP NetWeaver RFC SDK 6.3

6.3 IDoc-Programmierung mit dem SAP NetWeaver RFC SDK

IDoc-Sender und -Empfänger

Um mit C/C++-Programmen ALE-Szenarien realisieren zu können, müssen Sie einen tRFC-Server und einen tRFC-Client schreiben. Der tRFC-Server hat die Aufgabe, den Funktionsbaustein IDOC_INBOUND_ASYNCHRONOUS zur Verfügung zu stellen. Dieser Funktionsbaustein empfängt ein IDoc als interne Tabelle. Dieses IDoc kann von der im-plementierenden C-Funktion bzw. C++-Methode in eine Datei oder in eine Datenbank geschrieben werden. Der tRFC-Client muss aus einer Datei oder aus den Daten einer Datenbank ein IDoc als interne Tabelle erzeugen und per tRFC an den Funktionsbaustein IDOC_INBOUND_ASYNCHRONOUS schicken.

In diesem Abschnitt zeigen wir Ihnen die IDoc-Programmierung mit dem SAP NetWeaver RFC SDK. Die Arbeit mit diesem SDK haben Sie bereits in den Abschnitten 3.2, »Einfache SAP-NetWeaver-RFC-Clients«, bis 3.4, »SAP-NetWeaver-RFC-Server«, kennengelernt.

6.3.1 IDoc-Empfänger

tRFC-ServerDer IDoc-Empfänger ist ein tRFC-Server, der den Funktionsbaustein IDOC_INBOUND_ASYNCHRONOUS als C-Funktion bzw. als C++-Methode implementiert. Listing 6.4 zeigt diese Funktion. Sie schreibt die emp-fangenen IDoc-Zeilen aus dem Tabellenparameter IDOC_DATA_REC_40in eine Datei.

/* IDOC_INBOUND_ASYNCHRONOUS */ RFC_RC SAP_API idoc_inbound_asynchronous( RFC_CONNECTION_HANDLE rfcConn, RFC_FUNCTION_HANDLE rfcFunc, RFC_ERROR_INFO* errInf) { RFC_RC rc = RFC_OK; RFC_TABLE_HANDLE rfcTabData; RFC_STRUCTURE_HANDLE rfcStruct; SAP_UC tbuf[MAXBUFF+1]; FILE *fp; unsigned int count; unsigned int i; RfcGetTable(rfcFunc, cU("IDOC_DATA_REC_40"), &rfcTabData, errInf);

388


fp = fopenU (data_file, cU("a")); rc = RfcGetRowCount(rfcTabData, &count, errInf); rc = RfcMoveToFirstRow(rfcTabData, errInf); for(i=0; i < count; i++) { memsetU(tbuf, cU(' '), 1064); rfcStruct = RfcGetCurrentRow(rfcTabData, errInf); RfcGetChars(rfcStruct,cU("SEGNAM"), tbuf, 30, errInf); RfcGetChars(rfcStruct,cU("MANDT"), tbuf+30, 3, errInf); RfcGetChars(rfcStruct, cU("DOCNUM"), tbuf+33, 16, errInf); RfcGetChars(rfcStruct, cU("SEGNUM"), tbuf+49, 6, errInf); RfcGetChars(rfcStruct, cU("PSGNUM"), tbuf+55, 6, errInf); RfcGetChars(rfcStruct, cU("HLEVEL"), tbuf+61, 2, errInf); RfcGetChars(rfcStruct, cU("SDATA"), tbuf+63, 1000, errInf); tbuf[1063] = cU('\n'); if (fwriteU (tbuf, 1, 1064, fp) < 1064) rc = RFC_ABAP_EXCEPTION; if(i < count – 1) rc = RfcMoveToNextRow(rfcTabData, errInf); } fclose(fp); return rc; } /* idoc_inbound_asynchronous */

Listing 6.4 Funktion idoc_inbound_asynchronous

ALE-Customizing Um den Empfänger zu testen, müssen Sie mithilfe von Transaktion SALE das entsprechende Customizing im ALE-Subsystem vorneh-men. Zunächst definieren Sie ein logisches System für das externe C/C++-Programm, zum Beispiel CTSERV. Dann pflegen Sie eine tRFC-Destination für dieses System. Damit Sie es nachher bei der Generie-rung der Partnervereinbarungen einfacher haben, sollten Sie die Des-tination genauso nennen wie das logische System.

Schließlich erstellen oder erweitern Sie in Transaktion BD64 ein ALE-Verteilungsmodell so, dass ZORDER-Nachrichten von einem SAP-Man-danten an Ihr externes C/C++-Programm geschickt werden (siehe

389

IDoc-Programmierung mit dem SAP NetWeaver RFC SDK 6.3

Abbildung 6.19). Aus dieser Transaktion heraus können Sie auch die Partnervereinbarungen generieren.

Abbildung 6.19 Erweiterung des ALE-Verteilungsmodells

Mit dem ABAP-Programm ZIFP_SEND_IDOC können Sie nun Ihren IDoc-Empfänger testen. Wenn alles richtig funktioniert, schreibt der Empfänger das von dieser Transaktion gesendete IDoc in eine Datei mit dem Namen <TID>.dat.

6.3.2 IDoc-Sender

Der IDoc-Sender sieht genauso aus wie der tRFC-Client, den Sie in Abschnitt 3.3.2, »Transaktionaler RFC-Client«, kennengelernt haben.

IDoc lesenDie Funktion read_idoc in Listing 6.5 liest das IDoc aus einer Datei, deren Name dem Sender als Kommandozeilenargument übergeben wird. Die Funktion liest die Zeilen der Datei und hängt sie an die interne Tabelle IDOC_DATA_REC_40 an. Danach baut sie den Kontroll-datensatz auf und hängt ihn an die interne Tabelle IDOC_CONTROL_REC_40 an.

/* IDoc in Tabelle IDOC_DATA_REC_40 schreiben */ RFC_RC read_idoc(FILE *fp, RFC_FUNCTION_HANDLE rfcFunc) { RFC_RC rc = RFC_OK; RFC_TABLE_HANDLE rfcTabData; RFC_STRUCTURE_HANDLE rfcStruct; SAP_UC tbuf[IDOCBUFF+1]; SAP_UC docnum[16]; RFC_ERROR_INFO errInf;

390


/* IDoc in Tabelle IDOC_DATA_REC_40 schreiben */ rc = RfcGetTable(rfcFunc, cU("IDOC_DATA_REC_40"), &rfcTabData, &errInf); while (fgetsU (tbuf, 1065, fp) != NULL) { rfcStruct = RfcAppendNewRow(rfcTabData, &errInf); RfcSetChars(rfcStruct, cU("SEGNAM"), tbuf, 30, &errInf); RfcSetChars(rfcStruct, cU("MANDT"), tbuf+30, 3, &errInf); RfcSetChars(rfcStruct, cU("DOCNUM"), tbuf+33, 16, &errInf); memcpyU(docnum, tbuf+33, 16); RfcSetChars(rfcStruct, cU("DOCNUM"), tbuf+33, 16, &errInf); RfcSetChars(rfcStruct, cU("SEGNUM"), tbuf+49, 6, &errInf); RfcSetChars(rfcStruct, cU("PSGNUM"), tbuf+55, 6, &errInf); RfcSetChars(rfcStruct, cU("HLEVEL"), tbuf+61, 2, &errInf); RfcSetChars(rfcStruct, cU("SDATA"), tbuf+63, 1000, &errInf); } /* IDOC_CONTROL_REC_40 schreiben */ RfcGetTable(rfcFunc, cU("IDOC_CONTROL_REC_40"), &rfcTabData, &errInf); rfcStruct = RfcAppendNewRow(rfcTabData, &errInf); RfcSetChars(rfcStruct, cU("DOCNUM"), docnum, 16, &errInf); RfcSetChars(rfcStruct, cU("DOCREL"), cU("701"), 3, &errInf); RfcSetChars(rfcStruct, cU("IDOCTYP"), cU("ZORDER01"), 8, &errInf); RfcSetChars(rfcStruct, cU("MESTYP"), cU("ZORDER"), 6, &errInf); RfcSetChars(rfcStruct, cU("SNDPRT"), cU("LS"), 2, &errInf); RfcSetChars(rfcStruct, cU("SNDPRN"), cU("CTSERV"), 2, &errInf); return rc; }

Listing 6.5 Funktion read_idoc

391

IDoc-Programmierung mit Java und dem Java Connector 6.4

Damit das IDoc, das von Ihrem IDoc-Sender verschickt wird, im SAP-System auch richtig verarbeitet wird, müssen Sie mit Transaktion WE20 eine Partnervereinbarung für Ihr sendendes System pflegen (siehe Abbildung 6.13).

6.4 IDoc-Programmierung mit Java und dem Java Connector

In diesem Abschnitt wenden wir uns der Programmierung mit der Java-IDoc-Bibliothek zu. Nachdem wir Ihnen die IDoc-Client-Pro-grammierung vorgestellt haben, beleuchten wir nun die Implemen-tierungsschritte, die nötig sind, um IDocs an ein empfangendes Java-System zu senden.

6.4.1 Vorbereitung zur Verwendung der IDoc-Bibliotheken

Für die Programmierung von Java-basierten, IDocs nutzenden Anwendungen ist es zunächst erforderlich, die SAP-IDoc-Bibliothekvom SAP Service Marketplace herunterzuladen. Dabei gehen Sie so vor, wie in Abschnitt 4.1.1, »Installation«, beschrieben: Nachdem Sie sich unter http://service.sap.com/connectors mit Ihrem SAP-Service-Marketplace-Benutzer angemeldet haben, navigieren Sie über das Menü zu SAP Java Connector/Tools & Services und wählen den Link Download SAP Java IDoc Class Library 3.0.<Version>. Die in diesem Buch verwendete Bibliothek entspricht der Version 3.0 und ist zu diesem Zeitpunkt die aktuellste Version, die mit dem Java Con-nector 3.0 und nachfolgenden Implementierungen des Connectors zusammenarbeitet. Die Datei trägt für die Windows-Plattform den Namen sapidoc-3.0.<Version>.zip.

Aufsetzen der Programmier-umgebung

Die Bibliothek ist sowohl für Windows als auch für zahlreiche andere Umgebungen wie Unix oder HP-UX vorhanden. Nach dem Herunter-laden und Entpacken der ZIP-Datei befindet sich ein neuer Ordner auf der Festplatte, der die Java-Dokumentation, Beispiele für die Pro-grammierung von IDoc-Client und IDoc-Server sowie ein Java-Archiv mit dem Namen sapidoc3.jar beinhaltet. Wenn Sie bereits mit Java-basierten IDoc-Anwendungen gearbeitet haben, werden Sie feststel-len, dass es im Gegensatz zu älteren Versionen nur noch eine Biblio-thek gibt (statt zwei). Neben dieser Neuerung ist auch eine Vielzahl von Klassen umbenannt und restrukturiert worden. Darüber hinaus

392


haben auch Java-5-Sprachkonstrukte Eingang in die neue IDoc-Bibli-othek gefunden.

Wie bereits angedeutet, ist es für die Nutzung der IDoc-Bibliothek notwendig, die Java-Connector-Bibliothek zu verwenden. Die JCo-Bibliothek übernimmt dabei die Kommunikation mit dem Backend, während die IDoc-Bibliothek die Klassen für den Aufbau und die Ver-arbeitung von IDocs beisteuert. Für die Programmierung setzen Sie daher neben der möglicherweise bereits vorhandenen JCo-Bibliothek zusätzlich das eben angesprochene Java-Archiv sapidoc3.jar in den Klassenpfad Ihrer Entwicklungsumgebung.

6.4.2 Client-Anwendung für IDocs

Nachdem Sie Ihr Java-Projekt in Ihrer Entwicklungsumgebung aufge-setzt haben, können Sie mit der Programmierung der ersten IDoc-Anwendung beginnen. Die Anwendung sendet dem Mandanten 002 ein IDoc vom Typ ZORDER zu.

Verbindung aufbauen

Zunächst muss wie bei der herkömmlichen Java-Client-Programmie-rung eine Verbindung zum SAP-System aufgebaut werden. Der Verbindungsaufbau ist dabei analog zur reinen Java-Connector-Pro-grammierung, die Sie in Abschnitt 4.1, »SAP Java Connector«, ken-nengelernt haben. Das heißt, Sie erzeugen ein neues JCoDestination-Objekt über die Factory-Klasse JCoDestinationManager. Wie aus dem Sequenzdiagramm aus Abbildung 6.20 ersichtlich ist, wird im nächs-ten Schritt der Zugriff auf die Metadaten der IDocs instanziiert. Meta-daten werden dabei über eine Instanz vom Typ IDocRepositorybeschrieben. Da es sich um ein Interface handelt, muss das Objekt über eine Factory erzeugt werden. Die zentrale Klasse für die Erzeugung aller relevanten Typen ist die Klasse JCoIDoc.

Zugriff über Repository-Objekt

Wie aus dem vereinfachten Klassenbild der Klasse JCoIDoc in Abbil-dung 6.20 ersichtlich ist, implementiert die Klasse für die Arbeit mit Repositorys die Methode getIDocRepository. Über das Repository-Objekt kann auf die gesamte Metadatenstruktur der IDocs zugegrif-fen werden. Wie bei der reinen JCo-Programmierung ist auch bei der IDoc-Programmierung das Repository der Ausgangspunkt für die Validierung der angegebenen Ist-Werte gegen die im ABAP-Stack definierten Metadaten. Die Metadaten müssen deshalb auch Aus-gangspunkt für die Erzeugung des IDocs sein. IDocs werden in der Java-IDoc-Bibliothek über das Interface IDocDocument repräsentiert.

393


Abbildung 6.20 Kommunikationsabhängigkeiten für die Erzeugung eines Objekts vom Typ IDocDocument

Die Erzeugung eines solchen Objekts wird über zwei Schritte ermög-licht. Im ersten Schritt ist es nötig, eine Ausprägung des Interfaces IDocFactory zu erzeugen. Dazu rufen Sie die Methode getIDoc-Factory auf der zentralen Factory-Klasse JCoIDoc auf. Die erzeugte Factory-Instanz ist Dreh- und Angelpunkt für die Bereitstellung eines IDoc-Objekts. Das IDoc-Objekt wird repräsentiert durch das InterfaceIDocDocument. Um eine Instanz dieser Klasse zu erzeugen, rufen Sie die Methode createIDocDocument auf. Die Methode erhält zwei Para-meter: Der erste Parameter ist das bereits erzeugte Repository-Objekt, der zweite Parameter gibt den Namen des IDocs an, für das eine Proxy-Repräsentation benötigt wird.

Verarbeiten der Segmente

Nachdem das Proxy-Objekt erzeugt wurde, können Sie mit der eigentlichen Verarbeitung der IDoc-relevanten Informationen begin-nen. Verwenden Sie hier das IDoc mit dem Namen ZOrder, das in Abschnitt 6.1.1, »Entwicklung von IDocs«, eingeführt und diskutiert wurde. Das IDoc besteht aus zwei Segmenten, Z1ORDHD und Z1ORDPS. Segmente werden in der Java-IDoc-Bibliothek als ISegment verarbei-tet. Um die einzelnen Segmenttypen mit Daten zu füllen, muss eine Referenz auf das Wurzelsegment der IDoc-Proxy-Repräsentation bezogen werden.

394


Das Wurzelsegment wird dabei über die Methode getRootDocumentbesorgt. Da aus der Sicht der Wurzel die Bestellkopfinformationen als Kindelemente zu sehen sind, wird die Methode addChild auf dem Wurzelsegment aufgerufen. Die Methode erhält den Namen des Seg-ments und liefert ein neues ISegment-Objekt zurück. Dieses Objekt kann nun über die Methode setValue mit den entsprechenden Wer-ten gefüllt werden. Die Methode folgt dem Java-Standard und erhält als ersten Parameter den Feldbezeichner und als zweiten Parameter den zu setzenden Wert. Nachdem der Bestellkopf mit Daten versorgt ist, können die Bestellpositionen gesetzt werden. Dazu wird auf dem ISegment-Objekt der Kopfdaten die Methode addChild aufgerufen, und die jeweiligen Werte für die Bestellpositionen werden über-geben.

Senden des IDocs an das

ABAP-System

Den Abschluss bildet das Versenden des IDocs. Für das Versenden bietet die zentrale IDoc-Klasse JCoIDoc die Methode send. Die Methode wird in vier verschiedenen Ausprägungen zur Verfügung gestellt. Die Methodenausprägungen können dabei grob in zwei Typen eingeteilt werden: Eine Ausprägung wird verwendet, wenn lediglich ein einziges IDoc an das ABAP-System gesendet werden soll. Die zweite Ausprägung der Methode wird mit einer Liste von IDocs (vom Typ IDocDocumentList) aufgerufen. Allen Methoden ist ge-meinsam, dass sie neben den IDoc-Objekten auch die IDoc-Version, ein Objekt vom Typ JCoDestination und die Transaktionsnummerentgegennehmen, mit der das IDoc verarbeitet werden soll. Die Transaktionsnummer wird analog zur JCo-Programmierung über die Methode createTID auf der Klasse JCoDestination aufgerufen.

Nachdem auf dem IDoc-Proxy-Objekt die nötigen Informationen des sendenden und des empfangenen Systems gesetzt wurden, kann mit-tels der Methode send das IDoc an das ABAP-System übergeben wer-den (siehe Listing 6.6).

public static void main(String[] args) { try { JCoDestination lcoDestination = ConnectionMan-ager.getJCoDestination("MYDESTINATION"); IDocRepository repository = JCoIDoc.getIDocRepository(lcoDestination); IDocFactory idocFactory = JCoIDoc.getIDocFactory(); IDocDocument iDocument = idocFactory.createIDocDocument(repository,IDOCNAME); //Hinzufügen des root-Segments

395


IDocSegment rootSegement = iDocument.getRootSegment(); //Erzeugen des Bestellkopfsegments IDocSegment orderheader = rootSegement.addChild(IDOC_ORDER_HEADER); orderheader.setValue(ORDER_HEADER_ORDERID , 122); orderheader.setValue(ORDER_HEADER_BUYER, "Michael Wegelin"); orderheader.setValue(ORDER_HEADER_TYPE, "A0"); orderheader.setValue(ORDER_HEADER_REFID, "2"); //Hinzufügen eines Bestellungssegments IDocSegment orderpos = orderheader.addChild(IDOC_ORDER_POS); orderpos.setValue(ORDER_POS_ORDERID,"122"); orderpos.setValue(ORDER_POS_ORDERPOS,1); orderpos.setValue(ORDER_POS_MATID, "M1"); orderpos.setValue(ORDER_POS_MATTEXT, "Schrauben und Dübel"); orderpos.setValue(ORDER_POS_ORDERCOUNT, "23"); orderpos.setValue(ORDER_POS_PRICE, 12.30); orderpos.setValue(ORDER_POS_CURRENCY, "EUR"); String tid = lcoDestination.createTID(); iDocument.setMessageType("ZORDER"); iDocument.setRecipientPartnerNumber("AOUCLNT002"); iDocument.setRecipientPartnerType("LS"); iDocument.setSenderPort("SAPBSP"); iDocument.setSenderPartnerType("LS"); iDocument.setSenderPartnerNumber("AOUCLNT001"); JCoIDoc.send(iDocument,IDocFactory.IDOC_VERSION_DEFAULT, lcoDestination , tid); lcoDestination.confirmTID(tid); } catch (JCoException e) { e.printStackTrace(); } catch (IDocMetaDataUnavailableException e) { e.printStackTrace(); } catch(IDocIllegalTypeException e) { e.printStackTrace(); } catch (IDocSyntaxException e) { e.printStackTrace(); } catch (IDocConversionException e) { e.printStackTrace(); } catch(IDocFieldNotFoundException e) { e.printStackTrace(); } }

Listing 6.6 Versenden eines IDocs mit Java

396


Prüfen der IDoc-Konsistenz

Um die Konsistenz und Syntax des IDocument-Objekts zu prüfen, können Sie die Methode checkSyntax aufrufen. Falls die Syntax beschädigt bzw. fehlerhaft ist, wird eine Ausnahme vom Typ IDocSyntaxException ausgelöst. Daher müssen Sie den Methoden-aufruf in einem try-catch-Block platzieren. Falls keinerlei Fehler in der Syntax vorhanden sind, kann das IDoc an das SAP-System gesen-det werden.

Verarbeitung von IDocument-

Objekten

Für sendende wie auch für empfangende Java-Systeme ist die Verar-beitung der reinen IDocument-Objekte oft nicht ausreichend. In vie-len Fällen ist es zum Beispiel notwendig, das empfangene Dokument in ein anderes Format zu überführen und entsprechend weiterzuver-arbeiten. Genauso kann es gerade in Infrastrukturen, in denen Nach-richten ausgetauscht werden, vorkommen, dass aus einem Zwischen-format ein IDocument-Objekt initialisiert und an das SAP-System übermittelt wird. Die Vergangenheit hat gezeigt, dass besonders hier das XML-Format (Extensible Markup Language) seine Vorteile hat, obgleich andere Formate ähnlich komfortabel sind. Ein möglicher Vorteil der Nutzung von XML ist die einfachere Konvertierung mit-tels Extensible Stylesheet Language for Transformations (XSLT) in unter-schiedliche Formate. In heterogenen Landschaften ist dadurch eine komfortable Kommunikation möglich.

XML-basierte Verarbeitung

Für die XML-basierte Verarbeitung bietet die Java-IDoc-Bibliothek als Ausgangspunkt das Interface IDocXMLProcessor. Es bietet eine Viel-zahl von Methodenausprägungen mit der Bezeichnung parse und render. Die parse-Methoden dienen der Erzeugung von IDocument-Objekten bzw. einer Liste von IDocument-Objekten (als IDocument-List-Implementierung); analog verhalten sich die render-Methoden. Sie ermöglichen es, IDocument-Objekte als XML-Darstellungen zu erzeugen.

Sie erhalten die Instanz einer SAP-Implementierung für diese Schnitt-stelle über die zentrale IDoc-Factory-Klasse IDocFactory. Die benö-tigte Methode trägt den Namen getIDocXMLProcessor. Das Program-mierbeispiel in Listing 6.7 zeigt die Möglichkeit der Speicherung eines IDocs als XML-Dokument.

private void processIDoc(IDocDocument document) { try { IDocFactory idocFactory = JCoI-Doc.getIDocFactory(); IDocXMLProcessor xmlProcessor = idocFactory.getIDocXMLProcessor();

397


FileWriter fileWriter = new FileWriter("c:\\temp\\bestellung.xml"); xmlProcessor.render(document, fileWriter); } catch (IOException e) { e.printStackTrace(); } }

Listing 6.7 XML-Verarbeitung eines IDocument-Objekts

6.4.3 IDoc-Server

Nachdem Sie ein IDoc versendet haben, stellen wir Ihnen in diesem Abschnitt das Empfangen eines IDocs vor. In unserem Beispiel schrei-ben Sie das empfangene IDoc als XML-Datei auf die Festplatte. Die Projektkonfiguration in der Entwicklungsumgebung ist ähnlich wie bei der Programmierung eines IDoc-Senders. Im Klassenpfad befin-den sich die Bibliotheken des Java Connectors sowie die Java-IDoc-Bibliothek.

Implementierung eines IDoc-Servers

Für die Implementierung des IDoc-Servers erstellen Sie eine Klasse mit dem Namen EAIIDocServer. Sie finden diese Klasse bei den Pro-grammierbeispielen zum Buch im Eclipse-Projekt JCoServerProgram-mierung im Paket de.eai.javaserverprg.idoc. Ausgangspunkt ist das Interface JCoIDocServer. Das Interface erbt dabei vom Interface JCoServer. Das bedeutet, dass es möglich ist, eine Java-basierte Infra-struktur aufzubauen, die sowohl eine reine RFC-Kommunikation als auch eine IDoc-basierte Kommunikation mit dem SAP-System ermög-licht. Das Interface JCoIDocServer führt vier neue Methoden in die Java-Connector-Programmierung ein. Es handelt sich dabei um die Methoden getIDocHandlerFactory, getIDocRepository, setIDoc-HandlerFactory und setIDocRepository.

Zu Beginn der Implementierung wird ein neues JCoIDocServer-Objekt erzeugt. Das Objekt wird mit den Kommunikationsparame-tern für das SAP-System initialisiert. Wie Sie im Programmierbeispiel in Listing 6.8 sehen können, wird dies über die Factory-Methode getServer auf der Klasse JCoIDoc ermöglicht. Darüber hinaus ist es notwendig, dem Java-Server mitzuteilen, wer welche eingehenden IDocs verarbeiten soll. Dies geschieht über die Registrierung einer Implementierung der Schnittstelle JCoIDocHandlerFactory. In dem hier vorgestellten Beispiel übernimmt dies die Klasse EAIIDoc-HandlerFactory.

398


public class EAIIDocServer { public static void main(String[] args) { try { JCoIDocServer eaiServer = JCoIDoc.getServer("EAIIDocSample"); eaiServer.setIDocHandlerFactory( new EAIIDocHandlerFactory()); eaiServer.setTIDHandler(new EAITIDHandler()); EAIIDocErrorListener listener = new EAIIDocErrorListener(); eaiServer.addServerErrorListener(listener); eaiServer.addServerExceptionListener(listener); eaiServer.setConnectionCount(1); eaiServer.start(); } catch (JCoException e) { System.out.println( "Problems while starting the IDoc-Server " + e.getMessage()); } } }

Listing 6.8 Implementierung eines IDoc-Empfängers in Java

Wie Sie bereits gesehen haben, werden IDocs per tRFC übermittelt. Daher müssen Sie dem Serverobjekt mitteilen, wer im Java-System die Verwaltung von Transaktionsnummern übernimmt. Sie registrie-ren eine Implementierung des Interfaces JCoServerTIDHandler. Die Implementierung dieses Interfaces ist dabei identisch mit der reinen JCo-Serverprogrammierung.

Verarbeitung von eingehenden IDocs

Wie bereits angedeutet, ist ein Java-IDoc-Server in der Lage, unter-schiedliche Verarbeiter für eingehende IDoc-Objekte zu implemen-tieren. Die entscheidende Komponente ist dabei eine Implementie-rung der Schnittstelle JCoIDocHandlerFactory. Die Schnittstelle bietet eine Methode mit dem Namen getIDocHandler. Sie erhält als Aufrufparameter ein Objekt vom Typ JCoIDocServerContext. Der Kontext kann dazu verwendet werden, zu entscheiden, wer die eigentliche Verarbeitung eines IDocs übernimmt. Zum Beispiel kann als Entscheidungskriterium die IDoc-Version aus dem Kontext bezo-gen werden. Die Methode getIDocHandler liefert Implementierun-gen der Schnittstelle JCoIDocHandler zurück. Das Interface selbst

399


stellt letztlich die Grundlage für die eigentliche Verarbeitung von IDocs dar und bietet dafür die Methode handleRequest an.

Die Methode erhält zwei Parameter: Der erste Parameter ist vom Typ JCoServerContext, der zweite ist vom Typ IDocDocumentList und stellt eine Liste eingegangener IDocs dar. Das Programmierbeispiel in Listing 6.9 zeigt, wie empfangene IDocs über IDocXMLProcessor als XML-Dokumente gespeichert werden können.

public void handleRequest(JCoServerContext serverCtx, IDoc-DocumentList idocList) { String filepath = "c:\\idocoutput\\"; FileOutputStream fileOS = null; OutputStreamWriter objectOS = null; try { IDocXMLProcessor xmlProcessor = JCoIDoc.getIDocFactory().getIDocXMLProcessor(); fileOS = new FileOutputStream(filepath + serverCtx.getTID()+ "Document.xml"); objectOS=new OutputStreamWriter(fileOS, "UTF8"); xmlProcessor.render(idocList, objectOS, IDocXMLProcessor.RENDER_WITH_TABS_AND_CRLF); objectOS.flush(); } catch (FileNotFoundException e) { e.printStackTrace(); } catch (UnsupportedEncodingException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); } }

Listing 6.9 Implementierung der Methode handleRequest

6.4.4 Konfiguration für den Versand von IDocs

Im Anschluss an die Implementierung des externen Java-IDoc-Ser-vers muss das SAP-System entsprechend konfiguriert werden. Dazu melden Sie sich an Ihrem SAP-System an und rufen dort Transaktion SALE auf. Zunächst definieren Sie ein logisches System für den eben vorgestellten Java-Server. Dazu folgen Sie dem Menüpfad Grundein-

stellungen � Logische Systeme einrichten � Logisches System

benennen.

400


Logisches System und tRFC-

Destination

Fügen Sie nun einen neuen Eintrag hinzu. Konfigurieren Sie dann über Transaktion WE20 Ihr gerade eingeführtes logisches System. Im Anschluss starten Sie Transaktion SM59 und pflegen eine tRFC-Des-tination für den empfangenden Java-Server, wie wir es bei der her-kömmlichen JCo-Serverprogrammierung in Abschnitt 4.1, »SAP Java Connector«, gezeigt haben. Benennen Sie auch hier die Destination genauso wie das logische System, damit Sie es bei der Generierung der Partnervereinbarungen einfacher haben.

Verteilungsmodell erweitern

Nachdem Sie die Destination erfolgreich angelegt haben, ändern Sie das Verteilungsmodell, sodass ZORDER-Nachrichten von einem SAP-Mandanten an Ihr externes Java-Programm geschickt werden (siehe Abbildung 6.21). Aus dieser Transaktion heraus können Sie auch die Partnervereinbarung erzeugen.

Abbildung 6.21 Erweiterung des ALE-Verteilungsmodells

Abschließend starten Sie Ihren Java-IDoc-Server. Mit dem ABAP-Pro-gramm ZIFP_SEND_IDOC können Sie nun Ihren IDoc-Empfänger tes-ten. Wenn alles richtig funktioniert, schreibt der Empfänger das von dieser Transaktion gesendete IDoc in das von Ihnen bei der Program-mierung angegebene Verzeichnis.

6.5 IDoc-Programmierung mit dem SAP .NET Connector

In diesem Abschnitt lernen Sie die IDoc-Programmierung mit dem SAP .NET Connector kennen. Dazu müssen Sie einen tRFC-Serverund einen tRFC-Client schreiben, wie Sie es in Kapitel 5, »Remote Function Call mit C#«, gelernt haben.

401

IDoc-Programmierung mit dem SAP .NET Connector 6.5

tRFC-Server und -Client

Der tRFC-Server muss den Funktionsbaustein IDOC_INBOUND_

ASYNCHRONOUS implementieren. Dieser Funktionsbaustein empfängt ein IDoc als interne Tabelle, die dann in eine Datei oder Datenbank geschrieben werden muss. Umgekehrt muss der tRFC-Client aus einer Datei oder aus Daten in einer Datenbank ein IDoc als interne Tabelle erzeugen und per tRFC an den Funktionsbaustein IDOC_INBOUND_ASYNCHRONOUS schicken.

6.5.1 IDoc-Empfänger

Funktionsbaustein IDOC_INBOUND_ASYNCHRONOUS

Listing 6.10 zeigt die Implementierung des Funktionsbausteins IDOC_INBOUND_ASYNCHRONOUS als Methode IdocInboundAsynchronous einer C#-Klasse RfcFunctionImpl. Diese Methode schreibt die empfange-nen IDoc-Zeilen aus dem Tabellenparameter IDOC_DATA_REC_40 in eine Datei mit dem Namen <tid>.dat, wobei <tid> die Transaktions-ID ist.

class RfcFunctionImpl { [RfcServerFunction(Name = "IDOC_INBOUND_ASYNCHRONOUS")] public static void IdocInboundAsynchronous( RfcServerContext serverContext, IRfcFunction function) { Console.WriteLine( "Führe IDOC_INBOUND_ASYNCHRONOUS aus."); // Datei TID.dat zum Schreiben öffnen string dataFileName = string.Format( "{0}.dat", serverContext.TransactionID); FileStream dataFile = new FileStream( dataFileName, FileMode.OpenOrCreate, FileAccess.Write); StreamWriter writer = new StreamWriter(dataFile); // IDoc lesen und in Datei schreiben IRfcTable idoc = function.GetTable("IDOC_DATA_REC_40"); foreach (IRfcStructure record in idoc) { for (int i = 0; i < record.Count; i++) { if (i == record.Count – 1) writer.WriteLine(record.GetString(i)); else

402


writer.Write("{0};", record.GetString(i)); } } writer.Flush(); dataFile.Close(); } }

Listing 6.10 C#-Methode IdocInboundAsynchronous

ALE konfigurieren Um den Empfänger zu testen, müssen Sie, wie in Abschnitt 6.2.1, »Konfiguration von ALE«, beschrieben, das entsprechende Customi-zing im ALE-Subsystem vornehmen: Sie definieren ein logisches Sys-tem für das externe C#-Programm, pflegen eine tRFC-Destination für dieses System und erstellen oder erweitern ein ALE-Verteilungsmo-dell so, dass ZORDER-Nachrichten von einem SAP-Mandanten an Ihr externes C#-Programm geschickt werden. Danach generieren Sie aus dem Verteilungsmodell heraus die Partnervereinbarungen und testen anschließend Ihren IDoc-Empfänger mit dem ABAP-Programm ZIFP_SEND_IDOC.

6.5.2 IDoc-Sender

IDoc lesen Der IDoc-Sender sieht genauso aus wie der tRFC-Client, den wir in Abschnitt 5.3.2, »Transaktionaler RFC«, implementiert haben. Die Methode PrepareFunction in Listing 6.11 liest das IDoc aus einer Datei, deren Name als Parameter übergeben wird. Die Methode liest die Zeilen der Datei und hängt sie an die interne Tabelle IDOC_DATA_REC_40 an. Danach baut sie den Kontrolldatensatz auf und hängt ihn an die interne Tabelle IDOC_CONTROL_REC_40 an.

static IRfcFunction PrepareFunction(string dataFileName) { RfcDestination dest = RfcDestinationManager. GetDestination("NCO_ASHOST"); IRfcFunction function = dest.Repository.CreateFunction( "IDOC_INBOUND_ASYNCHRONOUS"); FileStream dataFile = new FileStream( dataFileName, FileMode.Open, FileAccess.Read); StreamReader reader = new StreamReader(dataFile); // IDoc lesen und in Tabelle füllen IRfcTable records = function.GetTable("IDOC_DATA_REC_40");

403

IDoc-Programmierung mit dem SAP .NET Connector 6.5

while (!reader.EndOfStream) { string line = reader.ReadLine(); records.Append(); string[] fields = line.Split(new char[] { ';' }); for (int i = 0; i < fields.Count(); i++) records.SetValue(i, fields[i]); } // Kontrolldatensatz aufbauen string docnum = records.GetString("DOCNUM"); IRfcTable control = function.GetTable( "IDOC_CONTROL_REC_40"); control.Append(); control.SetValue("DOCNUM", docnum); control.SetValue("DOCREL", "702"); control.SetValue("IDOCTYP", "ZORDER01"); control.SetValue("MESTYP", "ZORDER"); control.SetValue("SNDPRT", "LS"); control.SetValue("SNDPRN", "CSTSERV"); dataFile.Close(); return function; }

Listing 6.11 Die Methode PrepareFunction

Damit das IDoc, das von Ihrem IDoc-Sender verschickt wird, im SAP-System auch richtig verarbeitet wird, müssen Sie mit Transaktion WE20 eine Partnervereinbarung für Ihr sendendes System pflegen, wie in Abschnitt 6.2.1, »Konfiguration von ALE«, beschrieben (siehe Abbildung 6.13).

Inhalt

7

Inhalt

Einleitung ..................................................................................... 13

1 Grundlagen der SAP-Schnittstellenprogrammierung ................................ 17

1.1 SAP NetWeaver Application Server ............................. 171.1.1 SAP-Lösungen und SAP NetWeaver ............... 181.1.2 SAP NetWeaver Application Server ABAP ...... 201.1.3 SAP NetWeaver Application Server Java ......... 34

1.2 Sicherheit ................................................................... 391.2.1 Sicherheit in heterogenen Landschaften ......... 391.2.2 User Management Engine .............................. 441.2.3 KeyStores: Authentifizierung, Signierung,

Verschlüsselung ............................................. 461.3 Authentifizierung und Autorisierung ........................... 50

1.3.1 Single Sign-on mit dem SAP NetWeaver Portal ............................................................. 51

1.3.2 Sichere Integration externer Systeme ............. 561.4 Programmierung des SAP NetWeaver Application

Servers ABAP .............................................................. 681.4.1 ABAP Dictionary ............................................ 691.4.2 Authentifizierung und Autorisierung .............. 741.4.3 Nummernkreise ............................................. 751.4.4 Funktionsbausteine ........................................ 761.4.5 Verbuchungsbausteine ................................... 781.4.6 Anwendungsfunktionalität und

Benutzeroberflächen ...................................... 801.5 Überblick über die Schnittstellen

technologien von SAP ................................................. 811.5.1 Dateischnittstelle ........................................... 821.5.2 Remote Function Call (RFC) ........................... 841.5.3 Business Application Programming Interface

(BAPI) ............................................................ 951.5.4 Application Link Enabling (ALE) ..................... 981.5.5 SOAP ............................................................. 1041.5.6 OData ............................................................ 105

Inhalt

8

2 Remote Function Call mit ABAP .............................. 107

2.1 RFC-Funktionsbausteine in ABAP ............................... 1072.1.1 Funktionsbausteine zum Lesen ...................... 1072.1.2 Aufruf per sRFC ............................................. 1102.1.3 Funktionsbausteine zum Löschen und

Ändern .......................................................... 1132.2 Transaktionaler RFC ................................................... 1192.3 Queued RFC .............................................................. 125

2.3.1 qRFC mit Ausgangswarteschlange .................. 1272.3.2 qRFC mit Ausgangs- und

Eingangswarteschlange .................................. 1292.4 Background-RFC ........................................................ 1332.5 Business-Objekte und BAPIs ...................................... 137

2.5.1 Entwicklung von Business-Objekten .............. 1372.5.2 Entwicklung von BAPIs .................................. 1392.5.3 Business-Objekt »Helpvalues« ........................ 161

3 Remote Function Call mit C/C++ ............................. 167

3.1 SAP NetWeaver RFC Software Development Kit ........ 1673.1.1 Inhalte des SAP NetWeaver RFC Software

Development Kits ......................................... 1673.1.2 Kompilieren und Linken von C- und

C++-Programmen .......................................... 1693.2 Einfache SAP-NetWeaver-RFC-Clients ........................ 174

3.2.1 Aufbau eines SAP-NetWeaver-RFC-Clients .... 1753.2.2 Einfache Parameter ....................................... 1823.2.3 Strukturierte Parameter ................................. 1843.2.4 Tabellenparameter ........................................ 186

3.3 Komplexe SAP-NetWeaver-RFC-Clients ..................... 1893.3.1 Aufruf von BAPIs ........................................... 1893.3.2 Transaktionaler RFC-Client ............................ 1913.3.3 Queued RFC-Server ....................................... 203

3.4 SAP-NetWeaver-RFC-Server ....................................... 2043.4.1 Einfacher RFC-Server ..................................... 2053.4.2 Implementierung der Funktionen .................. 2093.4.3 Transaktionaler RFC-Server ............................ 213

4 Remote Function Call mit Java ................................ 223

4.1 SAP Java Connector ................................................... 2234.1.1 Installation .................................................... 224

Inhalt

9

4.1.2 Architektur des SAP Java Connectors .............. 2254.1.3 Programmierung mit dem

SAP Java Connector ....................................... 2274.1.4 Verarbeitung von Tabellen und Strukturen ..... 2374.1.5 Transaktionaler RFC ....................................... 2404.1.6 Queued RFC .................................................. 2414.1.7 Metadatenverarbeitung .................................. 244

4.2 SAP Enterprise Connector ........................................... 2454.2.1 Erzeugen von Proxy-Klassen ........................... 2464.2.2 Programmierung des Clients ........................... 251

4.3 Nutzung generischer Backend-Modelle ....................... 2534.3.1 Generische Proxy-Klassen ............................... 2534.3.2 Klassenabhängigkeiten ................................... 2554.3.3 Konfiguration der Destinationen .................... 2574.3.4 Implementierung ........................................... 260

4.4 RFC-Server .................................................................. 2694.4.1 Serverseitiges und clientseitiges

Repository ..................................................... 2694.4.2 Programmierung eines einfachen

JCo-Servers .................................................... 2724.4.3 Registrieren eines Funktionshandlers .............. 2744.4.4 Verwaltung von Transaktionen ....................... 276

4.5 SAP NetWeaver Portal Connector Framework ............. 2784.5.1 Java Connector Architecture ........................... 2784.5.2 System Landscape des Portals ........................ 2794.5.3 Einführung in die Portalprogrammierung ........ 2814.5.4 Anwendungsbeispiel des Connector

Frameworks ................................................... 285

5 Remote Function Call mit C# ................................... 293

5.1 SAP .NET Connector ................................................... 2935.1.1 Installation des SAP .NET Connectors ............. 2945.1.2 Verwendung des SAP .NET Connectors in

Visual-Studio-Projekten ................................. 2965.2 Einfache RFC-Clients ................................................... 299

5.2.1 Aufbau eines einfachen RFC-Clients ............... 2995.2.2 Destination-Management .............................. 3015.2.3 Repository und Metadaten ............................. 3085.2.4 Einfache Parameter ........................................ 3105.2.5 Strukturierte Parameter .................................. 3115.2.6 Tabellenparameter ......................................... 314

Inhalt

10

5.2.7 Ausnahmebehandlung ................................... 3165.3 Komplexe RFC-Clients ................................................ 320

5.3.1 Aufruf von BAPIs und Session-Management ................................................. 320

5.3.2 Transaktionaler RFC ....................................... 3235.3.3 Queued RFC .................................................. 3385.3.4 Background RFC ............................................ 338

5.4 RFC-Server ................................................................. 3415.4.1 Serverkonfiguration und Implementierung ..... 3425.4.2 Repository-Management ............................... 3495.4.3 Sicherheitsmanagement ................................. 3495.4.4 Session-Management .................................... 3515.4.5 Transaktionaler RFC ....................................... 3535.4.6 Queued RFC .................................................. 3565.4.7 Background RFC ............................................ 3575.4.8 Zustand des Servers überwachen ................... 358

6 IDocs und Application Link Enabling ....................... 361

6.1 IDocs ......................................................................... 3616.1.1 Entwicklung von IDocs .................................. 3626.1.2 Erzeugung von IDocs ..................................... 3666.1.3 Eingangsverarbeitung von IDocs .................... 370

6.2 Application Link Enabling .......................................... 3756.2.1 Konfiguration von ALE .................................. 3756.2.2 Test und Monitoring ..................................... 3816.2.3 ALE-Schnittstelle für BAPIs ............................ 382

6.3 IDoc-Programmierung mit dem SAP NetWeaver RFC SDK .................................................................... 3876.3.1 IDoc-Empfänger ............................................ 3876.3.2 IDoc-Sender .................................................. 389

6.4 IDoc-Programmierung mit Java und dem Java Connector .......................................................... 3916.4.1 Vorbereitung zur Verwendung der

IDoc-Bibliotheken ......................................... 3916.4.2 Client-Anwendung für IDocs ......................... 3926.4.3 IDoc-Server ................................................... 3976.4.4 Konfiguration für den Versand von IDocs ...... 399

6.5 IDoc-Programmierung mit dem SAP .NET Connector .................................................. 4006.5.1 IDoc-Empfänger ............................................ 4016.5.2 IDoc-Sender .................................................. 402

Inhalt

11

7 SOAP ........................................................................ 405

7.1 Inside-Out-Webservices und -Webclients mit dem AS ABAP ..................................................................... 4057.1.1 ABAP-SOAP-Webservice ................................ 4067.1.2 ABAP-SOAP-Webclient .................................. 415

7.2 Outside-In-Webservices und -Webclients mit dem AS ABAP ..................................................................... 4207.2.1 System Landscape Directory ........................... 4207.2.2 Service-Interfaces ........................................... 4217.2.3 ABAP-SOAP-Proxys ........................................ 425

7.3 Webservices und Webclients mit dem AS Java ............ 4297.3.1 Webservice-Infrastruktur im AS Java .............. 4307.3.2 Webservice-Provider mit J2EE ........................ 4347.3.3 Webservice-Clients ........................................ 4417.3.4 Adaptiver Webservice mit Web Dynpro ......... 4467.3.5 Webservice-Programmierung mit SAP JEE ...... 447

7.4 SOAP-Programmierung mit Java ................................. 4687.4.1 Java API for XML Web Services ...................... 4687.4.2 Implementierung eines Webservice-

Clients ........................................................... 4707.4.3 Implementierung eines Webservice-

Providers ........................................................ 4717.5 SOAP-Programmierung mit C# ................................... 472

8 SAP NetWeaver Gateway und OData ...................... 477

8.1 SAP NetWeaver Gateway ............................................ 4778.1.1 Embedded Deployment ................................. 4788.1.2 Central Hub Deployment ............................... 479

8.2 OData-Protokoll ......................................................... 4808.2.1 Atom-Syndication-Format .............................. 4818.2.2 Representational State Transfer ...................... 4818.2.3 OData-Datenmodell ....................................... 482

8.3 OData-Services entwickeln ......................................... 4878.3.1 Beschreibung des Datenmodells ..................... 4898.3.2 Generierung der Komponenten und

Anlegen des OData-Services .......................... 4928.3.3 Implementierung der Data-Provider-Klasse .... 4968.3.4 Monitoring und Fehlersuche .......................... 509

8.4 OData-Services mit SAPUI5 konsumieren ................... 5118.4.1 Von Phoenix zu SAPUI5 ................................. 512

Inhalt

12

8.4.2 Konsumieren eines OData-Services ............... 5158.5 OData-Services mit C# konsumieren .......................... 522

Anhang............................................................................ 531

A Literaturhinweise .................................................................. 531B Die Autoren ......................................................................... 533

Index ............................................................................................ 535

535

Index

.NET 472

.NET Connector � SAP .NET Connector

.NET-Assembly 296/IWFND/MAINT_SERVICE 489,

493, 510

A

ABAP 20Kurz-Dump 94SOAP-Proxy 425SOAP-Webclient 415SOAP-Webservice 406Stack 19Transaktionskonzept 32

ABAP Dictionary 69, 85, 139, 250ABAP Workbench 17, 70, 405Access Control List 52, 53ACL 52, 53Adapter 45adaptiver Webservice 442ALE 98, 361

Architektur 98Ausgangsbaustein 383Ausgangsparameter 379Customizing 99Eingangsbaustein 373, 383Eingangsparameter 380, 384Empfängerermittlung 384Empfängerport 379Konfiguration 362, 375Partnerprofil 102Statusmonitor 381Verteilungsmodell 101, 368, 376,

378, 384, 388, 400, 402Vorgangscode 374

ALE_MODEL_INFO_GET 368Änderungsvormerkung 33Anmeldesprache 21Anmeldung 20Anmeldungsmandant 23Annotation 36, 471

SOAPBinding 471WebMethod 471

Annotation (Forts.)WebService 454

Anwendungsfunktionsleiste 23Anwendungskomponente 34Anwendungsprotokoll 25Anwendungsschicht 17, 18, 20,

34, 37Anwendungsserver 18, 23, 34, 85Anwendungssicherheit 40API 35app.config 475APPEND 255Application Link Enabling � ALE 361Application Programming Interface

35Applikationsschicht � Anwendungs-

schichtApplikationsserver

Monitoring 37Profiling 37

Architektur, Client-Server 18aRFC 133ARFC2 254, 267ARFC2GenericModelClass 257, 266ARFC2GenericModelClassExecutable

257, 265, 266ARFC2Model 256, 265ARFC2ModelInfo 256, 264, 265ARFCSDATA 119ARFCSSTATE 119Array 79Array Insert 143ASP.NET 81Assembly 296Assoziation 483, 491asymmetrisches Verfahren 41asynchrone Kommunikation 35asynchroner RFC 90, 132Atom 477Atom Publishing Protocol 105, 477Atom Syndication 105, 477, 481Atom-Feed 498Ausgangswarteschlange 126, 131Ausnahme 78

communication_failure 112, 122

536

Index

Ausnahme (Forts.)Klasse 318RfcAbapException 319RfcAbapRuntimeException 318RfcCommunicationException 318RfcLogonException 318system_failure 112

auth/authorization_trace 94Authentifizierung 39, 50, 255AUTHORITY CHECK 93Autorisierung 39, 50

B

Backend-Modell 254Backend-Modell, generisches 253Background-RFC 93, 133Background-Workprozess 27BAdI 140BALW_BAPIRETURN_GET2 146BAPI 95, 97, 137, 382

ALE-Schnittstelle 103, 382BAPI_TRANSACTION_COMMIT 97,

141, 154, 189, 320BAPI_TRANSACTION_ROLLBACK

97Eingabehilfe 161Fehlermeldung 150freigeben 148GetSearchhelp 161instanzabhängiges 98, 149instanzunabhängiges 98, 156Konvention 139Parameter 140Return-Parameter 142Transaktionsmodell 123, 141, 189Verbuchung 143

BAPI_TRANSACTION_COMMIT 148Batch-Input 82, 83

Mappe 83Monitor 83

BeginSaveChanges 529Beispielanwendung 68Benutzer 21

Kontext 24, 28Name 21, 23Oberfläche 80SAPJSF 44Sitzung 20, 24

Benutzer (Forts.)Stammsatz 21

Berechtigung 75Objekt 75, 93Prüfung 109, 116, 162RFC 93

Bestellung 69bgRFC 93, 133

Client 341Monitor 136SAP .NET Connector 357Scheduler 137Unit-Objekt 133

Bildschirmbild 23, 30Binding, Custom 475bindRows 519Bindungsstil

Document 412RPC 412

BOR 95, 489BSP 81, 512Business Add-in � BAdIBusiness Application Programming

Interface � BAPI 95, 137, 382Business Exception 502Business Object Builder 137Business-Objekt 95, 137

C

C# 522C++-Compiler 167CALL FUNCTION 76CALL TRANSACTION 82Cast 288CCI 279C-Compiler 167Changing-Parameter 77, 250checkTID 276Classloader, Referenz 268, 289Client 20Client-Server-Architektur 18Code, unmanaged 296Codegenerator 254commit 113, 277COMMIT WORK 32, 33, 78, 120Commit, impliziter 113Common Client Interface 279Complex Type 483

537

Index

Conceptual Schema Definition LanguageCSDL 483

confirmTID 277Connection Pool 306Consumer, Proxy 427Content-Administrator 291content-type 504Controller 513, 516cookie 504CORS 520create 482, 521CREATE_ENTITY 502, 506C-RFC-Bibliothek 226Cross Origin Resource Sharing 520Cross Site Request Forgery 503CRUD 482, 487, 492CSDL 483CSRF 503CSRF-Token 503, 504, 527, 528CurrentIndex 315CurrentRow 315

D

Data-Provider-Klasse 487, 493Data-Provider-Klasse, Implementie-

rung 496data-sap-ui-theme 518Datei

Schnittstelle 82Service 25

Datenbank 18Datenbank-Commit 92Datenbindung 514Datencontainer 184Datenelement 70Datenschicht 18Datensicherheit 40Datenzugriffsschicht 37DDIC-Import 490Delegat 341DELETE 33, 482, 508, 509DELETE_ENTITY 508, 509DeleteObject 528demilitarisierte Zone 480Dependency-Injection 465Deployment Descriptor 36, 289, 434Design by Contract 36

Destination 110, 112, 222, 254, 300, 376, 377Application Data 265Authentifizierung 305BACK 112Bezeichner 446bgRFC 135DestinationConfiguration 329DestinationDataProvider 229Konfigurationsparameter 304Manager 300NONE 112Repository-Objekt 300SPACE 112

Developer Studio � SAP NetWeaver Developer Studio 281

DIAG 20, 25Dialog 30

Schritt 30Workprozess 27

digitale Signatur 42digitales Zertifikat 43Direct Input 83direkte Verbindung 230Dispatcher 25, 28DLL 225, 295Double Stack 18Dynamic Information and Action

Gateway 20, 25Dynamic Link Library 225, 295Dynamic Web Project 260Dynpro 30

E

EAR-Projekt 268Eclipse 447, 470, 513Eclipse-Plug-in 513ECo 246, 253EDM 482Eingabeprüfung 72Eingangswarteschlange 126, 131Einwegfunktion 42EIS 278EJB � Enterprise JavaBeanEJB, Container 37Endpunkt 409, 410Endpunkt-API 469EndSaveChanges 529

538

Index

Enqueue 27Enqueue-Workprozess 32Enterprise Connector 246, 253Enterprise Information System 278Enterprise JavaBean 34, 37, 434Enterprise Service 425Enterprise Services Repository 406,

420, 421Datentyp 421Service-Interface 422

Enterprise-Application-Projekt 434, 445

Entität 483Datentyp 483Eigenschaften 483Relationen 483

Entitätsmenge anlegen 492Entity

Bean 35Container 483Data Model 482Key 483Objekt 483Set 483, 484Type 483

Ereignis 513Ereignisbehandler 514ESR � Enterprise Services

RepositoryEvent 513Eventhandler 514Execute 528Exportparameter 77, 237, 250, 252,

272, 286Extensible Markup Language � XMLExtensible Stylesheet Language for

Transformations � XSLTextern 174externer Modus 22, 24

F

Fault-Typ 251Fehlerbehandlung 251Firewall 29Fremdschlüsselbeziehung 72Function Builder 76, 78, 89, 139Funktionsbaustein 33, 76, 489

ALE_INPUT_ALEAUD 370

Funktionsbaustein (Forts.)MASTER_IDOC_DISTRIBUTE 369Metadaten 309Parameter 310QIWK_REGISTER 132remotefähiger 84Schnittstelle 77TRFC_QIN_RESTART 132, 204Verbuchung 33

Funktionsgruppe 77, 107Funktionshandler 274

generischer 348registrieren 275

G

Gateway 26, 85, 204Host 88Monitor 94Service 88Service Builder 489

Generic Security Services Application Programming Interface 63

gepoolte Verbindung 230GET 482, 504GET_ENTITY 499, 501GET_ENTITYSET 497, 500getFunctionTemplate 244GetTable() 314GetValue() 310GetXXX-Methode 310Global Assembly Cache (GAC) 295Globally Unique Identifier 323Größenkategorie 72GSS-API V2 63GUID 323GUID-Speicher 357

H

Hash-Funktion 42Hash-Wert 42Helpvalues 161Hook-Methode 36Hostname 23, 24HTMLB 512HTTP 26, 405, 480, 482HTTP Authentication 466Hypertext Transfer Protocol � HTTP

539

Index

I

ICF 104, 488, 493ICF-Recorder 509ICM 26, 104IConnection 286IConnectorGatewayService 285Identität 46IDoc 98, 100, 102, 361

Basistyp 364Bibliothek 391Client 392Datensatz 369Eingangsverarbeitung 362Empfänger 387Erzeugung 366IDOC_INBOUND_ASYNCHRO-

NOUS 99, 387, 401IDocDocument 393IDocFactory 393IDocRepository 392IDoc-Typ 101, 362IDocXMLProcessor 396Kontrollsatz 368, 369, 372mit C# 400mit Java 391Nachverarbeitung 382Nummer 373Segment 362, 393Segmentdefinition 363Segmenttyp 362Server 397Status 373Typ 364, 366, 383Versand 362XML-Verarbeitung 396

IInteraction 287IInteractionSpec 287Implementation Container 433Importparameter 77, 233, 250, 252,

286, 287IN BACKGROUND TASK 119IN UPDATE TASK 78Inbound Queue 126, 131Inbound-Szenario 133infrastrukturelle Sicherheit 40INSERT 33Insert() 316Instanz 24

Integrationclientseitige 512serverseitige 512

Integrität 40, 42Interface � Schnittstelle 393Intermediate Document � IDoc 361Internet Connection Framework 104,

488, 493Internet Connection Framework � ICFInternet Connection Manager 26, 104Internet Information Server 513IRfcAbapObject 318IRfcDataContainer 310, 312, 315IRfcField 313IRfcFunction 300, 310IRfcParameter 311IRfcStructure 312IRfcTable 314IServerSecurityHandler 349ISessionProvider 323, 353ISO-Standard, X.500 45Iterator 239ITransactionIDHandler 353IUnitIDHandler 357IUser 46IUserMaint 46

J

J2EE 34Config-Tool 45Engine 430KeyStore-Service 48

JAAS 61Java 391Java 2 Enterprise Edition � J2EEJava API for XML Web Services 469Java Architecture for XML

Binding 2.0 469Java Authentication and Authorization

Service 61Java Connector � SAP Java ConnectorJava Cryptographic Architecture 47Java Cryptographic Extension 47Java Development Kit 469Java Enterprise Edition 34, 36Java Key Store 60Java Message Service 35Java Native Interface 57, 225

540

Index

Java Server Face 445Java Server Pages 37, 81, 254Java-Bibliothek 249Java-Client 260Java-Connector 253Java-Proxy 441

deployable 445, 463standalone 442, 460

JavaScript 486, 516JavaScript Object Notation � JSONJava-Skeleton 457Java-SOAP-Programmierung 468Java-Stack 19, 34, 37JAXB 2.0 469JAX-WS 469JCE 47JCo-Destination 254JEE 34, 36JEE5 469JEE-KeyStore-Service 48JKS 60JMS 35JNI 57, 225JSON 105, 481, 485, 514JSON-Notationselemente 486JSP 37, 81

K

KeyStore 47, 58KeyStore-Datei, verify.der 48KeyStore-Inhalt

JKS 47PKCS12 47

keytool 47, 58Klasse

generische 254JCo 243

Kommandofeld 22Kommunikation

asynchrone 35Fassade 247Fehler 112

KryptografiePrivate Key 40Provider 47, 58Public Key 40

Kundenauftrag 70

L

Lastverteilung 20, 28, 85, 90, 133, 247

Laufzeitabhängigkeit 267LDAP 44Lebenszyklus 35Lieferantenbestellung 70Link 484Logical Unit of Work 117, 120, 128

DB-LUW 32SAP-LUW 32

Login-Modul 62logischer Port 416, 427, 444logisches System 99, 102, 376, 388,

399, 402Logon

Gruppe 28Ticket 52, 60

LUW � Logical Unit of Work

M

Management 278Mandant 20Massendaten 79, 143Massenverbuchung 79MDB 35Memory Analyzer 39Menüleiste 21MESSAGE 112Message-Driven Bean 35Message-Oriented Middleware 35Message-Server 20, 28, 85Metadaten 244, 270, 392

Container-Metadaten 309Destination 255Dokument 493Element-Metadaten 309

Microsoft Intermediate Language 296Microsoft Visual Studio 293

2005 2932010 293, 472, 522Konsolenanwendung 170vorkompilierter Header 170

Middleware, Schnittstelle 226Model 513Model View Controller 513Modelldaten-Destination 255

541

Index

Model-Provider-Klasse 487, 493Modulpool 81Modus, externer 22, 24MOM 35

N

Nachricht 35Klasse 146Nummer 146Typ 101, 366, 382, 411, 422XML 405

Namenskollision 415Navigation Property 484Navigationspfad 491, 500Nummernkreis

Intervall 76Objekt 75

NWA 48, 466NWDS � SAP NetWeaver Developer

Studio

O

Object Navigator 75, 406, 489Objekttyp 138OData 105, 477, 478, 480, 514

Datenmodell beschreiben 489Modell 518Query 484Service 484Servicekatalog 489, 517

ODataModel 517OData-Query

$filter 485$format 484$inlinecount 485$orderby 485$select 485$skip 484$top 484

OData-Service 477, 487, 493ABAP 487Fehlersuche 509Generierung 492Komponenten 487Modell, technisches 488, 493Service, technischer 488, 493

öffentlicher Schlüssel 41

onCreate 518One-Way-Binding 514onInit 517Open Data Protocol � ODataOpen SQL 37Operation 408

asynchrone 422synchrone 422

Outbound Queue 126, 131Outbound-Szenario 133

P

Package Explorer 282PAI 31Paket 70, 247Paket, Verwendungserklärung 415Parameter

Changing 77einfacher 310Export 77, 237, 250, 252, 286Import 77, 233, 250, 252, 286, 287skalarer 110strukturierter 110Übergabe 89

Partnervereinbarung 376, 377, 378, 389, 391, 402

Passwort 21PBO 31Performance 36Persistenz 35Personal Security Environment � PSEPhoenix 512PKI 44Pluggable Authentication Model 61Port

Default 417logischer 416, 427, 444Nummer 25

PortalRuntime 285POST 482, 503, 504Präsentationsschicht 18Primärschlüssel 483Principal API 45Private-Key-Kryptografie 40privater Schlüssel 41Process After Input 31Process Before Output 31Profil 75

542

Index

Profilparameter 54Programm

ID 88, 275ZSSF_TEST_PSE 68

ProtokollHandler 432Implementierung 432

Provider 425Proxy 233, 393, 433

deployable 460Klasse 246, 251, 287, 415, 443, 469

Prüffeld 71Prüftabelle 71PSE 50, 63

Datei 60individuelles 64zentrales 63

Public-Key-Infrastruktur 44Public-Key-Kryptografie 40Pufferbereich 28Purchase Order 70PUT 482, 507, 508

Q

QIN-Scheduler 132, 204, 338QOUT-Scheduler 128qRFC, SAP .NET Connector 338, 356qRFC-Monitor

für Ausgangswarteschlange 128für Eingangswarteschlange 131

Queue 242Queued RFC 92, 125Queue-Name 338

R

Read 482RecordFactory 287References-Projekt 434Registrierung 208Remote Function Call � RFCremove 522Report 81Repository 243Repository, serverseitiges 269Repository-Management, SAP .NET

Connector 349

Representational State Transfer � REST

Resource-Adapter 278Ressource

Nutzung 26Verbrauch 31

REST 105, 481Adressierbarkeit 481Hypermedia 482Operation 482Repräsentation 482Zustandslosigkeit 482

Return-Parameter 140RFC 26, 84, 107, 277, 489

asynchroner 90, 132Background 93, 133Berechtigung 93Bibliothek 169Client 227Datentyp 234Destination 85, 110, 181Funktionsbaustein 107Gateway 345mit C 167mit C++ 167, 174mit Java 223queued 92, 125, 241registrierter Server 88, 204, 275RfcSendData 210Server 204, 269, 341Serverkonfiguration 345Struktur-Handle 185synchroner 89, 107, 118, 232, 342Tracing 94transaktionaler 91, 119, 122, 192,

240zum Ändern 113zum Anlegen 120zum Löschen 113

RfcBackgroundUnit 338RfcConfigrationParameters 301RfcContainerMetadata 309RfcDestinationManager 301RfcElementMetadata 309RfcFunctionImpl 348RfcServer 345, 358RfcServerFunction 348RfcSessionManager 353RfcTID 323

543

Index

RfcTransaction 324RfcUnitID 338rollback 277ROLLBACK WORK 32, 33, 79, 119Rollbereich 28Route 30Router 182Router-String 30, 248RSS-Feed 481

S

Sales Order 70Sammelsuchhilfe 72SAP .NET Connector 293

Ausnahmebehandlung 316Bibliothek 341IDoc-Programmierung 400IDoc-Sender 402

SAP CRM 18SAP Crypto Toolkit 57SAP Cryptolib 63, 64SAP Enterprise Connector 246, 253SAP ERP 18SAP GUI 19, 20, 25, 28SAP Implementation Guide 101, 488SAP Java Connector 223, 392

Architektur 225, 278Factory-Klasse 231Installation 224JCo.Client 251JCoConnectionData 232JCoContext 230JCoCustomRepository 269JCoDestination 228, 233JCoDestinationManager 228JCoDestinationMonitor 231JCoFieldIterator 239JCoFunction 233, 274JCoFunctionTemplate 244, 270JCoIDocHandlerFactory 397, 398JCoIDocServer 397JCoIDocServerContext 398JCoListMetaData 244, 270JCoMetaData 244JCoParameterList 234JCoRecord 234JCoRepository 233JCoServer 272

SAP Java Connector (Forts.)JCoServerContext 274JCoServerFactory 272, 273JCoServerFunctionHandle 274JCoServerTIDHandler 277, 398JCoTable 235Server 269Session-Management 229Version 224

SAP NetWeaver Administrator 48, 466

SAP NetWeaver Application Server 17, 257, 432ABAP 20, 68Java 34

SAP NetWeaver Composition Environ-ment 36, 254, 420, 447, 469

SAP NetWeaver Developer Studio 17, 224, 246, 281, 430, 513

SAP NetWeaver Gateway 106, 477Central Hub Deployment 478, 479Core-Komponente 478Developer Tool for Visual Studio 522Embedded Deployment 478Fehlerprotokoll 510Testversion 487

SAP NetWeaver Portal 45, 51, 278, 279Applikation 283Connector Framework 278Komponente 282, 284Projekt 282System 280

SAP NetWeaver Process Integration 420

SAP NetWeaver Process Integration, Services Registry 427

SAP NetWeaver RFC SDK 167Beispielprogramme 168Bibliotheksverzeichnis 172bin-Verzeichnis 168Client 175Compiler 169, 171demo-Verzeichnis 168einfacher Parameter 182Exportparameter 184Fehlerbehandlung 176GetRowCount 186Header-Dateien 169

544

Index

SAP NetWeaver RFC SDK (Forts.)IDoc-Programmierung 387IDoc-Sender 389Importparameter 184include-Verzeichnis 169, 171komplexer Client 189Konfigurationseigenschaft 171lib-Verzeichnis 169Linker 169, 171MoveToPreviousRow 186Präprozessordefinition 172qRFC 203Queue-Name 204Repository 208RFC_CONNECTION_HANDLE 179RFC_CONNECTON_PARAMETER

179RFC_ERROR_INFO 179RFC_FUNCTION_HANDLE 179RFC_FUNCTIONDESC_HANDLE

179RFC_ON_CHECK_TID 213RFC_ON_COMMIT 213RFC_ON_CONFIRM_TID 214RFC_ON_ROLLBACK 214RFC_STRUCTURE_HANDLE 185RfcAddNewRow 186RfcAppendNewLine 188RfcAppendNewRow 187RFC-Bibliothek 169RfcCloseConnection 175, 178, 180RfcConfirmTransaction 192, 202RfcCreateFunction 175RfcCreateTransaction 192, 201RfcDeleteAlRows 186RfcDeleteCurrentRow 186RfcDestroyTable 186RfcGetChars 185RfcGetCurrentRow 186, 187, 188RfcGetFunction 180RfcGetFunctionDesc 175, 180RfcGetRowCount 187, 188RfcGetString 184RfcGetStringLength 184RfcGetStructure 185RfcGetTable 186, 188RfcGetTransactionID 192, 201RfcInsertNewRow 186RfcInstallServerFunction 204, 208

SAP NetWeaver RFC SDK (Forts.)RfcInstallTransactionHandlers

213, 215RfcInvoke 175, 180RfcInvokeInTransaction 192, 202RfcListenAndDispatch 204RfcListenDispatch 208RfcMmoveToLastRow 186RfcMoveTo 186RfcMoveToFirstRow 186RfcMoveToNextRow 186, 189RfcOnCheckTransaction 216, 218RfcOnCommitTransaction 216RfcOnConfirmTransaction 217RfcOnRollbackTransaction 217RfcOpenConnection 175, 179RfcRegisterServer 204, 208RfcSetChars 184, 188RfcSubmitTransaction 192, 202Server 204, 205Serverfunktion 209strukturierter Parameter 184Tabellenparameter 186TID-Datei 192TID-Management 193Transaktionshandle 192tRFC-Client 192, 198tRFC-Server 213Verbindungsparameter 180

SAP PLM 18SAP SCM 18SAP SRM 18SAP UI Development Toolkit for

HTML5 � SAPUI5SAP Virtual Machine 38sap.ui.table 518sapgenpse 50, 64SAP-IDoc-Bibliothek 391SAP-Instanz 86SAP-Logon-Ticket 48, 57, 255SAP-Menü 23saprfc.h 176saprfc.ini 180, 181SAP-Router 29, 182SAP-Router-String 248SAPSSOEXT 57SAP-System 24SAPUI5 81, 106, 477, 511, 512

Bibliothek 512

545

Index

SAPUI5 (Forts.)Modell 514

Save 529Scalar Type 483Scheduler

QIN 132, 204, 338QOUT 128

SchlüsselFeld 71kryptografischer 41Management 43öffentlicher 41privater 41

Schnittstelle 17, 393Middleware 226Pattern 422Technologie 81Vereinbarung 36virtuelle 431, 438

Schreibsperre 74, 117SECUDIR 65Secure Network Communication 62Secure Sockets Layer 41SEGW 489SEI 433Selektion 158Selektionsmethode 73Self-Registration 46Separation of Concerns 34, 36Server Manager 345ServerDataProvider 272Server-Proxy 425serverseitiges Repository 269Service Browser 523Service Endpoint Interface 433Service Provider Interface 35Service Registry 455service_SendingRequest 528service_WritingEntity 528Servicedokument 484Service-Explorer 494Service-Interface 422Servicemetadaten 495Service-Metadaten-Dokument 484Services-Datei 25Servlet 37, 81, 260Session Bean 430

stateful 35stateless 35, 436

Session-Cookie 503, 527Session-Management, SAP .NET

Connector 351set-cookie 504SetModel 519setTIDHandler 277SetValue() 310Sicherheit 39

Daten 40hybrides Verfahren 41infrastrukturelle 40Integration 56Management 278Management, SAP .NET Connector

349System 40Transportschicht 62Zugriff 40

Signatur 42Single Point of Access 52Single Sign-on 51Single Stack 18SLD 280, 420SNC 62SNC, PSE-Container 67SOAP 104, 405

Action 412Body 413Envelope 413Header 413

SoftwareKomponente 420Produkt 420

Solution 473Sperre 32, 117

Baustein 74Liste 43Objekt 74Verwaltungs-Workprozess 27

SPI 35Spool-Workprozess 27SPRO 488sRFC 251SSL 41, 62SSO 51stateful 35, 230, 423Stateful Session Bean 35stateless 35, 422, 423Stateless Session Bean 35, 450

546

Index

Statusleiste 23STFC_CONNECTION 352strong-Reference 268Strukturparameter 110, 237Strut 445Suchhilfe 72symmetrisches Verfahren 41synchroner RFC 89, 107System

externes 86Funktionsleiste 22ID 24logisches 99, 102, 376, 388,

399, 402Meldung 23Nummer 24, 86PSE 54Sicherheit 40

System Landscape Directory 280, 420System Landscape, Portal 279, 280system_failure 112Systemfehler 112

T

TabelleBAPIF4T 161interne 187Parameter 78, 235, 237, 250Pflege 72T100 142, 149TBDE 384transparente 70TWPSSO2ACL 53

Table-Control 517TCP 25template 518Tentative-Update-Operation 423Ticketaussteller 51TID � Transaktions-IDTidStore 329, 336Titelleiste 22Tomcat-Webserver 513Transaction Control Protocol 25Transaktion 22, 23

BAPI 97, 148BD51 373BD64 388BD87 381

Transaktion (Forts.)BDBG 382Management 278Modell 189RZ10 54, 65SA16 72SALE 99, 101, 375, 388, 399SBGRFCMON 136SE11 70, 72SE16 72SE37 76, 89SE80 70, 425, 457SICF 104, 510SM30 53, 162SM35 83SM58 119SM59 85, 102, 110, 208, 222, 275,

376, 377, 400SMGW 94, 209SMICM 104SMQ1 129SMQ2 131, 242SMQR 132SMQS 129SNRO 75SOAMANAGER 105, 408, 409, 416,

417, 425, 427, 457SPRO 101SPROXY 425SSO2 54ST05 94ST22 94STRUSTSSO2 49, 52, 54, 67SU01 75SU02 75SU03 75SU21 75SWO 95SWO1 95, 137, 147WE20 379, 380, 400WE30 101, 364WE31 101, 362WE42 374, 380WE57 373WE81 100, 366WE82 101, 366WSADMIN 442WSPUBLISH 427

transaktionaler RFC 91, 119, 122

547

Index

Transaktions-ID 91, 119, 192, 216, 240, 323, 354, 394Datei 217Handler 277Management 241, 276, 336, 398Speicher 354

Transaktionsnummer � Transaktions-ID 394

Transport-Binding 433Transportobjekt 432Trennung von Belangen 34, 36tRFC 213, 353

Client 324, 387Server 387, 400

TRFC_QIN_RESTART 338TRFC_SET_QIN_PROPERTIES 130TU&C/C 423Two-Way-Binding 514

U

UME 44UME, Persistence Manager 45Umgebungsvariable 65Umgebungsvariable, RFC_INI 181Unified Resource Identifier 481Unix-Daemon 88UPDATE 33, 522Update 482UPDATE_ENTITY 507, 508UpdateObject 528URI 481URL-Mapping 261User Data Store 46User Management Engine 44User-Mapping 55

V

Verarbeitungsreihenfolge 92Verbindlichkeit 40, 42Verbindung 286

Aufbau 251direkte 230gepoolte 230Management 278Parameter 248Pool 306Test 209

Verbuchung 141Baustein 78, 116Tabelle 33Workprozess 27, 33

Verschlüsselung 39, 40Verteilungsmodell � ALE-Verteilungs-

modellVertrauensbeziehung 58Vertrauensstellung 44Vertraulichkeit 40View 513, 516virtuelle Maschine 37, 38virtuelles Interface 431, 438Visual Studio � Microsoft Visual

StudioVorgangscode 380

W

weak-Reference 268Web Dynpro 254, 512

ABAP 81, 512Java 37, 81, 254, 446, 512

Web Feed 481Web Service Description Language

� WSDLWeb Services Navigator 440, 455Webbrowser 19Webcontainer 37Web-Modul-Projekt 445Webservice 105, 406

adaptiver 442, 446Administration 409Authentifizierung 466Binding 431Client-Programm 418Consumer 406Datentyp 437Definition 406, 431, 439deployable Proxy 463Endpunkt 406, 409, 410Inside-Out-Ansatz 105, 405, 456Interface 430Konfiguration 431Laufzeit 432mit C# 472mit J2EE 434, 438mit Java 430, 433, 441, 470Navigator 105

548

Index

Webservice (Forts.)Operation 407, 455Outside-In-Ansatz 105, 420, 425,

456Porttyp 466Profil 407Provider 406Schnittstelle 408Standalone-Proxy 463Wizard 406

Wertübergabe 110WFetch 504Windows Management

Instrumentation (WMI) 295Windows-Service 88Workprozess 26, 27WSD 431, 439WSDL 105, 410, 442, 473

Binding 433Datei 410Document-Stil 412RPC-Stil 412

wsgen 469wsimport 469

X

X.500 45x-csrf-token 503, 504XML 396, 514

Nachricht 405Schema Definition Language 411Verarbeitung, IDoc 396

XSLT 396

Z

Zertifikat 43, 63, 67, 432Export 53Import 54X.509 432

Zugriffssicherheit 40Zuständigkeit 36zustandsbehaftet � stateful 35zustandslos � stateless 35

Wir hoffen sehr, dass Ihnen diese Leseprobe gefallen hat. Gerne dürfen Sie diese Leseprobe empfehlen und weitergeben, allerdings nur vollständig mit allen Seiten. Die vorliegende Leseprobe ist in all ihren Teilen urheberrechtlich geschützt. Alle Nutzungs- und Verwertungsrechte liegen beim Autor und beim Verlag.

Teilen Sie Ihre Leseerfahrung mit uns!

Dr.MichaelWegelin ist geschäftsführender Gesellschafter der 10 point software GmbH und für den Bereich ABAP und SAP NetWeaver Process Integration verantwortlich.

Michael Wegelin, Michael Englbrecht

SAP-Schnittstellenprogrammierung548 Seiten, gebunden, 3. Auflage 2014 69,90 €, ISBN 978-3-8362-2675-2

www.sap-press.de/3496

Dipl.-Inf.(FH)MichaelEnglbrecht ist Director NetWeaver Consulting bei der 10 point software GmbH und für den Be-reich Enterprise Java, SAP NetWeaver J2EE/JEE und SAPUI5 verantwortlich.

Wissen aus erster Hand.

http://www.sap-press.de/3496?GPP=lpn

https://www.facebook.com/GalileoPressVerlag

https://plus.google.com/118435207805510651040

http://twitter.com/Galileo_Press

Leseprobe - Store & Retrieve Data Anywhere · Wenn Sie Ihre IDoc-Segmente später in einem...

Documents

Transcript of Leseprobe - Store & Retrieve Data Anywhere · Wenn Sie Ihre IDoc-Segmente später in einem...