Entwicklung eines flexiblen IDoc-Monitors

Transkript

1 F Entwicklung eines flexiblen IDoc-Monitors Development of a flexible IDoc-Monitor Michael Lensch Bachelor Abschlussarbeit Betreuer: Prof. Dr. rer. nat. Andreas Lux Lutz Baumbusch, ORGA GmbH Altenglan,

2 Vorwort Diese Abschlussarbeit wurde im Auftrag der ORGA GmbH in Karlsruhe erstellt. Die ORGA ist eine 100% Tochtergesellschaft der FIDUCIA IT AG, einem der größten IT-Dienstleister im deutschen Bankensektor, und kann aufgrund dessen auf eine extrem leistungsfähige und sichere IT-Infrastruktur zurückgreifen. Die ORGA ist ein Spezialist für IT-Service und Beratung. In den Bereichen SAP- Lösungen, Dokumenten-Service, Personal-Service und IT-Service bietet die OR- GA Leistungen für Industrie, Handel, Verlage und Dienstleistungsunternehmen an. Ziel dieser Leistungen ist es durch Optimierung der Kundenprozesse die Wettbewerbsfähigkeit der Kunden zu steigern. Als SAP Channel Partner Gold und SAP Hosting Partner bietet die ORGA außerdem ein umfassendes Leistungsspektrum von der Beratung über Lizenzen bis hin zum Kundensupport.[Org08]

3 Kurzfassung Im Rahmen dieser Abschlussarbeit wurde für die ORGA GmbH in Karlsruhe ein flexibler IDoc-Monitor entwickelt. Die Dokumentation beschreibt wie der Monitor von Grundauf entwickelt wurde. Zu Beginn wird alles was zum grundlegenden Verständnis der Arbeit nötig ist erläutert. So werden einige Informationen zu der eingesetzten Programmiersprache ABAP gegeben. Zum Abrunden der Grundlagen wird u.a. noch der ABAP List Viewer (ALV) beschrieben. ALV wird bei der Entwicklung des IDoc-Monitors zur Listen-Darstellung eingesetzt. Im Anschluss wird die Entwicklung eines ersten IDoc-Monitors beschrieben. Dieser Monitor ist auf einen speziellen IDoc-Typ ausgelegt. Danach wurde eine weiterer IDoc-Monitor programmiert. Der zweite Monitor ist für einen anderen IDoc-Typ entwickelt worden und wird nur kurz angesprochen. Basierend auf den Erfahrungen, die bei den ersten beiden Monitoren gesammelt wurden, wurde ein Konzept für einen flexiblen IDoc-Monitor aufgestellt und beschrieben. Zum Abschluss wird die Entwicklung des flexiblen IDoc-Monitors beschrieben und erläutert. Within this Bachelor Thesis a dynamic IDoc-Monitor was developed by order of ORGA GmbH in Karlsruhe. The documentation describes how to develop the IDoc-Monitor. At the beginning there will be described everything that is needed for the basic understanding of this thesis. It is described what an IDoc is and how it is used. After this are the requirements for an IDoc-Monitor described. Below this there will be given some information about the used programming language ABAP. To complete the basics the ABAP List Viewer (ALV) is described. ALV is used for the development of the IDoc-Monitor to display lists. After this, the development of a first IDoc-Monitor ist described. This Monitor is developed to handle a special IDoc-Type. Next a second IDoc-Monitor ist programmed. The second IDoc-Monitor is developed for an other IDoc-Type and is described less detailed as the first Monitor. Based on the experiences of the two IDoc-Monitors there is maken and described a concept for a flexible IDoc-Monitor. Finally the development of the flexible IDoc-Monitor is described.

4 Inhaltsverzeichnis 1 Einleitung Aufgabenstellung und Zielsetzung Grundlagen IDoc IDoc-Basistyp Master-IDoc Kommunikations-IDoc Kontrollsatz Datensatz Statussatz Beispiel für IDoc Struktur IDoc-Monitor ABAP Aufbau von ABAP-Programmen Deklarationen Klassendefinitionen Unterprogramme Ereignisse zur Laufzeitumgebung PBO-Modul PAI-Modul ABAP List Viewer Idee Verwendung Praktische Umsetzung SimpleTreeModel Idee Verwendung Praktische Umsetzung Überblick über das Geschäftsfeld Agenturgeschäft

5 Inhaltsverzeichnis V 4 Entwicklung spezialisierter IDoc-Monitore Erster IDoc-Monitor Selektionsbild Übersichtsbild Detailbild Programmdokumentation Zweiter IDoc-Monitor Selektionsbild Übersichtsbild Detailbild Fazit Konzept des flexiblen IDoc-Monitors Konzept Entwicklung des flexiblen IDoc-Monitors Customizing Tabellen Customizing Tabelle für das Selektionsbild Customizing Tabelle für die änderbaren Felder Customizing Tabelle für die Funktionen Customizing Tabelle für den Status Selektionsbild Übersichts- und Detailbild Mögliche Funktionen Anwendungsbeispiele Pflege der Customizing Tabellen IDoc zu Materialstammdaten IDoc zu Hauptbuchdaten Schluss Literatur Index

6 Abbildungsverzeichnis 3.1 Beispiel für einen IDoc Kontrollsatz[Ido] Beispiel für einen IDoc Datensatz[Ido] Beispiel für IDoc Statussatz[Ido] Beispiel für IDoc Struktur[Ido] Zeitlicher Ablauf der Ereignisse eines ABAP-Reports[Ere08b] Das ALV-Grid-Control wird in das Custom-Container-Control gelegt ALV als Einzel- und als Teilelement Zentralregulierung[Age] Selektionsbild - erster IDoc-Monitor Übersichtsbild - erster IDoc-Monitor Drucktastenleiste des ersten IDoc-Monitors Detailbild - erster IDoc-Monitor Programmdokumentation - erster IDoc-Monitor Selektionsbild - Stammdaten (zweiter IDoc-Monitor) Übersichtsbild - zweiter IDoc-Monitor Funktion Massenänderung - zweiter IDoc-Monitor Detailbild - zweiter IDoc-Monitor Anzeige der Transaktion WE Struktur der Customizing Tabelle für das Selektionsbild Struktur der Customizing Tabelle für die änderbaren Felder Struktur der Customizing Tabelle für die Funktionen Struktur der Customizing Tabelle für die Ampelanzeige Selektionsbild des flexiblen IDoc-Monitors (Teil1) Selektionsbild des flexiblen IDoc-Monitors (Teil2) Übersichtsbild des flexiblen IDoc-Monitors Event-Handler-Klasse Pflege der Customizing Tabelle zum Selektionsbild Pflege der Customizing Tabelle zu den Funktionen Pflege der Customizing Tabelle zu den änderbaren Feldern Pflege der Customizing Tabelle zum Status Selektionsbild - Materialstammdaten (Teil 1)

7 Abbildungsverzeichnis VII 7.6 Selektionsbild - Materialstammdaten (Teil 2) Übersichtsbild - Materialstammdaten Anzeige der Materialdaten (Transaktion MM03) Selektionsbild - Hauptbuchdaten (Teil 1) Selektionsbild - Hauptbuchdaten (Teil 2) Übersichtsbild - Hauptbuchdaten Anzeige der Belegdaten (Transaktion FB03)

8 1 Einleitung Ziel dieser Abschlussarbeit war die Entwicklung eines IDoc-Monitors für das Karlsruher IT-Unternehmen ORGA GmbH. Besondere Schwierigkeit war, dass der Monitor auf verschiedene IDoc-Typen anwendbar sein sollte. Zu Beginn dieser Dokumentation wird beschrieben was ein IDoc überhaupt ist und wozu IDocs verwendet werden. Im Anschluss wird erläutert was die Anforderngen an einen IDoc-Monitor sind. Im Folgenden wird die Entwicklung zweier auf je einen IDoc-Typ ausgelegten IDoc-Monitore erläutert. Die ersten beiden IDoc-Monitore wurden im Rahmen zweier SAP-Projekte (unter dme Agency Business Model = Agenturgeschäft) entwickelt und dienten als Basis für den flexiblen IDoc-Monitor. Das Konzept und die spätere Umsetzung des flexiblen IDoc-Monitors wird anschließend beschrieben und erläutert.

9 2 Aufgabenstellung und Zielsetzung Bei dieser Abschlussarbeit soll ein universell einsetzbarer IDoc-Monitor entwickelt werden. Die Entwicklung erfolgt in der Programmmiersprache ABAP. Da die IDocs in den Übersicht immer mit Hilfe von ALV-Listen und Baumstrukturen dargestellt werden sollen sind ALV-Listen und das SimpleTree-Model wichtige Hilfsmittel bei der Entwicklung des IDoc-Monitors. Ziel dieser Software ist, die Enwicklung eines IDoc-Monitors, der auf verschiedene Arten von IDoc-Typen anwendbar ist. Das Problem dabei ist es zwischen den unterschiedlichen IDoc-Typen zu unterscheiden, da die IDoc-Typen sich im Aufbau ihrer Anwendungsdaten unterscheiden. Somit muss ein Weg gefunden werden die Unterschiede zwischen den verschiedenen IDocs herauszufinden und in der Software entsprechend zu behandeln. Dementsprechend ergeben sich auch unterschiedliche Funktionen, die auf die verschiedenen IDoc-Typen anwendbar sind (z.b. Absprung Material oder Absprung Belegdaten).

10 3 Grundlagen Dieses Kapitel erläutert die Grundlagen, die nötig waren um diese Abschlussarbeit umsetzen zu können. Zu Beginn wird erläutert, was IDocs sind. Danach wird die Funktionsweise eines IDoc-Monitors beschrieben und anschließend die Programmiersprache ABAP vorgestellt. Zum Abschluss wird wird das Konzept der ABAP List Viewer (ALV), des SimpleTreeModel und das Agenturgeschäft erklärt. 3.1 IDoc Ein IDoc (Intermediate Document) ist eine Schnittstelle, welche verwendet wird um Daten zwischen SAP R/3, R/2 und Non-SAP-Systemen auszutauschen. IDocs werden also zur Kommunikation zwischen verschiedenen ERP-Systemen eingesetzt. Der IDoc-Typ legt die Struktur eines IDocs fest.[ido08b, BITQ4] Wichtig: Ein IDoc kann nur Characterfelder enthalten! IDoc-Basistyp Der IDoc-Basistyp oder IDoc-Typ legt die Struktur des IDocs, also den Inhalt und damit welche Daten übertragen werden sollen, fest. Jeder IDoc-Basistyp ist mit einem Nachrichtentyp verknüpft. Durch den Nachrichtentyp wird definiert welche Art von Daten verteilt wird. Einem Nachrichtentyp wird der jeweils passende IDoc-Basistyp zugeordnet. Zu einem Nachrichtentyp können verschiedene IDoc- Basistypen existieren, da ein IDoc-Basistyp zu jedem SAP Release kompatibel erweitert werden kann. Durch den IDoc-Basistyp wird festgelegt wie die Daten, welche verteilt werden sollen, aufbereitet werden. Es wird festgelegt in welcher Reihenfolge welche Anwendungsdaten zu einer Nachricht gehören. Die IDoc-Daten werden zeilenweise angeordnet. Die Zeilen bilden dann die Segmente eines IDocs. Die Segmente lassen sich nochmals in Segmentfelder aufteilen. Durch den Segmenttyp wird die Zeilenstruktur bestimmt. Jedes Segmentfeld enthält den Feldnamen, die technischen Eigenschaften und die Semantik. Die verschiedenen IDoc-Segemnete können hierarchisch voneinander abhängig sein.

