Technischer Hintergrund

Dieses Kapitel richtet sich an Experten, die mehr über die technischen Hintergründe von enaio® data2ecm erfahren wollen, um z. B. neue Datenbeschaffungsklassen zu programmieren.

Module

Die Aufgabe Datenexport wurde in mehrere Teilprobleme zerlegt, die jeweils in eigenen Modulen realisiert werden. Ziel ist es, die einzelnen Module unabhängig voneinander zu programmieren und in den konkreten Projekten per Konfiguration zu einer Anwendung zusammenzuschalten.

Projektspezifische Anforderungen können durch Programmierung eigener Module realisiert werden.

Das konkrete Verhalten der Module kann durch Konfigurationseinstellungen beeinflusst werden.

Die nachfolgenden Abschnitte enthalten eine Beschreibung der unterschiedlichen Modulgruppen.

Datenbeschaffung

Das Modul zur Datenbeschaffung beschafft die Daten, die an enaio® zu übertragen sind. Es bekommt als Eingabedaten die Suchkriterien. Die gelesenen Daten werden in ein spezielles Objekt (siehe unten: Datenobjekt für interne Datenhaltung) geschrieben.

Das Datenbeschaffungsobjekt orientiert sich am Grundgedanken des Business Objekt. Es beschafft aber nicht unbedingt nur die Daten, die direkt zum Business-Objekt gehören, sondern kann auch zusätzliche Daten bereitstellen. Ein Beispiel wäre eine Rechnung, zu der nicht nur die eigentlichen Rechnungskopf- und Positionsdaten gesucht werden, sondern auch noch die Daten des Lieferanten (Anschrift, Telefonnummer, …).

Für die Vorgabe der Suchkriterien existieren zwei Möglichkeiten:

• Direkte Vorgabe der Suchfelder,

• Angabe einer DocID.

  Die Suchfelder werden dann gemäß des SAP®-Objektes und des Objectkeys zur DocID ermittelt.

Datenbeschaffungs-Module werden für die Standard-Aufgaben vorgefertigt, können aber auch im Rahmen eines Projektes neu geschrieben werden.

Datenobjekt für interne Datenhaltung

Die vom Datenbeschaffungs-Modul gelesenen Daten müssen über mehrere Module hinweg weitergereicht werden. Damit diese Aufgabe auf generische Weise unabhängig vom konkreten Projekt und den konkreten Daten realisiert werden kann, wird eine spezielle Darstellungsform verwendet, die durch das Modul für interne Datenhaltung realisiert wird. Dieses Modul ist ein Hilfsmodul, dessen Verwendung in anderen Modulen hart verdrahtet ist. Es kann daher nicht ersetzt werden.

Die Datenstruktur innerhalb des Moduls beruht auf einer Tabelle, die ein oder mehrere Datensätze aufnehmen kann.

Innerhalb der Datensätze werden Daten als Name-Wert-Paar gespeichert. Feldwerte werden daher immer in Form von Strings weitergereicht.

Die einzelnen Datensätze können neben den Werten der ersten Ebene auch eingebettete Tabellen enthalten. Diese werden beim Export nach enaio® in den Daten eines Tabellen-Controls abgelegt.

Das Objekt enthält mehrere Hilfsfunktionen zum Hinzufügen und Lesen von Werten.

Formatierung

Zwischen der Darstellung im SAP® und dem von enaio® benötigten Datenformat bestehen ggf. Unterschiede. Mitunter müssen SAP®-Feldwerte umgewandelt werden, um vom enaio® korrekt ausgewertet werden zu können.

Beispiele für derartige Umwandlungen sind:

• Hinzufügen oder Entfernen von führenden Nullen,

• Normalisierung von Telefonnummern,

• Entfernen von Sonderzeichen,

• Normalisieren von Zahlen.

Derartige Formatierungen werden durch eine Methode einer Klasse bereitgestellt. In der Konfiguration des enaio®-Projektes kann optional die Formatierungsklasse für ein Feld angegeben werden.

Eine Format-Methode erhält lediglich einen Feldwert als Eingabeparameter und liefert den formatierten Wert als String zurück.

Datenaufbereitung

Mitunter ist es in Projekten notwendig, die vom Datenbeschaffungsmodul gelieferten Daten zu modifizieren oder zu ergänzen. Dies könnte direkt in der Datenbeschaffung erfolgen. Um das Umprogrammieren der gesamten Datenbeschaffung zu vermeiden, können kleinere Ergänzungen und Modifikationen in separate Module verlagert werden.

Diese Module haben als Ein- und Ausgabeparameter lediglich das Objekt zur internen Datenhaltung. Sie können die enthaltenen Daten lesen und modifizieren.

Ein Beispiel für eine solche Datenaufbereitung ist das Hinzufügen des Namens eines enaio®-Schranks in Abhängigkeit von Feldwerten, z. B. dem Buchungskreis.

