Rapid Prototyping von Logistik-Anwendungen mit 4D und deren szenario-basierte Integration

Transkript

1 Forschungs- und Entwicklungsprojekt Thema: Rapid Prototyping von Logistik-Anwendungen mit 4D und deren szenario-basierte Integration Webservice-basierte Interoperation eines Demo WMS und ERP-Systems An der Fachhochschule Dortmund im Fachbereich Informatik Studiengang Informatik durchgeführt am Fraunhofer-Institut für Software- und Systemtechnik (ISST) Abteilung IT in der Logistik (ITL) von Andreas Beckers geboren am Matrikelnummer und Stefan de Bucourt geboren am Matrikelnummer Betreuer: Prof. Dr. Martin Hirsch Dipl. Inform. Norbert Weißenberg Dortmund, 24. Februar 2012

2

3 Eidesstattliche Erklärung Gemäß 16 (5) der MPO versichere ich an Eides statt, dass ich die vorliegende Arbeit selbständig angefertigt habe. Ich habe mich keiner fremden Hilfe bedient und keine anderen, als die angegebenen Quellen und Hilfsmittel benutzt. Alle Stellen, die wörtlich oder sinngemäß veröffentlichten oder nicht veröffentlichten Schriften und anderen Quellen entnommen sind, habe ich als solche kenntlich gemacht. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Dortmund, 24. Februar 2012 (Andreas Beckers) (Stefan de Bucourt) Mir ist bekannt, dass nach 156 StGB bzw. 163 StGB eine falsche Versicherung an Eides Statt bzw. eine fahrlässige falsche Versicherung an Eides Statt mit Freiheitsstrafe bis zu drei Jahren bzw. bis zu einem Jahr oder mit Geldstrafe bestraft werden kann. Dortmund, 24. Februar 2012 (Andreas Beckers) (Stefan de Bucourt) III

4 Kurzfassung Diese Projektarbeit befasst sich mit der Konzeption und Umsetzung eines Webservicebasierten Szenarios für die Kommunikation zweier Logistikanwendungen. Dazu wird beschrieben, wie ein Demo-Warehouse Management System sowie ein Demo-Enterprise Resource Planning System mit dem Entwicklungswerkzeug 4D erstellt wurden. Außerdem wird beschrieben, wie mit diesem Tool ein logistisches Szenario umgesetzt wurde. Das Logistik-Szenario umfasst eine Lieferankündigung (Avis), die vom Hersteller Digital Media Devices (DMD) an den Kontraktlogistiker Spedition Hurz versendet wird. Wenn die Ware eingetroffen und verarbeitet wurde, wird der Hersteller über diesen Liefereingang benachrichtigt. In diesem Szenario ist es außerdem auch vorgesehen, dass Korrekturen an der Lieferankündigung vorgenommen werden können. Zusätzlich zu diesen Kommunikationsabläufen werden in dieser Arbeit auch beispielhaft einige interne Abläufe der Demo-Logistikanwendungen konzipiert und realisiert. Das ist zum Beispiel die Auftragserstellung im ERP-System oder die Vereinnahmung und Einlagerung im Warehouse Management System. Ein besonderer Aspekt dieser Arbeit ist, dass das Austauschformat, das zur Kommunikation zwischen diesen Demonstratoren verwendet wird, OAGIS-nah entwickelt und eingesetzt wurde. Dazu werden zum Einen Grundlagen von OAGIS aufgezeigt und zum Anderen die Konzeption und Umsetzung der OAGIS-nahen Nachrichten für das Szenario beschrieben. IV

5 Inhaltsverzeichnis Eidesstattliche Erklärung Kurzfassung III IV 1. Einleitung Motivation und Ziele der Arbeit Abgrenzung Aufbau der Arbeit Grundlagen Entwicklungsumgebung 4D Das 4D-Plugin Lightning XML Extensible Markup Language Aufbau XSD XML Schema Definition Lightening und Flattening Webservices SOAP-Webservices Webservice Description Language (WSDL) SOAP REST-Webservices OAGIS Open Application Group Integration Specification ERP Enterprise Resource Planning WMS Warehouse Management System Szenario Ausgangslage Kommunikationsablauf Konzept der Anwendungen Kommunikation OAGIS-nahe Nachrichten Nomen Verben Business Object Documents V

6 Inhaltsverzeichnis Komplette Struktur der BODs Kommunikationsablauf mit BODs Synchronisation der Artikelstammdaten Synchronisation mit vorhandenen BODs Eigene Serviceschnittstelle Abgleich und Pflege von Hand MyERP Unterstützte Abläufe Einlagerungsauftrag erstellen Rückmeldung bearbeiten Korrekturauftrag erstellen Auftrag bezahlen Buchhaltung Benutzerrollen Datenmodell Erläuterung der Tabellen Zusammenfassung der Rechte Benutzeroberfläche Anlegen eines Auftrags Anlegen eines Korrekturauftrages MyInventory Szenario Avis anlegen Lieferung eintragen Wareneingang eröffnen Vereinnahmung durchführen Wareneingang abschließen Einlagerung Avis korrigieren Datenmodell Benutzerschnittstelle Realisierung Entwicklungsumgebung und Betrieb Installation 4D Installation des Lightning-Plugins Business Object Documents (BODs) MyERP Datenbank D als Datenbankmanagementsystem (DBMS) Abweichungen vom Konzept VI

7 Inhaltsverzeichnis Grafische Benutzeroberfläche mit Lightning Oberfläche mit 4D Aufbau der Seite Lightning-Formulare Benutzerverwaltung Logbuch Der Auftragsstatus Wichtige Funktionen Avis erstellen und versenden order_send Auftrag freigeben order_giveclearance Auftrag abschließen order_complete Nutzer ermitteln getcurrentuser BOD versenden BOD_send Avis erstellen BOD_createProcessShipment Angebotener Service _service_notifyreceivedelivery Lieferbenachrichtigung validieren BOD_eval_NRD Auf Lieferbenachrichtigung reagieren order_processnrd Umsetzung der Nutzeraktivitäten Einlagerungsauftrag erstellen Korrekturauftrag erstellen Auftrag bezahlen MyInventory Datenbankaufbau Logging-Tabelle nach Log4J Tabelle Dashboard für die Weboberfläche Weboberfläche mit Lightning Benutzerverwaltung, Rollen und Rechte Umsetzung der Benutzerschnittstelle Übersichtsseite Lieferung eingeben Wareneingang eröffnen Vereinnahmung durchführen Wareneingang abschließen Einlagerung Logging Umsetzung der Service-Schnittstelle Service-Anbieter - Avis anlegen Service-Anbieter - Avis korrigieren Service-Konsument - Lieferbenachrichtigung versenden VII

8 Inhaltsverzeichnis 6. Test MyERP White-Box-Test Administration der Datenbank Test der Serviceschnittstelle Testmöglichkeiten in Lightning MyInventory White-Box-Test Anlegen eines Avis Ändern eines Avis Lieferbenachrichtigung Szenario - Black-Box-Test Fazit Zusammenfassung der Ergebnisse Kritische Betrachtung der Arbeit Ausblick Szenario MyERP MyInventory Abbildungsverzeichnis 138 Tabellenverzeichnis 139 Quellcodeverzeichnis 142 Literaturverzeichnis 146 Glossar 149 A. Anhang 151 A.1. MyERP A.2. MyInventory A.3. Metriken A.4. Entwicklungsumgebung und Betrieb A.5. XML A.6. Testprotokolle VIII

9 1. Einleitung Die Firma Gartner für Marktforschung und Analyse in der Informationstechnik erklärt Cloud-Computing zu einem der aufstrebendsten Begriffe der heutigen Zeit (vgl. [Gar11]). Immer komplexer werdende Systeme haben einen Bedarf an schneller Hardware und hoher Skalierbarkeit. Dabei wird es immer aufwendiger, diese Systeme zu administrieren und zu warten. Aus diesem Grund beschäftigen sich auch große Unternehmen wie Amazon, Google und Microsoft immer mehr mit dem Thema Cloud-Computing. Beim Cloud Computing (speziell in Public Clouds) können Infrastrukturen (Infrastructure-as-a-Service (IaaS)), Entwicklungsumgebungen (Platform-as-a-Service (PaaS)) und Anwendungen (Software-as-a-Service (SaaS)) für die eigenen Ansprüche gemietet werden (vgl. [RM11, S. 15 f.]). Der Kunde selbst bekommt dabei einen Zugang, zum Beispiel über den Webbrowser, zu den Systemen der Cloud-Computing-Anbieter, auf denen dann die gewünschten Dienste ausgeführt werden können. Durch diesen Ansatz hat der Kunde die komplette Administration der zugrunde liegenden Hardware-Infrastrukur (IaaS) beziehungsweise der Entwicklungsumgebung (PaaS) oder Anwendungen (SaaS) ausgelagert und muss sich nicht selbst darum kümmern. Ein großer Vorteil daran ist die Skalierbarkeit, die durch einen Vertrag (Service-Level-Agreement, SLA) festgelegt wird. Darin wird unter anderem festgelegt, wie viel Rechenleistung bei Auslastungsspitzen maximal zur Verfügung gestellt wird. Die Abrechnung der Leistungen erfolgt bedarfsgerecht. Nur die Leistung, die tatsächlich in Anspruch genommen wurde, wird in Rechnung gestellt (vgl. [Man10]). Aus diesen Gründen beschäftigen sich auch die Fraunhofer-Institute für Software- und Systemtechnik (ISST) und Materialfluss und Logistik (IML) mit diesem Thema. Sie wollen eine innovative Cloud-Computing-Infrastruktur für die Logistik nutzbar machen. Mit der Logistics Mall sollen logistische IT-Anwendungen angeboten, gemietet und schließlich auch ausgeführt werden können (vgl. [Fra12]). Eine große Herausforderung für diesen hochtechnologisierten Marktplatz ist die Kommunikation der Anwendungen innerhalb der Cloud. So gibt es unterschiedlichste Dienste unterschiedlicher Anbieter, die innerhalb des Supply-Chain-Managements der Logistik miteinander verzahnt sind. Ein solches Cloud- Computing-System durchlebt einen langwierigen Entwicklungsprozess. Damit Interessenten und Investoren eine genauere Vorstellung davon bekommen, soll diese Projektarbeit weiter helfen. Es sollen Demonstratoren von Logistikanwendungen entstehen, die miteinander, auf möglichst standardisiertem Wege, kommunizieren. Diese Demosysteme stellen 1

10 1. Einleitung Services beziehungsweise Anwendungen in der Cloud der Logistics Mall dar, die ein Anbieter im Sinne von IaaS und PaaS eingestellt hat die Logistics Mall ist Entwicklungsumgebung und Hardwareinfrastruktur in einem und Kunden als SaaS-Anwendungen nutzen Motivation und Ziele der Arbeit von Stefan de Bucourt In der Logistics Mall bieten externe Entwickler ihre Software an und werden dann als Service oder Anwendung den Kunden zur Verfügung gestellt (SaaS). Die Entwicklung dieser Software gehört jedoch nicht zu den Aufgaben des ISSTs. Trotzdem ist es wünschenswert, die Fähigkeiten der Logistics Mall mit einigen Demonstrationsanwendungen zeigen zu können. Diese müssen nicht ausgereift sein, sondern sollen lediglich einen Eindruck davon vermitteln, was mit der Logistics Mall als Plattform möglich ist. Bei diesen Anwendungen handelt es sich um Demonstratoren, die mit vertretbarem Aufwand entwickelt werden müssen. Dazu wurde unter mehreren zur Auswahl stehenden Werkzeugen eines ausgesucht, welches eine schnelle Anwendungsentwicklung, ähnlich dem Rapid Application Developement, zulässt. Durch dieses Werkzeug soll der Aufwand für die Entwicklung, aber auch für Konfiguration und Betrieb der Anwendungen, gering gehalten werden. Vom Fraunhofer ISST wurde die Entwicklungsumgebung 4D der französischen Firma 4D SA ausgesucht (s. [4D 12a]). Da das Fraunhofer ISST über wenig vorherige Erfahrungen mit dieser Umgebung verfügt, wurde beschlossen, mit der Umsetzung eines Logistik- Szenarios weitere Erfahrungen zu sammeln. In diesem Szenario nutzt ein Gerätehersteller ein Enterprise-Resource-Planning-System in der Logistics Mall, um Einlagerungsaufträge an seinen Kontraktlogistiker zu versenden, dessen Warehouse-Management-System ebenfalls in der Logistics Mall zur Verfügung gestellt wird. Diese beiden Demo-Systeme sollen mit 4D erstellt werden und über das Internet miteinander kommunizieren, wobei sich die Kommunikation über Webservices an dem existierenden OAGIS-Standard orientieren soll, welcher als Kommunikationsstandard für die Logistics Mall vom Fraunhofer ISST und IML ausgewählt wurde. Die Kommunikation zwischen den Anwendungen steht dabei im Vordergrund, da die Realisierbarkeit einer solchen Kommunikation eine zwingende Voraussetzung für den Einsatz von 4D zum Erstellen von in der Logistics Mall lauffähigen Demoanwendungen darstellt. Neben der technischen Machbarkeit dieser Kommunikation mittels OAGIS und der Demonstrationssysteme selbst ist auch die detaillierte Entwicklungserfahrung mit 4D für das ISST ein wesentliches Ziel dieser Arbeit. Da die Anwendungen Cloud-geeignet sein sollen, wurde des Weiteren ein 4D-Plugin ausgewählt, mit der die Benutzeroberfläche webbasiert gestaltet werden kann. Auch die Mach- 2

11 1.2. Abgrenzung barkeit eines Web-Frontend sowie detaillierte Erfahrungen mit diesem Plugin sind wichtige Ziele der Arbeit Abgrenzung von Stefan de Bucourt Die beiden zu implementierenden Systeme dienen ausschließlich zur Demonstration möglicher Logistikanwendungen, wie sie in der Logistics Mall verfügbar gemacht werden sollen. Daher ist es nicht sinnvoll, vollständige Systeme für Warehouse Management und Enterprise Resource Planning zu erstellen: Bei einer explorativen Studie unter 27 ERP- Systemherstellen schätzten drei von vier Herstellern ihre Entwicklungszeiten zwischen 20 und 150 Mannjahren ein (vgl. [WKV07, S. 7]). Selbst das untere Ende dieser Schätzung für ein vollständiges System ist jenseits dessen, was für ein Demonstrationssystem aufgewendet werden kann. Auch wenn es wünschenswert ist, einige typische Aspekte solcher Systeme aufzugreifen, soll dies ausschließlich in Ansätzen geschehen. Denn ein vollständiger, korrekter Ablauf aller logistisch relevanten Vorgänge, die reale Systeme unterstützten müssen, ist im Rahmen dieser Arbeit weder realisierbar noch zweckmäßig. Es ist außerdem nicht zweckmäßig, die Demonstrationsanwendungen auf hohe Nutzerzahlen, viele Anfragen oder hohe Datenbestände auszulegen. Die Anwendungen werden, ihrem Zweck entsprechend, nicht in einem Kontext genutzt, wo diese Ansprüche zu erwarten sind Aufbau der Arbeit von Andreas Beckers Diese Arbeit beginnt mit einem Grundlagenkapitel über die wichtigsten Technologien, die zur Durchführung eingesetzt wurden. Dazu gehört ein Abschnitt über das Hauptentwicklunsgwerkzeug 4D sowie ein Abschnitt über die Extensible Markup Language (XML), mit der die Nachrichten aufgebaut sind, die zwischen den Demosystemen ausgetauscht werden. Des Weiteren wird erläutert, worum es sich bei Webservices handelt, die die Schnittstellen der Systeme darstellen. Anschließend wird erläutert, was der Business-Standard OAGIS ist und wie dieser aufgebaut ist. Zum Schluss dieses Kapitels werden die Grundzüge von Enterprise-Resource-Planning- und Warehouse-Management-Systemen dargelegt. Im darauf folgenden Kapitel 3 werden die genauen Abläufe des Szenarios beschrieben. Es wird darauf eingegangen, welches System welche Nachrichten versendet, welche Bedeutung diese Nachrichten haben und wie jeweils darauf reagiert wird. 3

12 1. Einleitung Nachdem das Szenario erläutert wurde, wird die Konzeption dieser Kommunikationsabläufe in Kapitel 4 dargelegt. Es wird beschrieben, wie die einzelnen Nachrichten OAGIS-nah aufgebaut sind und wie das entsprechende Szenario mit diesen konzipierten Nachrichten abläuft. In einem separaten Abschnitt wird als wichtiges Teilproblem des Datenaustauschs auf die Synchronisation der Stammdatensätze zwischen den Demoanwendungen eingegangen. Außerdem werden in diesem Kapitel die Konzeptionen der internen Abläufe der beiden Demosysteme, sowie der Aufbau der dafür benötigten Persistenzschicht getrennt erläutert. Auch auf die Benutzeroberfläche, zur Ausführung des Szenarios der jeweiligen Anwendungen, wird näher eingegangen. Die auf dem Konzept basierte Realisierung des Szenarios wird im Kapitel 5 beschrieben. Dazu wird zuerst erläutert, wie genau die Entwicklungsumgebung 4D eingerichtet wurde. Anschließend wird beschrieben, wie die OAGIS-nahen Nachrichten entwickelt wurden. Die beiden dann folgenden Abschnitte widmen sich der Realisierung der jeweiligen Demoanwendungen MyERP und MyInventory. Darin wird jeweils erläutert, wie die internen Abläufe implementiert und wie die Webservice-Schnittstellen für die Kommunikationsabläufe realisiert wurden. Auch auf die Umsetzung der Benutzeroberflächen wird näher eingegangen. Anschließend wird in Kapitel 6 beschrieben, mit welchen Methoden die jeweiligen Demosysteme und das komplette Szenario getestet wurde. Darauf folgt zum Schluss schließlich noch die Zusammenfassung der Ergebnisse sowie dessen kritische Betrachtung im Fazit zur Eignung von 4D. Da diese Arbeit von zwei Personen zusammen erstellt wurde, wird zu Beginn der jeweiligen Kapitel beziehungsweise Abschnitte der Name des Autors erwähnt, der dann auch für alle Unterabschnitte darin gilt. Dies bedeutet allerdings nicht, dass diese Teile der Arbeit ausschließlich von dieser Person erstellt wurden, sondern lediglich, dass dieser Teil von dieser Person niedergeschrieben wurde. Bis auf die internen Abläufe der einzelnen Demoanwendungen wurde der komplette Part der Kommunikation in Zusammenarbeit konzipiert und realisiert. 4

13 2. Grundlagen Die Entwicklungsumgebung 4D ermöglicht das schnelle Erstellen von Datenbankanwendungen. Dazu wird eine eigene prozedurale Programmiersprache genutzt, welche mit einer internen Datenbank arbeitet. Viele der üblichen Operationen zum Datenbankzugriff werden dabei automatisiert oder stark vereinfacht. Mit Hilfe der Extensible Markup Language und Schemadefinitionen lassen sich eigene, gut maschinenlesbare Textformate definieren. In einem solchen Format sind beispielsweise die Schnittstellendefinitionen von Webservices angegeben, so auch die in den Kapiteln 4 beschriebenen Schnittstellen von MyERP und MyInventory. Auch die Spezifikation der Open Application Group (OAGIS) ist in XML definiert. Dies ist ein internationaler Standard zum Datenaustausch zwischen verschiedenen Akteuren, wobei die Spezifikation individuellen Bedürfnissen entsprechend erweitert werden kann. Die Kommunikation der Demoanwendungen ist stark an OAGIS angelehnt, wie in Abschnitt beschrieben. Ein System zum Enterprise Resource Planning ermöglicht im Idealfall das Abbilden sämtlicher Geschäftvorfalle eines Unternehmens. Eines der bekanntesten dieser Systeme ist das deutsche SAP ERP (früher SAP R/3) Entwicklungsumgebung 4D von Stefan de Bucourt Im Jahre 1984 begann die Entwicklung eines RDBMS (Relationales Datenbankmanagementsystem), aus welchem 4D hervorging. Im nächsten Jahr folgte der erste grafische Editor für ein Datenbanksystem [4D 12c]. Seitdem ist 4D gewachsen und beinhaltet nun neben der Datenbank eine eigene Programmiersprache mit umfangreicher Bibliothek und einen eigenen Webserver. Eine mit 4D entwickelte Anwendung kann dabei auf mehrere Arten eingesetzt werden. So ist es möglich, die Anwendung nur im interpretierten Modus laufen zu lassen, was ohne starke Typprüfungen auskommt. Es ist allerdings jederzeit möglich die Anwendung zu kompilieren und damit eine ausführbare Binärdatei zu enthalten. Diese lässt sich sowohl für Windows- als auch Mac-Systeme einsetzten, ohne das sich in der Anwendung etwas für den Nutzer ändert. Weiterhin ist es möglich, aus einer entworfenen Anwendung ohne Änderungen des Quellcodes ein Client/Server-System zu generieren. Hierbei müssen sich 5

14 2. Grundlagen die Clients dann an dem Server anmelden und können von diesem direkt mit Updates versorgt werden. In allen Varianten steht jeweils der volle Umfang der Sprache zur Verfügung. Einzige Ausnahme sind hier kleine Änderungen zwischen interpretierem und compilierten Modus. Da 4D sowohl eine eigene Sprache als auch eine Datenbank umfasst sind beide stark aneinander gekoppelt. So lässt sich im Quellcode unkompliziert auf Tabellen zugreifen, und die Sprache verwaltet automatisch eine aktuelle Auswahl jeder einzelnen Tabelle. So ist es möglich, dass beim Laden eines Tabellentupels alle davon referenzierten Tupel automatisch selektiert werden. Diese starke Kopplung findet sich ebenfalls beim GUI-Editor. So kann ein Wizard aus jeder Datenbanktabelle mit wenigen Einstellungen funktionsfähige Ein- und Ausgabemasken generieren, in welchen direkt auf die Einhaltung von Datenbankconstraints wie, keine Nullwerte oder die Wahrung der referentiellen Integrität, geachtet wird. Zu den Besonderheiten der Sprache gehört ebenfalls die Möglichkeit, in Bezeichnern neben Umlauten ebenfalls Leerzeichen zuzulassen. So ist Meine erste Funktion in 4D ein valider Name. Diese Regel trifft neben Funktions- auch auf Variablen, Tabellen- und Feldbezeichner zu. Außerdem ist in 4D eine Benutzerverwaltung integriert. Nutzer werden hierbei über einen im System eindeutigen Namen gekenntzeichnet, und die Authentisierung erfolgt über ein Passwort. Dazu gibt es die Möglichkeit, Gruppen zu erstellen, und sowohl Gruppen als auch Nutzer als Mitglieder von Gruppen zu markieren. Durch diese Gruppen ist es in 4D möglich, ein System für mehrere Sichten zu erstellen, indem beispielsweise Zugriffsund Schreibrechte auf Daten auf bestimmte Gruppen beschränkt sind. Fest vorgegeben ist der Nutzer Designer welcher vollen Zugriff auf die Datenbank hat und den Zugang für Entwickler darstellt Das 4D-Plugin Lightning von Stefan de Bucourt Seit 1997 ist in 4D ein Webserver integriert. Dieser kann HTML-Seiten darstellen, die dynamisch generiert und mit 4D-HTML-Tags versehen werden können. Um die Erstellung der Weboberflächen zu vereinfachen, wurde von Graham Langley das Plugin Lightning entwickelt. Dieses hat Zugriff auf die 4D-Datenbank, und sämtliche in 4D geschriebenen Funktionen können für den Aufruf aus Lightning heraus freigeschaltet werden. Eine Unterstützung von mobilen Geräten ist für die nächste Lightning-Version ebenfalls geplant. Das Plugin kann über die Webseite des Entwicklers erworben werden: 6

15 2.3. XML Extensible Markup Language Lightning hat es sich dabei zum Ziel gemacht, die Entwicklung einer Weboberfläche für 4D-Anwendungen zu vereinfachen. So gibt es direkt nach der Installation eine Anmeldemaske für die Anwendung, welche auf die in 4D eingerichteten Nutzer zugreift. Darüber hinaus ist es durch einige spezifische Lightning-Tags einfach, aus einer HTML-Seite heraus auf die 4D-Datenbank zuzugreifen. Auch einige typische Funktionen des GUI-Editors von 4D werden aufgegriffen, so werden zum Beispiel bei der partiellen Eingabe eines Fremdschlüssel automatisch alle vorhandenen angezeigt, die nach der bisherigen Eingabe in Frage kommen XML Extensible Markup Language von Stefan de Bucourt Die um eigene Dialekte erweiterbare Auszeichnungssprache XML (von engl. Extensible Markup Language ) dient der strukturierten Darstellung von Daten. Dabei muss eine Textdatei nur wenigen Syntaxregeln genügen, um eine wohlgeformte (engl. well formed ) XML-Datei zu sein. Diese Regeln können mit Schemadefinitionen erweitert werden, um so einen eigenen XML-Dialekt zu erstellen. Genügt eine XML-Datei den strukturellen Anforderungen des angegebenen Schemas, so ist sie valide (engl. valid ). Dabei soll eine XML-Datei zum einen für Menschen verständlich bleiben und zum anderen gut von einem Programm geparst werden können [Bal07, S. 12 ff.]. Ein Beispiel für eine einfache, vollständige XML-Datei ist Quellcode <?xml version="1.0" encoding="utf 8"?> 2 <item> 3 <gtin> </gtin> 4 <description>ein Testartikel</description> 5 <height>10</height> 6 <width>20</width> 7 <depth unit="mm">30</depth> 8 <active /> 9 </item> Quellcode 2.1: Eine einfache, vollständige XML-Datei, die einen Artikel beschreibt Aufbau Unterschieden werden in XML die Elemente, sogenannte Tags (Auszeichnungen), und ihr Inhalt, welcher von einem öffnenden und einem schließenden Tag begrenzt wird. Dabei können sowohl die Elementnamen als auch der Inhalt selbst Unicode-Text sein, wenn dies 7

16 2. Grundlagen nicht anders spezifiziert wird. Diese Tags werden in spitze Klammern gesetzt, um die Unterscheidung vom Inhalt zu ermöglichen. 1 Ein XML-Dokument ist dabei immer in der Form eines Baumes strukturiert. Dieser beginnt mit einem zwingend vorhandenen, eindeutigen Wurzelelement, welches selbst wieder Elemente enthalten kann. Jedes Element kann einfach oder strukturiert sein. Einfache Elemente enthalten höchstens Text, strukturierte Elemente können selbst Elemente enthalten. Eine wichtige Bedingung für die Wohlgeformtheit ist, dass jedes Element sowohl einen öffnenden als auch einen schließenden Tag hat: auf ein öffnendes <einelement> muss also immer ein schließendes </einelement> folgen. Enthält ein Element keinen Inhalt, so kann dieses als leeres Element direkt in einer Sonderform angegeben werden, indem ein Schrägstrich am Ende des Elementnamens folgt: <leereselement />. Jedem Element können im öffnenden Tag beliebig viele Attribute zugewiesen werden, welche immer einen, im Element eindeutigen, Namen haben und einen Wert in Anführungszeichen zugewiesen bekommen müssen, wie im Beispiel 2.1 in Zeile 7 der Wert mm des Attributes unit. Jede XML-Datei beginnt mit der XML-Deklaration <?xml..?>, wobei das Attribut encoding angibt, in welchem Zeichensatz die Datei kodiert wurde, was in den selbst erstellten Dateien dieses Projektes immer UTF-8 ist. Ein weiteres mögliches Attribut ist die Angabe der verwendeten XML-Version, wobei hier version="1.0" als Standardeinstellung meist übernommen werden kann. Kein anderer Elementbezeichner darf mit der Zeichenfolge xml beginnen oder eines der Sonderzeichen enthalten, wie beispielsweise spitze Klammern. Sind in einer Datei XML-Deklaration und das Wurzelelement vorhanden, hat jedes Element einen schließenden Tag und sind im Inhalt alle Sonderzeichen maskiert, so handelt es sich um ein wohlgeformtes (engl. well formed ) XML-Dokument. Im obigen Beispiel 2.1 sind in der XML-Deklaration in Zeile 1 die beiden Attribute version und encoding gesetzt, wobei die hier gewählten Werte den Standardeinstellungen entsprechen. Das <item> (Zeile 2) ist hier das strukturierte Wurzelelement des XML-Baumes, in welchem sich die anderen Elemente <gtin>, <description> bis <active /> der Zeilen 3 bis 8 befinden. Das einfache Element gtin (Zeile 3) besitzt den Inhalt , das einfache Element <depth> in Zeile 7 das Attribut unit mit dem Wert mm. Das Element active ist ein Beispiel für ein leeres Element XSD XML Schema Definition Ein wohlgeformtes XML-Dokument muss zwar einigen Ansprüchen genügen, jedoch ist die Abfolge der Elemente und Attribute nicht festgelegt. Um weitere Ansprüche an den Inhalt eines Dokumentes stellen zu können gibt es mehrere Möglichkeiten: Eine Variante ist die Document Type Definition (DTD), also Dokumententypdefinition. Eine neuere Variante, 1 Sollen im Inhalt spitze Klammern oder einige andere Sonderzeichen enthalten sein, so müssen diese maskiert werden. Spitze Klammern lassen sich durch < bzw. > maskieren, für weitere Informationen siehe [Bal07], Seite 155, Markup-Zeichen. 8

17 2.3. XML Extensible Markup Language doe XML-basierte Schemadefinition (engl. XML Schema Definition, XSD), bietet jedoch mehr Möglichkeiten und wird hier ausschließlich behandelt. Die Grundzüge von XSDs werden im Folgenden beschrieben, während Informationen zu DTDs sich beispielsweise bei [bit10] finden lassen. In einer Schemadefinition, welche stets selbst ein valides XML-Dokument ist, können eigene Typen von Elementen bestimmt werden. Dabei sind sowohl einfache als auch strukturierte Typen möglich. So muss das Wurzelelement definiert und ihm ein Typ zugewiesen werden. Dieser kann als strukturierter Typ definiert werden, welcher wiederum aus mehreren Elementen anderer Typen besteht. Zusammen mit der Möglichkeit, vorhandene Typen einzuschränken, zu erweitern und zu kombinieren können so komplexe Strukturen aufgebaut werden. Beispiel 2.2 zeigt die Definition des in Beispiel 2.1 verwendeten Elementes item in Zeile 1, sowie Auszüge der Definition des zugehörigen Types ItemType. Die verwendeten Namen der Typen, die jeweiligen Elementennamen gefolgt von Type, entsprechen dabei einer typischen Konvention, sind jedoch nicht verpflichtend. 1 <xs:element name="item" type="itemtype" /> 2 <xs:complextype name="itemtype"> 3 <xs:sequence> 4 <xs:element name="gtin" type="xs:string" /> <xs:element name="depth" type="depthtype" /> 7 <xs:element name="active" type="activetype" minoccurs="0"/> 8 </xs:sequence> 9 </xs:complextype> Quellcode 2.2: Ausschnitt einer XSD-Datei Soll ein Dokument gegen eine Schemadefinition validiert werden, so muss diese Definition angegeben werden. Dies geschieht im Wurzelelement durch die Angabe des Attributs xsi:schemalocation, wie in Beispiel 2.3 in Zeile 4-5 zu sehen ist. Die zweite und dritte Zeile legen den Namensraum des Wurzelelementes fest. Der Namensraum wird dabei, ähnlich wie in einigen Programmiersprachen (C, C++), genutzt, um verschiedene Elemente mit gleichem Namen in verschiedenen Kontexten zu erlauben und diese gegebenfalls eindeutig ansprechbar in einer Datei verwenden zu können. 1 <TestWurzelElement 2 xmlns=" 3 xmlns:xsi=" instance" 4 xsi:schemalocation=" 5 Quellcode 2.3: Angabe von Namensraum und Schema in einem XML- Wurzelelement 9

18 2. Grundlagen Lightening und Flattening von Andreas Beckers Unter Lightening und Flattening versteht man das Schmälern und Konsolidieren von XML- Schemadefinitionen. Das Lightening bezieht sich hierbei auf das Schmälern selbst. Hierbei kann eine gegebene XML-Schema-Struktur anhand einer vorgegebenen XML-Instanz auf die Elemente und Attribute der Instanz eingestampft werden. Dies ist in Abbildung 2.1 veranschaulicht. Abbildung 2.1.: Lightening von XML-Schemadefinitionen (vgl. [Kie12]) Durchgeführt wird das Lightening durch einen XSLT-Prozessor und einer entsprechenden XSL-Lightener Implementierung. Als Input bekommt der Prozessor die zu schmälernde XSD-Struktur sowie die XML-Instanz, zu der die neue XSD-Struktur generiert werden soll. Als Output erhält man schließlich die neue XML-Schema Struktur, die nur die Elemente und Attribute enthält, die auch in der XML-Instanz vorhanden sind. Sinnvoll ist dies gerade bei sehr mächtigen XML-Schemata, aus denen lediglich Teilmengen für den eigenen Bedarf benötigt werden. Dies kann zum Beispiel bei OAGIS der Fall sein, deren XSD- Strukturen sehr mächtig sind und für viele verschiedenen Einsatzvarianten ausgelegt sind (siehe Kapitel 2.5). Der Vorteil dieser Technik ist nicht nur, dass die Schemata kleiner und überschaubarer werden, sondern auch, dass XML-Instanzen der neuen XSD-Strukturen nach wie vor valide gegenüber den unberührten XSD-Strukturen sind. Durch das sogenannte Flattening der Datenstrukturen kann eine modularisierte Struktur von vielen XSD-Dateien zu einer zusammengefassten Struktur umgewandelt werden. Dies wird in Abbildung 2.2 verdeutlicht. Funktional wird jedes Inkludieren von Schemadateien aufgelöst und in die Schemadatei direkt eingefügt. Dadurch erhält man für jeden vorkommenden Namespace genau eine Schemadefinitionsdatei. Das Ziel dahinter ist, dass möglichst wenige Dateien verwaltet 10

19 2.4. Webservices Abbildung 2.2.: Flattening von XML-Schemadefinitionen (vgl. [Kie12]) und veröffentlicht werden müssen, falls zum Beispiel ein Webservice bereitgestellt wird, der externe Schemadateien einbindet Webservices von Andreas Beckers Bei Webservices handelt es sich um modular gekapselte Dienste, die standardisiert mittels des Hypertext Transfer Protokolls (HTTP) über Netzwerke angeboten und aufgerufen werden können. Das Veröffentlichen geschieht dabei entweder über die Weitergabe der URL des Services an den entsprechenden Nutzer, oder aber durch Veröffentlichen in einen zentralen Verzeichnisdienst, wie zum Beispiel in ein UDDI-Repository (Universal Description, Discovery and Integration). Letztere Möglichkeit wurde aber von großen Unternehmen wie SAP, IBM und Microsoft zurückgezogen, da sie der Meinung sind, dass das Veröffentlichen eines Services in ein zentrales Verzeichnis nicht die Art ist, wie heutzutage Geschäfte gemacht werden (vgl. [Kri05]). Needless to say, this isn t how companies do business there s always a human element to establishing a relationship. As a result, the [UDDI Business Registry (UBR)] served as little more than an interoperability reference implementation. Now that UDDI has become more of a metadata management standard for SOA, there s little need for the UBR anymore. Jason Bloomberg [Kri05] Die veröffentlichten Dienste sind Schnittstellen des Systems, auf die weitere, verteilte Systeme Zugriff haben. Durch das Komponieren von Webservices (Orchestrierung) und durch geregelte Kommunikation zwischen mehreren Services (Choreographie) können komplexe Geschäftsprozesse abgebildet werden. Dabei gibt es verschiedene Möglichkeiten (Protokolle), diese Dienste bereitzustellen und aufzurufen. Dies ist zum Einen über SOAP möglich und wird im folgenden Kapitel erläutert. Die andere Möglichkeit bietet REST, das in Kapitel beschrieben wird. 11

20 2. Grundlagen SOAP-Webservices SOAP steht ursprünglich für Simple Object Access Protocol und bedeutete so viel wie Protokoll für einfachen Objektzugriff. Da SOAP allerdings gar nicht zum Zugriff auf Objekte geeignet ist und auch nicht einfach ist, wurde mit dem Erscheinen der Version 1.2 diese Abkürzung abgeschafft. SOAP ist somit ein Begriff für sich selbst (vgl. [Jos08, S. 268 f.]). SOAP ist die erste Möglichkeit zum Aufrufen eines Webservices und stellt eine Art des Datenaustauschs dar. Grundlegend dafür ist die WSDL-Datei, die die einzelnen Operationen des Services auflistet und beschreibt, welche Parameter und Rückgabewerte diese besitzen. In Kapitel wird auf den Aufbau der WSDL-Datei eingegangen. In Kapitel wird schließlich der Aufbau einer SOAP-Nachricht erläutert Webservice Description Language (WSDL) WSDL steht für Webservice Description Language und stellt die Beschreibungssprache für SOAP-Webservices dar. Mit ihr kann auf standardisiertem Wege die Schnittstelle zwischen Service-Anbieter und Konsument definiert werden. WSDL wird durch die Spezifikation des World Wide Web Consortium (W3C) definiert (vgl. [W3C01] und [W3C07]). Zurzeit existieren zwei wesentliche Versionen. Die am weitesten verbreitete und in diversen Werkzeugen und Technologien eingesetzte Version ist 1.1. Es gibt WSDL bereits in der Version 2.0. Diese verfügt über einige Verbesserungen und Erweiterungen, die in folgender Auflistung aufgeführt sind (vgl. [Dhe04]). Das Attribut targetnamespace in WSDL 2.0 ist jetzt ein Pflichtattribut im Wurzelelement definitions Das message-konstrukt wurde entfernt. In WSDL 2.0 wird direkt auf das Element types referenziert Operatorüberladung wird nicht mehr unterstützt PortTypes wurde umbenannt zu interfaces. Interface-Vererbung ist über das Attribut extend im interface Element möglich ports wurde umbenannt zu endpoints In Abbildung 2.3 ist der Aufbau der unterschiedlichen Versionen gegenübergestellt. Mit service und port, beziehungsweise endpoint in der neuen Version, wird der Service durch die genaue Adresse in Form einer URL mit dazugehörigem Port angegeben. Durch das binding werden dann die verschiedenen Operationen an den Service gebunden. Des Weiteren wird hier das genaue Übertragungsprotokoll festgelegt. 12

21 2.4. Webservices -part -input -output definitions types message porttype binding -soap : binding style -output -input WSDL 1.1 operation operation -fault -fault WSDL 2.0 description -input -output -infault -outfault -input -output -infault -outfault types interface operation binding operation -port service -endpoint service Abbildung 2.3.: Aufbau einer WSDL-Datei in Version 1.1 und 2.0 (vgl. [Jos08, S. 262 f.]) Innerhalb des porttype beziehungsweise interface wird die Verknüpfung zwischen Operationen und Request- und Responseparametern, bzw. Parameter und Rückgabewert, hergestellt. In der WSDL 1.1 Spezifikation können mit message allgemeine Datenpakete deklariert werden, die durch types mit Hilfe der XML-Schema Spezifikation exakt beschrieben werden. In der Version 2.0 ist dies durch direkte Referenzierung zu types möglich. Innerhalb der types werden schließlich einzelne Attribute benannt, die Häufigkeit des Auftretens sowie die Variablentypen. Es besteht auch die Möglichkeit, die XML-Schema Typenspezifikation auszulagern und innerhalb des WSDL-Dokuments zu importieren SOAP Die Spezifikation von SOAP beschreibt in erster Linie den Aufbau und das Format der Nachrichten, die bei einem Service-Aufruf zwischen Konsument und Serviceanbieter ausgetauscht werden. Die zu übertragenden Daten werden in einen speziellen Umschlag eingebettet, wie es in Abbildung 2.4 dargestellt ist. SOAP-Envelope SOAP-Header SOAP-Body Abbildung 2.4.: Aufbau einer SOAP-Nachricht Dabei wird innerhalb eines Umschlags (soap:envelope) ein Header (soap:header) und 13

22 2. Grundlagen ein Body (soap:body) eingefügt. Syntaktisch wird das Austauschformat mit Hilfe der Extensible Markup Language (XML) beschrieben. Im Listing Quellcode 2.4 ist eine Nachricht im XML-Format exemplarisch dargestellt. 1 <?xml version="1.0"?> 2 <soap:envelope xmlns:soap=" envelope"> 3 <soap:header> </soap:header> 4 <soap:body> 5 <ns:getcarinformation xmlns:ns=" 6 <kfz>do FH 123</kfz> 7 </ns:getcarinformation> 8 </soap:body> 9 </soap:envelope> Quellcode 2.4: Aufbau einer SOAP-Nachricht in XML Die Nutzdaten innerhalb des Body-Tags stellen den fachlichen Teil mit den wichtigen Daten dar. In dem gezeigten Beispiel ist das die Anforderung von Informationen über das Auto mit dem Kennzeichen DO-FH 123. Aus diesem Grund ist das Body-Element in einer SOAP-Nachricht Pflicht. Der Header hingegen ist obligatorisch und kann infrastrukturbedingte Informationen wie zum Beispiel Routing- und Sicherheitsparameter enthalten REST-Webservices Neben SOAP gibt es noch die REST-Webservices. REST steht für Representational State Transfer und hat sich parallel zu SOAP als leichtgewichtige Variante entwickelt (vgl. [Fie00]). Architekturen, die REST-Webservices nutzen, werden auch als RESTful bezeichnet. Die Prinzipien dieser Technik werden schon längst, wenn auch vielleicht nicht bekannt, im Internet eingesetzt. Ressourcen und Methoden werden über einen Uniform Resource Identifier (URI) angesprochen; quasi wie der Aufruf einer Webseite. Dabei kommen die Standard HTTP-Methoden GET, POST, PUT und DELETE zum Einsatz (vgl. [Lö11]). REST-Webservices können als Kollektion von Ressourcen angesehen werden. Jede dieser Ressourcen ist durch eine Basis URI zu erreichen, gefolgt von einer eindeutigen ID, die die gewünschte Ressource identifiziert. Ein Beispiel-Webservice, über den man Informationen über ein Auto über das KFZ-Kennzeichen als ID erhalten kann, könnte wie im folgenden Listing 2.5 über die HTTP-Methode GET aufgerufen werden. 1 FH_123 Quellcode 2.5: Beispiel eines Service-Aufrufs mittels REST Dabei stellt die URI ohne das KFZ-Kennzeichen die Kollektion aller, über diesen Service registrierten, Autos dar. Mit diesem Prinzip können schließlich Ressourcen-basiert 14

23 2.5. OAGIS Open Application Group Integration Specification Webservices angeboten werden. Der Rückgabewert eines REST-Aufrufs kann, anders als bei SOAP-Webservices, variieren. So kann die Antwort, wie auch bei SOAP-Webservices, im XML-Format zurückgeliefert werden aber auch Formate mit weniger Overhead, wie zum Beispiel JavaScript Object Notation, kurz JSON, sind weit verbreitet. Das Pendant zur WSDL-Datei ist bei RESTful-Webservices die WADL-Datei (Web Application Description Language, vgl. [Had09]). Darüber können ebenfalls Services und deren Eingabe- und Ausgabeparameter deklariert werden OAGIS Open Application Group Integration Specification von Andreas Beckers OAGIS ist ein transaktionsorientierter Business-Standard der Open Application Group Inc. (OAGi) für Dienste wie e-commerce, Cloud Computing, Service-orientierte Architekturen (SOA) und Webservices (vgl. [Ope12a]). Das Hauptproblem von verteilen und heterogenen Systemen ist die Kommunikation untereinander. Die große Herausforderung dabei ist, dass jedes System auch alle anderen Systeme verstehen kann. Mit der Spezifikation der Open Applications Group wurde dazu ein Standard eingeführt, der wie eine eigene Sprache für die Systemlandschaften zu verstehen ist. So ist es auch möglich, weitere Systeme anzukoppeln, die sich an der Kommunikation beteiligen können. Die Geschäftsdokumente, die hierbei zwischen den Geschäftspartnern ausgetauscht werden, werden Business Object Documents (BODs) genannt. Ein solches BOD ist in zwei Bereiche unterteilt. Das ist zum Einen die ApplicationArea, in der nicht-fachliche Daten, die meist technischer Natur sind, untergebracht sind. Das ist zum Beispiel die eindeutige Kennung des Senders oder aber auch der Zeitpunkt der Erstellung des BODs. Zum Anderen ist in dem Dokument der fachliche Teil in der DataArea untergebracht. Dieser Bereich ist, wie auch in Abbildung 2.5 zu sehen ist, in zwei weitere Bereiche unterteilt; in Verbs und Nouns. Ein Noun (zu deutsch: Nomen ) entspricht hierbei den wichtigen Geschäftsdaten, die weitläufig auch Business Objekte genannt werden. Dazu sind von OAGIS eine Vielzahl von Business Objekten spezifiziert worden (In Version existieren 84 Nouns). Darunter ist zum Beispiel ein Noun für eine Bestellung (PurchaseOrder) oder für den Status einer Bezahlung (PaymentStatus). Innerhalb eines jeden Nouns ist des Weiteren ein Block Components zu finden, innerhalb dessen der Block Fields vorzufinden ist. Components sind modulare Basisdatenblöcke, wie zum Beispiel der Block Adressen, die von allen BODs genutzt werden. Einige der Components sind von UN/CEFACT standardisiert und aus der Core Component Library entnommen (CCL, vgl. [Row05, S. 37 ff.] und [UNE12]). Die Fields sind ausschließlich 15

24 2. Grundlagen Business Object Document (BOD) ApplicationArea DataArea Verbs Nouns Components Fields Abbildung 2.5.: Architektur der BODs nach OAGIS (vgl. [Ope11]) die elementarsten Bestandteile in OAGIS, wie zum Beispiel die Attribute description und name (vgl. [Ope11]). Das Verb, das ebenfalls zum Datenteil eines BODs gehört, beschreibt die Geschäftsoperation, die mit dem Business Objekt durchgeführt werden soll. Ein Beispiel für ein solches Verb ist zum Beispiel Get, mit dem eine Liste von Daten (entsprechend des Nouns) angefordert wird. In einem Verb sind, im Gegensatz zum Noun, allerdings nur einige, wenige Attribute deklariert. Ein Beispiel für ein Attribut des Verbs Get ist zum Beispiel maxitems für die maximale Anzahl der Datensätze, die zurückgeliefert werden sollen. Die Antwort auf diese Nachricht würde in diesem Fall mit dem Verb Show zurückgeliefert werden. Durch die Kombination von Verb und Noun ergibt sich schließlich der Name des BODs. So ergibt zum Beispiel die Kombination des Verbs Get und dem Noun PurchaseOrder das BOD GetPurchaseOrder, welches mit dem BOD ShowPurchaseOrder beantwortet würde. Ausgeliefert wird die Spezifikation von OAGi als Paket von XSD-Dateien. Jedes Noun ist dabei eine eigene XSD-Datei, die wiederum die fachlich benötigten Komponenten inkludiert. Auch vorgefertigte BODs sind in diesem Paket enthalten, also ausgewählte Kombinationen von Verbs und Nouns. Die Menge an XSD-Dateien sind nach fachlichen Bereichen modularisiert worden. So gibt es Components für verschiedenste Business-Bereiche wie zum Beispiel Finanzen (FinancialComponents.xsd) oder Logistik (LogisticsComponents.xsd). Die Nachrichten, die in Form eines BODs ausgetauscht werden, haben die Form eines XML-Dokuments. Diese Dokumente können unabhängig von den Transportprotokollen der Systeme ausgetauscht werden. Sie können zum Beispiel mit HTTP (RESTful) oder SMTP ausgetauscht werden, genauso gut aber auch in Webservice-basierte SOAP-Nachrichten gepackt werden. 16

25 2.6. ERP Enterprise Resource Planning 2.6. ERP Enterprise Resource Planning von Stefan de Bucourt Unter dem Stichwort des Enterprise Resource Plannings (deutsch etwa Unternehmensweite Resourcenplanung ) werden System zusammengefasst, die möglichst umfassend die Abläufe eines Unternehmens abdecken. So gehören zu einem ERP-System mehrere Aspekte, die sich auf das gesamte Unternehmen auswirken können. Bei großen ERP-Systemen wie beispielsweise dem deutschen SAP handelt es sich um Standardsoftware, die in mehrere Bereiche unterteiltist. Es gibt jedoch auch Individual- oder Branchenlösungen. Typische Bereiche von ERP-Sytemen sind Lagerhaltungssysteme, Produktionsmanagement, Finanzbuchhaltung und Customer Relationship Management (CRM), welche sich beispielsweise bei SAP und Openbravo finden (vgl. [SAP12, Ope12c]). Damit einher geht ein ausgedehntes Rollenkonzept, um sowohl die Sichten auf als auch die Rechte im System den verschiedenen Aufgaben der Mitarbeiter zuzuordnen. Diese Systeme haben eine ungeheure Komplexität erreicht. So gibt es beispielsweise für SAP Handbücher, die sich lediglich mit einem der Module beschäftigen WMS Warehouse Management System von Andreas Beckers Ein Warehouse Management System (deutsch Lagerverwaltungssystem ) ist ein System zur automatisierten Verwaltung von Lagern durch Realisierung von komplexen Abläufen innerhalb des Lagermanagements. Insbesondere spielt hierbei das Verwalten von Mengen und Lagerorten sowie deren Beziehung zueinander eine Rolle (vgl. [HS08, S. 8 ff.]). Die eingesetzten Systeme bilden dabei oft spezialisierte Abläufe ab, die dadurch entstehen, dass unterschiedliche Anforderungen wegen des unterschiedlichen Bestellverhaltens der Kunden aber vor allem wegen unterschiedlicher Geschäftspraktiken der Lagerinhaber vorhanden sind. Dennoch existieren grundlegende Abläufe, die die Systeme gemeinsam haben. Der Einsatz des WMS beginnt schon bei der Annahme der Waren einer Lieferung und dem anschließendem Eröffnen des Wareneingangs, indem die Lieferung ins System eingetragen wird (vgl. [HS08, S. 23 ff.]). Darauf folgend findet der Einlagerungsprozess der Waren auf die Lagerplätze statt. Durch die Verwaltung aller Lagerplätze kann so automatisiert festgestellt werden, wo die Waren am sinnvollsten aufzubewahren sind. Ein Lager dient der temporären Aufbewahrung unterschiedlichster Artikel. Werden diese Artikel nun benötigt, zum Beispiel wenn ein Kunde die Ware bestellt hat, findet der Auslagerungsprozess statt, der ebenfalls durch das WMS verwaltet wird. Oft bestehen Bestellungen aus einer zusammengestellten Menge von unterschiedlichen Artikeln. Eine 17

26 2. Grundlagen weitere wichtige Aufgabe des WMS ist hierbei die Kommissionierung also Zusammenstellung dieser Artikel. Aus den unterschiedlichen Lagerplätzen müssen kontrolliert die Artikel ausgelagert und transportiert werden. Dabei gibt es Konsolidierungspunkte, an denen die Waren ebenfalls vom WMS identifiziert und kontrolliert werden. Wurden die richtigen Artikel in der korrekten Menge ausgelagert? Dazu können diverse Technologien, wie zum Beispiel Barcodescanner, Waagen (Zum Auswiegen der Bestellmenge) oder auch RFID-Systeme eingesetzt und mit dem WMS gekoppelt werden (vgl. [HS08, S. 243]). Nachdem alle Waren für eine Bestellung kommissioniert wurden, können diese schließlich verpackt und versandt werden. Ein besonderer Aspekt des WMS während dieser genannten Aktivitäten ist die Überwachung der Lagerbewegungen. Ein weiterer wichtiger Aspekt ist die Effizienz für die Einund Auslagerung. Durch effiziente Algorithmen können Transportwege verkürzt und somit Zeit und Geld eingespart werden. 18

27 3. Szenario von Stefan de Bucourt Es wurde ein einfaches Szenario vorgegeben, mit welchem die Eignung von 4D zur Erstellung von Demoanwendungen für die vom Fraunhofer ISST konzipierte Logistics Mall getestet werden soll. In diesem Szenario der Kontraktlogistik avisiert das ERP-System eines Herstellers die Einlagerung von Waren beim WMS des Logistikpartners. Beide Systeme sollen als Webanwendungen bedient werden und, als Vorbereitung für den Einsatz in der Cloud, über Webservices miteinander kommunizieren Ausgangslage Die Firma Digital Media Devices (DMD) aus Borken stellt Elektronikgeräte her, welche im Ruhrgebiet im Elektronikfachhandel angeboten werden sollen. Um dies zu erleichtern, wird die Dortmunder Firma Spedition Hurz mit der Lagerhaltung und Spedition beauftragt. Die Waren von Digital Media Devices werden von Spedition Hurz abgeholt und eingelagert. Für dieses Szenario sollen Demonstrations-Systeme für die beiden Firmen entwickelt werden. Zum Einen ist das ein Demo-Enterprise Resource Planning-System für DMD mit dem Namen MyERP und zum Anderen das Demo-Warehouse Management System für Sped. Hurz mit dem Namen MyInventory. Dabei liegt der Fokus auf der möglichst standardisierten Kommunikation der Systeme mittels Webservices. Im Szenario ist vorgesehen, dass im ERP-System Aufträge zur Einlagerung von Waren beim WMS angelegt werden. Über diese Aufträge soll ein Lieferavis an das WMS gesendet werden, damit dort die Einlagerung vorbereitet werden kann. Sobald die Lieferung eintrifft, soll diese vereinnahmt und das ERP-System über die Lieferung informiert werden. Der Austausch der Daten soll dabei auf XML-Dateien basieren, die an den Industriestandard OAGIS angelehnt sind Kommunikationsablauf Die Kommunikation beginnt mit dem Anlegen eines Auftrags im Enterprise Resource Planning-System. Für diesen Auftrag zur Einlagerung von Waren wird an das Warehouse 19

28 3. Szenario Management System ein Avis geschickt. Dieses Avis sorgt dafür, dass vom WMS Vorbereitungen für den Empfang der Ware vorgenommen werden können, beispielsweise das Bereitstellen von Lagerhilfsmitteln. Der Empfang des Avis wird dabei sofort bestätigt, wie es im UML-Sequenzdiagramm 3.1 dargestellt ist. interaction Kommunikationsablauf [ Kommunikationsablauf ] ERP WMS 1: Auftrag anlegen 2: Avis versenden 4: Empfang bestaetigen 3: Avis bearbeiten 5: Lieferung 7: Lieferbestaetigung versenden 6: Wareneingang bearbeiten 8: Bestaetigung bearbeiten 9: Empfang bestaetigen Abbildung 3.1.: Ein Überblick über die Kommunikationsabläufe im Szenario Hinweis: In den Bildern sind keine Umlaute vorhanden, da das vorgegeben UML-Tool diese für skalierbare EPS-Dateien nicht unterstützt Im Anschluss daran kann bei Sped. Hurz eine Lieferung eintreffen und im WMS eingetragen werden. Wann dies geschieht, ist nicht relevant, solange es nach dem Eingang des Avis geschieht. Eine Lieferung ohne vorher eingegangenen Avis wird gesondert behandelt (s. Abschnitt Lieferung eintragen). Der Fall, dass keine Lieferung eingeht, ist im Szenario nicht vorgesehen. Die Systeme sind also jederzeit bereit, die Abwicklung eines Auftrags weiterzuführen, sobald eine Lieferung eintrifft. Eine automatische Handlungsmöglichkeit der EDV-Systeme bei ausbleibender Lieferung wäre eine Benachrichtigung der Anwender über diese ausstehende Lieferung, indem nach einer bestimmen Anzahl an Tagen nach dem voraussichtlichen Ankunftstermin eine Meldung ausgeben wird. Für eine genauere Verfolgung der Lieferungen müsste der Transporteur in die Abläufe eingebunden werden, was aber für dieses einfache Szenario nicht vorgesehen ist. Ist die Lieferung eingetroffen, wird diese im WMS bearbeitet (Abschnitt Lieferung 20

29 3.2. Kommunikationsablauf eintragen und folgende). Sobald dieser Vorgang abgeschlossen ist, wird das ERP-System über die empfangenen Artikel informiert. Der Empfang dieser Information wird wieder quittiert. 21

30

31 4. Konzept der Anwendungen Zur Kommunikation der Anwendungen werden Business Object Documents verwendet, die stark an OAGIS angelehnt sind. Im ersten Abschnitt dieses Kapitels wird beschrieben, welche BODs eingesetzt werden und an welcher Stelle diese in der Kommunikation auftreten. Der zweite und dritte Teil des Kapitels erläutert die Konzepte hinter den Anwendungen MyERP (4.2) und MyInventory (4.3), die mit methodischen Vorgehensweisen entwickelt wurden. Dabei wird jeweils zuerst auf das systemspezifische Szenario mit Hilfe von UML-Aktivitätsdiagrammen eingegangen. Anschließend werden die Datenmodelle anhand von ER- und UML-Klassendiagrammen erläutert. Zusätzlich wird die Konzeption der Interaktionen mit der Weboberfläche durch Screenflows dargestellt und beschrieben Kommunikation Die Kommunikation der beiden Systeme soll nach einem festgelegten Schema stattfinden (s. Abschnitt 3.2). Die dazu genutzten Business Object Documents richten sich im Aufbau und der Namensgebung nach der Spezifikation der Open Application Group (OAGIS); so besteht jedes BOD aus einem Nomen und einem Verb, wie im folgenden Abschnitt detailliert beschrieben. Im Abschnitt werden schließlich die Kommunikationsabläufe inklusive der verwendeten BODs und der Erweiterung des Szenarios um die Korrekturaufträge dargestellt. In diesem Abschnitt wird des Weiteren erläutert, wie die Synchronisation der Artikelstammdaten stattfindet und welche Alternativen es geben würde OAGIS-nahe Nachrichten von Andreas Beckers Die im vorherigen Kapitel beschriebenen Nachrichten sind als OAGIS-nahe BODs konzipiert. OAGIS-nah bedeutet, dass für die Demoanwendungen nicht alle Feinheiten der Spezifikation berücksichtigt und übernommen werden. Stattdessen werden nur die benötigten Elemente eingesetzt, was quasi einem Lightening entspricht (siehe Grundlagenkapitel 2.3). Der grundsätzliche Aufbau der Objekte ist dennoch der gleiche wie in der eigentlichen Spezifikation. So ist ein BOD aufgeteilt in je ein Verb und ein Nomen (OAGIS-Noun). Das 23

32 4. Konzept der Anwendungen Verb beschreibt die auszuführende Aktion und das Nomen das zu behandelnde Objekt. In den folgenden Unterkapiteln sind die für das Szenario benötigten Verben und Nomen aufgeführt. Anschließend werden die aus Verb und Nomen zusammengesetzten BODs, die in den Anwendungen ausgetauscht werden, genauer beschrieben Nomen Es werden für die Kommunikation zwischen den Demoanwendungen drei OAGIS-Nouns benötigt. Das erste, das in dem Szenario auch zuerst ausgetauscht wird, ist die Lieferankündigung (Avis). Für diese Ankündigung wird schließlich das Nomen Shipment verwendet. Nach der OAGI-Spezifikation werden übermittelte Nachrichten Noun-unabhängig über das Hilfsnomen BOD (Business Object Document) bestätigt. Aus diesem Grund wird dieses Element auch für die Kommunikation übernommen. Das letzte benötigte Element ist schließlich die Lieferbestätigung. Dazu wird das Nomen ReceiveDelivery verwendet. In den folgenden Abschnitten werden diese drei Elemente näher erläutert. In der Abbildung 4.1 wird außerdem die genau Datenstruktur der Nomen anhand eines UML-Klassendiagramms dargestellt. package Schnittstelle[ OAGIS Noun] ShipmentHeaderType -AdviceID : xs:string -ApproxDateArrival : xs:date BODType -SuccessMessage : xs:string -FailureMessage : xs:string ShipmentType -Header : ShipmentHeaderType -ShipmentItems : List<ItemType> * ItemType -GTIN : xs:string -Description : xs:string -Quantity : xs:nonnegativeinteger -Height : xs:positiveinteger -Width : xs:positiveinteger -Depth : xs:positiveinteger -Weight : xs:float ReceiveDeliveryHeaderType -DeliveryReceiptID : xs:string -DateArrival : xs:date ReceiveDeliveryType -Header : ReceiveDeliveryHeaderType -ReceiveDeliveryItems : List<ReceiveDeliveryItemType> * ReceiveDeliveryItemType -ReceivedQuantity : xs:integer Abbildung 4.1.: Aufbau der OAGIS-Nouns Shipment Für das Lieferavis wird das Nomen Shipment genutzt. Dieses Element enthält nach Art der OAGI-Spezifikation einen eigenen Header. Darin enthalten ist die eindeutige Kennung des Avis (AdviceID) sowie die ungefähre Ankunftszeit der eigentlichen Lieferung (ApproxDateArrival). Zusätzlich zum Header ist in diesem OAGIS-Nomen eine Sequenz von Artikeln enthalten. Diese Sequenz enthält schließlich alle Artikel des Typs ItemType, die zur Lieferung angekündigt sind. Bei jedem Artikel werden dabei die relevanten Daten wie Global Trade Item Number (GTIN), Beschreibung, Menge und metrische Daten wie Größe, Länge, Breite und Gewicht angegeben. 24

33 4.1. Kommunikation ReceiveDelivery Ein ReceiveDelivery-Nomen entspricht einer tatsächlichen Lieferung, der eine Ankündigung voraus ging. Dieser Nachrichtentyp erweitert dabei den Header des vorher beschriebenen Elements Shipment um einige Daten. Das heißt also, dass alle Daten des vor der Lieferung eingegangenen Avis auch in dieser Nachricht mit versendet werden. Genauer genommen wird in dieser Nachricht die ID des Avis sowie das Ankündigungsdatum mitgesendet. Die Erweiterung des Headers entspricht der zur Lieferung beigefügten Lieferscheinnummer (DeliveryReceiptID) sowie das tatsächliche Lieferdatum (DateArrival). Die Erweiterung der Artikeldaten hat den Sinn, dass so auch die gelieferte Menge pro Artikel angegeben werden kann (ReceivedQuantity). So kann in der Nachricht direkt festgestellt werden, ob die gelieferte Menge mit der avisierten Menge übereinstimmt, oder ob Differenzen aufgetreten sind. Die vorgenommene Vererbung von Header und Artikeldaten entspricht auch der OAGIS-Struktur. BOD Das dritte Nomen, das für Antwortnachrichten in diesen Szenarien gedacht ist, ist BOD. BOD steht für Business Object Document und stellt eine allgemeine Nachricht, ohne direkten fachlichen Hintergrund dar. Für die Demoanwendungen sind die OAGIS- Elemente SuccessMessage, für Mitteilungen, die den Erfolg einer Nachrichtenübertragung ankündigen, sowie FailureMessage, die preisgibt, dass ein Fehler auftrat, vorgesehen. Die genauen Gründe für die Fehler beziehungsweise positive Meldungen über genauere Aktionen, die ausgelöst wurden, sind entsprechend Inhalt der Elemente. Für die Demoanwendungen ist jeweils nur eine der beiden Elemente erlaubt bzw. es wird nur ein Element ausgewertet. Ist in dem BOD eine Fehlermeldung enthalten, so wird die Nachricht als Fehlschlag interpretiert, unabhängig davon, ob auch eine SuccessMessage vorhanden ist Verben Nachdem der fachliche Inhalt in Form von OAGIS-Nouns beschrieben wurde, folgen nun die Verben, die die auszuführenden Aktionen kennzeichnen. Anders als die OAGIS-Nouns enthalten diese Verben für das Szenario keine weiteren Daten. Das System, das die OAGIS- Nachrichten empfängt, muss schließlich die beschriebene Funktion anhand des Typs ausführen. Dies ist vorgegeben, da OAGIS, wie im Grundlagenkapitel 2.5 beschrieben, ein Transaktionsstandard ist. Alle notwendigen Daten zur Weiterverarbeitung sind im Nomen enthalten. Für ein vollständiges BOD werden schließlich im Datenteil (DataArea) Verb und Nomen kombiniert (siehe Komplette Struktur der BODs). Für den Datenaustausch zwischen den Systemen werden schließlich vier Verben, die im Folgenden aufgelistet sind, benötigt (vgl. [Row05, S. 30]). Process Dieses Verb initiiert eine Business Operation, welche normalerweise darin resultiert, dass ein neuer Datensatz angelegt wird. 25

34 4. Konzept der Anwendungen Change Dadurch kann eine Änderung der Business Operation bzw. des zuvor angelegten Datensatzes initiiert werden. Notify Ein angekoppeltes System kann über dieses Verb benachrichtigt werden. Confirm Dieses Verb bestätigt einen Vorgang und tritt vor allem in. Kombination mit dem Nomen BOD auf Business Object Documents Nachdem die Hauptkomponenten Verben und Nomen beschrieben wurden, können die eigentlich benötigten Nachrichtentypen zusammengesetzt werden. Für die Kommunikation zwischen den Demosystemen werden genau vier solcher Typen benötigt, die in den folgenden Abschnitten erläutert werden. ProcessShipment Der erste Nachrichtentyp ist für die Mitteilung zur Ankündigung der Lieferung (Avis) bestimmt. Ein Lieferavis ist eine Mitteilung an ein System, die bekannt gibt, dass zu einem gewissen Zeitpunkt eine Lieferung mit einer bestimmten Anzahl von Artikeln eintrifft. Darauf muss sich der Empfänger entsprechend vorbereiten. Man kann also sagen, dass eine spezielle Business Operation durchgeführt wird. Aus diesem Grund wird das Verb Process eingesetzt. Die nötigen Daten über die in der Lieferung enthaltenen Artikel und deren Menge können in dem Nomen Shipment untergebracht werden. Somit ergibt sich für die Lieferankündigung als OAGIS-Business Object Document Process- Shipment. ChangeShipment Für die Korrektur eines Avis, wofür das nächste BOD benötigt wird, kann das Nomen Shipment wiederverwendet werden. Durch die darin enthaltene eindeutige Kennung AdviceID kann ein Rückschluss auf die vorher gesendete Nachricht gezogen werden. Das OAGIS-Nomen enthält nun die aktualisierten Daten der Artikel. Durch das Verb Change wird dem Empfängersystem schließlich mitgeteilt, dass die Business Operation zum Korrigieren der Daten durchgeführt werden soll. NotifyReceiveDelivery Wenn im WMS eine Lieferung eintrifft, muss das angekoppelte ERP-System über die genauen Artikelmengen informiert werden. Genau diesen Benachrichtungskontext liefert das Verb Notify. Die Angaben über die Artikel der Lieferung und deren Menge können über das Nomen ReceiveDelivery übertragen werden. Darin ist nicht nur die Lieferscheinnummer enthalten, die jeder Lieferung beiliegt, sondern auch ein Verweis auf das zuvor eingegangene Avis. So hat das Empfängersystem die Möglichkeit, die Lieferung mit dem eigentlichen Avis gegenzuchecken und entsprechende Maßnahmen durchzuführen. 26