11 3.1 IDoc 4 Ein IDoc muss nicht alle Segmente eines Segmenttyps enthalten, aber es können auch mehrere Segmente zu einem Segmenttyp in einem IDoc enthalten sein. Im Segmenttyp wird über die Attribute festgelegt, wie viele Segemente zu einem Segmenttyp mindestens enthalten sein müssen und maximal enthalten sein dürfen. Außerdem wird festgelegt in welcher Hierachie die Daten zueinander stehen (z.b. Eltern- und Kindsegmente).[Ido08a, Ido08b, BITQ4] Master-IDoc Ein Master-IDoc ist eine interne Tabelle, die auf dem IDoc-Basistyp basiert. Passend zur Segmentstruktur des IDoc-Basistyps werden die Anwendungsdaten zeilenweise in die interne Tabelle eingefügt. Eine interne Tabelle existiert nur zur Laufzeit, d.h. die Tabelle wird nicht in die Datenbank geschrieben. Master-IDocs werden von den Anwendungsprogrammen, die in ALE-Szenarien genutzt werden, automatisch erzeugt. In jeder Zeile des Master-IDocs gibt es einen Kontroll- und einen Datenteil. Der Kontrollteil enthält Metadaten wie die IDoc-Nummer, die Segementnummer, den Namen des Segmenttyps und die Hierarchieebene. Durch den Namen des Segmenttyps wird die Struktur des Datenteils bestimmt. Der Zeilentyp des Master-IDocs wird durch den ABAP-Dictionary-Strukturtyp EDIDD festgelegt.[ido08a, Ido08b, Mas, BITQ4] Kommunikations-IDoc Auf Grundlage des Master-IDocs erzeugt das System ein Kommunikations-IDoc. Das Kommunikations-IDoc wird oft auch einfach nur als IDoc bezeichnet. Im weiteren Verlauf dieser Dokumentation wird mit IDoc immer ein Kommunikations- IDoc gemeint sein. Ein Kommunikations-IDoc besteht aus 3 Teilen, einem Kontrollsatz, mehreren Datensätzen und mehreren Statussätzen.[Ido08a, Ido08b, BITQ4] Kontrollsatz Abbildung 3.1. Beispiel für einen IDoc Kontrollsatz[Ido] Der Kontrollsatz beinhaltet Informationen über den Inhalt, die Struktur, den Sender, den Empfänger und den aktuellen Status des IDocs.[Ido08a, Ido08b, BITQ4]

12 3.1 IDoc Datensatz Abbildung 3.2. Beispiel für einen IDoc Datensatz[Ido] Die Datensätze bestehen aus einem Header (Infoteil und Datenteil), der aus einer fortlaufenden Segmentnummer und einer Beschreibung des Segementyps besteht. Außerdem enthalten die Datensegmente eine 1000-Zeichen-lange Feldleiste. In der Feldleiste sind die Daten des Segments enthalten. Die Datensätze entsprechen den Zeilen des Master-IDocs[Ido08a, Ido08b, BITQ4] Statussatz Abbildung 3.3. Beispiel für IDoc Statussatz[Ido] In den Statussätzen werden die durchgeführten Verarbeitungsschritte des Segments beschrieben und gesichert.[ido08a, Ido08b, BITQ4] Beispiel für IDoc Struktur Abbildung 3.4 zeigt eine IDoc-Struktur. In diesem Beispiel muß dass Kopfsegment (Header) das erste Segement der Nachricht sein. Die Positionssegmente (Item) sind dem Kopfsegment untergeordnet. Zu jedem Kopfsegment gibt es mindestens eine Position, aber maximal Dem Positionsegment sind Unterpositionen (Subitem) untergeordnet. Zu den Positionssegmenten gehören 1 bis 99 Unterpositionen. Zusätzlich zu den Unterpositionen können den Positionssegmenten bis zu 9999 Textsegmente (Text) folgen. Es muss aber kein Textsegment folgen. Als letztes Element ist in diesem Beispiel das Akkumulationssegment (ACCUM) festgelegt. Dieses Segment kommt genau wie das Kopfsegment genau 1 mal vor.

13 3.2 IDoc-Monitor 6 Abbildung 3.4. Beispiel für IDoc Struktur[Ido] Das Beispiel soll verdeutlichen, wie eine IDoc-Struktur aussehen kann. Natürlich kann die Struktur auch ganz anders aufgebaut sein. So muss es z.b. keine hierachischen Beziehungen zwischen den einzelnen Segmenten geben.[ido08a, Ido08b, BITQ4] 3.2 IDoc-Monitor Ein IDoc-Monitor ist ein Programm, dass dazu dient IDocs im System zu überwachen und fehlerhafte IDocs einfacher bearbeiten zu können. Das Bearbeiten kann bedeuten, dass IDocs nicht nur korrigiert und freigegeben werden sondern auch aus dem System gelöscht werden können. Oft besteht ein IDoc-Monitor aus 3 graphischen Benutzeroberflächen: dem Einstiegsbild, dem Übersichtsbild und dem Detailbild. Das Einstiegsbild dient zu Selektion der Daten. Hier können über ein Formular verschiedene Suchkriterien für die IDocs angegeben werden. Diese Suchkriterien können beispielsweise IDoc-Nummer oder -Status sein. Das Übersichtsbild gibt eine Liste mit IDocs aus. In der Liste sind wesentliche Informationen zu den IDocs enthalten. Hier können die IDocs zur Berarbeitung ausgewählt werden.

14 3.3 ABAP 7 Das Detailbild beinhaltet alle Informationen aus den Segementen die zu dem jeweiligen IDoc gespeichert sind. Je nach IDoc-Monitor sind an dieser Stelle ausgewählte Felder änderbar und andere nicht. 3.3 ABAP ABAP ist eine Programmiersprache des Softwareunternehmens SAP. In ihrer Grundstruktur hat ABAP zahlreiche Gemeinsamkeiten mit der Progrmmiersprache COBOL. ABAP wurde speziell für die Massendatenverarbeitung in kommerziellen Anwendungen im SAP-Umfeld entwickelt. Zu Beginn stand ABAP für Allgemeiner Berichts-Aufbereitungs-Prozessor. Denn am Anfang wurde ABAP lediglich eingesetzt um an Kunden angepasste Auswertungen zu entwickeln, wobei es nicht möglich war Änderungen an der Datenbank vorzunehmen. Nach diversen Weiterentwicklungen der Sprache steht ABAP heute für Advanced Business Application Programming. Da der Sprachumfang von ABAP nicht fest definiert ist, wurde die Sprache in den letzten Jahren immer wieder erweitert. So ist es heute beispielsweise möglich durch die Erweiterung ABAP-Objects objektorientiert mit ABAP zu programmieren.[wika, Inc, BC4Q2a] Um ABAP-Programme zu modularisieren zu wiederverwendbar zu machen, wird der Quellcode in Include-Programme unterteilt. Aber auch ohne diese Unterteilung ist der ABAP-Quellcode lauffähig. Im folgenden werden einige wichtige Includes mit Beispielen erläutert. Im ABAP-Quellcode werden Kommentare durch ein * am Anfang der Zeile gekennzeichnet. 1 *& * 2 *& REPORT: ZMLTEST 3 *& * 4 * D e k l a r a t i o n e n 5 INCLUDE ZMLTEST TOP 6 7 * K l a s s e n d e f i n i t i o n e n 8 INCLUDE ZMLTEST CL * Unterprogramme 11 INCLUDE ZMLTEST F * E r e i g n i s s e zur Laufzeitumgebung 14 INCLUDE ZMLTEST E * PBO Modul 17 INCLUDE ZMLTEST O * PAI Modul 20 INCLUDE ZMLTEST I Aufbau von ABAP-Programmen In ABAP gibt es verscheidene Programmtypen. Für diese Abschlussarbeit war der wichtigste Programmtyp der REPORT. Ein REPORT ist ein ausführbares Programm und kann durch SUBMIT von einenm anderen ABAP-Programm

15 3.3 ABAP 8 gestartet werden. Weiterhin ist es möglich einen REPORT über einen Transaktionscode zu starten. Es kann aber auch REPORTS geben, zu denen kein Transaktionscode angelegt wurde. REPORTS müssen nicht unmittelbar über selbstdefinierte Dynpros gesteuert werden, weil zugehörige Prozessoren der Laufzeitumgebung automatisch und in einer vorgegebenen Reihenfolge die Aufrufe von Verarbeitungsblöcken und gegebenenfalls von Bildschirmen (Selektionsbilder und Listen) übernehmen. Es ist keine Definition von Ereignisblöcken vorgeschrieben, somit kann der Entwickler entscheiden, auf welche Ereignisse der REPORT reagieren soll. Bei REPORTS ist kein Benutzerdialog notwendig. Der Einsatz von REPORTS ist immer dann sinnvoll, wenn der Programmablauf ganz oder teilweise dem vordefinierten Ablauf in der Laufzeitumgebung entspricht. Bei der Ausführung eines Reports wird der Programmablauf durch die externen Ereignisse der ABAP-Laufzeitumgebung gesteuert. Abbildung 3.5 zeigt den zeitlichen Ablauf dieser Ereignisse. Einige dieser Ereignisse werden im Kapitel genauer erläutert und mit Hilfe von Beispielen verdeutlicht. [Ere08b, Ere08a, Pro08] Abbildung 3.5. Zeitlicher Ablauf der Ereignisse eines ABAP-Reports[Ere08b]

16 3.3 ABAP Deklarationen 1 *& * 2 *& I n c l u d e ZMLTEST TOP 3 *& * 4 REPORT z m l t e s t MESSAGE ID z m l t e s t /mess DATA: g t e d i d d TYPE STANDARD TABLE OF edidd, 9 g s e d i d d TYPE edidd, 10 g v t e x t ( 1 ) type c CONSTANTS: 13 g c j a LIKE g v t e x t 14 VALUE J CLASS l c l e v e n t r e c e i v e r DEFINITION DEFERRED DATA r e f e v e n t r e c e i v e r 19 TYPE REF TO l c l e v e n t r e c e i v e r DATA: r e f c u s t o m c o n t a i n e r 22 TYPE REF TO c l g u i c u s t o m c o n t a i n e r, 23 r e f a l v g r i d 24 TYPE REF TO c l g u i a l v g r i d Bei diesem Include handelt es sich um das sogenannte Top-Include. Dieses Include ist, im Gegensatz zu den anderen Includes, bei richtiger Namenskonvention immer in die die Navigation eingebunden und wird bei der Syntaxüberprüfung paralleler Include-Bausteine mitberücksichtigt. Durch den Ausdruck in Zeile 4 wird festgelegt, dass es sich um bei dem Programm um einen Report mit dem Name zmltest handelt. Dieser Report verwendet standardmäßig die Fehlermeldungen aus der Nachrichtenklasse zmltest/- mess. Die Zeilen 8 bis 10 legen drei lokale Variablen fest. Bei gt edidd handelt es sich um eine Tabelle vom ABAP-Dictionary-Strukturtyp EDIDD. Da Tabellen in SAP jedoch standardmäßig keine Kopfzeile haben, ist es nicht möglich direkt auf den Inhalt eines Feldes der Tabelle gt edidd zuzugreifen. Um dieses Problem zu beheben, wird die die Variable gs edidd als Struktur vom Typ EDIDD definiert. Eine Struktur ist eine Zeile einer Tabelle. Auf die Inhalte dieser Zeile kann innerhalb des Programms zugriffen werden. Der gemeinsame Einsatz von gt edidd und gs edidd wird im Unterkapitel genauer beschrieben. Die Variable gv text ist eine Variable von Typ Character mit der Länge 1. In den Zeilen 12 bis 14 wird Konstante definiert. Eine Konstante muss immer direkt bei der Deklaration einen Wert zugewiesen bekommen. In diesem Beispiel wird eine Konstante vom Typ der Variable gv text deklariert und bekommt den Text J zugewiesen. Durch den Ausdruck in Zeile 16 wird eine lokale Klasse mit dem Namen lcl event receiver durch die Anweisung DEFERRED wird die Klasse dem Programm vorläufig bekannt gemacht obwohl die der Klasse noch nicht definiert wur-

