3 SAP NetWeaver als Integrationsplattform
Werbung
AIXTRON Seminararbeit NetWeaver im Studiengang Scientific Programming von Sebastian Szlósarczyk Mat.Nr.: 827621 1. Betreuer: Prof. Dr. rer. nat. Volker Sander 2. Betreuer: Dipl. Ing. CIO Olaf Rupprecht AIXTRON Seite 2 von 54 AIXTRON Inhaltsverzeichnis EIDESSTAATLICHE ERKLÄRUNG ....................................................................................................................... 5 1 EINLEITUNG .......................................................................................................................................................... 6 1.1 1.2 2 MOTIVATION ................................................................................................................................................ 6 AUFBAU DIESER ARBEIT / ÜBERBLICK .......................................................................................................... 6 UNTERNEHMENS – UND WEBPORTALE .................................................................................................. 7 2.1 DEFINITION ................................................................................................................................................... 7 2.2 UNTERNEHMENSPORTALE ............................................................................................................................ 8 2.2.1 Eigenschaften .......................................................................................................................................... 8 2.2.2 Anforderungen an ein Unternehmensportal ............................................................................................ 9 2.3 KONKRETISIERUNG DER UMSETZUNGSZIELE ................................................................................................ 9 2.3.1 Prozess – und Informationsintegration (Integration Anwendung und Information) ............................. 10 2.3.2 Personalisierung ................................................................................................................................... 10 2.3.3 Single-Sign-On ...................................................................................................................................... 11 2.3.4 Portalkonzept ........................................................................................................................................ 11 2.3.4.1 2.3.4.2 2.3.4.3 2.3.5 Präsentationsschicht ......................................................................................................................................12 Anwendungsschicht .......................................................................................................................................13 Backendschicht ..............................................................................................................................................14 Client – Server....................................................................................................................................... 14 2.3.5.1 2.3.5.2 Definition ......................................................................................................................................................15 Client - Server bei Portalen ...........................................................................................................................15 2.4 WEBBASIERTE PORTALE/ANWENDUNGEN ................................................................................................... 16 2.4.1 Netzwerkumgebung ............................................................................................................................... 16 2.4.2 Webanwendung ..................................................................................................................................... 16 2.5 FORMEN WEBBASIERTER ANWENDUNGEN .................................................................................................. 17 2.5.1 Rich Internet Application ...................................................................................................................... 17 2.5.2 Webservice ............................................................................................................................................ 17 3 SAP NETWEAVER ALS INTEGRATIONSPLATTFORM ........................................................................ 18 3.1 PEOPLE INTEGRATION................................................................................................................................. 19 3.1.1 Multi-Channel Access ........................................................................................................................... 20 3.1.2 Portal .................................................................................................................................................... 20 3.1.3 Collaboration ........................................................................................................................................ 20 3.2 INFORMATION INTEGRATION ...................................................................................................................... 21 3.2.1 Business Intelligence ............................................................................................................................. 21 3.2.1.1 3.2.1.2 3.2.1.3 allgemeine Definition ....................................................................................................................................21 Business Information Warehouse (BW) .......................................................................................................22 Business Intelligence (BI) .............................................................................................................................27 3.2.2 Knowledge Management ....................................................................................................................... 35 3.2.3 Master Data Management ..................................................................................................................... 35 3.3 PROCESS INTEGRATION .............................................................................................................................. 35 3.3.1 Integration Broker ................................................................................................................................. 36 3.3.2 Business Process Management ............................................................................................................. 36 3.4 APPLICATION PLATFORM ............................................................................................................................ 37 3.4.1 JEE ........................................................................................................................................................ 38 3.4.1.1 3.4.1.2 3.4.1.3 3.4.1.4 4 JavaServer Pages (JSP)..................................................................................................................................40 Java Persistence API......................................................................................................................................41 WebDynpro ...................................................................................................................................................42 ABAP ............................................................................................................................................................46 AUSBLICK SAP NETWEAVER DEVELOPER STUDIO .......................................................................... 46 4.1 MÖGLICHKEITEN UND FUNKTIONEN ........................................................................................................... 47 5 GLOSSAR ......................................................................................................................................................... 48 6 LITERATURVERZEICHNIS ......................................................................................................................... 51 Seite 3 von 54 AIXTRON 6.1 6.2 6.3 BUCHLITERATUR ........................................................................................................................................ 51 INTERNETLITERATUR .................................................................................................................................. 52 SCREENLINKS ............................................................................................................................................. 53 Seite 4 von 54 AIXTRON Eidesstattliche Erklärung Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, alle Ausführungen, die anderen Schriften wörtlich oder sinngemäß entnommen wurden, kenntlich gemacht sind und die Arbeit in gleicher oder ähnlicher Fassung noch nicht Bestandteil einer Studien- oder Prüfungsleistung war. Name: _Sebastian Szlósarczyk_ Aachen, den 07.12.2010 ___________________________________ Unterschrift des Studenten Seite 5 von 54 AIXTRON 1 Einleitung 1.1 Motivation Projektdaten in einem Unternehmen kommen auf unterschiedliche Weisen zum Tragen. Sie geben unter anderem Auskunft, um welches Projektthema es geht, welche Mitarbeiter bei welchem Fortschritt sind oder was eigentlich entwickelt wird. Alle möglichen Daten werden von den jeweiligen Unternehmen archiviert und dokumentiert. Will man bestimmte Daten visuell darstellen, gibt es die Möglichkeit, dies auf einem so genannten Portal zu verwirklichen. Um ein erfolgreiches Unternehmensportal in Form eines Webportals zu erstellen, welches Projektdaten aus einem SAP ERP (SAP Enterprise Ressource Planning) – System entnimmt, braucht man zum einen Schreib-/Lesezugriff (je nach Funktionsweise des Portals) auf die von SAP verwalteten Datenbestände und zum anderen eine geeignete Software, die Schnittstellen zwischen diesen Datenquellen und Entwicklungsumgebungen für eine geeignete Applikation bereitstellt. Der SAP NetWeaver ermöglicht diese Methodik, was grundlegendes Thema dieser Arbeit ist. Es werden theoretische Grundlagen des Datenverarbeitungsprozesses, dem Data Warehousing unter Einsatz von Business Information Warehouse in SAP NetWeaver, und dem Anwendungsprozess in Form von dem Java Application Server erläutert. Das Ziel ist, die grundlegenden Anforderungen an ein Unternehmensportal zu beschreiben, wie auch eine Lösung von SAP mit der Software NetWeaver vorzustellen. 1.2 Aufbau dieser Arbeit / Überblick Diese Arbeit kann man im folgenden in zwei Themenbereiche gliedern: Der erste Teil befasst sich mit den allgemeinen Grundlagen über Portale, wie der Definition, und konkreten Anforderungen, die aus Unternehmenssicht an ein aufzubauendes Portal gestellt werden. Kurz werden auch verschiedene Element und Formen von Portalen vorgestellt. Im zweiten Teil wird aufbauend auf der Beschreibung und den Anforderungen des Portals mit dem SAP NetWeaver eine Technik vorgestellt, die eine Softwarelösung bereitstellt, mit der es möglich ist, webbasierte Unternehmensportale zu kreieren. Konkret wird hier besonders auf die Architektur der Datenbeschaffung aus dem SAP BW (s unten), wie auf die Bereitstellung dieser Daten für die spätere Anwendungsentwicklung, eingegangen. Kurz werden Screenshots der Seite 6 von 54 AIXTRON verschiedenen Möglichkeiten des Business Explorers gezeigt, auf welche Weise man sich die Daten anzeigen lassen kann. Im darauf folgenden, letzten Kapitel gibt es noch einen Ausblick auf das Tool SAP NetWeaver Developer Studio mit dem dann Anwendungen für das Portal entwickelt werden können, was in dem vorherigen Kapitel im Teil WebDynpro theoretisch erklärt wird. Wichtig ist, dass in dieser Arbeit Hauptaugenmerk auf die Java – Entwicklung mit SAP NetWeaver gelegt wird, somit der ABAP – Stack ausgenommen wird. Zur Wortwahl ist zu erwähnen, dass für den „Benutzer“ stellvertretend auch das Synonym „User“ benutzt wird. Referenzen werden als Hyperlink (für das elektronische Dokument zum besseren Navigieren) und Fußnote (vorzugsweise Druckversion) angegeben. Abbildungen werden kapitelübergreifend fortlaufend nummeriert. 2 Unternehmens – und Webportale In diesem Kapitel werden die Grundlagen eines Portals allgemein definiert, bevor dann die Anforderungen eines webbasierten Unternehmensportals aufgelistet werden. Zusätzlich wird eine theoretische Architektur beschrieben, die diese Anforderungen umsetzt. 2.1 Definition Mit webbasierten Anwendungen oder auch Webanwendungen sind diejenigen Arten von Anwendungen kategorisiert, bei denen die Interaktion zwischen User und Computer über einen Webbrowser in einer Benutzeroberfläche geregelt wird. Ein Portal (lat. porta – Tor, Pforte) wird in der Informatik als ein Zugang zu einem bestimmten System bezeichnet, welches bestimmte Dienste, Applikationen oder Prozesse integriert und Nutzern somit zur Verfügung stellt. Dieses Softwaresystem bietet Funktionen z.B. in den Bereichen Datenaustausch, Informationen, Suche, Personalisierung und Sicherheit. Aus diesen beiden Definitionen geht heraus, dass ein Webportal ein Portal ist, das eine Webanwendung integriert und einem allgemeinen Nutzerkreis über einen Webbrowser Seite 7 von 54 AIXTRON anbietet. Meistens ist es das Ziel eines Webportals, bestimmte Informationen für den jeweiligen Interessentenkreis zu strukturieren und systematisch zur Verfügung zu stellen. 2.2 Unternehmensportale Die Einsatzmöglichkeit eines Webportals oder eines Portals im allgemeinen kann man nach dem Benutzerkreis differenzieren. Es fallen demnach die Kategorien offene, die den Zugang für alle User unterstützen, und geschlossene Portale, welche sich auf einen gewissen Nutzerkreis beschränken. Umschließt dieser Nutzerkreis ein Unternehmen, wo spezielle Informationen des jeweiligen Unternehmens selbst, wie beispielsweise die von Mitarbeitern, Kunden oder Lieferanten verfügbar sind, so spricht man von einem Unternehmensportal. Vorweggenommen sei, dass ein SAP NetWeaver Portal ein solches Portal ist. 2.2.1 Eigenschaften Die Eigenschaften eines Unternehmensportals basieren auf der Funktionalität für den User, die das Portal unterstützen soll. Man unterscheidet hierbei Publishing Portale, die aus einer bestimmten Datenquelle für den jeweiligen Benutzerkreis relevante Informationen veröffentlichen Collaborative Portale, die die Zusammenarbeit in einem Unternehmen über weite Strecken und auch zeitliche Unterschiede ermöglichen (angemerkt sei hier schon das SAP im Produkt NetWeaver in der People Integration eine solche Komponente beinhaltet) Operational Portale, welche mehr für die Integration von unternehmensinternen Komponenten, wie beispielsweise eine Datenbank, eine Rolle spielen Decision Portale, die insgesamt ein Portal bieten, welches für die Verwaltung und Bearbeitung von Informationsbeständen, etc. bereitgestellt wird Seite 8 von 54 AIXTRON 2.2.2 Anforderungen an ein Unternehmensportal In einem Unternehmen gibt es verschiedene Personengruppen, abhängig von ihrer Zuständigkeit. Deswegen ist es nötig, Prozesse und Zusammenarbeit heterogener Gruppen zu unterstützen. Mit Prozessen ist hier ein grundlegender Baustein eines Unternehmens gekennzeichnet, der die Arbeitsprozesse einzelner Gruppen beschreibt, wie z.B. Verkauf und Vertrieb oder das Marketing. Der Datenaustausch auf verschiedenartigen Anwendungen, die möglicherweise eingesetzt werden, soll möglichst plattformunabhängig sein. Ein Beispiel hierfür ist die Transaktion mit einem Lieferanten: Der Kunde hat ein Produkt bestellt, dessen Lieferstatus vom Lieferanten mit Software „L“ in einer Datenbank gepflegt wird. Da der Kunde selbst diesen Status ständig einsehen möchte, aber Software „K“ benutzt, die zwar die Datenbank lesen kann, kann es aber zu Kompatibilätsproblemen kommen. Eine Lösung hier ist eine Schnittstelle oder Plattform, wo sowohl der Lieferstatus des Produktes aktualisiert, wie auch angesehen werden kann. Zusätzlich soll es allgemein möglich sein, über heterogene, oder standardisierte Anwendungen zugreifen zu können. Schnell erkennt man hier, dass eine Art webbasierte Anwendung nützlich ist, da über einen Webbrowser beide Seiten (Kunde und Lieferant) ihre nötigen Aufgaben erfüllen können. Weiter fällt auf, dass die Unterstützung plattformunabhängig sein muss, um diese Webbrowserunterstützung zu realisieren. Inhaltlich muss gewährleistet sein, dass dieser Lieferprozess in die Anwendung integriert werden muss. Was in dem Beispiel auch charakterisiert wird, ist, dass es zwei verschiedene Personengruppen gibt – Lieferant und Kunde. Es muss eine Möglichkeit geben, sich bei Benutzung der Anwendung zu authentifizieren, und anhand dessen die zuständigen Informationen einzusehen und gleichfalls sollen dabei direkt alle nötigen Komponenten der Anwendungen erreichbar sein, ohne dass man sich speziell für jede einzelne Komponente innerhalb des Portales anmelden muss. 2.3 Konkretisierung der Umsetzungsziele Das oben beschriebene Beispiel zeigt, welche allgemeinen Anforderungen sich an ein (Unternehmens-)portal stellen. Diese Anforderungen müssen konkretisiert werden, um folglich ein Konzept zu entwickeln. Seite 9 von 54 AIXTRON 2.3.1 Prozess – und Informationsintegration (Integration Anwendung und Information) Wie im Beispiel bereits vorgestellt bezeichnet man als Unternehmensprozesse Vorgänge, wie Vertrieb oder Marketing. Zu jeder Zeit entstehen Datenansammlungen und Informationen dieser Vorgänge. Man kann diese Vorgänge koordinieren, verwalten, oder ihnen auch nur einfach Informationen entnehmen. All diese Aufgaben mit dem damit verbundenen Vorgang werden zu einem Prozess zusammengefasst. In einem Unternehmensportal ist es wichtig solche Prozesse abzubilden und zu integrieren: Ein kompletter Geschäftsprozess muss explizit mit all seinen Aufgaben definiert werden, und diese Aufgaben, die sich bieten müssen in dem Portal zu sehen sein. Grob gesagt muss ein Prozess „veranschaulicht werden“. Da der User diese Prozesse aber nicht nur „einsehen“, sondern auch je nach Rolle (siehe Personalisierung) damit arbeiten soll, ist es nötig die jeweiligen Prozesse mit in das Portal zu integrieren. Ziel ist es , dass man auch über diese Systemgrenze Definition und Realisierung des Prozesses in der realen Welt auf die Abbildung im Portal, welche das Portal in der virtuellen Welt zugrunde legt, hinweg operieren kann. Infolge kann der User in Form von Anwendungen oder Methoden in dem Portal auf diese Prozesse zugreifen. Alle Daten, die er benötigt sollen ihm zur Verfügung gestellt werden. 2.3.2 Personalisierung Eine Unternehmensanwendung wird meist personenspezifisch genutzt. Wie im Beispiel1 erklärt, wird die Anwendung auf dem Portal dem jeweiligen User nach seiner Art der Anmeldung am Portal zugänglich gemacht. Diese Art kann einmal profilbasiert sein, was bedeutet dass der User seine eigenen persönlichen Einstellungen anhand seines Profils (spezifische, nötige Funktionen im Portal, Arbeitsbereich im Unternehmen), d.h. anhand seiner Personifikation, besitzt. Eine andere Form ist die rollenbasierte Personalisierung, wo der User einer Gruppe anhand seiner Eigenschaften, also einer Rolle, zugeordnet wird und folglich mit den Einstellungen dieser Rolle die Anwendung ausführen kann. Rollen können demnach z.B. nach Berufen, oder Positionen von Personen in einem Unternehmen vergeben werden. Ein IT Fachmann braucht z.B. Zugriff auf ein gesamtes Softwarepool, während ein Handwerker 1 2.2.2 Anforderungen an ein Unternehmensportal Seite 10 von 54 AIXTRON beispielsweise nur seine Stunden am PC buchen muss. Folglich braucht die Rolle IT Fachmann Zugriff auf ein Softwarepool, während in der Rolle Handwerker diese Rechte nicht nötig sind. Diese Rolle braucht nur den Zugriff auf die Software, mit der die Stunden abgezeichnet werden. Ein Beispiel profilbasierter Personalisierung sind so genannte „Soziale Netzwerke“ wie facebook oder studivz, wo jeder User selbst seine personenspezifischen Einstellungen, in diesem Fall persönliche Daten wie z.B. Kontaktdaten, Interessen oder persönliche Fotos, bearbeiten und anzeigen lassen kann. 2.3.3 Single-Sign-On Die Anmeldung im System wird so sichergestellt, wonach dem User aufgrund seiner Personalisierung/Authentifizierung die darauf basierenden Funktionen der Anwendung zur Verfügung gestellt werden. Um die Personalisierungen aller User zu verwalten wird eine zentrale Benutzerverwaltung eingeführt, über die die Zugangsdaten der User gespeichert sind. Es wird also eine zentrale Anmeldung im Portal eingeführt, wonach nach erfolgreicher Authentifizierung der User alles bereitgestellt bekommt, was er benötigt. 2.3.4 Portalkonzept In Abbildung 1 ist das allgemeine Konzept für Portalarchitekturen zu sehen. Auf die einzelnen Schichten wird im folgenden eingegangen. Seite 11 von 54 AIXTRON Abbildung 1: Referenzarchitektur 2.3.4.1 Präsentationsschicht Die oben angesiedelte Präsentationsschicht ist für den Enduser selbst die wichtigste. Wie im OSI – Referenzmodell werden dem User Endgeräte bzw. Endprogramme geliefert, mit denen er seine gewünschten Operationen ausführen kann. Ein wichtiger Aspekt ist hier die Darstellung der jeweiligen Anwendung, um diese Operation zu ermöglichen. Über Endgeräte wie z.B. einen Webbrowser wird auf eine Benutzeroberfläche zugegriffen, die die gewünschte Portalapplikation visualisiert. Geht man spezifisch auf diese so genannte Portalanwendungsvisualisierung ein, so spricht man bei der Abbildung des jeweiligen Prozesses in Form von einer dafür zuständigen Anwendung von Portlets. Diese sind nichts weiter, als virtuelle Fenster mit Inhalt der Applikation. Sie verarbeiten die Benutzerinteraktionen und liefern den Usern dynamisch generierte Inhalte. Seite 12 von 54 AIXTRON Für einen allgemeinen Standard bei Portlets gibt es seit 2003 Java Specification Request 168 Portlet Specification (JSR 168), welcher von Sun und IBM eingeführt wurde. Da die Portlets aber selbst eine Schnittstelle zu den Anwendungsprozessen sind und auf dem Endsystem nur angezeigt werden, sind sie in der Anwendungsschicht untergebracht. 2.3.4.2 Anwendungsschicht Die Anwendungsschicht sorgt zum einen für die Bereitstellung der Applikation(en), die auf dem Portal dargestellt werden. Grundlage hierfür ist ein Applikations – oder Anwendungsserver, welcher diese Aufgabe übernimmt und allgemein für die komplette Portalsoftware zuständig ist. Weiter bietet er Dienste an. Zu diesen gehören Transaktionsdienste (z.B. für verteilte Datenbanktransaktionen, oder allgemeine Informationsbeschaffung), die Enterprise Application Integration (EAI), welche die Unternehmensprozesse integriert, oder bestimmte WebserverFunktionalitäten, die Seiten im http oder WAP-Format bereitstellen. Hinzuzufügen ist, dass ein Application Server für ein Portal spezielle Portalbasisdienste erfüllen muss, die aus den oberen2 Anforderungen hervorgehen. Zu diesen werden folgende gezählt: Informationsverwaltung Benutzerverwaltung Rechteverwaltung Darstellungsdienste Prozesssteuerung Personalisierung Single-Sign-On Zum anderen ist in ihr die Anwendungs- oder Geschäftslogik angesiedelt, die zwischen den vielen Informationen oder Daten des Unternehmens eine strukturierte Logik einführt. Java selbst bietet mit der Schnittstelle Java Persistence API eine API, mit der es möglich ist, aus rohen Informationsbeständen, Objekte zu gewinnen und diese persistent zu halten. 2 2.2.2 Anforderungen an ein Unternehmensportal Seite 13 von 54 AIXTRON 2.3.4.3 Backendschicht Um das Konzept zu vervollständigen, fehlt noch eine Schicht, nämlich diejenige, wo die Informationen oder Datenbestände des Unternehmens entnommen werden, mit denen im Portal operiert wird. Laut Definition ist die Backendschicht (Unterschicht) diejenige Softwareschicht, welche systemnah liegt. Der Endbenutzer selbst operiert in dieser Schicht nicht. Ihm soll in dieser Schicht softwaremäßig alles bereitgestellt werden, damit er Funktionen benutzen kann, um die gewünschte Anwendung auszuführen. Die Benutzerinteraktion ist dabei separat in der Frontendschicht angesiedelt. Ziel ist also die klare Trennung von Benutzer- und systemnahen Operationen. Dabei sollen Befehle, über diese Interaktion in der Frontendschicht eingegeben werden, bei Bedarf an die Backendschicht zur Verarbeitung übergeben werden. Nach Verarbeitung der Befehle, werden die „Ergebnisse“ bereitgestellt, und dem User in der Frontendschicht passend angezeigt. Bezogen auf das Portal, werden in der Backend-Schicht alle möglichen Datenquellen definiert, die Informationen liefern sollen oder können, die dann im Portal zur Verfügung gestellt werden. Ein User kann über das Benutzerinterface (Frontendschicht) auf diese Daten bei Bedarf zugreifen. Eine Schnittstelle ist die EAI. 2.3.5 Client – Server Seite 14 von 54 AIXTRON Abbildung 2: Client-Server 2.3.5.1 Definition Bei dem Client – Server – Modell handelt es sich um ein spezielles Modell in der Informatik, in dem konzipiert wird, wie Aufgaben, bzw. Dienstleistungen in einem Netzwerk verteilt werden können. Man unterscheidet in diesem Modell Server(rechner) und Client(rechner), bei dem der Server (Dienstleister) einen Dienst, Anwendung oder Aufgabe anbietet, welcher von Clients(Kunden) auf Wunsch angefordert werden kann. Da es sich hierbei um eine Kommunikationsform zwischen Server und Client handelt, ist dabei ein Netzwerk, in dem beide Seiten zusammengeschlossen sind, die Grundvoraussetzung. Anfragen des Clients werden über das Netzwerk an den Server übermittelt. Dieser gibt dann bei Bedarf eine Antwort auf diese Anfrage. Da die Anfrage an einen Dienst gebunden ist, kann der Server antworten, indem er dem Client den Dienst anbietet und freistellt, ihm den Dienst verweigert (falls keine entsprechende Berechtigung vorhanden ist) oder antwortet, dass er diesen Dienst nicht besitzt, falls es der Fall ist. 2.3.5.2 Client - Server bei Portalen Wie im vorherigen Kapitel vorweggenommen, werden Portaldienste von einem Applikationsserver angeboten. Die Clients sind die jeweiligen Usergruppen, welche ihrer Rolle nach gewisse Portaldienste angeboten bekommen. Um also ein Portal aufzubauen muss man einen Anwendungsserver aufbauen, der in vernetzten Clients seine prozessintegrierten Anwendungen bereitstellt. Man erkennt, dass hier mehrere unterschiedliche Aufgaben für ein Ziel arbeiten. Ein solches System wird realisiert, indem man Stufe für Stufe jeweils eine Aufgabe realisiert. Veranschaulicht man sich diese Stufen anhand einer Treppe, so ist ganz oben das Ziel. Um ans Ziel zu gelangen, muss man Stufe für Stufe „hochgehen“. Softwaretechnisch ist dies so umgesetzt, dass höhere Stufe auf der unteren aufsetzt und diese um ihre Aufgabe erweitert, bis man ganz oben ist, und das Ziel – das bereitgestellte Portal – verwirklicht. In diesem Fall spricht man von einer Schichtenarchitektur, wobei die einzelnen Stufen als tier oder Schichten bezeichnet werden. Seite 15 von 54 AIXTRON 2.4 webbasierte Portale/Anwendungen 2.4.1 Netzwerkumgebung Bevor man auf die webbasierte Darstellung kommt, ist es wichtig, zu klassifizieren, auf welche Erreichbarkeit man zielt. Das Portal eines Unternehmens soll in einer bestimmten Netzwerkumgebung angeboten werden. Es gibt drei grundlegende Netzwerkumsetzungen, in denen das Unternehmen sein Portal anbieten kann: Intranet – wird in einem Unternehmen nur im internen Netz eingesetzt. Es haben Personen Zugriff, die direkt zu diesem Netz vernetzt sind. Wie der Name der Komponente schon sagt, sind dies interne Mitarbeiter einer Organisation oder eines Unternehmens. Es wird meistens ein Server intern verwendet, auf dem das ganze Portal betrieben wird. Extranet – erweitert das Intranet um ausgewählte, bestimmte, externe Personen, die nicht Teil der jeweiligen Organisation sind. Auch hier wird ein Server verwendet. Internet – Portale, die im Internet angeboten werden, sind für jeden zugänglich, der einen Internetanschluss hat. Hiermit wird meistens der allgemeine öffentliche Zugang eines Portals verwirklicht. Die Verwaltung kann über mehrere Server an verschiedenen Standorten übernommen werden, von denen das Portal, oder jeweils nur Portalkomponenten betrieben werden. Mit Portalkomponenten können einzelne Anwendungen gemeint sein, wo jede von einem anderen Server aus betrieben werden kann. Konzeptuell gibt es aber auch hier einen so genannten Main Server, der das grundlegende Portal beinhaltet und bei Anforderung eines Clients an diverse Funktionen auf den jeweiligen anderen Server verweist. 2.4.2 Webanwendung Nachdem man die allgemeinen Anforderungen verwirklicht hat und eine Infrastruktur zur Kommunikation zwischen Portal und Usern gewählt hat, ist es möglich die Webanwendung zu implementieren und auf dem Server über einen Webbrowser zur Verfügung zu stellen. Starten kann der User die Applikation, indem er z.B. im Browser die URL des Servers angibt, auf dem die Applikation hinterlegt ist. Nach dem Client – Server – Modell antwortet der Server auf die Clientanfrage und ermöglicht ihm nach Authentifizierung den Zugriff auf die georderte Anwendung. Seite 16 von 54 AIXTRON 2.5 Formen webbasierter Anwendungen 2.5.1 Rich Internet Application Mit einer Rich Internet Application (RIA) wird eine Internetanwendung bezeichnet, die dem User über eine Benutzeroberfläche möglichst viele Anwendungsmöglichkeiten und Funktionalitäten auf der Seite anbietet. Es ist nicht zwingend erforderlich über den Browser zu arbeiten. Die Anwendung selbst kann lokal installiert werden. Charakteristisch ist aber dabei, dass für die Ausführung der Anwendung eine Verbindung zum Internet benötigt wird. Ziel ist es eine auch rechenintensive Anwendung bereitzustellen, die auf lokalem Rechner installiert werden kann, aber im Internet erst gestartet werden kann. Zur Bereitstellung hochwertiger Performance wird die Rechenleistung bei RIA zwischen Server und Client aufgeteilt. 2.5.2 Webservice Ein Webservice – auch Webdienst genannt – ist eine softwarebasierte Anwendung, die über einen Uniform Resource Identifier (URI) identifiziert wird. Der Nutzen von Webservices ist mehr für Softwaresysteme bei Benutzeranfragen. Will ein User beispielsweise eine bestimmte Anwendung ausführen, so tauscht die von ihm benutzte Software mit einem Server Informationen aus, um dem User die benötigte Funktionalität zu liefern, selbst wenn es sich um zwei heterogene Systeme handelt. Dieser Austausch von Informationen und Bereitstellung von Funktionalitäten des Servers wird über einen solchen Webservice realisiert. Als Standardformat für den Kommunikationsaustausch wird hier das XML-Format verwendet. Speziell handelt es sich bei einem Webservice um eine in einem Netzwerk über Standardprotokolle wie HTTP oder SMTP erreichbare Applikation. Ein Vorteil hier ist, dass die Schnittstellen zum Aufruf, oder allgemeinen Gebrauch unabhängig von der Implementierung sind, da für den Zugang das XML-Format verwendet wird. Ein Webservice ermöglicht also die Ausführung eines Dienstes oder Programmes zwei heterogener Systeme. Will zum Beispiel ein System (Server) einen Dienst einer Gruppe von Clients anbieten, so wird ein Webservice erstellt, indem dieser Dienst bereitgestellt wird und anschließend kann dieser vom Client abonniert oder benutzt werden. Seite 17 von 54 AIXTRON 3 SAP NetWeaver als Integrationsplattform In Abbildung 3 sind die Schichten (so genannte Stacks) von SAP NetWeaver zusammengefasst. Vom Aufbau her fassen die oberen drei Schichten die Integrationsschichten zusammen, welche auf die untere, die Anwendungsplattform, aufsetzen. Zu erwähnen ist, dass diese Schichtendarstellung nicht hierarchisch interpretiert werden darf, wie z.B. beim OSI/ISO Modell, wo die oberen Schichten die Dienste der jeweils unterliegenden Schicht nutzen. Hier bietet jede Schicht unabhängig von anderen eigene Dienste/Services an, kann aber bei Bedarf Dienste anderer nutzen. Über alle vier Bereiche gibt es das Life Cycle Management und das Composite Application Framework. Für alle Phasen des Software-Lebenszyklus bietet die SAP NetWeaver Technologieplattform ein Life Cycle Management an. Dies umfasst das Design, die Entwicklung, den Test, den fortlaufenden Betrieb der Applikation und dessen Administrations- bzw. Change-Management. Über das Composite Application Framework ist es SAP bzw. einer anderen Unternehmung möglich, Applikationen zu entwickeln, die aus Services verschiedener Bereiche bestehen können. Im Folgenden werden die einzelnen Komponenten der vier Bereiche vorgestellt. Mit Stack wird ein Synonym für eine Schicht verwendet. Seite 18 von 54 AIXTRON Abbildung 3: SAP NetWeaver Stack 3.1 People Integration Die so genannte Benutzerschnittstelle ermöglicht es auf vereinheitlichte Weise authentifizierten Personen ihrer Rolle entsprechend auf Informationen Zugriff zu erhalten. Es gibt zum einen, die Möglichkeit auf dieses Enterprise Portal über die lokale Adresse im Webbrowser zuzugreifen, oder falls eine passende Konfiguration vorhanden ist, über das SAPGUI. Ein qualitatives Feature ist hierbei das Single-Sign-On (SSO), das den anmeldefreien Zugriff auf BackendSysteme gewährt. Jeder Benutzer muss sich in jeder Teilanwendung oder auf jeder Teilseite immer authentifizieren. Für eine allgemeine Authentifikation sorgt das SSO, besonders um Zeit einzusparen, die Sicherheit aber zu gewährleisten. Ein zu entwickelndes Unternehmensportal ist Teil dieses Stacks, da in dieser Schicht das Szenario der Benutzerinteraktion abgebildet wird. Seite 19 von 54 AIXTRON 3.1.1 Multi-Channel Access Wie im Schaubild dargestellt, ist der Multi-Channel-Access ganz oben angesiedelt. Diese Veranschaulichung bedeutet, dass hiermit die Benutzerschnittstelle für einen Zugriff von außen über mobile Endgeräte, Web, Messaging oder (Mobil - ) Funk bereitgestellt wird. Zum Funk sind zu erwähnen, dass SAP im Bezug ist, neue Technologien wie UMTS und 3G bzw. 4G (komplett) zu integrieren. Ein webbasiertes Unternehmensportal wird über einen Webbrowser angesteuert. Es wird die Möglichkeit geboten, selbst über weite Strecken, „erreichbar“ zu sein. 3.1.2 Portal Wie bereits in den Portalgrundlagen erwähnt, werden Informationen rollenbasiert zur Verfügung gestellt. Aufgabe des Portals ist es, diesen Zugriff in Abhängigkeit der Rolle des Benutzers, zu vereinheitlichen. Der Grund ist, dass Systeme von verschiedenen Herstellern stammen können, somit unterschiedlich abgelegt werden. Das (Unternehmens-)Portal filtert diese Daten für den User, damit er nur seine relevanten Datenbestände erhält, ohne dass der User wissen muss, wo genau sie abgelegt sind. Dies wird realisiert, indem jeder Rolle die jeweiligen Funktionen und Informationen hinterlegt sind, auf die der jeweilige Benutzer zugreifen muss. Um diesen so bezeichneten Content (Anzeige der Informationen) darzustellen, gibt es die iView (integrated View), die eine in sich geschlossene Anwendung in dem (Unternehmens-)Portal repräsentiert. Zur Begriffsbezeichnung „Portal“ ist hinzuzufügen, dass es sich im Kontext mit firmeninternen Datenbeständen wie bereits in der Definition3 angegeben, um ein Unternehmensportal handelt. 3.1.3 Collaboration Wie der Name schon aussagt, ist mit Collaboration die Zusammenarbeit von Teams bzw. Communities (hier in virtuellen Räumen) gemeint. Spezifischer geht es um den Informationsaustausch. Der Multi – Channel – Access ist die Basis für die Collaboration. In so genannten Collaboration-Rooms können gemeinsame Dokumente ausgetauscht werden. 3 2.1 Portaldefinition Seite 20 von 54 AIXTRON Vergleichsweise kann man hier Internet-Foren erwähnen, wie auch Chats, wo Informationen in Form von Text oder Dokumenten auch in Echtzeit transferiert werden. Es soll also ermöglicht werden, dass in einem Unternehmensportal auch der direkte Arbeitszusammenschluss in Form von Kommunikation wie auch Datenaustausch gewährleistet ist. Ein kleines Beispiel hierfür sei einmal eine Absprache und Einigung auf den Kauf eines Produktes von Kunden und die direkte Datenbankaktualisierung des Geschäftsprozesses, sodass über dieses beispielhafte Portal jeder (Käufer und Verkäufer) den aktuellen Stand einsehen kann. Unabhängig von Zeit und Ort! 3.2 Information Integration Information Integration stellt auf konsistente, zugreifbare Art und Weise Ihrem Unternehmen sowohl strukturierte als auch unstrukturierte Informationen zur Verfügung: Benutzer erhalten ununterbrochen Zugriff auf konsistente Informationen unabhängig von deren Ablageort. Kurz zusammengefasst, übernimmt Information Integration die Rolle der allgemeinen Datenbeschaffung. Der Zugriff auf Informationsbestände und die Bereitstellung ist der Hauptaspekt in dieser Komponente. 3.2.1 Business Intelligence „SAP Business Intelligence stellt mit Hilfe von Knowledge Management die Verbindung zwischen ‚denen, die etwas wissen’ zu denen ,die etwas wissen müssen’ her.“ Diese etwas umgangssprachliche Beschreibung von Business Intelligence (BI) bedeutet, dass BI in einem Unternehmen die Aufgaben von Datenanbindung und – integration, Datenspeicherung und – verwaltung bis hin zur Datenauswertung übernimmt. Ein besonders hervorzuhebendes Konstrukt ist dabei das Business Warehouse, worauf speziell eingegangen wird. Das Knowledge Management dient hier dazu, eine auf Wissen basierte Methodik bereitzusetellen, um intelligente Analysen auszuführen. 3.2.1.1 allgemeine Definition Übersetzt man „Business Intelligence“, so entsteht der abstrakte Begriff „Geschäftsintelligenz“. Versucht man sich diesen Begriff abstrakt zu erklären, stößt man auf die Worte „Geschäft“ und Seite 21 von 54 AIXTRON „Intelligenz“. Intelligenz kann man sich z.B. aneignen, indem man Informationen zu einem Thema sammelt und anhand dem Wissen, was man aus diesen Informationen gewonnen hat, „intelligent“ Entscheidungen in Gebieten treffen, die themenverwandt sind. Bezieht man sich auf das Wort Business – Geschäft, so kommt der Aspekt eines Unternehmens in dieses Wortspiel. Zusammengesetzt bedeutet dies, dass die so genannte Geschäftsintelligenz in unternehmensbezogenen Themen für intelligente Entscheidungen steht. Diese Definition der Entscheidungen basiert auf einem vom Unternehmen verwalteten Informationsbestand. Dieser Pool von Informationen wird verwendet, um gezielt Analysen und Entscheidungen zu veranschaulichen, die für das Unternehmen intelligent, also von Vorteil sind. Welche Informationen dies sind, woher sie kommen und wie sie bereitgestellt werden, wird im folgenden verdeutlicht. 3.2.1.2 Business Information Warehouse (BW) In diesem Abschnitt wird das zu Anfang des Kapitels erwähnte Business Warehouse ausführlich beschrieben. 3.2.1.2.1 Definition von Data Warehouse (DW) Knapp kann man sagen, dass ein DW eine Ansammlung von Informationen aus vielen verschiedenen Unternehmensbereichen ist. All diese Informationen, die vorwiegend der Entscheidungsunterstützung dienen, werden aus unterschiedlichen homogenen und auch heterogenen Quellen entnommen und in einer strukturierten, konsistenten Datenbank zusammengefasst. Zu beachten ist, dass es sich um eine strukturierte Datenbank handelt, deren Daten auch streng normalisiert sind. Zu erwähnen ist, dass diese Strukturierung der Datenbank in Form von starker Normalisierung der Daten gewährleistet wird, was die Hauptaufgabe eines DW ist, nämlich relevante Informationen zu entnehmen, diese zu normalisieren, um sie dann in einer Datenbank ablegen zu können. Dieser Vorgang wird als DataWarehousing spezifiziert. Hinzu kommt, dass diese Daten nicht verändert werden können. Es besteht nur ein Lesezugriff. Dieser Aspekt garantiert unter anderem die Möglichkeit, spätere Analyseergebnisse zu wiederholen, da Daten, die man in Vergangenheit benutzt hat, auch später in derselben Form zugänglich sind. Seite 22 von 54 AIXTRON 3.2.1.2.2 Online Transaction Processing (OLTP) Ein DW zählt selbst zu den Online – Transaction – Processing – Systemen (kurz OLTP). Wie der Name aussagt, steht ein OLTP System für ein System, in welchem hauptsächlich Transaktionen im Vordergrund stehen. Aus Datenquellen werden nötige Daten extrahiert, die für die weitere Verwendung zum Tragen kommen. Dieses Extrahieren ist transaktionsorientiert, was bedeutet, dass in einer Transaktionsfolge bestimmt und definiert wird, welche Daten man in Anspruch nimmt. Die Art der Datenbeschaffung ist dynamisch und wird online vorgenommen. Wichtig ist hier, dass Transaktionen nacheinander in einem Stapelverarbeitungsprozess abgearbeitet werden. Folgende Regeln sind bei einer Transaktion wichtig: Atomizität Entweder erfolgreicher Abschluss einer Transaktion, oder Abbruch und der Zustand vor Anfang der Transaktion bleibt beibehalten Konsistenz Ein Datenbestand muss vor und nach einer Transaktion regelkonform sein Isolation Transaktionen laufen getrennt voneinander ab; das Ergebnis sieht man erst nach Beendigung der Transaktion Dauerhaftigkeit Garantie, dass ein Datenbestand nach einer Transaktion ohne Einwirkung von außen seine Gültigkeit nicht verliert Im folgenden Abschnitt ist der (Transaktions-)Datenprozess erläutert. Vorgemerkt sei, dass bei einem DW die Transaktionen den Prozess der Überführung der Daten heterogener Sourcen in ein homogenes Schema (Datenbank) abbilden. Seite 23 von 54 AIXTRON 3.2.1.2.3 ETL – Prozess zur Datenbeschaffung Der bereits vorgemerkte Prozess der Datenbeschaffung aus externen/internen Quellen in ein DW wird in drei Phasen geteilt und demnach als ETL (Extraction – Transformation – Loading ) bezeichnet. Zuerst werden die Metadaten der zur Verfügung stehenden Quellen extrahiert. Da es sich hierbei meist um heterogene Datenbestände handelt, werden danach die vielen Daten in ein einheitliches Schema transformiert, welches an Datenziele angepasst ist. Mit Datenzielen werden physische Objekte definiert, womit eine Zielsetzung bei der Modellierung des Datenmodells, wie auch beim Laden der Daten gegeben ist. Nach Vereinheitlichung der Daten werden diese in das DW geladen und dort in einer speziell dafür eingerichteten Datenbank abgelegt. Abbildung 4 zeigt diesen Prozess. Speziell wird hier veranschaulicht, dass man vor und nach jeder Phase eine Ansammlung von Informationen hat: Vor der Extraktion die (heterogenen) Datenquellen, während der Transformation wird ein Arbeitsbereich bezogen, der in einer Art Repositorium zwischengespeichert ist und nach jeder Extraktion bzw. Transformation aktualisiert wird. Die Zieldatenbank wird nach dem Laden eines Zustands eines Arbeitsbereiches erstellt. Seite 24 von 54 AIXTRON Abbildung 4: ETL-Prozess 3.2.1.2.4 SAP Business Information Warehouse (BW) Wie in Abbildung 5 der grundlegende Aufbau von BI dargestellt ist, erkennt man speziell für die Softwarekomponente „BW“, dass auch hier ein DW und ein ETL – Prozess integriert sind. Es gibt aber einen wesentlichen Unterschiede zwischen einem reinen Data Warehouse und dem SAP Business Information Warehouse: Während ein DW in einer streng normalisierten Struktur alle Daten ablegt, verwendet das BW solche Datenbestände, um Transaktionen auszuführen und legt diese neuen Daten seinerseits nach erfolgreichen Verbundoperationen, also nicht normalisiert ab. Dies erscheint zunächst ein wenig verwunderlich, ist aber wie folgt zu erklären: Die Quelle für das BW ist ein internes DW, wo bereits Metadaten nach dem ETL –Prozess aus externen/internen Unternehmensquellen bereitgestellt wurden. Dieses interne DW hatte als Datenziel das BW. Das BW aber hat als Datenziel die in Abbildung 5 illustrierten Query & Reporting Tools, so genannte InfoCubes (werden im folgenden Kapitel4 erklärt). InfoCubes beinhalten Daten ausschließlich zur Analyse. Um eine performancegetreue und flexible Analyse durchführen zu können, ist es nötig, dass Daten in einer Form zur Verfügung Seite 25 von 54 AIXTRON stehen, ohne dass man vorher die Daten weder in Struktur, noch an Datenbeständen selbst verändern muss. Deswegen bereitet das BW mithilfe von Verbundoperationen, angewandt auf die normalisierten Daten aus dem internen DW, solche Datensätze zur späteren Analyse vor. Abbildung 5: grundlegender Aufbau SAP NetWeaver Business Intelligence Zusammengefasst sind die Hauptaufgaben des BW: Datenbeschaffung Datenhaltung Datenmodellierung Datenbereitstellung Datenverwaltung Für die allgemeine Extraktion von Quelldaten wird das Tool Administrator Workbench eingesetzt. Es lädt angeforderte Daten in das interne DW. 4 3.2.1.3.2 InfoCubes Seite 26 von 54 AIXTRON 3.2.1.3 Business Intelligence (BI) 3.2.1.3.1 BI als OLAP Business Intelligence gehört zu den Online Analytical Processing – Systemen (kurz OLAP). Es bedeutet, dass in dieser Komponente Auswertung, Analyse und Darstellung von Dokumenten und Daten realisiert werden. Allgemein kann der User anhand eines OLAP – Systems hypothetische Anfragen stellen und erhält als Bestätigung oder Negation ein Analyseergebnis. Dies soll für den Anwender entsprechend schnell geschehen und es soll darüber hinaus möglich sein, mehreren Benutzern diese Funktionalität bereitzustellen. Äquivalent zu einem OLTP – System, ist auch hier die Verarbeitung online. Die zu verarbeiteten Daten werden aus einer separaten Datenbank (aus einem DW) entnommen. Bewusst werden hier zwei Komponenten getrennt, damit Transaktionen auf die reinen Datenbestände in der Datenbank ausgeführt werden können, ohne dass dabei Analysedaten direkten Einfluss darauf haben. Performancetechnisch macht es auch Sinn, Daten, die später für eine Analyse gebraucht werden, soweit wie möglich darauf vorzubereiten. Bei der Analyse kann man folglich auf fertige strukturierte Daten zugreifen, ohne dabei noch etwas an den Datensätzen verändern zu müssen. Technisch wird dies in SAP gelöst, indem das BW aus dem internen DW eine Datenbank erstellt, die auf Reportingzwecke vorbereitet wird: Es wird eine Zieldatenbank erstellt, die viele zeitaufwändige, somit teure, Verbundoperationen beinhaltet und aufgrund dessen wie bereits in der Definition5 erwähnt, nicht normalisiert ist. Diese Daten müssen jetzt nur noch geladen werden, um erfolgreich zu analysieren. Der wesentliche Unterschied zwischen beiden Systemen ist die jeweilige Aufgabe: OLAP beschränkt sich auf die Analyse von Daten und OLTP auf den atomaren Transaktionsprozess von Daten. OLTP greift ständig auf aktualisierte direkt zu, während OLAP für eine Analyse auch historische Daten zur Verarbeitung bezieht. 3.2.1.3.2 InfoCubes Ganz abstrakt beschrieben ist ein InfoCube eine Art Informationseinheit oder Datenbestand. Geht man bei der Definition mehr ins Detail, so spezifiziert man einen InfoCube in SAP als Menge von relationalen Tabellen. Diese relationalen Tabellen, die im BW bereitgestellt werden, besitzen, wie in einem Datenmodell üblich, verschiedene Merkmale, Kennzahlen, Einheiten, Seite 27 von 54 AIXTRON deren Ausprägung oder Wert in einem InfoCube als Auswertungsobjekte dienen, so genannte InfoObjects. Im Begriff selbst wird die Semantik des Cubes – Würfels – verwendet: Es handelt sich hierbei um einen mehrdimensionalen Würfel. Die Dimensionierung (Beispiel in Abbildung 6) beruht auf den unterschiedlichen Dimensionen der zusammengesetzten InfoObjects. Ein InfoObject wird nach seinem Merkmal, seiner Kennzahl oder Einheit dimensioniert. Beispielsweise hat ein InfoCube, der aus Verkaufszahlen (Kunde) verschiedener Säfte (Produkt) in einem bestimmten Jahr (Zeit) besteht, die Dimension 3. Betrachtet man in diesem Szenario den Erlös, der in einem jeweiligen Jahr eines bestimmten Kunden beim Kauf eines gewissen Produktes, so hat man zusätzlich eine Art Funktionswert für diesen Zusammenhang. Dieser bildet eine neue Dimension, die vierte. Sachlogische Zusammenhänge wie z.B. Kunde und Konsument werden zu einer Dimension zusammengefasst. Abbildung 6: InfoCube Auch hier spielen performancetechnische Hintergründe eine Rolle, da bei einer derartigen Dimensionierung oft Unabhängigkeit zwischen den jeweiligen Dimensionen erreicht wird und die Datenhaltung in solchen InfoObjects bzw. daraus zusammengesetzten InfoCubes komprimiert klein wird. Diese Struktur des InfoCubes ist für das Reporting optimiert. InfoCubes werden deswegen verwendet, um die Analyse und das Reporting, worauf in BI abgezielt wird, zu ermöglichen. Sie werden als Datenziel benutzt. Anhand von diesen Würfeln wird eine Art Schnittstelle zwischen den Daten und Analysewerkzeugen geschaffen, da sie die Analysedaten repräsentieren. 5 3.2.1.2.1 Definition von Data Warehouse Seite 28 von 54 AIXTRON 3.2.1.3.3 Analyse Um dem Endanwender seine Analyse zu ermöglichen, bedarf es einem Werkzeug, das aus den InfoCubes die relevanten Daten filtert oder liest, die analysiert werden. Aufgrund der Definition der InfoCubes als relationale Tabellen, ist es aus technischer Sicht nötig, mithilfe von Query – Abfragen je nach Anwenderanfrage die zugehörige Query-View zu liefern. Diese Funktionalität wird in Form vom Navigationsfunktionen OLAP-Prozessor (Operationen Dice, (Abbildung 7) Drill-down/up, implementiert. Swap), welche Mithilfe die von nötigen Datenblöcke aus einem InfoCube entnehmen, Filterfunktionen, welche derartige Selektionen auf Wertebereiche einschränken und Aggregatations – und Darstellungsmethoden, welche die gewünschten Daten strukturieren und das Resultat zur Visualisierung bereitstellen, wird dem Endanwender seine gewünschte Analyse in einer Sicht geliefert. Betrachtet man das grundlegende Konzept, welches hier eingesetzt wird, handelt es sich um einen Applikationsserver, welcher in Form von Diensten diese Abfragen ermöglicht. Zu einer solchen Analyse existieren im SAP BW Modelle, die nicht nur diese Analysenform, sondern auch das Reporting übernehmen. Diese Komponente wird Business Content genannt. Für eine Laufzeitoptimierung können im OLAP-Cache je nach vorgenommenen Einstellungen queryabhängige Bestände zwischengelagert werden. Seite 29 von 54 AIXTRON Abbildung 7: OLAP-Prozessor 3.2.1.3.4 Präsentation/Visualisierung der Daten Die für den Endbenutzer verfügbare Komponente in SAP BW, um Abfragen zu erstellen und anzuzeigen ist der Business Explorer (BEx). Angemerkt sei hier, dass es auch möglich ist, über ein Format-Konvertierungstool (MDX-Prozessor), auf das daraus jeweils konvertierte Format über Drittanbieter diese Funktionalität zu benutzen (Abbildungen 7.1 und 7.2). In beiden Abbildungen sind Daten-Objekte (u.a. InfoCubes) mit dem OLAP-Prozessor verbunden, der die nötigen Datenteile extrahiert. Interagiert man als Benutzer über den BEx, so ist keine weitere Konvertierung nötig, andernfalls sind die in den Abbildungen aufgezeigten Schnittstellen zur Bereitstellung dieser Extraktion nötig. Seite 30 von 54 AIXTRON Abbildung 7.1: Schnittstellenbeschreibung für den Vorgang von InfoCubes zum BEx Abbildung 7.2: Schnittstellenbeschreibung für den Vorgang von InfoCubes zum BEx Da der Business Explorer (BEx) aus mehreren Werkzeugen besteht, spricht man oft von einer Suite. Im folgenden werden kurz diese einzelnen Tools mit ihren jeweiligen Aufgaben beschrieben und ein Screenshot dessen angezeigt: Seite 31 von 54 AIXTRON Übersicht über die Tools: BEx Query Designer BEx Analyzer BEx Web Application BEx Web Application Designer BEx Broadcaster BEx Query Designer dient zum Erstellen der gewünschten Abfragen. Abbildung 8.1: BEx Query Designer Seite 32 von 54 AIXTRON BEx Analyzer zeigt die bereitgestellten Daten mithilfe eines MS Excel AddIns innerhalb einer Tabellenkalkulation (meist in einem Excel-Sheet) an. Abbildung 8.2: BEx Analyzer BEx Web Application bietet eine webbasierte Darstellung vorgnererierter HTML-Seiten. Zur Anzeige wird ein WebBrowser benötigt. Abbildung 8.3: BEx Web Application Seite 33 von 54 AIXTRON BEx Web Application Designer gibt die Möglichkeit eine eigene WebApplication zu erstellen, die man später über eine spezifische URL aufrufen kann. Abbildung 8.4: BEx Web Application Designer BEx Broadcaster gibt die Möglichkeit, schon vorberechnete Informationen, via E-mail versenden zu können. Abbildung 8.5: BEx Broadcaster Seite 34 von 54 AIXTRON Umgesetzt ist dies so, dass BI auf das Business Warehouse, das SAP – Datenlager, wo operationale Datenbestände erfasst werden, zugreift. Angemerkt sei hier, dass das BW ein Datenbanksystem ist, welches rein für die Datenerfassung in Form von Transaktionen zuständig ist, während das BI es ermöglicht, diese Daten hypothesengestützten Analysemethoden zuzuordnen, je nachdem was für den User von Bedeutung ist. Um das Quellsystem BW aus performancetechnischen Gründen zu entlasten, extrahiert BI diese Daten, infolge der reinen Analyse. Ziel ist es, daraus Informationen zu erhalten, die als Entscheidungsgrundlage für Strategien und Handlungsmaßnahmen im Sinne der Unternehmensziele dienen können. 3.2.2 Knowledge Management Aufbauend auf der Collaboration Komponente bietet das Knowledge Management die Klassifikation, Verteilung und Ansammlung von unstrukturierten Informationen. Hierbei ist zu berücksichtigen, dass dieser Dienst nicht der Dokumentenverwaltung, sondern z.B. der Volltextindizierung und –suche (Enterprise Search), Objektsklassifikation, wie auch dem Feedback (z.B. in Form von „angehefteten“ Notizen) dient. 3.2.3 Master Data Management Die Stabilisierung der Benutzerstammdaten erfolgt mit dieser Komponente. Die dadurch entstehende konsistente Datenbasis gewährt, dass Geschäftsprozesse von allen Teilen des Unternehmensnetzwerkes benutzt werden können. Homogene Stammdatensätze werden über verschiedene vernetzte Systeme gesucht und identifiziert, bevor diese dann Geschäftsprozessen synonymartig zur Verfügung stehen. 3.3 Process Integration Seite 35 von 54 AIXTRON Die Prozessintegration übernimmt den allgemeinen Datenaustausch und die Kommunikation zwischen Prozessen und Diensten (Service Bus). Dabei sind folgende grundlegende Anforderungen über die Systemgrenze hinweg, die erfüllt werden müssen, zu beachten: Messaging zuverlässige Übertragung von Nachrichten vom Sender zum Empfänger (->QoS) Routing Wegbereitung und Ziel des Empfängers Mapping ermöglicht eine vereinheitlichte Datenabbildung in einem Format das bei Sender und Empfänger bekannt ist Business Process Management sorgt für die reibungslose Kommunikation zwischen den beteiligten Systemen In der Prozessintegration ist die SAP Exchange Infrastructure die wesentliche, die aus folgenden zwei Komponenten besteht. 3.3.1 Integration Broker Der Integration Broker oder auch Integration Engine genannt, übernimmt das Messaging, Routing und Mapping. Über einen Integration Server ist es möglich, sich dieser Funktionen zu bedienen. Das Format der Kommunikationsübertragung ist XML bzw SOAP – basiert. 3.3.2 Business Process Management Damit die Funktionen des Integration Broker auch funktionieren, ist eine Process Engine nötig, wo der Kommunikationsprozess reibungslos gewährleistet wird. In dieser PE wird das BPM ausgeführt, welches diese Anforderung übernimmt. Seite 36 von 54 AIXTRON Das Business Process Management umfasst folgende Bereiche: Steuerung von Geschäftsprozessen innerhalb von Anwendungssystemen über den SAP Business Workflow Steuerung von Integrationsprozessen (ccBPM) über die Exchange Infrastructure Steuerung von Ad-hoc Workflows über die Universal Worklist (UWL) des Enterprise Portal Zu unterscheiden sind dabei Workflows mit Ad-hoc-Workflows: Bei einem Workflow ist der Prozessablauf von Anfang an festgelegt. Ein Business Workflow ist ein solcher Prozess, bei dem Prozesse als Geschäftsprozesse definiert werden. Es ist bei diesem Workflow somit klar, welche unternehmensspezifische Abfolge es zu steuern gilt, wie z.B. Lieferung, Abnahme und Test oder Lieferung, Test und Abnahme. Bei einem Ad-hoc-Workflow dagegen ist es dem Anwender möglich, selbst zur Laufzeit die Abfolge der Prozesse vorzugeben. 3.4 Application Platform Die Anwendungsplattform, die SAP NetWeaver zugrunde liegt, bietet eine komplette Entwicklungsinfrastruktur für Webportale, - anwendungen und allgemeiner Business Application Software. Realisiert wird dies in Form des SAP Web Application Servers. Ein Ziel eines Unternehmensportals ist es, eine auf dem Application Server liegende Anwendung bereitzustellen. Die Application Platform ist diese entsprechende Serverbasis auf der alle Anwendungen entsprechend laufen. Zahlreiche APIs sorgen für ein grundlegendes Environment. Unterstützt wird diese Plattform parallel in zwei Programmiersprachen – JEE (im Bild noch die alte Benutzung von J2EE) und ABAP(s.u.), die jeweils Zugriff auf eine SQL-Datenbank haben, um den Informationsbestand anzubinden. Da bereits im Einleitungskapitel vorgemerkt wurde, dass diese Arbeit mit der Zielsetzung JAVA geschrieben wurde, wird genau auf diesen Stack eingegangen. Seite 37 von 54 AIXTRON 3.4.1 JEE Die Unterstützung der von Sun Microsystems aufgestellten Norm der Java Platform, Enterprise Edition, kurz JEE, wurde eingeführt um SAP NetWeaver mit einer standardisierten Programmiersprache zu erweitern. Es wurde eine Plattform angefordert, die transaktionsbasierte Ausführungen, wie die bei der Arbeit mit InfoCubes nötig sind, spezifiziert, die in Applikationen, insbesondere Web-Anwendungen, verwendet werden können. Die Möglichkeit, in einem Portal mehrere verschiedene und verteilte Anwendungen entwickeln zu können, wurde gesucht. Der Bedarf von Schnittstellen zwischen „rohen“ Informationen und deren Ablage als persistente Objekte, wie auch einzelnen Anwendungskomponenten und dem grundlegenden Portal selbst, war ein wichtiges Voraussetzungsmerkmal. Aufgrund dieser Anforderungen wurde JEE ausgewählt, da es folgende fundamentale Infrastruktur hat, die auf wikipedia6 aufgelistet ist: Sicherheit (Security), Transaktionsmanagement, Namens- und Verzeichnisdienste, Kommunikation zwischen Java-EE-Komponenten, Persistenzdienste zum langfristigen Speichern von Daten, Management der Komponenten über den gesamten Lebenszyklus (inklusive Instanziierung), Unterstützung für die Installation (Deployment) Während der Laufzeitumgebung übernimmt der Java EE Application Server diese Funktionalitäten. Zusätzlich kapselt er den Zugriff auf die Ressourcen des Betriebssystems. In der folgenden Abbildung ist die genaue Infrastruktur der Java EE dargestellt. 6 http://de.wikipedia.org/wiki/J2EE#Infrastruktur Seite 38 von 54 AIXTRON Abbildung 9: Infrastruktur Java EE Die einzelnen verschiedenen Komponenten (aus Abbildung 9), die jeweils eine bestimmte Aufgabe übernehmen, werden Container genannt. EJB-Container als Laufzeitumgebung für Enterprise Java Beans, welches für die konzeptuelle Entwicklung von Unternehmensanwendungen, wie Transaktions - , Namens- oder Sicherheitsdienste vorgesehen ist, die für Business Logic des Unternehmens innerhalb der Anwendung relevant ist Web-Container als Laufzeitumgebung für Servlets und JavaServer Pages (JSP) (wird im nachfolgenden Kapitel7 genauer behandelt) JCA-Container als Laufzeitumgebung für JCA Connectoren dient als Schnittstelle für verschiedenartige Anwendungen, die an das jeweilige System 7 3.4.1.1 Java Server Pages Seite 39 von 54 AIXTRON integriert werden sollen. Ein Beispiel einer solchen Schnittstelle ist die EAI, die in Kapitel 2.3.4.2 vorgestellt wurde. Der JMS-Provider dient der Kommunikation in Form von Nachrichten. Alle Komponenten sind in der Programmiersprache Java geschrieben. Zum historischen Hintergrund sei hinzugefügt, dass das Konzept seit dem 11.5.2006 den Namen Java EE 5 trägt. Vorgängerversionen (v1.0 bis v1.4) trugen noch den Namen J2EE, welcher auch im NetWeaver – Stack angegeben ist. 3.4.1.1 JavaServer Pages (JSP) Die Webprogrammiersprache JSP wurde von Sun Microsystems entwickelt. Ziel dieser Entwicklung war es, Java-Programme in HTML-Code oder allgemein in Webseiten zu integrieren. Für diese Einbindung gab es bereits das JHTML. JSP vereinfacht die dynamische Erzeugung von XML und HTML – Ausgaben mithilfe von einem eigenen Compiler. Der Quellcode, der dabei erzeugt wird, entspricht einem Java-Servlet. Das sind bestimmte Klassen, deren Instanzen die Sitzungsdaten auf dem Server speichern oder verändern. Kommt es zu einer Verwendung der Servlet-Spezifikation, so ist der Weg der Implementierung einer dynamischen Webseite der folgende: I. Erstellen einer Klasse, die von javax.servlet.http.HttpServlet erbt II. Überschreiben einer oder beider doGet und doPost – Methoden => Ziel ist die Möglichkeit, die http-Methoden GET und POST verarbeiten zu können III. Ablage der Metainformationen des Servlets in der web.xml – Datei, welche Deployment Descriptor genannt wird Es folgt, dass der Deployment Descriptor zusammen mit der komplilierten Klasse in einer einzigen Archiv-Datei zusammengeführt und zur Verfügung gestellt wird (Deployment). Da der in SAP NetWeaver bereitgestellte Application Server die Programmiersprache Java unterstützt, war es nötig für ein webbasiertes Portal JSP zu integrieren. Seite 40 von 54 AIXTRON 3.4.1.2 Java Persistence API Wie bereits8 beschrieben, operiert SAP NetWeaver speziell mit (Unternehmens-) Datenbeständen. Für eine erfolgreiche Entwicklung ist es nötig, diese Daten auf einfache und direkte Weise innerhalb der Anwendung als Objekte zu modellieren und abzuspeichern, wie auch diese zur Laufzeit verwendeten Objekte innerhalb einer relationalen Datenbank abzuspeichern. Da InfoCubes im BW rein aus relationalen Datenbeständen bestehen, die im OLAP-System benutzt werden, wird die Technik der objektrelationalen Abbildung verwendet. Die Java Persistence API bietet eine solche Schnittstelle, indem diese Library Funktionen zur Verfügung stellt, welche es ermöglichen mit Objekten zu arbeiten. Datenbankabfragen beziehen sich hier nicht auf die reinen Datenbanktabellen, sondern meistens auf vom OLAPProzessor verarbeitete InfoCubes, also schon relationale Datenentitäten, bzw. nur notwendige Teile davon. Für dieses Szenario eignet sich die Java Persistence Query Language (JPQL), die sich direkt auf Entitäten statt Tabellen bezieht. In der Java Persistence API werden zur Laufzeit die in JPQL formulierten Abfragen in SQL-Statements umgeformt, um eine klare Unterscheidung zwischen den jeweiligen Objekten und ihren Datenbeständen zu erreichen. Abbildung 10 illustriert die Java Persistence Infrastructure. 8 Kapitel 2 beinhaltet die Beschreibung, dass ein Unternehmen mit internen Datenbeständen interagiert Seite 41 von 54 AIXTRON Abbildung 10: Java Persistence API 3.4.1.3 WebDynpro Die nächste Stufe, die sich nach der Objektabbildung stellt, ist der Bereich der Entwicklung und die damit verbundene Form von Benutzeroberflächen, um Interaktionen seitens des Users zu ermöglichen. Auch hierfür stellt SAP NetWeaver ein Programmierkonzept bereit – WebDynpro, das besonders für webbasierte Anwendungen geeignet ist. Es beruht auf dem Model-ViewController – Entwurfsmuster (MVC). 3.4.1.3.1 Zielsetzung mit WebDynpro Mit WebDynpro wurden folgende Aspekte erreicht, die für die Entwicklung von Webanwendungen, welche browserbasierte GUIs mit Java bzw. Windowsbasierten GUIs verbinden, im Fokus stehen. Plattformunabhängigkeit SAP Standardtechnologie Seite 42 von 54 AIXTRON Trennung der Geschäftslogik von der Präsentationslogik über MVC Verringerung des Implementierungsaufwand mithilfe von grafischen Werkzeugen Automatischer Datentransfer durch Contextmapping Unterschiedliche Darstellung der Inhalte durch verschiedene Views Internationalisierung durch Mehrsprachigkeit Entwicklung performanter Webanwendungen Vordefinierte User Coding Areas 3.4.1.3.2 allgemeines Konzept – MVC (Model-View-Controller) Ein Model-View-Controller ist ein bezeichnendes Entwurfsmuster, in dem die Entwicklung einer Anwendung in drei Teile separiert wird: Das eigentliche Datenobjekt (model), einer Präsentationseinheit (view) und der für diese beiden Komponenten zuständigen Programmsteuerung (controller). Das model beinhaltet alle relevanten, persistenten Daten, welche dargestellt werden müssen, und ist für die Datenbeschaffung im allgemeinen zuständig. Die controller – Komponente ist für die Steuerung des Users zuständig. Über diese Steuerung wird dem User der Zugriff auf die Daten ermöglicht, welche er je nach gewünschter Funktionsweise ändern, bzw. lesen kann. In WebDynpro unterscheidet man zwischen zwei verschiedenen Controllern – den ViewControllern, welche für die Steuerung der Oberfläche implementiert sind und den ComponentControllern, welche den allgemeinen Programmablauf steuern und zusätzlich models mit ViewControllern verknüpfen. Natürlich müssen diese Funktionen, wie auch Daten über eine Oberfläche angezeigt werden, was mithilfe der view, einer Präsentation, realisiert wird. Seite 43 von 54 AIXTRON Abbildung 11: Model-View-Controller 3.4.1.3.3 Funktionsweise Der browserbasierte Client ermöglicht dabei eine plattformunabhängige Kommunikation. Zur Optimierung wird das in HTML-Formaten typische JavaScript eingesetzt. Für den Fall, dass ein Client JavaScript nicht unterstützt, übernimmt der Server die Generierung von nötigen HTML-Elementen wie –Funktionen. Ein Grund zur klaren Trennung der Aufgaben, wie sie das MVC – Entwurfsmuster beschreibt, ist die Möglichkeit, unterschiedliche Layouts für verschiedene Endgeräte zu generieren. In der Laufzeitumgebung und durch den Client werden passende Layouts „errechnet“. Hier wird ein weiterer performancetechnischer Aspekt betrachtet: Bei einem leistungsschwächeren Client übernimmt der Web Application Server das Rendern auf Client-Seite (client-side rendering), also diese Berechnung der Layoutkomposition. Kommt ein Client zum Einsatz, der eine bessere Hardwarekonfiguration besitzt, so ist die Layoutkomposition auf dem Client. Dieser Vorgang wird als Loadbalancing bei der Layoutberechnung bezeichnet. Ein wichtiger Teil bei dieser Entwicklung ist das Handling von Benutzerinteraktionen. In WebDynpro werden diese über Eingabekomponenten entgegengenommen. Alle möglichen Eingabekomponenten sind über ihre Methoden ansprechbar und können auch nach belieben Seite 44 von 54 AIXTRON erweitert werden. Wichtig ist, dass diese Komponenten im Hintergrund – also für den Entwickler unsichtbar/automatisch – auf Java Server Pages zugreifen. Ein bedeutender Unterschied ergibt sich bei diesem Zugriff im Gegensatz zu JavaScript: Es gibt keinen Loadbalancingmechanismus. Das Seitenlayout wird dabei berechnet, indem in HTML integrierter JAVA – Code von JSP benutzt wird. Dieser Vorgang wird nur serverseitig, deswegen kein Loadbalancing mit dem Client. Um Seiten zu erstellen, die einen ähnlichen oder gleichen Aufbau haben und sich somit voneinander beispielsweise durch ein Element unterscheiden, wird die Möglichkeit unterstützt, die Benutzeroberfläche sowohl statisch als auch dynamisch zu generieren. Es wird also angeboten, diese unterschiedlichen Elemente zur Laufzeit nachzuladen, ohne dass man die ganze Seite neu laden muss. Für die Aktualisierung der Seite oder Benutzeroberfläche verringert sich in diesem Fall der Zeitbedarf enorm. Dieser Fall wird als Round Trip spezifiziert. 3.4.1.3.4 Entwicklungsphase Als Basis für die Entwicklung einer WebDynpro – Applikation gilt der Meta Model Ansatz: Die Entwicklungsumgebung (in dem Fall SAP NW Visual Composer oder das Developer Studio) generiert Metadaten, die die Anwendung definieren. Diese Metadaten bilden ein Modell, das dem MVC-Entwurfsmuster entspricht. Um einen Standard für diese Art der Beschreibung zu definieren, wird XML eingesetzt. Diese Metadaten generieren folglich den Quellcode für die zu entwickelnde Anwendung. Ein weiteres Feature sind so genannte Hook-Methods, die es dem Entwickler ermöglichen, den Programmablauf zu steuern. Sie werden anhand der Metadaten generiert, um Zeitpunkte zu definieren, wann welche Ereignisse auftreten. Hinzu kommt die automatische Generierung von Quelltext für den Datenfluss zwischen Front – und Backend, als auch für die Navigation innerhalb der Anwendung und Erstellung der Benutzeroberfläche inklusive Komponenten. In der nachfolgenden Grafik sind die technischen Möglichkeiten einer Java Web Dynpro Anwendung abgebildet. Je nachdem für welche Art man sich entscheidet, gelangt man über Schnittstellen zum jeweiligen System: Benutzt man für die Entwicklung beispielsweise einen WebService Provider, so greift man über das Simple Object Access Protocol (SOAP) auf die nötigen Geschäftsdaten über einen dafür eingerichteten Web Service zu. SOAP ist ein Netzwerkprotokoll, welches auf der Seite 45 von 54 AIXTRON Anwendungsschicht des TCP/IP-Protokollstacks anzusiedeln ist und XML zur Repräsentation und Übertragung der Daten unterstützt. Für die Anwendungs-Integration in das SAP Enterprise Portal wird nach Erzeugung der WebDynpro Anwendung zur Laufzeit auch das XML-Format zur Darstellung der Anwendung auf dem Portal benutzt. Abbildung 12: Architektur Schnittstellen WebDynpro Anwendungen 3.4.1.4 ABAP ABAP ist die grundlegende SAP-Programmiersprache. Sie ähnelt COBOL. Weiterentwicklung SAP-Basis. Hauptsächlich werden mit dieser Sprache Daten einer zentralen Datenbank bearbeitet. Grundlegend ist diese Komponente für den eigentlichen direkten Bezug auf SAP R/3 Systeme. Da in dieser Arbeit mehr auf die Java-Entwicklung eingegangen wird, wird dieser Teil nicht weiter ausgeführt. 4 Ausblick SAP NetWeaver Developer Studio Eines der primären Ziele des NetWeaver ist die Möglichkeit, eine (Web)Anwendung zu erstellen, welche auf dem NetWeaver Application Server Einsatz findet. Die Architektur, wie Seite 46 von 54 AIXTRON SAP NetWeaver es schafft aus heterogenen Datenquellen Schnittstellen zum Umgang und zielgerichtet zur Programmierung von Anwendungen bereitzustellen, wurde in den vorherigen Kapiteln theoretisch behandelt. In diesem Kapitel wird die in NetWeaver enthaltene Software – Komponente Developer Studio vorgestellt, welche eine Entwicklungsumgebung ist, die auf Eclipse aufbaut. 4.1 Möglichkeiten und Funktionen Das Developer Studio bietet als zu Eclipse erweiterte Umgebung laut sap.com9 folgende Möglichkeiten und Funktionen an: J2EE-Perspektive - unterstützt Entwicklung und Anwendung der Technologien von Java 2 Enterprise Edition (J2EE), wie JavaServer Pages (JSPs), Servlets und Enterprise JavaBeans (EJBs). Web-Service-Perspektive - kombiniert Werkzeuge zur Definition, zur Suche und zum Testen von Webservices. Web-Dynpro-Perspektive bietet eine umfassende Umgebung für den modellbasierten Entwurf von Benutzungsoberflächen. Mit Web Dynpro können Sie Modelle von Benutzeroberflächen gestalten, die automatisch in Code für Java- und ABAPAnwendungen umgewandelt werden. Diese Benutzeroberflächen sind Client- unabhängig und lassen sich in unterschiedlichen Umgebungen nutzen – über das Web, Rich Clients oder mobile Geräte. Persistenzperspektive - unterstützt das Erstellen und Definieren von Datenbankobjekten wie Tabellen und Indizes mit Hilfe des Java Dictionary sowie von Editoren und Standards wie SQLJ oder Java Data Objects. Debugging-Perspektive - unterstützt das Testen von Java-Anwendungen durch Prüfen von Kenngrößen, Konventionen und Spracheinschränkungen. Java-Entwicklungsinfrastruktur-Perspektive - bietet Werkzeuge zum Organisieren, Verfolgen 9 und Koordinieren der Arbeit größerer Entwicklungsteams. Die http://www.sap.com/germany/plattform/netweaver/components/developerstudio/index.epx Seite 47 von 54 AIXTRON Entwicklerinfrastruktur verwaltet Quelltext, erstellt inkrementell neue Versionen und implementiert Anwendungen - immer auf dem richtigen Server und zur richtigen Zeit. Geschäftsprozess-Perspektive – ermöglicht Prozessarchitekten die Modellierung von Prozessebenen. Ziel ist das Erstellen und Debuggen ausführbarer Geschäftsprozessmodelle mit SAP NetWeaver Business Process Management. Geschäftsregeln-Perspektive - ermöglicht die Erstellung und Änderung von Verfahrensregeln in darstellbaren Formaten, beispielsweise Entscheidungstabellen mit SAP NetWeaver Business Rules Management. 5 Glossar Anwendung: Mit Anwendung wird eine Software oder Programm beschrieben, mit der der User/Anwender eine bestimmte Funktionalität am Computer erzielt. Anwendungs – Frontend: Schnittstelle zum User und steuernde Komponente eines Geschäftsprozesses. Authentifizierung Nachweis einer angegebenen Personalität oder eines bestimmten Merkmals. Backend: Mit Backend bezeichnet man auf Softwareebene diejenige Software die sehr systemnah ist. Benutzeroberfläche: Grafische Oberfläche, über die der Benutzer mit dem Computer (in einem Programm) interagiert. Cache: Kurz umschrieben, ist der Cache ein Speicher, der den zuletzt und am häufigsten verwendeten Inhalt zwischenspeichert. Seite 48 von 54 AIXTRON Datenmodell: Modell, zur Definition von Daten, wie z.B. in einer Datenbank. Eclipse: Entwicklungsumgebung, hauptsächlich für Java- Entwicklung. Im Laufe der Zeit wird es erweitert, und unterstützt (auch durch Addins/Plugins) mehrere Sprachen oder Standards (z.B. C++, XML). Enterprise Application Integration: Konzept, in dem die Geschäftslogik eines Unternehmens, in diversen Anwendungen integriert wird. Excel AddIns: Ein Excel AddIn ist ein optionales Modul, welches nach Installation in der Software Microsoft Excel zusätzliche Funktionen anbietet. Frontend: Mit Frontend bezeichnet man auf Softwareebene diejenige Software die sehr benutzernah ist, was bedeutet, dass hiermit die Schicht gemeint ist, in der die Benutzerschnittstelle realisiert ist.. GUI: Mit Graphical – User – Interface ist die Benutzeroberfläche gemeint, mit der der User arbeitet. Konsistente Datenbank: Mit einem konsistenten Datenbankzustand wird ein Zustand der Datenbank beschrieben, der an ein regelkonformes Schema gebunden ist. Diesem Schema liegen Regeln zugrunde, die eingehalten werden müssen, um diese Konsistenz zu erzielen. Laufzeitumgebung: Ein Programm, das ein gewünschtes Anwendungsprogramm durch Kommunikation mit dem Betriebssystem oder anderen Komponenten, für den jeweiligen Computer lauffähig bereitstellt. Normalisierung: Verfahren, um ein relationales Datenschema so zu zerlegen, um Redundanzen zu beseitigen. Objektrelationale Abbildung: Seite 49 von 54 AIXTRON Technik, mit der Objekte (als Entities) in einer relationalen Datenbank abgelegt werden können. persistent: s. Persistenz Persistenz: Fähigkeit, Daten oder digitale Objekte in Dateibeständen oder Datenbanken abzuspeichern. Query – Abfrage: Formale Abfrage in einer Datenbank nach bestimmten Daten(-sätzen). Query – View: Ansicht der nach einer Query – Abfrage ermittelten Daten(-sätze). Service Bus: Komunikation mit angebotenen Diensten. ->NetWeaver Process Integration Universal Description, Discovery and Integration (UDDI): Protokoll, um einen Verzeichnisdienst wie ein Repository, bereitzustellen. Webapplikation: Eine Webapplikation oder auch Webanwendung ist ein Computerprogramm, das von einem Webserver aus ausgeführt wird. Webbrowser: Computerprogramm zur Darstellung von Webseiten. Webseite: Spezielle Seite in der Informatik, die eine Anwendung beinhaltet oder Grafiken abbildet, und über das Internet in einem Webbrowser aufgerufen werden kann. Webserver: Anwendungsserver, der einen Webdienst oder eine Webanwendung anbietet. XML (eXtensible Markup Language): Seite 50 von 54 AIXTRON Standardformat, indem Daten in hierarchischen Strukturen dargestellt werden. Web Dynpro: 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. SAP ERP: ist das Hauptprodukt des deutschen Software-Unternehmens SAP AG, das es seit 1993 vertreibt. ERP steht für Enterprise-Resource-Planning oder Unternehmens-Informationssystem, womit alle geschäftsrelevanten Bereiche eines Unternehmens im Zusammenhang betrachtet werden können. 6 Literaturverzeichnis In der vorliegenden Arbeit wurde folgende Literatur verwendet, die in Buchliteratur und Weblinks aufgeteilt wird. Die Links der Screenshots sind im nachfolgenden Abschnitt aufgelistet. 6.1 Buchliteratur SAP BW: Buch SAP BW Datenbeschaffung, SAP Press ISBN 978-3-89842-1025-6 WebDynpro: Inside WebDynpro, SAP Press ISBN 978-3-89842-092-5 Portalarchitekturen, Unternehmensportale, Webportale: SAP NetWeaver Portal, SAP Press ISBN 978-3-89842-536-0 SAP NetWeaver Developer Studio SAP Java-Programmierung mit SAP NetWeaver, SAP Press ISBN 978-3-8362-1042-3 Seite 51 von 54 AIXTRON 6.2 Internetliteratur EAI http://www.torsten-horn.de/techdocs/eai.htm Business Logic http://de.wikipedia.org/wiki/Anwendungslogik JEE http://de.wikipedia.org/wiki/J2EE Java Persistence http://de.wikipedia.org/wiki/Java_Persistence_API Client Server http://de.wikipedia.org/wiki/Client-Server-Modell Java Server Pages http://de.wikipedia.org/wiki/JavaServer_Pages SAP NetWeaver Developer Studio http://www.sap.com/germany/plattform/netweaver/components/developerstudio/index.epx Rich Internet Application http://de.wikipedia.org/wiki/Rich_Internet_Application Workflow http://de.wikipedia.org/wiki/Workflow Webservice http://www.itwissen.info/definition/lexikon/Webservice-Architektur-WSA-web-servicearchitecture.html WebDynpro http://help.sap.com/saphelp_dm40/helpdata/de/db/bd3642e2a3ab04e10000000a1550b0/conte nt.htm Seite 52 von 54 AIXTRON http://www.bpc.ag/Presse-News/Knowledge-Corner/SAP-Web-Dynpro.html 6.3 Screenlinks Portalarchitektur und Business Intelligence wurden jeweils aus den Büchern SAP NetWeaver Portal bzw. BW Datenbeschaffung entnommen. Client Server http://www.modul-bus.de/mbnews/mbnews03/ClientServer.gif ETL http://upload.wikimedia.org/wikipedia/de/f/f0/ETL-Prozess.jpg Bex query http://en.sap.info/wp-content/uploads/2003/06/IMG192233ee5ae42027bf.gif Bex analyzer http://images.cnblogs.com/cnblogs_com/crazybugcn/AdHoc028.JPG http://wiki.sdn.sap.com/wiki/download/attachments/44794331/a23.gif Bex Web Appl http://wiki.sdn.sap.com/wiki/download/attachments/168461044/new%20iview%20BEx%20Web %20params.jpg Bex Web Appl Designer http://help.sap.com/saphelp_bw30b/helpdata/en/1a/456a3badc1b315e10000000a114084/Imag e2242.gif Bex Broadcaster http://www.con4pas.cz/res/data/003/000730_02_005621.jpg Java Persistence Seite 53 von 54 AIXTRON http://help.sap.com/saphelp_nw04/helpdata/de/2d/23b32e8c0152469edf07909703fe03/framese t.htm InfoCube http://wjd-mittelstandsfinanzierung.org/data/content/00000071/grafik2.jpg JEE http://upload.wikimedia.org/wikipedia/de/2/2e/J2ee-overview.png MVC http://www.ucancode.net/Products/Form2/mvc.gif WebDynpro http://help.sap.com/saphelp_dm40/helpdata/de/db/bd3642e2a3ab04e10000000a1550b0/TEMP LATE_image002.gif OLAP http://help.sap.com/saphelp_nw04/helpdata/de/d9/ed8c3c59021315e10000000a114084/TEMP LATE_image002.gif Seite 54 von 54