35 4.1. Kommunikation ConfirmBOD Der vierte und letzte Typ dient als direkte, synchrone Antwort auf Nachrichten der oben beschriebenen Typen. Es muss damit möglich sein, mögliche Fehlermeldungen mitzuteilen, wenn zum Beispiel fachliche wie auch technische Fehler auftreten. Aber auch erfolgreich übermittelte Nachrichten müssen entsprechend bestätigt werden. Dazu dient der OAGIS-standardkonforme Nachrichtentyp ConfirmBOD für synchrone Antworten. Das Verb Confirm ist schließlich der Indikator dafür, dass die Mitteilung angekommen ist. Innerhalb des BOD-Nomens können dann Meldungen über die Verarbeitung der eingegangen Nachricht deponiert werden Komplette Struktur der BODs In diesem Unterkapitel wird für die oben beschriebenen Nachrichtentypen die genaue Datenstruktur für die Demoanwendungen erläutert. Die in Kapitel beschriebenen Nomen finden sich hier wieder und werden zur Vollständigkeit aufgeführt. In Abbildung 4.2 ist schließlich mittels eines UML-Klassendiagramms der komplette Aufbau der vier Nachrichten dargestellt. Wie zu sehen ist, sind alle Datentypen mit dem Postfix Type versehen. Der Grund dafür liegt zum Einen an der konsistenten Namensgebung nach OAGIS und zum Anderen daran, dass üblicherweise XML-Schema Typdefinitionen so benannt werden (vgl. [Liq11]). Die eigentlichen Instanzen der BODs innerhalb der XML-Nachrichten sind Elemente der aufgeführten Typen. So ist zum Beispiel das Business Object Document ProcessShipment ein Element des Typs ProcessShipmentType. Die Typdefinitionen eines jeden BODs beinhaltet eine eigens definierte DataArea. Diese Typen haben die Bezeichnung in der Form [Name des BODs]DataAreaType. Wie in der Abbildung zu sehen ist, enthalten diese Bereiche genau die Verben und Nomen, die entsprechend auf deren Typdefinitionen referenziert sind. Zusätzlich zu den fachlichen Inhalten eines jeden Business Object Documents also die Nomen und Verben gibt es noch einen technischen Bereich. Dies ist durch Generalisierung realisiert, das heißt, dass die Typen der BODs von dem allgemeineren Typen Business- ObjectDocumentType abgeleitet sind. Dieser Typ enthält entsprechend nach OAGIS die ApplicationArea, die technische Daten enthält wie den Zeitpunkt der Erstellung der jeweiligen Nachricht (CreationDateTime) sowie die eindeutige Bezeichnung des Erstellers der Nachricht (SenderType). Die angepasste Architektur eines Business Object Documents für das Szenario ist in Abbildung 4.3 zu sehen. Im Gegensatz zur originalen OAGIS-Architektur wurden hierbei die Components innerhalb der Nomen entfernt. Die darin befindlichen Fields und Compounds wurden ebenfalls nicht übernommen, da sie für das Szenario nicht notwendig sind und die Komplexität unnötig aufgebläht hätten (siehe Grundlagenkapitel 2.5). 27

36 4. Konzept der Anwendungen package Schnittstelle[ OAGIS Aufbau BODs ] BusinessObjectDocumentType -ApplicationArea : ApplicationAreaType ApplicationAreaType -Sender : SenderType -CreationDateTime : xs:datetime SenderType -LogicalID : xs:string ProcessShipmentType -DataArea : ProcessShipmentDataAreaType NotifyReceiveDeliveryType -DataArea : NotifyReceiveDeliveryDataAreaType ConfirmBODType -DataArea : ConfirmBODDataAreaType ChangeShipmentType -DataArea : ChangeShipmentDataAreaType NotifyReceiveDeliveryDataAreaType -Notify : NotifyType -ReceiveDelivery : ReceiveDeliveryType ProcessShipmentDataAreaType -Process : ProcessType -Shipment : ShipmentType ChangeShipmentDataAreaType -Change : ChangeType -Shipment : ShipmentType ConfirmBODDataAreaType -Confirm : ConfirmType -BOD : BODType ProcessType ChangeType NotifyType ConfirmType ShipmentType -Header : ShipmentHeaderType -ShipmentItems : List<ItemType> BODType -SuccessMessage : xs:string -FailureMessage : xs:string ShipmentHeaderType -AdviceID : xs:string -ApproxDateArrival : xs:date ReceiveDeliveryHeaderType -DeliveryReceiptID : xs:string -DateArrival : xs:date ItemType -GTIN : xs:string -Description : xs:string -Quantity : xs:nonnegativeinteger -Height : xs:positiveinteger -Width : xs:positiveinteger -Depth : xs:positiveinteger -Weight : xs:float ReceiveDeliveryItemType -ReceivedQuantity : xs:integer ReceiveDeliveryType -Header : ReceiveDeliveryHeaderType -ReceiveDeliveryItems : List<ReceiveDeliveryItemType> Abbildung 4.2.: Aufbau der BODs Business Object Document (BOD) ApplicationArea DataArea Verb -Process -Change -Notify -Confirm Noun -Shipment -ReceiveDelivery -BOD Abbildung 4.3.: Angepasste OAGIS-Architektur für die Demoanwendungen 28

37 4.1. Kommunikation Kommunikationsablauf mit BODs von Stefan de Bucourt In Abbildung 4.4 wird zusammenfassend noch einmal der Kommunikationsablauf gezeigt. Im Vergleich zur Abbildung 3.1 werden in diesem Diagramm jedoch die genutzten Business Object Documents verwendet. Hier ist anschaulich zu sehen, dass zur Bekanntmachung eines Avis das BOD ProcessShipment genutzt wird, während für Veränderungen an diesem Avis das BOD ChangeShipment verwendet wird. Dieses befindet sich in einem optionalen Block, welcher die Kommunikationsvorgänge bei einer Korrektur darstellt. Dieser optionale Vorgang ist in zwei Abschnitte unterteilt, wovon der zweite ebenfalls optional ist: Bei jeder Änderung wird ein BOD vom Typ ChangeShipment an das WMS gesendet und von diesem mit einem BOD vom Typ ConfirmBOD quittiert. Nun kann es sein, dass in dieser Nachricht dem WMS mitgeteilt wird, dass die bisher erhaltene Lieferung den neuen Korrekturauftrag direkt abschließt und somit keine weitere Lieferung eintreffen wird. In diesem Fall ist die Kommunikationssequenz hier beendet und der Auftrag ist abgearbeitet. Alternativ dazu wird im Korrekturauftrag mitgeteilt, dass noch Teile nachgeliefert werden. Dann muss im WMS, wie bei einem normalen Auftrag, eben diese neue Lieferung eingehen, mit welcher die Bearbeitung fortgeführt werden kann. Ein solcher Korrekturauftrag wird also identisch behandelt wie ein normaler Auftrag. Eine weitere Korrektur ist dann möglich und läuft wieder wie die hier beschriebene ab Synchronisation der Artikelstammdaten von Stefan de Bucourt Um eine Kommunikation der beiden Anwendungen zu ermöglichen, müssen in beiden Systemen die gleichen Artikel vorhanden sein. Diese werden über die Global Trade Item Number (GTIN) identifiziert, eine global eindeutige Identifikationsnummer ähnlich der EAN (vgl. [GS106]). Neue Artikel werden dabei nur vom Hersteller DMD eingeführt. Zur Synchronisation dieser Stammdaten werden alle erforderlichen Werte redundant mit jedem BOD des Typs ProcessShipment, ChangeShipment oder NotifyReceiveDelivery übertragen. Betrachtete Alternativen dazu sind die Pflege von Hand sowie eine eigene Serviceschnittstelle zur automatisierten Stammdatensynchronisation Synchronisation mit vorhandenen BODs Die aus Aufwandsgründen gewählte Variante ist, bei einem Avis immer die für den Empfänger relevanten Artikelstammdaten mitzusenden. Dies sind die Global Trade Item Number, die Beschreibung eines Artikels, sowie dessen Abmessungen und Gewicht. Empfängt das WMS nun einen Einlagerungsauftrag mit einer unbekannten GTIN, so wird diese dem eigenen Artikelstamm hinzugefügt. Auch Änderungen ließen sich auf diese Weise einfach 29

38 4. Konzept der Anwendungen interaction Kommunikationsablauf mit BODs [ Kommunikationsablauf mit BODs ] ERP WMS 1: Auftrag anlegen 2: ProcessShipment 4: ConfirmBOD 3: Avis bearbeiten 5: Lieferung 7: NotifyReceiveDelivery 6: Wareneingang bearbeiten 8: Bestaetigung bearbeiten 9: ConfirmBOD opt [Wenn Aenderung noetig ist] 10: ChangeShipment 12: ConfirmBOD opt [Wenn weitere Lieferungen angekuendigt wurden] 15: NotifyReceiveDelivery 16: Bestaetigung bearbeiten 17: ConfirmBOD 11: Aenderung bearbeiten 13: Lieferung 14: Wareneingang bearbeiten Abbildung 4.4.: Ein Überblick über die Kommunikationsabläufe im Szenario inkl. der jeweils verwendeten BODs. 30

39 4.1. Kommunikation übernehmen, da die Stammdaten bei jedem BOD vom Typ ProcessShipment, Change- Shipment und NotifyReceiveDelivery mit übertragen werden. Dies wurde jedoch nicht umgesetzt, da die relevanten Daten (also Beschreibung, Maße und Gewicht eines Artikels) sich in den Demoanwendungen nicht ändern. Für neue Versionen eines bekannten Artikels muss also ein neuer Datensatz mit einer eigenen GTIN angelegt werden 1. Nachteilig an diesem Vorgehen ist der erhöhte Datenaufwand bei der Kommunikation. Trotz dieser redundanten Daten sind die übertragenen XML-Dateien jedoch noch immer recht klein: Ein ProcessShipment mit zwei Artikeln ist 1320 Byte groß (siehe Quelltext A.5). Diese Datenmenge ist mit heutigen Übertragungsraten nicht problematisch. Wenn bei jedem eingehenden BOD ein Abgleich mit den Artikelstammdaten zur Prüfung von Veränderungen stattfinden muss, verzögert dies die Abarbeitung am WMS im Bereich von einigen Milisekunden pro Artikel. Dies ist ebenfalls unproblematisch, sofern nicht sehr viele Aufträge anfallen. Die Systeme sind nicht auf eine solche Masse an Aufträgen auszulegen, da solche Nutzerzahlen für die Demonstrationsanwendungen nicht vorgesehen sind Eigene Serviceschnittstelle Eine andere Möglichkeit ist ein eigener Service zur Synchronisation der Artikelstammdaten, wozu das OAGIS-Verb sync genutzt werden kann. Diese Schnittstelle würde dafür sorgen, dass der Service für die Bekanntgabe eines Avis (also die Übertragung eines BOD ProcessShipment) nicht die zusätzliche Aufgabe erhält, die Artikelstammdaten zu synchronisieren. Dazu muss allerdings wieder eine komplexe Kommunikation aufgebaut werden, da auch mögliche Fehlerquellen und Änderungen der Stammdaten zu berücksichtigen sind. Dies würde u. U. komplexer werden als die eigentlichen unterstützten Abläufe, weswegen dieser Ansatz hier nicht gewählt wurde. So müsste der Kommunikationsvorgang selbst definiert werden, aber auch die Eskalation für den Fall, das an einer beliebigen Stelle in der Kommunikation der Aufträge eine Inkonsistenz der Datenbestände auftritt Abgleich und Pflege von Hand Die Auslagerung der Logistik an einen Dienstleister ist oft ein langwieriger Prozess, und die Bindung wird vertraglich festgeschrieben (siehe [Bru07] und [Imp12], zwei Unternehmen mit entsprechendem Angebot). Aus diesem Grund ist es möglich, im Rahmen des Szenarios zu definieren, dass bei diesem Prozess ein Abgleich der Stammdaten stattfindet, und dass spätere Änderungen von Hand eingepflegt werden. In diesem Fall würden MyERP und MyInventory auf synchronen Datenbeständen aufbauen. Sobald jedoch ein 1 Die Organisation GS1, welche die Vergabe von GTINs organisiert, hat auf ihrer Webseite (siehe [GS112]) ein Regelwerk zur Vergabe von GTINs für Produkte veröffentlicht. Diesem ist zu entnehmen, dass bei neuer Funktionalität (Punkt 4.3 ebd.) eine neue GTIN zu vergeben ist. 31

40 4. Konzept der Anwendungen Fehler, beispielsweise eine falsch übertragene GTIN vorliegt, würde dies zu Fehlern führen, die im System bearbeitet werden müssten. 32

41 4.2. MyERP 4.2. MyERP von Stefan de Bucourt Dieser Abschnitt betrachtet das Konzept des Demo-Enterprise Resource Planning Systems MyERP. Dabei wird zuerst auf die unterstützten Abläufe des Szenarios aus Sicht des ERP-Systems eingegangen (4.2.1), bevor die einzelnen Schritte des Szenarios inklusive der Schnittstellen zum WMS näher betrachtet werden. Es wird erläutert, wie Aufträge erstellt und an das WMS geleitet werden. Dabei wird auf die im Szenario abgedeckten Fehlerfälle eingegangen, sowie auf die korrigierenden Maßnahmen mittels Korrekturaufträgen. Im Anschluss werden die Datenstrukturen vorgestellt (4.2.3), und es wird das Konzept der Weboberfläche erläutert, welche die geplanten Abläufe unterstützt Unterstützte Abläufe Die unterstützten Abläufe beginnen damit, dass ein Benutzer einen Einlagerungsauftrag erstellt. Nach erfolgter Bearbeitung wird dieser freigegeben, worauf dem WMS ein Avis übermittelt wird (das BOD ProcessShipment, siehe Einlagerungsauftrag erstellen). Der zweite Teil beginnt mit der Nachricht des Logistikpartners, dass bei diesem Waren eingetroffen sind (Nachricht NotifyReceiveDelivery). Diese Rückmeldung wird vom System ohne Nutzerinteraktion abgearbeitet (siehe Rückmeldung bearbeiten). Ist die Lieferung wie im Avis angekündigt angekommen, so wird der Auftrag abgeschlossen. Sind nicht ausschließlich die angekündigten Waren in angekündigter Menge angekommen, so müssen Korrekturen vorgenommen werden. Zu diesem Zweck kann zu jedem fehlerhaften Auftrag ein nachfolgender korrigierender Auftrag erstellt werden (siehe Korrekturauftrag erstellen). Dieser kann später im Fehlerfall ebenfalls wieder korrigiert werden. Das UML-Aktivitätsdiagramm in Abbildung 4.5 bildet diese Abläufe ab, wobei die Aktivitäten Einlagerungsauftrag erstellen ( ), Rückmeldung bearbeiten ( ) und Korrekturauftrag erstellen ( ) an entsprechender Stelle eingehender erklärt werden, jeweils mit einem verfeinerten Aktivitätsdiagramm. Die Bezahlung eines Auftrags wird separat betrachtet. Ein Auftrag kann bezahlt werden, sobald er freigegeben ist und solange kein Korrekturauftrag vorliegt. Wenn ein solcher existiert muss dieser bezahlt werden, wobei etwaige vorher geleisteten Zahlungen berücksichtigt werden (siehe Auftrag bezahlen). Beim Bezahlen eines Folgeauftrages werden alle Vorgänger ebenfalls als bezahlt markiert. 33

42 4. Konzept der Anwendungen activity Ablaeufe MyERP [ Ablaeufe MyERP ] ProcessShipment : Einlagerungsauftrag erstellen Avis versenden ChangeShipment : Korrekturauftrag erstellen Empfangsbestaetigung erhalten NotifyReceiveDelivery : Rueckmeldung bearbeiten Auftrag korrekt? Ja Nein Auftrag abschließen Abbildung 4.5.: Die unterstützten Abläufe in MyERP Die Aktivitäten Einlagerungsauftrag erstellen (S. 35), Rückmeldung bearbeiten (S. 36) und Korrekturauftrag erstellen (S. 38) werden als eigene Abschnitte inkl. Diagrammen in den entsprechenden Abschnitten detailliert beschrieben. 34

43 4.2. MyERP Einlagerungsauftrag erstellen Die Handlung des Szenarios beginnt damit, im ERP-System einen Auftrag zu erstellen, wie in Diagramm 4.5 dargestellt. Hierbei handelt es sich durchwegs um Einlagerungsaufträge für den Kontraktlogistiker, andere Aufträge werden nicht betrachtet. Die einzelnen Schritte werden in Abbildung 4.6 dargestellt und im Folgenden erläutert. activity Einlagerungsauftrag erstellen( ProcessShipment ) [ Einlagerungsauftrag erstellen ] Standardwerte setzten Stammdaten bearbeiten Stammdaten speichern Auftragsposition hinzufuegen Auftrag vollstaendig? Ja Nein Freigabe veranlassen Avis erstellen ProcessShipment Abbildung 4.6.: Auftrag erstellen Bei der Erstellung eines Auftrags werden zwei Arten von Daten unterschieden: Zum Einen sind dies die Stammdaten eines Auftrags, wie die Angabe wann der Auftrag von welchem Nutzer freigegeben wurde, zum Anderen die zum Auftrag gehörenden Bewegungsdaten. Dies sind die einzelnen Artikel, die in einer bestimmten Menge als Auftragspositionen zum Auftrag hinzugefügt werden. Im Normalfall werden zuerst die Stammdaten bearbeitet. Der Zeitpunkt der Freigabe, der freigebende Nutzer und die Auftragsnummer (eindeutige Identifikationsnummer des Auftrags, auch Auftrags-ID) werden standardmäßig vom System gesetzt und können vom Nutzer nicht verändert werden. Der Nutzer kann daher bei den Auftragsstammdaten lediglich den Kontraktlogistiker auswählen, da theoretisch mehrere möglich sind. Im Szenario existiert allerdings nur die Spedition Hurz. 35

44 4. Konzept der Anwendungen Nach dem Bearbeiten der Stammdaten folgt das Anlegen von Auftragspositionen, also welche Artikel in welcher Menge eingelagert werden sollen. Sobald ein Nutzer hiermit beginnt, sollten die Stammdaten des Auftrags schon persistiert werden, obwohl noch keine weitere Handlung von Seiten des Systems erforderlich ist: Die Bearbeitung des Auftrags muss jederzeit unterbrochen zu einem späteren Zeitpunkt fortgesetzt werden können. Ist der Auftrag fertig erstellt, so kann ein Nutzer die Freigabe veranlassen. Dabei wird vermerkt, dass dieser Auftrag freigegeben wurde und welcher Nutzer dies getan hat, woraufhin die Daten des Auftrags nicht mehr bearbeitet werden können. Anschließend wird das Avis in Form eines ProcessShipments erstellt und als Nachricht an das WMS gesendet, um dieses somit über den neuen Auftrag zu informieren. Dabei erhält das Avis bei einem neuen Auftrag die Auftragsnummer, bei einem Korrekturauftrag die ursprüngliche Nummer. Dadurch kennzeichnet diese Nummer bei der Kommunikation mit dem WMS einen Vorgang eindeutig, auch wenn Korrekturaufträge erstellt wurden. Im Sequenzdiagramm 4.7 wird solch eine Sequenz von Auftrag und Korrekturaufträgen inklusive der verwendeten Kennungsnummern dargestellt. Mit dem Erhalt der Empfangsbestätigung vom WMS in Form eines ConfirmBOD gilt der Auftrag als angenommen. Bleibt die Bestätigung aus, so bleibt nur die Option, das Avis erneut zu versenden, also das BOD ProcessShipment erneut an das WMS zu übertragen. Dies wird jedoch nicht automatisch vom System übernommen, der Nutzer kann lediglich sehen, dass das Avis noch nicht bestätigt ist. Die geschätzte Ankunftszeit der Waren sollte eigentlich vom Spediteur des Kontraktlogistikers ermittelt werden. Da dieser Aspekt im Szenario nicht vorkommt, wird an dieser Stelle ein zufälliges, in naher Zukunft liegendes Datum eingetragen, ohne dem Nutzer eine Änderungsmöglichkeit zur Verfügung zu stellen Rückmeldung bearbeiten Nachdem beim Kontraktlogistiker eine Lieferung eingegangen ist, versendet dieser ein BOD vom Typ NotifyReceiveDelivery an den Hersteller (siehe Lieferung eintragen). Diese Meldung wird vom ERP-System, wie in Abbildung 4.7 dargestellt, automatisch bearbeitet. Der Nutzer hat hierauf keinen Einfluss, er sieht lediglich, dass sich der Status eines Auftrags ändert. Zur Abarbeitung muss zuerst der zur Nachricht NotifyReceiveDelivery gehörige Auftrag ermittelt und geladen werden. Dabei ist zu beachten, dass die Kommunikation mit dem WMS immer über die Avisnummer abläuft. Diese entspricht grundsätzlich einer Auftragsnummer im ERP-System. Ist jedoch ein Korrekturauftrag angelegt worden, so besitzt dieser eine eigene Auftragsnummer, die von der Avisnummer, die diesen Korrekturauftrag betrifft, abweicht. In diesem Fall muss also zur Avisnummer die aktuelle Korrekturauftragsnummer ermittelt werden. Das UML-Sequenzdiagramm in Abbildung 4.8 verdeutlicht die 36

45 4.2. MyERP activity Rueckmeldung bearbeiten( NotifyReceiveDelivery ) [ Rueckmeldung bearbeiten] Zugehoerigen Auftrag laden NotifyReceiveDelivery Vorraussetzungen pruefen Alle Auftragsdaten korrekt? Ja Nein Abbruch Gelieferte Artikelpositionen aktualisieren Jede Position pruefen Alle Artikel in avisierter Menge erhalten? Ja Nein Auftrag als korrekt markieren Auftrag als nicht korrekt markieren Abbildung 4.7.: Die Bearbeitungsschritte einer NotifyReceiveDelivery-Rückmeldung vom WMS 37

46 4. Konzept der Anwendungen Nummerierung an einem abstrakten Beispielablauf mit einem Auftrag und zwei folgenden Korrekturen. Ist der Auftrag eindeutig identifiziert und geladen, so werden die Voraussetzungen für die Abarbeitung geprüft. Konkret heißt dies, dass der Auftrag noch nicht abgeschlossen sein darf, dass er zum ausgewiesenen Kontraktlogistiker gehören muss und dass noch keine Lieferbestätigung für diesen Auftrag abgearbeitet wurde. Wird gegen eine dieser Bedingungen verstoßen, so wird die Abarbeitung abgebrochen. In diesem Fall enthält das ans aufrufende WMS gesendete ConfirmBOD eine Fehlermeldung. Dies geschieht beispielsweise dann, wenn eine NotifyReceiveDelivery-Nachricht mehrfach versendet wurde. Ist diese Prüfung abgeschlossen, so wird die gelieferte Menge jedes Artikels des Auftrags aktualisiert. Im Anschluss daran wird geprüft, ob alle Artikel in der avisierten Menge beim Kontraktlogistiker eingelagert wurden. Ist dies der Fall, so wird der Auftrag als erfolgreich abgeschlossen markiert. Ansonsten wird eine entsprechende Fehlermarkierung vorgenommen, welche die Art des Fehlers reflektiert. Dabei ist nicht entscheidend, bei wie vielen Artikeln ein Fehler auftritt, sondern nur, welche Typen von Fehlern aufgetreten sind. Es werden drei Grundtypen von Fehlern unterschieden, die kombiniert werden können. Die drei Typen sind: a) Es wurde von min. einem Artikel weniger geliefert als avisiert (beinhaltet fehlende Lieferung eines Artikels). b) Mindestens ein gelieferter Artikel wurde nicht avisiert. c) Es wurde von min. einem Artikel mehr geliefert als avisiert. Die gelieferte Menge einer Artikelposition eines Auftrags wird durch folgende Korrekturaufträge nicht angepasst, da diese ihre eigenen Bewegungsdaten haben. Somit ist es auch nach diesen Korrekturen möglich, genau einzusehen, welche Artikelposition welchen Fehler verursacht hat Korrekturauftrag erstellen Wurde beim Abarbeiten eines BODs vom Typ NotifyReceiveDelivery vom System ein Fehler festgestellt, so kann ein Korrekturauftrag erstellt werden. Dieser unterscheidet sich nur dadurch von einem normalen Auftrag, dass vermerkt wird, dass dieser Auftrag logisch auf einen anderen folgt. Zu diesem Zweck wird der fehlerhafte Auftrag als Vorgänger im neuen Korrekturauftrag eingetragen. Die Arbeitsschritte zur Erstellung eines Korrekturauftrags sind im Aktivitätsdiagramm 4.9 dargestellt. Ein Auftrag sowie dazu gehörende Korrekturaufträge zusammen werden als (Auftrags-) Sequenz bezeichnet. Vom System werden diejenigen Stammdaten des vorangegangenen Auftrags übernommen, welche für den neuen Auftrag nicht verändert werden dürfen. Dabei handelt es sich um 38

47 4.2. MyERP interaction Identifikationsnummern[ Identifikationsnummern] ERP 1: Auftrag a1 erstellen WMS 2: ProcessShipment (a1) 3: NotifyReceiveDelivery (a1) 4: Auftrag bearbeiten (a1) 5: Korrekturauftrag a2 erstellen 6: ChangeShipment (a1) 7: NotifyReceiveDelivery (a1) 8: Korrekturauftrag bearbeiten (a2) 9: Korrekturauftrag a3 erstellen 10: ChangeShipment (a1) 11: NotifyReceiveDelivery (a1) 12: Korrekturauftrag bearbeiten (a3) 13: Auftrag abschließen (a1, a2, a3) Abbildung 4.8.: Darstellung der benutzten Identifikationsnummern für Aufträge und Avise. Die Bezeichner a1, a2, und a3 stehen für die nacheinander vergebenen Auftragsnummern. Da es sich um eine Sequenz handelt (Auftrag und Korrekturen), bleibt die Avisnummer a1 gleich. 39

48 4. Konzept der Anwendungen activity Korrekturauftrag erstellen( ChangeShipment )[ Korrekturauftrag erstellen ] Auftragsdaten des Vorgaengers laden Vorgaenger als korrigiert markieren Korrekturauftrag speichern Vorhandene Auftragspositionen bearbeiten Auftrag freigeben ChangeShipment Abbildung 4.9.: Korrekturauftrag erstellen 40

49 4.2. MyERP die Referenzen auf den Kunden und den Kontraktdienstleister. Ferner wird eine neue Auftragsnummer vergeben, die des vorherigen Auftrags als Referenz festgehalten und die voraussichtliche Ankunftszeit wird neu ermittelt. Lediglich die voraussichtliche Ankunftszeit lässt sich vom Nutzer verändern. Die Stammdaten des Korrekturauftrags werden dabei sofort gespeichert, und beim Vorgänger wird vermerkt, dass nun ein Korrekturauftrag vorliegt. Darüber hinaus werden die Bewegungsdaten aus denen des alten Auftrags für den neuen generiert. Dabei wird ebenfalls die Angabe übernommen, wie viele Artikel der jeweiligen Position schon geliefert wurden. Die alten Daten bleiben dabei unangetastet. Der Nutzer hat danach die Möglichkeit, den Korrekturauftrag zu bearbeiten. Von den Stammdaten ist lediglich die voraussichtliche Ankunfszeit änderbar, die anderen Daten dürfen vom Nutzer nicht geändert werden. Die Auftragspositionen können jedoch editiert werden, wobei hier Grenzen gesetzt sind. So ist es nicht möglich, neue Auftragspositionen hinzuzufügen. Es kann lediglich die avisierte Anzahl geändert werden, und auch dies nicht beliebig. So darf die Anzahl nicht kleiner sein als die, welche schon geliefert wurde. Eine Korrektur nach oben ist nur möglich bis zu der Menge, die schon beim Kontraktlogistiker eingetroffen ist. Dadurch kann ein Auftrag nicht weiter nach oben korrigiert werden (außer, es wurde schon mehr geliefert als ursprünglich avisiert), und schon gelieferte Artikel können nicht aus einem Auftrag herausgenommen werden Auftrag bezahlen Zur Demonstration einiger typischer ERP-Funktionen wurde der Ablauf um die Möglichkeit erweitert, einen Auftrag bezahlen zu können. Dadurch wird MyERP um eine Funktionalität erweitert, welche eine logische Unterscheidung der Benutzer in Verkäufer und Buchhalter möglich macht. Diese Gruppen haben klar definierte Zuständigkeitsbereiche: Verkäufer erstellen und bearbeiten Aufträge, Buchhalter sind für die Bezahlung zuständig. In der vorgesehenen, vereinfachten Zahlungsmodalität bestimmt das Auftragsvolumen den Grundwert des an den Kontraktlogistiker zu zahlenden Betrages für einen Auftrag. Dabei wird für jeden Kontraktdienstleister festgelegt, wie viel Prozent des Auftragsvolumens an diesen zu zahlen ist; dies wird als Zahlrate bezeichnet. Zu- bzw. Abschläge für nicht angekündigte Teillieferungen, nachträgliche Änderungen des Volumens oder andere Fälle, werden nicht erhoben. Das Auftragsvolumen berechnet sich aus dem Wert eines Artikels multipliziert mit der Bestellmenge, aufsummiert über alle Auftragspositionen. 41

50 4. Konzept der Anwendungen ( ) Auftragsvolumen = Menge(i) Preis(i) (4.1) i Auftragspositionen Zahlbetrag = Auftragsvolumen Zahlrate (4.2) Die Bezahlung eines Auftrags ist weitgehend unabhängig vom Bearbeitungsprozess. Die Bezahlung kann für einen freigegebenen Auftrag geschehen, solange kein nachfolgender Korrekturauftrag existiert. Das heißt insbesondere, dass ein Auftrag bezahlt werden kann, bevor eine Lieferung eintrifft. Werden Abweichungen von dem ursprünglichen Avis durch einen nachfolgenden Auftrag korrigiert, so muss eine neue Bezahlung eingeleitet werden. Dabei ist für einen Auftrag und seine optionalen Korrekturaufträge nicht festgelegt, wann gezahlt werden muss. Daher muss bei der Zahlung eines Auftrags nicht nur das aktuelle Auftragsvolumen in Betracht gezogen werden, sondern auch die vorher geleisteten Zahlungen. In Abbildung 4.10 sind die Schritte aufgeführt, die vom System ausgeführt werden, sobald eine Bezahlung angestoßen wird. Zuerst werden die Bedingungen geprüft, ob der Auftrag überhaupt in einem Zustand ist, in dem er bezahlt werden kann. Wenn dem so ist, wird das aktuelle Auftragsvolumen berechnet. Aus diesem leitet sich durch Multiplikation mit der Zahlungsrate des Kontraktlogistikers der für diesen Auftrag zu zahlende Betrag ab. Steht der Zahlbetrag fest, so wird für alle Vorgänger des aktuellen Auftrags die geleistete Zahlungsmenge berechnet und aufsummiert, wobei schon getätigte Rückbuchungen subtrahiert werden. Zusammen mit dem zu zahlenden Betrag für den aktuellen Auftrag lässt sich somit der effektiv noch zu zahlende Betrag als einfache Differenz ermitteln. Dieser Betrag wird dann bei den Stammdaten des Auftrags vermerkt, und die Buchung wird erstellt. Im Anschluss wird der Auftrag sowie alle Vorgänger, bei denen dies noch nicht geschehen ist, als bezahlt markiert Buchhaltung Wie in anderen ERP-Systemen wie Openbravo (s. [ope12b]) lassen sich auch mit MyERP Buchungsvorgänge simulieren, wenn auch nicht direkt ausführen. Dabei werden in diesem Demosystem Buchungssätze erstellt und Konten zugewiesen, in denen Einträge für Soll und Haben vorgenommen werden. Da MyERP nur einen kleinen Teil der Geschäftsvorgänge des Herstellers Digital Media Devices erfasst, ist es nicht möglich, einen vollständigen Jahresabschluss zu erstellen. Es werden lediglich Buchungssätze vorbereitet, die vom Buchhalter später auszuführen sind. So haben sowohl Administratoren als auch Buchhalter keine Möglichkeit, einen einmal erstellten Buchungssatz zu manipulieren. Jeder Buchungssatz wird sofort erstellt, wenn die Bezahlung angestoßen wird. Außerdem ist in diesem eine Beschreibung vorhanden, aus welcher der Grund der Buchung hervorgeht, ob es sich also 42

51 4.2. MyERP activity Auftrag bezahlen [ Auftrag bezahlen ] Ist der Auftrag freigegeben? Nein Existiert ein Korrekturauftrag? Ja Ja Nein Berechne Auftragsvolumen Abbruch Berechne bereits geleistete Zahlungen Berechne zu zahlenden Betrag Ueberweisung erstellen : Bezahlung vermerken Abbildung 4.10.: Bezahlung eines Auftrags 43

52 4. Konzept der Anwendungen activity Bezahlung vermerken[ Bezahlung vermerken ] Auftrag als bezahlt markieren Existiert ein Vorgaenger? Nein Ja Vorgaenger laden : Bezahlung vermerken Abbildung 4.11.: Bezahlung vermerken, für einen Auftrag und seine Vorgänger um eine Buchung zur Zahlung, Nachzahlung oder Korrektur handelt. Zusätzlich wird bei jedem bezahlten Auftrag hinterlegt, welche Buchung zu diesem Auftrag gehört. Die Buchungssätze werden beim Bezahlen eines Auftrags im System erstellt. Da nur Einlagerungsaufträge an den Kontraktlogistiker umgesetzt wurden, wird immer vom ERP- System an das WMS gezahlt. Dementsprechend sind die Konten, auf denen gebucht wird, fest vorgegeben Benutzerrollen Die unterstützten Abläufe von MyERP können in zwei Zuständigkeitsbereiche aufgeteilt werden. Der erste Bereich umfasst die Pflege der Artikelstammdaten, das Anlegen und Bearbeiten von Aufträgen und die Behandlung der Problemfälle. Dieser Aufgabenbereich wird der Rolle der Verkäufer zugeordnet. Der zweite Aufgabenbereich umfasst die Veranlassung der Bezahlung von Aufträgen. Dieser Aufgabenbereicht wird der Rolle der Buchführer zugeordnet. Neben diesen Rollen gibt es noch eine dritte: Die Rolle Administrator, die auf alle Daten Zugriff hat. 2 Bei der Beschreibung der einzelnen Tabellen wird darauf eingegangen, welche Benutzergruppe welche Rechte auf der jeweiligen Tabelle besitzt, wobei Administratoren immer alle Rechte haben, wenn dies nicht explizit anders erwähnt wird. Es werden die typischen CRUD-Rechte unterschieden, also die Rechte zum Erstellen (von engl. create ), Lesen 2 Eine ähnliche Aufteilung findet sich beispielsweise beim Open-Source-ERP-System Openbravo. Dazu ist eine Anmeldung am Demosystem von Openbravo notwendig. Ist diese erfolgt, kann in der oberen Navigationsleiste über den Nutzernamen ein Kontextmenü geöffnet werden. Dort lassen sich die verschiedenen Rollen einsehen, welche aus Admin, Finance, Sales und Warehouse bestehen. Siehe [ope12b]. 44

53 4.2. MyERP (engl. read ), Bearbeiten (engl. update ) und Löschen (engl. delete ) von Datensätzen der entsprechenden Tabelle. Im Abschnitt wird dies noch einmal tabellarisch zusammengefasst Datenmodell Im Folgenden wird das Datenmodell beschrieben, mit welchem die vorher beschriebenen Vorgänge abgebildet werden. Dabei ist zu berücksichtigen, dass 4D als prozedurale Sprache keine Objekte im Sinne der objektorientierten Programmierung kennt. Das Konzept aus Abbildung 4.12 wurde als Datenbankschema direkt in 4D erstellt. Die einzelnen Tabellen werden im Folgenden beschrieben, wobei nur Fremdschlüssel erklärt werden sowie jene Felder, deren Bedeutung anhand des Namens nicht eindeutig ersichtlich ist. Der in den meisten Tabellen vorhandene Primärschlüssel hat den Bezeichner id und ist automatisch vergeben. Außnahmen sind die Tabellen erp_user, item, order_item und transaction_entry, welche andere Primärschlüssel besitzen. Fremdschlüssel auf andere Tabellen beginnen mit der Bezeichnung fid_, gefolgt vom Namen der referenzierten Tabelle Erläuterung der Tabellen Auftragsstammdaten order_core Zentrales Element des Modells ist die Tabelle order_core, welche die Stammdaten eines Auftrags aufnimmt. Diese verweist mit dem Feld fid_erp_user auf den Nutzer, welcher den Auftrag freigegeben hat. Das Feld fid_tpl verweist auf den Kontraktlogistiker (von engl. Third Party Logistics ), fid_customer verweist auf den Kunden, von dem ein Auftrag angenommen wurde. Dies ist für eine mögliche Erweiterung des Szenarios um Kundenaufträge eingefügt worden. Sofern ein Vorgängerauftrag existiert, wird über das Feld fid_predecessor auf diesen verwiesen. Dabei wird immer auf den direkten Vorgänger verwiesen, nicht auf den Ursprungsauftrag innerhalb einer Sequenz, auch wenn dies vom Aufbau der Datenbank her möglich ist. Über das Feld warehouse wird festgelegt, ob es sich um einen Einlagerungs- oder Kundenauftrag handelt. Außerdem wird bei den Stammdaten vermerkt, wann ein Auftrag freigeben wurde (Datum recorded) und wann er voraussichtlich ankommen soll (Datum eta, von estimated time (of) arrival ). Das Feld total_value bezeichnet den gesamten Auftragswert, amount_paid ist der für diesen Auftrag in der Buchung fid_transaction gezahlte Betrag. Dieser Wert kann negativ sein, wenn es sich um einen Korrekturauftrag mit einem geringeren Wert als der vorher schon bezahlte Ursprungsauftrag handelt. Der status bildet ab, wie weit der Auftrag schon bearbeitet wurde und ob es Probleme gab (s. vorherige Abschnitte bzw. Auflistung A.1 im Anhang). Die delivery_receipt_id ist die Lieferscheinnummer, die vom WMS im BOD NotifyReceiveDelivery mitgeliefert wird. Ist dieser Wert nicht 45

54 4. Konzept der Anwendungen Abbildung 4.12.: ER-Diagramm des Datenmodells, aufgenommen in 4D 46

55 4.2. MyERP Null, werden weitere BODs für diesen Auftrag mit einer Fehlermeldung zurückgewiesen. Das Feld invoice_paid gibt Auskunft darüber, ob ein Auftrag bezahlt wurde, während payable_until die Zahlungsfrist darstellt. Das Feld invoice_send ist nur in Kundenaufträgen von Belang; hier gibt es an, ob die Rechnung dem Kunden bereits zugestellt wurde. Auf dieser Tabelle haben Verkäufer alle Rechte, während Buchführern nur das Leserecht eingeräumt wurde. Ein Buchführer kann die Aufträge also sehen und später auch bezahlen, er kann sie aber nicht verändern. Nutzer erp_user Hier werden die Daten der Nutzer von MyERP gespeichert. Dabei wird die Nutzerverwaltung von 4D für die Rechte und Gruppen genutzt, weshalb auch der von 4D vergebenen Primärschlüssel in dem Attribut account_name gespeichert wird. Der Accountname entspricht dem Nutzernamen in 4D, zusätzlich werden Vor- und Nachname, das Geschlecht und die adresse von Nutzern gespeichert. Durch diese Tabelle ist es daher möglich, die üblichen 4D-Mechanismen zur Benutzerverwaltung zu nutzen und den Nutzern trotzdem selbst definierte Attribute hinzuzufügen. Diese Tabelle ist weder für Verkäufer noch für Buchführer sichtbar, da beide keine neuen Nutzer anlegen dürfen. Lediglich Administratoren haben Zugriff mit allen Rechten. Artikel item In der Tabelle item werden die Stammdaten der hergestellten und eingelagerten Artikel gespeichert. Als Primärschlüssel dient hier die GTIN (Global Trade Item Number), da diese einen Artikel global eindeutig identifiziert. Zu jedem Artikel wird gespeichert, wie oft dieser im eigenen Lager vorhanden ist und wie viele Exemplare insgesamt bei Kontraktdienstleistern vorgehalten werden. Neben den Größenangaben des Artikels wird außerdem festgehalten, ob dieser aktuell im Programm und somit aktiv ist. Wenn dies für einen Artikel nicht der Fall ist (weil dieser aus dem Programm entfernt oder durch einen Nachfolgeartikel ersetzt wurde), so soll er für neue Aufträge nicht zur Verfügung stehen. Die Verkäufer haben das Recht zum Lesen, Erstellen und Verändern auf der Tabelle und können somit die Artikelstammdaten verwalten. Buchführer dürfen lediglich die Daten einsehen. Auftragsbewegungsdaten (Auftragsposition) order_item Die Auftragspositionen werden in dieser Tabelle gespeichert, welche somit die Verbindung der Tabellen item und order_core darstellt, auf welche mit entsprechenden Fremdschlüsseln verwiesen wird. Diese Fremdschlüssel sind der zusammengesetzte Primärschlüssel für diese Tabelle. Dadurch kann jeder Artikel jedem Auftrag nur einmalig zugewiesen werden. Es wird jedem Datensatz in order_item zusätzlich eine id hinzugefügt, durch welche der Zugriff auf einen einzelnen Datensatz über nur dieses eine Feld gelingt. Im Feld quantity wird die 47

56 4. Konzept der Anwendungen avisierte Menge gespeichert, im Feld quantity_delivered die durch ein NotifyReceive- Delivery bestätigte gelieferte Menge. Für einen Korrekturauftrag wird ein eigener Satz von Bewegungsdaten erstellt, weshalb die Werte des Ursprungsauftrags nicht weiter angepasst werden. Daher lässt sich auch nach dem erfolgreichen Abschluss einer Sequenz jederzeit nachverfolgen, in welchem Schritt welche Artikel geliefert wurden. Diese Tabelle kann von Verkäufern und Buchführern eingesehen werden. Verkäufer haben zusätzlich das Recht, neue Datensätze zu erstellen und vorhandene zu bearbeiten. Kontraktlogistiker tpl Diese Tabelle identifiziert Kontraktlogistiker. Der Name tpl ist die gängige Abkürzung des englischen Begriffes third party logistics. Diese Tabelle wurde eingeführt, um mehrere Kontraktdienstleister unterstützten zu können. Das Feld logical_id ist die Kennzeichnung des Kontraktdienstleister innerhalb der BODs. Die payrate gibt an, welcher Prozentsatz des Auftragsvolumens als Zahlungsmenge vereinbart wurde, während pay_timelimit die Zahlungsfrist bezeichnet. Buchführer dürfen die Daten dieser Tabelle nur lesen, während Verkäufer zusätzlich erstellen und bearbeiten dürfen. Kunde customer Bei der angedachten Erweiterung des Szenarios um Kundenaufträge muss für jeden Auftrag nachgehalten werden, zu welchem Kunden dieser gehört. Konto account Diese Tabelle nimmt die Basisdaten eines Kontos auf. Einem Konto kann dabei ein übergeordnetes Konto zugeordnet werden, sodass sich eine Hierarchie aufbauen lässt. So kann das Konto Verbindlichkeiten Unterkonten für verschiedene Arten von Verbindlichkeiten oder Verbindlichkeiten gegenüber verschiedenen Parteien ausgestattet werden. Jedem Konto kann eine Farbe zugewiesen werden, um so einen zusätzlichen visuellen Hinweis zur Einordnung des Kontos zu ermöglichen, beispielsweise die Farbe blau für Verbindlichkeitskonten. Verkäufer können diese Tabelle einsehen, haben aber keine weiteren Rechte. Buchführer dürfen zusätzlich neue Datensätze erstellen. Auch Administratoren dürfen Datensätze nicht löschen oder verändern, um somit Manipulationen zu vermeiden. Buchung transaction Zu jedem Buchungssatz existiert genau ein Eintrag in dieser Tabelle, in welcher neben einer Beschreibung der Zeitpunkt der Erstellung festgehalten wird. Zu einer Buchung gehören immer mindestens zwei Buchungseinträge, einer im Soll, einer im Haben. Alle Nutzer können diese Tabelle nur einsehen, weitere Rechte sind nicht vorhanden. Die Datensätze werden vom System erstellt, nachdem ein Buchhalter eine Bezahlung initiiert 48

57 4.2. MyERP hat. Ein Eintrag, der einmal erstellt wurde, lässt sich also nicht mehr bearbeiten oder entfernen. Buchungseintrag transaction_entry Zu jeder Buchung gehören mindestens zwei, potentiell aber auch mehr Buchungseinträge. Der Index gibt die Reihenfolge der Einträge innerhalb einer Buchung an, eine eigene id ist nicht vorhanden. Jeder Eintrag kann entweder eine Buchung im Soll (debit) oder Haben (credit) sein, beides zusammen ist nicht möglich. Alle Nutzer können diese Tabelle nur einsehen, weitere Rechte sind nicht vorhanden. Die Datensätze werden vom System erstellt, nachdem ein Buchhalter eine Bezahlung initiiert hat. Ein Eintrag, der einmal erstellt wurde, lässt sich also nicht mehr bearbeiten oder entfernen Zusammenfassung der Rechte Die Tabelle 4.1 fasst die Rechte der einzelnen Benutzergruppen zusammen. Dabei werden die Rechte zum Erstellen (C, engl. create ), Lesen (Abgekürzt R von engl. read ), Bearbeiten (U, engl. update ) und Löschen (D, engl. delete ) von Datensätzen unterschieden und angegeben. Tabelle Administratoren Verkäufer Buchhalter Auftragsstammdaten C R U D C R U R Nutzer C R U D Artikel C R U D C R U R Auftragspositionen C R U D C R U R Kontraktlogistiker C R U D C R U Kunde C R U D C R U R Konto C R U R C R Buchung R R R Buchungseintrag R R R Tabelle 4.1.: Übersicht der Nutzerrechte Benutzeroberfläche Die Benutzeroberfläche von MyERP ist darauf ausgelegt, die vorgesehenen Abläufe zu unterstützten. In Abbildung 4.13 werden schematisch die Schritte zum Anlegen eines Auftrags gezeigt, Abbildung 4.14 zeigt das Anlegen eines Korrekturauftrages. Auf die Pflege der Stammdaten (Artikel, Kunden, Konten, Nutzer) wird nicht explizit eingegangen, da es sich hier lediglich jeweils um eine Auflistungsseite mit den vorhandenen Einträgen und einer Detailseite für die Pflege bzw. Neuanlage der Daten handelt. 49

58 4. Konzept der Anwendungen In den Eingabefeldern der schematischen Darstellungen steht hellgrauer Text für solchen, der vom Nutzer nicht geändert werden kann. Dabei werden in diesen Abbildungen nicht alle Felder gezeigt, da die Abfolge der Masken während der szenariotypischen Bearbeitung im Vordergrund steht. Im Text wird mit geklammerten Zahlen (3a) auf Teile der Abbildungen verwiesen, wobei die Teile 1 bis 5 in Abbildung 4.13 dargestellt sind, die Teile 6 bis 10 in Abbildung Anlegen eines Auftrags Beim Aufruf der Webseite muss sich ein Nutzer zunächst am System mittels üblicher Authentifizierungsmerkmale Benutzername und Passwort anmelden. Nach der Anmeldung gelangt er automatisch auf die Übersichtsseite der vorhandenen Aufträge (1). Über eine Menüleiste im oberen Teil des Bildschirmes ist es ebenso möglich, auf die vorhandenen Artikel, Kunden, Konten und Logistikpartner zuzugreifen. Ist der Nutzer ein Buchhalter, so kann er außerdem auf die Buchungen zugreifen, während ein Administrator noch weitergehende Rechte hat und zuerst eine kleine Übersichtsseite angezeigt bekommt. Um einen neuen Auftrag anzulegen, muss ein Nutzer Verkäufer sein und in der Menüleiste die Ansicht der Aufträge auswählen (sofern diese nicht schon ausgewählt ist), was zur Ansicht (1) führt. Diese gibt einen Überblick über die wichtigsten Daten der zuletzt erstellten Aufträge, wobei eine Navigation zu älteren Aufträgen ebenfalls möglich ist. So werden in der ersten Spalte Piktogramme dargestellt, die auf fehlende Zahlung (Auftrag 2) oder Probleme mit der Lieferung (Auftrag 3, Teil (6)) hinweisen. Dazu steht in der Übersicht unter anderem, welcher Nutzer einen Auftrag freigegeben hat, von welchem Kunden ein Auftrag erteilt wurde und welchen Status ein Auftrag besitzt. Von dieser Übersichtsseite aus ist es möglich, zu den Detailseiten der Aufträge, aber auch der verlinkten Kunden und Nutzer zu navigieren. Über den Button Neu kann ein neuer Auftrag erstellt werden. Die Ansicht (2) stellt einen neuen Auftrag beispielhaft dar. Als Kontraktlogistiker ist die Sped. Hurz voreingestellt. Der Auftragswert wird automatisch berechnet, sobald einem Auftrag Positionen hinzugefügt werden, was über den Button Neu im unteren Teil der Maske einem Verkäufer möglich ist. Dies führt zum Anlegen einer neuen Auftragsposition, welche wie in (3a) und (3b) dargestellt wird. Die Auftragsnummer wird dort passend zum Auftrag vom System ausgefüllt, die Positionsnummer ist ebenfalls voreingestellt. Ein Nutzer muss hier lediglich einen Artikel auswählen und die Bestellmenge des Artikels angeben. Ist ein Artikel schon in einer Auftragsposition des Auftrags vorhanden, so führt dies zu einer Fehlermeldung. Nachdem eine neue Auftragsposition angelegt wurde, wird der Nutzer zurück zur Auftragsansicht geführt. Diese wird aktualisiert, wie in (4) dargestellt. An dieser Stelle ist der Auftrag gespeichert, allerdings noch nicht an den Kontraktlogistiker übermittelt worden, sodass noch Änderungen vorgenommen werden können. Wird der Auftrag durch Betätigen 50

59 4.2. MyERP package MyERP [ Konzept Auftrag erstellen ]... Auftrag Artikel Kunde... Neu (1) AuftragsNr... Status 2... Abgeschlossen 1... Abgeschlossen Auftragsnummer: 3 (2) Auftragsnummer: 3 (3a) Kunde: Positionsnummer 8 Kontraktlogistiker: Sped. Hurz Artikel Testartikel 1 Auftragswert: 0 Menge 5 Auftragspositionen - 0 / 0 Neu Artikel Menge Geliefert Auftragsnummer: 3 Positionsnummer 9 (3b) Artikel Testartikel 2 Menge 5 Freigeben (4) Auftragsnummer: 3 Kunde: Kontraktlogistiker: Auftragswert: Sped. Hurz 300 Auftragspositionen - 2 / 2 Neu Artikel Menge Geliefert Testartikel 15 0 Testartikel (5) AuftragsNr... Status 3... Avis versendet 2... Abgeschlossen 1... Abgeschlossen Abbildung 4.13.: Diagramm: Beispielhafte Abfolge von Bildschirmmasken, um einen Auftrag zu erstellen. 51

60 4. Konzept der Anwendungen des Buttons freigegeben, so sind Änderungen nicht mehr möglich und das Avis, also das BOD vom Typ ProcessShipment, wird an den Kontraktlogistiker gesendet Anlegen eines Korrekturauftrages Sobald im MyERP eine Meldung über eine erhaltene Lieferung eingeht, also eine Nachricht vom Typ NotifyReceiveDelivery empfangen wird, wird diese vom System verarbeitet. Daraufhin wird der Status des betreffenden Auftrags aktualisiert. Ist die Lieferung wie avisiert eingetroffen, so steht im Statusfeld Abgeschlossen, wie dies im Beispiel bei den Aufträgen 1 und 2 zu sehen ist (1,5). Sind Differenzen aufgetreten, so spiegelt sich dies im Auftragsstatus wieder, wie in Abbildung 4.14 unter (6) für Auftrag 3 zu sehen ist. Beim Öffnen der Detailansicht eines solchen fehlerhaften Auftrags (7) erscheint ein neuer Button, mit dem sich ein Korrekturauftrag erstellen lässt (8). In diesen werden automatisch alle Informationen des vorherigen Auftrags übernommen. Im Gegensatz zu einem normalen Auftrag lassen sich keine Auftragspositionen mehr hinzufügen, die vorhandenen lassen sich allerdings anpassen (9a und 9b). So ist es möglich, die avisierte Menge nach unten zu korrigieren (9b), allerdings ist die schon gelieferte Menge das Minimum. Eine Korrektur nach oben ist nur bis zur bereits gelieferten Menge möglich. Sollen also noch mehr Artikel angekündigt werden als schon geliefert wurden, so muss dafür ein neuer Auftrag angelegt werden. Der Korrekturauftrag wird dann wie ein normaler Auftrag behandelt. Sobald er freigegeben wird, erhält das WMS ein neues Avis, welches ein BOD vom Typ ChangeShipment ist. Daraufhin wartet MyERP wieder auf eine Rückmeldung. Sind nach dieser noch immer Fehler vorhanden, so muss ein neuer Korrekturauftrag angelegt werden, bis die avisierte und gelieferte Menge aller Artikel übereinstimmen. 52

61 4.2. MyERP package MyERP [ Konzept Korrekturauftrag erstellen ]... Auftrag Artikel Kunde... (6) Neu AuftragsNr... Status! 3... Teile fehlen 2... Abgeschlossen 1... Abgeschlossen (8) Korrektur erstellen (7) Freigeben Korrektur fuer Auftrag 3 Auftragsnummer: 3 Auftragsnummer: 4 Kunde: Kunde: Kontraktlogistiker: Sped. Hurz Kontraktlogistiker: Sped. Hurz Auftragswert: 300 Auftragswert: 300 Auftragspositionen - 2 / 2 Artikel Menge Geliefert Testartikel 51 5 Testartikel Auftragspositionen - 2 / 2 Artikel Menge Geliefert Testartikel 15 5 Testartikel (9b) (9a) Auftragsnummer: 4 Auftragsnummer: 4 Positionsnummer 10 Positionsnummer 11 Artikel Testartikel 1 Artikel Testartikel 2 Menge 5 Bisher geliefert 5 Menge 5 Bisher geliefert 5 AuftragsNr... Status 4... Avis versendet 3... Korrigiert 2... Abgeschlossen 1... Abgeschlossen (10) Korrektur: Vorher 10 avisiert Abbildung 4.14.: Diagramm: Beispielhafte Abfolge von Bildschirmmasken, um einen Korrekturauftrag zu erstellen. 53

62 4. Konzept der Anwendungen 4.3. MyInventory von Andreas Beckers Dieses Kapitel beschäftigt sich mit dem konzeptionellen Aufbau des Demo Warehouse Management Systems MyInventory. Dabei wird zuerst das WMS-eigene Szenario beschrieben, also die Abläufe, die eine Demonstration eines WMS darstellen. Dazu gehört unter anderem der Eingang von Waren, das Umlagern dieser Waren auf Lagerhilfsmittel (LHM) wie zum Beispiel Paletten, sowie das anschließende Verteilen auf die Lagerplätze (Abschnitt 4.3.1). Nachdem beschrieben wurde, welche Abläufe das System unterstützt, wird das dazu benötigte Datenmodell beschrieben, also welche Entitäten (hier: Tabellen) dafür notwendig sind (Abschnitt 4.3.2). Im Anschluss daran wird noch die Konzeption der Benutzerschnittstelle für einen beispielhaften Ablauf des WMS-Szenarios erläutert. Genauer also, welche Sichten in welcher Form für die Demonstration benötigt werden (Abschnitt 4.3.3) Szenario Das zu entwickelnde Warehouse Management System MyInventory ist gemäß dem Szenario in verschiedene Bereiche unterteilt, die einzeln betrachtet werden. In Abbildung 4.15 ist für das WMS ein detaillierteres UML-Aktivitätsdiagramm abgebildet, das alle Kommunikationsvorgänge inklusive der OAGIS-ähnlichen Nachrichten enthält und dessen Aktivitäten in den folgenden Unterkapiteln verfeinert werden. Der Ablauf beginnt mit dem Eingang eines Avis, über eine Nachricht des Typs Process- Shipment, das über eine spätere Lieferung informieren soll und über einen Webservice empfangen wird. Diese Lieferankündigung wird im System schließlich bearbeitet und abgespeichert (Kap Avis anlegen). Nach Versand der Eingangsbestätigung über das OAGIS-nahe Objekt ConfirmBOD ist der Prozessablauf erst einmal unterbrochen, und zwar genau so lange, bis eine Lieferung eintrifft. Diese ist abhängig von dem zuvor gesendeten Avis. Die Lieferung, die in diesem Fall keine eingegangene Nachricht ist, ist ein Ereignis, also eine tatsächliche Lieferung, die schließlich durch einen Lagermitarbeiter über ein entsprechend bereitgestelltes Formular eingetragen wird (Kap Lieferung eintragen). Ist dies geschehen, kann von dem Mitarbeiter der Wareneingang eröffnet (Kap Wareneingang eröffnen) und die Vereinnahmung durchgeführt werden (Kap Vereinnahmung durchführen). Nach dieser Durchführung wird dann durch den Mitarbeiter der Wareneingang abgeschlossen (Kap Wareneingang abschließen). Dabei wird das angekoppelte System, das die Lieferung angekündigt hat, mittels des BODs Notify- ReceiveDelivery über diese Lieferung informiert. Der Mitarbeiter bekommt davon aber 54

63 4.3. MyInventory activity Szenario myinventory[ Szenario myinventory ] Avis eingegangen ProcessShipment : Avis anlegen Empfangsbestaetigung versenden ConfirmBOD Lieferung eingetroffen : Wareneingang eroeffnen Lieferung eintragen : Vereinnahmung durchfuehren Sende Lieferbenachrichtigung NotifyReceiveDelivery : Wareneingang abschließen : Einlagerung Korrigierter Avis eingegangen ChangeShipment ConfirmBOD : Avis korrigieren Ja Avis abgeschlossen? Nein Abbildung 4.15.: Das Szenario für MyInventory 55

64 4. Konzept der Anwendungen nichts mit, da dieser Vorgang eher technischer Natur ist, und ihn nicht von der Arbeit ablenken soll. Zu guter Letzt findet schließlich die Einlagerung (Kap Einlagerung) der gelieferten Artikel statt. Eine weitere Nachricht, die an das WMS MyInventory gesendet werden kann, ist das BOD ChangeShipment. Dieses ist wiederum abhängig von einer zuvor eingegangenen Lieferankündigung und hat den Zweck, diese zu korrigieren (Kap Avis korrigieren). Das kann zum Beispiel der Fall sein, wenn zu wenig geliefert wurde und auch keine Nachlieferung geschehen soll. Auch der Eingang einer solchen Nachricht wird über das Objekt ConfirmBOD bestätigt. Die einzelnen, komplexen Aktivitäten werden im Folgenden detailliert betrachtet Avis anlegen Der Eingang eines Lieferavis ist der erste Schritt der Abarbeitung in dem Szenario. Diese Aufgabe wird durch einen Webservice über den Empfang eines BODs ProcessShipment angestoßen. In Abbildung 4.16 ist der darauf folgende interne Ablauf dargestellt. activity Avis anlegen( ProcessShipment, ConfirmBOD )[ Avis anlegen ] Eintrag mit gleicher ID schon vorhanden? Nein Ja Avis-Eintrag in DB speichern Artikeldaten persistieren Ja Nein Unbekannte Artikel vorhanden? Artikel dem Avis zuordnen Erstelle Erfolgsmeldung Erstelle Fehlermedlung Erstelle Business Object Document ConfimBOD Sende synchrone Response Message Abbildung 4.16.: Anlegen eines Avis 56

65 4.3. MyInventory Zuerst wird überprüft, ob ein Avis mit derselben ID bereits versendet wurde. Dieser Fall ist nicht erlaubt, da anzunehmen ist, dass zu einem bereits versendeten Avis bereits Lagerplätze reserviert wurden und ein Überschreiben der Artikel zu Problemen in der Logistik führen könnte. Deshalb wird in diesem Fall als Rückantwort eine Fehlermeldung generiert. Für Änderungsmitteilungen zu einem bereits gesendeten Avis kann allerdings der zusätzliche Service über das BOD ChangeShipment genutzt werden. Das Konzept dahinter ist im Kapitel näher beschrieben. Wenn die Lieferankündigung noch nicht bekannt ist, wird ein entsprechender Datenbankeintrag erstellt. Des Weiteren werden alle dem System noch nicht bekannten Artikel persistiert. Nach der Zuordnung der angekündigten Artikel zu dem Datenbankeintrag wird schließlich eine Erfolgsmeldung generiert und als Antwort des Service-Aufrufs zurückgeliefert. Diese Nachricht ist als OAGIS-nahes BOD ConfirmBOD aufgebaut. Somit ist für das Service-aufrufende ERP-System sichergestellt, dass die Nachricht erfolgreich eingetroffen ist. Normalerweise wird nach Eingang eines Avis eine Riege von Aktivitäten durchgeführt. Es werden Lagerplätze reserviert oder sogar freigeräumt. Die ungefähre Ankunftszeit spielt dabei ebenfalls eine Rolle. In diesem Demo-WMS wird die Organisation der Lagerplätze jedoch nicht berücksichtigt. Der Fokus liegt mehr auf die Kommunikation sowie die Abarbeitung des Szenarios Lieferung eintragen Nach der Ankündigung einer Lieferung folgt als logischer Schritt die tatsächliche Lieferung von Artikeln. Diese trifft im Lager ein und wird durch einen Mitarbeiter entgegengenommen. Dann folgt die erste Interaktion durch den Mitarbeiter mit dem System MyInventory, nämlich die Eingabe aller relevanten Daten wie Lieferscheinnummer, das zugehörige Avis sowie alle gelieferten Artikel und deren Menge. Dazu wird ein entsprechendes Formular bereitgestellt, in welches die Daten vom Lieferschein eingegeben werden. Anschließend kann durch den Mitarbeiter der Wareneingang eröffnet werden. An dieser Stelle ist zu erwähnen, dass auch Lieferungen eintreffen können, die vorher nicht avisiert wurden. In diesem Fall ist MyInventory so konzipiert, dass die gelieferten Artikel den normalen Prozess des Wareneingangs durchlaufen. In der Eingabemaske zur Lieferung wird dabei kein Avis angegeben. Allerdings erfolgt dann keine Kommunikationsfolge zur Bestätigung der Lieferung. Der Mitarbeiter muss diese unangekündigte Lieferung manuell, zum Beispiel telefonisch, mit dem Händler klären. 57

66 4. Konzept der Anwendungen Wareneingang eröffnen Das Eröffnen des Wareneingangs beendet die Eingabe der Lieferung. Es können keine Änderungen mehr vorgenommen werden wie zum Beispiel das Hinzufügen weiterer Artikel. Der Prozess (Abb. 4.17) überprüft schließlich, ob die Lieferung avisiert wurde und wenn ja, ob alle Artikel vollständig geliefert wurden. activity Wareneingang eroeffnen [ Wareneingang eroeffnen ] Artikel dem Avis mit avisierter Menge null zuordnen Vorab Avis eingetroffen? Ja Ja Nein Nein Artikel in der Lieferung, die nicht avisiert wurden? Gelieferte Menge der Artikel von avisierter Menge abziehen Ja Alle avisierten Artikel eingetroffen? Avis als erledigt markieren Nein Eskalation Abbildung 4.17.: Wareneingang eröffnen Dabei gibt es mehrere Fälle zu berücksichtigen, die auch in Kombination auftreten können: 1. Es werden von einem oder von mehreren Artikeln zu wenig geliefert 2. Es werden von einem oder von mehreren Artikeln zu viel geliefert 3. Es werden ein oder mehrere Artikel geliefert, die nicht avisiert wurden 4. Es werden ein oder mehrere Artikel gar nicht geliefert 5. Die Lieferung wurde nicht avisiert In den ersten beiden Fällen wird in der Datenbank vermerkt, wie viele von den avisierten Artikeln tatsächlich geliefert wurden. Dabei wird am Ende überprüft, ob die gelieferte Menge der avisierten entspricht. Ist das nicht der Fall, wird das Avis nicht abgeschlossen, sondern bleibt als offener Datensatz bestehen. 58

67 4.3. MyInventory Wenn insgesamt zu viel geliefert wird (3. Fall), wird das Avis dennoch abgeschlossen. Für den gelieferten Überschuss wird eine Meldung generiert, da zuvor damit nicht geplant werden konnte und eventuell freier Platz extra bereitgestellt werden muss. Das gilt auch für den dritten Fall, in dem nicht avisierte Artikel geliefert wurden. Es werden neue Einträge in die Datenbank geschrieben aber die avisierte Menge auf Null belassen. So ist es später als Erweiterung des Systems möglich, auch für diesen Überschuss extra Kosten zu berechnen. Dies ist für das initiale Szenario aber nicht angedacht. Artikel, die gar nicht geliefert wurden (4. Fall), werden in der Datenbank nicht verändert. Die endgültige Prüfung des Avis sorgt schließlich dafür, dass das Avis nicht abgeschlossen wird. In dem Fall, dass der Lieferung kein Avis durch den Mitarbeiter zugeordnet wurde (5. Fall), wird anstelle der Benachrichtigung des normalerweise angebundenen ERP-Systems, eine Benachrichtigung an den Mitarbeiter ausgegeben. Diese besagt, dass er sich bei dem Händler, der die Lieferung versendet hat, zurückmelden soll. Eine Lieferung, die vorab nicht avisiert wird, stellt ein logistisches Problem für die Lagerverwaltung dar. Deshalb ist eine Eskalation durch den Mitarbeiten mit dem Händler vorgesehen, damit diese Probleme gelöst werden können Vereinnahmung durchführen Nach dem Eröffnen des Wareneingangs findet schließlich die Vereinnahmung der Artikel statt. Dabei wird jeder Artikel der Lieferung artikelrein auf Lagerhilfsmittel aufgeteilt. Das bedeutet, dass Artikel vereinzelt abgelegt werden. So befinden sich nur Artikel der gleichen Art auf jedem LHM. Dieser Vorgang soll die spätere Einlagerung erleichtern. activity Vereinnahmung durchfuehren[ Vereinnahmung durchfuehren ] Jedem Artikel ein Lagerhilfsmittel zuweisen Anzahl benoetigter LHMs bestimmen Vorhandene Anzahl der LHM reduzieren Abbildung 4.18.: Vereinnahmung durchführen Die Aufgabe des Mitarbeiters, der die Anwendung steuert, ist das Zuordnen von Lagerhilfsmitteln zu den gelieferten Artikeln, also zum Beispiel das Zuordnen einer Euro-Palette 59

68 4. Konzept der Anwendungen oder eines Kleinbehälters. Außerdem muss die Anzahl der benötigten LHM angegeben werden. Nachdem die Vereinnahmung durchgeführt wurde, wird schließlich vom System die Anzahl der noch vorhandenen LHM verringert (Abb. 4.18) Wareneingang abschließen Nach der Vereinnahmung ist es möglich, den Wareneingang abzuschließen (Abb. 4.19). Im System wird dabei der Tabelleneintrag als abgeschlossen markiert. Dieser Zustand aktiviert die Möglichkeit, mit der Einlagerung zu beginnen (Kap ). Im Hintergrund wird parallel die Kommunikation zum ERP-System initiiert, falls ein solches mit dem Kunden assoziiert ist. Dazu wird zuerst das OAGIS-nahe BOD NotifyReceiveDelivery erstellt und anschließend der Webservice angestoßen. Falls der Aufruf nicht erfolgreich ist, wird der Administrator über eine entsprechende Nachricht informiert. Durch dieses technische Problem wird der weitere fachliche Prozess der Einlagerung aber nicht gestört. Es obliegt dem Administrator, bei Kommunikationsproblemen einzugreifen. activity Wareneingang abschließen( NotifyReceiveDelivery ) [ Wareneingang abschließen ] Lieferung als abgeschlossen markieren ERP-System zur Benachrichtigung vorhanden? Ja Nein Erstellen des BODs NotifyReceiveDelivery ERP-System mittels Business Objekt informieren Auf synchrone Antwort ConfirmBOD warten Antwort erhalten? Ja Nein Antwort auswerten Nachrichtenuebermittlung erfolgreich? Ja Nein Administrator informieren Abbildung 4.19.: Wareneingang abschließen 60

69 4.3. MyInventory Einlagerung Nachdem der Wareneingang geschlossen wird, beginnt die Einlagerung der gelieferten Artikel. Die Lagerhilfsmittel werden zu bestehenden oder neuen Lagerplätzen transportiert und eingelagert. In dieser Anwendung wurde an dieser Stelle eine vereinfachte Lagerstrategie entworfen. Die Einlagerung ist in dem Szenario nicht vorgesehen, dennoch wurde eine Strategie implementiert, um das Demo Warehouse Management System runder zu gestalten. In Abbildung 4.20 ist der für diese Zwecke entworfene Algorithmus zu sehen. activity Einlagerung[ Einlagerung] Artikel entgegennehmen Nein Ja Nein Lagerplatz vorhanden? Kapazitaet ausreichend? Lagerkapazitaet ausgeschoepft? Nein Lagerplatz auffuellen Ja Ja Lagerplatz befuellen Nein Leerer Lagerplatz in einem Lager vorhanden, wo dieser Artikel schon gelagert wird? Ja Lagerplatz im gleichen Lager eroeffnen Neuen Lagerplatz eroeffnen Abbildung 4.20.: Einlagerung Zuerst wird überprüft, ob es schon in einem der vorhandenen Lager einen Lagerplatz mit dem einzulagernden Artikel gibt. Dieser Lagerplatz soll dann mit den Artikeln aufgefüllt werden. Reicht der Platz nicht aus, wird ein neuer Lagerplatz eröffnet. Dabei wird zuerst überprüft, ob es einen Lagerplatz in einem Lager gibt, in dem der Artikel schon gelagert wird. Schließlich sollen die gleichen Artikel nicht an unterschiedlichen Orten gelagert werden. Wenn aber kein Lagerplatz mehr vorhanden ist, wird ein neues Lager ausgewählt. 61

70 4. Konzept der Anwendungen Erste Priorität in diesem Algorithmus ist das Auffüllen von vorhandenen Lagerplätzen. So kann es auch vorkommen, dass erst einige Lagerplätze aufgefüllt werden, bevor ein neuer eröffnet wird. Die zweite Priorität ist das Eröffnen von Lagerplätzen im gleichen Lager des zuvor gelagert Artikels. Erst wenn keine dieser Bedingungen erfüllt ist, wird ein neues Lager für diesen Artikel gewählt. Dieser Algorithmus wird für alle vereinnahmten Artikel getrennt durchlaufen. Am Ende existiert dann ein Plan für das Einlagern der Artikel, wonach sich die Lagermitarbeiter richten können. Einige Aspekte werden bei diesem Algorithmus nicht beachtet. Das ist zum Beispiel die geografische Lage der Artikel. Es kann unter Umständen sinnvoller sein, nach näher liegenden Lagerplätzen zu suchen. Dadurch würde der Transportweg geringer ausfallen, als wenn zwischen den Lagerplätzen hunderte Meter Distanz wären. Ein weiteres Beispiel ist die Klassifikation der Artikel nach Häufigkeit der Ein- und Auslagerung. Für Artikel, die häufiger bestellt und eingelagert werden, ist ein Lagerplatz näher an der Wareneingangs- bzw. Warenausgangszone sinnvoller, wie es zum Beispiel bei der ABC-Klassifizierung beachtet wird. Dabei werden den Artikeln die Kategorien A, B oder C zugewiesen. Kategorie A für die Artikel, die am häufigsten umgelagert werden und Kategorie C für die Artikel, die am seltensten umgelagert werden (vgl. [ABC06]). Für die Demonstration eines Warehouse Management Systems soll jedoch die hier entwickelte Lagerhaltungsstrategie genügen Avis korrigieren Wenn eine Lieferung eingetroffen ist, aber die avisierte Menge nicht eingehalten wurde, ist das Avis noch nicht abgeschlossen und als offen markiert. In diesem Fall ermöglicht der Webservice zum Bearbeiten eines zuvor gesendeten Avis die Korrektur der avisierten Menge der Artikel. Des Weiteren kann auch ein Avis abgeändert werden, zu dem noch keine Lieferung eingetroffen ist. Das ist zum Beispiel dann der Fall, wenn eine angekündigte Lieferung kurzfristig umdisponiert wird und nicht mehr der angekündigten Menge entspricht. In Abbildung 4.21 ist für das System MyInventory der Prozess zum Korrigieren eines Avis dargestellt. Dabei müssen gewissen Fälle berücksichtigt werden, die in folgender Auflistung beschrieben sind: Es ist erlaubt, eine avisierte Menge zu erhöhen, falls zuvor Lieferungen des Artikels die vorherige Menge überschritten haben In allen anderen Fällen ist es nicht erlaubt, eine avisierte Menge zu erhöhen. Dafür ist der Service zum Anlegen eines neuen Avis vorgeschrieben Es dürfen keine neuen Artikel avisiert werden. Dazu ist ebenfalls der Service zum Anlegen eines neuen Avis vorgesehen 62

71 4.3. MyInventory activity Avis korrigieren( ChangeShipment, ConfirmBOD )[ Avis korrigieren ] Eintrag mit gleicher ID schon vorhanden? Neue oder unbekannte Artikel vorhanden? Artikel mit einer hoeher avisierten Menge vorhanden? Ja Nein Ja ETA abaendern Ja Nein Ja Nein Wurde von diesem Artikel bereits zu viel geliefert? Avisierte Menge anpassen Entspricht gelieferte Menge der nun bearbeiteten avisierten Menge? Nein Ja Avis als erledigt markieren Erstelle Erfolgsmeldung Erstelle Fehlermedlung Erstelle Business Object Document ConfimBOD Sende synchrone Response Message Abbildung 4.21.: Korrigieren eines Avis 63

72 4. Konzept der Anwendungen Wenn ein Avis geändert werden soll, das im System noch nicht vorhanden ist, wird eine Fehlernachricht erzeugt. Dies geschieht ebenfalls bei Eintritt einer der oben benannten Fälle. Diese Nachricht wird dann als Antwort, in der Form des Business Object Documents ConfirmBOD, zurückgegeben. Ansonsten wird das Avis entsprechend angepasst und eine Erfolgsmeldung in derselben Form zurückgegeben Datenmodell Damit eine Anwendung entwickelt werden kann, die die in Kapitel konzipierten Prozesse durchführt, wird ein geeignetes Datenmodell benötigt. In Abbildung 4.22 ist das Konzept für das Demo Warehouse Management System als UML-Klassendiagramm dargestellt, das ein Entity Relationship Diagramm repräsentiert. package myinventory[ Datenmodell] 0..1 * item_id -storagearea_id : int -capacity : int -quantity : int -description : String Item -item_id : int -description : String -gtin : String -width : int -height : int -depth : int -weight : float item_id 1 StorageArea item_id 1 * item_id * 1 * * customer_id 1 warehouse_id Receipt_Item -receipt_item_id : int -quantity : int -monopolized : boolean Advice_Item -advice_item_id : int -quantity : int -quantity_delivered : int Customer -customer_id : int -name : String -tel_nr : String -logicalid : String -_service_url : String -_service_soap_action : String -_service_method_name : String 1 Warehouse -warehouse_id : int -description : String -location : String * * customer_id 1 deliveryreceipt_id customer_id 1 * deliveryreceipt_id 1 * 1 * «stereotype» DeliveryReceipt_State [Enumeration] -Lieferung eingetroffen -Wareneingang eroeffnet -Vereinnahmung durchgefuehrt -Wareneingang abgeschlossen DeliveryReceipt -deliveryreceipt_id : int -confirmed : boolean -date : date -foreign_deliveryreceipt_id -state : DeliveryReceipt_State advice_id 1 * -advice_id : int -foreign_advice_id : String -date : date -finished : boolean MovementData Advice -movementdata_id : int -item_quantity : int -item_quantity_stored : int -stored : boolean -storagemean_quantity : int * 0..1 advice_id StorageMean -storagemean_id : int -quantity : int -description : String * storagemean_id 1 Abbildung 4.22.: Konzept des Datenmodells von MyInventory In diesem Modell sind für Artikel sowie für Kunden eigene Entitäten vorgesehen. Die Entität Customer enthält hierbei Kontaktdaten der Kunden wie Name und Telefonnummer. Aber auch technische Informationen wie Zugangsdaten zum Webservice und eine technische Kennung (logicalid) werden darin abgelegt. Diese werden benötigt, damit zum Einen der richtige Service zum Benachrichtigen über eingegangene Lieferungen genutzt 64

73 4.3. MyInventory wird, also zum Beispiel nicht der Service eines anderen Systems bzw. eines anderen Kunden. Zum Anderen wird die technische Kennung benötigt, damit beim Eingang eines Avis über den Webservice eine eindeutige Zuordnung zu einem Kunden hergestellt werden kann, da das System mit mehreren Mandanten arbeiten kann. Artikeldaten wie die Beschreibung, die global eindeutige Kennung GTIN oder Daten über die Größe und das Gewicht sind der Entität Item zugeschrieben. Die Daten eines eingehendes Lieferavis wird in Advice abgelegt. Dabei enthalten ist der Zeitpunkt des Zugangs sowie die mit übertragende Kennung des Fremdsystems. Diese dient der eindeutigen Referenzierung in dem verteilten System. Eine Referenz zu Customer sorgt dafür, dass jederzeit ein Rückschluss zum Kunden möglich ist. Des Weiteren kennzeichnet das Flag finished, ob dieses Avis bereits abgeschlossen ist, oder ob noch Lieferungen zu erwarten sind. Die Zuordnung von avisierten Artikeln zu den Artikeln, die im System persistiert sind, geschieht durch die zusätzliche Relationsentität Advice_Item. Dies wird mit einer n:m Assoziation realisiert und ermöglicht das zusätzliche Aufnehmen von Daten wie die Menge der avisierten Artikel sowie die gelieferte Menge der Artikel. Lieferungen werden in die Entität DeliveryReceipt gespeichert. Auch darin werden Ankunftszeit und die fremde Kennung (hier: Lieferscheinnummer) aufgeführt. Da auch Lieferungen eintreffen können, die zuvor nicht durch ein Avis angekündigt wurden, wird ebenfalls eine Referenz zur Kunden-Entität gehalten, wie es bei der Entität Advice der Fall ist. Dadurch ist ebenfalls, zu jeder Zeit, ein Rückschluss zum Kunden möglich. Die Attribute state und confirmed beschreiben den Zustand der Lieferung im System. Ersteres gibt den aktuellen fachlichen Zusammenhang an, also in welchem der Prozessschritte, die in Kapitel beschrieben sind, sich diese Lieferung gerade befindet. Das zweite Attribut beschreibt den Erfolg des Webservice Aufrufs, der zur Lieferbenachrichtigung über das BOD NotifyReceiveDelivery genutzt wird. Im Genaueren also, ob die Nachricht im anderen System angekommen ist oder ob es beim Versenden Probleme gab. Die Assoziation zwischen gelieferten Artikeln, dem Eintrag der Lieferung in Delivery- Receipt und dem Eintrag der Artikel in Item wird durch die Relationsentität Receipt- _Item realisiert. Einem Artikel wird hier zusätzlich zur gelieferten Menge auch hinterlegt, ob er bereits vereinnahmt wurde (Attribut monopolized) oder ob diese noch stattfinden muss. Die zur Vereinnahmung benötigten Lagerhilfsmittel, auch Ladehilfsmittel genannt, sind in der Entität StorageMean deklariert. Dazu gehört neben der Bezeichnung auch die Anzahl der noch zur freien Verfügung stehenden LHM. Zur Vereinnahmung selbst wird die Entität MovementData (Lagerbewegungsdaten) herangezogen. Einträge bezeichnen vereinnahmte Artikel die bereit zur Einlagerung sind und enthalten den einzulagernden Artikel selbst, welches LHM zur Vereinnahmung eingesetzt wird und wie viele davon benötigt wurden. 65

74 4. Konzept der Anwendungen Die einzulagernden Artikel werden in dieser Demoanwendung durch einen einfach gestalteten Algorithmus auf Lagerplätze aufgeteilt. Diese sind als Entität StorageArea modelliert. Darin enthalten ist zum Einen die verfügbare Gesamtkapazität, also wie viele Artikel insgesamt auf diesen Platz passen und zum Anderen die aktuelle Anzahl an eingelagerten Artikeln. Der Rückschluss zum Artikel selbst im System ist durch eine einfache Beziehung realisiert, denn es darf nur eine Artikelart pro Lagerplatz gelagert werden. Eine weitere Assoziation ist zum Lager selbst modelliert. Diese Entität Warehouse enthält schließlich die Beschreibung und den Standort des Lagers. Zur Eindeutigkeit jedes Eintrags aller Entitäten ist eine fortlaufende ID vorgesehen im Stile [Name der Entität]_id. Diese ID wird auch zur Referenzierung der einzelnen Entitäten eingesetzt Benutzerschnittstelle Die Benutzerschnittstelle ist konzeptionell so aufgebaut, dass der Ablauf der Aktivitäten des Szenarios angemessen durchgeführt werden kann. In Abbildung 4.23 ist der Pageflow des WMS für den Ablauf des Szenarios schematisch dargestellt. Zur Übersichtlichkeit werden andere Sichten, wie zum Beispiel für Listen und Detailformulare von Stammdaten, bewusst weggelassen. Nachdem sich der Benutzer der Anwendung eingeloggt hat, bekommt er die Übersichtsseite mit einigen Informationen über das Lager, Lieferungen und Avise zu sehen. Der erste funktionale Schritt des Mitarbeiters im Szenario ist das Eintragen einer eingegangenen Lieferung. Dafür navigiert er von der Übersichtsseite zur Seite mit der Auflistung der Lieferungen (1.). Dort hat er die Möglichkeit, über einen Button eine neue Lieferung einzutragen (2.). Auf der darauf folgenden Seite können nun alle Details zur Lieferung eingetragen werden. Dazu gehört vor allem die Pflichteingabe Lieferscheinnummer. Aber auch die Zuordnung zum Avis sowie die eigentlich gelieferten Artikel. Da zu einer Lieferung meist mehrere Artikel gehören, ist an dieser Stelle eine Liste von Artikeln vorgesehen, der mehrere Artikel inklusive der Mengenangabe hinzugefügt werden können. Wurden schließlich alle Angaben getätigt, kann der Wareneingang über einen Button eröffnet werden (3.). Wenn an dieser Stelle zum Beispiel die Lieferscheinnummer nicht eingegeben wurde, gibt es einen Hinweis, dass zuerst alle Pflichtfelder ausgefüllt werden müssen, damit der Wareneingang eröffnet werden kann. Nachdem der Wareneingang eröffnet ist, wird im Szenario als folgender Schritt die Vereinnahmung durchgeführt (Kapitel Vereinnahmung durchführen). Dazu ändert sich die aktuelle Seite der Lieferung dahingehend, dass keine neuen Artikel mehr hinzugefügt werden können. Des Weiteren gibt es nun in der Liste aller Artikel der Lieferung die Möglichkeit, für jeden einzelnen Artikel die Vereinnahmung mittels eines Buttons einzuleiten 66

75 4.3. MyInventory package myinventory[ Konzept Frontend ] Dashboard Avise Lieferungen myinventory 1) Anzahl abgeschlossener Avise Anzahl offener Avise Anzahl eing. Lieferungen Anzahl nicht bestaetigter Lieferungen Lager 1 Lagerplatz1 Auslastung 5% 5% x Item A zum Lagerplatz1 Bewegungen Dashboard Avise Lieferungen Neue Lieferung 2) Artikel Item A Item B LHM Palette Kiste Menge 2 1 Einlagerung 7) Einlagern Eingelagert Lieferung Status: Lieferscheinnummer Avis Kennung Artikel Item C 5 Lieferung eingetroffen Add L1 A1 Item A - 4 Item B - 2 Wareneingang eroeffnen 3) Lieferung Status: Lieferscheinnummer Avis Kennung Vereinnahmung durchgefuehrt L1 A1 Artikel Menge Vereinnahmung Item A Item B 4 2 6) Wareneingang abschliessen Lieferung Status: Wareneingang eroeffnet Lieferscheinnummer L1 Avis Kennung A1 Artikel Menge Vereinnahmung Item A Item B 4 2 Durchfuehren 4) Bewegung Artikel Item A Menge 4 Palette LHM 2 5) Vereinnahmung Abbildung 4.23.: Konzept des Frontends von MyInventory 67

76 4. Konzept der Anwendungen (4.). Für die Vereinnahmung muss dann schließlich in einem neuen Formular das Lagerhilfsmittel ausgewählt werden, das der Lagermitarbeiter zur artikelreinen Verlagerung genutzt hat. Des Weiteren muss hier auch die Anzahl der eingesetzten LHM angegeben werden (Pflichtfeld). Schließlich kann für diesen Artikel die Vereinahmung im System durchgeführt werden, bei der, wie im vorherigen Schritt, ebenfalls eine Validierung durchgeführt wird; also ob ein LHM ausgewählt wurde, und ob die Mengenangabe getätigt wurde (5.). Ist die Vereinnahmung für alle Artikel der Lieferung erfolgt, ändert sich der Button des vorherigen Formulars der Lieferansicht in einen Button, womit der Wareneingang abgeschlossen werden kann (6.). Der veränderte Status wird ebenfalls angezeigt und kennzeichnet den aktuellen Stand im Ablauf der Lieferabfertigung. Der Abschluss des Wareneingangs initiiert die Kommunikation zum fremden ERP-System. Davon bekommt der Lagermitarbeiter aber nichts mit, da diese Vorgänge für ihn irrelevant sind. Als letzten Schritt der Lieferabfertigung findet die Einlagerung statt. Diese kann in der Übersicht aller vereinnahmten Artikeln für jeden Eintrag durchgeführt werden. Dazu wird in der Listenansicht jeweils ein Button für noch nicht eingelagerte Artikel angezeigt (7.). Durch einen Klick auf diesen wird der in Kapitel beschriebene Einlagerungsalgorithmus ausgeführt. Das Ergebnis des Algorithmus wird als Information an den Mitarbeiter ausgegeben. Das Ergebnis ist schließlich, auf welche Lagerplätze die vereinnahmten Artikel untergebracht werden sollen. Diese Information kann der Lagermitarbeiter nun nutzen, um die Artikel vom Wareneingang wegzutransportieren. 68

77 5. Realisierung In diesem Kapitel wird beschrieben, wie die Konzepte aus Kapitel 4 umgesetzt wurden. Dabei wird zuerst erläutert, wie die Entwicklungsumgebung von 4D eingerichtet werden muss, damit mit der Realisierung begonnen werden kann. Dazu gehört auch die Installation des Plugins Lightning, durch das die Anwendungen über einen Webbrowser angesprochen werden können. Anschließend wird beschrieben, wie die zur Kommunikation benötigten Nachrichten in XML-Schemadateien umgesetzt wurden, um später zur Validierung in den Anwendungen zu dienen. Darauf folgend wird jeweils im Detail auf die Realisierung der Demoanwendungen My- ERP und MyInventory eingegangen. Dazu gehören unter anderem die Umsetzung der Schnittstelle selbst sowie der Aktivitäten des Szenarios. Diese beiden Realisierungskapitel für die Demonstratoren sind als in sich abgeschlossene Kapitel beschrieben. Das heißt, dass jeweils alle notwendigen Techniken und Umsetzungen erläutert werden. Deshalb kann es vorkommen, dass sich einige Erläuterungen wiederholen Entwicklungsumgebung und Betrieb von Andreas Beckers Für die Umsetzung der Konzepte der Demoanwendungen sowie für das Kommunikationsszenario muss die Umgebung zur Entwicklung mit der Rapid Prototyping Anwendung 4D und dem Plugin Lightning eingerichtet werden. In Kapitel wird dazu auf die Installation von 4D selbst eingegangen. Anschließend wird in Kapitel beschrieben, wie das Plugin Lightning installiert wird Installation 4D Die Entwicklung mit 4D findet im Client-Server Betrieb statt. Das bedeutet, dass sich der Entwickler mit dem 4D-Client an einem 4D-Server anmeldet und dort alle Quellcodes ablegt. Für die Entwicklung der Anwendungen wurde dazu eine virtuelle Maschine (VM) eingerichtet, auf der jeweils zwei Server-Instanzen von 4D installiert sind; jeweils eine für 69

78 5. Realisierung MyInventory und MyERP. Für die Anwendungen wird jeweils ein Projekt eingerichtet. Im 4D-Jargon nennt man diese auch Strukturen beziehungsweise Datenbankstrukturen. Bevor die Entwicklung beginnen kann, müssen noch die Ports konfiguriert werden, damit sich die beiden Anwendungen auf der VM nicht überschneiden. Dies erfolgt jeweils über die Konfigurationsoberfläche vom 4D-Server. In Abbildung 5.1 ist diese Oberfläche abgebildet. Abbildung 5.1.: Konfigurationsoberfläche einer Struktur im 4D-Server Zum Einen muss, wie in der Abbildung zu sehen, der TCP-Port des Webservers unabhängig voneinander eingestellt werden. Zum Anderen muss der Client-Server Port im gleichnamigen Reiter der Konfigurationsoberfläche angepasst werden. Die Entwicklung selbst findet auf getrennten Arbeitsplatzrechnern statt, auf denen jeweils der 4D-Client installiert ist. Darüber kann man sich schließlich mit dem Server über die IP-Adresse und dem im Reiter Client-Server vergebenem Port einloggen. Hierbei muss des Weiteren auch der Name der Datenbankstruktur angegeben werden, damit diese entsprechend geladen werden kann. Die Programmierung auf dem Client erfolgt in direkter Verbindung zum Server. Es muss also nicht extra eine Veränderung gespeichert oder hochgeladen werden; die Synchronisation der Daten erfolgt on-the-fly. In Abbildung 5.2 ist 70

79 5.1. Entwicklungsumgebung und Betrieb zusammengfasst die Systemarchitektur der kompletten Umgebung dargestellt. Abbildung 5.2.: Systemarchitektur der Demonstratoren und Nutzer Für den Fall, dass während der Entwicklung Fehler erzeugt werden, die nicht mehr behoben werden können, wird das Versionierungstool SVN eingesetzt, um auf frühere Versionen zurückgreifen zu können. Da die Dateien, die damit versioniert werden, auf einem anderen Server liegen, könnte selbst bei einem Systemausfall der erzeugte Code wiederhergestellt werden Installation des Lightning-Plugins Damit die 4D-Anwendungen über den Webbrowser genutzt werden können, muss das Plugin Lightning installiert werden. Dies gestaltet sich in wenigen Schritten die im Folgenden aufgelistet sind (vgl. [Lan11, S. 9 ff.]). 1. Zuerst muss die Lightning-Installation entpackt werden 2. In den Ordnern der Datenbankstrukturen der Demoanwendungen muss jeweils der Ordner Components erstellt werden 3. In diese Ordner muss die Hauptkomponente von Lightning kopiert werden ( GL Lightning.4dbase ) 4. In der Konfigurationsoberfläche der Datenbankstruktur muss jeweils die Standard- Homepage auf lightning-web/login.shtm umgestellt werden (siehe Abbildung 5.1, Pfade) 5. Anschließend muss man sich mit dem 4D-Client auf den 4D-Server einloggen und jeweils drei Datenbankmethoden in den Strukturen der Demoanwendungen editieren a) On Server Startup() (siehe Quellcode A.1 im Anhang) 71

80 5. Realisierung b) On Server Shutdown() (siehe Quellcode A.2 im Anhang) c) On Web Connection() (siehe Quellcode A.3 im Anhang) 6. Zum Schluss muss schließlich noch eine 4D-Methode mit dem Namen Ltg_List_- Get() erstellt und freigegeben werden. Das Freigeben erfolgt über die Methodeneigenschaften über die Option Shared by components and host database. Diese Methode dient dazu, dass in der Weboberfläche Auswahlboxen (Combo-Boxen) dargestellt werden können (siehe Quellcode A.4 im Anhang) Nach Durchführung dieser Schritte kann die Weboberfläche von Lightning über die IP- Adresse des Servers kombiniert mit dem Port des Webservers der Anwendung, aufgerufen werden. Dieser Port wird, wie im vorherigen Abschnitt beschrieben, in der Konfigurationsoberfläche angegeben. In dem Anmeldeformular der Lightning-Startseite kann man sich nun mit den in 4D eingerichteten Benutzern einloggen. Standardmäßig ist dies der Benutzer Designer, der zum Einrichten der Benutzeroberfläche gedacht ist, und der Administrator. Beide Benutzer besitzen zu Beginn kein Passwort. In den folgenden Abschnitten über die Realisierung der Demoanwendungen wird auf die Implementierung der Weboberflächen und der Verbindung zu den 4D-Anwendungen näher eingegangen. 72

81 5.2. Business Object Documents (BODs) 5.2. Business Object Documents (BODs) von Andreas Beckers Die für die Kommunikation zwischen den Demoanwendungen MyERP und MyInventory eingesetzten OAGIS-ähnlichen BODs werden durch XML-Schemadefinitionen (XSD- Dateien) realisiert. Die in Kapitel beschriebenen Datentypen sind dabei auf unterschiedliche XSD-Dateien verteilt und richtet sich so nach der Modularität von OAGIS. Der Kern einer jeden Nachricht sind die Business Objekte beziehungsweise die OAGIS- Nouns. Diese fachlichen Spezifikationen werden einzeln in den Unterordner Nouns ausgelagert, wie in Abbildung 5.3 zu sehen ist. / BODs/ ChangeShipment.xsd ConfirmBOD.xsd NotifyReceiveDelivery.xsd ProcessShipment.xsd Nouns/ BOD.xsd Item.xsd ReceiveDelivery.xsd Shipment.xsd Platform/ Meta.xsd Standalone/ ChangeShipment.xsd ConfirmBOD.xsd NotifyReceiveDelivery.xsd ProcessShipment.xsd Abbildung 5.3.: Verzeichnisstruktur der BOD-Realisierung Dabei ist der Typ Item in der Item.xsd nach OAGI-Spezifikation kein eigenständiges Noun, sondern ein Basisdatentyp innerhalb der Components. Zur Einfachheit halber wurde dieser Typ aber in eine eigene Schemadatei ausgelagert, da in der Konzeption der ganze Bereich Components aus diesem Grunde entfernt wurde. Die konzipierten Types der OAGIS-Nouns sind in den entsprechenden XSD-Dateien untergebracht. So ist zum Beispiel der BODType aus der Abbildung 4.1 in der Datei BOD.xsd zu finden. Da das Noun ReceiveDelivery eine spezialisierte Form von Shipment ist, 73

82 5. Realisierung wird in der Realisierung von ReceiveDelivery die Schemadefinition von Shipment inkludiert. Durch das XML-Schema Element <xs:extension...> wird der neue Typ abgeleitet. In Quellcode 5.1 in Zeile 16 ist dies im Auszug aus der Implementierung von ReceiveDelivery.xsd zu sehen. 10 <xs:include schemalocation="item.xsd"/> 11 <xs:include schemalocation="shipment.xsd"/> <! Extension of Shipment Header Type > 14 <xs:complextype name="receivedeliveryheadertype"> 15 <xs:complexcontent> 16 <xs:extension base="shipmentheadertype"> 17 <xs:sequence> 18 <xs:element name="deliveryreceiptid" type="xs:string" /> 19 <xs:element name="datearrival" type="xs:date" /> 20 </xs:sequence> 21 </xs:extension> 22 </xs:complexcontent> 23 </xs:complextype> Quellcode 5.1: Auszug der Implementierung des Nouns ReceiveDelivery Die OAGIS-Verbs selbst enthalten für die Demonstratoren keine Daten sondern benennen nur eine Aktion, die auf die Business Objekte (Nouns) angewendet werden sollen. Deshalb befinden sich diese in der gesonderten Datei Meta.xsd. In dieser Datei sind außerdem auch die anderen, nicht-fachlichen Inhalte wie die ApplicationArea und die darin enthaltenen Definitionen untergebracht. Die BODs selbst sind ebenfalls neue XML-Schema Dateien, die die vorher erstellten Schemata inkludieren. In der DataArea werden darin die Nouns und Verbs zusammengefasst. Durch Erweiterung des allgemeinen Typs BusinessObjectDocumentType wird schließlich die ApplicationArea geerbt und durch die vorher erstellte DataArea erweitert. Dieser neue Typ wird schließlich genutzt, um das Element des BODs zu deklarieren, das tatsächlich über eine XML-Instanz ausgetauscht wird. In Quellcode 5.2 ist zum besseren Verständnis die Umsetzung des BODs NotifyReceiveDelivery zu sehen. 12 <xs:element name="notifyreceivedelivery" type="notifyreceivedeliverytype" /> <xs:complextype name="notifyreceivedeliverytype"> 15 <xs:complexcontent> 16 <xs:extension base="businessobjectdocumenttype"> 17 <xs:sequence> 18 <xs:element name="dataarea" type="notifyreceivedeliverydataareatype" /> 19 </xs:sequence> 20 </xs:extension> 21 </xs:complexcontent> 22 </xs:complextype> <xs:complextype name="notifyreceivedeliverydataareatype"> 25 <xs:sequence> 74

83 5.2. Business Object Documents (BODs) 26 <xs:element name="notify" type="notifytype" /> 27 <xs:element name="receivedelivery" type="receivedeliverytype" /> 28 </xs:sequence> 29 </xs:complextype> Quellcode 5.2: Implementierung des BODs NotifyReceiveDelivery Dieser Aufbau des BODs ist OAGIS-konform. Es werden lediglich unbenutzte Strukturen weggelassen. Die so gekapselten und modular aufgebauten BODs befinden sich im gleichnamigen Ordner. Die Inklusionen der anderen Schemadateien sind relativ zu diesem Ordner realisiert. Im Ordner Standalone befinden sich des Weiteren noch einmal alle BODs, die aber in sich abgeschlossen und nicht mehr von anderen XSD-Dateien abhängig sind. Diese flachen Dateien wurden durch das Flattening der zuvor erstellten BODs realisiert (siehe Grundlagenkapitel 2.3.3). Ein Grund für diese zusätzlichen Dateien ist, dass die XML- Validierung in dem RAD-Tool 4D selbst nur gegen solche flachen Dateien möglich ist. Dieses Problem konnte durch verschiedene Testfälle verifiziert werden. Dazu wurde zuerst eine Validierung einer Beispiel-XML-Instanz gegen die modularen Schemadateien lokal durchgeführt. Nach Erfolg dieses Tests wurde die gleiche XML-Instanz ohne Erfolg über 4D validiert. Anschließend wurden die Inklusionen von einem relativen Pfad auf den absoluten Pfad des Webservers umgestellt. Auch dies blieb ohne Erfolg. Erst die Validierung gegen eine flache Schemadefinition erbrachte den gewünschten Erfolg. 75

84 5. Realisierung 5.3. MyERP von Stefan de Bucourt Dieses Kapitel beschäftigt sich mit der Umsetzung des Konzeptes von MyERP. Im Abschnitt wird auf 4D als Datenbankmanagementsystem eingegangen, bevor die realisierte Datenbank beschrieben wird. Der folgende Abschnitt befasst sich mit der Oberflächengestaltung mit Lightning, bevor in die Realisierung des Logbuchs beschrieben wird. Abschnitt erläutert die verschiedenen Werte des Auftragsstatus. Daran schließt sich in Abschnitt eine Beschreibung der wichtigsten in 4D realisierten Funktionen von MyERP an, die nicht eindeutig einer Aktivität zugeordnet werden können, bevor die konkrete Umsetzung der Nutzeraktivitäten beschreibt Datenbank Da 4D über ein eigenes Datenbankmanagementsystem (DBMS) verfügt, wird dieses hier vorgestellt und für die Datenhaltung genutzt. In Abbildung 5.4 ist die erstellte Datenbank im 4D-eigenen Editor zu sehen; auf die Unterschiede der Tabellen zum Konzept wird in Abschnitt eingegangen D als Datenbankmanagementsystem (DBMS) Die Datenbank wird in 4D über einen grafischen Editor erstellt und eingerichtet. In diesem Editor werden die einzelnen Tabellen angelegt, in welchen dann Felder erstellt werden können. Über ein Kontextmenü können Eigenschaften bestimmt werden, beispielsweise Einschränkungen ( constraints ) und Datentypen für die Felder oder aktive Trigger für einzelne Tabellen. Aber auch die Relationen der Tabellen lassen sich im Editor realisieren, wobei lediglich Beziehungen vom Typ 1:n hier realisiert werden können. 1 Bei diesen lässt sich im Kontextmenü einstellen, dass eine Verbindung von 4D automatisch verwaltet wird, wobei in diesem Fall ein Feld für die Auswahlanzeige festgelegt werden kann. Die automatische Verwaltung bewirkt, dass 4D beim Laden eines Datensatzes aus Tabelle A alle mit ihm verbundenen Datensätze aus Tabelle B direkt selektiert (s. [4D 12b], S. 1338). Zusätzlich wird in einem 4D-Formular die Eingabe eines Fremdschlüssels erleichtert. Wenn der Automatische Joker bei einer Relation aktiviert ist (was bei Auswahl einer Auswahlanzeige standardmäßig passiert), wird bei partieller Eingabe in ein Fremdschlüsselfeld ein neues Fenster geöffnet, in welchem die vorhandenen Datensätze mit ihrem Schlüssel und der Auswahlanzeige aufgelistet sind. Diese können dann ausgewählt werden, was in Abbildung 5.5 dargestellt wird. 1 In der Dokumentation von 4D werden 1:1-Beziehungen erwähnt, auf die Umsetzung wird jedoch nicht eingegangen (siehe [4D 12b, S. 166], Eine-zu-Eine Verknüpfungen ). 76

85 5.3. MyERP Abbildung 5.4.: Screenshot des ER-Diagramms der Datenbank, aufgenommen in 4D 77

86 5. Realisierung (a) Formular mit Fremdschlüssel (b) Auswahl der Fremdschlüssel Abbildung 5.5.: Screenshot aus 4D, Eingabeformular für Auftragspositionen mit Fremdschlüsseleingabe Sobald man in diesem Editor eine Tabelle, eine Relation oder ein Feld erstellt, löscht oder verändert, hat dies Auswirkungen auf die Datenbank und die gesamte Anwendung; die grafische Repräsentation ist somit jederzeit gleich der aktuellen Datenbank. So wird der Quelltext der Anwendung von 4D automatisch angepasst, wenn sich bei einer Umgestaltung der Anwendung ein Feldbezeichner in der Datenbank verändert. Wird ein Feld gelöscht, so wird der entsprechende Zugriff nicht entfernt, sondern lediglich der Feldbezeichner. Beispielsweise wird aus [Tabelle]Feld:=5 so [Tabelle]:=5, was bei der Ausführung oder einem Syntaxcheck zu einem Fehler führt. In 4D sind auch Tabellen- und Feldbezeichner möglich, die in SQL reservierte Wörter sind. So kann der Name erp user (man beachte das Leerzeichen) vergeben werden, ebenso wie order, was in SQL ein reserviertes Wort ist (für die Anweisung order by). Dies führt jedoch dann zu Problemen, wenn mittels in 4D eingebetteten SQL-Befehlen auf die Datenbank zugegriffen wird. Dies ist der Grund, warum solche Bezeichner vermieden wurden. Außerdem könnten Probleme entstehen, wenn die Anwendung mit anderen Anwendungen oder Datenbanken interagieren muss. Aus dem gleichen Grund wurde auch kein Gebrauch von der Möglichkeit gemacht, in Bezeichnern Umlaute und Leerzeichen zu benutzen, auch wenn dies in 4D zwar problemlos möglich ist. Ein weiterer Unterschied zu anderen SQL-Datenbanken wie Oracle oder MySQL ist, dass ein zusammengesetzter unique-constraint nicht auf mehrere Felder einer Tabelle angewendet werden kann. Zwar ist es durchaus möglich, einzelne Felder als unique zu deklarieren, aber eine Kombination von zwei Feldern ist nicht gelungen. Ein zusammengesetzter Primärschlüssel ist jedoch problemlos möglich, indem mehrere Felder einer Tabelle markiert 78

87 5.3. MyERP und über das Kontextmenü als Primärschlüssel definiert werden Abweichungen vom Konzept Das Konzept der Datenhaltung (Abschnitt auf Seite 45) musste an zwei Stellen erweitert werden. Dabei handelt es sich um zwei Tabellen, die so nicht vorgesehen waren, und zwar die Tabellen dashboard und log, deren Aufbau unter und beschrieben wird. Hinzu kommt die Tabelle prize_history, welche genutzt wurde, um das 4D-Konzept der unsichtbaren Tabelle zu testen. Die Tabelle und die Auswirkungen der Markierung als unsichtbar werden in beschrieben. Die Tabelle customer wurde in Vorbereitung einer Szenarioerweiterung um Kundenaufträge eingeführt und wird in beschrieben. Übersicht dashboard Diese Tabelle wurde angelegt, um in Lightning eine Übersichtsseite mit Optionen für Administratoren anzeigen zu können. Eine eigene Tabelle ist nötig, da in Lightning jedes Formular und damit jede darstellbare Seite zu einer Tabelle gehören muss. Die Tabelle hat lediglich eine ID als Primärschlüssel, aber sonst keine Einträge, da sie nur zur Anzeige der Testfunktionen genutzt wird. Daher wird der Aufbau im Testkapitel unter beschrieben. Die Tabelle und damit die Anzeige ließe sich um einige statistische Größen wie die Anzahl offener Rechnungen erweitern, was in MyInventory umgesetzt wurde. Beschrieben wird diese Umsetzung im Abschnitt Tabelle Dashboard für die Weboberfläche. Logbuch log In der Logbuch-Tabelle werden im Quellcode generierte Logeinträge aufgenommen. Dabei wird jedem Eintrag ein log_level zugewiesen, welches die Art des Eintrags widerspiegelt. Hinzu kommt die Quelle des Eintrags, für gewöhnlich die aufrufende Funktion, sowie die eigentliche Nachricht und der Zeitpunkt der Erstellung. Genaueres dazu ist im Abschnitt Logbuch erläutert. Kunden customer Eine Verwaltung von Kundendaten ist Bestandteil vieler ERP- Systeme (vgl. [SAP12, Ope12c]. Diese wurde jedoch nicht umgesetzt, da das Hauptaugenmerk der Demoanwendung nicht auf ERP-Funktionalität, sondern auf den Einlagerungsaufträgen bei MyInventory liegt. Da die Erweiterung der Demonstratoren um Kundenaufträge realistisch erscheint, wurde zumindest diese Tabelle eingefügt, um den Aspekt der Kunden im System zu erhalten. Auch besitzt die Tabelle order_core den booleschen Wert warehouse, welcher bei einer Erweiterung des Szenarios darüber Auskunft gibt, ob es sich um einen Einlagerungs- oder Kundenauftrag handelt. 79

88 5. Realisierung Preisverlauf price_history Es wurde mit der Tabelle eine Funktion von 4D getestet, indem diese Tabelle als unsichtbar markiert wurde. Dies wird im Editor, wie in Abbildung 5.4 dargestellt, mit dem kursiv geschriebenen Namen angezeigt. Es bewirkt, dass in einigen Standardeditoren von 4D, zum Generieren von Abfragen, diese Tabelle nicht angezeigt wird. Sie ist allerdings weiterhin vorhanden, und Zugriffe auf die Tabelle aus dem Quellcode werden nicht eingeschränkt (s. [4D 12b, S. 144]). In Lightning jedoch wird die Tabelle nicht angezeigt, und auch direkte Zugriffe sind nicht mehr möglich. Der Preisverlauf wurde ausgewählt, weil er als sinnvolle Erweiterung der ERP-Funktionalität angesehen werden kann. Wenn sich der Preis eines Artikels ändert, so ist es wünschenswert, diese Änderungen nachzuhalten. Mit dieser Tabelle ist es möglich, bei jeder Änderung eines Artikels über einen save existing record-trigger diese Tabelle zu aktualisieren. In der Tabelle wird für jeden Preis eines Artikels ein Eintrag erstellt, welcher über die Fremdschlüsselbeziehung fid_gtin auf den Artikel verweist. Gespeichert würde in dieser Tabelle neben dem Preis und der Referenz das Datum, zu welchem dieser Preis festgelegt wurde sowieso das Datum, bis zu welchem der Preis gültig war. Zusammen mit den Verkaufszahlen, die sich aus den Auftragspositionen für einen Zeitraum ergeben, könnten so Berichte generiert werden, inwieweit sich bei einem Artikel die Preisänderungen auf den Verkauf ausgewirkt haben. Dabei müssten die Daten der beiden Tabellen auf verschiedene Art in Relation gebracht und als Graphen aufbereitet werden. Da dies allerdings keinerlei Einfluss auf die Kommunikation mit dem WMS hat, wurde diese Funktionalität nicht umgesetzt Grafische Benutzeroberfläche mit Lightning Die Grafische Benutzeroberfläche (GUI) wurde mit dem 4D-Plugin Lightning von Graham Langley Limited entworfen. Das Plugin gibt dabei das Grundgerüst der Webseite vor, Anpassungen daran sind nur im Detail möglich. Dafür sind die entsprechenden Seiten einfach zu gestalten, und viele Funktionen, abgestimmt auf 4D, werden von Haus aus mitgeliefert. Die Möglichkeit einer eigenen 4D-Oberfläche als Standalone-Anwendung wurde nicht genutzt Oberfläche mit 4D Auch 4D bietet die Möglichkeit, einfach eine Oberfläche zu gestalten. So lassen sich Einund Ausgabeformulare mit einem Wizard sehr schnell generieren. Da MyERP aber für den Einsatz in der Cloud über einen Webbrowser bedient werden muss, wurde von dieser Möglichkeit kein Gebrauch gemacht. Es wurden lediglich Standardformulare angelegt, die im 4D-Editor, nicht aber als eigene Applikation, erreichbar sind. Diese Formulare gestatten dem Designer die direkte Manipulation der Daten, und sind so für die Testphase sehr hilfreich. 80

89 5.3. MyERP Aufbau der Seite Wie auch 4D unterstützt Lightning einen Rapid-Prototyping-ähnlichen Ansatz: wenn sich ein Benutzer als Designer anmeldet, hat er jederzeit die Möglichkeit, die Benutzeroberfläche zu verändern, ohne zwischendurch die Anwendung neu starten oder kompilieren zu müssen. Der Aufbau der Webseite ist von Lightning vorgegeben und orientiert sich stark am Aufbau der Datenbank. Es stehen auf jeder Seite im oberen Bereich ein Suchfeld und eine Reiterleiste (Tab Bar) zur Verfügung, deren Einträge ein Designer ändern kann. Darunter findet sich eine Seitenleiste (Sidebar) mit den zuletzt benutzten Entitäten sowie der Möglichkeit, schnell Datensätze einzelner Tabellen zu erzeugen; dieser Bereich lässt sich ein- und ausblenden 2. Rechts daneben befindet sich der Inhaltsbereich (Content Area) der Seite. Dort wird der Inhalt der Tabelle dargestellt, die im Reiter ausgewählt wurde. Die Abbildung 5.6 stellt die Übersichtsseite der Aufträge dar. Abbildung 5.6.: Lightning-Übersichtsseite für Aufträge Lightning-Formulare Die Benutzeroberfläche besteht aus Formularen, wobei für jede Tabelle beliebig viele verschiedene Formulare angelegt werden können. Diese bestehen aus HTML-Befehlen, vermischt mit spezifischen Tags aus 4D und Lightning. So beginnt jedes Formular mit dem Tag <ltg-form>. Dabei gilt, dass jedes Formular einen Namen besitzt, welcher mit dem Attribut name angeben werden kann. Ferner muss ein Formular zu einer Tabelle gehören, welche mit table="[4d-tabelle]" angegeben wird. Die einzelnen Formulartypen sind: 2 Wenn ein Browser genutzt wird, um sich an mehreren Lightning-Systemen anzumelden, so wird die linke Auswahlleiste entweder in allen Anwendungen oder in keiner angezeigt. 81

90 5. Realisierung List-Form (Listenformular) Eine Auflistung der vorhandenen Datensätze als Tabelle. Standardansicht, wenn eine Tabelle im Reiter ausgewählt wird. Kann Navigationsmöglichkeiten in die referenzierten Datensätze anzeigen, wie in Abbildung 5.6 zu sehen. Detail-Form (Detailformular) Das Detailformular, auf dem ein einzelner Datensatz einer Tabelle angezeigt wird. Wird für das Anlegen, Ansehen und Bearbeiten von einzelnen Datensätzen eingesetzt. Select-Form (Auswahlformular) Ist eine Tabelle über einen Fremdschlüssel referenziert, so wird ein vorhandenes Auswahlformular genutzt, um die Auswahl des referenzierten Datensatzes aus dieser Tabelle zu erleichtern. Ist kein Auswahlformular vorhanden, so wird hierfür ein Standarformular generiert, welches den Primärschlüssel und ein weiteres Feld beinhaltet, das in den Eigenschaften der Tabelle ausgewählt werden kann. Custom-Form (Spezialformular) Dies ist frei gestaltbar. Kann in anderen Formularen mittels <ltg-include> eingebunden oder als Ziel einer Methode genutzt werden. Klickt ein Nutzer auf den Reitereintrag einer Tabelle, so kommt er zur Listenansicht eben dieser Tabelle. Dort können dann Verlinkungen auf Detailseiten erfolgen, zum Beispiel auf die Detailseite des Auftrags über die Auftragsnummer und die Seite des Kunden über dessen Namen. Logik in Formularen In den Formularen muss nur ein Teil eines HTML-Dokuments angeben werden, da die Formulare in den vorhanden Rahmen von Lightning eingebaut werden. Es stehen alle Möglichkeiten von HTML zur Verfügung. Diese werden zusätzlich erweitert. Zum Beipsiel gibt es spezielle 4D-HTML-Tags. Diese sind als HTML-Kommentare aufgebaut und haben die Form <!-- #4DBEFEHL [Parameter] -->. Mit ihnen lassen sich beispielsweise beliebige 4D-Funktionen Aufrufen (Befehl 4DSCRIPT), andere Seiten einfügen (Befehl 4DINCLUDE) und logische Verzweigungen realisieren (Befehle 4DIF, 4DELSE und 4DENDIF). Zusätzlich zu diesen Befehlen stellt Lightning ab der Betaversion 1.6 eigene Tags für Logik zur Verfügung. Dies sind <ltg-if> und <ltg-else> sowie <ltg-switch> und <ltg-case>. Die Funktionalität dieser Befehle ließe sich zwar mit den 4D-If-HTML-Tags erreichen, jedoch sind die 4D-Tags in Kommentare eingebettet. Die Lightningbefehle hingegen folgen der XML-Syntax, was diese im Quellcodeeditor auffälliger macht. Ein Vergleich der beiden Stile liefern das Beispiel 5.3 für die 4D-Syntax und 5.4 für die Lightning-Syntax. 1 <! #4DIF (bedingung=true) > 2 <! #4DIF ((x > 20) & (y<10)) > 3 <p>erfolg</p> 4 <! #4DELSE > 5 <p>wenig Erfolg</p> 82

91 5.3. MyERP 6 <! #4DENDIF > 7 <! #4DENDIF > Quellcode 5.3: Einfaches If-Else mit 4D-HTML-Tags 1 <ltg if test="bedingung=true"> 2 <ltg if test="((x > 20) & (y<10))"> 3 <p>erfolg</p> 4 <ltg else/> 5 <p>wenig Erfolg</p> 6 </ltg if> 7 </ltg if> Quellcode 5.4: Einfaches If-Else mit Lightning-Tags Neben den Logiktags von Lightning werden allerdings noch andere Tags bereitgestellt. Diese sind für die Ein- und Ausgabe der Daten zuständig. Ein <ltg-field> stellt ein einzelnes Tabellenfeld dar, spezifiziert über das Attribut name="[tabelle]feldbezeichner". Dabei kann über die Attributszuweisung mandatory="true" angegeben werden, dass es sich um ein Pflichtfeld handelt. Die Angabe readonly="true" erzeugt ein Feld, das lediglich zur Ausgabe von Daten geeignet ist. Dabei werden die Felder in einem Detailformular immer als HTML-Eingabefelder dargestellt und in Listenformularen als einfacher Text ausgegeben. Die Felder werden von Lightning mit schon vorhandenen Daten gefüllt und sorgen dafür, dass Nutzereingaben nach dem Speichern auch in der Datenbank persistiert werden. Durch eine <ltg-caption> kann einem Eingabefeld eines Detailformulars eine Beschriftung zugewiesen werden. Für die Ausgabe in Listenformularen gibt es den Befehl <ltg-sort>, welcher ebenfalls über das Attribut name an ein Tabellenfeld gebunden wird. Zusätzlich wird ein Titel angegeben. Mit diesen Sortierungstags wird die Kopfzeile der Tabelle aufgebaut, welche die Liste der Datensätze anzeigt. Dabei kann jeder <ltg-sort>-tag vom Nutzer angeklickt werden, um die Tabelle neu sortiert angezeigt zu bekommen Benutzerverwaltung Die Benutzerverwaltung von 4D wird auch von Lightning unterstützt. So kann einzelnen Tabellen zugewiesen werden, welcher Nutzer bzw. welche Nutzergruppe hier welche Rechte haben. Unterschieden werden hier die Rechte zum Lesen, Anlegen, Verändern und Löschen von Entitäten. Wie Tabelle 4.1 zu entnehmen ist, können normale Mitarbeiter (sowohl Verkäufer als auch Buchführer) nicht die Nutzertabelle einsehen. Daher ist es einem Mitarbeiter in der Auftragsübersicht (Abbildung 5.6) auch nicht möglich, über den Benutzernamen auf die Detailseite des Nutzers zu gelangen, während der Designer hier einen Link präsentiert bekommt (Abbildung 5.7). 83

92 5. Realisierung Abbildung 5.7.: Ausschnitt der Übersichtsseite als Designer. Nicht befriedigend ist dabei die Unterstützung der Gruppen und ihrer Hierarchien. So ist es in 4D möglich, Gruppen zu erstellen und einen Nutzer zum Mitglied solcher Gruppen zu machen. Eine Gruppe kann ebenfalls Mitglied einer anderen Gruppe sein. Dadurch ist es beispielsweise möglich, die Gruppe der Administratoren als Mitglied jeder anderen Gruppe zu definieren, und einem Administrator somit Zugriff auf alle Funktionalität zu gewähren. Dies ist in Lightning nicht umgesetzt, weshalb die Gruppe der Administratoren jedes mal mit angegeben werden muss, wenn einer anderen Gruppe Rechte eingeräumt werden. Außerdem wirkt es sich auf die Verwendung des Attributs groups von Elementen aus, da hier nur einzelne Gruppen unterstützt werden, nicht jedoch die Hierarchien. So muss die Gruppe der Administratoren auch hier explizit aufgeführt werden Logbuch Mit Hilfe der log-tabelle und einer selbst erstellen Funktion ist es möglich, in 4D einen Logging-Mechanismus zu erhalten, der an Log4J angelehnt ist. Ein Logeintrag entspricht einem Eintrag in die Datenbanktabelle log. Dabei werden die Bezeichnungen von sechs Logleveln von Log4J übernommen, die jedem geloggten Ereignis eine Kategorie zuordnen. Diese reichen von TRACE für feinste Debug-Informationen über WARN für unerwartete oder unerwünschte Ereignisse bis hin zu FATAL für schwerwiegende Fehler (vgl. [Apa10]). Die einzelnen Level sind in Auflistung 5.5 dargestellt. Bei der Anzeige der Logeinträge kann eingestellt werden, ab welchem Level die Nachrichten angezeigt werden sollen, wobei niedrigere Einträge im Sinne der Gewichtung immer ausgeblendet werden. Dabei ist es mit dem selbst erstellten System nicht wie bei Log4J möglich, die Loglevel für einzelne Teilbereiche zu konfigurieren. 1 FATAL > ERROR > WARN > INFO > DEBUG > TRACE Quellcode 5.5: Die verwendeten Loglevel Es kann mit einer Zeile ein Logeintrag erstellt werden, welcher später aus der Tabelle ausgelesen werden kann. Der Befehl zum Erstellen der Einträge ist in Listing 5.6 zu sehen. Übergeben werden das Loglevel als Zeichenkette, die Quelle des Eintrags und die eigentliche Meldung. Optional können auch ein Datum und eine Uhrzeit mit angegeben werden. Um die Filterung nach Logleveln zu realisieren, wurde auf die Lösung von My- Inventory zurückgegriffen, beschrieben unter Logging. Es ist über Buttons auf 84

93 5.3. MyERP der Übersichtsseite möglich festzulegen, welche Datensätze geladen und angezeigt werden sollen. Daneben gibt es den Button mit der Aufschrift clear, welcher die als Quellcode 5.7 dargestellte Funktion log_clear aufruft. Diese selektiert und löscht alle Logeinträge, bevor die automatische ID zurückgesetzt wird. Durch den Aufruf von Ltg_Form_Display in Zeile 5 wird der Nutzer wieder auf das Logbuch geführt. 1 _LOG ("DEBUG";$funcionName;"Funktion aufgerufen") Quellcode 5.6: Funktionsaufruf _LOG 1 ALL RECORDS([log]) 2 DELETE SELECTION([log]) 3 SET DATABASE PARAMETER([log];Table Sequence Number;0) 4 5 Ltg_Form_Display ( >[log];"log_list") Quellcode 5.7: Löschen der Logbucheinträge Die Tabelle selbst ist nur für Administratoren sichtbar. Wie in Lightning üblich, wird die Seite über den Reitereintrag Logbuch erreicht. Dort werden die letzten Logeinträge angezeigt, wobei diese Einträge nach der ID sortiert sind. Der Zeitpunkt der Erstellung wird zwar bei den Datensätzen gespeichert, jedoch sind Uhrzeit und Datum getrennt, da es in 4D keinen Typ gibt, der beides enthält. Daher führt eine Sortierung nach Uhrzeit oder Datum nicht dazu, immer die Einträge in chronologischer Reihenfolge zu sehen. Zusätzlich werden die Einträge nach ihrer Kategorie farblich hinterlegt. Dazu wird jeder Tabellenzeile eine CSS-Klasse zugewiesen, welche der Kategorie entspricht. In der CSS- Datei des benutzten Lightning-Themes werden diesen Klassen dann Hintergrundfarben zugewiesen. So fallen beispielsweise Einträge der Kategorie FATAL durch ihre rote Hintergrundfarbe auf. In Abbildung 5.8 sind die Logeinträge der Funktion test_log zu sehen Der Auftragsstatus Ein Auftrag kann sich in verschiedenen Zuständen befinden. Um diese zu verfolgen, wurde den Stammdaten des Auftrags die Variable status hinzugefügt. Dabei wird dieser Wert bei der Abarbeitung eines Auftrags immer erhöht, nie verringert. Der Wert ist fast durchgängig zweistellig, wobei die erste Stelle angibt, in welchem Teil der Abarbeitung sich ein Auftrag befindet. Die zweite Stelle weist auf vorhandenen Fehler hin. In Anhang A.1 findet sich eine Auflistung aller möglichen Fehlercodes. Dabei wurde auch bedacht, dass später eventuell Teillieferungen implementiert werden könnten, bei denen nicht gelieferte Artikel vorkommen können. Daher wurden diese Werte mit der Anfangsziffer 3 deutlich von denen bei abgeschlossener Lieferung mit Ziffer 4 getrennt. 85

94 5. Realisierung Abbildung 5.8.: Logeinträge der Funktion test_log. Die Höhe der Ausgabezeilen wurde für diesen Screenshot nach unten korrigiert. Bei der Erstellung hat ein Auftrag den Status 0. In diesem Zustand ist es möglich, beliebige Änderungen am Auftrag vorzunehmen. Mit der Freigabe durch einen Nutzer erhält ein Auftrag den Status 10, sobald das Avis erstellt wurde den Status 11. Wenn beim Versenden des Auftrags ein Fehler auftritt, so wird der Status auf 12 gesetzt, ansonsten nach dem Erhalt der Empfangsbestätigung von MyInventory auf 20. Für einen Nutzer wechselt der Status im Normalfall also von 10 direkt auf 20, da das Avis direkt nach der Erstellung verschickt wird. Ein anderer Zustand weist also darauf hin, bis zu welchem Punkt das Freigeben erfolgreich war. Sobald ein Auftrag freigegeben wurde, ist es nicht mehr möglich, an diesem Änderungen vorzunehmen. Sobald vom MyInventory die Lieferbenachrichtigung eingeht, wird der Status des Auftrags automatisch angepasst. Wenn die Lieferung wie angekündigt bei Sped. Hurz angekommen ist, so wird der Status des Auftrags auf 60 gesetzt. Sind jedoch Abweichungen zwischen der angekündigten und der tatsächlichen Lieferung vorhanden, so wird der Status auf 40 gesetzt. Dabei werden die drei möglichen Fehler aus Abschnitt unterschieden: Es kann von mindestens einem Artikel zu wenig oder zu viel geliefert worden sein, oder mindestens ein nicht angekündigter Artikel wurde geliefert. Diesen Fehlertypen werden die numerischen Werte 1, 2 und 4 zugewiesen und auf den Status addiert. Ist bei einem Auftrag beispielsweise ein Artikel nicht geliefert (Fehlertyp 1) und ein anderer nicht avisierter geliefert worden (Fehlertyp 4), ergibt sich der Auftragsstatus 45. Ein Status zwischen 40 und 50 weißt also darauf hin, dass die Lieferung abgeschlossen wurde, aber noch Fehler vorhanden sind. In diesem Zustand kann ein Korrekturauftrag erstellt werden. Sobald dies passiert, wird der Status des Auftrags um 10 erhöht. Am neuen Wertebereich zwischen 50 und 60 lässt sich so sofort sehen, das ein Korrekturauftrag erstellt wurde, während die Information über den Fehlertyp erhalten bleibt. So würde sich der Status von 45 auf 55 ändern. 86

95 5.3. MyERP Wird ein Auftrag schließlich durch einen Korrekturauftrag abgeschlossen, so wird der Status ein weiteres mal um 10 erhöht. Somit ergeben sich Werte größer als 60, während der Fehlertyp weiterhin erhalten bleibt, im Beispiel wäre dies 65. So kann man an diesem Status von 65 sofort sehen, dass die Lieferung dieses Auftrags nicht wie avisiert angekommen ist, allerdings durch einen erfolgreichen Korrekturauftrag abgeschlossen wurde Wichtige Funktionen In diesem Abschnitt werden vorbereitet die wichtigsten Funktionen von MyERP erklärt. Dies ist notwendig, da sich die Funktionen nicht eindeutig den Aktivitäten zuordnen lassen. So müssen die Funktionen sowohl mit normalen als auch mit Korrekturaufträgen arbeiten können Avis erstellen und versenden order_send In der Methode order_send, vollständig abgebildet als Quellcode 5.8, wird zuerst der Auftrag mit der Methode order_giveclearance (s ) freigegeben. War dies erfolgreich, so wird das BOD erzeugt. Dabei unterscheidet die Methode zwischen einem normalen Auftrag, für welchen ein BOD ProcessShipment erstellt wird, und einem Korrekturauftrag, bei welchem ein ChangeShipment erstellt wird. Die Funktionen zum Erzeugen der BODs sind bis auf die Elementnamen gleich, weshalb nur BOD_createProcessShipment unter eingehend beschrieben wird. Nach der Erzeugung des BODs wird der Auftragsstatus auf 11 gesetzt und gespeichert. In Zeile 21 wird das BOD dann mit der Funktion BOD_send (s ) gesendet, die Antwort von MyInventory wird in Zeile 22 durch die Funktion BOD_evaluate_confirmBOD evaluiert. Dabei gilt, dass eine Nachricht ohne FailureMessage das gesendete BOD bestätigt. Ist beim Versenden ein Fehler aufgetreten, wird der Status auf 12 gesetzt; trat kein Fehler auf, wird der Status auf 20 gesetzt. Hier werden in Zeile 26 wieder Korrekturaufträge unterschieden, da bei diesen der Status schon in der Methode order_giveclearance gesetzt werden kann. Die Änderungen am Auftrag werden anschließend noch gespeichert, bevor ein Logeintrag erzeugt wird. 1 _LOG ("DEBUG";"order_send";"Funktion aufgerufen; order id: "+String([order_core]id)) 2 order_giveclearance 3 If ([order_core]status>=10) 4 C_LONGINT($bod_type) 5 $bod_type:=0 6 7 If ([order_core]fid_predecessor=0) 8 $bod:=bod_createprocessshipment ([order_core]id) 9 $bod_type:=1 10 Else 87

96 5. Realisierung 11 $bod:=bod_createchangeshipment ([order_core]id) 12 $bod_type:=2 13 End if 14 [order_core]status:=11 //Status 11: BOD created 15 SAVE RECORD([order_core]) C_BLOB($confirmBOD) 18 C_INTEGER($sended) //Could be done in a different Process 21 $confirmbod:=bod_send ($bod;$bod_type) 22 $sended:=bod_evaluate_confirmbod ($confirmbod) 23 If ($sended<0) 24 [order_core]status:=12 25 Else 26 If ([order_core]status>60) 27 //If order is correction and was completed in giveclearance, don t change the status. 28 Else 29 [order_core]status:=20 30 End if 31 End if 32 SAVE RECORD([order_core]) $msg:="dies ist der Avis für Auftrag Nummer "+String([order_core]id)+":" 35 $msg:=$msg+blob to text($bod;utf8 C string) 36 _LOG ("INFO";"order_send:35";$msg) 37 End if Quellcode 5.8: Versenden eines Auftrags Auftrag freigeben order_giveclearance Die Methode order_giveclearance besteht aus mehreren Teilen. Diese werden im Folgenden nacheinander beschrieben und aufgeführt, wobei einige Leerzeilen und Kommentare entfernt wurden. Sie kann ohne Parameter aufgerufen werden, wenn der freizugebende Auftrag der einzig aktuell selektierte ist. Ansonsten muss eine Auftrags-ID übergeben werden. In den Zeilen 8 bis 28 wird geprüft, ob der Auftrag freigegeben werden kann, wie in Quellcode 5.9 dargestellt ist. 8 If (Count parameters=1) 9 QUERY([order_core];[order_core]id=$1) 10 Else 11 If (Records in selection([order_core])#1) 12 //Should never happen: either call the method with ONE current order, 13 //or pass an order ID as parameter 14 _LOG ("ERROR";"order_giveClearance";"FEHLER: Nicht genau ein Record in Selection bei Aufruf von order_giveclearance ohne Parameter!") 15 ASSERT(False;"FEHLER: Nicht genau ein Record in Selection bei Aufruf von order_giveclearance ohne Parameter!") 16 Else 17 88

97 5.3. MyERP 18 //check that the order isn t already cleared 19 If ([order_core]status>=10) 20 //Order already cleared 21 If (<>debug=true) 22 Ltg_Msg_Error ("Order already cleared") 23 End if 24 _LOG ("INFO";"order_giveClearance";"order is already cleared") 25 //TODO: throw a custom error? 26 //ASSERT(false,"Auftrag bereits freigegeben") 27 $0:= Else Quellcode 5.9: Freigeben eines Auftrags - Zeilen 8-28 Kann der Auftrag freigegeben werden, so wird mit START TRANSACTION eine Datenbanktransaktion gestartet. Innerhalb dieser wird zuerst der aktuelle Nutzer bestimmt (Funktion getcurrentuser, ), bevor dieser und das aktuelle Datum im Auftrag gesetzt werden. Die Funktion order_setvalue berechnet den aktuellen Auftragswert des selektierten Auftrags und setzt diesen, zu sehen in START TRANSACTION 33 $currentuserid:=getcurrentuserid //If current user has ID 0, the method is not called from lightning. 36 //This means the Designer/Administrator called the function, and thus the Designer 37 //is set as the one giving clearance it can be altered later, if neccessary. 38 If ($currentuserid=0) 39 $currentuserid:=1 40 End if 41 [order_core]fid_erp_user:=$currentuserid 42 [order_core]recorded:=current date //calculate & set value 45 order_setvalue Quellcode 5.10: Freigeben eines Auftrags - Zeilen In den Zeilen 47 bis 55 des Quellcodes 5.11 wird für jeden Artikel aktualisiert, wie oft er sich noch im internen Lager befindet. Hier wurde darauf geachtet, dass sich bei einem Korrekturauftrag die gelagerte Menge unter Umständen nicht verändert oder sogar erhöht, wenn weniger Artikel gesendet wurden als ursprünglich avisiert. Daher wird der Wert für die interne Lagerhaltung immer um die Differenz von avisierter und bisher gelieferter Menge geändert. 32 QUERY([order_item];[order_item]fid_order=[order_core]id) 33 For ($i;1;records in selection([order_item])) 34 QUERY([item];[item]gtin=[order_item]fid_item) 35 $aenderung:=([order_item]quantity [order_item]quantity_delivered) 89

98 5. Realisierung 36 [item]on_site:=[item]on_site $aenderung 37 _LOG ("TRACE";"order_giveClearance";"Lagermenge von "+[item]gtin+" um "+String($aenderung)+" verändert.") 38 SAVE RECORD([item]) 39 NEXT RECORD([order_item]) 40 End for Quellcode 5.11: Freigeben eines Auftrags - Zeilen Zu jedem Einlagerungsauftrag wird auch ein Termin bestimmt, bis zu welchem die Rechnung zu begleichen ist. Dieser Termin wird in den Zeilen 57 bis 63 gesetzt, da dieser bei einem Einlagerungsauftrag aus der Kontraktlogistikertabelle (tpl) entnommen werden kann. Im Anschluss werden in den Zeilen bis 68 der Auftragsstatus auf 10 gesetzt und die Änderungen in der Datenbank gespeichert. 57 //set payable_until 58 If ([order_core]warehouse=true) 59 QUERY([tpl];[tpl]id=[order_core]fid_tpl) 60 [order_core]payable_until:=current date+[tpl]pay_timelimit 61 Else 62 [order_core]payable_until:=current date End if //set "clearance" to true, i.e. status [order_core]status:=10 67 SAVE RECORD([order_core]) 68 VALIDATE TRANSACTION Quellcode 5.12: Freigeben eines Auftrags - Zeilen Die Zeilen 70 bis 85 handeln die Möglichkeit ab, dass durch das Erteilen eines Korrekturauftrags eine Sequenz beendet werden kann. So kann die Fehlerquelle sein, dass zu wenige Waren geliefert wurden. Wenn die avisierte Menge dann im Korrekturauftrag auf die gelieferte heruntergesetzt wird, ist der Auftrag abgeschlossen. Um dies zu gewährleisten, wird in Quellcode 5.13 über alle Positionen des Auftrags iteriert. Dabei wird jeweils geprüft, ob die avisierte und gelieferte Menge übereinstimmen. Ist dies der Fall, so wird der Auftrag über die Methode order_complete (s ) als beendet markiert. 70 //Check if this completes the (correction) order 71 QUERY([order_item];[order_item]fid_order=[order_core]id) 72 C_BOOLEAN($allOK) 73 $allok:=true For ($i;1;records in selection([order_item])) 76 If ([order_item]quantity#[order_item]quantity_delivered) 77 $allok:=false 78 End if 79 NEXT RECORD([order_item]) 80 End for 90

99 5.3. MyERP 81 If ($allok=true) 82 $orderid:=[order_core]id 83 order_complete ([order_core]id) 84 QUERY([order_core];[order_core]id=$orderID) 85 End if Quellcode 5.13: Freigeben eines Auftrags - Zeilen Schließlich werden die im ersten Abschnitt (5.9) begonnenen Anweisungsblöcke noch beendet, wie in 5.14 dargestellt. 87 End if //order was not cleared 88 End if //RiS # 1 89 End if // #Params = 1 Quellcode 5.14: Freigeben eines Auftrags - Zeilen Auftrag abschließen order_complete Das Abschließen eines Auftrags kann in zwei Situationen gestartet werden. In der ersten wird ein BOD vom Typ NotifyReceiveDelivery erhalten, mit dem die vollständige Lieferung aller avisierten Artikel bestätigt wird. In diesem Fall wird order_complete von der Funktion order_processnrd aufgerufen. Die andere Situation ist ein Korrekturauftrag, der die avisierten Mengen genau auf die bis dahin gelieferten setzt. In diesem Fall ist die Funktion order_send der Aufrufer. Die Funktion order_complete hat dabei immer zwei Aufgaben: Den aktuellen Auftrag als erfolgreich beendet zu markieren sowie alle seine Vorgänger. Zu diesem Zweck ist die Funktion rekursiv aufgebaut, da bei einem Auftrag nicht bekannt ist, wie viele Vorgänger dieser besitzt. Dabei muss die Funktion, deren vollständiger Quellcode in 5.15 angegeben ist, immer mit einer Auftrags-ID als Parameter aufgerufen werden. Sie hat keinen Rückgabewert, verändert aber die aktuelle Selektion der Tabelle order_core auf den ersten Auftrag einer Sequenz. Mit der übergebenen ID wird ein Query erzeugt, der den Auftrag selektiert. Wenn dieser Auftrag durch einen anderen korrigiert wurde, so ist sein Status im Bereich von 51 bis 57. In diesem Fall wird der entsprechende Wert um 10 erhöht, um die zweite Stelle des Status als Fehlerindikator zu wahren. Ist der Auftragsstatus nicht in diesem Bereich, so wird er auf den Wert 60 gesetzt, bevor diese Änderung gespeichert wird. Im Anschluss wird geprüft, ob der Auftrag einen Vorgänger besitzt; wenn dem so ist, wird die Funktion order_complete ein weiteres mal mit der ID des Vorgängers aufgerufen. 91

100 5. Realisierung 1 //completes the order $1 (Status=60) and every predecessor (Status=6x) 2 QUERY([order_core];[order_core]id=$1) 3 _LOG ("DEBUG";"order_complete";"Function called with id="+string($1)+", status="+string([order_core]status)) 4 If (([order_core]status>=50) & ([order_core]status<60)) 5 //current order has a correction order 6 [order_core]status:=[order_core]status+10 7 Else 8 //is last order (normal or last correction) 9 [order_core]status:=60 10 End if 11 SAVE RECORD([order_core]) 12 If ([order_core]fid_predecessor#0) 13 order_complete ([order_core]fid_predecessor) 14 End if Quellcode 5.15: Abschließen eines Auftrags und seiner Vorgänger Nutzer ermitteln getcurrentuser Diese Funktion ermittelt die Benutzer-ID des aktuellen Nutzers. In 4D hat jeder Nutzer eine solche ID sowie einen Nutzernamen, die Funktion Current user liefert jedoch immer nur den Namen. Auch die Funktion Ltg_SessionGetProperties, mit welcher sich der in Lightning angemeldete Nutzer ermitteln lässt, liefert nur den Benutzernamen zurück. Für die Referenz auf den ERP-Nutzer aus der Tabelle order_core ist aber die ID erforderlich. Zu diesem Zweck wird der Nutzername ermittelt, entweder aus Lightning oder aus 4D. Dieser wird dann im Array der Benutzernamen, erhalten durch die Funktion GET USER LIST, gesucht. Der Index, an welchem der gesuchte Name gefunden wurde, wird dann genutzt, um aus dem Array der Benutzer-IDs den passenden Eintrag zu erhalten. Diese Abfrage ist in Quellcode 5.16 zu sehen. 1 If (Ltg_Session_GetCurrent #"") 2 //Take the current Lightning User 3 Ltg_Session_GetProperties (Ltg_Session_GetCurrent ; >$currentusername; >$sgroups; >$srole) 4 $currentuserid:=userids{find in array(usernames;$currentusername)} 5 Else 6 //Take the current 4D User 7 $currentuserid:=userids{find in array(usernames;current user)} 8 End if Quellcode 5.16: Ermitteln der aktuellen Benutzer-ID 92

101 5.3. MyERP BOD versenden BOD_send Diese Funktion bekommt ein BOD übergeben sowie eine Integervariable, welche Auskunft über den Typ des BODs gibt. Der Typ kann dabei 1 sein für ein ProcessShipment oder 2 für ein ChangeShipment. Je nachdem, welcher Typ vorhanden ist, wird die entsprechende Proxyfunktion aufgerufen, welche diesen Aufruf an MyInventory weiterleitet. Die Antwort von MyInventory wird von BOD_send zurückgeliefert. Die Auswahl der Proxyfunktion ist in Quellcode 5.17 zu sehen. 18 Case of 19 : ($bodtype=1) 20 $responsewms:=proxy_service_processshipment ($1) 21 : ($bodtype=2) 22 $responsewms:=proxy_service_changeshipment ($1) 23 Else 24 //A not supported type 25 _LOG("FATAL";"BOD_send";"Type "+String($bodType)+" not supported!") 26 ASSERT(False;"Type "+String($bodType)+" not supported!") 27 End case Quellcode 5.17: Versenden eines BODs Avis erstellen BOD_createProcessShipment Diese Funktion bekommt als optionalen Übergabeparameter eine Auftrags-ID. Wenn diese nicht übergeben wird, so muss die aktuelle Auswahl der Tabelle order_core ein Element enthalten, ansonsten wird die Bearbeitung mit einem Fehler abgebrochen. Weitere Plausibilitätsprüfungen finden nicht statt. Zurückgegeben wird das fertige BOD vom Typ ProcessShipment. Das Wurzelelement des BODs wird über die Funktion BOD_createBODroot erstellt, welche als Parameter den Namen des Wurzelelements übergeben bekommt. Mit dieser Information wird das vollständige Wurzelelement $root inklusive der Angabe des XSD-Schemas erstellt und zurückgeliefert. Anschließend wird mit der Funktion BOD_createApplicationArea die Application Area erstellt und in $root hinzugefügt. Diese beiden Funktionalitäten wurden in eigene Funktionen ausgelagert, da sie so auch bei der Erstellung der BODs vom Typ ChangeShipment und ConfirmBOD genutzt werden können. Anschließend wird über die 4D-Funktionen DOM Create XML element und DOM SET XML ELEMENT VALUE der XML-Baum aufgebaut und mit Daten gefüllt. Bei der Angabe der geschätzten Ankunftszeit wird die eigene Funktion datetime_getisodate verwendet, die ein Datum im 4D-Format übergeben bekommt und einen String im ISO-Format zurückliefert. Das Erstellen der einzelnen item-einträge geschieht in einer Schleife. Erwähnenswert ist hier, dass an die $description des Items ein Leerzeichen angehängt wird. Dies geschieht, 93

102 5. Realisierung weil 4D beim Konvertieren von Sonderzeichen in Base64 ein Euro-Symbol so kodiert, dass das folgende Zeichen korrumpiert wird. Damit hier nicht das Ende des Elements überschritten wird, wurde das Leerzeichen als Puffer eingesetzt. Aus diesem Grund hat jede Artikelbeschreibung im MyInventory am Ende ein Leerzeichen, da die Rückkonvertierung desselben in 4D aus dem Base64-kodierten String keine Probleme verursacht Angebotener Service _service_notifyreceivedelivery Dies ist der Service, über den MyInventory das MyERP-System über eingegangene Lieferungen informiert. Der Aufruf erfolgt dabei mit einem NotifyReceiveDelivery-BOD, die Antwort von MyERP ist ein BOD vom Typ ConfirmBOD. Zuerst wird der übergebene Parameter mit der Funktion BOD_eval_NRD evaluiert. Dabei wird zuerst die Validität geprüft. Bei bestandener Prüfung wird das BOD verarbeitet, wie in beschrieben. Zurückgeliefert wird ein Integerwert, welcher Ausschluss über die Evaluierung gibt. Anhand dieses Wertes wird die boolesche Variable $Notify- ReceiveDeliveryValid gesetzt, welche genutzt wird um später zu entscheiden, ob eine Failure- oder eine SuccessMessage zurückgeliefert wird. In einer case of-anweisung werden je nach Rückgabewert der Wert der Stringvariable $returnmessage und der Wert von $NotifyReceiveDeliveryValid gesetzt. Dabei steht der Rückgabewert 0 der Evaluierungsfunktion für einen erfolgreich abgeschlossenen Auftrag, während positive Werte darauf hinweisen, dass die Lieferung nicht wie avisiert empfangen wurde. In diesen Fällen ist die Abarbeitung erfolgreich, sodass die Variable den Wert true erhält. Ist der Rückgabewert jedoch negativ, dann ist ein Fehler aufgetreten. So erzeugt ein invalides XML-Dokument den Fehlercode -1 und eine entsprechende Meldung, sowie einen Logeintrag der Kategorie WARN. Ist das Dokument valide, so kann es sein, dass die Logische ID des Kontraktlogistikers unbekannt ist, dass die Auftrags-ID unbekannt ist oder dass zu einem Auftrag eine andere als die angegeben ID gehört. In jedem dieser Fälle wird eine der Variablen der Wert false zugewiesen. Am Ende werden beide Werte, also $NotifyReceiveDeliveryValid und $returnmessage, an die Funktion createconfirmbod übergeben. Das so erzeugte ConfirmBOD wird an den Aufrufer des Services zurückgeliefert Lieferbenachrichtigung validieren BOD_eval_NRD Diese Funktion prüft, ob die übergebene Variable vom Typ BLOB ein valides BOD vom Typ NotifyReceiveDelivery ist. Dabei werden die im Abschnitt 5.2 angesprochenen Probleme bei der Validierung durch eine Unterscheidung lokaler Testaufrufe von normalen Aufrufen über die Funktion _service_notifyreceivedelivery umgangen. Wenn die 94

103 5.3. MyERP Validierung nicht erfolgreich ist, so wird der Wert -1 zurückgegeben und die Funktion beendet. Wenn das BOD valide ist, wird die im nächsten Abschnitt beschriebene Funktion order_processnrd aufgerufen und deren Ergebnis zurückgeliefert Auf Lieferbenachrichtigung reagieren order_processnrd Nachdem das BOD NotifyReceiveDelivery validiert wurde, übernimmt die Funktion order_processnrd das Auswerten der Lieferbenachrichtigung. Dabei werden drei Phasen unterschieden: Auslesen der XML-Datei, Prüfen der Voraussetzungen und Aktualisieren der Auftragspositionen. In der ersten Phase werden alle relevanten Werte aus der XML-Datei ausgelesen und in lokalen Variablen gespeichert. Dabei wird ausgenutzt, dass die 4D-Methode DOM GET XML ELEMENT VALUE einen Wert ausliest und direkt eine Typkonvertierung durchführt. So gelingt beispielsweise das Auslesen der AdviceID wie in Quellcode Die Werte für die Auftragspositionen werden dabei über eine Schleife ausgelesen und in Arrays gespeichert. 24 $adviceid:=dom Find XML element($header;"/header/adviceid") 25 C_LONGINT($adviceIDValue) 26 DOM GET XML ELEMENT VALUE($adviceID;$adviceIDValue) Quellcode 5.18: Auslesen von AdviceID aus einem NRD In der zweiten Phase werden die ausgelesenen Daten inhaltlich überprüft. So wird geprüft, ob der Kontraktlogistiker berechtigt ist, für diesen Auftrag eine Lieferbenachrichtigung zu verschicken. In dieser Phase wird aus der übergebenen AdviceID, welche immer die ID des ersten Auftrags einer Sequenz darstellt, die ID des aktuell zu bearbeitenden Auftrags bestimmt. Dies übernimmt die rekursive Funktion order_findlastsuccessor. Sind alle Prüfungen abgeschlossen, so beginnt die dritte Phase. In dieser werden die Auftragspositionen geladen und der Wert für die gelieferte Menge wird angepasst. Dabei ist zu beachten, dass bei einer Lieferung möglicherweise ein Artikel bei war, der vorher nicht avisiert wurde. In diesem Fall gibt es zu diesem Artikel keine Auftragsposition, diese muss also neu angelegt werden. Wenn dies passiert, wird die boolesche Variable $notannounced auf true gesetzt, um diesen Fehler zu signalisieren. Nachdem alle Artikel aktualisiert wurden, erfolgt in einer Schleife die Prüfung darauf, ob zu einzelnen Positionen zu wenig oder zu viel geliefert wurde, was in den Variablen $tofew und $tomuch gespeichert wird. Aus diesen wird der Fehlercode $errorstatus wie in Quellcode 5.19 errechnet. 193 $errorstatus:=0 194 If ($tofew=true) 195 $errorstatus:=$errorstatus End if 197 If ($notannounced=true) 95

104 5. Realisierung 198 $errorstatus:=$errorstatus End if 200 If ($tomuch=true) 201 $errorstatus:=$errorstatus End if 203 If ($errorstatus=0) 204 order_complete ([order_core]id) 205 Else 206 //TODO: WENN Teillieferungen möglich sind: 30+$errorStatus! 3x für "Teillieferung da", 4x für "alles da, aber Fehler" 207 [order_core]status:=40+$errorstatus 208 End if 209 $0:=$errorStatus Quellcode 5.19: Berechnen des Fehlerkodes eines Auftrags Wenn dieser Fehlercode 0 ist, so wird der Auftrag abgeschlossen. Hat der Fehlercode einen anderen Wert, so wird dem Auftrag der Status 40+$errorStatus zugewiesen. Im Anschluss daran wird in jedem Fall der Fehlercode zurückgegeben und die Funktion wird beendet Umsetzung der Nutzeraktivitäten Im Folgenden wird die Realisierung der Aktivitäten von MyERP beschrieben. Dabei wird zuerst auf den Auftragsstatus eingegangen, bevor die Umsetzung der einzelnen Aktivitäten erläutert wird. Zu jeder Aktivität wird dabei sowohl auf die Weboberfläche als auch auf die in 4D geschriebenen Funktionen eingegangen Einlagerungsauftrag erstellen Ein neuer Auftrag wird über das Detailformular order_detail angelegt. Da dieses Formular auch für die Anzeige von vorhandenen Aufträgen in den verschiedenen Zuständen genutzt wird, muss sich die Oberfläche an den aktuellen Auftrag anpassen. Diese Unterscheidung wird anhand des Auftragsstatus vorgenommen. Das Formular enthält für die einzelnen Attribute der zugrundeliegenden Tabelle order- _core jeweils <ltg-field>-felder, welche über <ltg-caption> beschrieben werden. Die meisten dieser Werte sind nicht vom Nutzer editierbar, da diese vom System vorgegeben werden. Es kann ein Kunde und Kontraktdienstleister ausgewählt werden, jeweils über den Fremdschlüssel. Außerdem kann der geschätzte Ankunftstermin an dieser Stelle geändert werden. Zwar ist es möglich, andere Kontraktlogistiker anzulegen und hier anzugeben, dies wird vom System aber an den wichtigen Stellen wie Buchung und Aufruf der Webserviceschnittstellen nicht berücksichtigt, da andere Kontraktlogistiker nicht implementiert wurden. Die 96

105 5.3. MyERP Auswahl von Kunden wird nur dann relevant, wenn das Szenario um Kundenaufträge erweitert wird (s. 7.3 Ausblick). Wichtig ist hier, dass das Formular zwischen neuen und schon vorhandenen Aufträgen unterscheidet. So darf bei einem freigegeben Auftrag keiner dieser Werte mehr verändert werden. Aus diesem Grund werden die veränderbaren Felder nur dann angezeigt, wenn der Auftragsstatus kleiner als 10 ist. Dies geschieht, wie es im Quellcode 5.20 für das Feld [order_core]eta demonstriert ist. 1 <! #4DIF ([order_core]status>=10) > 2 <ltg field name="[order_core]eta" mandatory="true" readonly="true" /> 3 <! #4DELSE > 4 <ltg field name="[order_core]eta" mandatory="true" readonly="false" /> 5 <! #4DENDIF > Quellcode 5.20: Eingabefeld für geschätzte Ankunftszeit In diesem Formular wird außerdem das Listenformular der Auftragspositionen eingebunden, um so die zu einem Auftrag gehörenden Positionen direkt mit anzeigen zu können. Zu diesem Zweck muss im einleitenden Formulartag das Attribut relate-one auf true gesetzt werden, wie in Zeile 1 von Quellcode 5.21 zu sehen ist. Danach kann über den Befehl in Zeile 3 das Formular order_item_short_list eingebunden werden. 1 <ltg form name="order_detail" table="[order_core]" type="detail" relate many="true" relate one="true"> <ltg include name="order_item_short_list" table="order_item" /> 4 </ltg form> Quellcode 5.21: Lightning-Tag zum Einbinden eines Formulares In diesem Formular sind Buttons vorhanden, mit denen sich neue Auftragspositionen anlegen lassen. Bei diesen gilt ebenfalls, dass sie nur dann angezeigt werden, wenn der Auftragsstatus unter dem Wert 10 liegt. Für das Erzeugen einer neuen Auftragsposition wird von Lightning das Formular order_item_detail geöffnet. Wird dieses Formular zum Erstellen einer Auftragsposition geöffnet, so führt Lightning die 4D-Methode order_item_loadorderid aus. Diese besteht neben Logeinträgen aus den zwei in Quellcode 5.22 abgebildeten Zeilen. Diese Methode nimmt den aktuellen Auftrag, zu dem die neue Position gehört, und setzt dessen ID als Fremdschlüssel ein. Das Feld für die Auftragsnummer einer Position kann somit als nicht editierbar markiert werden, da das Ausfüllen immer automatisch erfolgt. 6 ASSERT(Records in selection([order_core])=1) 7 [order_item]fid_order:=[order_core]id 97

106 5. Realisierung 8 _LOG ("TRACE";"order_item_loadOrderId:7";"fid_order gesetzt auf "+String([order_core]id)) Quellcode 5.22: 4D-Methode order_item_loadoderid Zum Auswählen des Artikels wird das Benutzerformular item_short_list anstelle des Standardformulars genutzt. Beim Laden dieses Formulars wird die 4D-Methode item_- filterinactive aufgerufen, welche alle als inaktiv markierten Artikel aus der Auswahl entfernt. Dazu wird eine Query erzeugt, die nur jene Artikel selektiert, bei denen das Attribut inactive auf false gesetzt ist, wie in Quellcode 5.23 zu sehen ist. Somit können über das Formular nur Fremdschlüssel von aktiven Artikeln eingegeben werden. Lightning unterstützt die Auswahl von Fremdschlüsseln jedoch auch dadurch, dass bei teilweiser Eingabe eines Fremdschlüssels alle noch in Frage kommenden Kandidaten aufgeführt werden. Dies geschieht nicht in einem neuen Fenster, sondern in einem eigenen Bereich der Webseite, auf den ein Designer keinen Einfluss hat. Hier sind also immer alle Artikel auswählbar, auch solche, die eigentlich inaktiv sind. 1 QUERY([item];[item]active=True) Quellcode 5.23: Auswahl auf aktive Artikel einschränken Sobald zu einem Auftrag mindestens eine Auftragsposition angelegt wurde, verändert sich das Formular für diesen Auftrag ein wenig, indem der Button Auftrag freigeben erscheint. Ein klick auf diesen Button führt dazu, dass die Methode order_send ausgeführt wird. Wenn der Empfang des Avis nicht vom MyInventory bestätigt wird, so wird dieser Button durch einen Button mit der Aufschrift Avis erneut versenden ersetzt, welcher die gleiche Funktion aufruft. Beide Buttons sind nur für die Gruppen Verkäufer und Administratoren sichtbar Korrekturauftrag erstellen Bei der Erstellung eines Korrekturauftrags sind einige Abweichungen zur Erstellung eines normalen Auftrags vorhanden. So wird ein Korrekturauftrag nicht über den Button Neu in der Auftragsübersicht erzeugt. Stattdessen muss ein fehlerhafter Auftrag angezeigt werden, und bei diesem findet sich oben im Detailformular der Button Korrekturauftrag erstellen. Dieser Button ruft die Funktion order_createcorrection auf. Diese Funktion erstellt einen neuen Auftrag und überträgt die Stammdaten des zu korrigierenden Auftrags. Dieser wird als korrigiert markiert, indem der Status um 10 erhöht wird (von 4x auf 5x). Darüber hinaus werden ebenfalls neue Auftragspositionen erzeugt, die mit den Werten des alten Auftrags vorbelegt werden. Der Nutzer wird dann sofort auf das Detailformular des Korrekturauftrags weitergeleitet. 98

107 5.3. MyERP Hier hat er nun die Möglichkeit, die Auftragspositionen anzupassen. Dieser Anpassung sind enge Grenzen gesetzt. So ist es nicht möglich, neue Auftragspositionen anzulegen. Die avisierte Menge kann maximal auf die Menge korrigiert werden, die bereits geliefert wurde. Um diese Prüfung zu ermöglichen, ist im Detailformular order_item_detail der Auftragspositionen die Javascriptfunktion checknewquantity() eingeführt worden. Diese Funktion nutzt zum Vergleich das versteckte HTML-Eingabefeld oldquantity, welches über die 4D-Funktion <!--4DVAR [order_item]quantity --> den alten Wert der Position beim Aufruf der Seite zugewiesen bekommt. An dieser Stelle konnte kein Lightningfeld genutzt werden, da hier bei einer Wertänderung diese Änderung gegen sich selbst kontrolliert werden würde Auftrag bezahlen Zum Bezahlen von Aufträgen gibt es im Detailformular derselben eine eigenen Bereich oberhalb der Liste der Auftragspositionen. Dieser wird nur dann eingeblendet, wenn der Auftrag tatsächlich bezahlt werden kann, wenn also weder eine Bezahlung noch ein Korrekturauftrag vorliegt und der Auftrag freigegeben wurde. Diesen Bereich kann jeder Nutzer von MyERP sehen, unabhängig von der eigenen Berechtigung, da es nicht möglich ist, einzelne <div>-elemente für bestimmte Gruppen freizuschalten. Mitglieder der Gruppe Buchfuerer und Administratoren sind jedoch die einzigen, die den Button Auftrag bezahlen angezeigt bekommen. Die ausklappbaren Listen, auf denen die verschiedenen Konten dargestellt sind, haben jedoch auf den Bezahlvorgang keinen Einfluss. Beim Betätigen dieses Buttons wird die Funktion order_pay aufgerufen. In dieser Funktion wird zuerst die aktuelle Auftrags-ID gespeichert, da im späteren Verlauf die aktuelle Auswahl der Tabelle order_core verändert wird. Im Anschluss daran wird geprüft, ob der Auftrag in einem Status ist, in welchem er bezahlt werden kann. Was folgt ist die Berechnung der schon bezahlten Summe in einer Auftragssequenz, welche von der rekursiven Funktion order_getalreadypaid berechnet wird. Diese Funktion verändert auch die aktuelle Auswahl. Wenn für die aktuelle Auftragssequenz bisher nichts bezahlt wurde, so wird der zu zahlende Betrag aus dem Auftragsvolumen und der Zahlrate des Kontraktdienstleisters ermittelt. Für diesen Betrag wird mit der Funktion transaction_create eine Buchung erzeugt. Wurde in der aktuellen Auftragssequenz schon eine Zahlung getätigt, so wird der noch zu zahlende Betrag ermittelt. Wenn dieser höher ist als die schon gezahlte Summe, so wird eine Nachbuchung erzeugt. Ist der Betrag niedriger als der schon gezahlte Betrag, so wird eine Korrekturbuchung erstellt. 99

108 5. Realisierung Anschließend wird der tatsächlich gezahlte Betrag beim aktuellen Auftrag vermerkt sowie die Rechnung als bezahlt markiert. Nachdem diese Werte gespeichert wurden werden noch durch die rekursive Funktion order_paypredecessors auch alle anderen Aufträge innerhalb der Sequenz als bezahlt markiert. Außerdem wurde die Möglichkeit getestet, die Buchungen in den Tabellen transaction und transaction_entry gegen Veränderungen abzusichern. Zu diesem Zweck wurden Trigger erstellt, die mit den Tabellenereignissen On Deleting Record Event und On Saving Existing Record Event verbunden wurden. Sofern diese Ereignisse auf der Tabelle aktiviert sind, wird vor jeder Änderung oder Löschung eines Datensatzes der Trigger aufgerufen, dessen Quelltext in 5.24 dargestellt wurde. Diese Trigger geben einen selbst definierten Fehlerwert von zurück, durch welchen die Datenbankoperation von 4D abgebrochen wird. Auf diesem Weg lassen sich die Veränderungen wirksam auf Datenbanklevel unterbinden. Lediglich der Designer hat die Möglichkeit, die Trigger einer Tabelle zu deaktivieren. Dies ist in MyERP geschehen, um bei einem zurücksetzten der Datenbank die alten Buchungen löschen zu können. 1 If (Database event=on Deleting Record Event) 2 $0:= End if 4 If (Database event=on Saving Existing Record Event) 5 $0:= End if Quellcode 5.24: Trigger zum Verhindern von Änderungen 100

109 5.4. MyInventory 5.4. MyInventory von Andreas Beckers In diesem Kapitel wird die Realisierung des Szenarios für das Demo-WMS myinventory beschrieben. Dazu wird zuerst erläutert, wie mit dem Programm 4D die Datenbank umgesetzt wird. Anschließend wird beschrieben, wie das Plugin Lightning eingerichtet wird, um eine Weboberfläche entsprechend der Konzeption des Frontends zu erhalten. Des Weiteren wird die Rechteverwaltung von 4D für das Frontend eingesetzt, so dass ein Lagermitarbeiter nur Zugriff auf seine relevanten Daten erhält. In dem Kapitel wird darauf näher eingegangen. Anschließend wird in den beiden Kapitel und die Realisierung der Benutzerschnittstelle zum Abarbeiten des Szenarios, sowie die Realisierung der Kommunikation zwischen dem WMS und dem ERP-System erläutert Datenbankaufbau Das Anlegen der Datenbank gestaltet sich sehr einfach. Die Tabellen können durch einen grafischen Editor erzeugt und miteinander verknüpft werden. Die Bedienung ist dabei ähnlich einem Werkzeug zur Erstellung von UML-Diagrammen. Über ein Kontextmenü kann der Primärschlüssel festgelegt werden, sowie einzelne Constraints für die Tabelle und Attribute, wie zum Beispiel NOT NULL. So wird für das WMS die Datenbankstruktur gemäß der Konzeption in Kapitel erstellt. Als Besonderheit sei hier anzumerken, dass es keinen Datentypen gibt, der sowohl das Datum als auch die Uhrzeit abspeichern kann, wie es zum Beispiel bei der Programmiersprache Java der Fall ist. Diese werden in 4D einzeln als Date, für das Datum, und Time, für die Uhrzeit, behandelt. So werden zum Beispiel in den Tabellen Delivery- Receipt und Advice jeweils beide Datentypen genutzt, um den genauen Zeitpunkt festhalten zu können. Des Weiteren ist das Attribut state für die Lieferung (DeliveryReceipt) über eine TEXT- Variable realisiert. Einen speziellen Datentyp für Aufzählungen (Enumeration) gibt es in 4D nicht. Allerdings können in 4D sogenannte Lists realisiert werden. Die Einträge aus einer solchen Liste können zwar in einem 4D-eigenen Formular bequem verwaltet werden, in einer Weboberfläche mit dem Plugin Lightning aber nicht. Intern in 4D werden diese Listen als normale TEXT-Variablen umgesetzt. In Tabelle 5.1 werden die realisierten Status aufgelistet. In der Weboberfläche können dann diese Strings verwendet und überprüft werden. Für Statusabfragen müssen dann allerdings Textvergleiche durchgeführt werden. Eine interne Integer-Kennung gibt es dabei nicht. Im Anhang A.1 ist das realisierte Datenbankschema zu sehen, das größtenteils dem Konzept entspricht. Es sind zusätzlich zwei weitere Hilfstabellen erzeugt worden. Das ist zum 101

110 5. Realisierung Reihenfolge Status 1 Lieferung eingetroffen 2 Wareneingang eröffnet 3 Vereinnahmung durchgeführt 4 Wareneingang abgeschlossen Tabelle 5.1.: Status einer Lieferung Einen die Tabelle Log, die im Unterkapitel näher beschrieben wird und zum Anderen die Tabelle Dashboard, die zur Anzeige von Informationen der Lager in der Weboberfläche benötigt wird. Diese Tabelle wird im Unterkapitel erläutert Logging-Tabelle nach Log4J Die Tabelle LOG wurde realisiert, um einen Log4J-ähnlichen Loggingmechanismus zu erhalten. In 4D gibt es dafür keine angemessene Implementierung. So können schließlich auch in 4D mit Zeitstempeln versehende Logs erstellt werden, die auch mit einem bestimmten Label (TAG) bestückt sind. Dieses Label wird im entwickelten Demo-WMS dazu genutzt, um dem Namen der Projektmethode, in der das Log erstellt wird, angeben zu können. Dadurch kann festgestellt werden, an welcher Stelle ein Fehler oder eine Information entstanden ist. Die Klassifikation eines Logs, also ob es sich um einen schwerwiegenden Fehler handelt (FATAL), oder ob es sich nur um eine kurze Information über einen Systemvorgang handelt (INFO), kann mit dem Attribut LOG_LEVEL festgelegt werden. Dabei wurden die Log4J- Level realisiert, die in aufsteigender Wichtung in Listing 5.25 dargestellt sind. 1 TRACE < DEBUG < INFO < WARN < ERROR < FATAL Quellcode 5.25: MyInventory Loglevel (vgl. [Apa10]) Wie zu sehen ist, ist ein Log mit dem Level FATAL am schwerwiegendsten, gefolgt von ERROR und WARN. Mit dem Level INFO werden einzelne Vorgänge im System geloggt. Mit DEBUG werden einzelne Schritte eines Vorgangs aufgefasst, damit bei einem technischen Problem nachvollzogen werden kann, an welcher Stelle im Code eine mögliche Ursache sein könnte. Noch feingranularer kann schließlich mit dem Level TRACE geloggt werden Tabelle Dashboard für die Weboberfläche Für das Frontend wurde eine Willkommens- und gleichzeitig Übersichtsseite erstellt. Darauf werden einige Statistiken über eingegangene Avise und Lieferungen sowie über Lagerplätze aufgeführt. Dies ist aber, aufgrund des Werkzeugs Lightning, nur über eine 102

111 5.4. MyInventory gesondert angelegte Tabelle möglich. Deshalb wurde an dieser Stelle die Tabelle Dashboard realisiert. Auf die Realisierung des Frontends wird im Abschnitt näher eingegangen. Die Attribute dieser Tabelle sind schließlich die Statistiken, die dargestellt werden sollen. Das ist unter anderem die Anzahl offener Avise (advice_opened) sowie die Anzahl bereits abgeschlossener Avise (advice_closed). Des Weiteren ist ein Attribut für die Anzahl eingegangener Lieferung vorgesehen. Alle diese Attribute sind ganzzahlige Werte vom Typ Integer. Das letzte Attribut ist ein 4D-Text-Datentyp und ist gedacht für ausführliche Informationen über die Lagerplätze der verfügbaren Lager. Die Informationen werden als HTML- Code zusammengestellt und entsprechend auf der Übersichtsseite ausgegeben. Details zur Implementierung sind im Kapitel beschrieben Weboberfläche mit Lightning Die Benutzerschnittstelle des Warehouse Management System ist aufgrund der Einschränkung des Tools Lightning Datenbank-orientiert aufgebaut. Jede im Kapitel dargelegte Entität ist dabei eine Registerkarte (Tab) also eine eigene Sicht für den Nutzer. Datenbank-orientiert bedeutet in diesem Fall, dass es eine Listenansicht gibt, in der alle Datensätze tabellarisch angezeigt werden. Des Weiteren gibt es eine Detailansicht, in der einzelne Datensätze angezeigt und bearbeitet werden können. Es besteht dabei die Möglichkeit, für jede Sicht eigene Buttons einzubinden, die unter anderem mit Standardfunktionalität belegt werden, also zum Beispiel Speichern, Löschen und Neuer Datensatz. Diese Buttons können aber auch mit eigenen Funktionalitäten belegt werden, wie zum Beispiel das Auslösen des Folgeschritts in den Abläufen des Szenarios. Als ersten Schritt für die Umsetzung der Oberfläche müssen das Plugin Lightning installiert werden (siehe Kapitel Installation des Lightning-Plugins). Nach einem Neustart des 4D-Servers kann schließlich über die IP-Adresse und dem HTTP-Port die Weboberfläche von MyInventory geöffnet werden. Dort angelangt kann man sich mit seinen Benutzerdaten anmelden. Die Benutzerverwaltung des Demo-WMS wird in Kapitel näher beschrieben. Abbildung 5.9.: Kopfzeile von Lightning in der Weboberfläche Mit dem Benutzer Designer kann schließlich die Oberfläche eingerichtet werden. Über einen grünen Synchronisationsknopf in der Kopfzeile der Weboberfläche von Lightning werden alle beschriebenen Tabellen aus 4D geladen und stehen fortan als Registerkarten zur Verfügung (siehe Abb. 5.9). 103

112 5. Realisierung Allerdings müssen für die Listenansichten sowie für die Detailansichten die anzuzeigenden Felder und Eingabemasken noch eingerichtet werden. Dies kann auf jeder Seite über den Link form realisiert werden. Nach einem Klick öffnet sich im Browser ein HTML-Editor, mit dem die Seite dann mit üblichen HTML-Code gestaltet werden kann. Hinzu kommen zu den HTML-Tags noch Lightning-eigene Tags wie zum Beispiel der Tag, der ein Formular deklariert (<ltg-form.../>). Es gibt zwei Möglichkeiten, Daten aus 4D in die Webseiten einzubinden. Die erste Möglichkeit ist durch das Plugin Lightning gegeben. So gibt es zum Beispiel das Tag <ltg-field.../>, um Felder der Datenbank direkt über den Tabellennamen anzusprechen. Über das Attribut readonly des TAGs kann schließlich bestimmt werden, ob die Ausgabe als nicht editierbarer Text angezeigt wird (wenn true), oder aber der Wert im Formular geändert werden kann und somit direkt in der Datenbank übernommen wird (vgl. [Lan11]). Die zweite Möglichkeit, Daten aus 4D einzubinden, ist über 4D-eigene Tags (vgl. [4D 12e, S ff.]). Dazu wird ein normaler XML-Kommentar eingeleitet, gefolgt von dem gewünschten 4D-Tag. Im Codebeispiel (Quellcode 5.26) wird dies beispielhaft dargestellt. 1 <div> 2 Beispiel1: <! 4DTEXT [Dashboard]advice_closed > <br/> 3 Beispiel2: <ltg field name="[dashboard]advice_opened" readonly="true" /> 4 </div> Quellcode 5.26: Beispiel eines HTML 4D-Tags So können zum Beispiel die Inhalt der Attribute advice_closed und advice_opened aus der Tabelle Dashboard in die HTML-Seite eingebunden werden. Werte in den eckigen Klammern sind Bezeichner für Datenbanktabellen und direkt daran angehängt wird die Spalte der Tabelle referenziert. Im Kapitel wird schließlich der Aufbau relevanter Seiten des Demo-WMS MyInventory mit diesen Möglichkeiten erläutert Benutzerverwaltung, Rollen und Rechte Standardmäßig sind in 4D zwei Benutzer eingerichtet. Diese können unverändert in Lightning zum Einloggen in die Weboberfläche genutzt werden. Zum Einen gibt es den Administrator und zum Anderen den Designer. Der Administrator stellt hierbei den Verwalter des Systems dar. Er hat Zugriff auf alle Formulare und Datensätze. Er kann neue Datensätze erstellen und vorhandene Datensätze löschen. Der Designer ist, wie der Name schon vermuten lässt, der Benutzer, der die Oberflächen gestaltet. Er erstellt Eingabeformulare und Listenansichten und stellt die Buttons zur Verfügung, über die gewissen Funktionalitäten durchgeführt werden können. 104

113 5.4. MyInventory Für die Anwendung MyInventory wird als weiterer Benutzer der Lagermitarbeiter eingerichtet. Dieser hat nur eingeschränkte Rechte. Hauptsächlich ist er dafür zuständig, die Aktivitäten aus dem Szenario, wie sie im Konzept der Weboberfläche im Kapitel erläutert sind, durchzuführen. Er darf aber keine Datensätze löschen oder im Nachhinein verändern. Diese Privilegien gehören dem Administrator, der bei Problemfällen Datensätze verändern kann. Dieser Benutzer kann in 4D über die Toolbox komfortabel über eine Eingabemaske angelegt werden. Des Weiteren wird für ihn eine neue Benutzergruppe eingerichtet, der er auch zugeteilt wird. Dadurch ist es mit dem Plugin Lightning für die Weboberfläche möglich, bestimmte Funktionalitäten für ihn zugänglich zu machen, andere aber nicht. Im Bereich User Groups einer jeden Tabelle können schließlich den Aktionen Erzeugen (Create), Lesen (Read), Ändern (Update) und Löschen (Delete), den sogenannten CRUD-Operationen, Benutzergruppen zugewiesen werden. Somit wird deklariert, wer welche Aktion ausführen darf und wer nicht. Des Weiteren kann jedem eingefügten Button in der Oberfläche explizit angegeben werden, wer diesen benutzen darf. In Quellcode 5.27 ist dargestellt, wie dies für einen Button zu realisieren ist, der die 4D-Methode DeliveryReceipt_Close() ausführt. 1 <ltg button table="deliveryreceipt" method="deliveryreceipt_close" title="wareneingang abschließen" groups="mitarbeiter, Administratoren" /> Quellcode 5.27: Rechtevergabe bei Buttons in der Weboberfläche Über das Attribut groups innerhalb des Lightning-Tags zum Erzeugen eines Buttons können kommasepariert Benutzergruppen angegeben werden, die diese Button auslösen dürfen. Ist ein Benutzer in keiner Gruppe vertreten, wird der Button auch nicht dargestellt. Für die Standardaktionen (CRUD-Aktionen) der Buttons, wie zum Beispiel das Löschen eines Eintrags, muss jedoch keine Benutzergruppe explizit angegeben werden, da dies, wie zuvor beschrieben, über die Rechtevergabe der Tabellen geregelt wird. In Tabelle 5.2 wird für die einzelnen Tabellen und Datenbankoperation die Rechtevergabe für den Lagermitarbeiter dargestellt. Der Lagermitarbeiter hat schließlich alle Berechtigungen, die notwendig sind, um das Szenario durchzuführen. Dazu gehört das Anlegen und Bearbeiten von Lieferungen sowie von Bewegungsdaten für die Vereinnahmung. Auf die Stammdaten der Lager und Lagerplätze bekommt der Mitarbeiter lediglich lesenden Zugriff. Die Lagerplätze werden automatisch durch das System und dem Algorithmus vergeben. In den selteneren Fällen, wo das Lager ausgebaut wird oder gar neue errichtet werden, ist es vorgesehen, dass der Administrator diese ins System einpflegt. So können Probleme bei der Bedienung durch den Mitarbeiter eingegrenzt werden. 105

114 5. Realisierung Datenbanktabelle Create Read Update Delete Advice (Avise) x x x - DeliveryReceipt (Lieferungen) x x x - MovementData (Bewegungen) x x x - Item (Artikel) x x x - StorageArea (Lagerplätze) - x - - Warehouse (Lager) - x - - StorageMean (Lagerhilfsmittel) x x x - Customer (Kunden) - x - - Advice_Item x x x x Receipt_Item x x x x Dashboard - x - - Log Tabelle 5.2.: Rechte eines Lagermitarbeiters Generell ist es untersagt, Datensätze zu löschen. Dies gilt insbesondere für Lieferungen und Avise und trägt zur Nachvollziehbarkeit aller Vorgänge bei. Eine Ausnahme dieser Regelung stellen die Zwischentabellen Advice_Item und Receipt_Item dar. Die Zwischentabellen werden benötigt, um Artikel einer Lieferung beziehungsweise einem Avis zuzuordnen. Ein Löschen hier entspricht logisch einem Update auf der Tabelle Advice beziehungsweise DeliveryReceipt. Der Lagermitarbeiter hat so die Möglichkeit, Korrekturen bei der Eingabe der Artikel vorzunehmen. Dem Szenario entsprechend wird eine Korrektur nach dem Eröffnen des Wareneingangs allerdings nicht mehr gestattet (siehe Kapitel Wareneingang eröffnen). Einen Zugriff auf die Tabelle Log besitzt der Lagermitarbeiter nicht. Die Einträge sind nur für den Administrator einsehbar. Für die Tabelle Dashboard gibt es lediglich lesenden Zugriff, damit der Lagermitarbeiter beim Einloggen die Statistiken einsehen kann. Schreibenden Zugriff benötigt er nicht, da alle Aktualisierungen automatisch vom System vorgenommen werden (siehe Kapitel Übersichtsseite). Das System hat dabei immer vollen Zugriff auf alle Tabellen und Datensätze und besitzt keine eigene Benutzerrolle Umsetzung der Benutzerschnittstelle In den folgenden Unterkapiteln wird die Realisierung der Benutzerschnittstelle szenariobasiert erläutert. Dies beginnt mit der Übersichtsseite, die der Lagermitarbeiter nach dem Einloggen zu sehen bekommt. Danach wird die Realisierung der einzelnen Aktivitätsschritte abschnittsweise dargelegt. Zum Schluss wird noch auf die Realisierung des Loggings nach Log4J beschrieben. 106

115 5.4. MyInventory Übersichtsseite Die Übersichtsseite ist die erste Seite, die der Lagermitarbeiter nach dem Einloggen ins System zu sehen bekommt. Neben einer Begrüßung sind einige Statistiken über den Zustand des Lagers sowie über eingegangene Lieferungen und Avise zu sehen. Diese Daten werden automatisch beim Laden der Seite über eine entsprechende 4D-Methode aufbereitet. Im Formulareditor von Lightning wurde dazu im eröffnenden Tag des Formulars der Übersichtsseite eine Initialisierungsmethode angegeben (Siehe Quellcode 5.28). 1 <ltg form type="list" method="dashboard_init"> Quellcode 5.28: Initialisierung der Übersichtsseite Diese Methode Dashboard_Init errechnet also beim Start der Übersichtsseite alle erwähnten Statistiken. Für die Anzahl aller abgeschlossenen Avise wird zum Beispiel eine Query auf die Tabelle Advice abgesetzt, die alle Datensätze selektiert, die das Attribut finished auf true gesetzt haben (siehe Quellcode 5.29). 1 C_INTEGER($advice_closed) 2 QUERY([Advice];[Advice]finished=True) 3 $advice_closed:=records in selection([advice]) 4 [Dashboard]advice_closed:=$advice_closed Quellcode 5.29: Ermitteln der Anzahl aller abgeschlossenen Avise Über die Funktion Records in selection() kann schließlich die Anzahl aller geladenen Datensätze ermittelt werden und anschließend in die Tabelle Dashboard abgespeichert werden. Beim endgültigen Abspeichern des Datensatzes der Tabelle muss jedoch beachtet werden, dass insgesamt nur ein Eintrag vorhanden sein darf. Wie in Kapitel beschrieben, ist Dashboard eine Hilfstabelle zum Anzeigen der Statistiken. Auf der Weboberfläche sollen schließlich immer die aktuellsten Daten angezeigt werden. Dafür ist es ausreichend, wenn nur ein Datensatz erstellt wird, der bei jedem Aufruf aktualisiert wird. In Quellcode 5.30 wird die Implementierung dazu dargestellt. 1 ALL RECORDS([Dashboard]) 2 If (Records in selection([dashboard])=1) 3 FIRST RECORD([Dashboard]) 4 Else 5 CREATE RECORD([Dashboard]) 6 End if Quellcode 5.30: Sicherstellung, dass nur ein Eintrag vorhanden ist 107

116 5. Realisierung Zuerst werden alle Einträge der Tabelle Dashboard geladen. Anschließend wird überprüft, ob in der aktuellen Selektion ein Eintrag vorhanden ist. Wenn das der Fall ist, wird dieser Eintrag ausgewählt (FIRST RECORD()), ansonsten wird ein neuer Eintrag erstellt. In der Weboberfläche wird dann immer genau auf diesen Datensatz zugegriffen. Diese Implementierung ist an das Entwurfsmuster Singleton von Erich Gamma et al. angelehnt (vgl. [GHJV94, S. 127 ff.]). Für die Statistiken über die Lager und Lagerplätze wird in der Initialisierungsmethode dynamisch eine HTML-Tabelle erzeugt. So lässt sich auf der Oberfläche eine variierende Vorschau erzeugen, da sich die Anzahl der Lager und auch Lagerplätze ändern kann. Realisiert ist dies über eine Schleife über alle Lager (Warehouse) wie in Quellcode 5.31 zu sehen ist. 1 For ($i;1;records in selection([warehouse])) 2 $warehouse_info:=$warehouse_info + "<tr class= separator /><tr><td><strong>" + Ltg_Str_Encode( [Warehouse]description) + "</strong></td><td><strong>auslastung </strong></td></tr>" 3 // Load all related StorageAreas 4 RELATE MANY([Warehouse]warehouse_id) 5 6 // Infos about each StorageArea in current Warehouse 7 FIRST RECORD([StorageArea]) 8 For ($j;1;records in selection([storagearea])) 9 $overall_capacity:=$overall_capacity+[storagearea]capacity 10 $overall_quantity:=$overall_quantity+[storagearea]quantity 11 $warehouse_info:=$warehouse_info + "<tr><td style= padding left:20px; >" + Ltg_Str_Encode( [StorageArea]description) + "</td>" 12 $warehouse_info:=$warehouse_info + "<td class= datafield >" + String(([StorageArea]quantity 100)/ [StorageArea]capacity) + " %</td></tr>" 13 NEXT RECORD([StorageArea]) 14 End for NEXT RECORD([Warehouse]) 17 End for Quellcode 5.31: Lagerstatistiken generieren In dieser Schleife wird schließlich über den Befehl RELATE MANY() (Zeile 4) die Selektion zu allen Lagerplätzen ermittelt, damit anschließend darüber iteriert werden kann. So wird Zeile für Zeile HTML-formatiert die Übersicht der Lager generiert und in die Tabelle Dashboard gespeichert. In dem Formular für die Oberfläche wird schließlich dieses Attribut durch den 4DHTML-Tag <!- -4DHTML [Dashboard]warehouse_infos - -> eingebunden. Dieses Tag sorgt dafür, dass die HTML-Kommandos nicht als Zeichen dargestellt werden, sondern interpretiert werden und zur Formatierung beitragen. Strukturiert ist die Übersicht über eine HTML-Tabelle, die zwei Hauptspalten enthält. In der ersten Spalte werden die ganzzahligen Statistiken aus der Tabelle Dashboard, wie es 108

117 5.4. MyInventory in Kapitel beschrieben ist, eingefügt. In der zweiten Spalte werden schließlich die Lager- und Lagerplatzstatistiken eingefügt (siehe Abbildung 5.10). Abbildung 5.10.: Dashboard von MyInventory Lieferung eingeben Eine Lieferung wird über das Detailformular der Tabelle DeliveryReceipt angelegt. Dieses Formular enthält für alle Attribute der Tabelle Eingabefelder, die mittels des Lightning- Tags <ltg-field.../> eingefügt worden sind. Die Artikel der Lieferung werden über die Tabelle Receipt_Item zugeordnet. Da man sich zur Eingabe der Lieferung aber in einem anderen Formular befindet man befindet sich in einer anderen Tabelle kann an dieser Stelle das Listenformular der Tabelle Receipt_Item in das aktuelle Formular inkludiert werden. Dadurch sieht man im Detailformular der Lieferung eine Liste der anderen Tabelle. Das Einbinden geschieht wieder über ein Lightning-Tag, das in Quellcode 5.32 dargestellt ist. 1 <ltg include name="!list" table="receipt_item" /> Quellcode 5.32: Inkludieren eines Unterformulars in Lightning Das Attribut name gibt den Namen des gewünschten Formulars an. Mit der Angabe!List, wie es in diesem Fall angegeben ist, wird das Standard-Listenformular der angegebenen Ta- 109

118 5. Realisierung belle angefordert. Des Weiteren muss im Kopf der Detailansicht das Attribut relate-many auf true gesetzt werden. Dadurch wird automatisch die Relation zur Tabelle der gelieferten Artikel geladen. Somit werden in dieser inkludierten Tabelle nur die Artikel der aktuellen Lieferung angezeigt und nicht insgesamt alle Einträge aller Lieferungen. In der Listenansicht der Tabelle Receipt_Item gibt es Buttons zum Anlegen und Löschen von Artikeln. Dadurch ist es dem Lagermitarbeiter möglich, direkt in der Detailansicht der Lieferung komfortabel Artikel zu verwalten. Lediglich das Detailformular für die gelieferten Artikel (Tabelle Receipt_Item) ist eine andere Sicht, zu der man navigiert wird, um darin den gelieferten Artikel zu bestimmen und die gelieferte Menge anzugeben. Die restlichen Tabellenattribute, wie die Fremdschlüssel, werden durch eine realisierte Initialisierungsmethode, die im Detailformular angegeben ist, automatisch gesetzt und müssen nicht durch den Mitarbeiter beachtet werden. Die Auswahl eines Artikels an dieser Stelle wird von Lightning sehr komfortabel unterstützt. Sobald für einen Fremdschlüssel einer Tabelle ein Eingabefeld eingefügt wird, wird eine Auswahlbox neben diesem Feld angezeigt. Durch einen Klick darauf öffnet sich ein Selektionsformular entsprechend der referenzierten Tabelle. Dies ist in Abbildung 5.11 dargestellt. Abbildung 5.11.: Beispiel eines Selektionsformulars Dieses Formular ist wie ein normales Listenformular aufgebaut. Darin ist eine HTML- Tabelle mit einer Kopfzeile (thead) enthalten, in der die Spaltennamen bestimmt werden. Im Tabellenkörper (tbody) wird durch den XML-Kommentar <!- -LTG-LOOP- -> eine Schleife initiiert, in der schließlich Zeile für Zeile die Daten aus der Datenbank geladen werden. Dies ist wieder über das Lightning-Attribut <ltg-field.../> möglich. Zum Abschluss muss schließlich nur noch die Schleife (<!- -LTG-ENDLOOP-->) und die HTML- Tabelle abgeschlossen werden. In Quellcode 5.33 ist ein Minimalbeispiel mit nur einem Attribut zu sehen. 110

119 5.4. MyInventory 1 <table id="list_table"> 2 <thead> 3 <tr> 4 <td><ltg sort name="[item]item_id" title="interne ID"/></td> 5 </tr> 6 </thead> 7 <tbody> 8 <! LTG LOOP > 9 <tr> 10 <td><ltg field name="[item]item_id"/></td> 11 </tr> 12 <! LTG ENDLOOP > 13 </tbody> 14 </table> Quellcode 5.33: Aufbau eines Listen- und Selektionsformular in Lightning Der hier zu sehende Tag <ltg-sort.../> in der Kopfzeile ist ein zusätzliches Feature, das dafür sorgt, dass durch Klick auf den Spaltenkopf die Einträge entsprechend der Spaltenwerte sortiert werden. Wie schon erläutert, ist der Aufbau der Gleiche wie bei einer Listenansicht. Der einzige Unterschied ist, dass jeder Dateneintrag in einem Selektionsformular automatisch anklickbar ist und zur Auswahl des Eintrags führt. Nach der Auswahl des Artikels muss schließlich noch die gelieferte Menge angegeben werden. Durch einen Klick auf den Button zum Speichern gelangt man automatisch wieder zurück zum Detailformular. Auf diesem Button ist eine 4D-Methode hinterlegt, die überprüft, ob der gleiche Artikel vorab schon hinzugefügt wurde. Dadurch wird sichergestellt, dass keine doppelten Einträge generiert werden. Da man keine Constraints auf Attributpaare in der Datenbank legen kann (siehe Datenbankaufbau), wird diese Überprüfung durch eigenen Code realisiert. Die Implementierung nutzt einen Stack, da der aktuelle Dateneintrag entweder gespeichert werden soll (Artikel wurde vorher noch nicht hinzugefügt), oder aber gelöscht werden soll (es soll der vorherige Eintrag genutzt werden). In Quellcode 5.34 ist ein Auszug dieser Implementierung ersichtlich. 1 // Save actual record 2 PUSH RECORD([Receipt_Item]) 3 4 // Query for the same Receipt_Items 5 QUERY([Receipt_Item];[Receipt_Item]deliveryreceipt_id= [DeliveryReceipt]deliveryreceipt_id; ) 6 QUERY([Receipt_Item]; & ;[Receipt_Item]item_id=$actual_chosen_item) 7 8 If (Records in selection([receipt_item])=1) 9 // temp var for remembering the final selection 10 $temp_id:=[receipt_item]receipt_item_id // add the quantity of the new record to the record which is already in the db 13 [Receipt_Item]quantity:=[Receipt_Item]quantity+$actual_quantity 14 SAVE RECORD([Receipt_Item])

120 5. Realisierung 16 // Delete the record which wanted to be saved but is already in DB 17 POP RECORD([Receipt_Item]) 18 Ltg_SqNo_Reuse ( >[Receipt_Item];[Receipt_Item]receipt_item_id) 19 DELETE RECORD([Receipt_Item]) // set selection to the record which will be hold 22 QUERY([Receipt_Item];[Receipt_Item]receipt_item_id=$temp_id) 23 Else 24 // Restore new Receipt_Item 25 POP RECORD([Receipt_Item]) 26 SAVE RECORD([Receipt_Item]) 27 End if Quellcode 5.34: Temporäres Retten einer Selektion mittels eines Stacks Da es immer nur eine einzige Selektion auf eine Tabelle gibt (vgl. [4D 12b, S. 501]), muss die aktuelle Selektion mittels des Befehls PUSH RECORD zwischengespeichert werden. Erst dann beginnt die Suche nach vorhandenen Einträgen mit Hilfe der QUERY. Queries können, wie in diesem Beispiel zu sehen ist (Zeile 5 und 6), miteinander verknüpft werden. Diese verhalten sich dann wie SQL-Statements, die innerhalb der WHERE-Klausel mehrere Bedingungen durch AND und OR vorweisen. In den 4D-Queries werden dafür die booleschen Operatoren &, für eine logische UND-Verknüpfung, und, für die logische ODER-Verknüpfung, eingesetzt (vgl. [4D 12e, S ff.]). Mit dem Zeichen * am Ende einer Query wird deklariert, dass noch weitere Queries folgen und der Befehl noch nicht ausgeführt werden soll. Wird nun ein Eintrag gefunden, wird die neu eingegebene Menge auf den gefundenen Eintrag aufsummiert. Der Eintrag, der fälschlicherweise neu erstellt wurde, wird dann mittels des Befehls POP RECORD wiederhergestellt und gelöscht (Zeile 17-19). Mit der Lightning- Methode Ltg_SqNo_Reuse() wird dabei die zuvor automatisch generierte ID wieder freigegeben. Wenn allerdings kein Eintrag gefunden wird, wird der vorher gerettete Eintrag als neuen Datensatz in der Datenbank gespeichert. Nachdem nun beschrieben wurde, wie das Eingabeformular zum Anlegen einer neuen Lieferung realisiert wurde, geht es an die Realisierung des nächsten Aktivitätsschritt aus dem Konzept (siehe Benutzerschnittstelle), dem Eröffnen des Wareneingangs. Die Realisierung dazu wird im folgenden Abschnitt beschrieben Wareneingang eröffnen Das Eröffnen des Wareneingangs ist über das Detailformular der Lieferung möglich. Dazu wurde ein weiterer Button implementiert, der für diesen Schritt zuständig ist. Wichtig dabei ist, dass nach Eröffnen des Wareneingangs ein weiteres Betätigen dieses Knopfes untersagt werden muss. Nach Eröffnen des Wareneingangs ist schließlich die Vereinnahmung der nächste Aktivitätsschritt. 112

121 5.4. MyInventory Die wichtigste Funktionalität, die bei dieser Aktivität sichergestellt werden muss, ist das Verhindern der weiteren Bearbeitung dieser Lieferung. Realisiert ist dies durch Setzen des Zustands der Lieferung mit Hilfe des Attributs state der Tabelle DeliveryReceipt auf Wareneingang eröffnet und wird durch eine an einen Button gebundene 4D-Methode ausgelöst. In der Weboberfläche im Lightning-Formular wird überprüft, welchen Status die Lieferung hat. Wenn dieser Status also der Wareneingang eröffnet ist, werden die Eingabefelder als schreibgeschützt (readonly) gesetzt. Die Realisierung ist in Quellcode 5.35 für ein Eingabefeld dargestellt. 1 <! #4DIF ([DeliveryReceipt]state="Lieferung eingetroffen") > 2 <ltg field name="[deliveryreceipt]foreign_deliveryreceipt_id" mandatory="true" /> 3 <! #4DELSE > 4 <ltg field name="[deliveryreceipt]foreign_deliveryreceipt_id" readonly="true" mandatory="true" /> 5 <! #4DENDIF > Quellcode 5.35: Status-basierte Anzeige von Eingabefeldern Die Überprüfung hierbei bezieht sich auf den ersten Status, nämlich Lieferung eingetroffen. Nur dann ist es erlaubt, eine Bearbeitung durchzuführen. Ab dem Status Wareneingang eröffnet ist dies nicht mehr erlaubt. Der Kontrollfluss selbst ist hier über 4D-eigene HTML-Tags realisiert, die innerhalb eines XML-Kommentars eingefügt sind (#4DIF, #4DELSE, #4DENDIF). Eine elegantere Lösung, als Kontrollfluss in einen Kommentar einzufügen, ist durch ein später erschienenes Update des Tools Lightning ermöglicht worden. Dabei wurden spezielle Lightning-Tags eingeführt, die die 4D-Befehle für die Abfragen ablösen können. Nach dem gleichen Prinzip wird das spätere Hinzufügen beziehungsweise Löschen von Artikeln unterbunden. Dazu wurden die Buttons Neu und Löschen innerhalb eines Kontrollblocks gesetzt, der nur ausgeführt wird, wenn der Status Lieferung eingetroffen ist. Des Weiteren wird innerhalb der an den Button gebundenen 4D-Methode, die auch den Status auf Wareneingang eröffnet setzt, die gelieferte Menge mit der avisierten Menge verglichen. Die verschiedenen Fälle, die im Konzept im Kapitel beschrieben sind, wurden dabei beachtet. Für alle Abweichungen von der avisierten Menge wird eine Meldung erstellt, die abschließend dem Nutzer der Anwendung dargestellt wird. Dies ist durch eine 4D-Methode möglich, die von der Erweiterung Lightning bereitgestellt wurde. Die Hinweise an den Lagermitarbeiter, die sich in der Variable $message befinden, werden, wie in Quellcode 5.36 dargestellt, an die Benutzeroberfläche ausgegeben. 1 Ltg_Msg_Information( Ltg_Str_Encode($message) ) Quellcode 5.36: Ausgabe einer Information auf der Weboberfläche 113

122 5. Realisierung Die innere Methode Ltg_Str_Encode() sorgt dafür, dass alle Sonderzeichen und Umlaute korrekt dargestellt werden. Die äußere Methode sorgt hingegen dafür, dass die Nachricht, als Information formatiert, dargestellt wird. Andere Formatierungen wären in Lightning zum Beispiel über die Methode Ltg_Msg_Error() möglich. Wenn die Lieferung mit der avisierten Menge übereinstimmt, wird ebenfalls eine entsprechende Meldung ausgegeben. Zusätzlich wird das Flag finished der Tabelle Advice auf true gesetzt und wird in der Liste aller Avise dazu genutzt, eine schnelle Übersicht abgeschlossener Avise zu ermöglichen Vereinnahmung durchführen Die Vereinnahmung der Artikel erfolgt über das Unterformular der Tabelle Receipt_Item im Detailformular der Lieferung. Darin ist eine Liste aller gelieferten Artikel zu sehen, die vorab eingetragen wurden. Dort ist für diesen Aktivitätsschritt eine neue Spalte eingefügt worden, bei der zu jedem noch nicht vereinnahmten Artikel eine Verlinkung zu einer 4D- Methode hergestellt ist. In dem Screenshot in Abbildung 5.12 ist dies rechts unten zu sehen (Vereinnahmen). Abbildung 5.12.: Screenshot der Oberfläche zur Vereinnahmung Durch einen Klick auf diesen Link kann der Vereinnahmungsprozess für jede Artikelart einzeln vorgenommen werden. In der 4D-Methode wird dazu ein Bewegungsdatensatz der Tabelle MovementData vorbereitet. Dem Datensatz wird der entsprechende Artikel ([Receipt_Item]item_id), die zu vereinnahmende Menge ([Receipt_Item]quantity) 114