17 3.3 ABAP 10 de. Um eine globale Klasse bekannt zu machen müsste nach dem DEFERRED noch PUBLIC folgen. In Zeile 18 wird die Referenzvariable ref event receiver deklariert. Die Variable hat eine Referenz auf ein Objekt der Klasse lcl event receiver. Die Zeilen 21 bis 24 beschreiben wie ein Container- und das zugehörige ALV- Grid-Objekt erzeugt werden. Die beiden Objekte werden im weiteren Verlauf des Programms benötigt um die Listen-Ausgabe der Daten mittels ALV-Grid zu realisieren. Wie genau ein ALV-Grid aufgebaut wird, wird in Kapitel 3.4 näher beschrieben. Das obige Codebeispiel zeigt einige wesentlichen Deklarationsmöglichkeiten die in ABAP möglich sind. Alle Variablen, Konstanten, Referenzen und Klassen, die im Top-Include deklariert werden, sind global im Programm verfügbar. Lokale Variablen, müssen in den jeweiligen Unterprogrammen deklariert werden.[wika, Inc, BC4Q2a] Klassendefinitionen 1 *& * 2 *& I n c l u d e ZMLTEST CL1 3 *& * 4 * D e f i n i t i o n der Event Handler Klasse 5 CLASS l c l e v e n t r e c e i v e r DEFINITION. 6 7 PUBLIC SECTION. 8 METHODS: 9 handle data changed 10 FOR EVENT data changed OF c l g u i a l v g r i d 11 importing er data changed, h a n d l e g r i d d o u b l e c l i c k 14 FOR EVENT d o u b l e c l i c k 15 OF c l g u i a l v g r i d ENDCLASS * Implementierung der Event Handler Klasse 20 CLASS l c l e v e n t r e c e i v e r IMPLEMENTATION METHOD handle data changed. 23 * Hier wird f e s t g e l e g t was im F a l l e e i n e Änderung der Daten p a s s i e r t 24 ENDMETHOD METHOD h a n d l e g r i d d o u b l e c l i c k. 27 * Hier wird f e s t g e l e g t was im F a l l e e i n e s D o p p e l k l i c k s p a s s i e r 28 ENDMETHOD ENDCLASS. Das Codebeispiel zum Include ZMLTEST CL1 zeigt den grundsätzlichen Aufbau einer Event-Handler -Klasse. Die Klasse hat zwei Methoden. Die Methode handle data changed wird im weiteren Verlauf dieses Beispiels benötigt um auf Datenänderungen in einem ALV-Grid zu reagieren. Und die Methode handle grid double click wird eingesetzt um auf einen Doppelklick in einem ALV-Grid reagieren zu können. Grundsätzlich ist es bei der objektorientierten Programmierung in ABAP so, dass zuerst die Klasse mit all seinen Methoden und Attri-

18 3.3 ABAP 11 buten definiert (Zeile 5 bis 17) wird und dann implementiert (Zeile 20 bis 30) wird.[wika, BC4Q2a] Unterprogramme Im Include zu den Unterprogrammen können alle Unterprogramme eines ABAP- Programmes (sog. Forms) abgelegt werden. Im Folgenden wird an kleinen Beispielen kurz gezeigt, wie in einem Unterprogramm Klassen verwendet werden können, wie Unterprogramme aufgerufen werden und wie in einem Unterprogramm eine Datenbankabfrage ausgeführt wird. 1 *& * 2 *& I n c l u d e ZMLTEST F01 3 *& * FORM c r e a t e c o n t r o l s CREATE OBJECT r e f e v e n t r e c e i v e r. 8 SET HANDLER r e f e v e n t r e c e i v e r >handle data changed FOR r e f a l v g r i d. 9 SET HANDLER r e f e v e n t r e c e i v e r >h a n d l e g r i d d o u b l e c l i c k FOR r e f a l v g r i d ENDFORM Das obige Codebeispiel zeigt wie die Methoden der Handler-Klasse, die im Include ZMLTEST CL1 (siehe 3.3.3) definiert wurde auf das ALV-Grid angewendet wird. Dazu muss zuerst der Konstruktor der Klasse lcl event receiver aufgerufen werden um ein Objekt zu erzeugen. In diesem Fall wird, da kein Konstruktor definiert wurde der Standardkonstruktor verwendet. Danach werden die beiden Methoden als Handler beim ALV-Grid-Objekt angemeldet. Sobald eine Datenänderung oder ein Doppelklick vorliegt, wird die entsprechende Methode der Handler-Klasse ausgeführt FORM l e s e d a t e n PERFORM g e t d a t a ENDFORM Durch den Ausdruck PERFORM get_data wird das Unterprogramm get data aufgerufen FORM g e t d a t a SELECT * 5 FROM edidd 6 INTO CORRESPONDING FIELDS OF TABLE g t e d i d d. 7 IF sy subrc <> 0. 8 MESSAGE i WITH Bei der Datenbankabfrage i s t e i n F e h l e r a u f g e t r e t e n. 10 ENDIF ENDFORM Im Unterprogramm get data werden alle Daten der Tabelle EDIDD in die Ta-

19 3.3 ABAP 12 belle gt edidd geladen. Sollte dabei ein Fehler auftreten wird die Systemvariable sy-subrc durch die ABAP-Laufzeitumgebung automatisch ungleich 0 gesetzt. Somit können Fehler beim Select-Aufruf einfach durch eine Abfrage des Inhaltes von sy-subrc behandelt werden.[wika, BC4Q2a] Ereignisse zur Laufzeitumgebung 1 *& * 2 *& I n c l u d e ZMLTEST E01 3 *& * 4 *& * 5 *& Event i n i t i a l i z a t i o n 6 *& * 7 INITIALIZATION. 8 * I n i t i a l i s i e r u n g 9 PERFORM i n i t i a l i z a t i o n *& * 12 *& Event s t a r t of s e l e c t i o n 13 *& * 14 START OF SELECTION. 15 * DB l e s e n 16 PERFORM l e s e d a t e n *& * 19 *& Event end of s e l e c t i o n 20 *& * 21 END OF SELECTION. 22 CALL SCREEN Dieses Include ist für die Behandlung der Ereignisse zur Laufzeitumgebung verantwortlich. Drei Ereignisse werden in dem obigen Codebeispiel gezeigt. So kann das Ereignis INITIALIZATION dazu verwendet werden um das Selektionsbild vorzubelegen. Die eigentliche Vorbelegung findet hier in einem Unterprogramm statt, welches durch den Ausdruck PERFORM initialization aufgerufen wird. Ein weiteres wichtiges Ereignis ist START-OF-SELECTION. Dieses Ereignis tritt nach der Verarbeitung des Standardselektionsbildes und vor dem Lesen von Daten durch die logische Datenbank ein. Im obigen Beispiel werden bei diesem Ereignis die selektierten Daten geladen. Das dritte Ereignis aus diesem Beispiel ist END- OF-SELECTION. Das Ereignis tritt nach dem Lesen von Daten durch die logische Datenbank ein. Im obigen Beispiel wird bei diesem Ereignis das Nachfolgebild aufgerufen.[wika, Sap, Wikc, BC4Q2a, Ere08b, Ere08a]

20 3.3 ABAP PBO-Modul 1 *& * 2 *& I n c l u d e ZMLTEST O01 3 *& * 4 *& * 5 *& Module STATUS 4000 OUTPUT 6 *& * 7 * t e x t 8 * * 9 MODULE s t a t u s OUTPUT SET PF STATUS SET TITLEBAR ENDMODULE. STATUS 4000 OUTPUT 15 *& * 16 *& Module CONTROL PROCESSING OUTPUT 17 *& * 18 * t e x t 19 * * 20 MODULE c o n t r o l p r o c e s s i n g OUTPUT gv docnum = s docnum low IF r e f c u s t o m c o n t a i n e r IS INITIAL. 25 * C o n t r o l s erzeugen und e r s t m a l i g e Anzeige 26 PERFORM c r e a t e c o n t r o l s ELSE. 28 * C o n t r o l s b e a r b e i t e n und Anzeige a k t u a l i s i e r e n 29 PERFORM r e f r e s h c o n t r o l s ENDIF ENDMODULE. CONTROL PROCESSING OUTPUT In das PBO-Modul (Process Before Output) kommen alle Aktionen, die vor dem Ausführen eines Bildes notwendig sind. In diesem Beispiel wird im Modul status_4000 der Status und der Titel des Ausgabebildes festgelegt. Der Titel ist der Text, der in der Titelzeile des Bildes angezeigt wird. Der Status definiert wie die Menüleiste, die Drucktastenleiste und die Funktionstasten belegt sind. Im Modul control_processing_4000 wird die ALV-Liste aufgebaut und die Inhalte werden eingefügt.[wika, Sap, Wikc, BC4Q2a]

21 3.4 ABAP List Viewer PAI-Modul 1 *& * 2 *& I n c l u d e ZMLTEST I01 3 *& * 4 *& * 5 *& Module USER COMMAND 4000 INPUT 6 *& * 7 * t e x t 8 * * 9 MODULE user command 4000 INPUT g v s c o d e = g v f c o d e. 12 CLEAR g v f c o d e CASE g v s c o d e. 15 WHEN SAVE. 16 PERFORM save. 17 WHEN BACK. 18 SET SCREEN 0. LEAVE SCREEN. 19 WHEN DETAIL. 20 PERFORM l i n k d e t a i l s. 21 ENDCASE ENDMODULE. USER COMMAND 4000 INPUT *& * 26 *& Module e x i t INPUT 27 *& * 28 * t e x t 29 * * 30 MODULE e x i t INPUT CASE g v f c o d e. 33 WHEN EXIT. 34 LEAVE PROGRAM. 35 WHEN CANC. 36 SET SCREEN 0. LEAVE SCREEN. 37 ENDCASE ENDMODULE. e x i t INPUT In das PAI-Modul (Process After Input) kommen alle Aktionen, die nach dem Drücken eines Eintrags im Menü oder der Drucktastenleiste des jeweiligen Bildes ausgeführt werden müssen. Die sind in der Regel eine Reaktion auf die Benutzereingabe und eine Reaktion auf klicken des Exit- oder Abbrechen-Buttons. Klickt der Anwender auf einen einfachen Menüeintrag wird in diesem Beispiel das Modul user_command_4000 ausgeführt. Das Exit-Modul behandelt das Klicken einen Abbruch- oder Exit-Buttons. In beiden Modulen wird erst eine Fallunterscheidung gemacht und dann je nachdem welcher Code von dem Button übersand wurde, durch Verlassen des Programms oder Aufruf eines Unterprogramms reagiert.[wika, Sap, Wikc, BC4Q2b] 3.4 ABAP List Viewer Idee Die Grundidee ist die, dass es zu Begeinn eine leere Bildschirmoberfläche gibt. Auf diese Bildschirmoberfläche wird ein Custom-Container-Control gelegt. Dieser

22 3.4 ABAP List Viewer 15 Container dient als Behälter für das eigentliche ALV-Grid-Control, also die ALV- Liste. Die Grafik 3.6 soll diesen Zusammenhang nochmal etwas verdeutlichen.[alv, Wikb, BC4Q2b, Rös05] Abbildung 3.6. Das ALV-Grid-Control wird in das Custom-Container-Control gelegt Verwendung Der ABAP List Viewer vereinheitlicht die Bedienung von Listen in SAP- Systemen. Bestandteil einer ALV-Liste ist eine Toolbar um diverse Aktionen auf die Liste anwenden zu können (z.b. sortieren, drucken). Diese Aktionen müssen von dem Entwickler nicht von Hand implementiert werden, sondern sind bereits Teil des SAP-Systems. Es gibt zwei Möglichkeiten das ALV Grid Control in SAP einzusetzen. Zum einen als Bildschirmelement zusammen mit anderen Bildschirmelementen. Und zum anderen als einziges Bildschirmelement. Wie das ALV-Grid-Control eingesetzt wurde lässt sich an der Toolbar erkennen. Beim gemeinsamen Einsatz mit anderen Bildschirmelementen ist die Toolbar direkt über der Liste positioniert. Wenn das ALV Grid Control das einzige Element ist, ersetzt die Toolbar die Standard- Drucktastenleiste.[Alv, Wikb, BC4Q2b, Rös05]

23 3.4 ABAP List Viewer 16 Abbildung 3.7. ALV als Einzel- und als Teilelement Praktische Umsetzung Im Folgenden wird mit Hilfe der Klasse CL GUI ALV GRID ein ALV-Grid- Control implementiert. 1 * Custom Container Control I n s t a n z erzeugen 2 CREATE OBJECT r e f c u s t o m c o n t a i n e r EXPORTING 4 container name = CUSTOM CONTROL1 5 r e p i d = sy cprog 6 dynnr = EXCEPTIONS 8 c n t l e r r o r = 1 9 c n t l s y s t e m e r r o r = 2 10 c r e a t e e r r o r = 3 11 l i f e t i m e e r r o r = 4 12 l i f e t i m e d y n p r o d y n p r o l i n k = 5 13 OTHERS = IF sy subrc <> MESSAGE ID sy msgid TYPE sy msgty NUMBER sy msgno 16 WITH sy msgv1 sy msgv2 sy msgv3 sy msgv4. 17 ENDIF Zu Beginn muss ein Custom-Container-Control erzeugt werden, in den das ALV- Grid später abgelegt werden kann. Das Custom-Container-Control ist ein Objekt der Klasse cl gui custom container. Der Container wird in diesem Fall auf dem Bild mit der Nummer 5000 abgelegt (siehe Zeile 6) * ALV Grid Control I n s t a n z erzeugen 4 CREATE OBJECT r e f a l v g r i d EXPORTING 6 i p a r e n t = r e f c u s t o m c o n t a i n e r EXCEPTIONS 8 e r r o r c n t l c r e a t e = 1 9 e r r o r c n t l i n i t = 2 10 e r r o r c n t l l i n k = 3 11 e r r o r d p c r e a t e = 4 12 OTHERS = IF sy subrc <> MESSAGE ID sy msgid TYPE sy msgty NUMBER sy msgno 15 WITH sy msgv1 sy msgv2 sy msgv3 sy msgv4. 16 ENDIF Als nächstes wird eine Objekt der Klasse cl gui alv grid erzeugt. Dieses Objekt ist das eigentliche ALV-Grid. Der Konstruktor der ALV-Grid-Klasse bekommt den Container als Parameter übergeben (siehe Zeile 6). Jetzt wurde das ALV-Grid mit

24 3.5 SimpleTreeModel 17 dem Container, der bereits auf dem Bildschirm positioniert ist, verlinkt. Allerdings ist das ALV-Grid noch leer, da noch keine Tabelle zugewiesen wurde * Anzeige der Daten im ALV Grid Control 3 CALL METHOD r e f a l v g r i d >s e t t a b l e f o r f i r s t d i s p l a y 4 EXPORTING 5 i s t r u c t u r e n a m e = g c s t r u c t u r e k o n t r 6 i s v a r i a n t = g s v a r i a n t 7 i s a v e = A 8 i s l a y o u t = g s l a y o u t 9 CHANGING 10 i t o u t t a b = g t k o n t r s t a t 11 i t f i e l d c a t a l o g = g t f i e l d c a t 12 EXCEPTIONS 13 i n v a l i d p a r a m e t e r c o m b i n a t i o n = 1 14 p r o g r a m e r r o r = 2 15 t o o m a n y l i n e s = 3 16 OTHERS = IF sy subrc <> MESSAGE ID sy msgid TYPE sy msgty NUMBER sy msgno 19 WITH sy msgv1 sy msgv2 sy msgv3 sy msgv4. 20 ENDIF Um nun auch das ALV-Grid mit Daten zu füllen, wird die Methode set table for first display der Klasse cl gui alv grid aufgerufen. Durch die optionalen Parameter is variant und i save wird festgelegt, dass sich das Layout der der Liste beliebig anpassen und als Variante sichern lässt. Somit kann jeder Benutzer seine eigene, für sich optimierte Variante zu der ALV-Liste anlegen, sichern und als Standard festlegen.[alv, Wikb, BC4Q2b, Rös05] 3.5 SimpleTreeModel Idee Die Grundidee ist vergleichbar mit dem ABAP List Viewer, denn auch das SimpleTreeModel wird in ein Custom-Container-Control. Der Unterscheid ist, dass beim ALV eine Tabelle dargestellt wird und beim SimpleTreeModel eine Baumstruktur.[Rös05] Verwendung Durch das SimpleTreeModel lassen sich hierachisch strukturierte Daten in einer Baumstruktur darstellen. Die Darstellung ist vergleichbar mit der Navigationshilfe im Windows Explorer. Bei dem SimpleTreeModel kann zu jedem Knoten genau ein Text hinterlegt werden. Es gibt verschidene andere Tree-Modelle von SAP, bei denen zu jedem Knoten mehrere Texte spaltenweise hinterlegt werden. Es gibt die Möglichkeit zwischen Ordnern und Knoten in der Baumstruktur zu unterscheiden. Weiterhin ist es Möglich anstelle eines Knotens eine beliebige Grafik einzufügen (z.b. Logo für MS Word-Datei). Jeder Knoten und Ordner der Baumstruktur hat einen eindeutigen Schlüssel/Namen und eine Referenz auf den Vorgängerknoten. Somit lässt sich die Baumstruktur bis zur Wurzel eindeutig zurückverfolgen.[rös05]

25 3.5 SimpleTreeModel Praktische Umsetzung Im Folgenden wird mit Hilfe der Klasse CL GUI SIMPLE TREE wird ein SimpleTree-Control implementiert. Zunächst wird eine Instanz zum SimpleTree-Control vom Typ CL GUI SIMPLE TREE erzeugt. Diese wird in das Custom Control abgelegt (vgl. ALV). 1 * Das Ausgabe Control f ü r d i e Baumstruktur e r s t e l l e n 2 CREATE OBJECT t r e e c o n t r o l 3 EXPORTING 4 parent = c o n t a i n e r 5 EXCEPTIONS 6 l i f e t i m e e r r o r = 1 7 c n t l s y s t e m e r r o r = 2 8 c r e a t e e r r o r = 3 9 f a i l e d = 4 10 t r e e c o n t r o l a l r e a d y c r e a t e d = IF sy subrc <> MESSAGE a ENDIF. Das folgende Codebeispiel zeigt, wie die Knoten in die Baumstruktur eingefügt werden können. 1 * Wurzel i n den Baum e i n f ü g e n 2 CALL METHOD t r e e c o n t r o l >add node 3 EXPORTING 4 node key = root 5 i s f o l d e r = X 6 t e x t = Wurzelknoten 7 EXCEPTIONS 8 OTHERS = 1. 9 IF sy subrc <> MESSAGE a ENDIF * B l a t t i n den Baum e i n f ü g e n 14 CALL METHOD t r e e c o n t r o l >add node 15 EXPORTING 16 node key = Knoten1 17 r e l a t i v e n o d e k e y = root 18 r e l a t i o n s h i p = c l s i m p l e t r e e m o d e l=>r e l a t l a s t c h i l d 19 i s f o l d e r = 20 t e x t = Blatt 21 EXCEPTIONS 22 OTHERS = IF sy subrc <> MESSAGE a ENDIF. Zu Beginn wird der Wurzelknoten in die Baumstruktur eingefügt. Der Wurzelknoten zeichnet sich dadurch aus, dass kein Vorgängerknoten angegeben wird (relative_node_key). Es darf nur einen einzigen Wurzelknoten geben und der node_key muss für jeden Knoten iendeutig sein. Dadurch lässt sich jeder Knoten eindeutig identivizieren und ansteuern. Durch den Parameter isfolder wird festgelegt ob der Knoten ien Blatt oder ein Ordner ist. Es handelt sich dann um einen Ordner, wenn isfolder = X ist.[rös05]

26 3.6 Überblick über das Geschäftsfeld Agenturgeschäft Überblick über das Geschäftsfeld Agenturgeschäft Als Agenturgeschäft wird eine Form der Geschäftsabwicklung zwischen Dritten bezeichnet. Es wird dabei zwischen der Zentralregulierung, dem Factoring, der Kreditkartenabwicklung und dem Vermittlungsgeschäft unterschieden. Da im Rahmen dieser Abschlussarbeit lediglich die Zentralregulierung für das betriebswirtschaftliche Hintergrundverständnis wichtig war, wird an dieser Stelle auch nur die Zentralregulierung näher erläutert. Zentralregulierung Bei der Zentralregulierung (siehe 3.8) werden die Beteiligten in drei Gruppen eingeteilt: Den Einkaufsverband(Zentralregulierer), die Mitglieder des Einkaufsverbandes(Kunden) und die Lieferanten. Der Einkaufsverband handelt im Auftrag seiner Mitglieder die Preise und Konditionen für Wareneinkäufe mit einem Lieferanten aus. Wird ein Geschäft abgeschlossen entsteht ein Kaufvertrag zwischen dem Lieferanten und dem Kunden. Der Einkaufsverband übernimmt meist für die Wareneinkäufe eine Ausfallbürgschaft (=Delkredere) gegenüber dem Lieferanten. Weiterhin verpflichtet sich der Lieferant dazu die Zahlungsabwicklung über den Einkaufsverband vorzunehmen. Zur Zahlungsabwicklung erhält der Einkaufsverband die Rechnungen vom Lieferanten und sammlt diese. Der Zentralregulierer begleicht die Forderungen des Lieferanten selbst und stellt diese Ausgaben den Mitgliedern dann jeweils periodisch in Rechnung. Somit hat der Lieferant den Vorteil, dass seine Forderungen auf einen Schlag erstattet werden, da der Einkaufsverband für seine Mitglieder die Waren zahlt. Die Mitglieder des Einkaufsverbandes haben den Vorteil, dass sie die Waren zu günstigeren Preisen kaufen können, da der Verband die Waren für alle Mitglieder einkauft und somit in großen Mengen kaufen kann. Für die Rechnungssammlung und die Zahlungsabwicklung erhält der Einkaufsverband eine Zentralregulierungsprovision. Außerdem erhält der Einkaufsverband eine Provision dafür, dass er die Ausfallbürgschaft übernimmt. Die Provisionen zieht der Einkaufsverband von dem Betrag, welchen er an den Lieferanten zahlt ab. Das Hintergrundwissen über die Zentralregulierung war für diese Arbeit deswegen wichtig, da zwei der drei entwickelten IDoc-Monitore im Auftrag der ORGA für Unternehmen entwickelt wurden die als Zentralregulierer aktiv sind.[age]

27 3.6 Überblick über das Geschäftsfeld Agenturgeschäft 20 Abbildung 3.8. Zentralregulierung[Age]

28 4 Entwicklung spezialisierter IDoc-Monitore In diesem Kapitel wird die Entwicklung zweier auf bestimmte IDoc-Typen ausgelegten IDoc-Monitore beschrieben. Diese IDoc-Monitore dienen als Grundlage für den flexiblen IDoc-Monitor. 4.1 Erster IDoc-Monitor Der erste IDoc-Monitor ist ein sehr umfangreicher und mit vielen Funktionen ausgestatteter IDoc-Monitor. Jedoch ist er nur auf einen IDoc-Typ anwendbar. Der Idoc-Monitor besteht aus drei Teilen, dem Selektionsbild, dem Übersichtsbild und dem Detailbild. Diese drei Teile werden im folgenden beschrieben Selektionsbild Abbildung 4.1. Selektionsbild - erster IDoc-Monitor

29 4.1 Erster IDoc-Monitor 22 Abbildung 4.1 zeigt das Selektionsbild, welches zu dem IDoc-Monitor entwickelt wurde. Auf diesem Selektionsbild sollten als Suchkriterien Verkaufsorganisation, Kreditor, Erstellungsdatum, Erstellungsuhrzeit, Nachrichtenvariante, IDoc- Status, IDoc-Nummer, Änderungsdatum und die Referenz der Übertragungsdatei verwendet werden. 1 * E i n g a b f e l d e r d e f i n i e r e n e r s t e r Block 2 SELECTION SCREEN BEGIN OF BLOCK b01 WITH FRAME TITLE text * E i n g a b f e l d e r d e f i n i e r e n e r s t e r Unterblock 5 SELECTION SCREEN BEGIN OF BLOCK b01 1 WITH FRAME TITLE text SELECT OPTIONS: 8 s v k o r g FOR vbak vkorg, 9 s l i f n r FOR l f a 1 l i f n r SELECTION SCREEN END OF BLOCK b * E i n g a b f e l d e r d e f i n i e r e n z w e i t e r Unterblock 14 SELECTION SCREEN BEGIN OF BLOCK b01 2 WITH FRAME TITLE text SELECT OPTIONS: 17 s c r e d a t FOR edidc credat, 18 s c r e t i m FOR edidc cretim, s mescod FOR edidc mescod, s s t a t u s FOR edidc s t a t u s, 23 s docnum FOR edidc docnum, 24 s upddat FOR edidc upddat, s r e f i n t FOR edidc r e f i n t. dateiname SELECTION SCREEN END OF BLOCK b * E i n g a b f e l d e r d e f i n i e r e n d r i t t e r Unterblock 31 SELECTION SCREEN BEGIN OF BLOCK b01 3 WITH FRAME TITLE text PARAMETERS: p max tr TYPE i SELECTION SCREEN END OF BLOCK b SELECTION SCREEN END OF BLOCK b * E i n g a b f e l d e r d e f i n i e r e n d r i t t e r Block 40 SELECTION SCREEN BEGIN OF BLOCK bl3 WITH FRAME TITLE text PARAMETERS: p v a r i TYPE s l i s v a r i. 42 SELECTION SCREEN END OF BLOCK bl3. 43 * Ende von /ZRB/AB IDOC MONITOR t Oben sehen Sie einen Teil des Codes zur Erstellung des Selektionsbildes. Im folgenden werden einige Teile des Quelltextes erläutert. Mit der Anweisung in Zeile 2 wird der äußere Rahmen des oberen Blocks definiert. Weiterhin wird dem Rahmen als Titel text-012 übergeben. Das Textsymbol text-012 beinhaltet als Text Selektion. Durch die Anweisung in Zeile 8 wird dem Select-Option s vkorg das Tabellenfeld vbak-vkorg zugewiesen. Dadurch ist zur Verkaufsorganisation eine obere und Untere Grenze auswählbar. Die weiteren Rahmen und Select-Options werden analog definiert. In Zeile 33 wird der Parameter p_max_tr vom Typ Integer definiert. Der Paramter erscheint in dem Einstiegsbild als das Feld für die maximale Anzahl von Treffern.

30 4.1 Erster IDoc-Monitor 23 1 *& * 2 *& Event i n i t i a l i z a t i o n 3 *& * 4 INITIALIZATION s s t a t u s s i g n = I. 8 s s t a t u s o p tion = EQ. 9 s s t a t u s low = APPEND s s t a t u s TO g t s t a t u s Das Ereignis INITIALIZATION wird zwischen Laden des Programms und dem Aufbau des Selection-Screen ausgelöst. Hier kann beispielsweise der Status vorbelegt werden. Im obigem Beispiel würden nur IDocs mit dem Status 51 gesucht werden. 1 *& * 2 *& Event end of s e l e c t i o n 3 *& * 4 END OF SELECTION. 5 6 CALL SCREEN Das Ereignis END-OF-SELECTION wird nach dem Lesen von Daten durch die logische Datenbank ausgelöst. Hier ist END-OF-SELECTION so definiert, dass Screen 4000 aufgerufe wird. Screen 4000 ist das Übersichtsbild Übersichtsbild Abbildung 4.2. Übersichtsbild - erster IDoc-Monitor

31 4.1 Erster IDoc-Monitor 24 Die Abbildung 4.2 zeigt das Übersichtsbild, das nach dem Selektionsbild angezeigt wird. Dieses Übersichtsbild besteht aus einem großen ALV-Grid. Die erste Spalte zeigt in Form einer Ampel an, ob das IDoc erfolgreich abgeschlossen (Ampel = grün), fehlerhaft abgeschlossen (Ampel = Rot) oder noch nicht abgeschlossen (Ampel = gelb) ist. Abgeschlossen heißt, dass das IDoc nicht mehr verändert werden darf, weil bereits der BEleg zu dem IDoc erzeugt wurde. Somit hat das IDoc seinen Zweck erfüllt und die Daten wurden korrekt ins System übertragen. Fehlerhaft abgeschlossen heißt, dass die IDoc-Daten fehlerhaft waren und kein Beleg dazu erzeugt werden konnte. Das IDoc muss dann neu übertragen werden. In der Regel werden im IDoc Monitor nur die IDocs angezeigt, die noch nicht abgeschlossen sind. Denn die abgeschlossenen IDocs sind nicht mehr änderbar. In den folgenden Spalten werden zahlreiche Kontrolldaten zu dem jeweiligen IDoc angezeigt, wie u.a. die IDoc-Nummer, der IDoc-Status, die Lieferantennummer, die Lieferantenadresse, die Kundennummer und die Kundenadresse. Auf dem Übersichtsbild werden die Daten aus dem Kontrollsatz der selektierten Idocs angezeigt und um einige Zusatzinformationen (z.b. Meldungstext, Lieferantenname) erweitert. Auf die einzelnen IDocs können unterschiedliche Funktionen angewendet werden. In diesem Fall wurden 14 Funktionen implementiert. Diese Funktionen sind über die Drucktastenleiste ausführbar (siehe 4.3). Abbildung 4.3. Drucktastenleiste des ersten IDoc-Monitors Die erste Funktion ist der Link in die Detailansicht zu dem IDoc. Hierbei wird in das Detailbild zu dem IDoc verzweigt. Das Detailbild beinhaltet verschiedene Informationen zu den einzelnen Datensätzen des Idocs und wird in näher erläutert. Als nächstes wurde der Sprung in die technische IDoc-Sicht implementiert. Dabei wird eine Transaktion im SAP-System aufgerufen, bei der die technischen Daten zu beliebig vielen IDocs angezeigt werden können (Transaktion WE02). Da in disem Fall die IDoc-Nummern der ausgewählten IDocs an die Transaktion mit übergeben werden sollen, wird die Transaktion nicht wie üblich über CALL TRANSACTION ausgerufen, sondern durch den den SUBMIT-Befehl: 1 SUBMIT r s e i d o c 2 WITH docnum IN lr docnum 2 WITH c r e d a t IN r a n g e c r e d a t 3 AND RETURN. Hinter dem Transaktionscode WE02 verbirgt sich der Report rseidoc2. Dieser wird durch den SUBMIT gestartet und bekommt die Variablen lr docnum und range credat übergeben. Die Variable lr docnum beinhaltet die ausgewählten IDoc-Nummern. Durch range credat wird ein Zeitraum übergeben, indem die IDocs erstellt wurden. In diesem Fall wurde dieser Zeitraum auf den Initialwert gesetzt um alle IDocs zu den übergebenen Nummern unabhängig vom Erstel-

32 4.1 Erster IDoc-Monitor 25 lungsdatum anzuzeigen. Würde kein Zeitraum übergeben, dann würde der Report rseidoc2 den Zeitraum auf den aktuellen Tag setzten und nur IDocs zu den übergebenen Nummern anzeigen, die am aktuellen Tag erstellt wurden. Mit der dritten Funktion kann der Agenturbeleg zu dem ausgewählten IDoc aufgerufen und angezeigt werden. Wurde zu dem IDoc noch kein Agenturbeleg erzeugt, so erhält der Benutzer eine entsprechende Fehlermeldung. Der Agenturbeleg wird durch die Transaktion WZR3 angezeigt. 1 SET PARAMETER ID WLZ FIELD l w b e l n. 2 3 CALL TRANSACTION WZR3 AND SKIP FIRST SCREEN. Vor dem Aufruf der Transaktion wird der Paramter WLZ mit der Belegnummer des selektierten IDoc gefüllt. Durch den Zusatz AND SKIP FIRST SCREEN wird eingestellt, dass das Selektionsbild direkt verlassen und gleich der Agenturbeleg angezeigt wird. Die vierte Funktion aktualisiert die Liste mit den IDocs. 1 CALL METHOD r e f a l v g r i d >r e f r e s h t a b l e d i s p l a y Hierbei wird lediglich die refresh table display der Klasse CL GUI ALV GRID aufgerufen. Diese Methode sorgt dafür, dass der Inhalt des ALV-Grid-Controls mit den Daten der Ausgabetabelle neu aufgebaut wird. Beim aktuallisieren wird weiterhin geprüft ob im Hintergrund noch Jobs aktiv sind. In diesem Fall erhält der Anwender eine Infomeldung. Denn wenn die Jobs aktiv sind, könnte sich der Status bei den betroffenen IDocs verändern. Bei der fünften Funktion wird die Verarbeitung des IDocs im Hintergrund angestoßen, d.h. zu dem IDoc wird ein neuer Job gestartet, ausgeführt und beendet. Diese Funktion ist dann sinnvoll, wenn über das Detailbild Daten des IDocs so verändert wurden, dass das IDoc erfolgreich abgeschlossen werden kann. Durch die Verarbeitung wird der Status an den neuen Zustand des IDocs angepasst. So lässt sich erkennen ob das IDoc erfolgreich abgeschossen werden konnte oder ob erneut ein Fehler aufgetreten ist. Als nächste Funktion wurde das logische Löschen der IDocs realisiert. Logisches Löschen, bedeutet in diesem Fall, dass der Status des Idocs auf gelöscht gesetzt wird das IDoc aber nicht tatsächlich aus der Datenbank gelöscht wird. Anschließend wurde eine Funktion zum ablehnen eines IDocs programmiert. Dabei wird auch wie beim logischen Löschen nur der Status des IDocs verändert. Die nächste Funktion ist die IDoc-Freigabe. Hierbei kann ein IDoc, sofern ein entsprechender Fehler vorliegt, freigeben werden. D.h. das IDoc würde fehlerhaft abgeschlossen werden. Hier kann der Anwender zwischen verschiedenen Freigabetypen wählen und einen Freigabetext eingeben. Ein Freigabetyp muss gewählt werden um den Status dementsprechend anzupassen und damit das IDoc fehler-

33 4.1 Erster IDoc-Monitor 26 haft abzuschließen. Die Funktion IDoc-Kennzeichnen sorgt dafür, dass ein IDoc auf verarbeitet und dann auf erledigt gesetzt wird. Bedingung dafür ist, dass der zugehörige Agenturbeleg dern Status erledigt oder storniert hat. D.h. auch durch diese Funktion wird das gewählte IDoc abgeschlossen. Durch die Funktion IDoc Drucken wird die Druckausgabe der IDoc-Daten gesteuert. Dabei werden die ausgewählten IDocs an einen Funktionsbaustein übergeben, welcher die IDoc-Daten aufbereitet, ein passendes Formular dazu erstellt und an den Drucker sendet. Weiterhin gibt es noch vier Funktionen zum -Versand. Dabei werden Empfänger- und Betreffdaten zum Teil aus der Datenbank entnommenen und an den Funktionsbaustein, welcher auch das Drucken regelt übergeben. Jedoch wird das Formular in diesen Fällen nicht gedruckt sondern per versendet Detailbild Abbildung 4.4. Detailbild - erster IDoc-Monitor Das Detailbild gibt neben den Kontrolldaten eines IDocs auch die Datensätze des jeweiligen IDocs aus. Zum Teil gibt es auch die Möglichkeit Daten zu ändern

34 4.1 Erster IDoc-Monitor 27 um so das IDoc später weiter verarbeiten zu können. Dieser IDoc-Typ hat vier verschiedene Datensegmente (Die Kopfdaten, die Steuerdaten, die Positionsdaten und ein Segment für die Freigabedaten) und bezieht sich auf Rechnungen. Die Kopfdaten kommen bei jedem IDoc dieses Typ exakt einmal vor und enthalten eindeutige Informationen wie die Rechnungsnummer, den Rechnungssteller oder den Rechnungsempfänger. Die Steuerdaten können mehrfach vorkommen und enthalten Informationen wie den Steuersatz und den Steuerbetrag. Da die Rechnungspositionen unterschiedlich versteuert werden können, ist es auch möglich, dass mehrere Steuersätze zu einem IDoc existieren. Das Detailbild lässt sich in fünf Bereiche unterteilen. Der erste Bereich beinhaltet ein ALV-Grid mit Daten aus dem Kontroll- und Statussatz des ausgewählten IDocs. Wobei lediglich der letzte, also der aktuelle Statussatz des IDocs angezeigt wird. Diese Daten können hier nicht geändert sondern nur eingesehen werden. Der zweite Bereich beinhaltet ein ALV-Grid mit den Kopfdaten. Die Kopfdaten sind teilweise änderbar. So kann beispielsweise die Rechnungsnummer oder die Nummer der Verkaufsorganisation geändert werden Programmdokumentation Teil des IDoc-Monitors ist ein kleine Dokumentation (siehe 4.5), die auf dem Selektionsbild aufgerufen werden kann und dann in Form eines PopUps angezeigt wird. Abbildung 4.5. Programmdokumentation - erster IDoc-Monitor

35 4.2 Zweiter IDoc-Monitor Zweiter IDoc-Monitor Dieser IDoc-Monitor ist ein weniger umfangereich als der IDoc-Monitor aus Kapitel 4.1. Jedoch sind zum Teil andere Funktionen implementiert. Im folgenden werden lediglich die Unterschiede zum ersten IDoc-Monitor beschrieben Selektionsbild Das Selektionsbild ist lediglich im Bereich Stammdaten unterschiedlich zu dem Selektionsbild des ersten IDoc-Monitors. In den Segmenten zu diesem IDoc-Typ wird neben dem Lieferant und ein(e) RegionalleiterIn gepflegt. Deswegen war es notwendig das Selektionsbild anzupassen. Abbildung 4.6. Selektionsbild - Stammdaten (zweiter IDoc-Monitor) Übersichtsbild Die ALV-Liste auf dem Übersichtsbild zu dem zweiten IDoc-Monitor unterscheidet nur unwesentlich von dem ersten Monitor (siehe Abbildung 4.7). Jedoch gibt Abbildung 4.7. Übersichtsbild - zweiter IDoc-Monitor es etwas weniger und zum Teil andere Funktonen als ersten Monitor. Die - Funktionen, die bei dem ersten IDoc-Monitor noch Bestandteil waren sind bei diesem IDoc-Monitor nicht notwendig. Der wesentliche Unterschied ist die Funktion Massenänderung (siehe Abbildung 4.8). Bei dieser Funktion ist es möglich mehrere IDocs gleichzeitig zu verändern. Dazu werden über ein PopUp Daten eingelesen und beliebig viele markierte IDocs auf diese Daten geändert. Die übrigen Funktionen sind mit Ausnahme der Anpassungen an die unterschiedliche Segmentstruktur genauso implementiert wie bei dem ersten IDoc-Monitor. Die Funktion zurück zum Lieferant ist genauso implementiert wie die Funktion Idoc ablehnen des ersten IDoc-Monitors.

36 4.2 Zweiter IDoc-Monitor 29 Abbildung 4.8. Funktion Massenänderung - zweiter IDoc-Monitor Detailbild Das Detailbild besteht lediglich aus 3 Bereichen den Kopfdaten, den Positionsdaten und den Steuerdaten (siehe 4.9). Wie bei dem ersten IDoc-Monitor gibt es auch hier, abhängig vom IDoc-Status änderbare Felder. Da die Segmente dieses IDocs anders sind als beim ersten IDoc-Monitor, unterscheiden sich die änderbaren Felder. Abbildung 4.9. Detailbild - zweiter IDoc-Monitor

37 4.3 Fazit Fazit Nachdem die Entwicklung der ersten beiden IDoc-Monitore abgeschlossen ist, lassen sich einige Vor- und Nachteile dieser Monitore erkennen. So fällt es auf, dass die Transaktion WE02(siehe 4.10) bereits eine recht gute Übersicht über die IDocs gibt. Diese Übersicht wird durch die Funktion Absprung in die technische IDoc-Sicht, welche in beiden IDoc-Monitoren implentiert ist aufgerufen. Der Vorteil den die IDoc-Monitore haben ist, dass hier die IDocs auch modifiziert werden können und es durch die verschieden Fuktionen die Möglichkeit gibt die IDocs positiv oder negativ abzuschließen. Bei der Transaktion WE02 sind dagegen keinerlei Änderungen möglich. Eine sehr gute und schnelle Übersicht gibt jeweils das Übersichtsbild. Hier lässt Abbildung Anzeige der Transaktion WE02 sich durch die Ampelanzeige auf den ersten Blick erkennen in welchem Zustand das IDoc ist. Außerdem wird auf dem Übersichtsbild auch direkt der Meldungstext zum aktuellen Status des IDocs angezeigt. So erkennt man an dieser Stelle ohne viel Aufwand beispielweise warum ein IDoc nicht abgeschlossen werden konnte. Allerdings hat die Darstellung, welche bei diesen IDoc-Monitoren gewählt wurde auch Nachteile. So ist das Detailbild durch die zahlreichen ALV-Grids mit den jeweiligen Drucktastenleisten ziemlich unübersichtlich. Abschließend lässt sich sagen, dass die beiden IDoc-Monitore zwar gelungen sind und auch den gewünchten Mehrwert liefern. Jedoch haben die IDoc-Monitore auch Schwächen, welche der flexible IDoc-Monitor nicht haben soll.

38 5 Konzept des flexiblen IDoc-Monitors In diesem Kapitel wird das Konzept eines universell einsetzbaren IDoc-Monitors beschrieben. Dabei werden noch keine Probleme die bei der Realisierung des Konzeptes auftraten genannt, sondern es wird lediglich die Idee hinter dem IDoc- Monitor beschrieben. 5.1 Konzept Der flexible IDoc-Monitor soll anders als die bisherigen IDoc-Monitore auf alle IDoc-Typen anwendbar sein. D.h. die Tabllenstruktur muss sich dynamisch an den IDoc-Typ anpassen um die verschiedenen IDoc-Segmente darstellen zu können. Außerdem soll der IDoc-Monitor ohne großen Entwicklungsaufwand bei unterschiedlichen Unternehmen einsetzbar sein. Weiterhin soll der flexible IDoc-Monitor wesentlich übersichtlicher als die zuvor entwickelten IDoc-Monitore sein. Optimal wäre eine Kombination aus den zwei IDoc-Monitoren aus Kapitel 4 und der Ansicht aus Transaktion WE02. Um den IDoc-Monitor flexibel anpassen zu können, müsste auf dem Selektionsbild ein IDoc-Typ ausgewählt werden. Durch den IDoc-Typ könnten aus der Tabelle EDISDEF die Segmente zu dem IDoc ermittelt werden. Sobald die Segmente bekannt sind könnte die Tabellen-Struktur festgelegt werden und die Segmente könnten somit korrekt angezeigt werden. Um die Kombination aus den zwei IDoc-Monitoren und der Ansicht aus Transaktion WE02 zu erreichen, müsste die graphische Benutzeroberfläche zweigeteilt sein. Links könnten die IDoc-Nummern angezeigt werden und auf der rechten Seite Segmentdaten zu dem IDoc. Um den Mehrwert gegenüber Transaktion WE02 zu haben, soll es auch wieder möglich sein Funktionen auf die IDocs anzuwenden. Da jedoch nicht bei jedem IDoc-Typ alle Funktionen Sinn machen, muss an dieser Stelle entschieden werden welche Funktionen angezeigt werden sollen. So macht z.b. die Funktion Anzeige des Agenturbelegs nur bei IDocs aus dem Agenturgeschäft Sinn. Wenn jedoch Idocs mit Materialdaten angezeigt werden würde es Sinn machen eine Funktion zu haben, die zu dem ausgewählten Material die Daten anzeigt. Also könnte an dieser Stelle beispielsweise die Transaktion MM03 aufgerufen werden. Diese Unterscheidung der Funktionen muss im Rahmen des flexiblen IDoc-Monitors auf jeden Fall berücksichtigt werden.

39 6 Entwicklung des flexiblen IDoc-Monitors Dieses Kapitel erläutert die wie das Konzept des universell einsetzbaren IDoc- Monitors realisiert wurde. Insbesondere werden in diesem Kapitel auch Schwierigkeiten die erst bei der Implementierung ersichtlich wurden angesprochen und deren Lösung beschrieben. 6.1 Customizing Tabellen Da sich nicht alle Informationen komplett dynamisch ermitteln lassen, war es notwendig einige Customizing Tabellen zu erstellen. Diese Tabellen müssen dann für die IDocs, auf welche der Monitor angewendet werden soll, gepflegt werden. Beispiele für die Pflege der Customizing Tabellen befinden sich in Kapitel Customizing Tabelle für das Selektionsbild Für das Selektionsbild war eine Customizing Tabelle notwendig geworden um das Selektionsbild dynamisch anpassen zu können und je nach IDoc-Typ weitere Selektionsoptionen zu haben. Schlüssel der Tabelle sind die Mandantennummer, der IDoc-Typ und der Segmentname. Somit kann jeder Mandant zu jedem IDoc-Typ und Segment nur genau ein Feld eintragen. Abbildung 6.1. Struktur der Customizing Tabelle für das Selektionsbild Customizing Tabelle für die änderbaren Felder Um die änderbaren Felder bei jedem IDoc-Typ anders wählen zu können, war auch hier eine Customizing Tabelle nötig. Hier sind alle Tabellenfelder Teil des

40 6.1 Customizing Tabellen 33 Primärschlüssels. Also könnten theoretisch alle Felder jedes IDoc-Segmentes änderbar sein. Abbildung 6.2. Struktur der Customizing Tabelle für die änderbaren Felder Customizing Tabelle für die Funktionen Durch die Customizing Tabelle für die Funktionen können jedem IDoc-Typ beliebig Funktionen zugeordnet werden. Die Schlüsselfelder sind der Mandant, der IDoc- Typ und der Funktionscode. Damit ist gesichert, dass keine Funktion für einen IDoc-Typ doppelt eingetragen wird. Abbildung 6.3. Struktur der Customizing Tabelle für die Funktionen Customizing Tabelle für den Status Da auch der IDoc-Status in unterschiedlichen Unternehmen unterschiedlich behandelt werden kann, lässt sich durch diese Customizing Tabelle zu jedem Status festlegen welche Farbe die Ampel im Übersichtsbild haben soll. Bei allen Status, die in dieser Tabelle nicht gepflegt sind, wird die Ampel grau angezeigt. Abbildung 6.4. Struktur der Customizing Tabelle für die Ampelanzeige

41 6.2 Selektionsbild Selektionsbild Das Selektionsbild wurde für den flexiblen IDoc-Monitor zweigeteilt. Der erste Teil(siehe Abb. 6.5) hat genau eine Selektionsoption. Hier muss der IDoc-Typ ausgewählt werden. Bleibt das Feld leer, erscheint eine Fehlermeldung, da jedes IDoc einen IDoc-Typ zugeordnet ist. Abbildung 6.5. Selektionsbild des flexiblen IDoc-Monitors (Teil1) Der zweite Teil(siehe Abb. 6.6) des Selektionsbildes besteht aus einen festen und einem dynamischen Teil. Im festen Teil können Kontrolldaten und eine maximale Anzahl von Treffern angegeben werden. Kontrolldaten nach denen selektiert werden kann sind die IDoc-Nummer, das Erstellungsdatum, die Erstellungsuhrzeit, der Idoc-Status und das Datum an dem das IDoc zuletzt geändert wurde. Der Teil mit den dynmischen Selektionsdaten wird durch die Customizing Tabelle zum Selektionsbild festgelegt. Abbildung 6.6. Selektionsbild des flexiblen IDoc-Monitors (Teil2) Um das Selektionsbild dynamisch anzupassen, musste ABAP-Code zur Laufzeit generiert werden. Dazu gab es bereits eine Programmvorlage, welche an einigen Stellen erweitert wurde. Die Code-Generierung erfolgte unter Verwendung des Befehls INSERT REPORT. Das Folgende Beispiel zeigt wie sich ABAP-Code dynamisch erzeugen lässt:

42 6.3 Übersichts- und Detailbild APPEND REPORT z i d o c m o n i s e l e k t i o n. TO g t c o d e g s c o d e = DATA: g t e d i d 4 type standard t a b l e o f edid4.. 5 APPEND g s c o d e TO g t c o d e g s c o d e = SELECT OPTIONS: so docn f o r edidc docnum o b l i g a t o r y.. 8 APPEND g s c o d e TO g t c o d e g s c o d e = SELECT * FROM edid4 INTO TABLE g t e d i d 4 WHERE docnum IN so docn.. 11 APPEND g s c o d e TO g t c o d e INSERT REPORT ZIDOCMONI SELEKTION FROM g t c o d e SUBMIT z i d o c m o n i s e l e k t i o n VIA SELECTION SCREEN AND RETURN Die Variable gt code ist eine Tabelle, die Textzeilen enthält, welche maximal 255 Byte lange sein dürfen und gs code ist eine Strukur vom Zeilentyp der Tabelle. Der Zeilentyp wurde so ausgewählt, da laut Definition von INSERT REPORT eine Tabelle mit maximal 255 Byte langen Textzeilen übergeben bekommen darf. Die Codezeilen werden über den Befehl APPEND an die Tabelle gehängt. So können beliebige Codezeilen erstellt werden. Über den Befehl INSERT REPORT wird dem Report (hier ZIDOCMONI_SELEKTION) die Tabelle mit den Codezeilen übergeben. Ist der Report noch nicht vorhanden, wird der Report automatisch neu angelegt. Existiert bereits ein Report mit diesem Namen, wird dieser mit dem neuen Code überschrieben. Durch den SUBMIT-Befehl wird der Report gestartet und ausgeführt. Das folgende Code-Beispiel zeigt den Code, der im Code-Bespiel zuvor, erzeugt wurde: REPORT z i d o c m o n i s e l e k t i o n DATA: g t e d i d 4 type standard t a b l e o f edid SELECT OPTIONS: so docn f o r edidc docnum o b l i g a t o r y SELECT * FROM edid4 INTO TABLE g t e d i d 4 WHERE docnum IN so docn Der große Vorteil dieser Technik ist, dass auf diese Art Reports zur Laufzeit erstellt werden können. Es ist zwingend notwendig Reports zur Laufzeit zu erstellen, denn sonst wäre ein dynamisches Selektionsbild oder grundsätzlich die Erstellung von dynamischem Programmcode nicht realisierbar. Je umfangreicher der Code wird, desto langsamer wird das Programm jedoch. Um eine gute Laufzeit zu haben, sollte deswegen so wenig wie möglich Code generiert werden. 6.3 Übersichts- und Detailbild Um die Erfahrungen der ersten beiden IDoc-Monitore mit den Vorteilen der Transaktion WE02 zu kombinieren wurden bei dem flexiblen IDoc-Monitor das Übersichts- und das Detailbild zusammengefügt. Die graphische Benutzerober-

43 6.3 Übersichts- und Detailbild 36 fläche ist zweigeteilt (siehe Abb. 6.7). Auf der linken Seite befindet sich eine Baumstruktur und auf der rechten Seite ist eine ALV-Liste mit den aktuellen Segmentdaten. In der Drucktastenleiste befinden sich die die Buttons zu den Funktionen. Abbildung 6.7. Übersichtsbild des flexiblen IDoc-Monitors Je nach IDoc-Typ sind unterschiedliche Funktionen zu sehen. Die Aktivierung der Funktionen ist durch die Customizing Tabelle aus Kapitel geregelt. Das folgende Codebeispiel zeigt wie ermittelt wird welche Funktionen aktiviert werden sollen und wie die Aktivierung realisiert wird SELECT * 3 FROM z i d o c m o n i f k t 4 INTO CORRESPONDING FIELDS OF TABLE g t c u s t 5 WHERE doctyp = gv doctyp 6 ORDER BY f c o d e. 7 8 * Buttons d i e a k t i v i e r t s e i n s o l l e n, werden aus g t f c o d e e n t f e r n t 9 LOOP AT g t c u s t INTO g s c u s t. 10 LOOP AT g t f c o d e INTO g s f c o d e IF g s c u s t f c o d e = F REF AND g s f c o d e = F REF. 13 DELETE g t f c o d e INDEX sy t a b i x. 14 ELSEIF g s c u s t f c o d e = F IDO AND g s f c o d e = F IDO. 15 DELETE g t f c o d e INDEX sy t a b i x. 16 ELSEIF g s c u s t f c o d e = F BEL AND g s f c o d e = F BEL. 17 DELETE g t f c o d e INDEX sy t a b i x. 18 ELSEIF g s c u s t f c o d e = F VER AND g s f c o d e = F VER. 19 DELETE g t f c o d e INDEX sy t a b i x. 20 ELSEIF g s c u s t f c o d e = F DEL AND g s f c o d e = F DEL. 21 DELETE g t f c o d e INDEX sy t a b i x. 22 ENDIF ENDLOOP. 25 ENDLOOP Die Tabelle zidocmoni_fkt ist die Customizing Tabelle mit den Funktionsdaten. Aus dieser Tabelle werden alle Zeilen ausgelesen und in eine interne Tabelle geschrieben, bei denen der IDoc-Typ gleich dem aktuell angezeigten IDoc-Typ ist. So werden nur die Funktionen gefunden, die auch angezeigt werden sollen. Die interne Tabelle gt_fcode beinhaltet alle Funktionscodes, die für den flexiblen IDoc-

44 6.3 Übersichts- und Detailbild 37 Monitor angelegt wurden. Über zwei geschachtelte Schleifen werden werden all die Funktionscodes aus gt_fcode entfernt, die in der Customzing Tabelle hinterlegt sind. Nachdem die Schleifen durchlaufen wurden, stehen nur noch die Funktionscodes zu den Funktionen, die nicht aktiv sein sollen in der internen Tabelle gt_fcode. Im PBO-Modul wird der Status des Ausgabebildes mit dem Zusatz excluding gt_fcode gesetzt. Dadurch werden die Funktionen, die ausgeblendet werden sollen nicht angezeigt. Die möglichen Funktionen werden in Kapitel 6.4 genauer beschrieben. Das besondere an der Anzeige der ALV-Liste ist, dass sich die Zeilenstruktur dynamisch ändert. Dies ist notwendig um alle IDoc-Typen darstellen zu können. Da die Tabellenstruktur erst zur Laufzeit feststeht, denn erst dann wird der IDoc-Typ ausgewählt, wird anstelle einer internen Tabelle ein Feldsymbol vom Typ ANY TABLE verwendet. Diesem Feldsymbol kann dann zur Laufzeit ein Tabellentyp zurgeordnet werden. Das Folgende Codebeispiel zeigt wie diese Zuweisung praktisch umgesetzt wird: * Feldsymbole 3 FIELD SYMBOLS <gt out > TYPE ANY TABLE. 4 FIELD SYMBOLS <g t o u t s > TYPE ANY. 5 DATA d r e f TYPE REF TO data * T a b e l l e mit der Struktur des a k t u e l l e n Datensegments e r s t e l l e n 8 CREATE DATA d r e f TYPE STANDARD TABLE OF ( gv segnam ) 9 WITH NON UNIQUE DEFAULT KEY. 10 ASSIGN dref >* TO <gt out > CREATE DATA d r e f s TYPE ( gv segnam ). 13 ASSIGN d r e f s >* TO <g t o u t s > * An e i n Feldsymbol werden d i e Daten mit C o l l e c t 16 * und n i c h t mit Append angehängt 17 LOOP AT g t e d i d d o u t INTO g s e d i d d. 18 MOVE gs edidd sdata TO <g t o u t s >. 19 COLLECT <g t o u t s > INTO <gt out >. 20 ENDLOOP CALL METHOD r e f a l v g r i d >s e t t a b l e f o r f i r s t d i s p l a y 23 EXPORTING 24 i s t r u c t u r e n a m e = g c s t r u c t u r e 25 i s a v e = A 26 CHANGING 27 i t o u t t a b = <gt out > 28 i t f i e l d c a t a l o g = g t f i e l d c a t 29 EXCEPTIONS 30 i n v a l i d p a r a m e t e r c o m b i n a t i o n = 1 31 p r o g r a m e r r o r = 2 32 t o o m a n y l i n e s = 3 33 OTHERS = In Zeile 8 des Codebeispiels wird die Datenreferenz dref als Tabelle vom Typ des aktuellen Segments definiert. Diese Referenz wird in Zeile 9 dem Feldsymbol für die Ausgabetabelle zugewiesen. Nun stellt das Feldsymbol <gt_out> eine interne Tabelle dar. Da diese interne Tabelle jedoch zur Laufzeit definiert wird und somit zum erst zur Laufzeit festet welchen Typ die Tabelle hat, dürfen keine Zeilen mit APPEND angehängt werden. Stattdessen werden die Zeilen mit collect

45 6.3 Übersichts- und Detailbild 38 hinzugefügt (siehe Zeile 19). Das Feldsymbol <gt_out_s> stellt die zur Laufzeit generierte Struktur der internen Tabelle dar. Um das ALV-Grid zur erstellen wird der Methode set_table_for_first_display als Ausgabetabelle die dynamische Tabelle übergeben. Auf diese Art können ALV-Grids mit beliebiger Tabellenstruktur dynamisch zur Laufzeit erstellt werden. Um die Funktionalität der der des ALV-Grids zu vervollständigen müssen trotz der dynamischen Struktur Felder der Ausgabetabelle änderbar gemacht werden. Die Änderbaren Felder können zu jedem IDoc-Typ über die Cusomizing Tabelle aus Kapitel ermittlet und gepflegt werden. Das folgende Codebeispiel zeigt wie die Felder änderbar gemacht werden: 1 * Die Customizing T a b e l l e d u r c h l a u f e n und F e l d e r änderbar machen 2 LOOP AT g t c u s t f e l d INTO g s c u s t f e l d. 3 4 LOOP AT g t f i e l d c a t INTO g s f i e l d c a t. 5 6 IF g s f i e l d c a t f i e l d n a m e = g s c u s t f e l d f e l d AND 7 gv segnam = g s c u s t f e l d segnam. 8 9 g s f i e l d c a t e d i t = X. 10 MODIFY g t f i e l d c a t FROM g s f i e l d c a t ENDIF ENDLOOP ENDLOOP. In verschachtelten Schleifen werden die Customizing Tabelle und der Feldkatalog durchlaufen. Sobald das aktuell anzuzeigende Segment in der Customizing Tabelle und das aktuelle Feld im Feldkatalog gefunden wurden wird im Feldkatalog das Kennzeichen für Änderbarkeit gesetzt (Zeile 9) und der Feldkatalog aktuallisiert (Zeile 10). Nun muss noch geprüft werden ob der aktuelle Status des IDocs Änderungen erlaubt. Durch die Methode set_ready_for_input der Klasse CL GUI ALV GRID kann das AVL-Grid auf änderbar gesetzt werden. Das ALV-Grid ist dann änderbar, wenn der Methode i_ready_for_input = 1 übergeben wird. Das folgende Codebeispiel stellt dies nochmals praktisch dar: 1 * Prüfen ob IDoc geändert werden d a r f 2 IF gs data s t a t u s IN g r s t a t u s g r u e n OR 3 gs data s t a t u s IN g r s t a t u s r o t. 4 5 CALL METHOD r e f a l v g r i d >s e t r e a d y f o r i n p u t 6 EXPORTING 7 i r e a d y f o r i n p u t = ELSE CALL METHOD r e f a l v g r i d >s e t r e a d y f o r i n p u t 12 EXPORTING 13 i r e a d y f o r i n p u t = ENDIF. Um Ein ALV-Grid änderbar zu machen, müssen also zwei Bedingungen erfüllt sein. Zum einen muss das das ALV-Grid grundsätzlich änderbar sein ( = set_ready_for_input ) und zum anderen muss bei den Feldern, welche änderbar sein sollen, der Feldkatalog angepasst werden.

46 6.4 Mögliche Funktionen 39 Um auf Änderungen des ALV-Grids und Doppelklicks reagieren zu können, musste eine Event-Handler-Klasse erstellt werden. Abbildung 6.8 zeigt das Klassendiagramm zur der Event-Handler-Klasse. Abbildung 6.8. Event-Handler-Klasse Die Methode handle_node_double_click wird verwendet, wenn auf ein Blatt oder auf einen Knoten der Baumstruktur ein Doppelklick ausgeführt wird. Im Falle eines Doppelklicks wird das ALV-Grid mit den Daten des angeklickten IDocs gefüllt. Um auf Änderungen der Daten im ALV-Grid reagieren zu können wird die Methode handle_data_changed benötigt. Sobald die Methode aufgerufen wird, werden die Daten so aufbereitet, dass sie gesichert werden können. Bei einem Doppelklick auf ein Feld des ALV-Grids, wird die Methode handle_grid_double_click aktiv. Als Reaktion auf den Doppelklick, wird das IDoc zudem das angeklickte Feld gehört in der Baumstruktur markiert und die Kontrolldaten dazu angezeigt. 6.4 Mögliche Funktionen Es ist möglich bei diesem flexiblen IDoc-Monitor bis zu 5 Funktionen zu aktivieren. Es handelt sich dabei um eine Funktion zum Verlinken einer genaueren Anzeige (z.b. Agenturbeleg, Materialstamm), einer Funktion zum Absprung in die technische IDoc-Sicht, einer Funktion zum Aktuallisieren der Baumstruktur und des ALV-Grids, einer Funktion um die Hintergrundverarbeitung anzustoßen und einer Funktion zum logischen Löschen von IDocs. Die Funktionen zum Absprung in die technische IDoc-Sicht (WE03) und zum Anstoßen der Hintergrundverarbeitung sind genauso implementiert wie bei den beiden vorherigen IDoc-Monitoren. Allerdings müssen diese beiden Funktionen, wie alle anderen Funktionen auch, in die Cusomizing Tabelle die in beschrieben wird, eingetragen werden. Die Funktion zum Aktuallisiern läd die Daten aus der Datenbank neu und baut die Baumstruktur und das ALV-Grid neu auf. Zu der Funktion zum logischen Löschen der IDocs wird in der Customizing Tabelle eine Statusnummer eingetragen. Auf diesen Status wird das IDoc dann gesetzt, wenn die Funktion aktiviert wird. Somit ist gewährleistet, dass die Funktion auch

47 6.4 Mögliche Funktionen 40 dann funktioniert wenn der IDoc-Status einen anderen Wert erhalten soll bei den beiden IDoc-Monitoren aus Kapitel 4. Diese Möglichkeit macht die Funktion felxibel einsetzbar. Bei der Funktion zum Verlinken in einer genauere Ansicht im IDoc-Monitor werden neben den üblichen Werten wie dem IDoc-Typ und dem Funktionscode auch der Name der Transaktion, der Parameter der gesetzt werden soll, die Tabelle und das Feld auf die sich der Paramter bezieht eingetragen. Wie die Customizing Tabelle genau gepflegt wird im Kapitel 7 näher beschrieben.

48 7 Anwendungsbeispiele In diesem Kapitel wird anhand von zwei der wichtigsten IDoc-Typen gezeigt wie der flexible IDoc-Monitor funktioniert und sich die Anzeige anpasst. Es wird auch auf Probleme hingewiesen, die bei der Anwendung auftreten können. 7.1 Pflege der Customizing Tabellen Die Customizing Tabellen können über die Transaktion WE30 gepflegt werden. Die Abb. 7.1 zeigt wie eine gepflegte Tabelle zu dem Selektionsbild aussehen kann. In diesem Fall wird beispielsweise das Selektionsbild zu einem IDoc mit Materialstammdaten 2 zusätzliche Selektionsoptionen haben. Abbildung 7.1. Pflege der Customizing Tabelle zum Selektionsbild Um die Funktionen in der Customizing Tabelle zu pflegen ist zum Teil ein etwas größerer Aufwand notwendig. So muss um das logische Löschen zu für einen IDoc-Typ zu aktivieren lediglich der Funktionscode F DEL und eine Statusnummer eingetragen werden. Die Statusnummer wird geplegt um die Fuktion flexibler zu halten. Denn so funktioniert die Funktion auch, wenn sich die Statusnummer ändern oder in einem anderen SAP-System unterschiedlich sind. Um für den IDoc-Typ MATMAS01 den Sprung in die Materialdaten zu aktivieren, muss zum FunktionscodeF BEL die Transaktion MM03, der Parameter MAT, die Tabelle E1MARAM, das Feld MATNR und die Feldposition 2 eingetragen werden. Dadurch wird beim anklicken der Funktion der Parameter MAT mit dem Wert

49 7.1 Pflege der Customizing Tabellen 42 des Feldes MATNR aus dem Segment E1MARAM gefüllt und die Transaktion MM03 aufgerufen. Analog dazu können zu allen IDoc-Typen Absprung- Funktionen belegt werden. Die Funktionen zum Aktuallisieren und Verarbeiten im Hintergrund werden durch das Eintragen der Funktionscodes F REF und F VER aktiviert. Um in die technische IDoc-Sicht springen zu können wird zu jeweiligen dem IDoc-Typ der Funktionscode F IDO mit dem Programmnamen RSEIDOC2 eingetragen. Dieses Programm wird dann mit der aktuellen IDoc- Nummer aufgerufen. Abbildung 7.2. Pflege der Customizing Tabelle zu den Funktionen Die Pflege der Customizing Tabelle für die änderbaren Felder ist relativ einfach gestaltet. In die Tabelle wird der IDoc-Typ, der Segmentname sowie der Feldname eingetragen(vgl. Abb. 7.3). Abbildung 7.3. Pflege der Customizing Tabelle zu den änderbaren Feldern Um die Ampelfarben dynamische zu steuern, wird eine weitere Customizing Tabelle gepflegt. Hier werden alle Statusnummern eingetragen, bei denen die Ampel nicht grau sein soll. Jedem Status können die Farben Rot (fehlerhaft abgeschlos-

50 7.2 IDoc zu Materialstammdaten 43 sen), Gelb (offen) oder Grün (erfolgreich abgeschlossen) zugeordnet werden. Abbildung 7.4. Pflege der Customizing Tabelle zum Status 7.2 IDoc zu Materialstammdaten Im Folgenden wird beschrieben, wie ein IDoc mit Materialstammdaten (MAT- MAS01) von dem IDoc-Monitor dargestellt und behandelt wird. Nachdem auf dem ersten Selektionsbild als IDoc-Typ MATMAS01 ausgewählt wurde (siehe Abb. 7.5, wird das zweite Selektionsbild aufgebaut. Abbildung 7.5. Selektionsbild - Materialstammdaten (Teil 1) Aufgrund der Daten in der Customizing Tabelle sind im Bereich IDoc-Daten der Materialkurztext und das Werk als zusätzliche Selektionsoptionen auswählbar. Wären keine Daten in der Customizing Tabelle zu dem Selektionsbild gepflegt, würde der Bereich IDoc-Daten komplett wegfallen (siehe Abb. 7.6).

51 7.2 IDoc zu Materialstammdaten 44 Abbildung 7.6. Selektionsbild - Materialstammdaten (Teil 2) Nachdem die IDocs nun selektiert wurden, wird das Übersichtsbild geöffnet (siehe Abb. 7.7). Am Anfang wird zu den IDocs, die Selektiert wurden jeweils der Kontrollsatz angezeigt und in der Baumstruktur sind lediglich die IDoc-Nummern zu sehen. Durch einen Doppelklick auf eine IDoc-Nummer (egal ob in der Baumstruktur oder in der ALV-List) werden nur noch die zugehörigen IDoc-Kontrolldaten angezeigt. Nun können die verschiedenen Transaktionen auf das IDoc angewendet werden. In der Baumstruktur lassen sich die Ordner der weiter öffnen und man sieht die IDoc-Sgmente. Durch einen Doppelklick auf eines der Segmente, werden alle Datensätze dieses Segmentes zum ausgewählten IDoc in der ALV-Liste agezeigt. Abbildung 7.7. Übersichtsbild - Materialstammdaten Durch Ausführen der Funktion Anzeige Beleg wird zu dem Material aus dem IDoc die Transaktion MM03 aufgerufen und es werden die Materialdaten angezeigt (siehe Abb. 7.8). Zusätzlich sind für diesen IDoc-Typ die Funktionen Aktuallisieren und IDoc löschen aktiviert.

52 7.3 IDoc zu Hauptbuchdaten 45 Abbildung 7.8. Anzeige der Materialdaten (Transaktion MM03) 7.3 IDoc zu Hauptbuchdaten Anhand einiger IDocs mit Hauptbuchdaten (FIDCMT01), sollen die Uterscheide und möglichekeiten des flexiblen IDoc-Monitors aufgezeigt werden. Auf dem ersten Teil des Selektionsbild wird nun FIDCMT01 als IDoc-Typ ausgewählt (siehe Abb. 7.9). Abbildung 7.9. Selektionsbild - Hauptbuchdaten (Teil 1) Im Folgenden wird das zweite Selektionsbild aufgebaut und hier zeigt sich der erste Unterscheid zu dem zweiten Selektionsbild des IDoc-Typs MATMAS01. In diesem Fall gibt es in dem Block IDoc-Daten mit der Belegnummer lediglich ein weiteres Selektionskriterium (siehe Abb. 7.10).

53 7.3 IDoc zu Hauptbuchdaten 46 Abbildung Selektionsbild - Hauptbuchdaten (Teil 2) Das Übersichtsbild (siehe Abb. 7.11) ist nun auf die Segmentdaten des IDoc- Typ FIDCMT01 angepasst. D.h. Die Struktur der ALV-Liste passt sich an die Segmentdaten des IDocs an und es ist nur noch eine Funktion ( Anzeige Beleg ) in der Drucktastenleiste sichtbar. Abbildung Übersichtsbild - Hauptbuchdaten Wenn die Funktion angeklickt wird, springt das Programm zur Transaktion FB03 (siehe Abb. 7.12). Diese Transaktion zeigt den Buchhaltungsbeleg zu dem IDoc an.

54 7.3 IDoc zu Hauptbuchdaten 47 Abbildung Anzeige der Belegdaten (Transaktion FB03)