Da die Datenaufbereitung als Hilfsmittel für Projekte gedacht ist, existieren im Standard keine vorgefertigten Module.

Datenstruktur für Exportbausteine

Die gelesenen, formatierten und ggf. ergänzen Daten werden der Ausgabesteuerung übergeben. Diese überträgt einen Teil oder alle Daten in die Export-Datenstruktur. Dabei werden die bis hierher reinen SAP®-Daten mit enaio®-spezifischen Informationen ergänzt.

Die Export-Datenstruktur beruht auf einer Klasse, deren Verwendung in den diversen Bausteinen hart programmiert ist.

Die Aufbereitung findet in der Ausgabesteuerung statt, die konkrete physische Ausgabe in einem separaten Modul.

Ausgabesteuerung

Innerhalb der Ausgabesteuerung, die ausprogrammiert ist und nicht ersetzt werden kann, werden die SAP®-Daten mittels einer enaio®-bezogenen Konfiguration ausgewertet und in die Export-Datenstruktur übertragen.

Das enaio®-System weist ein eigenes Datenmodell auf, das durch die Begriffe Schrank, Ordner, Register und Dokument gekennzeichnet ist. Diese Elemente sind hierarchisch organisiert.

Die im SAP® ermittelten Daten liegen hingegen in einer flachen Struktur vor. Per Konfiguration muss daher festgelegt werden, wie die SAP®-Daten auf die enaio®-Elemente zu verteilen sind. Außerdem muss auf den bereits im enaio® vorhandenen Datenbestand reagiert werden. Je nach Szenario sind Einfüge- oder Modifikationsoperationen davon abhängig, ob das Zielobjekt im enaio® bereits existiert oder nicht. Auch über das Anlegen von Verweisdokumenten bzw. Verweiskopien entscheidet der im enaio® vorhandene Datenbestand. 

Die Ausgabesteuerung wertet die Konfiguration aus, fragt mit Hilfe des konkreten Ausgabemoduls enaio®-Daten ab und entscheidet auf Grund der Abfrageergebnisse über die konkreten Operationen.

Da nicht alle Ausgabemodule den Online-Zugriff auf ein enaio®-System ermöglichen, kann bei Einsatz dieser Module nicht der volle Funktionsumfang der Anwendung genutzt werden.

Physikalische Ausgabe

Die Kommunikation mit dem enaio®-System bzw. die Ausgabe der Daten kann mittels unterschiedlicher Mechanismen erfolgen.

Für die konkrete Ausgabe existiert jeweils eine konkrete Klasse, die aus der Ausgabesteuerung heraus angesprochen wird. Die Zuordnung erfolgt per Konfiguration, kann also geändert werden.

Im Moment werden folgende Ausgabemöglichkeiten unterstützt:

• Direkte Übertragung an enaio® über den Service 'dms'

• Ausgabe einer CSV-Datei,

• Ausgabe einer CSV-Datei mit erweitertem Header für enaio® classify,

• Ausgabe einer XML-Datei,

• Bildschirmausgabe (nur für Testzwecke).

Bei Bedarf können diese Ausgabeklassen erweitert bzw. komplett neu programmiert werden.

Zugriff auf den Service 'dms'

Der Service 'dms' unterstützt den vollen Funktionsumfang der Ausgabeschnittstelle. Über den Service 'dms' ist es möglich, enaio®-Objekte online anzulegen und zu modifizieren. Dazu erfolgt vor dem Schreibvorgang eine Abfrage auf die Existenz des Objektes. In der Konfiguration wird die Reaktion auf das Ergebnis des Suchvorgangs vorgegeben.

Neben dem Übertragen von Daten können Dokumentverknüpfungen angelegt werden. Dabei wird vorausgesetzt, dass in einem technischen Schrank SAP®-Dokumente archiviert wurden.

Ist dies der Fall, so kann über den Service 'dms' ein Verweis auf ein Dokument in einem technischen Schrank erstellt werden. Diese Dokumente im technischen Schrank dürfen aus nur einer Komponente bestehen, damit sie als Ziel eines Verweises dienen können.

Es können mehrere enaio®-Objekte bearbeitet werden, die aber in einer hierarchischen Beziehung zueinander stehen müsse. Es kann bei einem Aufruf jeweils ein Element einer Hierarchieebene angelegt werden.

Der Service 'dms' kann auch Daten für Tabellen übertragen.

Ausgabe in CSV-Datei

Mit diesem Ausgabemodul wird eine CSV-Datei geschrieben, in der Feldinhalte durch ein frei wählbares Trennzeichen voneinander getrennt werden.

Bei dieser Ausgabevariante ist keinerlei direkte Kommunikation mit dem enaio® server vorgesehen. Somit werden alle verfügbaren Daten ausgegeben. Die Entscheidung über Update oder Insert eines enaio®-Objektes kann dann erst beim eigentlichen Import getroffen werden.

Die CSV-Datei besitzt eine Kopfzeile mit den Namen der ausgegebenen Felder.

Prinzip bedingt können keine Daten für Tabellen-Controls ausgegeben werden.

Auch wenn in der Konfiguration mehrere enaio®-Elemente enthalten sind, entsteht nur eine Ausgabezeile, in der die Daten aller enaio®-Elemente einer Ausgabeoperation enthalten sind.

Ausgabe als Classify-Datei

Diese Variante ähnelt der Ausgabe in eine CSV-Datei. Der wesentliche Unterschied besteht in der Generierung eines ausführlichen Headers.

Ausgabe in XML-Datei

Die auszugebenden Daten werden als XML-Datei aufbereitet. Auch hier erfolgt die Umwandlung der Daten mehrerer enaio®-Objekte in eine flache Struktur.

Jeder Datensatz wird in ein <record>-Tag eingeschlossen. Innerhalb dieses Tags stehen Tags, deren Name dem Feldnamen entspricht. Für einfache Felder wird der auszugebende Wert als Text innerhalb der Feldnamen-Tags eingefügt. Daten für Tabellen-Controls (ebenfalls Feldnamen-Tags) werden zeilenweise in <line>-Tags eingeschlossen. Diese Tags stehen innerhalb des Feldnamen-Tags.

Der gesamte Inhalt der XML-Datei wird in ein <records>-Tag eingeschlossen.

Steuerprogramm

Der Grundgedanke der Lösung besteht darin, immer wiederkehrende Aufgaben in eigenständigen Modulen zu kapseln und diese je nach Projekterfordernissen zu einer Anwendung zu kombinieren.

Das Zusammenschalten der Module zu einer funktionsfähigen Anwendung erfolgt durch das Steuerprogramm. Dieses ermittelt die Gesamtmenge (IDs) der zu übertragenden Business Objects und ruft dann nacheinander die diversen Module auf, um die Daten komplett zu lesen und auszugeben.

Zunächst ist es möglich, dieses Programm komplett selbst zu programmieren. Dadurch kann auf alle Anforderungen des jeweiligen Projektes eingegangen werden.

Die Modularisierung und Standardisierung der Schnittstellen zwischen den Modulen bieten aber auch die Möglichkeit, generisch arbeitende Ausgabeprogramme zu erstellen. So existiert eine aus mehreren Klassen und Programmen bestehende Implementierung für ein generisches Steuerungsprogramm, das neben der Generik auch noch den Vorteil einer gesicherten Übertragung mittels des Queue-Konzeptes ermöglicht.

Ausgabe mit Queue

Eine Queue ist eine Warteschlange, in die die auszugebenden Elemente eingestellt werden. Für jedes Element werden Informationen gespeichert, mit denen die Ausgabe jederzeit durchgeführt werden kann. In der Queue werden Fehlerzustände bei der Ausgabe vermerkt, so dass später ein erneuter Ausgabeversuch gestartet werden kann.

Fehlerzustände sind nicht nur echte Übertragungsfehler. Auch die Datenbeschaffungsklassen können einen Fehler auslösen, der die Übertragung unterbricht. So prüfen einige Datenbeschaffungsklassen (z. B. die für FI-Rechnungen), ob der auszugebende Beleg schon fertig gebucht ist. Eine Übertragung wird erst dann gestattet, wenn die Daten vollständig sind.

Wird ein neuer Eintrag in die Queue aufgenommen, dann wird sofort der erste Export-Versuch gestartet. Verläuft dieser erfolgreich, dann wird das Element aus der Warteschlange gelöscht und dafür in eine Liste mit erfolgreich exportierten Elementen aufgenommen.

Ein periodisch einzuplanender Job durchläuft alle in der Queue enthaltenen Elemente.

Die gesamte Queue-Ausgabe besteht aus folgenden Elementen:

• Dictionary-Tabelle für Queue,

• Dictionary-Tabelle für erfolgreich exportierte Elemente,

• Klasse für Behandlung eines Queue-Eintrags,

• Klasse für generische Export-Schnittstelle,

• Job zur Abarbeitung der Elemente in der Queue,

• Anwendung zur Analyse der Queue (Transaktion /OSGMBH/DX_QADM).

Die generische Export-Schnittstelle bietet im Moment zwei Methoden zum Erstellen eines Queue-Eintrages an. Beide dienen zur Ausgabe von ArchiveLink-Dokumenten mit ihren Metadaten.

Während bei der ersten Methode eine ArchiveLink-DocID übergeben wird, um ein einzelnes Dokument zu identifizieren, exportiert die zweite alle Dokumente einer vorgegebenen Dokumentart, die zu einem ebenfalls anzugebenden Business Object gehören.