Praxissemsterbericht. Praxissemester bei ZF Friedrichshafen AG im EDI Bereich

Transkript

1 Praxissemsterbericht Praxissemester bei ZF Friedrichshafen AG im EDI Bereich Matrikel Nr:

2 1 Inhalt 1. Das Unternehmen 1.1. ZF Strategie beim elektronischen Geschäftsdatenaustausch 1.2. SAP Exchange Infrastructure 1.3. Arbeitsvorgang in der EDI Abteilung von ZF Friedrichshafen AG 2. Das Projekt 2.1. Vorgehensmodell zur Softwareentwicklung 2.2. Wasserfall-modell Anforderungsanalyse Business Process Modeling Notation EDI Arbeitsabläufe Use-Case-Diagram Architektur (Model-View-Controller) Backend Webservice Web Dynpro Technologie Model View Controller 3. Das Ergebnis der Applikation 4. Fazit und Quellen

3 2 1. Das Unternehmen Die ZF Friedrichshafen AG ist die Muttergesellschaft des ZF-Konzerns und zählt zu den weltweit führenden Unternehmen auf dem Gebiet der Antriebs- und Fahrtechnik. Die Produkte von ZF umfassen Getriebe, Lenkungen, Achsen, Kupplungen, Stoßdämpfer, Fahrwerkskomponenten und Systeme, Gummi-Metallkomponenten, und andere Bauteile für Pkw, Lkw, Busse, Baumaschinen, Landmaschinen, Bahn, Schiff, Flugzeug und Maschinen. ZF Friedrichshafen hat 117 Werke in 26 Ländern. Das Unternehmen ZF Friedrichshafen AG entwickelt, produziert und prüft weltweit Technologien für Antriebs- und Fahrwerktechnik. Auf der Weltrangliste der Automobilzulieferer gehört ZF zu den führenden Unternehmen und ist bestrebt, etablierte Märkte zu sichern und auszubauen. Die konsequente Ausrichtung auf den Kundennutzen bildet dabei den Kern des Unternehmens hat sich der ZF-Konzern deutlich schneller als erwartet von den Folgen der weltweiten Finanz- und Wirtschaftskrise erholt. Der Umsatz stieg um 38 Prozent auf 12,9 Milliarden Euro und erreichte damit ein neues Rekordniveau. ZF ist ein dezentral organisiertes Unternehmen, dessen Divisionen und Geschäftsfelder selbstständig am Markt agieren und sich flexibel am Kundennutzen orientieren. Die strategischen Weichenstellungen werden durch den Konzern vorgenommen. Dabei haben die Gesamtinteressen des Konzerns Vorrang vor den Interessen der Divisionen und Geschäftsfelder ZF Strategie beim elektronischen Geschäftsdatenaustausch Mittels EDI (Electronic Data Interchange) werden logistische und kaufmännische Daten auf elektronischem Wege zwischen Partnern in einem standardisierten Format ausgetauscht. Es ist für konzentrierte Business-Prozesse konstruiert, bei denen Dokumente etwa Bestellungen und Rechnungen in hohen Mengen, regelmäßig und automatisch zwischen einander bekannten Partnern abgearbeitet werden sollen. Als einer der größten Automobilzulieferer der Welt tauscht ZF mit Kunden und Lieferanten Daten per EDI aus. Für ZF soll EDI einen Austausch bei hohen Anforderungen an Performance, Sicherheit und Schnelligkeit bereitstellen. Der Datenaustausch in elektronischer Form ermöglicht die automatisierte Integration von Daten in ein Anwendungssystem wie SAP. Dabei entfallen manuelle Erfassungstätigkeiten. Daten wie Abruftermine und Abrufmengen werden korrekt eingelesen, sodass ausgangsseitig eine hohe Datenqualität gewährleistet wird. Innerhalb eines vollautomatisierten Geschäftsprozesses ist der elektronische Datenaustausch ein wichtiger Bestandteil der gesamten Prozesskette.

4 SAP Exchange Infrastructure Im Laufe der Zeit hat sich in vielen Unternehmen, aufgrund der unterschiedlichen Plattformen (z. B. Windows, Linux, Unix usw.), Programmiersprachen (z. B. ABAP, Java, C# usw.) und Hersteller (z. B. SAP, Siebel, Eigenentwicklungen usw.) eine heterogene Systemlandschaft (SAP- und Nicht-SAP-Systeme) etabliert. Mit Hilfe der SAP Exchange Infrastructure (SAP XI) ist es möglich diese Systeme miteinander zu verbinden. Somit ist eine Kommunikation zwischen den einzelnen Systemen, sowohl unternehmensintern als auch unternehmensübergreifend möglich. Die XI beruht auf einer offenen Architektur und bedient sich anerkannten Standards wie WSDL, XML, XSD, SOAP und Java. Sie ist ein Baustein der Technologie Plattform SAP-Netweaver. Die zentralen Komponenten der XI-Laufzeit ist der Integration Server Arbeitsvorgang in der EDI Abteilung von ZF Friedrichshafen AG Täglich gibt es Aufgaben pro Aufträge bei der EDI Abteilung zu erledigen. Bei Aufträgen handelt es sich um Bestellungen von ZF Weltweit, deren Werke und Lieferanten. Aufträge werden in verschiedene Prozesse z.b. Lieferabruf, Lieferschein, Rechnung von EDI Mitarbeiter bearbeitet. Die EDI Mitarbeiter sorgen für Transformation von elektronischem Datenaustausch zwischen ZF Werken und Lieferanten. Wie der Datenaustausch oder mit welchem System das gemacht wird( Mapping ), war für mein Projekt uninteressant. 2. Das Projekt Meine Aufgabe in der EDI Abteilung bestand darin, eine Software für die EDI Datenverwaltung zu realisieren. Die Software sollte benutzt werden, um die Status aller Aufträge der EDI übersichtlicher zu gestalten und zu bearbeiten. Es sollte bei jedem Auftrag gespeichert werden, um welchen Prozess es sich handelt, welche Mitarbeiter für welchen Auftrag verantwortlich waren und welche ZF Werke und welche Lieferanten zu einem Auftrag zuzuordnen sind. Zusätzlich werden auch noch alle auftragsrelevanten Daten für die EDI Abteilung gespeichert. Da sich das Projekt hauptsächlich um Bearbeitung der Aufträge und die dazu gehörige Daten beschäftigt, wurde das es zum Request Management Application benannt. Die Applikation sollte falsche Eingaben von Usern vermeiden. Bei falscher Eingabe sollte die Applikation eine Fehlermeldung mit einer genauen Fehlerbeschreibung anzeigen. Bestenfalls sollten die Fehler auf das Inputfeld hinweisen, in dem eine falsche Eingabe getätigt wurde.

5 4 Praxissemester bei ZF Friedrichshafen AG im EDI Bereich Die Tätigkeit könnte man als Entwicklung eines Request-Verwaltungstools mit SAP NetWeaver Technologie für die Abteilung EDI & Process Integration beschreiben. Darunter sind die Aufgabenschritte folgendermaßen aufgeteilt: Anforderungsanalyse Entwicklung in Java auf verteilten Systemen Konzept und Realisierung der DB als Basis für die Anwendung Konzept, Realisierung und Test der Software 2.1 Vorgehensmodell zur Softwareentwicklung Zu erledigen war ein komplettes Software Projekt von Anforderungsanalyse bis zur Implementierung. Daher war es sinnvoll ein Vorgehensmodell zu erstellen, um den Entwicklungsprozess in überschaubare, zeitliche und begrenzte Phasen zu unterteilen, und somit die Software Schritt für Schritt fertigstellen. Folgende Punkte können als Vorteile eines Vorgehensmodells für das Projekt betrachtet werden: Zielorientierte Vorgehen Projektbegleitende Dokumentation frühzeitige Fehlererkennung durch festgeschriebene Testaktivitäten Übersicht über Status der EDI-List Projekt Die gesamte Anforderungsanalyse und auch Java Programmierung, die in den nächsten Abschnitten der Arbeit beschrieben werden, wurde in der Vorlesungen IT Projektmanagement, Software Technik 1/2 und Objektorientierte Programmierung gut erklärt und auch praktiziert. Die gelernten Methoden konnte im Praktikum eingesetzt werden. Mehrere Vorlesungen und Laborübungen waren äußerst hilfreich. 2.2 Wasserfall-Modell Da der Umfang der Projektarbeit nicht zu groß war und es sich um keine Gruppenarbeit handelte, habe ich mich für das Wasserfall-Modell als Projektplan entschieden. Dabei gehen die Phasenergebnisse wie bei einem Wasserfall immer als bindende Vorgaben für die nächsttiefere Phase ein. Das Wasserfall-Model besteht aus 4 Phasen, die das Projekt in 4 selbständige Schritte bis zum Hauptziel unterteilen.

6 5 Abbildung 1: Wasserfall-modell Anforderungsanalyse Wer Erfahrung mit Programmierung hat, weißt dass eine falsche Anforderungsanalyse oder unklare Benutzererfordernisse Projektverlust verursachen und trotz langem Zeitaufwand anstatt dem verlangtem Ziel eher höhere Kosten erreichen. Es musste detailliert klargestellt werden, was die Software für EDI-Abteilung automatisieren soll. Was sind die Probleme? Was sind genaue Erfordernisse der EDI-Mitarbeiter? Wer sind die Benutzergruppen? Wie ist das Arbeitsablauf in der EDI-Abteilung? Hinzu kommen alle anderen Fragen, die sich nicht auf technische Realisierung des Projektes beziehen, sondern eher Wünsche des Benutzers sind. Dazu habe ich als ersten Schritt mich mit den Mitarbeitern bzw. die Benutzer in Kontakt gesetzt und im ersten Monat des Praktikums hatte ich mit meiner Betreuerin (Frau Büttcher) und einem Mitarbeiter (Herr Kaufman) des EDI-Teams wöchentlich eine Jour fix Meeting. In dem Meeting haben wir die Anforderungen des EDI besprochen und das Ergebnis in einen, für alle verfügbaren Mindjet MindManager befasst. Meine Betreuerin Frau Büttcher ist die Gruppenleiterin des Lieferantenteams und auch ein Benutzer der Software. Sie konnte mir in der Anforderungsphase viel helfen.

7 6 Es folgen einige Beispiele von meinen Notizen nach jedem Jour Fix oder Besprechung mit den Mitarbeitern in der Abteilung: Die EDI Mitarbeiter wollen wissen, welcher Mitarbeiter mit Welchem Lieferanten in Verbindung ist, um es zu vermeiden dass zwei oder mehrere EDI Mitarbeiter unterschiedliche Prozesse bei demselben Lieferanten bearbeiten. Das Ziel ist es, dass ein Mitarbeiter alle Prozesse von einem Lieferant bearbeitet. Der Bearbeiter muss am System nach Lieferanten Namen suchen können. ( Such Option). Es müssen in einem bestimmten Zeitintervall alle Aufträge, deren PI Status (Lieferschein) auf finished sind, in einer extra Tabelle erscheinen damit Frau Büttcher diese bearbeiten kann. Ein Lieferant wird nur von einem EDI Center Mitarbeiter bearbeitet. Der EDI Center Mitarbeiter darf aber mehrere Lieferanten bearbeiten. Erst wenn Status SAP auf finished und die Kategorie auf Rollout gesetzt ist, soll eine automatische an die in der Liste zugeordnete Person gesendet werden. Frau Büttcher in der EDI muss entscheiden können, welche Mitarbeiter welchen Auftrag bearbeiten. Nachdem die erwünschten Anforderungen einiger Maßen klar gestellt wurden, kamen auch noch teilweise technischer Fragen, die ich in Jour fix Meeting gestellt habe: Was ist das Parameter data sheet für eine Datentype? Ein URL Link? Kann man das als normalen Text betrachten? Welche der Stammdaten sind bei der Erstellung eines neuen Auftrags Pflicht und welche sind nicht Pflicht? Wo werden Standorte und Werk Nr. bei View gezeigt? Reicht es wenn man durch Auswahl der finished bei der Drop-down Menü erledigte Aufträge in der Spalte sehen kann? Um die Anforderungsanalyse besser zu verstehen, sollte ich für täglichen Arbeitsablauf der EDI-Abteilung eine Business Process Modeling Notation Diagram und für Benutzer Gruppen eine Use-Case-Diagram für Benutzerrechte darstellen.

8 Business Process Modeling Notation EDI Arbeitsabläufe Um eine Software zu realisieren ist es wichtig zu wissen, welche Daten von welchem User eingegeben werden und für welche User die Daten Sichtbar sein müssen. Oder welche Daten in welche Views sichtbar sein müssen. Das Business Process Modeling Notation oder auch als Abkürzung BPMN genannt, ermöglicht eine grafische Spezifikationssprache, mit dem man diese Fragen beantworten kann. Als erstes habe ich die Benutzergruppen (FB, Lieferant, EDI, ZGMS, Werk) im Bezug der Request Management Application Datenverwaltungsprogramm und auch die Prozesse (Lieferabruf, Lieferschein, Rechnung) für den täglichen Arbeitsablauf der EDI Bereich eingeteilt. FB steht für den ZF Fachbereich, in dem sich ZF Weltweit Werke sich befinden. Die ZGMS ist die Abkürzung für EDI Weltweit Mitarbeiter, die von ZF AG als erste ZF Mitarbeiter betrachtet werden, die für eine Bestellung den Lieferanten kontaktieren. Abbildung 2: Business Process Modeling Notation

9 8 Als Beispiel wird der Arbeitsablauf eines Lieferabrufes beschrieben: ZF-Werk sendet einem Auftrag an ZGMS. ZGMS Mitarbeiter spricht mit dem Lieferant und trägt den Auftrag in der Request Management Application Datenverwaltungsprogramm ein. Der EDI Mitarbeiter konfiguriert die SAP Anwendung (PI) in der EDI und testet den elektronische Datenaustausch für den Lieferabruf mit dem Lieferanten. Wenn die Testphase mit dem Lieferanten fertig ist, wird der Status PI in der Request Management Application Datenverwaltungsprogramm auf finished gesetzt, sonst bleibt der Status auf testing Use-Case-Diagram Eines der Anforderung war die Fähigkeit des Programms, Benutzerrechte vergeben zu können. z.b nur Admin bzw. die Frau Büttcher darf einen zu bearbeitenden Auftrag zu einem Mitarbeiter zuordnen. Um benutzerrechte für das Programm zu realisieren, sollte man wissen welche Benutzergruppen es für das Programm gibt, und wie sie das Programm benutzen. Die Übersicht für Benutzergruppen und was sie mit dem Programm erledigen, habe ich mit Use-Case- Diagram dargestellt. Die Benutzerrechte für Request Management Application Datenverwaltungsprogramm war die niedrigste Priorität, die ich auch im Zeitraum des Praktikums nicht geschafft habe zu erledigen. Diese und noch ein paar nicht geklärte Anforderung könnten das Thema für meine Bachelorarbeit bei ZF Friedrichshafen sein. Abbildung 3: Use-Case-Diagram

10 9 Praxissemester bei ZF Friedrichshafen AG im EDI Bereich Architektur Das Programm sollte Plattform- und Framework-unabhängig für EDI Teams in verschiedenen ZF Werke, in den Standorten der ZF über myzf Portal verfügbar sein. Dies wird über Webservices ermöglicht. Web Dynpro ist die im Projekt verwendete Technologie, die zur Darstellung von webgestützten Anwendung dient. Es sollten die Datentransformation vom Server zu Browser und umgekehrt über Webservice ermöglicht werden. In der untersten Schicht der Architektur steht die Datenbank. Der Zugriff auf die Datenbank wird mit JDBS realisiert und von so genannten Bean Klassen zu Verfügung gestellt. Der Webservice stellt die von JDBS implementierten Methoden über das Web und in XML Format zur verfügen. Die Web Dynpro Programmierung basiert auf dem MVC-Entwurfsmuster. Weil das MVC einen flexiblen Programmentwurf macht, der unter anderem eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Das MVC stammt aus Smalltalk, und dient zur Strukturierung von Anwendungsobjekten mit einer visuellen Darstellung. Dadurch beschreibt die prinzipielle Architektur die Anwendung (wie Architekturmuster). Das unterscheidet 3 Aspekte eines Objekts, die sonst oft zusammengeworfen werden fachliche Aspekte (Modell) Darstellung (View) Reaktion auf Benutzereingaben (Geschäftslogik, genannt Controller) MVC trennt diese Aspekte und realisiert sie durch verschiedene Objekte, um Wiederverwendbarkeit und Flexibilität zu vergrößern und koppelt sie locker über hat-ein - Beziehung und Observer-Entwurfsmuster. Abbildung 4 MVC-Entwurfsmuster

11 10 Kurze Erklärung zu EDI_Custom_Controller, Model und Views: Das Model ermöglicht dem Controller den Zugriff auf die EDI Datenbank. Die Klasse EDI_Custom_Controller erstellt die ganze Logik für die Verbindung zwischen den Views und dem Model. Jeder View hat eine Klasse für die Darstellung der Übersicht und der Oberflächenelemente. Die Views verwenden die in Controller implementierte Methoden, um auf die Datenbank zu zugreifen. Abbildung 5 Web Dynpro Explorer

12 Backend Bei der Anforderungsanalysephase und zur Klarstellung der Daten Basis und die Kordialitäten von einzelnen Tabellen, habe ich eine Entity Relation Model für Datenbank EDI modelliert. Dies dient dazu, im Rahmen der semantischen Datenmodellierung einen Ausschnitt der realen Welt von Request Management Application zu beschreiben. Z.b eine Auftrag (Order) hat ein Werk(ZF Plant) und einen Lieferanten(Supplier). Das heißt jeder Lieferant oder jedes Werk kann zu einem oder mehreren Aufträge zugeordnet sein. Abbildung 6 Entity Relation Model für Datenbank EDI

13 12 Um die Einzelne Einträge in der Datenbank zu spezifizieren braucht man natürlich eine eindeutige ID für jeden Eintrag. Die IDs bei den Tabellen in der Datenbank sollten nicht vom User gefordert werden, sondern es wird beim Anlegen eines Datensatzes eine neue eindeutige ID automatisch erzeugt und in der Datenbank gespeichert. Um die Erzeugung von eindeutige IDs bei der Tabellen Einträge in der EDI List DB zu automatisieren, braucht man Sequences, die automatische Hochzählung von Einträgen ermöglichen und noch Triggers, die in dem Fall als Beobachter für neue Daten dienen. Triggers erzeugen also einen neue eindeutige ID für jeden neuen Auftrag. z.b sobald ein Auftrag in der Datenbank hinzugefügt wird, wird der Trigger (AUFTRAG_HOCHZAEHLEN) der Sequence (ID_AUFTRAG_HOCHZAEHLEN) aufrufen. Dieses Sequence Zählt die ID_Auftrag auf eine Zahl hoch, und liegt diesen Integer als ID für den neuen Auftrag in der EDI LIST DB Datenbank fest. Somit existiert für jeden Eintrag in jeder Table eine eindeutige ID Nummer, die in unserem Fall eigentlich nur intern zur Identifizierung und Verbindungen zwischen abhängige Einträge verwendet wird. Beinahe die gleiche oder sogar umfangreichere Arbeit hatte ich in der HTWG Konstanz bei der Datenbanken Vorlesung oder im auch Labor. Der Stoff wurde in der HTWG gut geklärt und das hat mir bei der Realisierung von Request Management Application Datenbank viel geholfen. Abbildung 7 Request Management Application Datenbank

14 Webservice Für die transaktionsbasierte Ausführung von Request Management Application und EDI List Database über Webdynpro wurde ein Webservice EDIListWS mit J2EE erstellt. Um die Entwicklung komplexer mehrschichtiger verteilter mittels Java zu vereinfachen, wurden Enterprise JavaBeans (EJB) eingesetzt. Diese EJBs sind standardisierte Komponenten innerhalb von ZF Java-EE-Server. EDIListWS beinhaltet vier Packages (beans, logic, persistence, util) und darunter die benötigten Java Klassen, die in Entwicklungsabteilung von ZF Friedrichshafen AG als standardisierte Form verwendet werden. util: In util Klassen sind Java Klassen mittels JDBC implementiert, die allgemein für Datenbank Connection wiederverwendet werden. persistence: Für jede Tabelle in der Datenbank wurde eine Klasse unter persistence Package implementiert. Diese Klassen wurden verwendet um die jeweiligen Objekte zu kapseln. Das heißt jeder Eintrag in der Datenbank wird zuerst als ein Objekt gekapselt und mit einer eindeutigen ID in der Datenbank gespeichert. logic: Unter logic kommen Klassen die mit der Betrachtung vom Geschäftslogik für Datenbearbeitung benötig werden. Bei Request Management Application handelt es sich um eine Datenverwaltungsprogramm. Es gab also vier Funktionen die für die Entwicklung wichtig waren. Diese Funktionen sind also Daten hinzufügen, löschen, aktualisieren und aufrufen. Abbildung 8 ejb

15 14 Die sogenannte DAO (Data Access Objects) Klassen realisieren die oben genannten Funktionen. Beim Hinzufügen eines Auftrages bekommt z.b. die EDIListAddDAO klasse als Parameter für seine Konstruktor den einzutragenden Auftrag als Objekt. Dieses Objekt ist eine Instanz von Typ Auftrag unter persistence Package. Dazu erzeugt die EDIListAddDAO Klasse erst mal eine Instanz von SQLInsertStatmentHelper um die Connection mit Datenbank für Hinzufügen eines Auftrages in Datenbank zu ermöglichen. Danach werden die Details vom neuen Auftrag in Datenbankspalten eingetragen. beans: Bei der Erstellung eines Webservices unter J2EE werden automatisch für jede DAO Klasse eine Schnittstelle erstellt. Sie werden für Webservice als Schnittstelle benutzt Web Dynpro Technologie Die eingesetzte Technologie für Softwareentwicklung in IT Abteilung von ZF Friedrichshafen AG ist die Web Dynpro mit Java Programmierung Sprache. Web Dynpro (WD) ist eine Technologie, die von SAP im Rahmen der NetWeaver Strategie eingeführt wurde. Sie dient dem Erstellen von webgestützten Anwendungen, die mit einem SAP ERP und anderen Systemen zusammenarbeiten. Die Web Dynpro Programmierung basiert auf dem MVC-Entwurfsmuster. Sie basiert auf Java oder ABAP. Während die Java-Version bereits seit der SAP NetWeaver-Einführung verfügbar ist, ist die ABAP-Variante erst seit Anfang 2006 verfügbar. Views beinhalten das Layout und die Darstellung der Daten. Eine View wird ausschließlich aus vorgefertigten Elementen zusammengefügt, so dass keine Kenntnisse zu HTML erforderlich sind. Jede View hat ihren eigenen View-Controller. Component Controller verbinden Models mit View-Controllern und steuern den Ablauf der Applikation. Models dienen der Datenbeschaffung z. B. aus SAP R/3 Systemen via adaptive RFC-Model oder zum Beispiel per Web Services. Models beinhalten einen Model-Kontext, der die Daten des jeweilig letzten Model-Aufrufs enthält. Kontexte sind jedem Controller zugeordnete Datenspeicher. Der Kontext eines View- Controllers speichert die Daten solange die View aktiv ist (vergleichbar dem Request einer J2EE- Anwendung). Der Component-Controller speichert die Daten View-übergreifend, solange die Applikation läuft (vergleichbar der Session). Mapping verbindet die Daten der Kontexte und veranlasst einen automatischen Datenabgleich zur Laufzeit.

16 15 Im Zusammenspiel werden nun verschiedene Views auf einem Window angeordnet und die Startview wird markiert. Diese wird zur Laufzeit zuerst angezeigt. Durch Interaktion des Benutzers über Bedienelemente werden Events ausgelöst, die Methoden in den Controllern ansprechen. In diesen Methoden programmiert der Entwickler nun z. B. Model-Aufrufe, um Daten aus den Backend-Systemen zu beschaffen. Über das Mapping der Kontexte werden diese innerhalb der Web- Dynpro-Applikation transportiert, so dass sie in einer View wieder angezeigt werden können Model Die Daten für eine Web-Dynpro-Anwendung werden über so genannten Web-Dynpro- Models zur Verfügung gestellt. Für die Definition und das Editieren dieser Models sowie für einen Zugriff auf Daten eines externen XMI-Models stellt das SAP NetWeaver Developer Studio spezielle Model-Werkzeuge zur Verfügung. Die Werkzeuge reduzieren den Zeitaufwand und die Codierung, die man normalerweise für die Implementierung gebraucht hätte. Dieser sogenannte Model dient der Datenbeschaffung per Webservice. Model beinhaltet einen Model-Kontext, die die vorher genannten Schnittstellen in Webservice entsprechen. Durch die Verbindung von Model und EDI_Custom_Controller würde eigentlich die Datenübertragung von Applikation Oberfläche und Datenbank möglich. Man könnte somit im Prinzip das Model als Backend Schnittstelle und die Controller als Oberfläche Schnittstelle betrachten. Diese transportieren Objekte, die von Geschäftslogik definiert sind. Abbildung 9 Model

17 View Die Präsentations-Schicht ist für die Darstellung der benötigten Daten aus dem Modell und die Entgegennahme von Benutzerinteraktionen zuständig. Sie kennt sowohl ihre Steuerung als auch das Modell, dessen Daten sie präsentiert. Sie ist aber nicht für die Weiterverarbeitung der vom Benutzer übergebenen Daten zuständig. Im Regelfall wird die Präsentation über Änderungen von Daten im Controller weitergegeben. Die Web-Dynpro-Werkzeuge liefern Unterstützung für die Oberflächenentwicklung während der Design- und der Implementierungsphase. Das View-Layout wird im Layout Editor entworfen, die benötigten Benutzungsoberflächen-Elemente sind für eine gute Übersicht in diverse Kategorien eingeteilt. Das Layout von UI-Elementen wird in der Regel zur Designzeit erstellt. Alternativ können Sie es auch dynamisch zur Laufzeit anlegen. Für jedes Element gibt es außerdem zahlreiche Eigenschaften, die Verwendungsmöglichkeiten und das Erscheinungsbild der einzelnen Elemente in einer Bildschirmoberfläche sind daher zahlreich. Beispiele für einfache Oberflächenelemente sind Feldbezeichner und Eingabefelder. Komplexe Objekte wie Tabellen bieten z.b. Schachtelungsoptionen. Für eine Gruppierung von zusammengehörigen Elementen in einer Anwendung stehen Container-Elemente zur Verfügung. Auch das Oberflächenelement für die Integration interaktiver Formulare lässt sich mit einem Mausklick in den Arbeitsbereich des Layouts Editor bringen. Von dort lässt es sich mit dem integrierten Adobe-Designer-Werkzeug bearbeiten, welches wiederum die Web-Dynpro-relevanten Formular-Elemente, zum Beispiel für eine Werteprüfung gegen ein SAP System, enthält (Adobe Bibliothek). Der automatische Datenfluss zwischen View-Layout und View-Kontext wird durch die Definition der Datenbindung in diesem Schritt ermöglicht.

18 17 Bei meinem Projekt musste ich 24 Views erstellen. Davon waren aber ein paar für Sicherheit Abfragen, wenn man zum Beispiel eine Änderung in der Applikation speichern wollte. Es gibt auch kleine Dialogboxs, die zum Beispiel für Auswahl eines Werks von ZF Werke bei Erstellung einen Auftrags zu Verfügung steht. Abbildung 10 Views In Abbildung 10 sieht man eine Übersicht von alle Views, Controllers, und Models. Dies ist ein Werkzeug von Web Dynpro Technologie, die zur Übersicht von Komponente/ en in einer Applikation zu Verfügung steht. Im Bild sind drei Schichten (sowie man es auch Üblicherweise von MVC Model View Controller Architektur kennt) zu unterscheiden. Die oberste Schicht besteht aus Views, die eigentlich keine Logik beinhalten sondern nur zur Darstellung von Oberfläche Elementen zuständig sind. Nach der Datenbank und EJB bzw. Beans Realisierung waren Views der nächste Schritt, mit dem es sich zu befassen galt. Es gibt genügend Funktionen, die für die Bearbeitung von Oberfläche Elemente in einem View von Web Dynpro Technologie breit implementiert sind. Es hat eine gewissen Zeit in Anspruch genommen bis die Oberfläche Elemente von Web Dynpro Technologie oder allgemeine die Programmierung mit dieser Technologie erlernt wurde. Die mittlere Schicht zeigt die Controller Klassen (Die Funktionalität von Controller Klassen wird in nächste Abschnitt geklärt). In der untersten Schicht sind die Models.

19 18 Im Bild sind auch die Pfeile, die von oberen Schichten nach unten verbunden sind. Die Pfeile zeigen die Beziehungen zwischen den Schichten. So wie man es auch im Bild sehen kann, haben die Views Zugriff auf Controllers. Eine View benutzt, oder besser gesagt ruft die Implementierte Methoden von Controller. Das gleiche gilt auch für die Beziehung von Controllers und Models. Um die Funktionalität von Controller handelt es sich im nächsten Abschnitt. Abbildung 11 Diagram View Jeder View in Webdynpro Entwicklung hat drei Perspektiven. Eine Klasse in dem man eine beliebige Java Sprache Code schreiben kann. Üblicherweise wird in dieser Klasse nur der benötige Code zum Aufrufen von Methoden in Controller Klassen geschrieben. Noch ein Vorteil dieser Architektur liegt es darin, dass die Implementierte Methoden von Controller in beliebig vielen Views unabhängig wiederverwenden kann. Diese Klasse wird gezeigt wenn man auf Implementation klickt. Dies wurde in Abbildung 11 durch einen Pfeil gezeigt. In der zweite Perspektive( so wie man es in Abbildung 11 sieht) handelt es sich um die veränderbare Oberfläche Elemente. Im linken Bereich vom Bild sieht man alle Views und darunter Ihre einzelnen Oberfläche Elemente. Im aktuellen Fall wurde auf dem View Namens AuftragErstellen geklickt. Und unter Outline wurden alle Elemente von AuftragErstellen sortiert. Beim Anklicken auf diese Elemente werden in rechten Bereich unter Properties die jeweilige Element Eigenschaft, die man auch Manuel ändern kann, gezeigt.

20 19 Die letzte Perspektive von View ist Context. Der Context bei WD entspricht in der Programmierung den normalen Variablen, die man als Platzhalter beim Programmieren benutzt. Sie sind meistens mit den Context von Controllers verbunden, außer wenn es sich um eine dynamische Variabel handelt, die man nur zur Laufzeit verwendet, und nicht in der Datenbank gespeichert werden muss. Die Controller Klassen haben eigene Contexte, die mit Model bzw. mit Datenbank verbunden sind Controller Die Controller Klasse in WD ist die wichtigste Klasse, die die gesamte Logik beinhaltet. Diese hat zwei Perspektiven. Einmal die normale Java Klasse und das Controller- Context. So wie ich es oben beschrieben habe, entspricht der Context bei Web Dynpro dem gleichen Platzhalter, wie man es beim Programmieren kennt. Einziger Unterschied ist die manuelle Verarbeitung von Variablen und, dass diese Variablen in Programm Code implementieren werden müssen. Bei der Controller Klasse von Request Management Applikation habe ich 2336 Zeilen Code programmiert. Das ist natürlich wegen Unsichtbarkeit nicht gut, dass eine Klasse so viele Zeilen und Methoden hat, aber da am Ende des Praktikum nicht mehr viel Zeit übrig blieb und die Abteilung bald die Applikation produktiv setzen wollten, war es nicht möglich sich mit weiteren Klassen zu beschäftigen. Ich werde Wahrscheinlich für Bachelorarbeit noch in ZF Friedrichshafen AG weiter angestellt und werde diese Klasse noch in paar Klassen teilen.

21 20 3. Das Ergebnis der Applikation Nachdem das Projekt bzw. die Applikation fertig war, gab es immer wieder Kleinigkeiten die ich vor der Produktivsetzung erledigen musste. Trotz fast vollständiger Anforderungsanalyse, die wir in der Abteilung am Anfang des Praktikums gemacht haben, gab es sogar in der Logik Missverständnisse die ich noch ändern musste. Die Applikation sollte auf eine internes Portal von ZF Namens myzf erscheinen. Deshalb musste ich noch die Übersicht und Fenstergröße zu diesem Portal anpassen. Nachdem die Applikation vollständig war, hatte ich ein Meeting mit dem Chef der EDI Abteilung(Herr Fuchs), Frau Büttcher und Herr Kaufman. Im Meeting dürfte ich die Applikation vorstellen. Vor dem Produktivsetzung und Verbindung mit myzf Portal musste die Anwendung einen Abnahmetest bestehen. Im Folge werde ich zwei wichtige Fenster vom Request Management Application beschreiben. Abbildung 12 Overview In der Abbildung 12 sieht man die Overview Tab. In diesem Fenster werden alle Aufträge der EDI Abteilung angezeigt (Die Einträge sind keine echten Aufträge sondern nur Testdaten). Jede Zeile wird als ein Auftrag bezeichnet und die Spalten sind Details von den Aufträgen. Im oberen Bereich sieht man vier Buttons. Wie man es im Bild sieht sind alle Daten Text Views, also auf dieser Tabelle kann man nicht die Details von Einträge ändern aber wenn man auf Edit Button klickt, wird man auf einem neuen Fenster landen, in dem man die Daten des in Overview ausgewählten Auftrags bzw. Zeile bearbeiten kann.

22 21 Falls man einen Auftrag bzw. eine Zeile löschen will, kann man auf Delete Button klicken. Vor dem Löschen eines Auftrages, wird zuerst der User gefragt ob jener wirklich den Auftrag löschen will. Es gibt mehrere EDI Mitarbeiter die in unterschiedlichen Orten der Welt mit dieser Anwendung arbeiten. Deswegen steht ein Refresh Button zur Verfügung. Wenn man auf diesen Button klickt werden alle Daten erneut von der Datenbank geholt oder aktualisiert. Wenn man einen neuen Auftrag anlegen will, muss man auf Create New Entry Button klicken. Dann wird ein neues Fenster zum Anlegen eines neuen Auftrags scheinen. Dieses Fenster wird im nächst folgenden Teil erklärt. Alle Spalten sind sortierbar. Jede Spalte hat im oberen Bereich eine Filter Funktion, mit dem man nach belieben Wörter in den jeweiligen Spalten suchen kann. Für einen Auftrag könnten null oder mehrere Kommentare existieren, die von einem oder mehreren EDI Mitarbeiter eingegeben werden können. Diese Kommentare mit jeweiligem Datum kann man im Overview sehen in dem man auf sogenannte Popin (die kleine schwarze Dreieck in der Klinke Seite der Tabelle) klickt. Unter Responsible EDI Spalte sieht man Select Button für jeden Auftrag in der Tabelle. Mit dieser Funktion kann man einen Mitarbeiter für den jeweiligen Auftrag auswählen, der diesen Auftrag erledigen muss. Beim klicken dieses Buttons wird, wie man es im Bild sieht, ein Dialog Box Fenster erscheinen. Auf diesem Dialog Box sieht man die Liste aller Mitarbeiter. In dieser Liste unter Number of Entry with same Supplier Spalte, sieht man die Anzahl von Aufträgen, die der jeweilige Mitarbeiter mit demselben Lieferant von ausgewähltem Auftrag bearbeitet hat. Das hilft Frau Büttcher bei der Entscheidung, welcher Mitarbeiter am besten dazu passt, diesen Auftrag zu erledigen. Nach der Auswahl eines Mitarbeiters, wird statt Select Button in der Overwiev, der Name der Mitarbeiter stehen.

23 22 In der Abbildung 13 sieht das Fenster Create New Entry. In diesem Fenster kann man einen neuen Auftrag für die EDI Abteilung anlegen. Für jeden Auftrag sollte man ein Werk und einen Lieferant und andere Eingaben, die für Erstellung eines Auftrages Angefordert sind, eingeben. Es gibt aber auch Eingaben wie Comment, Link to parameter data sheet, die man freiwillig eingeben kann. Wenn man die angeforderten Eingaben nicht eingibt und auf Save Button klickt, wird, wie man es im Bild sieht, im unteren Bereich eine Fehlermeldung mit roter Farbe scheinen und wenn man auf den jeweiligen Fehler klickt, wird der User auf Fehlende Eingabe hingewiesen. Abbildung 13 Create New View Im Create New Entry Fenster kann man ein Werk von der bereits angelegte Werkliste auswählen, indem man auf den Select Plant Button klickt. Dadurch wird eine Dialog Box mit der Liste aller ZF Werke erscheinen, in dem man ein Werk für diesen neuen Auftrag auswählen kann. Die Details von einem Lieferanten, wie Supplier Name, Supplier Nummer und DUNS muss der Benutzer Manuel eingeben.

24 23 Die Anwendung kontrolliert beim jedem Anlegen von Aufträge und Eingabe von Lieferanten, ob es sich um einen neuen Lieferant handelt, oder um einen schon bereits in der Anwendung eingegeben Lieferant. Falls der Lieferant neu ist, wird unter Tab Lieferanten(Supplieres) und darunter Lieferanten Liste ein neuer Lieferant mit denselben Details automatisch hinzugefügt. Sonst wird der neue Auftrag zu bereits existierenden Lieferant zugewiesen. Auch beim Löschen eines Auftrages in der Overwiev wird zuerst von der Anwendung kontrolliert, ob es mehrere Aufträge gibt, die mit zu löschenden Lieferant verbunden sind. Falls dies der Fall sein sollte, wird der Lieferant von der Lieferantliste nicht gelöscht, sonst wird dieser Lieferant automatisch gelöscht, weil es keinen Auftrag für diesen Lieferant gibt. Man könnte das Projekt noch erweitern und umfangreicher machen. Die Erstellung von Benutzerrechte oder Reports, die noch nicht genau geklärte Darstellung von Statistik, der erledigt oder nicht erledigte Aufträge in bestimmtem Zeitraum darstellen soll, könnte, wie schon bereits erwähnt, ein Thema für meine Bachelorarbeit im siebten Semester bei ZF Friedrichshafen AG sein. 4. Fazit und Quellen Im Praktikum bei ZF Friedrichshafen AG durfte ich Erfahrungen über das unternehmerische Umfeld sammeln. Man hat die Hierarchien von Abteilungen erleben können und die Unternehmenskultur besser kennengelernt. Es gab zum Anfang des Projektes ständig Termine und Jour fix, die ich organisieren musste. Anfangs wusste ich nicht, wie die Software funktionieren soll oder wie die Verbindung von Oberfläche und der Datenbank gemacht werden soll oder wie ich die Oberfläche mit Web Dynpro Technologie erstellen soll, vorallem weil ich davor nie mit Web Dynpro gearbeitet hatte. Aber ich habe gemerkt, dass beim Unternehmen nicht alles so schnell wie die normalen Vorgehensweisen im Studium ist, sondern dass man für jeden Schritt Geduld mitnehmen musste. Meine Wunsch für das Praktikum war es, dass ich Erfahrungen mit Softwareentwicklung sammle und zum ersten Mal eine vollständige Software oder Applikation realisiere. Die Tatsache, dass es sich bei dem Projekt nicht um eine Gruppen handelte, könnte man vielleicht als Vorteil für mich sehen, weil ich in Rahmen meines Praktikum alle Relevanten Anforderungen eines Software Projektes umsetzen dürfte.

25 24 Quellen: