Universität Dortmund Fachbereich Informatik Lehrstuhl für Software-Technologie Endbericht der Projektgruppe  Inhalt 1 Einleitung 6 2 Was ist eine Projektgruppe? 8 3 Seminarphase 9 3.1 Allgemein 9 3.2 Softwareentwicklungsprozesse 9 3.3 Applikationsserver 10 3.4 Konfigurationsverwaltung und Projektdokumentation 11 3.5 Telematik-, Mobilfunk- und Netzwerktechniken 12 3.6 XML-basierte Datenaustauschformate 12 3.7 Mobile Commerce 13 3.8 Sicherheit 14 3.9 E-Bill Anwendungen 14 4 Das Modell für Com42Bill 16 5 Die Architektur 19 5.1 Allgemein 19 5.2 Komponente GUI 20 5.3 Komponente Sicherheit 22 5.4 Komponente Business Logic 24 5.5 Komponente Datenkonverter 30 5.6 Komponente Datenbank 39 6 Funktionalität 42 6.1 Allgemein 42 6.2 Funktionen der Benutzeroberfläche 42 6.3 Funktionen der Administrationsoberfläche 53 7 Das Datenmodell 62 8 Hard- & Software 76 8.1 Infrastruktur 76 8.2 Installation 76 9 Projektmanagement 78 9.1 Einleitung 78 9.2 Abschnitte des Projekts 78 9.3 Querschnitssaufgaben 79 9.4 Aufgabenübersicht 81 10 Qualitätsmanagement 82 10.1 Einleitung 82 10.2 Prozessmodell 82 10.3 Qualitätssicherung 92 11 Fazit 95 Anhang A Anforderungsliste 97 A.1 Aufbau 97 A.2 Datenkonverter (DK) 98 A.3 GUI (G) 105 A.4 Business Logic (BL) 125 A.5 Sicherheit (S) 132 A.6 Datenbank (DB) 138 Anhang B Projektplan 143 B.1 Projektplan (tabellarisch) 143 B.2 Projektplan (grafisch) 150 Anhang C ebXML-Dokumente 154 C.1 CPP für Com42Bill 154 C.2 CPA zwischen Com42Bill und einem Rechnungssteller 159 C.3 CPA zwischen Com42Bill und einem Finanzdienstleister 165 C.4 Business Process Specification Schema (BPSS) 169 C.5 XML-Schema für den Import von Rechnungen/Stornos 171 C.6 XML-Schema für den Import von Rechnungsstati 173 C.7 XML-Schema für die Rückmeldung eines Rechnungs- bzw. Stornoimports 174 C.8 XML-Schema für die Rückmeldung eines Rechnungsstatusimports 176 C.9 XML-Schema für eine Überweisung 177 C.10 XML-Schema für die Rückmeldung des Finanzdienstleisters 177 C.11 Beispiel für eine ebXML Message (Rechnungsimport) 178 Anhang D Dokumentation der Workflow-Engine 180 D.1 Einleitung 180 D.2 BusinessObjects 180 D.3 Workflows 204 Anhang E Qualitätsmanagement: Testplan 207 E.1 Beschreibung des Testplans 207 E.2 Testprojektbeschreibung 207 E.3 Testgegenstände 209 E.4 Testziele 211 E.5 Testeinschränkungen 211 E.6 Teststrategie 212 E.7 Kriterien für das Ende des Tests 212 E.8 Testergebnisse 213 E.9 Testaufgaben 213 E.10 Testumgebungsanforderungen 214 E.11 Testverantwortlichkeiten 214 E.12 Testaufgabenverteilung 215 E.13 Testzeitplan 216 E.14 Testrisiken und Notfallplan 218 E.15 Fazit 218 Anhang F : Qualitätsmanagement: Reviews 220 F.1 de.Com42Bill.components.security.Authentification.java 220 F.2 de.Com42Bill.components.security.RequestAuthorizationBean.java 223 F.3 de.Com42Bill.components.gui.HistoryControllerBean.java 226 F.4 de.Com42Bill.components.dataconverter.impExpMgr.ImpExpMgrBean.java 229 Anhang G Qualitätsmanagement: Klassentests 232 G.1 de.Com42Bill.components.security.Authentification.java 232 G.2 de.Com42Bill.components.gui.RequestDispatcherBean.java 242 G.3 de.Com42Bill.components.dataconverter.businessServiceInterface.AttachmentConstructorBean.java 261 G.4 de.Com42Bill.ebppsystem.core.UserInformation.java 285 Anhang H Qualitätsmanagement: Systemtest 291 Anhang I Verzeichnisse 293 I.1 Abbildungsverzeichnis 293 I.2 Literaturverzeichnis 295 Einleitung Ein Electronic Bill Presentment and Payment-System (EBPP) ist ein Softwaresystem, das den Ablauf von Transaktionen zwischen Rechnungssteller und Rechnungsempfänger auf elektronischem Wege ermöglicht. Dieses System soll Unternehmen die Möglichkeit bieten, Rechnungen über ein elektronisches, einfach zugängliches und einfach bedienbares Medium zur Verfügung zu stellen, sowie den Endverbraucher in die Lage versetzen, diese Rechnungen zu überprüfen und zu bezahlen. Durch elektronische Medien wird der Handel erleichtert. Daraus resultieren neue Bedürfnisse an Abrechnungssysteme, um die Möglichkeiten der elektronischen Medien während der gesamten Transaktion zu nutzen und die Nachteile der klassischen Zahlungsarten zu vermeiden. Wie Abbildung 1 zeigt, ist die beliebteste Zahlungsart die Bezahlung per Rechnung [Wuv99]. Bei dieser Art der Zahlung hat der Kunde die Möglichkeit, seine Zahlungen vor der endgültigen Durchführung noch einmal zu kontrollieren. Verunsichert durch Nachrichten über Betrug oder Falschabbuchungen misstrauen viele Kunden Zahlungsarten, bei denen direkt auf ihr Konto zugegriffen wird.  Abbildung 1: Welche Zahlungsarten würden Sie im Internet bevorzugen? Typischerweise werden Rechnungen in Papierform der Ware beigelegt oder separat zugesandt. Diese Art der Rechnungsübermittlung ist jedoch sowohl auf Rechnungssteller- als auch auf Rechnungsempfängerseite sehr kostenintensiv. Während bei dem Rechnungssteller die Kosten in der Verwaltung und beim Versand sowie der Nachverfolgung der Rechnung anfallen, ist es für den Rechnungsempfänger aufwändig, einen Überweisungsträger auszufüllen und diesen zur Bank zu bringen, wobei hier jedoch vielfach elektronische Teillösungen im Einsatz sind, wie z.B. die Bezahlung von Rechnungen per Homebanking oder M-Payment-Systeme wie zum Beispiel Paybox [Pay01]. Hier beginnt die Idee eines EBPP-Systems. Wenn der Bezahlvorgang elektronisch erfolgt, kann auch die Rechnungsstellung elektronisch erfolgen; der Medienbruch zwischen elektronischem Medium zur Bestellung und ggf. zur Lieferung und einer Rechnungspräsentation auf Papier ist vermeidbar. Weiterhin können dem Rechnungsempfänger in einer zentralen Rechnungsverwaltung zusätzlich Finanzdienstleistungen, wie zum Beispiel Finanzierungen oder Transportversicherungen, angeboten werden. Die Verlagerung des Zahlungsverkehrs auf elektronische Systeme sorgt für eine Zeitverkürzung zwischen Rechnungsstellung und –ankunft bei dem Kunden. Dies ermöglicht eine schnellere Bezahlung, etwa wenn vor der Lieferung bezahlt werden soll. Des Weiteren kann der Rechnungssteller von einer sicheren Übertragung ausgehen, so dass verlorene oder vergessene Rechnungen als Verzugsgrund entfallen. Zudem entfallen Papierverbrauch und Versand, wodurch mittel- bis langfristig Zeit- und Kosteneinsparungen für die Unternehmen erzielt werden können. Die Option, dass ein derartiges System auch das Mahnwesen übernimmt, bietet ebenfalls Einsparungspotential auf der Seite des Rechnungsstellers. Der hier vorliegende Endbericht beschreibt die Arbeitsergebnisse der Projektgruppe Com42Bill, die die obigen Überlegungen in ein Softwaresystem umgesetzt hat. Nach einer Seminarfahrt, dessen Ergebnisse in Kapitel 3 vorgestellt werden, wurde zunächst ein Modell entwickelt, das das Grundgerüst für das zu implementierende System darstellt. Dieses in Kapitel 4 vorgestellte Modell wurde weiterentwickelt; Ergebnis ist die Architektur des Systems (Kapitel 5) sowie das zugehörige Datenmodell (Kapitel 7). Kapitel 6 beschreibt die Funktionalität des Systems. In Kapitel 8 folgt die Beschreibung der eingesetzten Hard- und Software. Die Berichte des Projektmanagements und der Qualitätsmanager schliessen sich diesem an. Den Abschluss bildet ein Fazit, in dem die Erfahrungen der PG-Teilnehmer zusammengefasst sind. Im Anhang befinden sich Erläuterungen und Beschreibungen der eingesetzten bzw. entwickelten Technik. Was ist eine Projektgruppe? Im Rahmen eines Studiums nimmt ein Informatikstudent hauptsächlich an Vorlesungen teil. Diese vermitteln theoretische Grundlagen und Spezialwissen. Dabei sind die Anwendungsgebiete eher abstrakt formuliert; der praktische Einsatz dieses Wissens wird hierbei nicht erlernt. Um diesem Problem zu begegnen, gibt es Projektgruppen. Die Projektgruppe ist ein zentraler Bestandteil des Hauptstudiums jedes Informatikstudenten der Universität Dortmund. Diese Pflichtveranstaltung umfasst zwei Semester mit jeweils ca. 15 Semesterwochenstunden. Acht bis zwölf Studenten nehmen an einer Projektgruppe teil. Die Gruppe wird von zwei Lehrstuhlmitarbeitern betreut. Diese Betreuer beraten und unterstützen die Projektgruppe. Projektgruppen zielen darauf ab, verschiedene praktische Fähigkeiten zu vermitteln und diese zu trainieren. Da Problemstellungen im Allgemeinen zu komplex bzw. zu umfangreich sind, um diese allein lösen zu können, muss das Problem innerhalb der Gruppe aufgeteilt werden. Dabei wird auch der Umgang mit gruppendynamischen Prozessen erlernt. Durch die Konfrontation mit neuen Problemen reicht es nicht aus, bekanntes Wissen anzuwenden. Vielmehr sind die Teilnehmer einer Projektgruppe gezwungen, sich über neue Techniken zu informieren, diese an ein Problem anzupassen und anschließend anzuwenden. Die Teilnehmer der Projektgruppe bekommen ein Problem vorgestellt. Dieses Problem müssen sie selbständig analysieren und strukturiert Lösungen dazu erarbeiten. Am Ende wird die Lösung implementiert; es werden also alle Phasen eines Softwareentwicklungsprozesses durchlaufen. Die Darstellung der Projektgruppe nach Außen und die Kommunikation mit der Außenwelt regelt die Gruppe in eigener Regie. Die Betreuer kontrollieren das Vorgehen und stehen der Gruppe in Problemfällen mit Ratschlägen zur Seite. Seminarphase Allgemein Um das Wissen aller Teilnehmern einer Projektgruppe auf eine homogene Basis zu stellen, werden in einer Seminarphase verschiedene Vorträge zu den unterschiedlichen Aspekten, die sich aus der Zielsetzung der Projektgruppe ergeben, gehalten. Die Seminarphase findet in der Regel vor dem eigentlichen Beginn der Projektgruppe in Form einer Exkursion statt, um das Kennenlernen der Teilnehmer untereinander zu fördern. Es folgt eine Zusammenfassung der Ausarbeitungen zu den Vorträgen, die Ausarbeitungen selbst sind auf der Internetseite des Projekts [C42B02] erhältlich. Softwareentwicklungsprozesse Mit steigenden Ansprüchen an aktuelle Softwaresysteme wird das Augenmerk immer mehr auf Softwareentwicklungsprozesse gelenkt, die diese Ansprüche erfüllen können. Aufgrund verschiedener Anforderungen bei der Softwareentwicklung sind unterschiedliche Softwareentwicklungsprozesse entstanden. Man muss bei der Betrachtung der Prozesse mehrere Begriffe unterscheiden. Ein Vorgehensmodell beschreibt auf abstrakte oder generische Weise, wie ein Softwaresystem entwickelt wird. Ein Prozessmodell beschreibt die Aktivitäten, deren Reihenfolge sowie deren Ziele und Elementarmethoden eines Prozesses. Ein Prozessleitfaden ist das Ergebnis der Anpassung eines Prozessmodells an ein Unternehmen [Mül99]. Während Anfang der siebziger Jahre das Wasserfallmodell entstand, welches den Entwicklungsprozess in Phasen unterteilt, existieren heutzutage eine Vielzahl von Modellen, welche deutlich komplexere Strukturen vorweisen. Das Spiralmodell [Boe86] basiert auf dem Wasserfallmodell. Es arbeitet in Zyklen, welche den Phasen des Wasserfallmodells entsprechen. Ein weiteres Modell ist das Prototyping Modell [Kah01]. Es gibt verschiedene Ansätze des Prototyping. Hier sind vor allem exploratives, evolutionäres, experimentelles und rapid prototyping zu erwähnen. Das V-Modell [IESE02] ist 1992 vom deutschen Verteidigungsministerium veröffentlicht worden. Es sollte die Softwareentwicklung im Bereich der Bundeswehr regeln. Mittlerweile ist dieses Modell aber für alle Bundesaufträge verpflichtend. Viele Unternehmen haben dieses Modell zum internen Standard gemacht. Das V-Modell ist in 4 Submodelle unterteilt. Die Entwicklung selbst wird im Submodell Systemerstellung (SE) dargestellt. Die Submodelle Qualitätssicherung (QS), Konfigurationsmanagement (KM) und Projektmanagement (PM) begleiten diese Entwicklung. Jedes dieser Submodelle hat seine eigenen Aktivitäten, Produkte und Rollen. Der Rational Unified Process (RUP) [Kru98] ist eigentlich kein Entwicklungsprozess, sondern ein kommerzielles Komplettpaket, das einen Entwicklungsprozess enthält. Der RUP unterteilt analog zum Wasserfallmodell die Entwicklung in vier Phasen. Abgeschlossen wird eine Phase durch einen Meilenstein. Sollten die Anforderungen eines Meilensteins nicht ausreichend erfüllt sein, so muss die Phase wiederholt werden. Extreme Programming [Wel99a] ist eine neue Entwicklungsmethodik, die in den letzen Jahren bekannt geworden ist. Es ist ein leichtgewichtiger Entwicklungsprozess, welcher auf vier Werten basiert. Diese Werte lauten Kommunikation, Einfachheit, Rückkopplung und Mut. Im IBM-OOTC-Prozess [Müll99] ist eine Phase die kleinste Prozesseinheit. Eine Phase ist nicht, wie bei den anderen Modellen, eine zeitliche Einteilung, sondern ein sich wiederholender Vorgang, welcher sich auf einen Entwicklungsaspekt konzentriert. Jede Phase erstellt ihr eigenes Produkt. Der IBM-OOTC-Prozess beschreibt diese Phasen und Produkte und definiert, welche Tätigkeiten in den Phasen durchzuführen sind. Nicht zuletzt werden auch Entwicklungsmodelle als weiterzuentwickelnde Produkte verstanden. Dieser Aufgabe widmen sich die Qualitätsmodelle. Das CMM teilt Softwareentwicklungsprozesse in 5 Qualitätsstufen ein. Je nach Einordnung in eine dieser Stufen werden unterschiedliche Maßnahmen zur Erreichung des Stufenziels vorgeschrieben. Bootstrap baut auf denselben Qualitätsstufen auf, welche im CMM definiert wurden. Es teilt jedoch diese Stufen in Viertel ein, um eine genauere Einordnung zu erlangen. Außerdem wird das Unternehmen in drei Bereiche eingeteilt. Diese Bereiche lauten Organisation, Methodik und Technologie. SPICE (Software Process Improvement and Capability Determination) [SQI02] wurde 1993 ins Leben gerufen, um einen internationalen Standard auf Basis der ISO 9001 Norm zur Qualitätssicherung bei der Softwareentwicklung zu entwickeln. SPICE baut teilweise auf CMM auf und erweitert den Umfang dieser Methode. Es enthält keine Vorgehensweise zur Beseitigung von Schwächen. Zur Unterstützung der Entwicklung existieren verschiedene Notationen. Die am häufigsten eingesetzten Notationen sind UML, Ereignisgesteuerte Prozessketten (eEPK) und Petri Netze. Applikationsserver Ein Application Server ist eine Lösung für viele Client/Server Problematiken: monolithische und nur teuer zu wartende Applikationen, erhöhte Netzwerkbelastung wegen der Datenverarbeitung auf dem Client, schlechte Wiederverwendbarkeit der Applikationslogik. Durch Einführung einer zusätzlichen Schicht – der Applikationsschicht – wird die Applikationslogik von den Clients in einen Application Server verlagert. Die Clients beschäftigen sich nur mit der Entgegennahme von Benutzer-Events und mit der Steuerung des Benutzer-Interface (Abbildung 2).  Abbildung 2: Aufbau eines 3- und mehrschichtigen Systems Als Standard, der das Zusammenspiel zwischen Application Server und Komponenten genau regeln soll, wurde Enterprise Java Beans (EJB, aktuell in der Version 2.0) festgelegt. EJB-Komponenten werden Enterprise Beans genannt und bedienen sich der Programmiersprache Java, die sich aufgrund ihrer Vorteile (klare Trennung von Interface/Implementierung, Plattformunabhängigkeit…) auf diesem Gebiet durchgesetzt hat. Als rein serverseitige Komponenten enthalten EJB's keine grafische Benutzeroberfläche, sondern implementieren die reine Funktionalität einer Applikation (Business Logic). Clients nutzen die von den Beans angebotenen Dienste, indem sie sich mit diesen mittels geeigneter Protokolle verbinden. Die Realisierung einer grafischen Benutzeroberfläche ist dabei nicht zwingend erforderlich. Ein weiterer wichtiger Standard im Bereich der Java Application Server ist die Java 2 Platform Enterprise Edition Spezifikation von Sun Microsystems, die die Standards beschreibt, an die sich Hersteller/Entwickler von zertifizierter Enterprise-Software halten müssen. Als reine Spezifikation lässt J2EE, die zurzeit in Version 1.3 vorliegt, den Herstellern bei der Implementierung freie Hand, was teilweise wiederum zu Problemen der Inkompatibilität führt, da Spezifikationen mitunter unterschiedlich ausgelegt werden. Da die vollständige Betrachtung der Eigenschaften auch nur eines Application Servers den Rahmen dieses Abstracts sprengen würde, wird daher für Interessierte auf das Seminar Java Application Server des WS2000 verwiesen. [AS02] Konfigurationsverwaltung und Projektdokumentation Ziel dieses Abschnitts ist es, die prinzipielle Arbeitsweise von Software-Konfigurations-Management (SKM)-Werkzeugen vorzustellen. Darüber hinaus wird eine Auswahl an Werkzeugen kurz präsentiert. Software-Konfigurationsmanagement (SKM) ist die Aufgabe, Änderungen - und damit die Evolution - eines Softwaresystems zu organisieren und zu kontrollieren. Das Ergebnis einer Änderung an einer Software-Komponente wird als Version bezeichnet und wird von einem SKM-Werkzeug durch automatische Vergabe einer Versionsnummer dokumentiert. Unter einer Konfiguration versteht man die Zusammenfassung aller Komponenten eines SW-Systems zu einer Einheit [Ze00]. Um SKM in automatisierter Form anzuwenden, bedient man sich sogenannter SKM-Werkzeuge. Aufgaben hierbei sind die Rekonstruktion (Rückgriff auf eine vorherige Version einer Komponente), die Koordination (Vermeidung von gleichzeitiger Bearbeitung einer Komponente durch verschiedene Entwickler) und die Identifikation (Dokumentation von Unterschieden zwischen einzelnen Versionen). Das Repository eines SKM- Werkzeugs ist ein zentrales Archiv, in dem alle Versionen aller Komponenten eines Softwaresystems abgelegt werden. Mit dem Begriff Sandbox wird der Arbeitsbereich bzw. das Arbeitsverzeichnis bezeichnet, in dem die Änderungen an den Komponenten vorgenommen werden, wobei der Inhalt des Repository zunächst von den Änderungen unberührt bleibt. Durch eine check in - Funktion werden Komponenten aus dem Arbeitsbereich in das Archiv kopiert. Das Werkzeug ermittelt dabei die Änderung gegenüber der vorherigen Version und vergibt automatisch eine Versionsnummer bzw. Revisionsnummer. Bei der check out-Funktion wird in umgekehrter Weise die aktuellste Kopie der gewählten Komponenten in den Arbeitsbereich kopiert [Pe01]. Durch eine lock-Funktion können Dateien nach einem check out für andere Benutzer mit einem Schreibschutz versehen werden. Durch diese Funktion kann eine Datei immer nur sequentiell von allen Benutzern bearbeitet werden. Um Bearbeitungsvorgänge zu parallelisieren, bieten viele SKM- Werkzeuge die Möglichkeit, Versionierungen in verschiedene Pfade aufzuteilen und zu einem späteren Zeitpunkt wieder zusammenzuführen. Das Revision Control System (RCS) ist ein kostenloses Werkzeug, mit dem nur Dateien verwaltet werden können, Unterverzeichnisse werden nicht unterstützt. CVS (Concurrent Version System) kann im Gegensatz zu RCS auch ganze Verzeichnisbäume bzw. komplette Software-Projekte versionieren. SCCS (Source Code Control System) ist ähnlich wie RCS sehr rudimentär, allerdings ohne Portierungen nach Windows und ohne grafische Benutzerschnittstelle. Als kommerzielle Varianten verfügbarer SKM - Werkzeuge sind beispielsweise PVCS Version Manager , RATIONAL Clearcase oder Microsoft Visual Source Safe zu nennen [Sch00, Wie02]. Zur Projektdokumentation gehören die Beschreibung von Schnittstellen und Funktionen und die Dokumentation der durchgeführten Änderungen (Versionsgeschichte). Änderungen können mit Hilfe der SKM-Werkzeuge dokumentiert werden. Beschreibungen und Design-Dokumente müssen durch das SKM-Werkzeug mitverwaltet werden. Telematik-, Mobilfunk- und Netzwerktechniken Dieser Vortrag dient der Einführung in die Bereiche Telematik, Mobilfunk- und Netzwerktechniken. Aus der Definition des Begriffs Telematik geht hervor, dass unter dem Begriff Telematik der gemeinsame Einsatz von Informatik und Telekommunikationstechnik zu verstehen ist [BMI97]. Als ein einfaches Beispiel kann man sich zwei Rechner vorstellen, die über Mobilfunk miteinander kommunizieren. Zu den populärsten Einsatzgebieten der Telematik gehören das Gesundheits- und Verkehrswesen. Im Gesundheitswesen werden durch Telematik Kommunikationserleichterungen und Effizienzsteigerungen durch Rationalisierungsprozesse erreicht. Zudem können durch Schaffung integrierter Versorgungsketten Qualitätsverbesserungen erzielt werden. Durch den Einsatz der Telematik im Straßenverkehr wird die bestehende Infrastruktur effizienter genutzt und damit der Verkehrsfluss verbessert. Weitere Folge ist eine Optimierung der Transport- und Verkehrsabläufe. Ferner werden bei Einsatz von Telematikstrukturen im Strassenverkehr auch eine Verringerung der Umweltbelastung und eine Erhöhung der Verkehrssicherheit prognostiziert [LBE01]. Das Kapitel über Mobilfunktechniken gibt einen Überblick über die Technik, die dem Mobilfunk zu Grunde liegt, angefangen mit einem kurzen Ausflug in die analoge Vergangenheit des Mobilfunks über im Augenblick verwendete Techniken bis hin zu modernen Verfahren, die in Zukunft die Mobilfunktechnik bestimmen sollen. Grundlegend für Netzwerktechniken sind die Referenzmodelle ISO/OSI und TCP/IP. Die wesentliche Idee ist hierbei, datenverarbeitungsorientierte Funktionen, transportorientierte Funktionen und physikalische Übertragung getrennt voneinander zu betrachten und zu realisieren [Obe98]. So wird die Komplexität bei der Planung und dem Entwurf des Rechnernetzes reduziert. XML-basierte Datenaustauschformate Der automatisierte Austausch von Daten zwischen Maschinen ist seit mehreren Jahrzehnten für Geschäftstransaktionen unerlässlich. Electronical Data Interchange (EDI) ist hierbei der Obergriff für den „unternehmensübergreifenden Austausch von strukturierten Geschäftsdokumenten zwischen Rechneranwendungen unter Nutzung von Datenformatstandards und Kommunikationswegen“ [Geo01]. Als Kommunikationsweg hat sich in den letzten Jahren das Internet mit seinen Standardprotokollen weltweit etabliert. Somit steht den Geschäftspartnern ein weitverbreitetes kostengünstiges Medium zur Verfügung. Im Bereich der Datenformatstandards basieren alle heutigen Auszeichnungssprachen auf der Standardized Generalized Markup Language (SGML), welche die allgemeinste und ausdrucksstärkste Sprache darstellt. In Anschluss an die hauptsächlich für die Präsentation von Inhalten gedachten Hypertext Markup Language (HTML) wurde die eXtensible Markup Language (XML) entwickelt. Diese nimmt eine Trennung zwischen der Struktur der Dokumente und den Inhalten vor, welche separat definiert werden können. Somit ist die Sprache problemlos erweiterbar, da eigene Strukturen definiert werden können [Jec01, Bei01]. XML bildet die Grundlage für sogenannte Web Services. Diese Dienste sind Softwarekomponenten, die via Remote-Procedure-Calls (RPC) über das Internet genutzt werden können. Das Simple Object Access Protocol (SOAP) ermöglicht dabei das standardisierte Durchführen von RPCs, mit Hilfe von UDDI können Web Services gefunden werden. WSDL dient schließlich der Beschreibung der Web Services [Che01, OM01, Jep01, Sta01, Udd00, Ogb00]. Web Services dienen unter anderem dem automatischen Datenaustausch zwischen Softwaresystemen. Die für den Austausch benötigten Datenformate basieren vorwiegend auf dem XML-Standard. XML-basierte Datenaustauschformate lassen sich wie folgt in drei verschiedene Kategorien einteilen: Die Kategorie Frameworks legt lediglich die Spezifikationen für den strukturierten Nachrichten-/Dokumentenaustausch zwischen verschiedenen Partnern fest. Mit Hilfe der Gruppe Functionsn werden branchenunabhängige Geschäftsprozesse definiert, somit sind erste Bausteine vorhanden, um die Nachrichten zu strukturieren. Zum Nachrichtenaustausch innerhalb einer Branche beziehungsweise von einer Versorgungskette werden bei der Kategorie Verticals die XML-Vokabulare feingranulierter spezifiziert. Von der ersten bis zur dritten Kategorie erhalten die Austauschformate stets mehr Struktur, wodurch einerseits die Ausdruckfähigkeit abnimmt, andererseits wird durch fortschreitende Standardisierung der globale Austausch von Geschäftsdokumenten entproblematisiert [Whb01]. Mobile Commerce In den letzten Jahren gewann Electronic Commerce (E-Commerce), also die Abwicklung von Handel und Dienstleistungen über elektronische Medien, enorm an Bedeutung. Eine spezielle Variante des E-Commerce stellt Mobile Commerce (M-Commerce) dar. Der Konsument benutzt hierbei ein mobiles Endgerät wie z. B. ein Mobiltelefon oder einen PDA, um Geschäfte online abzuwickeln. Diese Mobilität bietet dem Konsumenten hohe Flexibilität durch Ortsunabhängigkeit. Die weite Verbreitung mobiler Endgeräte stellt bereits eine optimale Ausgangsbasis für M-Commerce dar. Die Anwendungsmöglichkeiten sind aber aufgrund der momentan verfügbaren Technologien noch sehr eingeschränkt. Einerseits bieten die auf dem GSM- und GPRS-Standard basierenden Mobilfunknetze zu geringe Datenübertragungsraten, andererseits zeichnen sich insbesondere WAP-Mobiltelefone durch mangelnde Darstellungsmöglichkeiten aus. Erst mit Zukunftstechnologien wie UMTS kann das Potential von M-Commerce voll ausgeschöpft werden. Besonders aufgrund der zukünftig möglichen Übertragung von Bild- und Videodaten ist hier eine Vielzahl an neuen Dienstleistungen zu erwarten. Ein Beispiel für einen Bereich, in dem bereits Dienstleistungen angeboten werden, ist Mobile Payment (M-Payment). Hierbei gibt es verschiedene Ansätze, um das Mobiltelefon als Zahlungsmittel zu etablieren. Der deutsche Anbieter „Paybox“ sowie der französische Anbieter „ItiAchat“ bieten Lösungen an, die sich aber in ihrer Handhabung deutlich voneinander unterscheiden. Andere Anbieter wie z. B. „Payitmobile“ befinden sich noch im Teststadium [Kie01]. Ein weiterer wichtiger Dienstleistungsbereich ist Mobile Banking (M-Banking). Dieser soll nach Aussagen von Analysten die Bankgeschäfte zukünftig revolutionieren. Bereits Anfang der 90er Jahre wurde von mehreren großen Finanzinstituten wie z. B. der Dresdner Bank der Aktienhandel via SMS angeboten, allerdings ohne großen Erfolg. Ein wesentlich erfolgreicheres Beispiel ist die auf Java basierende Applikation „youtrade on Palm“, die vom Schweizer Finanzinstitut Credit Suisse eingesetzt wird. Hierdurch hat der Kunde die Möglichkeit, seine Aktiengeschäfte via PDA auszuführen [Mus02]. Sicherheit Sicherheit in offenen Netzen wird in Zukunft ohne die Verwendung kryptographischer Verfahren nicht zu gewährleisten sein. Das technologische Know-how sowie hardware- und softwarebasierende Verfahren zum Schutz der Vertraulichkeit, der Integrität und der Zuordnungsfähigkeit von über Netze zu übermittelnden Nachrichten und zu speichernden Daten ist vorhanden. In der Telekommunikation kann Verschlüsselungstechnik von den Betreibern der Dienste eingesetzt werden, beispielsweise im Mobilfunknetz. Es besteht aber auch die Möglichkeit, dass die Teilnehmer ihre zu übermittelnden Informationen selbst schützen, indem sie entsprechende Verschlüsselungs- und Signaturtechniken einsetzen. In dem Vortrag wurde der Schwerpunkt auf die Kryptographie gesetzt. Es wurden zuerst Verfahren der Kryptographie vorgestellt [Bro02], danach folgten als Beispiele zwei Algorithmen für das symmetrische Verfahren, nämlich DES (Data Encryption Standard) und IDEA (International Data Encryption Algorithm) und einen Algorithmus für das asymmetrische Verfahren, RSA (Rivest, Shamir und Adleman) und deren Ergebnisbeurteilung [RSA02]. Dann wurden die digitale Signatur sowie die Verfahren zur Erstellung und Überprüfung von Signaturen behandelt. Danach wurde ein Überblick über Zertifikate und deren Ausstellung gegeben. Im Weiteren wurden die Authentifizierung und im Anschluss Anwendungen wie SSL (Secure Socket Layer) und SHTTP für kryptographische Systeme präsentiert [Kro96]. E-Bill Anwendungen Electronic Billing Presentment and Payment –Systeme (EBPP) sind eine Applikation oder eine Menge von Applikationen, die den Ablauf der Transaktion zwischen Rechnungssteller und Rechnungsempfänger auf elektronischem Wege ermöglichen. Diese Systeme sollen Unternehmen und Endverbrauchern die Möglichkeit bieten, Rechnungen über ein elektronisches, einfach zugängliches und bedienbares Medium zur Verfügung zu stellen, zu überprüfen und zu bezahlen. Um ein solches System realisieren zu können, werden hohe Anforderungen an die Sicherheit und Effizienz unter Bezugnahme der gesetzlichen Regelungen und Vorschriften gesetzt. Für die Realisierung der Systeme werden 3 unterschiedliche Modelle herangezogen: Buyer Direct-, Thick Consolidator- und Thin Consolidator-Modell. Direct Billing-Systeme sind sehr Anwender-spezifisch und nur mit hohem Aufwand an unterschiedliche Rahmenbedingungen anzupassen. Hierbei agiert in der Regel ein Unternehmen als Rechnungssteller nur für seine eigenen Kunden. Systeme, die dem Buyer Direct-Modell folgen, haben sich Marktstudien zufolge bisher nicht durchsetzen können. Hierbei wird ein funktionierendes EBPP-System auf der Seite des Rechnungsempfängers vorausgesetzt. Bislang sind derartige Lösungen ausschließlich im B2B-Bereich anzutreffen, da ihre Realisierung aufgrund hoher Kosten auf den herkömmlichen Endkundenbereich nicht übertragbar ist. Nur das Consolidator-Modell verspricht eine Realisierung, die viele verschiedene Parteien zufrieden stellen könnte. Bei diesem Modell wird, wie bereits erwähnt, zwischen dem Thick und dem Thin Consolidator unterschieden. Hierbei agiert eine dritte Firma als Vermittler zwischen den Rechnungsempfängern auf der einen und den Rechnungsstellern auf der anderen Seite (Consolidator). Das Thick Consolidator Modell sieht eine vollständige Speicherung der Rechnungsdaten auf dem Consolidator-System vor, wohingegen das Thin Consolidator Modell die Aufbewahrung der detaillierten Rechnungsdaten bei dem Rechnungssteller voraussetzt. Der Consolidator bietet den Rechnungsempfängern in diesem Fall nur eine grobe Rechnungsbersicht, wobei der Rechnungsempfänger auf Wunsch über einen Verweis auf die Seiten des Rechnungsstellers die restlichen Details seiner Rechnungen einsehen kann. Auf diesem Weg bleibt der Direktkontakt zwischen einem Unternehmen und seinen Kunden erhalten. Die Entwicklung des EBPP begann als eine Menge von Einzellösungen unterschiedlicher Anbieter, die diese Systeme als Direktanbieter zum Eigenzweck entwickelten. Aufgrund der Nähe zu den elektronischen Medien waren diese Unternehmen hauptsächlich in der Internet- und Telekommunikationsbranche tätig. Die steigende Bedeutung des E-Commerce lässt ebenso dem EBPP eine größere Bedeutung zukommen, da es logisch erscheint, auf elektronischem Wege erworbene Waren über den gleichen Weg ohne einen Medienbruch, also der Rechnung auf Papier, zu bezahlen. Da die Wirtschaftlichkeit dieser Systeme stark von der Masse der sie nutzenden Kunden abhängig ist, stellen Benutzerfreundlichkeit, Effizienz und Funktionsvielfalt auf der einen, Akzeptanz und Vertrauen der Kunden auf der anderen Seite die entscheidenden Faktoren bei der Durchsetzung und Standardisierung des jeweiligen Systems dar. Als durchsetzungsfähigstes Modell der EBPP-Systeme wird von Fachleuten das Thin Consolidator Modell angesehen, denn dieses bietet allen Beteiligten die größte Flexibilität. Der Kunde kann also seine Rechnungen zentral abarbeiten, während die Unternehmen den überlebenswichtigen Draht zu ihnen behalten. Das Modell für Com42Bill Der Vergleich der drei Modelle zur Realisierung eines EBPP-System (siehe Kapitel 3.9) zeigt folgendes Bild: Direct Billing-Systeme sind anwenderspezifisch und nur mit hohem Aufwand an unterschiedliche Rahmenbedingungen anzupassen. Systeme, die dem Buyer Direct-Modell folgen, haben sich Marktstudien zufolge bisher nicht durchsetzen können. Ihr Einsatz ist mit vergleichsweise hohem Aufwand für den Rechnungsempfänger verbunden [So02]. Nur das Consolidator-Modell verspricht eine Realisierung, die vielen verschiedenen potenziellen Kunden gerecht wird: Branchenunabhängigkeit und die Möglichkeit, sämtliche Arten von Waren und Dienstleistungen in unterschiedlichen Zahlungsweisen zu bezahlen sind Vorteile, die mit den anderen Lösungen nicht erreicht werden. Bei der möglichen Ausprägung des Consolidator-Modells fiel in der Entwurfsphase die Wahl auf den Thin Consolidator, der den Austausch und die Verarbeitung nur der notwendigsten Rechnungsdaten vorsieht. Im Vergleich zum Thick Consolidator fallen weniger Daten an, was die Datenhaltungs- und Entwicklungskosten senkt. Eine weitere Stärke des Thin Consolidator-Modells besteht ferner darin, dass der direkte Kontakt des Rechnungsstellers zum Rechnungsempfänger durch ein System dieser Art nicht unterbrochen wird. Die Ergebnisse einer Experten-Untersuchung [So02], die Consolidator-Modellen im Vergleich eine positive Erfolgstendenz einräumen, bestätigen die Entscheidung, mit Com42Bill einen Thin Consolidator zu realisieren. Die an Com42Bill–Transaktionen beteiligten Parteien lassen sich in vier Gruppen einteilen, die in Abbildung 3 zusammen mit ihrer Relation zum Betreiber von Com42Bill dargestellt sind.  Abbildung 3: Rollenmodell Der Rechnungssteller sollte die Möglichkeit erhalten, sich über eine Weboberfläche jederzeit über den Status seiner Transaktionen informieren zu können. Von dieser Idee wurde vor allem mangels Zeit abgesehen. Der Ausweg bestand darin, die benötigten Informationen über die ebXML-Schnittstelle des Datenkonverters an den Rechnungssteller zu schicken. Somit beschränkt sich die Schnittstelle zu dem Com42Bill-System hauptsächlich auf die Kommunikation über die genannte standardisierte Schnittstelle. Dadurch erhält der Rechnungssteller folgende Datenaustauschszenarien: Er ist in der Lage, die entsprechenden Rechnungsdaten zur weiteren Verarbeitung an Com42Bill zu übergeben. Die Statusänderung des Bezahlungsvorgangs wird simultan vom Rechnungssteller an Com42Bill weitergegeben, wodurch der Rechnungsempfänger sich jederzeit über den Status seiner Rechnungen informieren kann. Solche Szenarien sind vollständig implementiert worden. Die Registrierung des Rechnungsstellers bei Com42Bill geschieht ausschließlich offline mit Unterzeichnung eines gemeinsamen Vertrags zwischen den beiden Parteien. Dabei werden alle geschäftsrelevanten Daten ausgetauscht, die eigentliche Freischaltung in dem Com42Bill-System geschieht durch das Anlegen eines neuen Rechnungsstellers auf der Administratoroberfläche. Diese Aufgabe obliegt somit dem Betreiber von Com42Bill. Die Rechungsempfänger sollten ursprünglich die Möglichkeit erhalten, sowohl über Web- als auch W@P-Schnittstellen mit Com42Bill zu arbeiten. Aufgrund hoher Anforderungen an die webbasierte Oberfläche blieb letztendlich keine Zeit mehr, die Handyvariante zu integrieren. Aus heutiger Sicht der rasanten Technologieentwicklung wäre eine WAP-Implementierung sogar als Fehlgriff zu betrachten, wenn man bedenkt, dass viele vielversprechende WAP-Projekte gescheitert sind. Über eine Mobillösung sollte erst im Zuge der Einführung von UMTS nachgedacht werden. Die Rechnungsempfänger können folgende Abläufe über die Webseite tätigen: Um seine persönlichen Rechnungsdaten einzusehen oder die Bezahlung seiner Rechnungen zu veranlassen, braucht der Rechnungssteller sich lediglich mit seinem Benutzernamen und seinem Com42Bill-Passwort anzumelden, wonach er sein persönliches Com42Bill-Portal erreicht. Die Voraussetzung hierfür ist die einmalige Registrierung bei dem Betreiber von Com42Bill. Diese geschieht direkt über die Weboberfläche. Der Benutzer wird dabei ausführlich über jeden Registrierungsschritt informiert und kann bei Bedarf auf die ausreichend vorhandenen Hilfestellungen zurückgreifen. Weiterhin kann sich ein Rechnungsempfänger per E-Mail über Fälligkeiten oder neu eingetroffene Rechnungen informieren lassen. Zusätzlich war die Möglichkeit vom SMS-Versand zu denselben Zwecken angedacht, die hohen Anschaffungskosten eines SMS-Gateways hinderten uns leider daran, diese Idee umzusetzen. Diese Option ist jedoch ein Bestandteil der Komponente Business Logic und kann bei Bedarf problemlos aktiviert und parallel zur E-Mail-Benachrichtigung eingesetzt werden. Die Finanzdienstleister führen die Zahlungsaufträge, die von den Rechnungsempfängern erteilt werden, aus. Die Voraussetzung für eine erfolgreiche Zusammenarbeit mit dem Com42Bill-System ist die Implementierung der ebXML-Schnittstelle von Seiten des Finanzdienstleisters, welche standardmäßig über die Datenkonverter-Komponente angeboten wird. Man soll an dieser Stelle bedenken, dass dieser Standard immer noch Zukunftsmusik bleibt, man jedoch fest von der Annahme ausgeht, dass immer mehr Finanzdienstleister diesen Standard akzeptieren und in ihre Kommunikationsschnittstellen integrieren werden. Somit bleibt auch Com42Bill sehr gut für die Zukunft des elektronischen Zahlungsverkehrs gerüstet. Was den konkreten Datenaustausch zwischen den Finanzinstituten und Com42Bill betrifft, so lässt sich dieser folgendermaßen zusammenfassen: Bei einer zur Bezahlung freigegebenen Rechnung gelangen die Informationen über die Komponente Business Logic zum Datenkonverter. Dieser seinerseits bereitet die Rechnungsdaten für den Austausch über die genannte ebXML-Schnittstelle auf und verschickt diese an das entsprechende Finanzinstitut. Die Statusabfrage ist jederzeit möglich, bei erfolgten Transaktionen oder evtl. aufgetretenen Fehlern informiert der Finanzdienstleister die Com42Bill-Gegenstelle umgehend. Dieser wiederum gibt die Daten in Com42Bill-interner Form an die Businesslogic-Komponente weiter, welche wiederum die GUI-Komponente (also den Rechnungssteller) mit neu eingetroffenen Daten konfrontiert. Somit wurden alle am Anfang festgesetzten Ziele der Kommunikation zwischen dem Finanzdienstleister und Com42Bill weitestgehend realisiert. Der Betreiber des Systems fungiert als Mittler zwischen Rechnungssteller, Rechnungsempfänger und Finanzdienstleister. Die von dem Rechnungssteller erhaltenen Rechnungsdaten werden dem Rechnungsempfänger übermittelt. Nach einer Zahlungsfreigabe des Rechnungsempfängers werden die Zahlungsdaten an einen Finanzdienstleister zur Ausführung übermittelt. Diese Funktionen erfordern kein Eingreifen des Betreibers, die Daten werden automatisch durch das System an die richtigen Empfänger übertragen. Um den reibungslosen Betrieb zu gewährleisten, hat der Betreiber jedoch jederzeit die Möglichkeit, über eine einfach zu bedienende Administrationsoberfläche in den Betrieb einzugreifen. Die Administrationsoberfläche bietet dem Betreiber eine einfache und sehr bequeme Möglichkeit, beinahe alle Parameter des Systems zu verwalten, sowie interne Abläufe zu kontrollieren. Anfangs war zusätzlich angedacht, eine Art statistische Auswertung der Geschäftsprozesse zu implementieren. Es stellte sich jedoch heraus, dass der Umfang dieser Aufgabe so enorm ist, dass man durchaus eine weitere Projektgruppe lange Zeit damit beschäftigen könnte. Abgesehen von dieser Ausnahme wurden alle Anforderungen umgesetzt. Somit erhält der Betreiber ein mächtiges Werkzeug zur Verwaltung seines gesamten Systems. Die Architektur Allgemein Die Systemarchitektur gibt eine Übersicht über die einzelnen Komponenten, welche gemeinsam das EBPP-System bilden. Bereits in der Seminarphase wurde eine Aufteilung in fünf Komponenten beschlossen, welche sich auch in Personengruppen, den Komponententeams, widerspiegeln. Jede Komponente hat einen klar abgegrenzten Aufgabenbereich. Der Zugriff einer Komponente auf Dienste einer anderen geschieht ausschließlich über definierte Schnittstellen. So ist eine Austauschbarkeit und Unabhängigkeit der Komponenten gewährleistet. Einige Entscheidungen bzgl. der Architektur haben systemweite Auswirkungen. Zunächst ist der Beschluss zu nennen, einen J2EE-Applikationsserver als Grundlage für das System einzusetzen. Diese Entscheidung ist aus den Überlegungen der Teilnehmer entstanden, dass es im Rahmen einer Projektgruppe nahezu unmöglich ist, ein zufriedenstellendes Rahmenwerk für ein komplettes Softwaresystem zu entwerfen und entwickeln. Als schwierigste Punkte sind hier das Transaktionsmanagement sowie das Objekt-Relationale-Mapping der Java-Objekte auf relationale Datenbankstrukturen zu nennen. Diese Überlegungen haben zu der Ansicht geführt, dass durch den Einsatz eines Applikationsservers das Softwaresystem Com42Bill deutlich an Qualität und Flexibilität gewinnen und somit durch die Einhaltung von Standards auch eine höhere Marktfähigkeit erlangen kann. Nach Ansicht der PG-Teilnehmer überwiegen die Vorteile eines solchen Einsatzes gegenüber dem massiven Einarbeitungsaufwand, der nahezu alle Komponenten betrifft. Im Endeffekt hat sich gezeigt, dass diese Entscheidung richtig war. Es mussten zwar während der gesamten Implementierungsphase immer wieder neuartige Probleme im Umgang mit dem Applikationsserver gelöst werden, es hat jedoch jeder eine Menge Erfahrungen sammeln können, die einem evtl. auch im späteren Berufsleben noch zugute kommen werden. Gerade im Bereich der Persistierung und des objekt-relationalen Mappings hat das EJB-Konzept geholfen, einen gewissen Qualitätsstandard zu erreichen, der dank unserer Entwicklungsumgebung auch problemlos auf Applikationsserver anderer Hersteller übertragen werden kann. Die zweite systemweite Entscheidung ist der Einsatz von RequestDictionaries. Hierunter sind Container-Objekte zu verstehen, in denen unter einem Namen beliebige Objekte abgelegt werden können (Key-Value-Paare). Die RequestDictionaries werden beim Eintreffen jeglicher Anfragen an das System erzeugt und bleiben mindestens bis zum Versenden der zugehörigen Antwort im System bestehen, maximal jedoch bis zum Beenden der zugehörigen Benutzersitzung. Hierdurch können die Schnittstellen zwischen den einzelnen Komponenten sehr klein gehalten werden. Beim Hinzufügen von benötigten Objekten müssen daher keine Schnittstellen angepasst werden. Jede Komponente nimmt sich die benötigten Informationen aus dem RequestDictionary und fügt eigene Objekte, die aus der Arbeit der Komponente resultieren, hinzu. Der einzige Nachteil eines solchen Mechanismus ist die Notwendigkeit der genauen Spezifikation aller Objekttypen und der zugehörigen Schlüssel durch die jeweiligen Komponenten. Hier muss also das Vorhandensein der benötigten Objekte sichergestellt werden. Der Verwaltungsoverhead, der durch das Anlegen und Synchronhalten der benötigten Konstanten (diese bilden die Keys) entstand, hat sich teilweise als etwas nervenaufreibend erwiesen. Hier war ziemlich viel Sorgfalt bei den Komponententeams notwendig, zumal die unterschiedliche Handhabung meist erst während der Integration auffiel. Trotzdem haben sich die schlanken Schnittstellen als sehr angenehm erwiesen. Man muss nur an wenigen Stellen auf deren Einhaltung achten. Es war sehr interessant zu sehen, wie unterschiedlich die ursprüngliche Architektur von den Komponententeams umgesetzt wurde. Von sehr vielen Zehn-Zeiler-Klassen bis zu Klassen mit 500 Zeilen ist alles dabei. Teilweise wurden die Subkomponenten direkt in Klassen umgesetzt. Daher werden die Komponenten vermutlich mit sehr unterschiedlichem Aufwand auf Änderungen reagieren können. Die Anpassbarkeit an neue Anforderungen können wir „leider“ nicht mehr erproben. Im Folgenden werden die Teilarchitekturen der einzelnen Komponenten vorgestellt. Komponente GUI Bei der Gestaltung der grafischen Oberfläche von Com42Bill wird besonderer Wert auf Benutzerfreundlichkeit und Softwareergonomie gelegt. Ein modernes, ausgewogenes Design und ein umfangreiches Hilfesystem sind maßgebende Eigenschaften dieses Systems. Es wurde eine Oberfläche erstellt, die es ihren Benutzern ermöglicht, die Bedienung und Navigation möglichst einfach und unkompliziert zu erleben. Eine große Rolle spielen eine überschaubare Seitenstruktur sowie die einfache Möglichkeit, die verschiedenen Funktionen, wie beispielsweise die Übersicht über offene Rechnungen, direkt von der Startseite aus zu erreichen. Das einheitliche Design aller Seiten des Systems trägt dazu bei, es allen Benutzern zu erleichtern, das System wiederzuerkennen und sich darin zurechtzufinden. Das Kennenlernen des Com42Bill-Web-Interfaces wird durch gezielte Hilfestellungen unterstützt. So wird zum Beispiel jeder Schritt der Rechnungsübersicht verständlich erklärt und erläutert, welche Daten von dem Endbenutzer erwartet werden und in welcher Form diese in die einzelnen Eingabefelder einzutragen sind. Einen weiteren Auszug aus dem Hilfesystem stellen die häufig gestellten Fragen (FAQ) dar, die bei den meisten Anfangsproblemen die erste Anlaufstelle sind. Auch diese sind selbstverständlich von jeder Seite über das Menü per Mausklick zu erreichen. Die technische Seite der GUI-Komponente bereitet die darzustellenden Daten in das aktuell benötigte Format auf. Der Zugriff auf das System erfolgt von Seiten der Rechnungsempfänger nur per Internet; hierfür wird eine HTML-Darstellung der Benutzungsoberfläche bereitgestellt. Eine Erweiterung auf andere Ausgabesprachen, wie bspw. WML, ist leicht machbar. Wählt der Rechnungsempfänger eine Funktion aus, leitet die GUI die zur Ausführung nötigen Schritte bei den anderen Komponenten ein. Diese Komponente stellt ein Web-Publishing Framework bereit, mit dem sich dynamisch Webinhalte generieren und anzeigen lassen. Der wichtigste architektonische Aspekt ist der Einsatz von XML (eXtensible Markup Language) und XSLT (XML-Stylesheet-Language-Transformation). Mit diesen Mechanismen lassen sich auf einfache Weise dynamisch Inhalte für die verschiedensten Ausgabemedien erzeugen. Die Komponente GUI erhält von der Business Logic fachliche Objekte in Form von Entity-Beans, welche zur Anzeige ermittelt werden. Diese müssen nun zunächst in einen XML-Datenstrom transformiert werden. An dieser Stelle ist der einzige Nachteil dieser Technologie zu sehen. Da die meisten J2EE-Applikationsserver Mechanismen anbieten, benötigte Attribute der persistenten Entity-Beans erst bei explizitem Abruf nachzuladen (Lazy Loading), ist es von großer Wichtigkeit, bei der Transformation in XML auch nur die wirklich zur Anzeige benötigten Daten zu übersetzen. Für die Transformation wurden im Laufe der Zeit verschiedene Ansätze diskutiert und ausprobiert. Zunächst wurde die Einsetzbarkeit von Castor (www.castor.org) geprüft. Das Team kam jedoch zu dem Schluss, das Castor für diesen Zweck noch nicht weit genug entwickelt ist. Bei komplexeren Objekten und Relationen gab es keine zufriedenstellenden Lösungen. Der zweite Versuch war eine statische Implementierung der Transformation. Hierbei wurden die XML-Tags „per Hand“ erzeugt. Diese Lösung stieß ebenfalls schnell an ihre Grenzen. Die letzte und aktuelle Lösung erfolgt über die Java-Introspection-API, welche die Struktur der Objekte dynamisch abfragen und somit die benötigten Daten extrahiert werden kann. Liegt nun der XML-Datenstrom vor, kann ein XML-Stylesheet mit Hilfe eines XSLT-Prozessors auf diesen angewendet werden. Durch diese Transformation wird der fertige Ausgabe-Datenstrom erzeugt, welcher zurück zum Client übertragen wird. Lediglich durch den Austausch eines solchen Stylesheets kann bereits ein anderes Ausgabeformat, wie z.B. PDF erzeugt werden. Vom Einsatz eines fertigen XML-Publishing-Frameworks wurde abgesehen, da die angebotenen Funktionalitäten die benötigten bei weitem übersteigen und meist auf den Einsatz ohne Zuhilfenahme von Applikationsservern ausgelegt sind. Nach Ansicht des Komponententeams GUI würde der Einarbeitungsaufwand den gewonnenen Nutzen in diesem Falle übersteigen. Bei der Umsetzung der Architektur hat das Komponententeam weitestgehend die Subkomponenten direkt in Klassen umgesetzt. Aus Sicht der Architekten bestehen hier noch Optimierungsmöglichkeiten im Bereich des Klassendesigns. Mehrere Hilfsklassen für bestimmte Funktionen erhöhen die Übersicht. Ebenso wären die Einsatzmöglichkeiten von J2EE-Architektur-Patterns zu prüfen. Die Komponente GUI weist folgende Architekturübersicht auf:  Abbildung 4: Teilarchitektur der Komponente GUI GUI: Unter diesen Bestandteil fallen alle zur Verfügung gestellten grafischen Benutzeroberflächen, auf die ein Geschäftspartner zugreifen kann. RequesthandlerServlet: Dies ist der Startpunkt der Verarbeitung aller von der Weboberfläche gestellten Requests. Die vom Eingabemedium abgeschickten Datenformulare bzw. gestarteten Aktionen werden hier entgegen genommen. Das Servlet erhält einen Eingabestrom an Daten, der aufzubereiten ist. Alle Daten, welche sich am http-Request befinden, werden in einem RequestDictionary (Container-Objekt) hinterlegt. Im nächsten Schritt wird die Syntaxkontrolle für die Eingabedaten gestartet. Im Anschluss wird der RequestDispatcher aufgerufen, welcher die weitere Abarbeitung des Requests einleitet. Zuletzt wird der ResponsePresenter zur Erzeugung des Ausgabedatenstroms angestoßen, bevor das Servlet die Daten zurück zum Client überträgt. RequestDispatcher: Diese Komponente ist die zentrale Verwaltungsstelle der ClientRequests. Der Dispatcher delegiert die Request-Autorisierung und Authentifizierung bei der Sicherheit. Des Weiteren wird geprüft, ob die Anfrage aus dem Cache des Historycontrollers beantwortet werden kann, um die Business Logic nicht unnötig zu belasten. Ebenso erfolgt die Behandlung von Fehlermeldungen, welche im Fall einer fehlerhaften Autorisierung bzw. Authentifizierung durch die Komponente Sicherheit ausgelöst werden. Zuletzt wird die Ausführung des Geschäftsprozesses bei der Business Logic initiiert. HistoryController: Beim HistoryController ist eine Verbotsliste für nicht erlaubte Übergänge in der Navigationsstruktur der GUI hinterlegt. Hierdurch wird für jeden Request ersichtlich, ob dieser gültig ist und sich somit der Benutzer „an dieser Stelle“ befinden darf. Mit Hilfe dieser Subkomponente lässt sich sicherstellen, dass sich jeder Benutzer mit seiner Session in einem genau definierten Zustand innerhalb des Systems befindet. Der HistoryController arbeitet dabei ähnlich einem Zustandsautomaten, wobei durch das Ausführen von Geschäftsprozessen und dem anschließenden Anzeigen der Ergebnisse Zustände definiert werden. Mit Hilfe der Verbotsliste werden alle unzulässigen Zustandsübergänge festgelegt. Bei jedem Request wird also der aktuelle Zustand der Session festgestellt und mit Hilfe der aktuellen Anfrage entschieden, ob ein entsprechender Zustandsübergang ausgeführt werden darf, also ob die Anfrage abgearbeitet werden kann. Andernfalls wird der Zustand nicht geändert und der Benutzer erhält eine entsprechende Meldung oder die vorhergehende Seite erneut angezeigt. Des Weiteren ist im Historycontroller ein Caching-Mechanismus implementiert. Statische Daten können permanent hinterlegt werden, dynamische Daten werden nach dem Ablauf von drei Minuten aus dem Cache entfernt. WorkflowAdapter: Diese Einheit stellt die einzige Schnittstelle von der Requestverwaltung zur BusinessLogic dar. Der WorkflowAdapter beauftragt den WorkflowMgr, welcher den Einstiegspunkt in die Business Logic darstellt, den Geschäftsprozess zu starten. Ebenso nimmt er die Ergebnisse der Geschäftsprozessausführung entgegen. Der WorkflowAdapter wird auch von der Komponente Datenkonverter und vom JobMgr der Komponente Business Logic zum Starten von Geschäftsprozessen benutzt. ResponsePresenter: Der ResponsePresenter arbeitet die Ergebnisse des Prozesses, welche sich in dem vom RequesthandlerServlet erstellten RequestDictionary befinden, grafisch auf für die GUI-Anzeige und sendet einen Datenstrom entweder direkt oder über das RequesthandlerServlet an diese. Mit Hilfe der BeanUtils [APA01] aus dem Apache-Jakarta-Projekt werden die Objekte in ein XML-Dokument umgewandelt, welches anschließend vom Xalan-XSLT-Prozessor und einem XSL-File in ein HTML-Dokument weiterverarbeitet wird. Komponente Sicherheit Diese Komponente ist dafür zuständig, alle Vorgänge zu überwachen und sicherheitskritische Vorgänge zu steuern. Es werden Sicherheitsrichtlinien definiert, um ein einheitliches Sicherheitskonzept zu realisieren. Ziel aller Maßnahmen ist ein hoher Sicherheitsstandard, der gewährleistet, dass Daten korrekt und unverändert übertragen werden. Weiterhin muss sichergestellt werden, dass ein Benutzer nur auf die ihn betreffenden Daten zugreifen kann. Die Sicherheitsrichtlinien stellen eine Grundlage für die Konzeption und Implementierung der einzelnen Komponenten und deren Subkomponenten dar. Sie legen fest, über welche Protokolle mit Programmen außerhalb des Systems wie z.B. WWW-Browsern kommuniziert werden soll. Bevor ein Rechnungsempfänger bzw. Rechnungssteller das System verwenden kann, muss er sich zunächst anmelden. Die Authentifizierung erfolgt durch eine Benutzeridentifikation und ein individuelles Passwort. Nach erfolgter Anmeldung werden die diesem Benutzer zugewiesenen Zugriffsrechte überprüft. Dadurch wird sichergestellt, dass ein Rechnungssteller bzw. –empfänger nur die Aktionen durchführen kann, für die er autorisiert ist. Insbesondere bedeutet dies, dass sich Rechnungssteller bzw. Rechnungsempfänger nur über die ihnen zugedachten Schnittstellen anmelden können. Während der Ausführung werden bei jeder gewählten Funktion die Berechtigungen überprüft, um missbräuchliche Nutzung des Systems zu verhindern und Kompromittierungsversuche rechtzeitig zu erkennen. Die Sicherheitskomponente besteht - wie in Abbildung 5 dargestellt - im Wesentlichen aus vier Subkomponenten. Des Weiteren sind Funktionalitäten wie z.B. Datenübertragungsprotokolle beteiligt, welche sich jedoch im Architekturbild nicht zentral zusammenfassen lassen, sondern am gesamten Datenaustausch sowohl innerhalb als auch außerhalb des Systems beteiligt sind.  Abbildung 5: Teilarchitektur der Komponente Sicherheit RequestAuthorization: Die RequestAuthorization ist die erste Anlaufstelle bei der Bearbeitung eines jeden Requests. An dieser Stelle wird die Art des Requests identifiziert und an die entsprechende Untereinheit zur Bearbeitung weitergeleitet. Einzige Ausnahme stellen öffentliche Seiten dar, die ohne weitere Autorisierung angezeigt werden dürfen, da sie nicht auf sensible Daten zugreifen. Diese werden direkt von der RequestAuthorization autorisiert. SessionMgr: Der SessionMgr ist für die Verwaltung der Benutzersessions verantwortlich. Er bietet Funktionalität zum Auffinden und Bearbeiten von Sessions. Der Einsatz von Sessions ermöglicht das Behalten von Anmeldeinformationen über mehrere Requests. Die Überprüfung auf Gültigkeit einer Session erfolgt über mehrere Schritte. Zuerst wird überprüft, ob eine Session dem SessionMgr bekannt ist. Ist dies nicht der Fall, ist die Session ungültig. Ansonsten wird überprüft, ob die Session abgelaufen ist. In diesem Fall werden die Benutzerinformationen aus der Session entfernt und nur öffentliche Requests erlaubt. Authentification: Hier findet die Verwaltung aller Benutzer des Systems statt. Hierzu gehören die Rechnungssteller, die Rechnungsempfänger sowie die Administratoren des Systems. Nur Benutzer, die dieser Untereinheit bekannt sind, können sich am System über die ihnen zugewiesene Schnittstelle anmelden. Authorization: Mit Hilfe dieser Untereinheit erfolgt die Zugriffssteuerung für die einzelnen Geschäftsprozesse. An dieser Stelle ist hinterlegt, welche Benutzergruppe welchen Zugriff auf das System erlangen darf. Diese Funktionalität lässt sich unter dem Oberbegriff Role Based Access Control (RBAC) zusammenfassen. Die Rechte beziehen sich dabei auf Objekte, welche geschützt werden müssen. Die Benutzer nehmen nun eine oder mehrere Rollen ein und erhalten darüber bestimmte Rechte auf die Objekte, welche bei Com42Bill in erster Linie Geschäftsprozesse (Workflows) sind. Die höheren Level der RBAC führen komplexere Strukturen wie beispielsweise Hierarchien ein. Komponente Business Logic Die Komponente Business Logic bildet das Kernstück des Systems. Ihre Aufgabe ist es, alle im System anfallenden Geschäftsprozesse abzubilden und bei entsprechendem Aufruf abzuarbeiten. Ein Geschäftsprozess ist dabei eine zusammengehörige Folge von Aufgaben, welche nach bestimmten Regeln auf ein bestimmtes Ziel hin durchgeführt werden. Als Beispiel ist die Durchführung einer Finanztransaktion zu nennen. Von der Beauftragung der Transaktion durch den Rechnungsempfänger bis zum Empfang einer Statusmeldung am Ende der Transaktion sind verschiedene Teilaufgaben zu erfüllen, welche als Gesamtheit einen Geschäftsprozess darstellen. Die gesamte Verwaltung der Workflows, welche Geschäftsprozesse im System repräsentieren, wird durch die im Folgenden beschriebene Workflow-Engine durchgeführt. Workflow-Engine Durch den Einsatz von Workflows hat die Komponente sehr viel an Flexibilität gewonnen. Workflows bestehen aus mehreren Teilabschnitten, welche jeweils kleine Schritte von der Geschäftslogik ausführen, die sog. Business-Objekte. Im Gegensatz zum reinen Einsatz von Session Beans sind die Teile der Geschäftsprozesse nicht mehr fest verdrahtet. Außerdem muss bei einer Änderung der Ablaufreihenfolge nicht mehr der Source-Code angepasst werden, sondern nur noch die XML-Datei. Hierdurch wird auch die uneingeschränkte Wiederverwendbarkeit der einzelnen Business-Objekte garantiert, die nun in mehrere Workflows eingebunden werden können. Abbildung 6 stellt dies am Beispiel einer Zahlungsanweisung dar. Um eine größtmögliche Flexibilität zu erreichen, müssen weitergehende Funktionen, wie Verzweigungen zwischen Workflows sowie Entscheidungs- und Zusammenführungsknoten, bereitgestellt werden. Aufgrund der Modellierung der Workflows in XML unterliegt man bei der Umsetzung und Entwicklung der Infrastruktur keinen Einschränkungen. Als XML-Sprache für die Workflow-Definitionen viel die Wahl auf die Business-Process-Modelling-Language (BPML) der Business-Process-Modelling-Initiative (BPMI) [BPM00], einem Zusammenschluss aus vielen Vertretern der Wirtschaft. Dieses Vokabular enthält alle benötigten Funktionen. Die Ausführung der Geschäftsprozesse muss durch eine zentrale Einheit gesteuert und überwacht werden. Mit dieser Kontrolleinheit interagieren die anderen Komponenten mit Ausnahme der Datenbank, die von Teilkomponenten der Business Logic direkt angesprochen wird. Es lassen sich drei Möglichkeiten unterscheiden, wie ein Geschäftsprozess gestartet werden kann. Die erste Möglichkeit ist der Aufruf durch die Komponente GUI im Rahmen einer Benutzerinteraktion. Mögliche Interaktionen sind zum Beispiel die Bezahlung einer Rechnung oder die Pflege der angegebenen Kontendaten. Die zweite Möglichkeit ist der Prozessstart durch den Datenkonverter, zum Beispiel nach dem erfolgten Import neuer Rechnungsdaten. Die dritte Möglichkeit ist die zeitgesteuerte Ausführung von Standard-Aufträgen, wie zum Beispiel die Mahnungsversendung oder die Durchführung von Finanztransaktionen. Im Folgenden wird auf die technische Umsetzung eingegangen.  Abbildung 6: Beispiel-Workflow Eine Teilaufgabe des Komponententeams Business Logic war es, die Auswertung des in XML modellierten Workflows durchzuführen und in eine Aufrufreihenfolge von Business-Objekten umzusetzen. Hierzu wurde der Betrieb der Engine in zwei Phasen eingeteilt, die Initialisierungsphase und die Ausführungsphase. Während der Initialisierungsphase werden die XML-Dateien eingelesen und mit Hilfe von Castor in eine Objektstruktur übersetzt. Zu den wichtigsten BPML-Objekten existieren nun entsprechende Gegenstücke in der Komponente, welche rekursiv erzeugt und parametrisiert werden. Am Ende besteht ein Workflow nur noch aus einer Aneinanderreihung von verschiedenen Workflow-Nodes, wobei jeder Node seinen Nachfolger kennt. Die Ausführung besteht also lediglich aus dem rekursiven Aufruf der einzelnen Nodes, wobei jeder Node andere Aktionen durchführt. Im Folgenden werden die verfügbaren Nodes erläutert. BusinessNode BusinessNodes sind die einzigen Nodes, welche die sogenannte „Business Logic“ ausführen und direkt oder indirekt auf Entitäten arbeiten. Jeder BusinessNode ist für die Ausführung einer Instanz eines bestimmten Business-Objekts verantwortlich. Ein Business-Objekt ist dabei eine stateful SessionBean, welches in mehreren Contexten und somit mehreren Workflows auftreten kann und Aktivitäten ausführt. Die Implementierung der BusinessObjects als stateful SessionBeans hat sich als keine gute Wahl erwiesen. Ursprünglich war vorgesehen, während der Initialisierungsphase eine Instanz des SessionBeans zu erzeugen und diese während der Ausführung immer wieder zu benutzen. Beim Testen haben sich jedoch zwei schwierige Problemfelder ergeben. Zum einen sind stateful SessionBeans nicht Multithreading-fähig. Man kann sie lediglich im Deployment-Deskriptor so modifizieren, dass die Aufrufe sequentiell ausgeführt werden und der Container somit keine Exceptions ausgelöst. Dieser Umstand ist bereits ein Ausschlusskriterium für eine Enterpriseanwendung, wo jedem Request ein neuer Thread zugewiesen wird. Das zweite Problem besteht darin, dass der Container die Instanz des SessionBeans vernichtet, sobald darin eine Exception auftritt. Als Workaround wurde daher die Erzeugung der Bean-Instanzen in die Ausführungsphase der BusinessNodes ausgelagert, so dass für jeden Request eine neue Referenz vom Container geholt wird. Es wäre zu überlegen, ganz auf den Einsatz von SessionBeans zu verzichten. Die beiden herausragenden Funktionalitäten von SessionBeans, wie das Lifecycle-Management durch den Container und das Transaktionsmanagement werden eigentlich nicht benötigt, sondern von der Workflow-Engine übernommen. CallNode Der CallNode ist für die Ausführung von Subworkflows zuständig. Am Ende der Subworkflow-Ausführung kehrt die Engine wieder zum CallNode zurück, und der aufrufende Workflow wird weiter ausgeführt. Hiermit kann eine gewisse Modularisierung der Workflows erreicht werden. Es können beispielsweise immer wiederkehrende Aufgaben (sogenannte Prefix-Workflows) in den aktuellen Flow inkludiert werden. JumpNode Ähnlich wie der CallNode führt ein JumpNode ebenfalls einen Subworkflow aus. Er kann jedoch nur am Ende eines Workflows stehen und kehrt nicht mehr zurück. Auch dieser Node kann das Auftreten von zwei gleichen Handlungsabläufen in verschiedenen Workflows verhindern und sorgt für mehr übersicht. SwitchNode SwitchNodes sind Entscheidungsknoten, welche Abfragen auf dem Dictionary durchführen und daraufhin den nächsten auszuführenden Knoten auswählen. Ein SwitchNode enthält 0 bis n SwitchCaseNodes. Jeder SwitchCase enthält dabei eine Condition, sowie eine Aktivitätenliste und einen optionalen Kontext. Sollte keine Condition der jeweiligen Cases zutreffen, wird der SwitchDefaultNode ausgeführt, welcher keine Condition mehr enthalten muss. SwitchCaseNode Beim Zutreffen der Condition im SwitchCaseNode wird dieser ausgeführt. Die Condition besteht aus zwei oder drei Teilen, je nachdem, ob Vergleichswerte benötigt werden. Definition Case-Conditions Die einzelnen Teile der Conditions werden in dem XML-File eingetragen und durch Semikolons getrennt. Der erste Teil besteht immer aus dem zu überprüfenden Dictionary-Key. Der zweite Teil wird von dem Type-Code der Operation gebildet. Bei Nichtexistenzabfragen muss dann noch im dritten und letzten Teil der Condition der Vergleichswert angegeben werden. Die nachfolgende Tabelle gibt einen Überblick über die möglichen Conditions. BedeutungType-CodeBeschreibungDefined1Fragt auf dem Dictionary ab, ob ein Key existiertNOT Defined2Fragt auf dem Dictionary ab, ob ein Key nicht existiertEquals3Gleichheitsabfrage auf Strings!Equals4Umgekehrte Gleichheitsabfrage auf Strings=5Gleichheitsabfrage auf Integer!=6Verneinte ...<7Integeroperation>8Integeroperation<=9Integeroperation>=10IntegeroperationSwitchDefaultNode Der SwitchDefaultNode wird ausgeführt, wenn keine Condition für einen der SwitchCaseNodes zutrifft. JoinNode Ein JoinNode führt vorher auseinandergegangene Workflows wieder zusammen. Um an einen JoinNode anzuknüpfen, benutzt man einen JumpNode. OnFaultNode OnFaultNodes können in allen Kontexten definiert werden und stellen Eventhandler für Nicht-System-Fehler dar. Das bedeutet, dass die Ausführung durch solch einen fachlichen Fehler nicht mit einer Exception unterbrochen wird, sondern der Workflow einen anderen Weg „einschlägt“. Jeder OnFaultNode besitzt einen Code, über den er angesprochen werden kann. FaultNode Durch die Ausführung eines FaultNodes wird ein Event für die Ausführung des zugehörigen OnFaultNodes ausgelöst. Der Code des FaultNodes muss dabei dem des OnFaultNodes entsprechen. WorkflowContext Der WorkflowContext stellt eine Umgebung für die Ausführung der Workflows bereit. Jeder Workflow muss mindestens einen WorkflowContext enthalten. Zusätzlich kann in jeder ComplexActivity (SequenceNode, OnFaultNode, SwitchCaseNode, SwitchDefaultNode) ein eigener WorkflowContext enthalten sein. Mit den jeweiligen Contexts wird eine Hierarchie aufgebaut. Das bedeutet, dass in jedem aktuellen Context auch die Informationen eines ParentContext abrufbar sind. Zurzeit sind folgende drei Funktionalitäten innerhalb der WorkflowContexts verfügbar. Transaktionen Transaktionen sind bei allen schreibenden Operationen auf Entitäten notwendig (WebLogic ist zusätzlich der Meinung, dass diese auch zum Navigieren über Container-Managed-Relations notwendig sind), um die Datenkonsistenz zu bewahren bzw. sicherzustellen. Da die Granularität der BusinessObjects möglichst hoch sein sollte, reicht es nicht aus, Transaktionen auf einzelne BusinessObjects zu beschränken. Somit erfolgt die Transaktionssteuerung auf Workflowebene. Es ist daher möglich, in einem beliebigen Context eine Transaktion zu starten. Diese Transaktion wird spätestens am Ende der Workflowausführung verarbeitet (commit) oder vorher beim Auftreten einer Exception zurückgesetzt (rollback). Vorgesehen ist weiterhin, dass in naher Zukunft Transaktionen auch durch einen Eintrag im Workflow an bestimmter Stelle verarbeitet werden können. Dies wird notwendig sein, wenn man im gleichen Workflow Daten ausliest, in dem sie angelegt wurden. Properties Um die Dynamik der BusinessObjects weiter zu erhöhen, können in WorkflowContexts Properties angelegt werden, welche aus Key-Value-Paaren bestehen. Diese Parameter werden den BusinessObjects übergeben. Hiermit können die BusinessObjects von außen konfiguriert werden. Hierdurch kann die Anzahl der BusinessObjects drastisch gesenkt werden, wenn zwei Objects ähnliche Aktionen durchführen müssen. Sie werden also parametrisierbar. Faults Die bereits beschriebenen OnFault-Nodes werden in WorkflowContexts deklariert. Das Manager-Konzept Die Komponente Business Logic stellt vier Arten von Basisdiensten zur Verfügung, welche im Rahmen der Ausführung eines Geschäftsprozesses in Anspruch genommen werden: Der erste Dienst stellt Möglichkeiten bereit, die drei Arten von Vertragspartnern (Rechnungssteller, Rechnungsempfänger, Finanzdienstleister) im System zu verwalten. Der zweite Dienst betrifft die Pflege der Rechnungen. Für den Rechnungssteller bietet dieser Dienst die Möglichkeit zur Rechnungsübermittlung, aber auch zur Nachverfolgung und Stornierung bzw. Gutschrift. Der Rechnungsempfänger kann seine Rechnungen einsehen oder zur Zahlung freigeben. Der nächste Dienst befasst sich mit der Verwaltung von Finanztransaktionen. Aufgabe dieses Dienstes ist die Zusammenstellung und Bereitstellung von Transaktionsdaten. Der Rechnungsempfänger kann weiterhin den Status seiner Buchungen verfolgen. Der vierte Dienst stellt das Mahnwesen bereit und übernimmt die Benachrichtigung des Kunden im ersten Schritt per E-Mail. Die Basisdienste werden in Form von Managern bereitgestellt, welche nach dem Singleton-Designpattern entwickelt wurden. Aufgrund des Einsatzes der Manager bleibt der Benutzer der Entitäten in den Business Objects nahezu von der Verwaltung von EntityBeans und dem dafür benötigten Know-How unberührt. Ebenso wenig muss er sich mit SQL auseinandersetzen. Die Unterteilung des Systems in mehrere Komponenten wird hier konsequent fortgeführt. Somit wird es möglich, die verschiedenen Entwickler mit ihren Spezialfähigkeiten strikt zu trennen. Auf unterster Ebene befinden sich die EJB-Entwickler, welche sich am besten mit J2EE-Technologien auskennen müssen. Bei (u.U. anderen) Beteiligten muss Wissen vorhanden sein, wie man EJBs benutzt. Die Business-Objekte werden von Java-Entwicklern implementiert, welche auf die Dienste der Manager zugreifen können. Auf oberster Ebene im Bereich der Komponente Business Logic werden die Geschäftsprozesse – im Idealfall grafisch – entwickelt. Hierfür ist nun kein Wissen über Programmiersprachen mehr notwendig. Die Weiterentwicklung von Com42Bill kann somit klar strukturiert erfolgen. Im Anschluss werden die Subkomponenten kurz erläutert.  Abbildung 7: Teilarchitektur der Komponente Business Logic WorkflowMgr: Der WorkflowMgr wird vom WorkflowAdapter aufgerufen. Dieser hat die Aufgabe, den Geschäftsprozess zu starten und zu überwachen. Zu Beginn des Prozesses wird nach Bedarf eine Transaktion gestartet. Im Anschluss werden die einzelnen Workflow-Nodes ausgeführt. Business Objects: Die Business Objects sind die Komponenten der Business Logic, welche statusbehaftet sein können. Die Business Objects werden im Rahmen eines Geschäftsprozesses referenziert und bilden einen Teil des Prozesses. Sie sind als stateful SessionBeans implementiert. Die Business Objects operieren nun auf den nachfolgend genannten Managern zur Laufzeit eines Geschäftsprozesses. TransactionMgr: Der Transaktionsmanager hat die Aufgabe, neue Transaktionen zu erstellen und deren Verlauf aufzuzeichnen. Beim Abschluss des Geschäftsprozesses muss die Transaktionen entweder komplett verarbeitet werden (commit) oder komplett rückgängig gemacht werden (rollback). Diese Funktionalität wird durch den Applikationsserver zur Verfügung gestellt und ist über die standardisierte Java Transaction API (JTA) und das Java Naming and Directory Interface (JNDI) zugreifbar. BusinessPartnerMgr: Dieser Manager verwaltet die Repräsentationen der Rechnungssteller / Rechnungsempfänger und Finanzdienstleister. Die Kernaufgabe ist das Führen der zugehörigen Konten. InvoiceMgr: Der InvoiceMgr verwaltet alle Vorgänge, welche in Beziehung zur Verarbeitung von Rechnungen stehen. PaymentMgr: Der PaymentMgr stellt Methoden bereit, Finanztransaktionen auf Basis der Entitäten durchzuführen, bzw. deren Durchführung für einen späteren Zeitpunkt zu planen. AlertMgr: Dieser Manager verwaltet das Mahnwesen sowie weitere Benachrichtigungsdienste, wie z.B. Benachrichtigungen über fällige oder neu eingetroffene Rechnungen. JobMgr: Der JobMgr initiiert alle zeitgesteuerten Geschäftsprozesse. Hierzu greift er auf den WorkflowAdapter zu. Der JobMgr hat auch die Möglichkeit, im Anschluss an die Durchführung eines Geschäftsprozesses einen Datenexport zu initiieren. Komponente Datenkonverter Im Rahmen der von Com42Bill angebotenen Dienstleistungen spielt der Austausch von Geschäftsdaten eine entscheidende Rolle. Das System muss Rechnungsdaten vom Rechnungssteller entgegennehmen und Überweisungsaufträge an Finanzdienstleister übermitteln können. Die Herausforderung beim elektronischen Austausch von Daten besteht im Allgemeinen darin, dass diese von beiden Seiten „verstanden“ werden müssen, um sie weiterverarbeiten zu können. Dieses „Verständnis“ wird vom Datenkonverter gewährleistet.  Abbildung 8: Kommunikation von Com42Bill mit anderen Systemen Der Datenkonverter empfängt Rechnungsdaten von einem Rechnungssteller. Da diese jedoch für gewöhnlich nicht in einem standardisierten Format vorliegen, werden sie in ein eigenes Format konvertiert, um die Daten intern weiterverarbeiten zu können. Hierfür muss vor der ersten Übermittlung ein gemeinsames Austauschformat definiert werden. Ein geeigneter Ansatz hierfür ist der ebXML-Standard, der in Kapitel 5.5.1 näher beschrieben wird. Im Weiteren müssen die Daten der von den Rechnungsempfängern veranlassten Buchungen an die Finanzdienstleister übermittelt werden. Hierzu kann der Datenkonverter die Daten in ein Format konvertieren, welches der Finanzdienstleister verarbeiten kann. Die Übermittlung der Daten erfolgt ebenfalls auf der Basis des ebXML-Standards. Bei Bedarf können die Buchungsdaten über einen separaten Konverter in EDIFACT konvertiert und dem Finanzdienstleister bereitgestellt werden (siehe Abbildung 8). Der Datenaustausch erfolgt in beiden Fällen völlig automatisiert. Der Empfang der Rechnungsdaten erfolgt über eine Online-Schnittstelle, d.h. über eine direkte Datenverbindung, so dass die Daten innerhalb des Systems zügig weiterverarbeitet werden können. Welches Transportprotokoll für den Datentransport verwendet wird, ist unabhängig von dem verwendeten Austauschformat. Dadurch kann der Datenaustausch mit Com42Bill einfach an die Erfordernisse eines Rechnungsstellers angepasst werden. Die Buchungsdaten werden dagegen aus Sicherheitsgründen über eine DFÜ-Verbindung an den Finanzdienstleister übermittelt. Der Datenkonverter stellt die Programmschnittstelle zu den Vertragspartnern bereit. Grundlage der Architektur dieser Komponente ist das ebXML-Framework [Ebx02], welches Mechanismen bereitstellt, unabhängig vom verwendeten Datenaustauschformat Dokumente mit Geschäftspartnern auszutauschen. ebXML – eine allgemeine Einführung Die Vereinigten Nationen (UN/CEFACT) und die Organisation für die Förderung Strukturierter Informationsstandards (OASIS) haben in Zusammenarbeit ein weltweites Projekt gestartet: die Electronic Business XML Initiative (ebXML). Das Ziel ist es, ein Rahmenwerk zu definieren, bei dem XML in einer standardisierten Art und Weise für den Austausch elektronischer Geschäftsdokumente verwendet wird. Dieses Rahmenwerk soll die Schaffung konsistenter, robuster und integrationsfähiger eBusiness-Anwendungen ermöglichen und letztendlich dadurch einen einzigen globalen eBusiness-Markt schaffen, auf dem sich Unternehmen jeder Größe und jeder geografischen Lage treffen können. Das Rahmenwerk stellt keine konkreten Implementierungen bereit, sondern beschreibt detailliert die Schnittstellen der einzelnen Komponenten und stellt zahlreiche Informationsmodelle bereit (siehe ebXML-Spezifikationen). Geschäftsprozesse ebXML basiert auf einer geschäftsprozessorientierten Sichtweise. Dabei beschreibt ein Geschäftsprozess detailliert, wie und wann ein Geschäftsteilnehmer bestimmte Rollen einnimmt, welche Verbindungen es zu anderen Geschäftsteilnehmern gibt und welche Verantwortlichkeiten in diesem Zusammenhang auf den einzelnen Geschäftsteilnehmern lasten. Es geht bei der Spezifikation von Geschäftsprozessen nicht darum, zu beschreiben, wie die Dokumente (z. B. Rechnungsdaten) auszusehen haben, die zwischen den Geschäftsteilnehmern ausgetauscht werden. Vielmehr gilt es zu beschreiben, wie die Interaktion zwischen den Geschäftsteilnehmern im Rahmen eines ebXML-Geschäftsprozesses (z. B. Bezahlvorgang) aussieht. Geschäftspartnerprofile Die Zusammenführung von Geschäftspartnern wird unterstützt durch XML Dokumente. Jeder Geschäftspartner, der ebXML nutzen möchte, muss die folgenden Dokumente bereitstellen: Collaboration Protocol Profile (CPP): Ein CPP dient der öffentlichen Bekanntmachung eines Unternehmens. Es beschreibt, welche Geschäftsprozesse, Nachrichtenformate, Kommunikationsschnittstellen etc. ein Unternehmen unterstützt. Auf Basis dieser Informationen können Unternehmen zueinander finden. Wenn ein Unternehmen ein anderes Unternehmen mit einem passenden CPP gefunden hat, können die weiteren Vereinbarungen für die Durchführung elektronischer Geschäftstransaktionen untereinander getroffen werden.  Abbildung 9: Collaboration Protocol Profile (CPP) Collaboration Protocol Agreement (CPA): Die Vereinbarungen zwischen zwei Unternehmen resultieren in einem sog. CPA. Ein CPA ist also ein Vertrag zwischen zwei Geschäftspartnern, in dem die Geschäftstransaktionen sowie die technischen Schnittstellen für einen automatisierten Datenaustausch beschrieben werden. Grundlage für ein CPA sind die beiden CPPs der Geschäftspartner. Ein CPA wird von den Geschäftspartnern manuell erzeugt. Dieser Prozess soll zukünftig durch spezielle Tools vereinfacht werden.  Abbildung 10: Collaboration Protocol Agreement (CPA) Business Process Specification Schema (BPSS): Jedes CPP und CPA ist mit einem BPSS verknüpft. In einem BPSS werden die Geschäftsprozesse der Unternehmen beschrieben. Die ebXML-Registry Die ebXML-Registry ist die zentrale Registrierungsstelle der ebXML-Community. Hier werden sämtliche ebXML-Dokumente der Unternehmen gespeichert. Dies ist also eine Plattform, in der sich Unternehmen über andere Unternehmen informieren und evtl. eine Partnerschaft via ebXML eingehen können. Diverse Realisierungen von ebXML-Registries existieren bereits: Korea (http://www.xeni.co.kr/services/formSearchContent.jsp) Taiwan (http://www.xml.org.tw) Beispielszenario Um einen Überblick über ebXML zu gewinnen, wird im Folgenden ein Beispielszenario betrachtet, in dem die Unternehmen A und B miteinander eine Geschäftsbeziehung eingehen. Zu Beginn dieses Szenarios benutzt Unternehmen B bereits ein ebXML-konformes System, während Unternehmen A noch nicht über ein derartiges System verfügt.  Abbildung 11: Beispielszenario Unternehmen A verfügt noch nicht über ein ebXML-konformes System, möchte aber zukünftig ein solches System nutzen. Daher fragt Unternehmen A in einer ebXML-Registry die nötigen Informationen (Implementierungsdetails, ebXML-Spezifikationen) ab. Unternehmen A plant und implementiert eine eigene ebXML-konforme Anwendung. Dabei ist es nicht unbedingt notwendig, eine Individualanwendung zu erstellen. Vielmehr ist zu erwarten, dass es in Zukunft auch fertige ebXML-Anwendungen von Drittherstellern gibt, die ein Unternehmen nur für die eigenen Belange konfigurieren muss. Um selbst von anderen Unternehmen gefunden werden zu können, muss Unternehmen A ein Unternehmensprofil (CPP) erstellen und in der ebXML-Registry ablegen. Unternehmen B sucht einen geeigneten Geschäftspartner. Es durchsucht daher die ebXML-Registry nach Unternehmen, die die gesuchten Geschäftsprozesse unterstützen. Dabei findet es zum Beispiel Unternehmen A und fordert dessen CPP an. Dieses Profil enthält alle Daten, die Unternehmen B braucht, um die Geschäftsinteressen von Unternehmen A sowie die dafür notwendigen Protokolle feststellen zu können. Unternehmen B sendet nun eine Nachricht an Unternehmen A, in dem es sein Interesse an einer Geschäftsbeziehung mitteilt. Falls auch Unternehmen A an einer Geschäftsbeziehung interessiert ist, muss ein Vertrag (CPA) zwischen den beiden Unternehmen festgelegt werden. Der eigentliche Austausch von ebXML-Geschäftsnachrichten kann beginnen. Beschreibung von Geschäftsprozessen Geschäftsprozesse werden im Rahmen von ebXML durch das Business Process and Information Model (BPIM) beschrieben. Über spezielle Modellierungs-Tools können hier die Geschäftsregeln definiert und erstellt werden. Die Modellspezifikationen stellen somit sicher, dass jede Geschäftsregel von jedem Teilnehmer verwendet und vor allem verstanden werden kann. Die Modellierung erfolgt in UML, anschließend werden die Modelle in XML-Syntax transferiert.  Abbildung 12: Struktur von Geschäftstransaktionen Die Struktur von Geschäftstransaktionen in der ebXML-Welt wird in Abbildung 12 dargestellt. Geschäftstransaktionen (business transactions) sind mit einem Dokumentenfluss (document flow) verknüpft und werden durch eine Choreographie (choreography) in ihrer Abfolge gesteuert. Die Choreographie wird durch eine sog. Collaboration zusammengefasst und von den Geschäftspartnern als solche referenziert. Ein konkreter Ablauf könnte wie folgt aussehen: Zwei oder mehr Geschäftspartner nehmen über Rollen an einer Collaboration teil. Beispiele für Rollen sind „Rechnungssteller” oder „Rechnungsempfänger”. Sie geben die Position wieder, die ein Geschäftspartner innerhalb einer Collaboration einnimmt. Der Datenaustausch erfolgt dabei über Dokumentenflüsse im Rahmen von Geschäftstransaktionen. Durch Choreographien wird schließlich die Reihenfolge, in der diese Geschäftstransaktionen auszuführen sind, definiert. Die einzelnen Begriffe werden im Folgenden nochmals näher erläutert: Collaboration: Eine Collaboration bildet eine Menge von Geschäftstransaktionen und dadurch einen unternehmensübergreifenden Geschäftsprozess ab. Jedem Geschäftspartner wird mindestens eine Rolle in einer Collaboration zugeordnet. Es gibt zwei Arten von Collaborations: Binary Collaborations: es nehmen zwei Geschäftspartner teil. Multiparty Collaborations: es nehmen mehr als zwei Geschäftspartner teil. Multiparty Collaborations werden aus Binary Collaborations „zusammengesetzt”. Geschäftstransaktion: Eine Geschäftstransaktion ist atomar, d. h. sie kann nicht mehr in Unter-Geschäftstransaktionen unterteilt werden. Sie wird zwischen zwei Partnern mit gegensätzlichen Rollen (anfordernde und antwortende Rolle) ausgeführt. Ein weiteres Merkmal von Geschäftstransaktionen ist, dass sie nur als Ganzes entweder erfolgreich sein oder fehlschlagen können. Dokumentenfluss: Ein Dokumentenfluss ist die Realisierung einer Transaktion in Form von Dokumenten, die die Geschäftspartner untereinander austauschen. Dabei gibt es immer ein „Request”-Dokument und optional, falls eine Antwort notwendig ist, auch ein „Response”-Dokument. Choreographie: Die Choreographie legt fest, in welcher Reihenfolge Geschäftstransaktionen innerhalb einer Binary Collaboration ausgeführt werden sollen. In der UML-Ansicht von ebXML-Geschäftsprozessen wird die Choreographie als Aktivitätsdiagramm dargestellt. Messaging-Service Der Messaging-Service stellt im ebXML-Rahmenwerk die Komponente dar, die sich um Transport, Routing & Packaging von Geschäftsdaten kümmert. Im Einzelnen bietet der Messaging-Service folgende Funktionen: Eindeutige Identifikation der Nachricht Bereitstellung von Absender- und Empfängerangaben Angabe von Routing-Informationen, d.h. des nächsten ebXML-Message Service Handlers Signatur der Nachricht zur eindeutigen Identifikation des Absenders und zur Sicherstellung der Unversehrtheit der Nachricht Verschlüsselung der Nachrichten Empfangsbestätigung Fehlerbenachrichtigung  Abbildung 13: Struktur einer ebXML-Nachricht Für die Verpackung der Geschäftsdaten wird eine Erweiterung von SOAP 1.1 (Simple Object Access Protocol), welches ebenfalls auf XML basiert, verwendet (siehe Abbildung 13). Im SOAP Envelope sind lediglich Informationen enthalten, die die Empfänger-Schnittstelle benötigt, um die Nachricht im Rahmen eines Geschäftsprozesses zu identifizieren. Die eigentlichen Geschäftsdaten befinden sich in einem Attachment. Als Attachment kann neben XML jedes beliebige Format gewählt werden, so dass Geschäftsdaten in beliebigen Austauschformaten übertragen werden können. Für die Übertragung der Daten werden die üblichen Übertragungsprotokolle (HTTP, SMTP etc.) verwendet. ebXML – Einsatz bei Com42Bill Die Wahl auf den Einsatz von ebXML fiel aus mehreren Gründen. Zunächst einmal handelt es sich um ein XML-basiertes Framework, welches lediglich den Rahmen spezifiziert, in dem die Daten übertragen werden. EbXML werden zur Zeit hohe Durchsetzungschancen vorausgesagt. Da es sich noch nicht um einen allgemein akzeptierten Standard handelt, ist es für eine Projektgruppe besonders interessant, sich mit dieser neuen Technologie auseinander zusetzen. Eigene Recherchen haben ergeben, dass im Sektor der Finanzdienstleister lediglich Datenträgeraustausch (DTAUS) und EDIFACT eingesetzt wird, woran sich in naher Zukunft auch nichts ändern dürfte. Eine interne Diskussion hat ergeben, dass eine Implementierung einer EDIFACT-Schnittstelle vom Aufwand den Rahmen einer Projektgruppe sprengen würde. Wie bereits in der Seminarphase im Vortrag „SGML-basierter Datenaustausch“ erläutert, gelten individuelle EDIFACT-Anbindungen als sehr teuer und schwer zu handhaben, wodurch sie für viele Rechnungssteller nicht in Frage kommen würden. Aus diesen Gründen wurde beschlossen, zunächst nur einen Austausch auf Basis von ebXML zu realisieren und eine EDIFACT-Anbindung in der Architektur zunächst nur vorzusehen. Die Schnittstellen zu den Geschäftspartnern Aus den o. g. Gründen ließen sich keine realen Geschäftspartner mit einer ebXML-Schnittstelle finden. Um die Schnittstelle des Datenkonverters testen zu können, wurden daher sowohl für den Rechnungssteller als auch für den Finanzdienstleister Dummy-Schnittstellen implementiert. Für jeden Partner wurden die entsprechenden CPPs und daraus hervorgehend die CPAs zwischen Com42Bill und einem fiktiven Rechnungssteller sowie Com42Bill und einem fiktiven Finanzdienstleister erzeugt. Die Dokumente befinden sich im Anhang C. Die unterstützten Geschäftsprozesse Com42Bill unterstützt die folgenden Geschäftsprozesse, die in einem BPSS beschrieben sind. Zwischen Com42Bill und dem Rechnungssteller wird ein Geschäftsprozess ausgeführt, der den Austausch von Rechnungsdaten beschreibt. Hierbei werden mehrere einzelne Geschäftstransaktionen durchgeführt: Der Rechnungssteller sendet Rechnungen oder Stornos zu bereits existierenden Rechnungen. Com42Bill speist diese Daten in sein System ein und sendet dem Rechnungssteller zu jeder empfangenen Rechnung bzw. Storno eine Statusnachricht. Diese Statusnachricht gibt an, ob die empfangenen Daten korrekt verarbeitet wurden oder ob Fehler bei dem Datenimport Fehler aufgetreten sind. Wenn ein Rechnungsempfänger schließlich eine Rechnung bezahlt hat, informiert der Rechnungssteller nach dem Eingang der Zahlung Com42Bill durch eine entsprechende Nachricht. Diese Nachricht wird ebenfalls durch eine Statusnachricht von Com42Bill quittiert. Aufgrund dieser Information vom Rechnungssteller kann der Status einer bezahlten Rechnung bei Com42Bill entsprechend gesetzt werden. Der Geschäftsprozess, der zwischen Com42Bill und dem Finanzdienstleister durchgeführt wird, beschreibt den Überweisungsvorgang. Com42Bill sendet Überweisungen zum Finanzdienstleister. Falls die Überweisungsdaten fehlerhafte Informationen enthalten, wird vom Finanzdienstleister eine Fehlernachricht gesendet. Das BPSS befindet sich in Anhang C. Die unterstützten Datenaustauschformate Die Geschäftsdaten werden bei den Dokumentflüssen jeder Geschäftstransaktion in XML übertragen. Hierzu existiert zu jedem Dokumentfluss ein XML-Schema, welches den Aufbau der Daten vorgibt. Die Erweiterung auf andere Datenaustauschformate ist möglich. Zum einen ist die Architektur des Datenkonverters flexibel gestaltet, so dass andere Formate ohne großen Aufwand integriert werden können. Andererseits ist es auch denkbar, durch einen weiteren vorgeschalteten Datenkonverter, die Daten zwischen dem bereits bestehenden XML-Format und einem andern Format zu konvertieren. Die XML-Schemata sind im Anhang C abgebildet. Architektur  Abbildung 14: Teilarchitektur der Komponente Datenkonverter Der Datenkonverter besteht aus den folgenden Subkomponenten (siehe Abbildung 14). MsgServiceInterface Funktion: Das MsgServiceInterface ist die Schnittstelle für externe ebXML-Applikationen, die mit Com42Bill elektronischen Datenaustausch betreiben möchten. Hier werden ebXML-Nachrichten über den MsgReceiver empfangen und über den MsgSender versendet. Technologie: Hier wurde JAXM 1.1 (Java API for XML Messaging) eingesetzt. Diese API stellt Funktionalitäten zum Generieren und Senden von SOAP-Nachrichten bereit. Der MsgReceiver ist ein JAXM-Servlet. Dieses verwendet einen Listener, der über einen HTTP-SOAP-Channel SOAP-Nachrichten empfangen kann. Der MsgSender ist ein stateless Session Bean und benutzt ebenfalls einen HTTP-SOAP-Channel, um SOAP-Nachrichten zu versenden. MsgServiceHandler Funktion: Hier werden SOAP-Nachrichten verarbeitet. Eingehende Nachrichten werden entpackt und in ihre elementaren Bestandteile zerlegt (Body, Header, Attachment). Aus den einzelnen Bestandteilen werden Informationen, die für den auszuführenden Workflow relevant sind, extrahiert. Das sind z. B. Daten, die zur Authentifizierung benötigt werden, sowie Informationen über den Typ der eingegangenen Nachricht. Umgekehrt werden hier auch ausgehende Nachrichten zusammengesetzt, bevor sie über den MsgSender versendet werden. Technologien: Hier kamen ebenfalls JAXM 1.1 sowie stateful und stateless Session Beans zum Einsatz. BusinessServiceInterface Funktion: Hier wird die Ausführung der ebXML-Geschäftsprozesse kontrolliert. Bei eingehenden Nachrichten werden abhängig vom Typ der Nachricht und des enthaltenen Attachments (Business Document) die Geschäftsdaten aus dem XML Attachment extrahiert und konvertiert und anschließend der entsprechende Workflow bei der Business Logic gestartet. Beim Export von Geschäftsdaten wird entsprechend der zu startende ebXML-Geschäftsprozess initiiert. Zu sendende Daten werden anschließend in ein entsprechendes XML-Attachment konvertiert. Technologien: Zum Einsatz kamen Castor 0.3.9.21 (Open Source Data Binding Framework for Java), JAXM 1.1 sowie stateless Session Beans. CPAParser Funktion: Das CPA, welches als XML-Dokument vorliegt und die relevanten Informationen für die Ausführung eines ebXML-Geschäftsprozesses enthält, wird geparst. Die benötigten Daten werden ausgelesen und an anderer Stelle weiter verwendet. Technologie: Als zentrale Technologie wurde DOM (Document Object Model) eingesetzt, um XML in Java zu konvertieren. ImpExpMgr Funktion: Der ImpExpMgr ist die zentrale Schnittstelle zu den anderen Komponenten des Systems. Die Authentifizierung und Authorisierung bei der Sicherheitskomponente sowie der Im- und Export von Daten in das System erfolgt ausschließlich über diese Schnittstelle. Technologie: Auch diese Schnittstelle wurde als stateless Session Bean implementiert. Komponente Datenbank Die Komponente Datenbank besteht aus zwei Subkomponenten: Einem Datenbankmanagementsystem (DBMS) und einem EJB-Container, über den die Zugriffe auf die Datenbank stattfinden. Die Aufgabe des DBMS besteht in der Speicherung der Daten, die die Arbeitsgrundlage für alle Komponenten des Softwaresystems Com42Bill darstellen. Außer dem EJB-Container hat keine andere Komponente direkten Zugriff auf die Datenbank. Grundsätzlich werden zwei Arten von Daten unterschieden: Globale Daten des Systems, die allen beteiligten Komponenten zur Verfügung stehen sollen, sowie Daten, die dem exklusiven Zugriff einzelner Komponenten des Systems unterliegen. Für alle gilt der Grundsatz der zentralen Datenhaltung. So wird eine komfortable Administration möglich; einfache Datensicherung durch zentrale Backups ist eine weitere Stärke, die hierdurch erreicht wird. Da dem Datenbankmanagementsystem eine relationale Datenbank zugrunde liegt, alle Komponenten jedoch mit Objekten arbeiten, werden die angeforderten Daten in Entity Beans gemappt, welche die Objektrepräsentationen der einzelnen Datensätze/Datenbankviews darstellen. Andersherum wird beim Speichern von neuen Daten eine Abbildung von Objekt in Tabellenstrukturen vorgenommen. Dies bezeichnet man als Objekt-Relationales-Mapping (O/R-Mapping). Auf das Datenbankmanagementsystem wird über eine Java Database Connectivity (JDBC) –Schnittstelle zugegriffen. Somit kann das System leicht auf eine andere Datenbank als die vom Entwicklerteam vorgesehene angepasst werden. Die Komponente Datenbank profitiert maßgeblich vom Einsatz eines J2EE-Applicationservers. Das komplette O/R-Mapping kann mit Hilfe der Container Managed Persistence (CMP) automatisch durchgeführt werden. Des Weiteren muss man sich nicht um die Konsistenz der Daten kümmern, da sowohl die Datenbankmanagementsysteme als auch die Applikationsserver Transaktionsmonitore/-manager besitzen, welche diese Aufgabe übernehmen. Die Wahl beim Datenbankmanagementsystem fiel auf die Version 8i der Oracle – Datenbank. Diese Entscheidung ist hauptsächlich mit der Verbreitung und somit der sehr guten Unterstützung bei den Applicationservern zu begründen. Beim Applicationserver entschied man sich für das Produkt WebLogic 6.1 von der Firma Bea. Hiermit liegt eine stabile und erprobte Version zugrunde, welche sich problemlos in die meisten Entwicklungsumgebungen integrieren lässt. Die Entity-Enterprise Java Beans wurden nach der Version 2.0 der Spezifikation implementiert. Die zwei wesentlichen Neuerungen dieser Version sind zum einen Container-Managed-Relations. Hierbei übernimmt der Container beispielsweise die Verwaltung von m:n-Relationen. Hiermit entfällt das eigenhändige Management der Zwischentabelle. Die zweite Neuerung ist die EJB-Query Language (EJB-QL). Hierbei handelt es sich um eine SQL-ähnliche Abfragesprache, mit dessen Hilfe eigene Finder-Methoden der Home-Interfaces zum ermitteln bestimmter Datensätze geschrieben werden können. Bei der Umsetzung der Komponente bestand durch den Einsatz von EJBs kein großer Gestaltungsspielraum. Das gesamte Objektmodell wurde implementiert und enthält somit bereits einigen Spielraum für Erweiterungen, wie z. B. die Umsetzung der Länderanpassung des Systems. Die einzelnen Bestandteile der Komponente, welche in Abbildung 15 schematisch dargestellt sind, werden abschließend erläutert. Home-Interfaces: Die Home-Interfaces stellen die Lebenszyklusmethoden für die Entity-Beans zur Verfügung. Hiermit ist es möglich, neue Entitäten zu erzeugen, vorhandene aufzufinden und sie letztendlich auch wieder zu entfernen. Entity-Beans: Diese Objekte stellen die Repräsentationen der Datenbankdatensätze/-views dar. O/R-Mapping: Beim Einsatz einer relationalen Datenbank müssen die Attribute des Entity-Beans auf relationale Strukturen abgebildet werden. Diese Aufgabe übernimmt das O/R-Mapping. Connection Pool: Die Verbindungen zwischen EJB-Applikationsserver und Datenbank sollten aus Performanzgründen in einem Pool zur Verfügung gestellt werden. In diesem Connection Pool werden geöffnete JDBC-Verbindungen gehalten, über welche der Applikationsserver mit der Datenbank kommunizieren kann. Die Implementierung erfolgt in der Regel durch den Applikationsserver. DBMS: Das Datenbankmanagementsystem ist die klassische relationale Datenbank.  Abbildung 15: Teilarchitektur der Komponente Datenbank Funktionalität Allgemein Alle Funktionen von Com42Bill werden über eine Web-Schnittstelle bereitgestellt. Das bedeutet, dass die Kommunikation zwischen Benutzern (Betreiber und Rechnungsempfänger) und dem Server, auf dem Com42Bill läuft, über HTML-Seiten und –Formulare stattfindet. Eine Umsetzung auf WML-Seiten für WAP-fähige Mobilgeräte ist in der Architektur vorgesehen, jedoch in dem realisierten System noch nicht umgesetzt. Die einzelnen Anforderungen, die mit dem System umgesetzt werden sollten, können im Zwischenbericht [C42B02_2] dieser Projektgruppe nachgelesen werden. Im Folgenden werden die Funktionen von Com42Bill beschrieben; geplante, aber nicht umgesetzte Funktionen werden im Text erwähnt. Funktionen der Benutzeroberfläche Begrüßung Dem Benutzer werden auf der Begrüßungsseite kurz die Ziele von Com42Bill bekannt gemacht. Über diese Seite hat der Benutzer Zugriff auf alle anderen Elemente von Com42Bill, so kann er sich beispielsweise über das Quick-Login in der rechten Spalte sofort anmelden. Auch die aktuellen Nachrichten und die wichtigsten Punkte der FAQ sind in der rechten Spalte aufgeführt.  Abbildung 16: Begrüßungsseite Die weiteren Seiten von Com42Bill kann der Benutzer über den Menüpunkt MyCom42Bill erreichen. Befindet sich der Mauszeiger über diesem Button, öffnet sich ein Popup-Menü. Durch einen Druck auf den Button selbst kann der Benutzer eine Übersichtseite der Funktionen von Com42Bill erreichen.  Abbildung 17: Popup-Menü Aktuelles Com42Bill hat die Möglichkeit, den Benutzer auf der Seite Aktuelles mit aktuellen Informationen zu versorgen. Hier können zum Beispiel Umstellungen oder Verbesserungen des Systems angekündigt oder bekannt gemacht werden.  Abbildung 18: Aktuelles MyCom42Bill MyCom42Bill ist eine geschützte Seite, für die der Benutzer bereits angemeldet sein muss. Sie bietet einen Überblick über die Funktionen, die in Com42Bill aufgerufen werden können. Außerdem zeigt sie einen Kurzüberblick über die Rechnungen des Benutzers in der rechten Spalte.  Abbildung 19: MyCom42Bill Login Will der Benutzer nicht das Quick-Login benutzen, so kann er auch eine Login-Seite über das Popup-Menü des Com42Bill-Buttons aufrufen. Nach einem erfolgreichen Login wird der Benutzer direkt zur Übersichtsseite MyCom42Bill weitergeleitet.  Abbildung 20: Login Rechnungsübersicht Die Rechnungsübersicht bietet dem Benutzer Kontrolle über seine Rechnungen. Mittels der Suchfunktion kann er sich nur gewünschte Rechungen anzeigen lassen. Die Übersicht zeigt den Rechnungsstatus, die Fälligkeit und den Rechnungssteller.  Abbildung 21: Rechnungsübersicht Mittels des Buttons in der Spalte „Zahlen?“ kann er jede offene Rechnung zum Rechnungskorb hinzufügen oder aus diesem entfernen. Rechnungen im Rechnungskorb sind zur Bezahlung vorgemerkt. Den Bezahlvorgang selbst kann der Benutzer über den Button „Bezahlen“ unter den Rechnungen starten. Bezahlvorgang Der Bezahlvorgang läuft in mehreren Schritten ab. Zunächst wird dem Benutzer der Rechnungskorb gezeigt, also die Rechnungen, die zur Bezahlung vorgemerkt wurden. Diese Rechnungen können in dieser Übersicht auch noch entfernt werden, um sie nicht mit diesem Bezahlvorgang zu begleichen. Durch den Button „Zurück“ kann der Benutzer in den Schritten des Bezahlvorganges jederzeit auf die vorherige Seite gelangen bzw. den Bezahlvorgang abbrechen.  Abbildung 22:Bezahlvorgang – Schritt 1 Im nächsten Schritt wählt der Benutzer die gewünschte Bezahlungsmethode aus. Er kann unter allen Bezahlmethoden wählen, die er in Com42Bill konfiguriert hat. Zusätzlich kann er noch einen späteren Zeitpunkt für die Bezahlung durch die Datumseingabe festlegen.  Abbildung 23: Bezahlvorgang – Schritt 2 Nach der Wahl des Bezahlvorgangs erfolgt die Bestätigung der Bezahlung durch den Knopf „Bezahlen“. Der Benutzer bekommt zur Bestätigung eine entsprechende Meldung des Systems, dass sein Auftrag gemäß seiner Angaben ausgeführt wird.  Abbildung 24: Bezahlvorgang – Bestätigung Persönliche Daten Auf dieser Seite wird dem Benutzer die Möglichkeit gegeben, seine persönlichen Daten zu ändern, also das Passwort, die Anschrift und ähnliche Informationen.  Abbildung 25: Persönliche Daten ändern Zahlungsweise ändern Hier kann der Benutzer seine Konten verwalten. Er kann neue Konten anlegen, die dann für den Bezahlvorgang zur Verfügung stehen, Konten löschen oder auch Kontoinformationen überarbeiten.  Abbildung 26: Zahlungsmethode ändern In dem Dialog für das Anlegen bzw. Editieren der Zahlungsmethode kann der Benutzer die Art des Kontos angeben und die zugehörigen Informationen des Kreditinstituts. Vorgesehen waren unterschiedliche Arten von Konten für die Bezahlung, also zum Beispiel Kreditkarten, umgesetzt wurden im Laufe des Projekts aber vorerst nur Bankkonten.  Abbildung 27: Kontodaten ändern Logout Durch den Aufruf der Seite Logout meldet sich der Benutzer explizit ab. Seine derzeitige Anmeldung wird für ungültig erklärt und die geschützten Bereiche sind ab jetzt nicht mehr zugänglich. Für die erfolgreiche Abmeldung erhält er auf dieser Seite eine Bestätigung.  Abbildung 28: Logout Registrierung Neue Benutzer, die sich bei Com42Bill anmelden wollen, müssen sich für den Dienst registrieren. Die Registrierung läuft in mehreren Schritten ab. Zunächst wird dem Benutzer der Registriervorgang erklärt.  Abbildung 29: Registriervorgang – Erklärung Danach wird nach den persönlichen Daten verlangt, also Name, Anschrift und Kontaktinformationen.  Abbildung 30: Registriervorgang – Persönliche Daten Als nächstes wählt der Benutzer einen Login-Namen und ein Passwort aus. Sollte der Login-Name bereits vergeben sein, so kann er die Seite nicht mittels der Bestätigung verlassen und muss erst einen anderen Namen eingeben. Zusätzlich kann er auswählen, ob und wie er über eingehende Rechnungen informiert werden möchte.  Abbildung 31: Registriervorgang – Wahl des Logins Im dritten Schritt muss eine Zahlmethode eingegeben werden, damit der Benutzer für eingehende Rechnungen Bezahlvorgänge abwickeln kann.  Abbildung 32: Registriervorgang – Kontoinformationen eingeben Vor der abschließenden Bestätigung der Registrierung werden nochmals alle eingegebenen Daten zur Kontrolle angezeigt. Wenn der Benutzer Fehler entdeckt, so können diese durch ein Korrigieren in den vorhergehenden Schritten des Registriervorganges behoben werden. Diese Seiten kann der Benutzer über den Zurück-Button erreichen.  Abbildung 33: Registriervorgang - Kontrollansicht Abschließend wird dem Benutzer die erfolgreiche Registrierung bestätigt. Support Auf der Seite Support werden dem Benutzer Kontaktinformationen für eventuell benötigte Hilfe angezeigt. Zusätzlich wird auf die FAQ-Seiten von Com42Bill verwiesen, auf denen der Benutzer eventuell bereits die Antworten zu seinen Fragen finden kann.  Abbildung 34: Support Frequently Asked Questions Auf dieser Seite werden häufig gestellte Fragen und deren Antworten präsentiert. Auf diese Weise kann der interessierte Benutzer sich selbst über häufig erfragte Funktionen und Eigenschaften von Com42Bill informieren.  Abbildung 35: FAQ Impressum Das Impressum stellt in Kurzform die Projektgruppe 411 vor. Neben dem Zeitraum der Entwicklung werden die Ziele und gewünschten Ergebnisse der Projektgruppe vorgestellt. Bei einem „Echteinsatz“ würde hier das nach §6 Teledienstegesetz (TDG) geforderte Impressum stehen [TDG02]. Kontakt Auf der Kontaktseite findet man Informationen zu den Betreuern der Projektgruppe sowie die Emailadresse der Entwicklergruppe von Com42Bill. Funktionen der Administrationsoberfläche Begrüßung Um die Administrationsfunktionen optisch deutlich von der Benutzeroberfläche zu trennen, ist die Administrationsoberfläche komplett in grün gehalten. Um dennoch einen Widererkennungseffekt zu erreichen, entspricht das Design der Seite im Wesentlichen dem der Benutzerseite. Zunächst muss sich der Administrator anmelden:  Abbildung 36: Anmeldung für den Administrator In der vorliegenden Version gibt es nur einen administrativen Benutzer, Benutzername ist „Administrator“. Weitere administrative Benutzer mit eingeschränkten Rechten sind zwar vorgesehen, aber nicht realisiert, da die Pflege von Benutzergruppen und –rechten nicht umgesetzt wurde. Die Begrüßungsseite für den Administrator sieht wie folgt aus:  Abbildung 37: Begrüßungsseite für den Administrator Der prinzipielle Aufbau entspricht dem der Benutzeroberfläche. Die gewünschte Aktion bzw. der zu administrierende Teilbereich wird auf der linken Seite ausgewählt. In der aktuellen Version teilt sich der Administrationsbereich in acht Teilbereiche. Aktuelles Auf dieser Seite können die Nachrichten bearbeitet werden, die dem Benutzer (Rechnungsempfänger) in der rechten Spalte der Benutzeroberfläche angezeigt werden.  Abbildung 38: Administrationsseite "Aktuelles" Im oberen Bereich kann eine neue Nachricht eingegeben werden. Ein Klick auf „Speichern“ speichert die neue Nachricht. Im unteren Bereich werden die vorhandenen Nachrichten angezeigt. Zu jedem Artikel gibt es einen zugehörigen Link „Diesen Artikel löschen“. FAQ Der FAQ – Bereich der Benutzeroberfläche soll dem Rechnungsempfänger Hilfestellungen bei der Bedienung von Com42Bill geben. Zunächst gelangt der Administrator zu einer Übersicht aller bereits vorhandenen Artikel:  Abbildung 39: FAQ-Übersicht Über die entsprechenden Links können die einzelnen FAQ-Artikel editiert und gelöscht werden. Über den Link „Eine neue FAQ anlegen“ gelangt man zu einem Eingabeformular für FAQs, das im Wesentlichen wie das zum Bearbeiten einer FAQ aussieht:  Abbildung 40: FAQ editieren Wie in allen anderen Formularen auch, gelangt der Administrator durch Klick auf „Abbruch“ wieder zu der Übersicht, ein Klick auf „Speichern“ speichert die gemachten Eingaben. Benutzer Zunächst landet der Administrator auf einer Übersichtsseite, auf der der zu bearbeitende Benutzer ausgewählt werden kann:  Abbildung 41: Benutzerauswahl Die Löschung wird direkt von dieser Seite ausgelöst. Zum Editieren gelangt der Administrator auf folgende Seite:  Abbildung 42: Benutzer editieren Alle wesentlichen Daten zu dem Benutzer können hier bearbeitet werden. Ein Klick auf „Abbruch“ bringt den Administrator zurück zur Übersicht, ein Klick auf „Speichern“ speichert die vorgenommenen Änderungen. Im unteren Bereich der Seite kann ein Konto des Rechnungsempfängers ausgewählt werden:  Abbildung 43: Kontenauswahl Die Kontodaten können auch geändert werden:  Abbildung 44: Konto editieren Vorgesehen waren Bankkonten und Kreditkarten; realisiert wurde nur die Eingabe von Bankkonten. Die Neuanlage eines Bankkontos ist hier nicht vorgesehen; dies kann nur der Benutzer selbst. Rechnungssteller Da die Rechnungssteller, anders als die Rechnungsempfänger, keine eigene Oberfläche haben, um Ihre Daten zu ändern, gelangt man hier zu der einzigen Stelle, an der die Daten von Rechnungsempfängern bearbeitet werden können. Zunächst wird man wie bei den Benutzern auf eine Übersichtsseite geführt:  Abbildung 45: Rechnungssteller auswählen Ein Rechnungssteller kann nicht gelöscht werden. Wird ein Rechnungssteller vom System ausgeschlossen, wird dieser gesperrt (siehe folgenden Abschnitt). Die Löschung eines Rechnungsstellers ist eine kritische Angelegenheit, da Zahlungsverkehrsdaten einige Jahre aufbewahrt werden müssen; des weiteren ist unklar, wie lange nach der letzten Rechnung noch Reklamationen möglich sein müssen. Daher haben wir auf eine endgültige Löschung eines Rechnungsstellers verzichtet. Zu jedem angelegten Rechnungssteller gibt es einen Link „Editieren“, der zu der Bearbeitungsseite für Rechnungssteller führt:  Abbildung 46: Rechnungssteller editieren Durch die Checkbox „Aktiviert“ kann ein Rechnungssteller, wie bereits erwähnt, gesperrt werden. Im unteren Bereich des Formulars kann ein Finanzkonto zur Bearbeitung ausgewählt werden. Dieser Bereich sieht aus wie beim Rechnungsempfänger (vgl. Abbildung 43). Auch hier können derzeit nur Bankkonten eingegeben werden (das Formular zur Neuerfassung sieht genauso aus; daher wird auf eine Abbildung verzichtet).  Abbildung 47: Finanzkonto editieren Banken Die Daten aller Banken in Deutschland wurden in die Datenbank importiert. Ein Ablauf zur Pflege der Bankdaten wurde nicht implementiert, da die Änderungen von der Deutschen Bank in einem festgelegten Format herausgegeben werden und daher leicht importiert werden können. Rechnungen Da der Betreiber eines Systems, das hauptsächlich auf Kundenaktionen basiert, in jede Aktion eingreifen können muss, gibt es einen Bereich zur Administration der Rechnungen. Diese können über die folgende Maske gesucht werden:  Abbildung 48: Rechnungen suchen Weitergehende Funktionen sind hier nicht vorhanden. Bei einem Echteinsatz muss der Betreiber an dieser Stelle die Möglichkeit haben, in Rechnungsvorgänge einzugreifen bzw. sich weitere systeminterne Details zu Zahlungsvorgängen anzusehen. Jobs Hier können regelmäßig auszuführende Arbeitsabläufe angelegt und bearbeitet werden. Der prinzipielle Aufbau ist wie bei der Benutzerkonfiguration oder der Rechnungsstellerkonfiguration:  Abbildung 49: Jobübersicht Hier kann ein Job sofort gestartet werden (für wiederkehrende Jobs, die jedoch nicht regelmäßig ausgeführt werden). Diese Funktion ist bislang lediglich vorgesehen; ein Sofortstart von Jobs ist derzeit nicht möglich. Außerdem kann der Job hier gelöscht werden. Ein Klick auf „Editieren“ bringt den Administrator zu folgendem Formular:  Abbildung 50: Job konfigurieren Alle Angaben, die für einen Job relevant sind, werden hier erfasst. Des Weiteren können auf dieser Seite Zusatzinformationen eingesehen werden, hier z.B. das Datum der letzten Ausführung sowie die Dauer der letzten Ausführung. Berichte Aus Zeitgründen wurde auf eine Implementierung von Statistik- und Berichtsfunktionen verzichtet.  Abbildung 51: Berichte Das Datenmodell Das Objektmodell umfasst alle persistenten Daten des Systems, die durch Entity Beans abgebildet werden. Das System enthält auch viele Klassen, die nicht auf der Datenbankebene abgebildet werden. Diese Klassen werden daher im Objektmodell nicht dargestellt. Um einen strukturierten und umfassenden Überblick über das Objektmodell von Com42Bill zu geben, wird zunächst die Package-Struktur des Systems dargestellt. Sie entspricht dem Package-Aufbau des bestehenden Together-Projektes. Das Objektmodell setzt sich aus der Summe der Diagramme aller Packages zusammen. Ein Package kann weitere Packages oder Klassen enthalten. Packages bilden also Gruppierungen für funktional zusammengehörige Klassen. Die Package-Struktur kann mit einer Baumstruktur verglichen werden, wobei jede Klasse ein Blatt ist. Die Komponenten des Systems werden zunächst durch Packages grob dargestellt. Eine verfeinerte Darstellung erfolgt dann auf Klassenebene. Der Begriff Package wird in diesem Dokument folgenderweise verwendet: Ein Sub Package ist immer ein Bestandteil eines übergeordneten Packages. Ein Sub Package ist ebenfalls ein Package. Der Begriff Package ist der Oberbegriff und wird synonym für Sub Packages verwendet. Der Begriff Sub Package wird nur dann explizit verwendet, wenn auf die spezielle Eigenschaft des betroffenen Packages als Bestandteil eines übergeordneten Packages hingewiesen werden soll. Zu jedem Package existiert ein Diagramm, welches die zu diesem Package gehörenden Entity Beans beinhaltet. Die Methoden der Entity Beans sind in den Diagrammen der Übersichtlichkeit halber ausgeblendet. Die ausgeblendeten Bereiche sind bei jedem Entity Bean-Symbol am unteren rechten Rand durch kleine Symbole gekennzeichnet (vgl. Abbildung 55). Entity Beans haben häufig Relationen zu Entity Beans aus anderen Packages. Um die Funktion eines Packages im systemweiten Kontext erschliessen zu können, werden in einigen Diagrammen zur Beschreibung eines Packages auch Entity Beans aus fremden Packages abgebildet. Letztere werden dabei als Link dargestellt. Ein Link wird durch ein Pfeil-Symbol an der unteren Kante des entsprechenden Entity Bean-Symbols gekennzeichnet. Zur Darstellung des Objektmodells wurden Teile der UML-Modellierung in Together 6.0 herangezogen, die insbesondere bei den Beschriftungen in der Package-Notation nicht mit UML 1.4 konform ist. Ein wichtiges Merkmal des Objektmodells ist die fehlende Vererbung bei den Entity Beans: auf diese muss verzichtet werden, da Vererbung bei Entity Beans der EJB 2.0-Spezifikation nicht unterstützt wird. Im Folgenden wird das Objektmodell für Com42Bill genauer erläutert: Abbildung 52 zeigt die grobe Darstellung der hierarischen Together-Projekt-Struktur: Das Super Package de bzw. Com42Bill enthält die beiden Packages ebppsystem und components, die beide wiederum Sub Packages enthalten. Diese werden in den folgenden Kapiteln detailiert beschrieben. Die Relation zwischen den beiden Packages ebppsystem und components repräsentiert Beziehungen zwischen den persistenten Entitäten dieser beiden Packages.  Abbildung 52: Grobe Package-Struktur des Systems Das Package ebppsystem bildet den zentralen Teil des Objektmodells. Hier sind alle allgemeinen Entity Beans enthalten, auf denen alle Komponenten arbeiten, so wie speziell für die Komponente Business Logic bestimmte Entity Beans. Entity Beans, die jeweils nur von den übrigen Komponenten benutzt werden, sind im Package components zusammengefasst.  Abbildung 53: Struktur des Package ebppsystem Wie Abbildung 53 zeigt, enthält das Package ebppsystem die fünf Sub Packages businesspartner, invoice, payment, alert und core. Diese sind an mehreren Punkten miteinander verknüpft. Die durch Pfeile dargestellten Abhängigkeiten korrespondieren mit den Assoziationen der Entity Beans, die in den unterschiedlichen Sub Packages von ebppsystem enthalten sind. Eine wichtige Rolle spielt das Package core: es enthält hauptsächlich nicht-fachliche Entity Beans, welche Funktionalitäten des Frameworks bereitstellen. Das Package invoice enthält alle Entity Beans, die zur Abbildung einer Rechnung benötigt werden. Eine Rechnung wird von einem Rechnungssteller an Com42Bill übermittelt. Mahnungen (im Package alert abgebildet) werden vom System generiert. Rechnungssteller und Rechnungsempfänger werden innerhalb des Package businesspartner abgebildet. Daher bestehen zwischen diesen drei Packages direkte Beziehungen. Weiterhin ist die Zahlung, die im Package payment modelliert wird, mit der Modellierung der Rechnung verknüpft.  Abbildung 54: Package-Struktur des Sub Package core Eine zentrale Rolle spielt das Package core: Dieses Sub Package von ebppsystem enthält Entity Beans, die von allen Komponenten des Systems benötigt werden. In den Entity Beans dieses Packages werden Konfigurationsdaten sowie nicht-fachliche Daten, die zum Betrieb des Systems notwendig sind, gespeichert. Eine Übersicht zu diesem Package gibt Abbildung 54. Zu beachten ist, dass außer den dargestellten Relationen keine sonstigen Relationen zwischen den Packages bestehen. Durch das Entity Bean des Package user werden die Benutzer (User) abgebildet, die mit dem System in Online-Verbindung stehen. Die auf den Workflow bezogene Job-Verwaltung wird durch die Entity Beans des Package job abgebildet. Hier werden Informationen über die auszuführenden Jobs sowie über den Ausführungszeitpunkt gespeichert. Die Geschäftsprozesse der Komponente Business Logic werden durch das Package Workflow repräsentiert. Die Entity Beans des Sub Packages common stehen allen Komponenten des Systems zur Verfügung und stellen die systemweiten Informationen bereit. Die Struktur von common wird in Abbildung 55 dargestellt.  Abbildung 55: Struktur des Package common Das Entity Bean URLConfigurationBean dient der Bereitstellung von Einstiegsadressen für Benutzergruppen des Systems. Dieses Entity Bean dient der Angabe zusätzlicher URLs zur SSL-Verschlüsselung, welche durch das System selbst generiert werden können. Das Entity Bean LocaleBean unterstützt die Umsetzung der Länderanpassung des Systems. Diese Funktionalität wurde nicht implementiert. In dem Entity Bean RegistryBean werden Dienste und Funktionseinheiten des Systems zentral registriert. In dem Entity Bean CurrencyBean werden Währungseinstellungen hinterlegt.  Abbildung 56: Struktur des Package job Die auf den Workflow bezogene Job-Verwaltung wird durch die Entity Beans des Sub Package job modelliert. In dem Entity Bean JobConfigurationBean werden Einstellungen zur Ausführung eines Workflows hinterlegt: Eine JobConfiguration stellt ein zeitgesteuertes Ereignis dar, mit dem ein Workflow gestartet wird. Das Entity Bean JobTimerBean dient der Zeitsteuerung der Workflow-Ausführung.  Abbildung 57: Struktur des Package user Durch das im Sub Package user enthaltene Entity Bean UserInformationBean werden die Benutzer (User) abgebildet. UserInformationBean wird von der Komponente Sicherheit zur Unterstützung der Authentifizierung und Zugriffssteuerung benötigt. Die Struktur dieses Package wird in Abbildung 57 dargestellt. Die n:m Beziehung zwischen GroupBean und UserInformationBean wird bei der Beschreibung des Package security näher erläutert (vgl. Abbildung 65).  Abbildung 58: Struktur des Package workflow Das Entity Bean WorkflowEntryBean repräsentiert die Geschäftsprozesse der Komponente Business Logic. Einem Geschäftsprozess können mehrere Startpunkte zugeordnet sein, hier repräsentiert durch das Entity Bean WorkflowStartNodeEntryBean. Über dieses Bean wird durch die Komponente Sicherheit festgelegt, ob dieser Geschäftsprozess durch den aktuell angemeldeten Benutzer ausgeführt werden darf.  Abbildung 59: Struktur des Sub Package alert Sind mehrere Rechnungen fällig bzw. sind mehrere Mahnungen vorhanden, werden diese in einer Liste zusammengefasst. Diese Liste wird durch AlertListBean dargestellt. Es gibt zwei Ausprägungen des Zahlungshinweises: Erinnerung (InvoiceReminderBean) und Mahnung (PaymentWarningBean), die je nach Dauer des Zahlungsverzugs eingesetzt werden können. Mehrere Zahlungshinweise sind einem Rechnungsempfänger und einer Rechnung zugeordnet.  Abbildung 60: Struktur des Sub Package businesspartner In dem Package businesspartner sind durch die Entity Beans InvoicingPartyBean und InvoiceRecipientBean die Rollen Rechnungssteller und Rechnungsempfänger modelliert. Zusammen mit dem Entity Bean FinancialServiceProviderBean repräsentieren sie alle beteiligten Rollen innerhalb eines Workflows der Business Logic (können aber auch von anderen Komponenten außerhalb eines Workflows verwendet werden). Ihre Kontaktdaten werden durch die beiden Entity Beans PersonDataSheetBean und CompanyDataSheetBean dargestellt. Diese Entity Beans entsprechen den unterschiedlichen Anforderungen, die Informationen zu Firmen und privaten Einzelpersonen mit sich bringen. Die benötigten Adressinformationen werden durch AddressBean repräsentiert. Die Entity Beans der Rechnungssteller und Rechnungsempfänger können zu Profilgruppen (ProfileGroupBean) zusammengefasst werden. Die Profilgruppen können z.B. als Zugriffsrechte benutzt werden. Das Entity Bean FinancialAccountBean repräsentiert die Finanzkonten der beteiligten Rollen, über die die Zahlungsvorgänge abgewickelt werden. Das Entity Bean FinancialAccountAttributesBean dient der weiteren Spezifizierung des FianancialAccountBean, z.B. Angabe von Kreditkarteninformationen. Durch das IncrementBean lassen sich die laufenden Nummern für Rechnungssteller, Rechnungsempfänger, Rechnungen, Finanzdienstleister und Transaktionen generieren.  Abbildung 61: Struktur des Sub Package invoice Mit den Entity Beans des Package invoice werden die Rechnungen modelliert. Seine Klassenstruktur wird in Abbildung 61 dargestellt. Das zentrale Entity Bean – InvoiceBean – repräsentiert Rechnungen. Mit dem InvoiceLinkBean können Beziehungen zwischen mehreren Rechnungen hergestellt werden. InvoiceTypeBean legt den Typ der Rechnungen fest.  Abbildung 62: Struktur des Package payment Der Zahlungsvorgang wird im Package payment modelliert, hier dargestellt in Abbildung 62. Das InvoiceContainerBean  dient ähnlich einem Warenkorb der Gruppierung von Rechnungen, welche zusammen bezahlt werden sollen. Eine thematische Gruppierung kann (optional) über InvoiceTypeBean erfolgen. Die Transaktionsdaten werden in dem Entity Bean PaymentTransactionBean abgebildet, die Zahlungsweise dagegen in PaymentMethodBean. Zahlungen werden durch das Entity Bean PaymentTransactionListBean zusammengefasst.  Abbildung 63: Package-Struktur des Package components Wie in Abbildung 52 bereits dargestellt, enthält das Objektmodell des Systems neben dem Package ebppsystem ein weiteres Package components mit zentraler Bedeutung. In dem Package ebppsystem werden neben den allgemeinen auch die Entity Beans der Komponente Business Logic modelliert. In dem Package components sind die spezifischen Entity Beans der übrigen Komponenten enthalten (die Komponente Datenkonverter benötigt keine eigenen Entity Beans). Eine strikte Trennung der Komponenten wird dabei durch die weitere Unterteilung in die Sub Packages security und gui vorgenommen (siehe Abbildung 63). Die Entity Beans dieser Sub Packages hängen mit denen der Komponente Business Logic zusammen, jedoch existieren keine anderen Relationen zwischen den Sub Packages von components.  Abbildung 64: Struktur des Package gui Die Entity Beans der Komponente GUI werden im Package gui zusammengefasst (siehe Abbildung 64). Gespeichert werden die Artikel für den Abschnitt „Mein Orakel“ auf der Hauptseite (News) (siehe Kapitel 6.2.1) sowie Hilfestellungen für den Umgang mit Com42Bill (FAQ). Die Speicherung von Hilfetexten ist vorgesehen, aber nicht implementiert.  Abbildung 65: Struktur des Package security Das Package security wird in Abbildung 65 dargestellt. Hier werden die Entity Beans modelliert, die zur Verwaltung der Zugriffrechte benötigt werden. In UserInformationBean (Package de.Com42Bill.ebppsystem.core.user) werden die nicht-fachlichen Benutzerdaten gespeichert. Mehrere Benutzer können in einer Gruppe enthalten sein. Außerdem kann ein Benutzer mehreren Gruppen zugeordnet werden. Eine Gruppe entspricht einer Benutzergruppe, die den darin enthaltenen Benutzern die Ausführung bestimmter Workflows erlaubt. Zwischen GroupBean und WorkflowStartNodeEntryBean besteht ebenfalls eine n:m Beziehung. Jeder Gruppe können mehrere Workflows zugeordnet werden. In umgekehrter Richtung kann jeder Workflow mehreren Gruppen zugeordnet werden. Dieser Aufwand ermöglicht eine sehr variable Rechteverwaltung. Bei der Modellierung von n:m Beziehungen zwischen Entity Beans müssen in Together 6.0 für beide betroffenen Entity Beans Assignment-Tabellen definiert werden. Eine Assignment-Tabelle besteht aus zwei Spalten, die für die Primärschlüssel der beiden Entity Beans vorgesehen sind. Das Eintragen der Primärschlüssel in die Assignment-Tabellen wird während des Deployments vom Applicationserver übernommen. Hard- & Software Infrastruktur Das System Com42Bill wird in Java auf Basis der Spezifikation der Java 2 Enterprise Edition (J2EE) in der Version 1.3 entwickelt, da sich der Einsatz dieser Technik gerade im Bereich des e-Business bereits vielfach bewährt hat. Die Entwicklung findet in einer Windows-Umgebung statt. Der Domänencontroller ist ein Intel Celeron 1GHz Rechner, auf welchem das Betriebssystem Microsoft Windows 2000 Server installiert ist. Alle benötigten Serverdienste werden von diesem Rechner bereitgestellt. Die Klienten sind ebenfalls Intel Celeron 1 GHz Rechner und werden mit Microsoft Windows 2000 Professional betrieben. Damit stehen zur Entwicklung typische Arbeitsumgebungen zur Verfügung, da zu einem Großteil private PCs mit Microsoft Windows Betriebssystemen genutzt werden. Die Softwareentwicklungsumgebung ist das Together ControlCenter von TogetherSoft in der Version 6. Dadurch ist es möglich, das System vollständig in einer Entwicklungsumgebung zu entwickeln. Durch die Unterstützung von UML steht ein standardisiertes und effizientes Hilfsmittel bei der Entwicklung zur Verfügung, welches es erlaubt, die einzelnen Entwicklungsschritte grafisch und verständlich darzustellen. Die Dateien werden in einem CVS-System verwaltet. Hier kommt auf dem Server CVSNT zum Einsatz. Die Klienten benutzen WinCVS bzw. das Together ControlCenter zum Abgleich der Dateien mit den Versionen des Servers. Dies ermöglicht eine unkomplizierte Verwaltung sämtlicher Dokumente und aller anderen anfallenden Dateien, so dass jeder, der an der Entwicklung beteiligt ist, jederzeit die aktuellsten Informationen zur Hand hat. Zur Präsentation der Projektgruppe nach Außen wird der in Windows 2000 Server integrierte IIS-Dienst genutzt. Dieser unterstützt die von unserer Homepage geforderten Techniken. Darüber hinaus ist die Anmeldung an den internen Bereich der Homepage direkt mit der Anmeldung an der Domäne verbunden, so dass hier keine zusätzlichen Passworte notwendig werden und der Nutzungskomfort deutlich erhöht werden kann. Installation Welche Software für den Betrieb von Com42Bill benötigt wird, ist nicht vollständig vorgeschrieben. Als Grundlage für den Betrieb von Com42Bill dient der Applicationserver Weblogic 6.1 SP 3 der Firma Bea. Dadurch ist Com42Bill weitgehend unabhängig von der Wahl der Datenbank. Diese muss lediglich eine korrekte Anbindung an Weblogic bieten. Für die Entwicklung fiel die Entscheidung auf Oracle 8. Für eine möglichst einfache Konfiguration wird die Installation dieser Software in deren Standardverzeichnisse empfohlen. Bevor mit der Installation von Com42Bil begonnen wird, muss die zu Grunde liegende Software installiert und konfiguriert werden. Eine neue Installation eines auf Windows NT basierenden Serverbetriebssystems ist als Grundlage zu empfehlen. Es sollte zuerst die Datenbank und anschließend der Applicationserver installiert werden. Handelsübliche Datenbanken unterstützen eine Vielzahl von Parametern, um sie optimal auf die erwartete Auslastung einzustellen. Für die Entwicklung wurde Oracle auf minimale Ressourcennutzung konfiguriert, da nicht mehr als 10 - 20 gleichzeitige Verbindungen zu erwarten waren. Für den Produktiveinsatz muss die Konfiguration entsprechend der erwarteten Zugriffe angepasst werden. Genauere Informationen zur Konfiguration der Datenbank sind in deren Dokumentation verfügbar. Wichtig ist, dass ein Datenbankbenutzer angelegt wird, der anschließend von Weblogic für den Zugriff auf die Datenbank genutzt wird. Es ist davon abzuraten, für diesen Zweck einen Datenbankadministrator zu benutzen. Der Anfangsdatenbestand wird auf der Installations-CD von Com42Bill mitgeliefert und kann direkt in die Datenbank importiert werden. Die Installation von Bea Weblogic sollte ohne die mitgelieferten Beispiele erfolgen. Die einzurichtende Domain soll cbdomain heißen, da die Konfigurationsskripte von Weblogic auf diese Domain zugeschnitten sind. Nun sollte das Verzeichnis „Konfiguration“ von der Com42Bill-CD auf die Partition C: der Server-Festplatte kopiert werden. Wurden die Programme in die Standardpfade installiert, ist die Installation damit auch fast abgeschlossen. Ansonsten müssen die Pfade in den kopierten Dateien entsprechend angepasst werden. Die Dateien, die auf der CD im Verzeichnis y zu finden sind, müssen auf eine Partition oder Freigabe kopiert werden, die über den Laufwerksbuchstaben Y: eingebunden wird. Bei der Konfiguration von Weblogic ist zu beachten, dass in den jeweiligen Einstellungen der aktuelle Server im Tab „Target“ ausgewählt wird, da erst dann die Einstellungen wirksam werden. Die Konfigurationskonsole ist über http://localhost:7001/console erreichbar. Zuerst sollte hier die Startklasse de.Com42Bill.ebppsystem.core.server.StartupCore im Bereich Startup & Shutdown eingetragen werden. Hierdurch werden grundlegende Initialisierungen bei jedem Serverstart durchgeführt. Über die Konfigurationskonsole müssen als Nächstes ein JDBC Connection Pool und eine JDBC Tx Data Source eingerichtet werden. Der Namensvorschlag für diese Einträge ist CbConnectionPool. Anschließend muss eine Mail-Session eingerichtet werden. Diese dient zum automatischen Versenden der Emails von Com42Bill. Als letzten Schritt vor der eigentlichen Installation von Com42Bill muss JMS konfiguriert werden. Es werden die Komponenten Connection Factory, Store und Server benötigt. Vorgesehene Namen hierfür sind CBJMSConnectionFactory, JMSFileStore und CBJMSServer. Nun kann mit Hilfe der Konfigurationskonsole die Installation der Applikation beginnen. Als Applikation wird die Datei „Com42Bill.ear“ von der beiliegenden CD ausgewählt. Anschließend wird die Web Application GUIServlets als Standardservlet eingerichtet. Dies kann im Bereich „Servers“ vorgenommen werden. Weblogic lässt neben der Kommunikation über HTTP auch die Kommunikation über HTTPS zu. Hier ist Port 7002 vorkonfiguriert. Für die Nutzung von Com42Bill sollte aus Sicherheitsgründen nur die Kommunikation über HTTPS erlaubt werden. Andere Ports sollten deshalb durch eine geeignete Firewall abgeschirmt werden. Nach einer erfolgreichen Installation kann Com42Bill über folgende URLs erreicht werden: Benutzerseiten: https://localhost:7002/doRequest Administrationsseiten: https://localhost:7002/doRequest?reqid=adm Projektmanagement Einleitung In diesem Kapitel wird der Projektplan der Projektgruppe 411 (Com42Bill) beschrieben. Dabei werden die Aktivitäten, die von den einzelnen Gruppen der Projektgruppe in den beiden Semestern durchgeführt wurden, vorgestellt. Bei diesen Gruppen handelt es sich um die Entwicklungs- und Querschnittsaufgabenteams. Somit wird der Projektplan auch in zwei wesentlichen Aufgabenbereichen aufgeteilt. Zuerst werden die Tätigkeiten, die in den Entwicklungsteams und anschließend die Tätigkeiten, die von den Querschnittsaufgabenteams vollzogen wurden, dargestellt. Insgesamt waren jeweils fünf verschiedene Entwicklungs- und Querschnittaufgabenteams im Einsatz. Jedes Entwicklungsteam war für die Entwicklung einer Komponente zuständig. Neben der Entwicklung wurden parallel durch die Querschnittsaufgabenteams weitere Tätigkeiten durchgeführt, die im Rahmen eines solchen Projektes typischerweise anfallen. Die Vorgehensweise bei der Entwicklung des Com42Bill-Systems war für alle Entwicklungsteams dieselbe. Der Zeitaufwand bei der Entwicklung der einzelnen Komponenten variierte dabei leicht. Nachfolgend werden die Haupt-Aktivitäten, in denen jedes Entwicklungsteam involviert war, vorgestellt: Abschnitte des Projekts Anforderungsanalyse Die Anforderungsanalyse zeichnete die Anfangsphase der Projektgruppe aus. Ziel dieser Phase war es, funktionale und nichtfunktionale Anforderungen für die einzelnen Komponenten zu ermitteln. Hierbei wurden die Eigenschaften, die die jeweilige Komponente besitzen muss, festgehalten. Für nähere Erläuterungen bzgl. Anforderungen der Komponenten siehe Anhang A. Für die Erstellung des Anforderungsdokuments wurden ca. 45 Tage, d.h. von Mitte Mai bis Mitte Juli 2002 Zeit benötigt. Systemarchitektur In der Phase Systemarchitektur wurde zunächst von den Chef-Architekten eine Architektur für das Gesamtsystem entworfen und vorgestellt. Die Komponententeams haben die vorgeschlagenen Architekturen für ihre Komponente übernommen und später gemäß eigenen Vorstellungen und Möglichkeiten nach und nach angepasst. Für die Erstellung der Systemarchitektur wurden ebenfalls ca. 45 Tage, d.h. von Mitte Mai bis Mitte Juli 2002 Zeit benötigt. Klassenmodell Die Phase Klassenmodell diente eigentlich dazu, die nicht-persistenten Klassen der Komponenten in UML-Notation zu modellieren. Der vorgesehene Anfangstermin für diese Aktivität (02.07.2002) wurde nicht eingehalten. Es wurde entschieden, diese Aktivität parallel zu der Prototyping-Phase durchzuführen, weil erst dort einige Fragen bzgl. der Machbarkeit einiger Funktionen und somit der Notwendigkeit einiger Klassen geklärt werden konnte. Trotz alledem ist diese Hauptaktivität von keiner Komponente genau durchgeführt und dokumentiert worden. Eigentlich sollte diese Phase Mitte Juli 2002 beginnen und Anfang November 2002 fertig sein. Objektmodell Die Phase Objektmodell diente dazu, die persistenten Klassen der Komponenten in UML-Notation zu modellieren. Insgesamt wurden für die erste Version des Objektmodells 95 Tage benötigt, d.h. von Beginn der PG (April 2002) bis Anfang September 2002. Für die Verwaltung und Pflege des Objektmodells waren die Mitglieder der Komponente Datenbank zuständig. Objektdesign Ziel der Phase Objektdesign war es, die Klassen der Komponenten detailliert zu beschreiben, d.h. die notwendigen Attribute und Methoden hinzuzufügen. Am Ende dieser Phase sollte ein Designdokument vorliegen. Der vorgesehene Zeitrahmen für diese Phase war Mitte Juli 2002 bis Mitte Oktober 2002. Da das Designdokument erst am Ende der Implementierungsphase, d.h. als alle Komponenten lauffähig waren, fertig gestellt werden konnte, konnte der Endtermin für diese Phase nicht eingehalten werden. Prototyp Die Prototyping-Phase war dafür vorgesehen, die Key-Features der Komponenten mit reduziertem Funktionsumfang zu implementieren bzw. verschiedene Techniken zu testen, um die Machbarkeiten für die Komponente festzustellen. Hierbei sollten die Key-Features der Komponenten so ausgewählt werden, dass ein Gesamtdurchlauf des Systems, d.h. der Einbezug aller Komponenten, möglich war. Diese Phase ist in der vorlesungsfreien Zeit durchgeführt worden, d.h. von Anfang Juli bis Ende September waren die Teilnehmer mit Prototyping beschäftigt. Implementierung In der Implementierungs-Phase fand die eigentliche Implementierung statt, wobei hier in fast allen Komponenten die Erkenntnisse und der Code aus der Prototyping-Phase eingeflossen sind. Die Komponenten wurden in dieser Phase mit allen vorgesehenen Features vollständig implementiert und dokumentiert. Mit der Implementierung begannen die Komponententeams ungefähr Mitte Oktober. Einige benötigten mehr und andere weniger Zeit. Ingesamt dauerte dieser Phase bis Mitte Februar 2003. Zu Beginn waren die Aktivitäten Klassenreviews, Klassentests und Integrationstests zusätzlich zu den anderen Aktivitäten jeder Komponente eingetragen. Da jedoch für die Planung und Beaufsichtigung dieser Aktivitäten die Querschnittsaufgabe Qualitätsmanagement im Laufe der zweiten Projektgruppensemester verantwortlich wurde, wurden diese zu den anderen Aktivitäten dieser Querschnittsaufgabe hinzugefügt. Für die Klassenreviews wurden insgesamt 34 Tage von 10.12.2002 bis 24.01.2003, für die Klassentests wurden insgesamt 9 Tage von 20. bis 30.01.2003 und für die Integrationstests insgesamt 15 Tage 30.01. bis 15.02.2003 benötigt. Querschnitssaufgaben Wie oben schon erwähnt, waren parallel zu Entwicklungsaktivitäten auch Querschnittsaktivitäten zu erfüllen, die nachstehend vorgestellt werden. Projektmanagement Der Projektplan wurde während der Anfangsphase der Projektgruppe erstellt und musste kontinuierlich durch das Projektmanagement aktualisiert werden. In einem Rhythmus von ca. zwei Wochen wurde der Projektplan in der Projektgruppensitzung besprochen. In den ersten Projektgruppensemester wurde durch das Projektmanagement ein Anforderungsdokument erstellt, dessen Pflege an das Qualitätsmanagement übergeben wurde. Des Weiteren pflegte das Projektmanagement die Abwesenheitsliste und organisierte die Verwaltung der Projektgruppen-Kasse. In der Abwesenheitsliste konnten sich die Teilnehmer, die während der Semesterferien für längere Zeit nicht anwesend waren, eintragen. Marketing Im ersten Semester der Projektgruppe hat das Marketingteam die Bestellung von Projektgruppen T-Shirts organisiert, das Whitepaper entworfen, die Erstellung des Zwischenberichtes koordiniert, das Projektgruppenplakat entworfen und sich um die Kontaktaufnahme mit den Firmen gekümmert. Im zweiten Projektgruppensemester hat das Marketingteam sich wieder um die Kontaktaufnahme mit den Firmen bemüht. Diese Bemühungen blieben jedoch ohne Erfolg. Eine weitere Tätigkeit war die Koordination der Erstellung des Abschlussberichts. Für die Präsentation des Com42Bill-Systems ist das Marketingteam ebenfalls zuständig. Qualitätsmanagement Das Qualitätsmanagement war u. a. verantwortlich für den Entwurf eines Code Guide. Diese Aktivität wurde recht frühzeitig in den ersten Semesterwochen der Projektgruppe erledigt. Des Weiteren war es dafür verantwortlich, Dokumente wie den Projektplan, Anforderungs-dokument und Key-Features bzgl. ihrer Richtigkeit zu prüfen. Die Erstellung, Pflege und Wartung des Prozessmodells wurde ebenfalls durch das Qualitätsmanagement vorgenommen. Im zweiten Semester der Projektgruppe hat das Qualitätsmanagement jeweils die Klassenreviews, die Klassentests und die Integrationstests der Komponenten organisiert und in Zusammenarbeit mit den jeweiligen Komponenten durchgeführt. Zum Abschluss wurde ein Systemtest durchgeführt. GUI Am Anfang der Projektgruppe existierte neben den anderen Querschnittsaufgaben auch die Querschnittsaufgabe GUI. Sie war für den Entwurf des Com42Bill-Logos zuständig und sollte auch das Plakat erstellen. Die Querschnittsaufgabe GUI wurde in der Mitte des ersten Projektgruppensemesters aufgelöst; das Team ging in den Querschnittsaufgaben Marketing und Qualitätsmanagement auf. Chef-Architekten Die Chef-Architekten haben am Anfang des ersten Semesters eine Gesamtsystemarchitektur, in der die Subkomponenten aller Komponenten ersichtlich werden, entwickelt. Diese wurde anschließend von den Komponententeams aufgenommen und erweitert. Die Systemarchitektur wurde von den Chef-Architekten während der gesamten Projektgruppe gepflegt und aktualisiert. Zudem mussten sie die Schnittstellen zwischen den Komponenten kontinuierlich überprüfen und Anpassungsvorschläge entwickeln. Neben diesen Tätigkeiten sind sie für die Installation und Einrichtung des Applikationsservers gemeinsam mit den Systemadministratoren zuständig gewesen. Systemadministration Zu den Aktivitäten von Systemadministratoren gehörten u. a. die Einrichtung von Server, Workstations und CVS. Des Weiteren sind sie für die Installation und Einrichtung der Entwicklungsumgebung bzw. neuer Software zuständig gewesen. Neben diesen Tätigkeiten haben sie die Newsgroup und den FTP-Zugang für die Projektgruppe eingerichtet. Aufgabenübersicht Zuordnung der Projektgruppenteilnehmer zu Komponenten / Querschnittsaufgaben: KomponentenzuständigkeitenBusiness LogicAlireza Salemi, Narcisse Kemogne Kamdem, Timo AlbertDatenkonverterChristian Kotthoff, Zahir AmiriDatenbankserverAndre Pavlenko, Stefan Pinschke (1. PG-Semester)SicherheitsserverBastian Schlich, Dennis MüllerGUIAlexander Schmitz, Matthias Niggemeier, Dino HasanbegovicQuerschnittsaufgabenzuständigkeitenSystemadministrationStefan Pinschke (1. PG-Semester), Dennis MüllerMarketingMatthias Niggemeier, Dino HasanbegovicQualitätsmanagementChristian Kotthoff, Alexander Schmitz, Andre PavlenkoChef-ArchitektenAlireza Salemi, Narcisse Kemogne Kamdem, Timo AlbertProjektmanagementBastian Schlich, Zahir AmiriStefan Pinschke und Bastian Schlich tauschten in der Mitte des ersten Projektgruppensemester ihre Querschnittssaufgabe. Im zweiten Projektgruppensemester war Stefan Pinschke nicht mehr Teilnehmer der Projektgruppe Com42Bill. Qualitätsmanagement Einleitung Das Ziel bei der Software-Entwicklung ist es, eine Software von hoher Qualität zu erzeugen. Qualität wird von einigen Fachleuten als die Abwesenheit von Fehlern definiert [STE00]. Auf Softwareprodukte ist diese Definition nicht ohne weiteres übertragbar, denn auch Software mit Fehlern wird akzeptiert und genutzt. Die ISO-Norm definiert Qualität als die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen (ISO8402)[ISO00]. Die Aufgabe des Qualitätsmanagements bei der Softwareentwicklung ist es, sich nicht nur mit der Kontrolle auf Fehler am Endprodukt, die dann beseitigt werden müssen, sondern auch mit der Untersuchung der Ursache solcher Fehler zu beschäftigen. Auf diese Weise können Strategien entwickelt werden, diese Fehler zu vermeiden bzw. das Risiko ihres Auftretens zu verringern. Der Umschwung dieses Konzepts vom elementorientierten System der Qualitätssicherung zu dem prozessorientierten Qualitätsmanagement ist in der Softwareindustrie erst mit der Einführung der ISO9000-Normen geschehen. Dieser prozessorientierte Ansatz des Qualitätsmanagements geht von dem Grundsatz aus, dass ein qualitativ hochwertiger Prozess auch mit hoher Wahrscheinlichkeit ein qualitativ hochwertiges Produkt hervorbringt [Ste00]. In einer Projektgruppe ist das primäre Ziel nicht das Erreichen eines möglichst hohen Qualitätsstandards, sondern die Entwicklung eines funktionsfähigen Prototypen. Ein hohes Qualitätsniveau kann hier vor allem aus Zeitgründen nicht gewährleistet werden. Das bedeutet aber nicht, dass das Thema Qualität in einer Projektgruppe komplett vernachlässigt wird. Das Qualitätsmanagement der Projektgruppe Com42Bill legt den Schwerpunkt auf die Qualitätssicherung und die Optimierung der Softwareentwicklung. Für die Qualitätssicherung war das Durchführen eines Testprojektes, das ausführlich in einem Testplan dokumentiert wurde, ein elementares Hilfsmittel. In dem Testprojekt wurden mehrere Testphasen angesetzt, die teilweise schon während der Implementierungsphase eingesetzt haben, um Fehler rechtzeitig finden und beheben zu können. Die Testphasen begannen auf Klassenebene mit Codeinspektionen und Klassentests ausgewählter Klassen. Besonders ergiebig war die darauf folgende Integrationstestphase, in der die Schnittstellen zwischen den einzelnen Komponenten getestet und in mehreren Iterationen anschließend korrigiert werden mussten. Abschließend folgte ein Gesamtsystemtest, bei dem die Funktionalität des Systems im Vordergrund stand. Für die Optimierung der Softwareentwicklung als Ganzes wurde nach dem prozessorientierten Ansatz des Qualitätsmanagements ein Prozessmodell aufgestellt. Diese lehnt sich an das Wasserfallmodell mit Rückkopplung an. Mit Hilfe des Prozessmodells wurde der Softwareentwicklungsprozess dokumentiert und analysiert. Prozessmodell Das Prozessmodell bildet die für die Softwareentwicklung getätigten Aktionen ab und stellt einen Zusammenhang zwischen den Ergebnissen der Tätigkeiten und davon abhängenden Prozessen dar. Ein Prozess ist ein Satz von in Wechselbeziehung oder Wechselwirkung stehenden Tätigkeiten, der Eingaben in Ergebnisse umwandelt (DIN EN ISO 9000:2000) [ISO00]. Am Prozessmodell kann die Wertschöpfungskette des Entwicklungsprozesses nachvollzogen werden und Schwachpunkte analysiert werden, um den Prozess für zukünftige Projekte zu optimieren, es bietet somit eine Grundlage für die kontinuierliche Verbesserung der Softwareentwicklung. Das hier beschriebene Prozessmodell dokumentiert den Entwicklungsprozess der Projektgruppe. Symbolik Für die Dokumentation des Softwareentwicklungsprozesses der Projektgruppe Com42Bill wurde eine Darstellung gewählt, die an der Petrinetz-Notation angelehnt ist. Diese Notation folgt der Definition von Prozessen nach der ISO-Norm, aus einer oder mehreren Eingaben wird mittels einer Tätigkeit ein Ergebnis gewonnen. Tätigkeiten werden mittels eines Rechtecks dargestellt, die Eingaben und die Ergebnisse dieser Tätigkeiten durch Kreise. Komplexe Tätigkeiten werden der Übersichtlichkeit halber in den Diagrammen zunächst durch ein Rechteck, das von einem grauen Rahmen umgeben ist, symbolisiert. Diese Tätigkeiten werden dann in weiteren Grafiken aufgelöst. Die Eingaben und Ausgaben, die außerhalb dieser Verfeinerung erstellt bzw. gebraucht werden, sind durch gestrichelte Linien gekennzeichnet. Ein Beispiel für die diese Darstellung ist in Abbildung 66 zu sehen.  Abbildung 66: Notation Entwicklungsprozess Das Diagramm Entwicklungsprozess, das in Abbildung 67 gezeigt wird, stellt die Abläufe des gesamten Softwareentwicklungsprozesses dar. Ausgangspunkt der Softwareentwicklung war die in der Projektgruppenbeschreibung skizzierte Produktidee. Ausgehend von dieser Produktidee wurden Vorträge über möglicherweise benötigte Technologien und Konzepte gehalten; die Ergebnisse dieser Vorträge sind in den Seminarausarbeitungen nachzulesen. Ausgehend von diesen Ausarbeitungen und unter Berücksichtigung des zu erreichenden Endergebnisses wurde eine Entscheidung über das zu entwickelnde System gefällt. Die Wahl fiel auf ein Thin-Consolidator-System. Sehr früh in der Entwicklungsphase wurde die Entscheidung getroffen, das System komponentenbasiert zu erstellen. Das System wurde in benötigte Komponenten aufgeteilt und Teams mit der Verantwortlichkeit für die Komponenten betraut. Der weitere Verlauf des Softwareentwicklungsprozesses kann in folgende wichtige Phasen unterteilt werden: Anforderungsanalyse, Prototyping und Implementierung. Für den Beginn dieser Phasen waren noch unterstützende Prozesse, wie die Auswahl von Key-Features und das Erstellen eines Klassenmodells für das Prototyping, notwendig. Begleitend zur Phase der Implementierung setzen auch die bereits angesprochenen Tests und Reviews ein, um Fehler möglichst früh zu entdecken. Auf die einzelnen Phasen sowie auf die unterstützenden Prozesse wird in den folgenden Abschnitten ausführlich eingegangen.  Abbildung 67: Entwicklungsprozess Anforderungsanalyse Als eine der aufwändigsten Aufgaben des Entwicklungsprozesses hat sich die Anforderungsanalyse herausgestellt. Ausgehend von der erfolgten Komponenteneinteilung und den Ausarbeitungen, aus denen erste Aufgaben des Systems und der einzelnen Komponenten herausgearbeitet werden konnten, wurden erste Anforderungen erstellt. Es wurde aber sehr schnell deutlich, dass Unklarheiten über die Zusammenarbeit der Komponenten, die späteren Anwendungsfälle und deren Ablauf eine Konkretisierung der Anforderungen erschwerte. Aus diesem Grund wurden für das bessere Verständnis notwendige Dokumente wie die Systemarchitektur und eine textuelle Beschreibung der Komponenten angefertigt. Um die Aufgaben des Endproduktes und damit auch die Aufgaben einzelner Komponenten besser verstehen zu können, wurden in einem weiteren Schritt ein Architekturmodell, Use-Case-Diagramme, Aktivitätsdiagramme, ein Rollenmodell und in späteren Iterationen auch bereits ein Objektmodell entworfen. Mehrere dieser Iterationen, in denen die jeweiligen Erkenntnisse aus den Modellen in die Anforderungen und wiederum weitere notwendige Ergänzungen in den Anforderungen wieder in die Modelle übernommen wurden, waren nötig, um die Anforderungslisten zu komplettieren. Die Erstellung der Anforderungsliste und der Modelle waren aufgrund häufiger Reviews und Ergänzungen relativ komplexe Prozesse. Sie werden in den nächsten beiden Abschnitten noch genauer erklärt.  Abbildung 68: Anforderungsanalyse Anforderungen Ausgehend von der Entscheidung für Komponenten wurde versucht, Anforderungen an diese Komponenten aufzustellen. Für ein besseres Verständnis der Komponenten wurden zunächst textuelle Beschreibungen der Komponenten erstellt. Diese Beschreibungen wurden durch Reviews auf erste Fehler und auf Unstimmigkeiten überprüft und verbessert. Bereits bei der Erstellung dieser Beschreibungen wurde klar, dass man einheitliche Begrifflichkeiten für die vorkommenden Benutzerrollen benötigt, die durch das Rollenmodell eingeführt wurden. Die Komponentenbeschreibungen waren eine Grundlage für die Anforderungen an die Komponenten. Diese Anforderungsliste durchlief mehrere Iterationen, um die Anforderungen auf ein einheitliches Detailniveau zu bringen. In späteren Iterationen wurden die Anforderungen durch die Erkenntnisse aus den entwickelten Modellen ergänzt.  Abbildung 69: Anforderungen Modelle Ergänzend zu den Komponentenbeschreibungen und um für zukünftige Dokumente eine einheitliche Bezeichnung für die Benutzerrollen des Systems zu haben, wurde ein Rollenmodell erstellt. Um einen Überblick über die Zusammenarbeit der Komponenten zu erhalten, wurde ein Architekturmodell erstellt. Durch neue Anforderungen wurden in weiteren Iterationen Anpassungen des Architekturmodells notwendig. Für ein besseres Verständnis der Funktionen von Com42Bill wurden Use-Case-Diagramme entwickelt. Als weitere Verfeinerung wurden die Funktionen durch Aktivitätsdiagramme beschrieben. Die Erkenntnisse aus den Diagrammen über die Funktionsweise gingen in die weiteren Iterationsstufen zur Überarbeitung der Anforderungsliste ein. Bereits bei den Anforderungen wurde versucht festzustellen, welche Daten die Komponenten dauerhaft speichern müssen. Diese Daten wurden in dem Objektmodell festgehalten, das durch ständige Reviews ergänzt und überarbeitet wurde.  Abbildung 70: Modelle Technologieentscheidung Bereits in einer frühen Iterationsstufe der Erstellung der Anforderungsliste und der Modelle wurden Entscheidungen über die einzusetzende Software und die Softwaretechnologien getroffen. Aufgrund der Komplexität des Zusammenspiels der Komponenten und der zugehörigen Subkomponenten fiel die Entscheidung nach Auswertung der Features und der Verfügbarkeit der Produkte auf einen Applicationserver und einen Datenbankserver. Auch eine Entwicklungsumgebung wurde so bestimmt. Die Auswahl von Softwaretechnologien konnte ebenfalls aufgrund der Aufgaben, die sich aus den Anforderungslisten ergaben, getroffen werden. So wurde von der Komponente Business Logic beispielsweise eine Pipelinearchitektur für die Umsetzung der Geschäftsprozesse gewählt.  Abbildung 71: Technologieentscheidung Auswahl von Key-Features Aus den Ergebnissen der Anforderungsanalyse wurden für die Entwicklung von Prototypen Key-Features ausgewählt. Nachdem diese Key-Features zunächst unabhängig von der Zusammenarbeit der Komponenten untereinander bestimmt wurden, war eine Überarbeitung für einen wünschenswerten frühen Workflowtest nötig. Für ein effizientes Prototyping wurde ein Zeitplan für die Entwicklung der Prototypen, unter dem Gesichtspunkt, eine frühe Zusammenarbeit der Komponenten zu ermöglichen, erstellt.  Abbildung 72: Auswahl von Key-Features GUI-Design Die Erstellung der Benutzeroberflächen teilte sich in zwei Bereiche, zum einen die Bestimmung eines einheitlichen Aussehens der Webseiten, einem Style-Guide, und dem Aufstellen eines Navigationslayouts, an dem die Funktionen der Webseiten abgelesen werden können. Die Anforderungen an den Style Guide wurden bereits in der Anforderungsliste gestellt. Das Navigationslayout ergab sich aus den Benutzerrollen und den Funktionen, die durch die Use-Case-Diagramme und die Aktivitätsdiagramme beschrieben wurden. Die Zusammenführung des Style Guide und des Navigationslayout ergaben das endgültige Screendesign der Benutzeroberfläche.  Abbildung 73: GUI-Design Klassenmodell Für das Prototyping und die Implementierung wurde ein Klassenmodell benötigt. Dieses ergab sich sehr leicht aus dem Objektmodell und der Systemarchitektur, die erforderlichen Schnittstellen und Übergabeparameter konnten aus den Anforderungen und den Aktivitätsdiagrammen ermittelt werden. Eine Kontrolle und Überarbeitung des Klassenmodells und besonders der Schnittstellen waren für eine spätere Zusammenarbeit der Komponenten unabdingbar.  Abbildung 74: Klassenmodell Testplan Um Fehler in den Klassen und der Zusammenarbeit der Komponenten zu erkennen, sind Tests notwendig. Für systematische Tests, die die Qualität des Produkts Com42Billl sichern sollen, ist die Erstellung eines Testplans sinnvoll. Je früher ein Fehler in der Softwareentwicklung entdeckt wird, desto leichter ist er zu beheben. Aus diesem Grund wurde entschieden, die Tests inkrementell aufeinander aufzubauen. Die Tests wurden deshalb in vier Testphasen eingeteilt. In der ersten Testphase wurden Whiteboxtests wie Code-Reviews und Klassentests geplant. Durch diese Tests soll die Fehlerfreiheit in den einzelnen Klassen der Komponenten gewährleistet werden. In der zweiten Phase sollten Komponententests, die als Blackboxtests geplant waren, durchgeführt werden. Diese Testphase wurde jedoch aufgrund von Problemen bei der Integration der Komponenten aus Zeitgründen verworfen. Die Zusammenarbeit der Komponenten wurde in der Integrationstestphase überprüft. Hierfür wurden Greyboxtests angesetzt, bei denen die Schnittstellen zwischen den Komponenten beobachtet werden. Abschliessend erfolgte in der letzten Phase ein Gesamtsystemtest. Für die einzelnen Tests wurden zunächst die Testlinge ausgewählt und danach Testszenarien ausgearbeitet. Die Verantwortlichen für die jeweiligen Tests und die zeitliche Planung wurden in einem Testplan festgehalten.  Abbildung 75: Testplan Prototyping Das Prototyping war in zwei Stufen unterteilt. Die erste Stufe diente der Prüfung der verwendeten Technologie und der Machbarkeit. Das Ergebnis dieser Stufe waren bereits rudimentäre Prototypen. Erkenntnisse, die man aus der Implementierung dieser Prototypen gewonnen hatte, konnten wiederum zu einer Veränderung dieser Prototypen führen, so dass hier mehrere Iterationen möglich waren. War die technische Machbarkeit geklärt, so bestand die zweite Stufe aus einer Implementierung funktionaler Prototypen. Auch die Erkenntnisse aus diesen Prototypen gingen in die Verbesserung ein. Die funktionalen Prototypen sollten bereits in dieser Phase des Prototyping zu einem ersten Workflowtest zusammengeführt werden. Die Auswertung der Prototypen kann in einem ungünstigen Fall einen Rückschritt zu den Anforderungen notwendig machen, wenn man erkennt, dass das System so nicht umsetzbar ist. Aufgrund technischer Schwierigkeiten konnten nicht alle Komponententeams die Prototypenphase zum Abschluss bringen, so dass der geplante Workflowtest während des Prototypings nicht zustande kam.  Abbildung 76: Prototyping Implementierung Die Implementierung und das Testen stellen die letzten Phasen des Entwicklungsprozesses dar. Mit den Ergebnissen des Prototyping sollte die Implementierung schnell zu funktionsfähigen Komponenten führen. Bereits während der Implementierung der Komponenten setzen die im Testplan festgehaltenen Code-Reviews und Klassentests an. Eine Vorabintegration der Komponenten erfolgte schon während der Entwicklung, um die Schnittstellen der Komponenten aufeinander abzustimmen. Die Ergebnisse, die sich aus der Vorabintegration ergaben, gingen in die weitere Implementierung ein. Die vollständige Integration der Komponenten erfolgte danach. Das entstandene Gesamtsystem wurde nun mit Hilfe der geplanten Integrationstests überprüft. Die bei den Integrationstests entdeckten Fehler mussten bei der Implementierung der Komponente, in der die Fehler entdeckt wurden, behoben werden. Bei diesen Tests ging es vor allem darum, die Schnittstellen zwischen den Komponenten zu testen. Nach dem Integrationstest folgte ein Gesamtsystemtest. Fehler, die bei diesem Test entdeckt wurden, mussten selbstverständlich wieder in den Komponenten selbst korrigiert werden. Auch bei diesem Test lag ein besonderes Augenmerk auf der fehlerfreien Zusammenarbeit der Komponenten.  Abbildung 77: Implementierung Betrachtet man den gesamten Entwicklungsprozess, so erkennt man, dass die einzelnen Phasen der Entwicklung aufeinander aufbauen. Rückschritte zu einer vorherigen Phase, also eine Iteration, sind erlaubt. Das Entwicklungsmodell der Projektgruppe lehnt sich an das allgemeinere Wasserfallmodell mit Rückkopplung an. Die Phasen des Modells sind dabei: Anforderungsanalyse, Prototyping, Implementierung, Test. Qualitätssicherung Für die Qualitätssicherung, also die Kontrolle der Software, wurde ein Testplan entwickelt. In diesem Testplan wurden Verantwortlichkeiten, Testmethoden, Testziele und Zeitpläne festgelegt. Die Tests wurden in mehreren Phasen, die aufeinander aufbauen, ausgeführt. Aufgrund der beschränkten Zeit der Projektgruppe konnte kein vollständiger Test in jeder Phase durchgeführt werden, so dass man sich auf exemplarische Tests an ausgewählten Testlingen beschränkte. Die einzelnen im Testplan angesetzten Phasen waren Code-Reviews, Klassentests, Komponententests, Integrationstests und ein Gesamtsystemtest. Code-Inspektionen/-Reviews Ausgewählte Klassen wurden mittels Inspektionen überprüft und ihre Funktionen mit den Entwicklern diskutiert. Bei diesen Inspektionen erläuterte der Entwickler des jeweiligen Code-Stückes die Funktionen und die Art der Umsetzung. Durch Diskussionen und Vergleich mit den Anforderungen entdeckte Fehler wurden notiert, bewertet und später behoben. Die Auswahl der Klassen für die Inspektionen wurde nach den Kriterien getroffen, dass sie wichtig für die Gesamtfunktion des Systems sind und sich aufgrund ihres Zusammenspiels mit anderen Klassen oder ihrer Funktionsweise nicht für einen Klassentest eignen. Klassentests Als zweite Phase wurden Klassentests durchgeführt, bei denen ausgewählte Klassen der Komponenten mittels des Verfahrens der Zweigüberdeckung getestet wurden. Für die Tests wurden dementsprechend Eingabedaten für die Methoden der Klassen ausgewählt und beobachtet, ob das Verhalten den Erwartungen entspricht. Bei diesen Tests wurden Klassen gewählt, die wichtige Entscheidungen im Ablauf des Systems treffen. Es konnten allerdings nicht von jeder Komponente Klassen getestet werden, denn der Klassentest verlangt, dass der Testling weitestgehend von anderen Klassen isoliert wird. Bei den Klassen der Business Logic war das nicht möglich, da die über 100 Beans erst durch die Workflowkonfiguration sinnvoll miteinander verknüpft werden und einzeln nur wenig Funktionen enthalten. Nur einige bei diesen Tests entdeckte Fehler waren kritisch und mussten behoben werden. Komponententests In einer folgenden Phase sollte ein Komponententest durchgeführt werden, der aber ausgesetzt wurde. Die Gründe dafür waren Probleme bei der Integration der Komponenten, die erforderten, dass die Komponenten während der Integration stetig auf die Zusammenarbeit mit anderen Komponenten angepasst werden mussten. Es bestand also kein abschließender Zustand, der zu diesem Zeitpunkt hätte getestet werden können. Aus Zeitgründen wurde diese Testphase komplett verworfen und der Integrationstest vorgezogen. Integrationstest Der Integrationstest stellte aufgrund der Komplexität der allgemeinen Schnittstelle zwischen den Komponenten eine besondere Herausforderung. Die Möglichkeit einen destruktiven Test durchzuführen, um Fehler aufzudecken, wurde schnell verworfen, da die Anzahl der möglichen Eingaben den Testrahmen sprengen würde. Man entschied sich also für einen demonstrativen Test, um die Funktionsfähigkeit der Komponenten zu zeigen. Wie im Testplan vorgesehen wurde ein nachrichtenbasierter Test angesetzt, bei dem der Inhalt des Requests, des Übergabeobjekts zwischen den Komponenten, an kritischen Stellen des Systems ausgegeben wurde.  Abbildung 78: Komponentenschnittstellen Diese Hotspots sind anhand der Systemarchitektur leicht zu erkennen, es sind die Schnittstellen zwischen den Komponenten. Auch bei diesem Test waren Einschränkungen zu machen, denn zwischen der Business Logik und der Datenbank gab es keine einheitliche Schnittstelle, an der Daten hätten abgegriffen werden können. Also Grundlage für den demonstrativen Test dienten die Use-Cases, die während des Systementwurfs herausgearbeitet wurden. Gesamtsystemtest In der letzten Testphase wurde der Gesamtsystemtest durchgeführt. Hierbei wurde der Schwerpunkt auf einen Funktionstest gelegt, von Performanz- und Belastungstests wurde Abstand gehalten. Der Funktionstest wurde als Black-Box-Test realisiert. Zunächst wurden alle Funktionen der Applikation, die in den Anwendungsfall- und Aktivitätsdiagrammen abgebildet worden sind, im Rahmen eines Funktionsflusstests überprüft. Dabei wurde über die beiden System-Schnittstellen, dem Web-Interface der GUI und dem Datenkonverter, für jeden spezifizierten Anwendungsfall eine entsprechende Oberflächenausprägung mit den benötigten Daten erzeugt. Anschließend wurden die aus dem jeweiligen Anwendungsfall resultierenden Ausgaben überprüft. Neben dem Funktionsflusstest wurde zusätzlich ein Syntaxtest durchgeführt. Hierbei wurden an den System-Schnittstellen absichtlich syntaktisch falsche Daten eingegeben, um zu kontrollieren, ob die Syntax richtig interpretiert wird und der Benutzer auf fehlerhafte Daten durch eine entsprechende Meldung hingewiesen wird. Fazit Die Teilnehmer der Projektgruppe Com42Bill konnten in ihrer einjährigen Arbeit viel Erfahrung sowohl im Umgang mit neuen Technologien, als auch im Umgang miteinander in einem Team sammeln. Die wohl wichtigsten Erfahrungen im Überblick: Teamarbeit / Kommunikation: Auch wenn die Trennung in Komponenten von der Sache und der eingesetzten Technik sinnvoll ist, sollte jeder immer daran denken, dass an einem Gesamtsystem gearbeitet wird. Wichtig ist der Blick „über den Tellerrand“, d.h. in die Arbeit und den Fortschritt der anderen Komponenten. Bei dem „Blick“ darf es jedoch auch nicht bleiben, eine permanente Absprache, welche Techniken eingesetzt werden und wie Schnittstellen aussehen ist dringend notwendig. Bei Schwierigkeiten kann so auf eine breitere Wissensbasis zurückgegriffen werden; abgesehen davon hilft ein konstruktives Gespräch oft mehr als gegenseitige Schuldzuweisungen. Die mangelnde Kommunikation wurde dadurch verstärkt, dass sehr selten zusammen entwickelt wurde. Jede Komponente hatte im privaten Bereich ihren eigenen Server aufgebaut; dies führte zu den oben erwähnten fehlenden Informationen über die anderen Komponenten. Der Hauptgrund für die Programmentwicklung auf privaten Rechnern dürfte bei der unzureichenden technischen Ausstattung und den unzumutbaren baulichen Gegebenheiten des Uni-Pools zu suchen sein. Technik / Entwicklung: Das eingesetzte Entwicklungswerkzeug, Together ControlCenter, ist auf den vorhandenen Rechnern nicht geeignet, ernsthaft Software zu entwickeln. Auf aktuellen Rechnern ist zwar eine fast flüssige Programmbedienung möglich, jedoch geraten auch hier einige Operationen, wie Übersetzen oder gar Deployment, zum Geduldsspiel. Das Konzept des Applicationservers, wie er in dieser PG eingesetzt wurde, fand breiten Anklang. Es wird ein umfangreiches Framework zur Verfügung gestellt, das dem Entwickler viel Arbeit abnimmt. Diese Arbeitserleichterung erkauft man sich allerdings mit zum Teil recht komplexen Konfigurationsvorgängen sowie zum Teil nicht nachvollziehbaren Verhaltensweisen des Servers beim Versuch, selbstgeschriebene Beans einzusetzen. Eine umfangreiche und tiefgreifende Einarbeitung in den eingesetzten Applicationserver ist vor dem Einsatz in einer Betriebsumgebung dringend nötig. Vor allem das Debugging gestaltet sich (noch) recht schwierig, da die eingesetzte Entwicklungsumgebung keinen Eingriff oder Einsicht in laufende Programme erlaubt. Bevor man mit dem Programmieren beginnt, muss der zu programmierende Teil ordentlich spezifiziert werden. Alles, was hier eingespart wird, muss hinterher mehrfach angehängt werden. Um eine doch recht große Gruppe wie eine PG zu koordinieren, ist ein straffer Plan nötig, der allerdings auch von allen Teilnehmern ernst genommen werden muss. Natürlich kann es da zu Verschiebungen kommen; aber das Projektziel sollte nie aus den Augen verloren werden, sonst verschwendet man leicht zu viel Zeit. Ausblick: Die im Rahmen dieser PG erstellte prototypische Version von Com42Bill bietet an vielen Stellen Raum für Erweiterungen. Die Darstellung muss nicht auf PCs beschränkt bleiben. Eine Alternativdarstellung auf mobilen Endgeräten ist denkbar (und im Rahmen der umgesetzten Architektur auch leicht machbar). Der Datenkonverter kann leicht auf die verschiedensten Formate und Kommunikationskanäle von Rechnungsstellern und Finanzdienstleistern angepasst werden, ohne das ebXML-Rahmenwerk zugrunde legen zu müssen. Da innerhalb Deutschlands ebXML noch nicht verbreitet ist, wird dies vor einem „Echteinsatz“ auch nötig sein. Durch das Konzept der Business Logic sind Workflows recht einfach erweiterbar und anpassbar. Hier ist vor einem „Echteinsatz“ noch etwas Arbeit nötig, um wirklich alle Abläufe, die im täglichen Betrieb nötig sind, zu automatisieren. Sicherheit: Die Kommunikation zwischen dem Com42Bill-Server und den Benutzern geschieht derzeit über http. Diese Verbindung sollte, da ja sensible Daten übertragen werden, auf eine SSL-verschlüsselte Verbindung umgestellt werden. Die Möglichkeit hierzu ist im Applicationserver vorhanden; es muss jedoch noch ein öffentlicher Schlüssel bei einer der Zertifizierungsstellen (z.B. Thawte) bestellt werden. Offene Fragen: Die komplette Konzeption eines EBPP-Systems würde den Rahmen einer Projektgruppe sprengen. Wir haben uns bei unserer Arbeit hauptsächlich um die technische Umsetzung gekümmert, daher bleiben einige betriebswirtschaftliche Fragen offen: Kostenrechnung: Wie rechnet sich das System für den Betreiber? Wer trägt anfallende Kosten, und wie hoch sind diese? Zahlungssicherheit: Gibt es für den Rechnungssteller eine Zahlungsgarantie? Wie wird die für den Betreiber dargestellt? Zahlungen: Wer führt Zahlungen aus? Es gibt bislang keine ebXML-Schnittstelle zur deutschen Kreditwirtschaft; wie geht der Zahlungsverkehr vonstatten? Identität: Wie wird die Identität von Benutzern geprüft? Kredit: Wie werden Kreditlimits von Benutzern verwaltet? Anforderungsliste Aufbau IDIdentifiziert die Anforderung eindeutig, um auf sie referenzieren zu können (siehe Spalte „Abgedeckt durch“)Betroffene KomponenteGibt an, welche Komponente diese Anforderung erfüllen muss.Abgedeckt durchGibt an, welche Anforderung einer Komponente diese Anforderung abdeckt. Mögliche Werte sind: die ID einer Anforderung einer anderen Komponente, falls diese Anforderung durch eine andere Komponente erfüllt wird.selbstdiese Anforderung muss von der eigenen Komponente erfüllt werden nicht abgedeckt diese Anforderung ist an eine andere Komponente gerichtet ist, wird aber von ihr nicht erfülltBeschreibungBeschreibt die Anforderung textuell, um Missverständnissen vorzubeugen.BegründungBegründet, warum die Anforderung aufgestellt wurde.DatumGibt das Datum an, an dem die Anforderung aufgestellt wurde.PrioritätGibt die Priorität der Anforderung an. Mögliche Werte sind Zahlen von 1 bis 4, wobei 1 die höchste Priorität beschreibt.TypGibt an, ob eine Anforderung unbedingt erfüllt werden muss oder ob es sich um eine optionale Anforderung handelt. Mögliche Werte sind:mussdie Anforderung muss unbedingt erfüllt werden kanndie Anforderung wird nur erfüllt, wenn zum PG-Ende hin noch genügend Zeit vorhanden ist.Funktional (F)Es wird ein „x“ eingetragen, falls die Anforderung funktional ist.Nicht-funktional (NF)Es wird ein „x“ eingetragen, falls die Anforderung nicht-funktional ist.Schnittstellen-Relevanz (SR)Es wird ein „x“ eingetragen, falls die Anforderung Auswirkungen auf eine Schnittstelle hat.StatusGibt den aktuellen Status an, mögliche Werte sind:in Arbeit die Anforderung wurde noch nicht implementierterledigtdie Anforderung wurde bereits implementiertentfälltdie Anforderung wird nicht mehr benötigtBegründung für Status entfälltIn dieser Spalte steht die Begründung für ein eventuelles entfallen der Anforderung Datenkonverter (DK) IDBetroffene Komp.Abgedeckt durchBeschreibungBegründung   DatumPrioTypFNFSRStatusBegründung für Status entfällt.DK-001SS-009Die Sicherheitskomponente muss den Benutzer identifizieren und authentifizieren können (SSL).Es dürfen nur berechtigte User Zugriff haben.23.6.021mussx xerledigt DK-002SS-019Die Sicherheitskomponente muss ausgehende Daten verschlüsseln und eingehende Daten entschlüsseln können (SSL).Die Daten dürfen nicht durch Dritte gelesen werden.23.6.021mussx xerledigt wird von Weblogic automatisch erledigt, wurde aber noch nicht getestetDK-003SS-020Die Sicherheitskomponente muss anhand der digitalen Signatur die Unverändertheit (Integrität) der Daten und die Identität des Versenders (Authentizität) überprüfen. Datensicherheit.19.6.021mussx xentfällt erfordert die Implementierung einer komplexen Infrastruktur, die den Rahmen der PG sprengen würdeDK-004SS-010Die Sicherheitskomponente muss anhand einer ID einen Geschäftsprozess identifizieren, den der Datenkonverter dann über den Workflow-Adapter bzw. Workflow-Manager initiieren kann.Der Datenkonverter muss entsprechende Geschäftsprozesse anstoßen können.11.6.021mussx xerledigt DK-005GUIG-059Die GUI muss im Workflow-Adapter eine Schnittstelle bereitstellen, die das Container-Objekt vom Datenkonverter empfangen und weiterleiten kann.Der Datenkonverter muss entsprechende Geschäftsprozesse anstoßen können.11.6.021mussx xerledigt DK-006GUIG-059Die GUI muss dem Datenkonverter über den Workflow-Adapter ein Container-Objekt zur Verfügung zu stellen.Der Datenkonverter ist verantwortlich, diese Daten zu konvertieren und zu versenden.11.6.021mussx xerledigt DK-007GUIG-059Die GUI muss dem Datenkonverter Statusmeldungen über den Verlauf der Geschäftsprozesse zur Verfügung stellen.Der Datenkonverter muss den Status seines initiierten Geschäftsprozesses überprüfen können.11.6.021mussx xerledigt DK-008DBDB-007; DB-009Das DBMS speichert ebXML relevante Dateien (CPP von Com42Bill, CPAs, DTD's, Business Process Specification etc.)Datenspeicherung11.6.021mussx xentfällt Die Dokumente werden nicht in der DB, sondern auf dem Server abgelegt, da sie der ebXML-Community zugänglich sein müssen (Registry-Ersatz)DK-009DK Der Datenkonverter stellt der Sicherheitskomponente die nötigen Informationen zur Verfügung, um Requests authentifizieren zu können.Der User muss eindeutig identifiziert werden11.6.021mussx  entfällt abgedeckt durch DK-032DK-010DK Der Datenkonverter stellt der Sicherheitskomponente die nötigen Informationen zur Verfügung (z. B. eine ID), um den entsprechenden Geschäftsprozess identifizieren zu können.Der User muss eindeutig identifiziert werden11.6.021mussx  entfällt abgedeckt durch DK-032DK-011DKselbstDer Datenkonverter stellt der GUI (Workflow-Adapter) ein Container-Objekt bereit, welches die zu verarbeitenden Geschäftsdaten sowie den zugehörigen Geschäftsprozess enthält.Weiterleitung von Geschäftsprozessen und Daten an die Business-Logic.11.6.021mussx  erledigt DK-012DKselbstDer Datenkonverter muss Daten abhängig vom Finanzdienstleister konvertieren und ihm bereitstellen können.Überweisungsauftrag an Finanzdienstleister übermittelen11.6.021mussx  erledigt DK-013DK Der Datenkonverter besitzt eine Subkomponente RegistryVerwaltung der ebXML-relevanten Dateien (CPAs etc.)11.6.021mussx  entfällt die Implmentierung einer ebXML Registry ist nicht das primäre PG-Ziel und hätte den Rahmen eindeutig gesprengt.DK-014DKselbstDer Datenkonverter besitzt eine Subkomponente MsgServiceInterfaceEingehende Daten empfangen und enpacken, ausgehende Daten verpacken und versenden (gemäß ebXML Protokoll)11.6.021mussx  erledigt DK-015DKselbstDer Datenkonverter besitzt eine Subkomponente MsgServiceInterfaceHandlerKonvertierung; Kommunikation mit Sicherheitskomponente, DBMS über Registry, GUI (Workflow-Adapter)11.6.021mussx  erledigt DK-016DKselbstErstellung eines CPPs für das Betreiber-System und ein Dummy-CPP für Testzwecke.notwendig für ebXML19.6.021muss x erledigt DK-017DKselbstErstellung eines CPAs anhand der beiden CPPs.notwendig für ebXML19.6.021muss x erledigt DK-018DK Es werden so wenig Daten wie möglich übertragen, d.h. die zu übertragenden Daten werden auf das nötigste beschränkt.Performance und Datensicherheit.19.6.021muss x entfällt abgedeckt durch DK-032DK-019DK Der Datenkonverter kommuniziert nur über sichere Verbindungen.Datensicherheit.19.6.021muss x entfällt abgedeckt durch DK-032DK-020DK Der Datenkonverter ist für die übertragenen Daten verantwortlich.Datensicherheit.19.6.021muss x entfällt abgedeckt durch DK-032DK-021DK Der Datenkonverter speichert nur seine eigenen Daten in der DatenbankDatensicherheit.19.6.021muss x entfällt abgedeckt durch DK-032DK-022DKselbstDer Datenkonverter empfängt Rechnungsdaten vom Rechnungssteller, konvertiert und packt diese in ein Container-Objekt.Weiterleitung von Geschäftsprozessen und Daten an die Business-Logic.19.6.021mussx  erledigt DK-023Externes ebXML-ModulselbstEingehende Daten empfangen und entpacken, ausgehende Daten verpacken und versenden (gemäß ebXML Protokoll). Rechnungsstellr muss die Funktionen manuell ausführen.Rechnungstellern, die kein ebXML-System besitzen, soll die Möglichkeit gegeben werden, Com42Bill zu nutzen.11.6.024kannx  entfällt war nur optional vorgesehenDK-024DBnicht abgedecktDie Datenbank soll die Möglichkeit bereitstellen, gezielt auf einzelne XML-Tags zuzugreifen.Performance23.6.024kannx xentfällt DK hält keine Daten in der DB, sondern nur im Filesystem des WebserversDK-025DKselbstDer Datenkonverter muss jede Datenübertragung protokollieren.Nachverfolgung bei Problemen.23.6.021mussx  erledigt DK-026SS-022Die Sicherheitskomponente muss eine Public-Key-Infrastruktur bereitstellen.Datensicherheit.23.6.021mussx xentfällt erfordert die Implementierung einer komplexen Infrastruktur, die den Rahmen der PG sprengen würdeDK-027SS-023Die Sicherheitskomponente muss einen Mechanismus bereitstellen, um ausgehende Nachrichten digital zu signieren.Datensicherheit.23.6.021mussx xentfällt erfordert die Implementierung einer komplexen Infrastruktur, die den Rahmen der PG sprengen würdeDK-028DKselbstDer Datenkonverter muss dem Sender den Empfang einer Nachricht durch eine Acknowledge Message bestätigen. Diese enthält Informationen (digitale Signatur), um die Identität und Integrität einer Nachricht überprüfen zu können.Datensicherheit.16.6.021mussx  erledigt digitale Signatur fehltDK-029DKselbstDer Datenkonverter muss Nachrichtenduplikate erkennen und ignorieren können.Datensicherheit.17.6.021mussx  entfällt wurde aus Zeitgründen nicht implementiert, hat aber keine Auswirkung auf die FunktionalitätDK-030DKselbstDie Gültigkeitsdauer einer Nachricht wird durch ein TTL-Attribut (Time To Life) festgesetzt.Datensicherheit.18.6.021mussx  entfällt wurde aus Zeitgründen nicht implementiert, hat aber keine Auswirkung auf die FunktionalitätDK-031DKselbstDer Datenkonverter benötigt ein Administrationstool, um interne Dateien verwalten zu können.Es müssen Dateien manuell in der Datenbank abgelegt bzw. geändert werden.19.6.021mussx xentfällt Die Dokumente werden nicht in der DB, sondern auf dem Server abgelegt, da sie der ebXML-Community zugänglich sein müssen (Registry-Ersatz)DK-032DKselbstDer Datenkonverter muss die Sicherheitsrichtlinien der Komponente Sicherheit berücksichtigenDatensicherheit.26.6.021mussx xerledigt DK-033DKselbstDer Datenkonverter muss der Datenbank ein Objektmodell zur Verfügung stellen.Abbildung der Daten des DK in der DB26.6.021muss xxerledigt DK-034GUIG-090Die GUI muss eine Benutzeroberfläche bereitstellen, mit deren Hilfe CPP/CPAs in die Datenbank eingefügt bzw. gelöscht und geändert werden können.Administration10.7.022mussx xentfällt DK hält keine Daten in der DB, sondern nur im Filesystem des WebserversDK-035DKselbstEs müssen vom Rechnungssteller Statusinformationen über die erfolgte Bezahlung von Rechnungen importiert werden.Rechnungspräsentation#######1mussx xerledigt DK-036DKselbstEs müssen vom Rechnungssteller Informationen zu Stornierungen von Rechnungen importiert werden.Rechnungspräsentation#######1mussx xerledigt DK-037DKselbstEs müssen vom Finanzdienstleister Fehlermeldungen bei fehlgeschlagener Überweisungsausführung importiert werden.Rechnungspräsentation#######1mussx xerledigt DK-038DKselbstVersendete Nachrichten werden auf der Festplatte zwischengespeichertSicherheit.#######1mussx xerledigt DK-039DKselbstDer Rechnungssteller erhält zu jeder importierten Rechnung, Storno sowie Statusinformation eine Statusmeldung über den Erfolg/Mißerfolg des jeweiligen Datenimports.Sicherheit.#######1mussx xerledigt DK-040DKselbstDer DK teilt der BL mit, wenn der Export einer Überweisung fehlgeschlagen ist.Die BL kann des Bezahlungsstatus rückgängig machen.#######1mussx xerledigt DK-041DKselbstDer Rechnungssteller erhält bei fehlgeschlagener Authentifizierung eine entspr. FehlernachrichtSicherheit.#######1mussx xerledigt  GUI (G) IDBetroffene Komp.Abgedeckt durchBeschreibungBegründung   DatumPrioTypFNFSRStatusBegründung für Status entfällt.G-001GUIselbstInformationen dürfen nicht durch das Layout der Seite in den Hintergrund gedrängt werdenEin zu komplexes Layout verhindert eine einfache Wahrnehmung der dargestellten Informationen. Durch ein zu einfaches Layout wird die Seite uninteressant.28.4.023muss x erledigt G-002GUIselbstEin einheitliches Design auf allen Webseiten muss gewährleistet sein. (Corporate Design)Ein einheitliches Layout hilft dem Benutzer, sich auch auf untergeordneten Seiten zurechtzufinden.28.4.022muss x erledigt G-003GUIselbstDie Funktion und Bedienbarkeit von Web-Seiten darf nicht von Bildschirmauflösungen oder Farbtiefen abhängig sein.Jeder Benutzer soll unabhängig von der verfügbaren Ausstattung die Seite nutzen können, wodurch einer Einschränkung der potentiellen Kunden vorgebeugt wird.28.4.023muss x erledigt G-004GUIselbstDas Seitenlayout hat eine feste Breite.Eine Konsistenz des Seiteninhalts wird gewährleistet, das Verschieben der einzelnen Elemente bei unterschiedlichen Auflösungen wird dadurch verhindert28.4.023kann x erledigt G-005GUIselbstDie Layoutgestaltung beruht auf Templates.Globale Änderungen im Layout können leicht über die Templates durchgeführt werden.28.4.022kann x erledigt G-006GUIselbstDialoge sind intuitiv erschließbar sein, d.h. umittelbar verständlich sein.Der Benutzer soll ohne Anleitung in der Lage sein, die Dialoge bedienen zu können.28.4.022kann x erledigt G-007GUIselbstDialoge unterstützen den Benutzer bei der Durchführung der Aufgabe ohne ihn zusätzlich zu belasten.Effizientes Arbeiten mit den Dialogen muss möglich sein.28.4.021kann x erledigt G-008GUIselbstDialoge sind erwartungskonform sein, d.h. den Erwartungen des Benutzers entsprechen, die er aus Erfahrungen mit anderen Arbeitsabläufen bereits mitbringt und die er sich während der Benutzung des Systems angeeignet hat.Ohne diese Voraussetzung kann der Benutzer die Dialoge nicht intuitiv bedienen.28.4.023kann x erledigt G-009GUIselbstDialoge müssen fehlerresistent sein, d.h. im Falle eines durch Benutzereingaben verursachten Fehlers muss das System stabil bleiben und dem Benutzer deutlich machen, welchen Fehler er begangen hat und ihm durch Ratschläge helfen, den aufgetretenen Fehler Fehlerhafte Eingaben dürfen nicht toleriert werden und müssen vom Benutzer korrigiert werden, da sonst eine korrekte Abarbeitung der Eingaben nicht möglich ist.28.4.021mussx  in Arbeit G-010GUIselbstDer Text einer Seite ist leicht überschaubar durch z.B. aussagekräftige und hervorgehobene Überschriften und Unterteilung in Abschnitte.Text enthält Informationen und sollte schnell einzuordnen und zu lesen sein.28.4.022kann x erledigt G-011GUIselbstInformationen auf der Seite sind in der Reihenfolge ihrer Wichtigkeit angeordnet sein.Die Erfassung wichtiger auf der Seite enthaltener Informationen soll zuerst erfolgen. Stößt der Benutzer zuerst auf Unwichtiges, so verlässt er die Seite evtl. vorzeitig.28.4.024kann x erledigt G-012GUIselbstÜberflüssige Animationen, Laufschriften und „top“-Technologien wie Flash dürfen nicht eingesetzt werden, wenn es alternative Standard-Darstellungsmöglichkeiten gibt.Jeder Benutzer soll in der Lage sein, die Seite benutzen zu können - auch mit älteren Browsern oder auf anderen Betriebssystemen.28.4.022muss x erledigt G-013GUIselbstGrafische Symbole sind mit alternativen Textbeschreibungen versehen werden.Wenn der Clientbrowser keine Bilder anzeigen kann, so soll der Benutzer immer noch in der Lage sein, sich auf der Seite zurechtzufinden.28.4.023kann x erledigt G-014GUIselbstGrafiken und Multimedia-Objekte haben eine für jede Übertragungsart geeignete Dateigröße.Die Ladezeit einer Seite muss in einem akzeptablen Rahmen liegen.28.4.023muss x erledigt G-015GUIselbstDie gesamte Webpräsenz muss hierarchisch strukturiert sein.Mithilfe einer Hierarchie kann der Benutzer die Struktur der Seite leicht erfassen.28.4.021muss x in Arbeit G-016GUIselbstDie Navigation innerhalb der Hierarchie muss auf allen Seiten logisch zu erschließen und nachzuvollziehen sein.Ohne einen logischen Aufbau kann der Benutzer den Aufbau der Seite nicht nachvollziehen.28.4.021muss x in Arbeit G-017GUIselbstVerweise in der Hierarchie der Organisationsstruktur müssen deutlich erkennbar sein (z.B. Darstellung der gesamten Hierarchie in einem Navigationsbaum).Der Benutzer muss schnell erkennen sein, wie er durch die Seiten navigieren kann.28.4.022muss x erledigt G-018GUIselbstDie aktuelle Position des Benutzers in der Hierarchie muss jederzeit erkennbar sein.Nur so kann der Benutzer sich in der Organisation der Seiten orientieren.28.4.021muss x erledigt G-019GUIselbstIm Fließtext werden Links nur sparsam eingesetzt.Verknüpfungen im Text sind schwerer zu erkennen und tragen nicht zur Übersichtlichkeit bei. Durch häufige Links und damit Verzweigungsmöglichkeiten soll der Benutzer in seinem Lesefluss nicht gestört werden.28.4.024kann x erledigt G-020GUIselbstLinks beschreiben das verknüpfte Element möglichst exakt. Text-Links sind zu diesem Zweck prägnant formuliert, grafische Links haben Symbole.So ist eine Benutzung dieser Elemente ohne zusätzliche Erklärungen möglich.28.4.022kann x erledigt G-021GUIselbstLinks müssen eindeutig gekennzeichnet sein: Text-Links durch farbige oder stilistische Hervorhebung (z.B. Unterstreichung), grafische Links durch optische Effekte (z.B. Highlighting).Links ermöglichen die Navigation zwischen den Seiten und müssen deshalb klar erkennbar sein.28.4.022muss x erledigt G-022GUIselbstGrafische Links müssen eine Alternative in Form von Text-Links haben.Wenn der Clientbrowser keine Bilder anzeigen kann, so soll der Benutzer immer noch in der Lage sein, solche Links zu benutzen.28.4.021muss x in Arbeit G-023GUIselbstMit Ausnahme von Rechnungsdetails und evtl. Hilfen werden gelinkte Seiten nicht in einem neuen Fenster geöffnet.Die Navigation mit Vor- und Zurückbuttons ist beim Öffnen neuer Seiten nicht möglich.28.4.022kann x erledigt G-024GUIselbstDie Funktion des Back-Buttons muss gewährleistet sein, damit der Benutzer im Zweifelsfall jederzeit einen Schritt zurückgehen kann.Bei Fehlern oder Unsicherheiten soll der Benutzer immer die Möglichkeit haben, zu einer vorhergehenden Seite zurückzukehren.28.4.022mussx  erledigt G-025S Der Rechnungsempfänger hat die Möglichkeit sich mittels Benutzername und Passwort am System anzumelden.Ein Authentifizierung ist für den Zugriff auf geschützte Daten unbedingt nötig.28.4.021mussx xentfällt G-026GUIselbstDer Rechnungsempfänger wird in regelmäßigen Abständen daran erinnert sein Passwort zu ändern.Eine regelmäßige Passwortänderung erhöht die Sicherheit.28.4.024kannx  entfällt G-027SS-024Die Sicherheit weist auf ein veraltetest Kennwort bei der Authentifizierung hin.Diese Funktion löst G-026 aus.11.6.023kannx xentfällt G-028GUIselbstÜber die GUI kann der Rechnungsempfänger Daten wie Adresse, Telefonnummer, Faxnummer, usw. ändern.Eine Pflege der persönlichen Daten muss zur Kontaktaufnahme möglich sein.28.4.023mussx  in Arbeit G-029BLBL-007Die BL stellt Funktionen zum Ändern der Rechnungsempfängerdaten zur VerfügungErmöglicht G-02811.6.022mussx xerledigt G-030GUIselbstDer Rechnungsempfänger kann eine Rechnungsübersicht anfordern und einsehen.Eine Rechnungsübersicht ist für die Überschaubarkeit der Rechnungen unabdingbar.28.4.021mussx xerledigt G-031GUI/DBselbstDie dargestellten Rechnungen müssen einen eindeutigen Zustand haben, also „offen“, „fällig“, „bezahlt“ oder „in Bearbeitung“Nur durch eindeutige Zustände kann der Status einer Rechnund schnell erkannt werden.28.4.021muss xxerledigt G-032GUIselbstIn der Rechnungsübersicht können die Rechnungen nach Kriterien sortiert und gefilter werden.Diese Maßnahme erleichtert die Übersicht über die Rechnungen.28.4.023kannx xerledigt G-033BLBL-007Die BL stellt eine Funktion für das Abfragen von Rechnungen nach Kriterien wie Zeitraum, Fälligkeit, Status, etc.Diese Funktion ermöglicht G-030 und G-03211.6.021mussx xerledigt G-034GUIselbstÜber Links der Rechnungen aus der Rechnungsübersicht wird man zu den bei dem Rechnungssteller bereit gestellten Details weitergeleitet.Rechnungsdetails sind im lokalen System nicht verfügbar, deshalb muss zum Rechnungssteller weiterverlinkt werden.28.4.022mussx  in Arbeit G-035GUIselbstRechnungen aus der Rechnungsübersicht können für den Zahlungsvorgang markiert werden.Auf diese Weise können mehrere Rechnungen auf einmal bezahlt werden.28.4.021mussx  in Arbeit G-036GUIselbstBei den Dialogen für die Bezahlung kann zwischen mehreren Zahlungsarten gewählt werden. Eine vorher gewählte Standardbezahlung ist die Grundeinstellung.Die Wahl über die Art der Bezahlung ist für die Begleichung der Rechnung(en) notwendig.28.4.022mussx  in Arbeit G-037BLBL-008Eine Abfrage der möglichen Bezahlungsmöglichkeiten eines Rechnungsempfängers muss über die BL möglich sein.Ermöglicht G-03511.6.021mussx xin Arbeit G-038GUIselbstNach dem Abschluss der Bezahlung und der Bestätigung, dass der Vorgang bei der Business Logic ist, wird eine Bestätigung des Zahlungsvorgangs präsentiert.Der Zahlungsvorgang ist erst abgeschlossen, wenn er bei der Business Logic eingegangen ist. Danach erhält der Benutzer die notwendige Bestätigung.28.4.021muss xxin Arbeit G-039BLnicht abgedecktDie BL gibt nach dem Eingang eines Bezahlvorgangs eine Bestätigung an die GUI.Ermöglicht G-03811.6.021mussx xin Arbeit G-040GUIselbstDer Rechnungsempfänger kann zu jeder Funktion eine Hilfe aufrufen.Eine notwendige Unterstützung des Benuters für den Fall, das er sich nicht mehr zurechtfindet.28.4.023kannx xin Arbeit G-041DBDB-009Die Hilfen werden in der DB abgespeichert. 11.6.021mussx xentfällt,statische Texte wurden zur einfacheren Entwicklung ausserhalb der Datenbank gespeichert G-042DBDB-007Die DB bietet über ein entsprechendes Objekt einen Zugriff auf die Hilfen und Suchfunktionen in den Hilfstexten.Über die Suchfunktionen kann der Rechnungsempfänger nach gewünschten Funktionen suchen.11.6.021mussx xentfälltalle Hilfen wurden durch Tooltip-Hilfen ersetzt G-043DK (Wieso Anforderung von GUI an DK?) Der Rechnungssteller hat die Möglichkeit einen Datenaustausch ohne GUI durchzuführen.Auf diese Weise wird eine Automatisierung des Übermittlungsvorgangs möglich. (DK!?)28.4.022kannx xentfällt für GUI, vom DK erledigt G-044SS-017Eine Authentifizierung ist für das Einsehen geschützer Daten notwendig.Der Rechnungssteller kann sich am Webinterface mit einem Benutzernamen und Kennwort anmelden.28.4.021mussx xin Arbeit G-045GUIselbstDer Rechnungssteller kann eine Übersicht seiner Rechnungen einsehen.Dadurch kann er seine Rechnungen bezahlt/unbezahlt übersehen.28.4.021mussx  erledigt G-046GUIselbstDer Rechnungesteller kann die Rechnungen in der Rechungsübersicht nach Kriterien sortieren und filternEine Erleichterung bei der Übersicht der Rechnungen.28.4.022kannx  erledigt G-047BL Die BL stellt eine Funktion für das Abfragen von Rechnungen nach Kriterien wie Zeitraum, Fälligkeit, Status, etc.Diese Funktion erleichtert dem Rechnungssteller die Übersicht über seine Rechnungen.11.6.021mussx xentfälltder Rechnungssteller hat keine eigene GUI (wurde aus Zeitgründen nicht mehr implementiert) G-048DK/BL Informationen über die eigenen Rechnungen sollen in standardisierten Formen herunterladbar seinDies ist eine der Möglichkeiten Änderungen der Stati der eingespeisten Rechungen abzufragen.28.4.024kannx xentfälltoptionales Feature aus Zeitmangel nicht umgesetzt G-049GUIselbstDas Requesthandler-Servlet packt die Eingaben der GUI in ein Containerobjekt.Ein Containerobjekt beinhaltet alle Eingaben und Antworten der Komponenten, durch die es durchgereicht wurde.30.5.021mussx  erledigt G-050GUIselbstDas Requesthandler-Servlet kann die Eingaben bereits auf syntaktische Fehler kontrollieren.Korrekte Eingaben sind für das System notwendig.30.5.023kannx  in Arbeit G-051GUIselbstDer Request-Dispatcher unterscheidet zwischen Requests, die an die Sicherheit bzw. an die Business Logic weitergeleitet werden müssen.Requests, die der Authentifizierung dienen werden nicht von der BL bedient und müssen an die Sicherheit weitergeleitet werden.30.5.021mussx  erledigt G-052SS-015Der Request-Dispatcher überprüft beim Session-Manager vor der Bearbeitung einer Anfrage und vor der Ausgabe des Ergebnisses, ob eine Erlaubnis für diese Aktionen besteht.Um sicherzustellen, dass in dem "Zeitloch" zwischen Start des Requests und der Ausgabe die Session nicht beendet wurde und so die Ausgabe evtl. eine unauthorisierte Person zu sehen bekommt, wird vor der Ausgabe nochmals mit der Sicherheit gegengecheckt.30.5.023mussx xerledigt G-053GUIselbstDer Request-Dispatcher überprüft mit dem History-Controller, ob die gewünschte Anfrage zulässig ist.Ein Rückschritt, z.B. nach der Bestätigung einer Zahlung zu den Einstellungen für diese Zahlung, darf nicht möglich sein. Diesen Fall fängt der History-Controller ab.30.5.022mussx  erledigt G-054GUIselbstGültige Anfragen leitet der Request-Dispatcher an den Workflow-Adapter weiter.Der Workflow-Adapter bietet die Schnittstelle zur Business-Logic.30.5.021mussx  erledigt G-055DBDB-007; DB-009Der History-Controller speichert alle Aktionen des Benutzers in der DB.Um die gültige Reihenfolge der Anfragen eines Benutzers sicherzustellen, müssen diese Anfragen gespeichert werden.30.5.022mussx xentfälltlogging wurde in Abstimmung mit der Gesamt-PG weggelassen, hauptsächlich aus Performance-Gründen G-056GUIselbstDer History-Controller kontrolliert ob eine gewünschte Aktion auf die vorhergehende(n) folgen darf.s. G-05330.5.022mussx  erledigt G-057GUIselbstDer Response-Presenter bereitet die Ergebnisse einer Anfrage/Aktion für die Darstellung auf.Die Ergebnisse einer Aktion/Abfrage in einem Containerobjekt müssen für die Ausgabe aufbereitet werden.30.5.021mussx  erledigt G-058GUIselbstDer Workflow-Adapter leitet sämtliche Anfragen an den Workflow-Manager zur Bearbeitung weiter. Spezifizierung!!!Der Workflow-Adapter ist ein Wrapper des Workflow-Managers der Business Logic. Durch ihn wird eine strikte architektonische Trennung der GUI und der BL möglich.30.5.021mussx xerledigt G-059GUIselbstDie GUI stellt die vom DK benötigten Funktionen im Workflow-Adapter bereit. Gemäss der noch zu definierenden Schnittstelle werden Containerobjekte und Statusmeldungen übergeben. 11.6.021mussx xerledigt G-060BLBl-010Die BL bietet Funktionen um statistische Daten über die Rechungen abzufrufen. Diese Statistiken sind sowohl für Rechnungsempfänger als auch für Rechnungssteller für eigene Rechnungen verfügbar.Statistiken bieten eine schnelle Möglichkeit sich einen Überblick über z.B. seine monatlichen ausgaben zu schaffen.5.6.024kannx xentfälltoptionales Feature aus Zeitmangel nicht umgesetzt G-061GUIselbstDie GUI bietet dem Rechnungsempfänger Statistiken über seine Rechnungen an.Eine mögliche Zusatzfunktion. (s. G-059)11.6.024kannx  entfällt siehe G-060 G-062DBDB-007; DB-009Die internen Daten der Komponente GUI werden soweit wie möglich in der Datenbank gespeichert. (s. G-041)Die Speicherung in der Datenbank ermöglicht eine Zugriffssicherheit.5.6.021muss  xerledigt bis auf XSL und Grafiken G-063GUI Dem Rechnungssteller wird eine GUI für den Zugriff auf Daten der Registry und Repository des DK zur Verügung gestellt.Über diese Schnittstelle kann der Rechnungssteller selbst das Format steuern, in dem er Rechnungen erhält und an den Betreiber verschickt.5.6.023mussx xentfälltumgesetzt durch DK (?) G-064GUI  Der DK bietet der GUI Funktionen für das Abfragen darzustellender Informationen der Registry und des Repositiory.Ermöglicht G-062.11.6.023mussx xentfällt G-065GUI Es wird keine Verarbeitungslogik auf den Clients sowohl beim Rechnungsempfänger als auch beim Rechnungssteller eingesetzt.Dadurch wird die Benutzung von Applets zur Verarbeitung von Rechnungsdaten ausgeschlossen. (s. S-002)11.6.021muss xxerledigt G-066GUI Es werden jederzeit nur notwendige Daten übertragen.Zur Sicherheit werden keine unnötigen Informationen übertragen. (s. S-003)11.6.021muss xxerledigt G-067S Die Übertragung zwischen dem jeweiligen Benutzer und der GUI verläuft spätestens ab der Authentifizierung verschlüsselt (SSL).Sensible Daten müssen auch bei der Übertragung geschützt werden. (s. S-004)11.6.021muss xxentfälltdurch Komponente Sicherheit nicht unterstützt G-068GUIselbstDie GUI stellt Funktionen zum Versenden von Emails, SMS, etc. zur Verfügung. (Softwareverfügbarkeit David?)Mit dieser Funktion kann die BL Informationen über den Eingang neuer Rechungen oder Manungen an den Rechnungsempfänger versenden.11.6.023kannx xentfälltBL hat eigene Funktion zum Mailversand G-069GUI Es werden keine Daten auf dem Klienten gehalten. Ein eventueller Datenexport ist davon ausgenommen.Daten könnten in falsche Hände geraten.24.6.021mussx  erledigt G-070GUI Daten können nur von den hierzu berechtigten Benutzern eingesehen werden.Daten könnten in falsche Hände geraten.24.6.021mussx  in Arbeit G-071GUI Es werden nur Daten, die von der jeweiligen Komponente verwaltet werden, gespeichert.Komponenten speichern keine Daten, welche sie von anderen Komponenten erhalten haben. Aktualität der Daten und Datensicherheit.24.6.021muss x erledigt G-072S Der Betreiber hat die Möglichkeit sich mittels Benutzername und Passwort am System anzumelden.Ein Authentifizierung ist für den Zugriff auf geschützte Daten unbedingt nötig.28.4.021mussx xerledigt G-073GUIselbstDer Betreiber kann eine Liste der Rechnungsempfänger einsehenZur Kontrolle der Daten im System28.6.022mussx  erledigt G-074GUIselbstDer Betreiber kann Details der Rechnungsempfänger kontrollierenZur Kontrolle der Daten im System28.6.022mussx xerledigt G-075GUIselbstDer Betreiber kann Rechnungsempfängerkonten löschen, editieren und anlegen.Zur Wartung der Daten im System.28.6.023mussx xerledigt G-076GUIselbstDer Betreiber kann eine Liste der Rechnungssteller einsehenZur Kontrolle der Daten im System28.6.022mussx  erledigt G-077GUIselbstDer Betreiber kann Details der Rechnungssteller kontrollierenZur Kontrolle der Daten im System28.6.022mussx xerledigt G-078GUIselbstDer Betreiber kann Rechnungsstellerkonten löschen, editieren und anlegen.Zur Wartung der Daten im System.28.6.023mussx xerledigt G-079GUIselbstDer Betreiber kann eine Liste der Finanzdienstleister einsehenZur Kontrolle der Daten im System28.6.024mussx  entfälltkein Workflow G-080GUIselbstDer Betreiber kann Details der Finanzdienstleister kontrollierenZur Kontrolle der Daten im System28.6.024mussx xentfälltkein Workflow G-081GUIselbstDer Betreiber kann Finanzdiensteleisterkonten löschen, editieren und anlegen.Zur Wartung der Daten im System.28.6.024mussx xentfälltkein Workflow; aktuell nur Banken unterstützt; die Daten der Banken werden importiert G-082GUIselbstDer Betreiber kann eine Liste der Rechnungen einsehenZur Kontrolle der Daten im System28.6.022mussx  erledigt G-083GUIselbstDer Betreiber kann Details der Rechnungen kontrollierenZur Kontrolle der Daten im System28.6.022mussx xerledigt G-084GUIselbstDer Betreiber kann Rechungen löschen.Zur Wartung der Daten im System.28.6.023mussx xerledigt G-085GUIselbstEinhalten der Sicherheitsrichtliniensiehe S-0211.7.021mussx xin Arbeit G-086GUIselbstDer Betreiber kann die Benutzer (Rechungsempfänger, Rechnungssteller, Finanzdienstleister) Gruppen zuordnen.Die Sicherheitsgruppen werden für die Einordnung der Rechte der Benutzer benötigt.5.7.022mussx xentfälltbislang kein WorkflowG-087GUIselbstDer Betreiber kann Sicherheitsgruppen anlegen, löschen und editieren.Bearbeiten der Sicherheitsgruppen.5.7.022mussx xentfällt,die Zuordnung der Workflows zu Gruppen ist statisch G-088GUIselbstDer Betreiber kann über die GUI Systemjobs anlegen und löschen.?5.7.022mussx xerledigt G-089GUI selbstDer Betreiber kann über die GUI Systemjobs zur Ausführung anstossen.?5.7.022mussx xentfällt, von BL nicht vorgesehenG-090GUIselbst Der Betreiber stellt ein Interface für das hinzufügen und löschen von CPP bzw. CPAsZur Wartung des Datenkonverters.5.7.022mussx xentfälltbislang kein Workflow definiertG-091GUIselbst Die Kunden-ID des Rechnungsempfängers muss vom Rechnungssteller vor der Inanspruchnahme von Com42Bill als Zahlungsmethode überprüft werden, Dies soll realisiert werden durch eine Umleitung auf die Com42Bill-Login-Seite, wo der Rechnungsempfänger sich anmelden kann. Danach erfolgt der Rücksprung zur Rechnungssteller-Seite mit entsprechender Rückmeldung.Sicherheit.5.7.022kannx xentfällt Business Logic (BL) IDBetroffene Komp.Abgedeckt durchBeschreibungBegründung   DatumPrioTypFNFSRStatusBegründung für Status entfällt.BL-001BLselbstAbbilden aller im System anfallenden Geschäftsprozesse (sowohl für die Durchführung von GUI- und ImpEx-Requests, wie auch administrative Tätigkeiten des Betreibers)Hauptaufgabe der Komponente BL4.6.021muss x erledigt BL-002BLselbstWorkflowmanager startet und steuert die Workflows, die einem vorher von BL festgelegten Ablauf folgen.Die Ausführung der Geschäftsprozesse muss verwaltet werden30.5.021mussx xerledigt BL-003BLselbstDie Abläufe einzelner Geschäftprozesse, welche von Pipelines realisiert werden, werden in Form von XML-Files festgehalten.Die Geschäftsprozesse können mit Pipelines sehr anschaulich und flexibel modelliert werden. Die Verfügbarkeit von Tools ist zu klären30.5.021mussx  erledigt BL-004BLselbstRealisierung einer GUI für das Modellieren von PipelinesJe nachdem, wie oft sich die Geschäftsprozesse um Laufe der Projektgruppe noch ändern und wie erweiterbar das System im Anschluss sein soll, ist das Handling der reinen XML-Dateien nach Möglichkeit abzulösen4.6.023kannx  entfälltDiese Funktionaltät war optional angedacht, um die Usabilty zu erleichert.BL-005BLselbstWorkflowmanager arbeitet auf Businessobjects die vom Manager oder vom EJB-Container zur Verfügung gestellt werden (hängt vom evtl. Einsatz von SessionBeans ab)Die BusinessObjects als Teile der Pipelines führen die eigentliche BusinessLogic aus30.5.021mussx  erledigt BL-006BLselbstBusinesspartnermanager verwaltet alle Daten die für einen Businesspartner notwendig ist. Der Manager kann Kundenkonten anlegen, erfragen, löschen, bearbeiten usw.Die Rollen müssen im System repräsentiert werden30.5.022mussx xerledigt BL-007BLselbstInvoicemanager ist für die Rechnungsdatenverwaltung zuständig. Er bietet Funktionen zur Speicherung von Rechnungen und deren Zuordnung zu Businesspartnern. Da man Rechnungen nicht löschen können sollte, muss es möglich sein, sie zu stornieren. Ebenso mussLogisch30.5.022mussx xerledigt BL-008BLselbstPaymentManager ist für das Bezahlungsmanagement der Rechnungen verantwortlich. Hiermit werden die Finanztransaktionen vorbereitet und verarbeitetEbenfalls essentiell für ein EBPP-System30.5.022mussx xerledigt BL-009BLselbstAlertmanager ist für alle anfallenden Benachrichtigungen im Rahmen der Rechnungsabhandlung zuständigBenachrichtigungsdienste sind zwar unerlässlich, stellen jedoch nicht die Basisfunktionalität des Systems sicher4.6.023mussx xerledigt BL-010BLselbstReportmanger ist für das Erzeugen von Berichten, sowie zum Abrufen von Statistiken zuständigSehr nützliche Funktionalität sowohl für Rechnungssteller als auch -empfänger. Jedoch keine Basisfunktionalität30.5.024mussx xentfälltDiese ist ein illusionarische Anforderung. Es hatte auf "kann" stehen müssen.BL-011BLselbstPersonalisationmanager ist für die an die Kundenwünsche angepasste Umgebung zuständig Value-Added-Service30.5.024kannx xentfälltDiese Funktionalität wird nirgends gefordert. Aber die Entities sind voehanden.BL-012BLselbstTransaktionsmanagment sollte vom EJB-Container unterstützt werden. Gegebenenfalls müssen die Funktionalitäten erweitert werden.Geschäftsprozesse müssen als Einheit ausgeführt werden können, um die Konsistenz der Daten zu wahren30.5.021mussx  erledigt BL-013GUIG-058Überreichen eines RequestDictionary, eines GUI-Requests, aus dem der zu startende Workflow ersichtlich ist und evtl. einer gültigen Session. Die Abarbeitung des Workflows wird vom Workflow-Adapter initiiert.BL ist nur eine passive Komponente, d.h. wird immer von anderen Komponenten angestoßen. Wenn dies geschieht, muss aus dem Aufruf hervorgehen, welcher Geschäftsprozess unter welchen Umständen zu starten ist30.5.021mussx xerledigt BL-014GUIG-050Überprüfen der Formulardaten, welche mit dem RequestDictionary übergeben werden auf TypkorrektheitDie BL führt nur die inhaltliche Korrektheitsüberprüfung der Daten durch4.6.022muss x offen BL-015GUIG-068Bereitstellen von Template-Mechanismen, welche es ermöglichen, aus einem Geschäftsprozess Benachrichtungen via Mail, SMS etc. zu verschicken.Das Erscheinungsbild der zu verschickenden Benachrichtigungen sollte schnell anpassbar sein und von den Inhalten, welche im Geschäftsprozess ermittelt werden, abstrahiert werden4.6.023mussx xentfälltSiehe GUIBL-016GUIG-058,G-059Überreichen eines RequestDictionary, eines ImpEx-Requests, aus dem der zu startende Workflow ersichtlich ist, und ebenfalls einer Session. Die Abarbeitung des Workflows wird vom Workflow-Adapter initiiert.Hier gilt das selbe wie unter BL-013, jedoch für Requests, welche vom Datenkonverter stammen30.5.021mussx xerledigt BL-017DBDB-012Datenbankkomponente stellt die EJB-Entity-Objekte für die Speicherung der in den Workflows anfallenden Daten bereit. Ebenso müssen gewünschte Daten in Form von EJB-Objekten abgerufen werden könnenDie Datenbankkomponente ist der einzige Datenbehälter für fachliche Daten30.5.021mussx xerledigt BL-018GUIG-054Das Durchführen eines Workflows über den Workflow-Adapter muss bereits autorisiert sein.Die Komponente BL führt selber keine Autorisierung / Authentifizierung durch. Daher muss diese Funktionalität von der Komponente GUI vorher sichergestellt werden30.5.021muss x erledigt BL-019DK Das Durchführen eines Workflows über den Workflow-Adapter muss bereits autorisiert sein.Die Komponente BL führt selber keine Autorisierung / Authentifizierung durch. Daher muss diese Funktionalität von der Komponente Datenkonverter vorher sichergestellt werden30.5.021muss x erledigt BL-020BLselbstZurückgegeben eines Ergebnisses nach einem Workflowdurchlauf, weitere Statusmeldungen werden im RequestDictaionary abgelegtGUI und DK müssen Antwort auf Request erhalten25.6.021mussx xerledigt BL-021BLselbstBereitstellen eines Communication Service, mit dessen Hilfe Mails und andere Nachrichten aus einem Workflow heraus verschickt werden könnenNotwendig für Benachrichtigungsdienste25.6.022mussx  erledigt BL-022BLselbstBereitstellen einer Jobverwaltung, welche zeitgesteuert oder auch manuell ausgelöste Workflows starten kannNotwenig, um z.B. Finanztransaktionen zeitgesteuert durchführen zu können, oder Benachrichtigungen zu verschicken25.6.022mussx  erledigt BL-023BL So wenig Daten wie möglich übertragensiehe S-00325.6.021muss x entfälltSiehe neue Sicherheits-anforderungenBL-024BL Verantwortlichkeit für übertragene Datensiehe S-00525.6.021muss x entfälltSiehe neue Sicherheits-anforderungenBL-025BL Nur eigene Daten speichernsiehe S-00725.6.021muss x entfälltSiehe neue Sicherheits-anforderungenBL-026BLselbstEvtl. Bereistellen eines Query-Frameworks, mit dessen Hilfe dynamisch konfigurierte Suchabfragen durchgeführt werden könnenHilft bei Suchfunktionen und Auswertungen, jedoch hoher Implementierungsaufwand25.6.023kannx  entfälltDiese Komponete ist die Verbesserung der requestgeschwingkeit angedacht gewesen. Eine Searchfunktion ist auf Programmierebne implementiert.BL-027BLselbstEinhalten der Sicherheitsrichtliniensiehe S-02130.6.021muss x erledigt BL-028GUIG-088, G-089Die GUI muss eine Benutzeroberfläche bereitstellen, mit deren Hilfe man Systemjobs anlegen, löschen und anstossen kann.Administration10.7.022mussx  erledigt Sicherheit (S) IDBetroffene Komp.Abgedeckt durchBeschreibungBegründung   DatumPrioTypFNFSRStatusBegründung für Status entfällt.S-001GUI Es werden keine Daten auf dem Klienten gehalten. Ein eventueller Datenexport ist davon ausgenommen.Daten könnten in falsche Hände geraten.30.5.021muss x erledigtAuslagerung in die Sicherheitsrichlinien. S-002GUI, BL Die Daten werden in verarbeiteter, d.h. endgültiger Form, übermittelt.Klienten müssen keine Verarbeitungslogik besitzen.30.5.021muss x erledigtAuslagerung in die Sicherheitsrichlinien.S-003GUI, DK, DB, BL Es werden so wenig Daten wie möglich übertragen, d.h. die zu übertragenden Daten werden auf das nötigste beschränkt.Performance und Datensicherheit.30.5.021muss x erledigtAuslagerung in die Sicherheitsrichlinien.S-004GUI, DK Ist eine Datenübertragung außerhalb des Betreibers nötig, wird nur über sichere Verbindungen kommuniziert.Datensicherheit.30.5.021muss x entfällt, von S nicht unterstütztVerschlüsselung wird wegen nicht vorhandener PGP Infrastruktur nicht umgesetzt.S-005GUI, DK, DB, BL Jede Komponente ist für die übertragenen Daten verantwortlich.Jede Komponente muss wissen ob der Empfänger die Daten, welche er anfordert, wirklich bekommen darf.30.5.021muss x entfälltAuslagerung in die Sicherheitsrichlinien.S-006GUI, DK, BL Daten werden ausschließlich in der Datenbank gespeichert.Datensicherheit und Datenintegrität.30.5.021muss x entfälltAuslagerung in die Sicherheitsrichlinien.S-007GUI, DK, BL Es werden nur Daten, die von der jeweiligen Komponente verwaltet werden, gespeichert.Komponenten speichern keine Daten, welche sie von anderen Komponenten erhalten haben. Aktualität der Daten und Datensicherheit.30.5.021muss x entfälltAuslagerung in die Sicherheitsrichlinien.S-008S Benutzer des Systems müssen sich über die Komponente Sicherheit anmelden.Anmeldung.30.5.021muss xxentfälltAuslagerung in die Sicherheitsrichlinien.S-009DKDK-001Die Komponente Datenkonverter muss, zur Anmeldung eines Benutzers an das System, der Komponente Sicherheit den Benutzernamen, das Passwort und die benutzte Schnittstelle übermitteln.Anmeldung eines Benutzers der Komponente Datenkonverter.30.5.021mussx xerledigt S-010DKDK-004Die Komponente Datenkonverter übergibt der Komponente Sicherheit, zur Überprüfung einer auszuführenden Aktion, die Session-ID und die gewünschte Aktion.Authorisierung einer Aktion der Komponente Datenkonverter.30.5.021mussx xerledigt S-011SselbstNachdem überprüft wurde ob die gewünschte Aktion zulässig ist, erteilt die Komponente Sicherheit der Komponente Datenkonverter die Erlaubnis bzw. ein Verbot.Authorisierung einer Aktion der Komponente Datenkonverter.30.5.021mussx xerledigt S-012SselbstDie Komponente Sicherheit übergibt, nach erfolgter Anmeldung, der Komponente Datenkonverter eine Session-ID und den Benutzernamen, welcher zu dieser Session gehört.Anmeldung eines Benutzers der Komponente Datenkonverter.30.5.021mussx xerledigt S-013GUIG-052Bei einer "anonymen Anfrage" übergibt die Komponente GUI der Komponente Sicherheit die gewünschte Aktion.Authorisierung einer Aktion der Komponente GUI.30.5.021mussx xerledigt S-014GUIG-052Die Komponente GUI übergibt der Komponente Sicherheit, zur Überprüfung einer auszuführenden Aktion, die Session-ID und die gewünschte Aktion.Authorisierung einer Aktion der Komponente GUI.30.5.021mussx xerledigt S-015SselbstNachdem überprüft wurde ob die gewünschte Aktion zulässig ist, erteilt die Komponente Sicherheit der Komponente GUI die Erlaubnis bzw. ein Verbot.Authorisierung einer Aktion der Komponente GUI.30.5.021mussx xerledigt S-016GUIG-044Die Komponente GUI muss, zur Anmeldung eines Benutzers an das System, der Komponente Sicherheit den Benutzernamen, das Passwort und die benutzte Schnittstelle übermitteln.Anmeldung eines Benutzers der Komponente GUI.30.5.021mussx xerledigt S-017SselbstDie Komponente Sicherheit übergibt, nach erfolgter Anmeldung, der Komponente GUI eine Session-ID und den Benutzernamen, welcher zu dieser Session gehört.Anmeldung eines Benutzers der Komponente GUI.30.5.021mussx xerledigt S-018DBDB-007Die Komponente Datenbank muss der Komponente Sicherheit Methoden zur Verfügung stellen, mit deren Hilfe die Komponente Sicherheit Daten ablegen kann.Speicherung der Komponentendaten.30.5.021mussx xerledigt S-019SselbstDie Komponente Sicherheit muss Methoden zur Verschlüsselung bereitstellen.Datensicherheit.14.6.021mussx  erledigt S-020SselbstDie Komponente Sicherheit überprüft anhand der digitalen Signatur, obe die Daten, welche dem Datenkonverter übertragen wurden unverändert sind. Es wird ebenfalls die Identität des Absender überprüft.Datensicherheit.22.6.021mussx xentfälltVerschlüsselung wird wegen nicht vorhandener PGP Infrastruktur nich umgesetzt.S-021AlleDK-032; DB-024; BL-027;G-085Die Komponenten müssen sich an die Sicherheitsrichtlinien halten.Sicherheit.22.6.021muss x entfälltAuslagerung in die Sicherheitsrichlinien.S-022SselbstDie Komponente Sicherheit muss eine Public-Key Infrastruktur bereitstellen.Datensicherheit.27.6.021mussx xentfälltVerschlüsselung wird wegen nicht vorhandener PGP Infrastruktur nich umgesetzt.S-023SselbstDie Komponente Sicherheit muss Methoden zur Signierung von Nachrichten bereitstellen.Datensicherheit.27.6.021mussx xentfälltVerschlüsselung wird wegen nicht vorhandener PGP Infrastruktur nich umgesetzt.S-024SselbstDie Komponente Sicherheit weißt den Benutzer auf ein veraltetes Kennwort hin.Sicherheit.27.6.021mussx  entfälltFeature wurde nicht mehr gewünscht.S-025SselbstDie Komponente Sicherheit stelle Methoden zur Verfügung, um Benutzer anzulegen, zu bearbeiten und zu löschen.Benutzeradministration.10.7.021mussx xin ArbeitDurch DB.S-026SselbstDie Komponente Sicherheit stelle Methoden zur Verfügung, um ACL-Groups anzulegen, zu bearbeiten und zu löschen.Benutzeradministration.10.7.021mussx xin ArbeitDurch DB.S-027SselbstDie Komponente Sicherheit stelle Methoden zur Verfügung, um Request-Types anzulegen, zu bearbeiten und zu löschen.Benutzeradministration.10.7.021mussx xin ArbeitWird nich benötigt.S-028GUIG-075, G-078, G-081Die Komponente GUI stellt eine Benutzeroberfläche zur Verfügung mit deren Hilfe man Benutzer anlegen, bearbeiten und löschen kann.Benutzeradministration.10.7.021mussx xin ArbeitGUI nicht vorgesehen.S-029GUIG-086, G-087Die Komponente GUI stellt eine Benutzeroberfläche zur Verfügung mit deren Hilfe man ACL-Groups anlegen, bearbeiten und löschen kann.Benutzeradministration.10.7.021mussx xin ArbeitGUI nicht vorgesehen.S-030GUInicht abgedeckt ??Die Komponente GUI stellt eine Benutzeroberfläche zur Verfügung mit deren Hilfe man Request-Types anlegen, bearbeiten und löschen kann.Benutzeradministration.10.7.021mussx xin ArbeitGUI nicht vorgesehen.Datenbank (DB) IDBetroffene Komp.Abgedeckt durchBeschreibungBegründung   DatumPrioTypFNFSRStatusBegründung für Status entfällt.DB-001DK Es muß eine Datenstruktur für das ebXML-Repository definiert werden30.5.022muss xxentfälltWurde von DK übernommen DB-002DK Die Methoden für den Zugriff auf das ebXML-Repository müssen definiert werden30.5.022muss xxentfälltWurde von DK übernommen DB-003DBselbstImplementierung eines DB-User-basierten ZugriffsschutzesVerhinderung von unberechtigten Zugriffen auf die gespeicherten Daten 31.5.021mussx  entfällt von S übernommenDB-004DB Konfiguration des Transaktions-ManagementsSicherstellung, dass Zugriffsvorgänge auf die DB vollständig durchgeführt werden1.6.022mussx  erledigt DB-005DBselbstBeschleunigung des Zugriffs auf DatenhaltungMöglichst schneller Zugriff auf gespeicherte Daten2.6.022kannx  entfällt DB-006DBselbstKonfiguration der SerialisierungErfolgt automatisch durch AppServer3.6.022mussx  erledigt DB-007DBselbstImplementierung der Zugriffsfunktionalitäten Anlegen, Löschen, Ändern, Lesen, Suchen nach Vorgabe der entsprechenden Komponenten 4.6.022mussx xin Arbeit DB-008GUIselbstFestlegung der Entitäten, die global für andere Komponenten verfügbar sein sollen 5.6.022muss xxerledigt DB-009BLselbstFestlegung der Entitäten, die global für andere Komponenten verfügbar sein sollen 5.6.022muss xxerledigt DB-010DKselbstFestlegung der Entitäten, die global für andere Komponenten verfügbar sein sollen 5.6.022muss xxerledigt DB-011SselbstFestlegung der Entitäten, die global für andere Komponenten verfügbar sein sollen 5.6.022muss xxerledigt DB-012DBselbstAlle Entitäten (auch vererbte) des Objektmodells sollen als Tabellen abgebildet werden, ihre Attribute werden als Spalten der entsprechenden Tabellen realsiert 6.6.022mussx  erledigt DB-013BLselbstFestlegen der Methoden für Mgr-SubkomponentenFür die Implementierung von HomeInterfaces wichtig12.6.022mussx xerledigt DB-014DBselbstBereitstellen von Methoden für Aufbau der DB-Verbindungen (ConnectionPool)Erfolgt automatisch durch AppServer12.6.022mussx xerledigt DB-015DBselbstBereitstellen von get/set Methoden für Entity-BeansFür den Zugriff auf die Attribute der Entity-Beans wichtig12.6.021mussx xerledigt DB-016DBselbstErmöglichung von Container Management PersistenzEntlastung der BL12.6.021mussx  erledigt DB-017DBselbstDaten, die systemweit gültig sind (Entitäten des Package CORE im Objektmodell), werden in einem DB-Bereich gespeichert, der allen autorisierten Komponenten zugänglich istTrennung von Globalen und Komponenten-eigenen Daten zwecks Datenintegrität und Verteilbarkeit18.6.021muss x erledigt DB-018DKselbstAlle Daten einer Komponente werden in einem exclusiven Bereich der DB gespeichertSicherung der Datenkonsistenz, Datenintegrität, leichte Austauschbarkeit der Daten18.6.021muss x erledigt DB-019SselbstAlle Daten einer Komponente werden in einem exclusiven Bereich der DB gespeichertSicherung der Datenkonsistenz, Datenintegrität, leichte Austauschbarkeit der Daten18.6.021muss x erledigt DB-020BLselbstAlle Daten einer Komponente werden in einem exclusiven Bereich der DB gespeichertSicherung der Datenkonsistenz, Datenintegrität, leichte Austauschbarkeit der Daten18.6.021muss x erledigt DB-021GUIselbstAlle Daten einer Komponente werden in einem exclusiven Bereich der DB gespeichertSicherung der Datenkonsistenz, Datenintegrität, leichte Austauschbarkeit der Daten18.6.021muss x erledigt DB-022DBselbstAlle Daten einer Komponente werden in einem exclusiven Bereich der DB gespeichertSicherung der Datenkonsistenz, Verteilbarkeit der DB18.6.021muss x erledigt DB-023DBselbstDer Zugriff auf die Daten einer Komponente erfolgt exclusiv und ausschliesslich durch sie selbstSicherung der Datenkonsistenz18.6.021muss x erledigt DB-024DBselbstDie Sicherheitsrichtlinien müssen eingehalten werden.S-02127.6.021muss x erledigt  Projektplan Projektplan (tabellarisch) Im Folgenden wird der Projektplan in tabellarischer Form dargestellt. Kennenlernfahrt & Seminarphase Task-IDTask NameDauerStartEnde Kick-Off Nordhelle3 Tage10.04.200212.04.2002 Datenkonverter Task-IDTask NameDauerStartEndeDK-01Anforderungsanalyse41 Tage16.05.200211.07.2002Anforderungsdokument1 Tage15.07.200215.07.2002DK-02Systemarchitektur119 Tage06.05.200216.10.2002Dokument Systemarchitektur1 Tage16.10.200216.10.2002DK-03Klassenmodell67 Tage16.07.200215.10.2002UML-Diagramm Klassenmodell1 Tage15.10.200215.10.2002DK-04Objektmodell51 Tage28.06.200206.09.2002UML-Diagramm Objektmodell1 Tage06.09.200206.09.2002DK-05Objektdesign79 Tage16.07.200231.10.2002Designdokument1 Tage15.10.200215.10.2002DK-06Prototyp (Key Features)45 Tage16.07.200213.09.2002DK-06.1CPP für Com42Bill10 Tage15.07.200226.07.2002DK-06.2CPAs definieren5 Tage29.07.200202.08.2002DK-06.3Austauschformat/Dokumentstruktur5 Tage05.08.200209.08.2002DK-06.4MsgServiceInterfaceHandler10 Tage12.08.200223.08.2002DK-06.5MsgServiceInterface25 Tage23.08.200225.09.2002Lauffähiger Prototyp1 Tage01.10.200201.10.2002DK-07 Implementierung70 Tage07.10.200210.01.2003DK-07.1Spezifikation des Request-Dictionarys70 Tage07.10.200210.01.2003DK-07.2Verfeinerung der Architektur65 Tage14.10.200210.01.2003DK-07.3Klassendiagramm (grob)3 Tage08.01.200310.01.2003DK-07.4Erstellung und Dokumentation des CPP & CPA60 Tage21.10.200210.01.2003DK-07.5BusinessServiceInterface4 Tage07.01.200310.01.2003DK-07.6MsgServiceHandler5 Tage06.01.200310.01.2003DK-07.7CPAParser2 Tage09.01.200310.01.2003DK-07.8ImpExpMgr45 Tage11.11.200210.01.2003DK-07.9Darstellung der Rechnung und Überweisung im Browser10 Tage13.01.200324.01.2003Lauffähige Komponente27 Tage10.01.200314.02.2003 GUI Task-IDTask NameDauerStartEndeGUI-01Anforderungsanalyse40 Tage17.05.200211.07.2002Anforderungsdokument1 Tage11.07.200211.07.2002GUI-02Systemarchitektur46 Tage17.05.200219.07.2002Dokument Systemarchitektur1 Tage21.06.200221.06.2002GUI-03Klassenmodell84 Tage16.07.200207.11.2002UML-Diagramm Klassenmodell1 Tage07.11.200207.11.2002GUI-04Objektmodell98 Tage17.05.200230.09.2002UML-Diagramm Objektmodell1 Tage30.09.200230.09.2002GUI-05Objektdesign81 Tage16.07.200204.11.2002Designdokument1 Tage04.11.200204.11.2002GUI-06Navigationsstruktur12 Tage23.10.200207.11.2002GUI-06.1HTML12 Tage23.10.200207.11.2002GUI-06.2WAP12 Tage23.10.200207.11.2002Dokumentation1 Tage07.11.200207.11.2002GUI-07Prototyp (Key-Features)55 Tage10.07.200223.09.2002GUI-07.1Syntaxkontrolle55 Tage10.07.200223.09.2002GUI-07.2Datenbank-Templates55 Tage10.07.200223.09.2002GUI-07.3Presenter55 Tage10.07.200223.09.2002GUI-07.4Workflowtest55 Tage10.07.200223.09.2002GUI-07.5History55 Tage10.07.200223.09.2002Lauffähiger Prototyp1 Tage23.09.200223.09.2002GUI-08Implementierung96 Tage01.10.200210.02.2003GUI-08.1RequestServlet96 Tage01.10.200210.02.2003GUI-08.2RequestDispatcher96 Tage01.10.200210.02.2003GUI-08.3HistoryController96 Tage01.10.200210.02.2003GUI-08.4RequestPresenter96 Tage01.10.200210.02.2003GUI-08.5WorkflowAdapter96 Tage01.10.200210.02.2003GUI-08.6HTML/WAP96 Tage01.10.200210.02.2003Lauffähige Komponente1 Tage28.02.200328.02.2003 Sicherheit Task-IDTask NameDauerStartEndeS-01Anforderungsanalyse55 Tage26.04.200211.07.2002Anforderungsdokument1 Tage15.07.200215.07.2002S-02Systemarchitektur55 Tage06.05.200219.07.2002Dokument Systemarchitektur1 Tage19.07.200219.07.2002S-03Klassenmodell67 Tage16.07.200215.10.2002UML-Diagramm Klassenmodell1 Tage15.10.200215.10.2002S-04Objektmodell45 Tage08.07.200206.09.2002UML-Diagramm Objektmodell1 Tage06.09.200206.09.2002S-05Objektdesign67 Tage16.07.200215.10.2002Designdokument1 Tage15.10.200215.10.2002S-06Prototyp (Key-Features)51 Tage09.07.200216.09.2002S-06.1Autorisierung GUI25 Tage15.07.200216.08.2002S-06.2Authentifizierung GUI6 Tage19.08.200226.08.2002S-06.3Autorisierung DK3 Tage27.08.200229.08.2002S-06.4Authentifizierung DK4 Tage30.08.200204.09.2002S-06.5Administration9 Tage05.09.200216.09.2002S-06.6Kennwort1 Tage16.09.200216.09.2002S-07Implementierung69 Tage17.09.200220.12.2002S-07.1Session Manager29 Tage17.09.200225.10.2002S-07.2Request Authorization30 Tage28.10.200206.12.2002S-07.2.1Authentification25 Tage28.10.200229.11.2002S-07.2.2Authorization25 Tage04.11.200206.12.2002S-07.3Administration30 Tage11.11.200220.12.2002Lauffähige Komponente1 Tage20.12.200220.12.2002 Business Logic Task-IDTask NameDauerStartEndeBL-01Anforderungsanalyse60 Tage15.04.200205.07.2002Anforderungsdokument1 Tage05.07.200205.07.2002BL-02Systemarchitektur29 Tage04.06.200212.07.2002Dokument Systemarchitektur1 Tage12.07.200212.07.2002BL-03Klassenmodell67 Tage16.07.200215.10.2002UML-Diagramm Klassenmodell1 Tage15.10.200215.10.2002BL-04Objektmodell80 Tage20.05.200206.09.2002UML-Diagramm Objektmodell1 Tage06.09.200206.09.2002BL-05Objektdesign67 Tage16.07.200215.10.2002Designdokument1 Tage15.10.200215.10.2002BL-06Prototyp (Key-Features)56 Tage15.07.200227.09.2002BL-06.1Rechnungsempfängerverwaltung56 Tage15.07.200227.09.2002BL-06.2BusinessObjects für Beispielworkflow36 Tage05.08.200220.09.2002BL-06.3Modellierung eines Beispielworkflows36 Tage12.08.200227.09.2002BL-06.4Workflowverwaltung25 Tage27.08.200227.09.2002BL-06.5Ergbnisrückgabe an GUI (Interaktion)15 Tage09.09.200227.09.2002BL-07Implementierung71 Tage14.10.200220.01.2003BL-07.1BPML Engine48 Tage14.10.200218.12.2002BL-07.2AlertMgr46 Tage14.10.200216.12.2002BL-07.3PamentMgr 46 Tage14.10.200216.12.2002BL-07.4Business Objects46 Tage18.11.200220.01.2003BL-07.5Workflow modellieren46 Tage18.11.200220.01.2003BL-07.5.1Invoice BO46 Tage29.11.200231.01.2003BL-07.5.2BusinessPartner BO46 Tage29.11.200231.01.2003BL-07.5.3Payment BO46 Tage09.12.200207.02.2003BL-07.5.4Alert BO46 Tage09.12.200207.02.2003BL-07.5.5Core BO46 Tage09.12.200207.02.2003BL-07.6Businesspartner Manager46 Tage14.10.200216.12.2002BL-07.7Invoice Manager46 Tage14.10.200216.12.2002BL-07.8Job Manager65 Tage18.11.200213.02.2003Lauffähige Komponente1 Tage28.02.200328.02.2003 Datenbank Task-IDTask NameDauerStartEndeDB-01Anforderungsanalyse64 Tage15.04.200211.07.2002Anforderungsdokument1 Tage11.07.200211.07.2002DB-02Objektmodell Com42Bill95 Tage29.04.200206.09.2002UML-Diagramm Objektmodell1 Tage06.09.200206.09.2002DB-03Klassenmodell DataBaseAccess.67 Tage16.07.200215.10.2002UML-Diagramm Klassenmodell1 Tage15.10.200215.10.2002DB-04Objektdesign DataBaseAccess67 Tage16.07.200215.10.2002Designdokument1 Tage15.10.200215.10.2002DB-05Installation DB-Server5 Tage01.07.200205.07.2002DB-06Konfiguration DB-Server15 Tage08.07.200226.07.2002DB-06.1User15 Tage?08.07.200226.07.2002DB-06.2Netzwerkanbindung15 Tage?08.07.200226.07.2002DB-06.3Sicherheit15 Tage?08.07.200226.07.2002Ergebnis1 Tage26.07.200226.07.2002DB-07Prototyp (Key-Features)56 Tage15.07.200227.09.2002DB-07.1Persistenz Rechnungen46 Tage15.07.200215.09.2002DB-07.2Persistenz Zahlungsvorgang46 Tage15.07.200215.09.2002DB-07.3Persistenz Businesspartner56 Tage15.07.200227.09.2002DB-07.4Persistenz Systemdaten56 Tage15.07.200227.09.2002DB-07.5Persistenz User56 Tage15.07.200227.09.2002DB-07.6Persistenz GUI56 Tage15.07.200227.09.2002DB-07.7Persistenz Datenkonverter56 Tage15.07.200227.09.2002DB-07.8Persistenz Sicherheit56 Tage15.07.200227.09.2002Lauffähiger Prototyp1 Tage27.09.200227.09.2002DB-08Implementierung75 Tage21.10.200231.01.2003DB-08.1Businesspartner: Invoicing Party, InvoiceRecipient, ProfileGroup9 Tage30.10.200211.11.2002DB-08.2core.common9 Tage30.10.200211.11.2002DB-08.3core.job9 Tage30.10.200211.11.2002DB-08.4core.session9 Tage30.10.200211.11.2002DB-08.5core.user9 Tage30.10.200211.11.2002DB-08.6core.workflow9 Tage30.10.200211.11.2002DB-08.7Businesspartner: FinancialServiceProvider, PersonDataSheet, CompanyDataSheet6 Tage11.11.200218.11.2002DB-08.8UserInformation- InvoicingParty6 Tage11.11.200218.11.2002DB-08.9UserInformation- InvoiceRecipient6 Tage11.11.200218.11.2002DB-08.10security6 Tage11.11.200218.11.2002DB-08.11UserInformation- Group6 Tage11.11.200218.11.2002DB-08.12invoice6 Tage11.11.200218.11.2002DB-08.13Invoice- InvoiceContainer6 Tage11.11.200218.11.2002DB-08.14PaymentTransaction- InvoiceContainer6 Tage11.11.200218.11.2002DB-08.15Adress, ProfileGroupAssignment 6 Tage18.11.200225.11.2002DB-08.16FinancialAccount, FinancialAccountAttributes6 Tage18.11.200225.11.2002DB-08.17alert6 Tage18.11.200225.11.2002DB-08.18PaymentWarning- Invoice6 Tage18.11.200225.11.2002DB-08.19InvoiceReminder- Invoice6 Tage18.11.200225.11.2002DB-08.20gui6 Tage25.11.200202.12.2002DB-08.21InvoiceRecipient- History6 Tage25.11.200202.12.2002DB-08.22InvoicingParty- History6 Tage25.11.200202.12.2002DB-08.23payment6 Tage25.11.200202.12.2002DB-08.24SessionInformation- UserInformation6 Tage25.11.200202.12.2002DB-08.25Invoice- InvoiceRecipient6 Tage25.11.200202.12.2002DB-08.26PaymentTransaction- FinancialAccount6 Tage25.11.200202.12.2002DB-08.27WorkflowStartNodeEntry- Group6 Tage25.11.200202.12.2002Lauffähiger Komponente1 Tage28.02.200328.02.2003 Projektmanagement Task-IDTask NameDauerStartEndeProjektplan1 Tage14.06.200214.06.2002Pflege und Wartung des Projektplans182 Tage17.06.200221.02.2003Review Projektplan 11 Tage22.08.200222.08.2002Review Projektplan 21 Tage19.09.200219.09.2002Review Projektplan 31 Tage21.10.200221.10.2002Review Projektplan 41 Tage28.10.200228.10.2002Review Projektplan 51 Tage04.11.200204.11.2002Review Projektplan 61 Tage18.11.200218.11.2002Review Projektplan 71 Tage02.12.200202.12.2002Review Projektplan 81 Tage16.12.200216.12.2002Review Projektplan 91 Tage13.01.200313.01.2003Review Projektplan 101 Tage20.01.200320.01.2003Review Projektplan 111 Tage03.02.200303.02.2003Review Projektplan 121 Tage17.02.200317.02.2003Abwesenheitszeiten organisieren143 Tage09.08.200221.02.2003 Marketing Task-IDTask NameDauerStartEndeT-Shirts1 Tage28.06.200228.06.2002Whitepaper33 Tage16.05.200201.07.2002Zwischenbericht31 Tage22.07.200202.09.2002Plakat54 Tage08.08.200221.10.2002Abschlußbericht37 Tage20.01.200310.03.2003Präsentation in Dortmund um 10 Uhr R3181 Tage28.03.200328.03.2003 Qualitätsmanagement Task-IDTask NameDauerStartEndeCode Guide1 Tage28.06.200228.06.2002Testplan Integrationstest1 Tage27.12.200227.12.2002Testplan Systemtest1 Tage31.01.200331.01.2003Pflege und Wartung des Anforderungsdokuments177 Tage21.06.200220.02.2003Pflege und Wartung der Key-Feature152 Tage26.07.200220.02.2003Erstellung eines Prozessmodells24 Tage24.06.200225.07.2002Pflege und Wartung des Prozessmodells152 Tage26.07.200220.02.2003 Klassenreviews Task-IDTask NameDauerStartEndeSicherheit1 Tage10.12.200210.12.2002GUI1 Tage12.12.200212.12.2002DK1 Tage16.01.200316.01.2003DB1 Tage22.01.200322.01.2003BL1 Tage24.01.200324.01.2003 Klassentests Task-IDTask NameDauerStartEndeSicherheit1 Tage21.01.200321.01.2003DB6 Tage24.01.200331.01.2003GUI1 Tage24.01.200324.01.2003DK1 Tage27.01.200327.01.2003BL1 Tage30.01.200330.01.2003 Klassenreviews Task-IDTask NameDauerStartEndeSicherheit1 Tage10.12.200210.12.2002GUI1 Tage12.12.200212.12.2002DK1 Tage16.01.200316.01.2003DB1 Tage22.01.200322.01.2003BL1 Tage24.01.200324.01.2003 Integrationstests Task-IDTask NameDauerStartEndeGUI - DK1 Tage30.01.200330.01.2003GUI - BL1 Tage31.01.200331.01.2003GUI - Sicherheit1 Tage31.01.200331.01.2003DK - Sicherheit1 Tage03.02.200303.02.2003DK -BL13 Tage30.01.200315.02.2003BL - DB6 Tage07.02.200315.02.2003 GUI Task-IDTask NameDauerStartEndeStyle Guide für Web, WAP67 Tage16.07.200215.10.2002 Chefarchitekten Task-IDTask NameDauerStartEndeSystemarchitektur45 Tage29.04.200228.06.2002Pflege und Wartung der Systemarchitektur171 Tage01.07.200220.02.2003Schnittstellenüberwachung130 Tage02.07.200227.12.2002Installation & Einrichtung Bea-Weblogic21 Tage04.07.200201.08.2002 Systemadministration Task-IDTask NameDauerStartEndeEinrichtung Server1 Tage31.05.200231.05.2002Einrichtung Workstations1 Tage31.05.200231.05.2002CVS Repository1 Tage31.05.200231.05.2002Pflege und Wartung der PG Homepage224 Tage17.04.200220.02.2003Installation & Einrichtung Bea-Weblogic21 Tage04.07.200201.08.2002Einrichtung eines FTP-Zugangs 13 Tage20.06.200208.07.2002 Projektplan (grafisch) Nachfolgend ist die grafische Version des Projektplans abgebildet.  Abbildung 79: Projektplan, Teil 1  Abbildung 80: Projektplan, Teil 2  Abbildung 81: Projektplan, Teil 3  Abbildung 82: Projektplan, Teil 4 ebXML-Dokumente Im Folgenden werden die wichtigsten Dokumente, die für das ebXML-Rahmenwerk benötigt werden, dargestellt. CPP für Com42Bill Das CPP dient der öffentlichen Bekanntmachung von Com42Bill. Es beschreibt, welche Geschäftsprozesse, Nachrichtenformate, Kommunikationsschnittstellen etc. Com42Bill unterstützt.   - -  -   4242424242   -  -     -   urn:icann:Com42Bill.de:bpid:bp01 - -       Com42BillChannelHTTP_CH   - -       Com42BillChannelHTTP_CH           -     -   urn:icann:Com42Bill.de:bpid:bp01 - -       Com42BillChannelHTTP_CH   - -       Com42BillChannelHTTP_CH           -     -   urn:icann:Com42Bill.de:bpid:bp01 - -       Com42BillChannelHTTP_CH   - -       Com42BillChannelHTTP_CH           -  - -   ClientCertificateKey?????   ClientCertificateValue?????     - -   ???   ???     - -   ???   ???     - -       -  -     - -   HTTP   basic -   SSL         -   HTTP   basic   -   SSL           - - -   3   PT2H   Guaranteed     P1D   - -   3   PT2H   Guaranteed     P1D       -  -  -   http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd   -  -   www.Com42Bill.de/ebxml/BillingDataImportRequest.xsd   -  -   www.Com42Bill.de/ebxml/BillingDataImportConfirmation.xsd   -  -   www.Com42Bill.de/ebxml/BillingDataStatusRequest.xsd   -  -   www.Com42Bill.de/ebxml/BankTransferDataExportRequest.xsd   -  -   www.Com42Bill.de/ebxml/BankTransferDataFailureConfirmationt.xsd   -  -   www.Com42Bill.de/ebxml/BillingDataStatusConfirmation.xsd   -  -   - -           -  -   - -           -  -   - -           -  -   - -           -  -   - -           -  -   - -             Com42Bill’s Collaboration Protocol Profile   CPA zwischen Com42Bill und einem Rechnungssteller Das CPA stellt einen Vertrag zwischen Com42Bill und einem Rechnungsteller dar, anhand dessen die elektronischen Geschäftstransaktionen zwischen den beiden Parteien durchgeführt werden können.   -     2002-10-01T07:21:00Z   2003-02-28T07:21:00Z -  -   4242424242   -  -     -   urn:icann:Com42Bill.de:bpid:bp01 - -       Com42BillChannelHTTP_CH   - -       Com42BillChannelHTTP_CH           -     -   urn:icann:Com42Bill.de:bpid:bp01 - -       Com42BillChannelHTTP_CH   - -       Com42BillChannelHTTP_CH           -  - -   ClientCertificateKey?????   ClientCertificateValue?????     - -   ???   ???     - -   ???   ???     - -       -  -     - -   HTTP   basic -   SSL         -   HTTP   basic   -   SSL           - - -   3   PT2H   Guaranteed     P1D   - -   3   PT2H   Guaranteed     P1D       -  -   313131313131   -  -     -   urn:icann:Com42Bill.de:bpid:bp01 - -       InvoicingPartyChannelHTTP_CH   - -       InvoicingPartyChannelHTTP_CH           -     -   urn:icann:Com42Bill.de:bpid:bp01 - -       InvoicingPartyChannelHTTP_CH   - -       InvoicingPartyChannelHTTP_CH           -  - -   ClientCertificateKey?????   ClientCertificateValue?????     - -   ???   ???     - -   ???   ???     - -       -  -     - -   HTTP   basic -   SSL         -   HTTP   basic   -   SSL           - - -   3   PT2H   Guaranteed     P1D   - -   3   PT2H   Guaranteed     P1D       -  -  -   http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd   -  -   www.Com42Bill.de/ebxml/BillingDataImportRequest.xsd   -  -   www.Com42Bill.de/ebxml/BillingDataImportConfirmation.xsd   -  -   www.Com42Bill.de/ebxml/BillingDataStatusRequest.xsd   -  -   www.Com42Bill.de/ebxml/BillingDataStatusConfirmation.xsd   -  -   - -           -  -   - -           -  -   - -           -  -   - -             agreement between Com42Bill and Invoicing Party   CPA zwischen Com42Bill und einem Finanzdienstleister Das CPA stellt einen Vertrag zwischen Com42Bill und einem Finanzdienstleister dar, anhand dessen die elektronischen Geschäftstransaktionen zwischen den beiden Parteien durchgeführt werden können.   -     2002-10-01T07:21:00Z   2003-02-28T07:21:00Z -  -   4242424242   -  -     -   urn:icann:Com42Bill.de:bpid:bp01 - -       Com42BillChannelHTTP_CH   - -       Com42BillChannelHTTP_CH           -  - -   ClientCertificateKey?????   ClientCertificateValue?????     - -   ???   ???     - -   ???   ???     - -       -  -     - -   HTTP   basic -   SSL         -   HTTP   basic   -   SSL           - - -   3   PT2H   Guaranteed     P1D   - -   3   PT2H   Guaranteed     P1D       -  -   212121212121   -  -     -   urn:icann:Com42Bill.de:bpid:bp01 - -       BankChannelHTTP_CH   - -       BankChannelHTTP_CH           -  - -   ClientCertificateKey?????   ClientCertificateValue?????     - -   ???   ???     - -   ???   ???     - -       -  -     - -   HTTP   basic -   SSL         -   HTTP   basic   -   SSL           - - -   3   PT2H   Guaranteed     P1D   - -   3   PT2H   Guaranteed     P1D       -  -  -   http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd   -  -   www.Com42Bill.de/ebxml/BankTransferDataExportRequest.xsd   -  -   www.Com42Bill.de/ebxml/BankTransferDataFailureConfirmationt.xsd   -  -   - -           -  -   - -             agreement between Com42Bill and financial service provider   Business Process Specification Schema (BPSS) In dem BPSS werden die Geschäftsprozesse, die Com42Bill durchführen kann, abgebildet.   -  -   doc             - -     -       - -     -       - -     -       -                 -                 -                   XML-Schema für den Import von Rechnungen/Stornos Im Folgenden wird die Formatvorlage für den Austausch von Rechnungen bzw. Stornos dargestellt.   -  - -  - - - -  - - - -  - - - -    -    -    -    -    -    -    -  - - - -  - - - -    -                -  - - - -    -    -                      -  - - - -  - - - -    -    -                        XML-Schema für den Import von Rechnungsstati Im Folgenden wird die Formatvorlage für den Austausch von Statusinformationen zu Rechnungen dargestellt.   -  - -  - - - -  - - - -    -    -    -                  XML-Schema für die Rückmeldung eines Rechnungs- bzw. Stornoimports Im Folgenden wird die Formatvorlage für die Rückmeldung zu einem Rechnungs- bzw. Stornoimport dargestellt.   - - - - -  - - -         -  - - - -  - - - -  - - - -    -    -    -                -  - - - -  - - - -    -    -    -                              XML-Schema für die Rückmeldung eines Rechnungsstatusimports Im Folgenden wird die Formatvorlage für die Rückmeldung zu einem Rechnungsstatusimport dargestellt.   -  -  - - - - -  - - -         -  - - - -  - - - -    -    -    -                        XML-Schema für eine Überweisung Im Folgenden wird die Formatvorlage für eine Überweisung dargestellt.   -  - -  - - - -                  -    -    -            XML-Schema für die Rückmeldung des Finanzdienstleisters Im Folgenden wird die Formatvorlage für die Rückmeldung zu einer Überweisung dargestellt.   -  - -  - - - -    -            Beispiel für eine ebXML Message (Rechnungsimport) Im Folgenden wird am Beispiel eines Rechnungsimports eine ebXML Message dargestellt. Diese setzt sich aus einem SOAP Envelope und einem XML-Attachment zusammen. Das XML-Attachment basiert auf dem XML-Schema aus Anhang C.5. SOAP Envelope    - -   - -   InvoicingParty   BillingDataSender_RLE   -   Com42Bill   BillingDataReceiver_RLE     http://www.Com42Bill.de/ebXML/cpa_Com42Bill_invoicingParty.xml   Conversation   urn:icann:Com42Bill.de:bpid:bp01   BillingDataImportRequestAction -   BillingDataImportRequest   20030224_220628       - - -     ebXML Message         Attachment    -   - -   1234   9876   12.12.2002   222   24.12.2002   1746342   Komplettzahlung       Dokumentation der Workflow-Engine Einleitung In diesem Anhang werden die einzelnen Funktionen, sowie Eingabe- und Ausgabewerte der BusinessObjects beschrieben. Mit diesen ist eine effizientere Modellierung der Workflows möglich, wobei dieses Dokument als Referenz benutzt werden kann. Die Beschreibung eines BusinessObjects besteht aus mehreren Teilen. Zunächst wird der vollständig qualifizierte Klassenname des SessionBeans angegeben. Darunter erfolgt die Angabe des aktuellen Status. Somit ist hier eine ständige Aktualisierung notwendig. Verwaltet werden der Spezifizierungsstatus und der Implementierungsstatus. Im Anschluss erfolgt eine Beschreibung der Funktionalität. Zusätzlich sollte hier angegeben werden, ob das BusinessObject einen „Error-Ausgang“ besitzt und wann dieser benutzt wird. Sollte das BusinessObject eine Transaktion benötigen, wo dies nicht anhand des Namens ersichtlich ist (Insert, Update ...), ist dies hier ebenfalls anzugeben. Im Folgenden sind noch die einzelnen Ein- und Ausgabewerte des BusinessObjects zu beschreiben. Die einzelnen FormValues müssen hier jedoch nicht angegeben werden, da dies zu unübersichtlich werden würde. Somit reicht es, sich auf komplexere Objekte und evtl. Primärschlüsselübergaben zu beschränken. Unter der Spalte Key sollte die entsprechende Variable aus den RequestConstants angegeben werden, welche einen bestimmten Dictionary-Wert kennzeichnet. Datentypen sollten selbsterklärend sein. Beim Typ unterscheidet man zwischen Dictionary-Eingangswerten (RD-IN), Dictionary-Ausgangswerten (RD-OUT) und Properties (PROP, werden im Workflow-Context gesetzt). Zusätzlich ist anzugeben, ob die Werte Pflichtangaben (mandatory) oder optional sind. Zuletzt sollte für jeden Dictionary-Key eine kurze Beschreibung abgegeben werden. BusinessObjects Package BusinessPartner InsertAddress Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.InsertAddressBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Ermittelt, ob sich ein Rechnungssteller oder –empfänger im RD befindet. Erzeugt, wenn dies der Fall ist, ein neues Address-Objekt und ordnet dieses dem gefundenen BusinessPartner zu. Andernfalls wird eine BusinessObjectException geworfen. KeyDatentypTypBeschreibungRD_InvoiceRecipientInvoiceRecipientRD-IN / optionalRechnungsempfänger, für den eine neue Adresse erzeugt wirdRD_InvoicintPartyInvoicingPartyRD-IN / optionalRechnungssteller, für den eine neue Adresse erzeugt wirdRD_AddressAddressRD-OUT / mandatoryDie neu erzeugte Adresse, welche entweder einem Rechnugssteller oder Rechnungsempfänger zugeordnet wurde.UpdateAddress: Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.UpdateAddressBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Ermittelt eine Addresse aus dem RD und aktualisiert sie anhand der Input-Parameter im RD. KeyDatentypTypBeschreibungRD_AddressAddressRD-IN / mandatoryDie Adresse, welche aktualisiert werden soll DeleteAddress Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.DeleteAddressBean Status: Spezifiziert / Implementiert Beschreibung: Ermittelt eine Addresse aus dem RD und löscht sie. KeyDatentypTypBeschreibungRD_AddressAddressRD-IN / mandatoryDie Address, welche gelöscht werden soll DetermineAddress: Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.DetermineAddressBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Ermittelt eine oder mehrere Adressen. Wird eine UUID vorgefunden, ermittelt das BusinessObject nur diese eine Adresse. Wird andernfalls einer der beiden Businesspartner vorgefunden, wird entweder dessen DefaultAdresse (wenn gewünscht), oder alle seine Adressen zurückgegeben. KeyDatentypTypBeschreibungDefaultAddressOnlybooleanPROP / mandatoryGibt an, ob nur die DefaultAdresse zurückgegeben werden soll. Andernfalls wird bei Vorhandensein eines BusinessPartners eine Collection mit allen Adressen zurückgegeben.FV_ADDRESSIDStringRD_IN / optionalDie UUID der Adresse, welche ermittelt werden sollRD_ADDRESSAddressRD_OUT / optionalEinzelne ermittelte Adresse (entweder über UUID oder Default)RD_INVOICERECIPIENTInvoiceRecipientRD_IN / optionalDer Optionale Rechnungsempfänger, von welchem eine oder mehrere Adressen besorgt werden.RD_INVOICINGPARTYInvoicingPartyRD_IN / optionalDer optionale Rechnungssteller, von welchem eine oder mehrere Adressen besorgt werden.RD_ADDRESSESCollectionRD_OUT / optionalCollection der ermittlten Adressen eine BusinessPartner’s InsertPersonDataSheet Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.InsertPersonDataSheetBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Erzeugt ein neues PersonDataSheet und setzt es zu dem vorher ermittelten InvoiceRecipient in Beziehung. KeyDatentypTypBeschreibungRD_INVOICERECIPIENTInvoiceRecipientRD_IN / mandatoryDer InvoiceRecipient, zu welchem der neue DataSheet in Beziehung gesetzt wird.RD_PERSONDATASHEETPersonDataSheetRD_OUT / mandatoryDer neu erzeugte PersonDataSheet InsertCompanyDataSheet Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.InsertCompanyDataSheetBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Erzeugt ein neues CompanyDataSheet und setzt es zu dem vorher ermittelten FinancialServiceProvider oder InvoingParty in Beziehung. Wird keiner von den beiden im Dictionary gefunden, wirft das BusinessObject eine BusinessObjectException. KeyDatentypTypBeschreibungRD_INVOICINGPARTYInvoicingPartyRD_IN / optionalDie optionale InvoicingParty, welche zum neuen DataSheet in Beziehung gesetzt wird.RD_FINANCIALSERVICEPROVIDERFinancialServiceProviderRD_IN / optionalDer optionale FinancialServiceProvider, welcher zum neuen DataSheet in Beziehung gesetzt wird.RD_COMPANYDATASHEETCompanyDataSheetRD_OUT / mandatoryDer neu erzeugte CompannyDataSheet DeleteCompanyDataSheet Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.DeleteCompanyDataSheetBean Status: Spezifiziert / Implementiert Beschreibung: Ermittelt ein CompanyDataSheet im Dictionary. Wird keines gefunden, wirft das BusinessObject eine BusinessObjectException, andernfalls wird das gefundene CompanyDataSheet gelöscht. KeyDatentypTypBeschreibungRD_CompanyDataSheetCompanyDataSheetRD_IN / mandatoryDer zu löschende CompanyDataSheetDeterminePersonDataSheet Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.DeterminePersonDataSheetBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Ermittelt ein PersonDataSheet anhand des Primärschlüssels oder anhand eines vorhandenen InvoiceRecipients. Falls nichts Passendes gefunden wird, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_INVOICERECIPIENTInvoiceRecipientRD_IN / optionalDer InvoiceRecipient, dessen PersonDataSheet ermittelt wird.FV_PERSONDATASHEET_UUIDStringRD_IN / optionalDie UUID des zu ermittelnden PersonDataSheetRD_PERSONDATASHEETPersonDataSheetRD_OUT / mandatoryDer ermittelte PersonDatSheetUpdatePersonDataSheet Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.UpdatePersonDataSheetBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Ermittelt einen InvoiceRecipient oder ein PersonDataSheet aus dem Dictionary. Wird keines der beiden gefunden, wird eine BusinessObjectException ausgelöst. Andernfalls werden die Werte des PersonDataSheet aktualisiert. KeyDatentypTypBeschreibungRD_INVOICERECIPIENTInvoiceRecipientRD_IN / optionalDer optionale InvoiceRecipient, dessen PersonDataSheet aktualisert werden soll.RD_PERSONDATASHEETPersonDataSheetRD_IN / optionalDas PersonDataSheet, das aktualisiert werden soll. UpdateCompanyDataSheet Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.UpdateCompanyDataSheetBean Status: Spezifiziert / Rumpf Beschreibung: Aktualisiert ein CompanyDataSheet, welches sich im Dictionary befindet. Falls ein Fehler auftritt, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_COMPANYDATASHEETCompanyDataSheetRD_IN / mandatoryDer zu aktualisierende CompanyDataSheet DetermineCompanyDataSheet Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.DetermineCompanyDataSheetBean Status: Spezifiziert / Rumpf Beschreibung: Ermittelt ein CompanyDataSheet anhand des Primärschlüssels oder anhand einer vorhandenen InvoicingParty. Wird nichts passendes gefunden, so wird eine BusinessObjectException geworfen. KeyDatentypTypBeschreibungFV_CompanyDataSheet_UUID CompanyDataSheetRD_IN / mandatoryErmittelt den CompanyDataSheet nach UUID InsertFinancialAccount Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.InsertFinancialAccountBean Status: Spezifiziert / Implementiert Beschreibung: Erzeugt einen neuen FinancialAccount und setzt die notwendigen Beziehungen. Zunächst müssen entweder eine InvoicingParty oder ein InvoiceRecipient im Dictionary sein. Ebenfalls sollte der FinancialServiceProvider vorhanden sein. Wenn ein Fehler auftritt, wird eine BusinessObjectException ausgelöst. In diesem BusinessObject sollten ebenfalls alle FinancialAccountAttributes angelegt werden. KeyDatentypTypBeschreibungRD_INVOICINGPARTYInvoicingPartyRD_IN / optionalInvoingParty, welche dem neuen Account zugeodnet werden soll.RD_INVOICERECIPIENTInvoiceRecipientRD_IN / optionalInvoiceRecepient, welcher dem neuen Account zugeordnet werden sollRD_FINANCIALSERVICEPROVIDERFinancialServiceProviderRD_IN / mandatoryFinancialServiceProvider, welcher dem neuen Account zugeordnet werden sollRD_FINANCIALACCOUNTFinancialAccountRD_OUT / mandatoryDer neu erzeugte FimenancialAccountUpdateFinancialAccount de.Com42Bill.ebppsystem.businesspartner.businessobjects.UpdateFinancialAccountBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Aktualisiert einen FinancialAccount mit Hilfe von FormValues. Wenn kein Account im Dictionary gefunden wird, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_FINANCIALACCOUNTFinancialAccountRD_IN / mandatoryDer zu aktualisierende FinancialAccountDeleteFinancialAccount Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.DeleteFinancialAccountBean Status: Spezifiziert / Implementiert Beschreibung: Löscht einen FinancialAccount. Falls kein FinancialAccount gefunden wird, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_FINANCIALACCOUNTFinancialAccountRD_IN / mandatoryDer zu löschende FinancialAccountDetermineFinancialAccount Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.DetermineFinancialAccount Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Enthält das Dictionary eine UUID für einen FinancialAccount, wird dieser ermittelt. Wird eine AccountNumber gefunden, wird der FinancialAccount mit dem gegebenen FinancialServiceProvider ermittelt. Wird kein Provider gefunden, wird eine BusinessObjectException ausgelöst. Sind weder UUID noch AccountNo vorhanden, wird nach und nach auf Vorhandensein von InvoiceRecipient, InvoicingParty und FinancialServiceProvider geprüft. Für den ersten gefundenen der drei werden die Accounts (unter Auswertung des DefaultFlags bei InvoicingParty und InvoiceRecipient) ermittelt. Sollte überhaupt kein Input gefunden werden, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungFV_FINANCIALACCOUNT_UUIDStringRD_IN / optionalDie UUID des zu ermittelnden FinancialAccountsRD_INVOICERECIPIENTInvoiceRecipientRD_IN / optionalInvoiceRecipient, dessen FinancialAccounts ermittelt werden (Default-Flag wird ausgewertet)RD_INVOICINGPARTYInvoicingPartyRD_IN / optionalInvoicingParty, derern FinancialAccounts ermittelt werden (Default-Flag wird ausgewertet)RD_FINANCIALSERVICEPROVIDERFinancialServiceProviderRD_IN / optionalFinancialServiceProvider, dessen FincialAccounts ermittelt werden. Wird ein Account anahnd der AccountNumber ermittelt, wird hierfür der ServiceProvider zwingend benötigtFV_FINANCIALACCOUNT_ACCOUNTNOStringRD_IN / optionalDer zugehörige Account wird für den gegebenen FinancialServiceProvider ermitteltRD_FINANCIALACCOUNTFinancialAccountRD_OUT / optionalEin ermittelter FinancialAccountRD_FINANCIALACCOUNT_COLLECTIONCollectionRD_OUT / optionalEin Liste von ermittelten FinancialAccounts.DefaultBooleanPROP / optionalDieses Flag bestimmt, ob nur der Default-FinancialAccount ermittelt, wenn mehrere existieren. (Standard: false)DetermineInvoiceRecipient Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.DetermineInvoiceRecipientBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Zunächst werden die beiden Config-Flags abgefragt. Sind beide auf ‚true’ gesetzt, wird eine WorkflowInitException ausgelöst. Sonst wird im Falle von „DetermineByUser“ der aktuelle Benutzer aus dem Dictionary geholt und anhand dessen der BusinessPartner ermittelt und im Dictionary abgelegt. Bei „DetermineAll“ werden alle vorhandenen InvoiceRecipients ermittelt. Dies sollte aus Performance-Gründen vermieden werden und später durch ordentliche Abfragen ersetzt werden. Sind beide Flags auf false gesetzt, wird der InvoiceRecipient entweder anhand seiner UUID oder seiner Kundennummer ermittelt. KeyDatentypTypBeschreibungFV_INVOICERECIPIENT_UUIDStringRD_IN / optionalDie UUID des zu suchenden InvoiceRecipientsFV_INVOICERECIPIENT_CUSTOMERNUMBERStringRD_IN / optionalDie Kundennummer des zu suchenden InvoiceRecipients.DetermineByUserBooleanPROP / mandatoryMit Hilfe dieses Flags wird festgesetzt, ob der InvoiceRecipient anhand des eingeloggten Users bestimmt werden soll. (Standard: false)DetermineAllBooleanPROP / optionalMit Hilfe dieses Flags wird festgesetzt, ob alle existierenden Benutzer ermittelt werden sollen. (Standard: false)RD_INVOICERECIPIENTInvoiceRecipientRD_OUT / optionalDer ermittelte InvoiceRecipientRD_INVOICERECIPIENT_COLLECTIONCollectionRD_OUT / optionalEine Liste von ermittelten InvoiceRecipientsRD_USERINFORMATIONUserInformationRD_IN / optionalDer optionale User, von welchen der BusinessPartner ermittelt werden kannInsertInvoiceRecipient Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.InsertInvoiceRecipientBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Erstellt einen neuen InvoiceRecipient und füllt ihn mit FormValues. KeyDatentypTypBeschreibungRD_INVOICERECIPIENTInvoiceRecipientRD_OUT / mandatoryDer angelegte InvoiceRecipientUpdateInvoiceRecipient Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.UpdateInvoiceRecipientBean Status: Spezifiziert / Rumpf Beschreibung: Aktualisiert einen vorher ermittelten InvoiceRecipient anhand der FormValues KeyDatentypTypBeschreibungRD_INVOICERECIPIENTInvoiceRecipientRD_IN / MandatoryDer InvoiceRecipient, welcher aktualisiert werden soll.DetermineInvoicingParty Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.DetermineInvoicingPartyBean Status: Rumpf Beschreibung: Zunächst werden die beiden Config-Flags abgefragt. Sind beide auf ‚true’ gesetzt, wird eine WorkflowInitException ausgelöst. Sonst wird im Falle von „DetermineByUser“ der aktuelle Benutzer aus dem Dictionary geholt und anhand dessen der BusinessPartner ermittelt und im Dictionary abgelegt. Bei „DetermineAll“ werden alle vorhandenen InvoicingParties ermittelt. Dies sollte aus Performance-Gründen vermieden werden und später durch ordentliche Abfragen ersetzt werden. Sind beide Flags auf false gesetzt, wird die InvoicingParty entweder anhand seiner UUID oder seiner Kundennummer ermittelt. KeyDatentypTypBeschreibungFV_INVOICINGPARTY_UUIDStringRD_IN / optionalDie UUID der zu suchenden InvoicingPartyFV_INVOICINGPARTY_CUSTOMERNUMBERStringRD_IN / optionalDie Kundennummer der zu suchenden InvoicingParty.DetermineByUserBooleanPROP / mandatoryMit Hilfe dieses Flags wird festgesetzt, ob die InvoicingParty anhand des eingeloggten Users bestimmt werden soll. (Standard: false)DetermineAllBooleanPROP / optionalMit Hilfe dieses Flags wird festgesetzt, ob alle existierenden Benutzer ermittelt werden sollen. (Standard: false)RD_INVOICINGPARTYInvoicingPartyRD_OUT / optionalDie ermittelte InvoicingPartyRD_INVOICINGPARTY_COLLECTIONCollectionRD_OUT / optionalEine Liste von ermittelten InvoicingPartiesRD_USERINFORMATIONUserInformationRD_IN / optionalDer optionale User, von welchen der BusinessPartner ermittelt werden kannInsertInvoicingParty Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.InsertInvoicingPartyBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Legt eine neue InvoicingParty an und füllt sie mit FormValues. KeyDatentypTypBeschreibungRD_INVOICINGPARTYInvoicingPartyRD_OUT / mandatoryDie neu erzeugte InvoicingPartyUpdateInvoicingParty Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.UpdateInvoicingPartyBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Aktualisiert eine vorher ermittelte InvoingParty mit FormValues KeyDatentypTypBeschreibungRD_INVOICINGPARTYInvoicingPartyRD_IN / mandatoryDie zu aktualisierende InvoicingPartyInsertProfileGroup Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.InsertProfileGroupBean Status: Spezifiziert / Implementiert Beschreibung: Legt eine neue ProfileGroup an. KeyDatentypTypBeschreibungRD_PROFILEGROUPProfileGroupRD_OUT / mandatoryDie neu erzeugte ProfileGroupUpdateProfileGroup Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.UpdateProfileGroupBean Status: Spezifiziert / Rumpf Beschreibung: Aktualisiert eine vorher ermittelte ProfileGroup. Tritt dabein ein Fehler auf, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_PROFILEGROUPProfileGroupRD_IN / mandatoryDie zu aktualisierende ProfileGroupDeleteProfileGroup Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.DeleteProfileGroupBean Status: Spezifiziert / Rumpf Beschreibung: Löscht eine vorher ermittelte ProfileGroup. Tritt dabei ein Fehler auf, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_PROFILEGROUPProfileGroupRD_IN / mandatoryDie zu löschende ProfileGroupAssignProfileGroupsToBusinessPartner Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.AssignProfileGroupsToBusinessPartnerBean Status: Spezifiziert / Rumpf Beschreibung: Erstellt Beziehungen zwischen einem BusinessPartner (InvoicingParty/InvoiceRecipient) und ProfileGroups. Es werden sowohl neue Beziehung gesetzt als auch nicht mehr benötigte entfernt. Wird keine InvoicingParty gefunden, wird eine BusinessObjectException ausgelöst. Wird andernfalls keine ProfileGroup-Collection gefunden, wird ebenfalls eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_INVOICERECIPIENTInvoiceRecipientRD_IN / optionalDer optionale erste Teil für die BeziehungRD_INVOICINGPARTYInvoicingPartyRD_IN / optionalDer optional erste Teil für sie BeziehungRD_PROFILEGROUP_COLLECTIONCollectionRD_IN / mandatoryDie ProfileGroups, mit denen eine Beziehung hergestellt werden soll. Beziehung zu ProfileGroups, die nicht in der Collection sind, müssen entfernt werden.DetermineProfileGroup Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.DetermineProfileGroupBean Status: Spezifiziert / Rumpf Beschreibung: Ermittelt eine ProfileGroup anhand ihrer UUID oder ihres Namens. Andernfalls werden alle ermittelt. KeyDatentypTypBeschreibungFV_PROFILEGROUP_UUIDStringRD_IN / optionalUUID der zu ermittelnden ProfileGroupFV_PROFILEGROUP_NAMEStringRD_IN / optionalName der zu ermittelnden ProfileGroupRD_PROFILEGROUPProfileGroupRD_OUT / optionalEinzelne ermittelte ProfileGroupRD_PROFILEGROUP_COLLECTIONCollectionRD_OUT / optionalCollection von ermittelten ProfileGroupsInsertFinancialServiceProvider Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.InsertFinancialServiceProviderBean Status: Spezifiziert / Implementiert Beschreibung: Legt einen neuen FinancialServiceProvider an. KeyDatentypTypBeschreibungRD_FINANCIALSERVICEPROVIDERFinancialServiceProviderRD_OUT / mandatoryDer neu erzeugte FinancialServiceProvider.UpdateFinancialServiceProvider Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.UpdateFinancialServiceProviderBean Status: Spezifiziert / Rumpf Beschreibung: Aktualisiert einen vorher ermittelten FinancialServiceProvider anhand der gegebenen FormValues. Falls ein Fehler auftritt, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_FINANCIALSERVICEPROVIDERFinancialServiceProviderRD_IN / mandatoryDer zu aktualisierende FinancialServiceProviderDeleteFinancialServiceProvider Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.DeleteFinancialServiceProviderBean Status: Spezifiziert / Rumpf Beschreibung: Löscht einen vorher ermittelten FinancialServiceProvider. Falls keiner gefunden wird, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_FINANCIALSERVICEPROVIDERFinancialServiceProviderRD_IN / MandatoryDer zu löschende FinancialServiceProviderDetermineFinancialServiceProvider Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.DetermineFinancialServiceProviderBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Da es vorerst keine GUI zur Pflege von FinancialServiceProvidern geben wird, muss dieser automatisch angelegt werden, sofern noch nicht im System vorhanden. Daher wird der Error-Ausgang benutzt, sofern weder unter der UUID noch der BLZ oder der CPAID ein FinancialServiceProvider gefunden wurde. Sollte keiner dieser drei FormValues im Dictionary vorhanden sein, wird das Flag ‚DetermineAll’ ausgewertet. Standardmässig wird eine BusinessObjectException geworfen. Steht das Flag auf true, wird eine Collection mit allen FinancialServiceProvidern ermittelt. KeyDatentypTypBeschreibungFV_FINANCIALSERVICEPROVIDER_UUIDStringRD_IN / optionalUUID des zu ermittelnden ServiceProvidersFV_FINANCIALSERVICEPROVIDER_BLZStringRD_IN / optionalBLZ der zu ermittelnden ServiceProvidersFV_FINANCIALSERVICEPROVIDER_CPAIDStringRD_IN / optionalCPAID des zu ermittelnden ServiceProvidersRD_FINANCIALSERVICEPROVIDERFinancialServiceProviderRD_OUT / optionalEin einzelner ermittelter ServiceProviderRD_FINANCIALSERVICEPROVIDER_COLLECTIONCollectionRD_OUT / optionalEine Collection von ermittelten ServiceProvidernDetermineAllBooleanPROP / optionalIst das Flag auf true gesetzt, werden alle existierenden FinancialServiceProvider zurückgegeben, sofern keine einschränkenden Parameter angeben sind. Falls ein Fehler auftritt, wird eine BusinessObjectException ausgelöst. (Standard:false)ImportFinancialServiceProvider Bean: de.Com42Bill.ebppsystem.businesspartner.businessobjects.ImportFinancialServiceProviderBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Liest eine CSV-Datei ein und legt die dort spezifizierten FinancialServiceProvicer an. Ist bereits ein Datensatz mit der BLZ vorhanden, wird der zu importierende Datensatz zu Testzwecken zunächst ignoriert. KeyDatentypTypBeschreibungAbsolulteFilePathStringPROP / mandatoryDer absolute Pfad zur CSV-Datei Package Invoice InsertInvoiceType Bean: de.Com42Bill.ebppsystem.invoice.businessobjects.InsertInvoiceTypeBean Status: Rumpf Beschreibung: Legt einen neuen InvoiceType an. KeyDatentypTypBeschreibungFV_FINANCIALACCOUNT_UUIDStringRD_OUT / mandatoryDer neu angelegte InvoiceType.UpdateInvoiceType Bean: de.Com42Bill.ebppsystem.invoice.businessobjects.UpdateInvoiceTypeBean Status: Spezifiziert / Rumpf Beschreibung: Aktualisiert einen vorher ermittelten InvoiceType. Wird keiner gefunden, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_INVOICETYPEInvoiceTypeRD_IN / mandatoryDer zu aktualisierende InvoiceTypeDeleteInvoiceType Bean: de.Com42Bill.ebppsystem.invoice.businessobjects.DeleteInvoiceTypeBean Status: Spezifiziert / Rumpf Beschreibung: Löscht einen vorher ermittelten InvoiceType. Wird keiner gefunden, wird eine BusinessObjectException ausgelöst. Hängen an dem InvoiceType noch Invoice dran, darf der InvoiceType nicht entfernt werden. Sollte dies der Fall sein, wird der ERROR-Ausgang des BusinessObjects benutzt und ein Fehler-Hinweis ins Dictionary eingetragen. KeyDatentypTypBeschreibungRD_INVOICETYPEInvoiceTypeRD_IN / mandatoryDer zu löschende InvoiceTypeER_INVOICETYPE_BOUNDStringRD_OUT / optionalDieser Wert wird im Dictionary eingetragen, wenn dem InvoiceType noch Invoices zugeordnet sind.DetermineInvoiceType Bean: de.Com42Bill.ebppsystem.invoice.businessobjects.DetermineInvoiceTypeBean Status: Spezifiziert / Rumpf Beschreibung: Ermittelt ein oder mehrere InvoiceTypes. Zunächst wird auf das Vorhandensein einer UUID geprüft. Wird keine vorgefunden, ist der Versuch mit einem Namen für den InvoiceType durchzuführen. Sind beide Versuche erfolglos, werden alle InvoiceTypes ermittelt. KeyDatentypTypBeschreibungFV_INVOICETYPE_UUIDStringRD_IN / optionalDie UUID des zu ermittelnden InvoiceTypesFV_INVOICETYPE_NAMEStringRD_IN / optionalDer Names des zu ermittelnden InvoiceTypesRD_INVOICETYPE_COLLECTIONCollectionRD_OUT / optionalCollection mit ermittelten InvoiceTypesRD_INVOICETYPEInvoiceTypeRD_OUT / optionalEin ermittelter InvoiceType (anhand seiner UUID oder seines Namens)InsertInvoiceLink Bean: de.Com42Bill.ebppsystem.invoice.businessobjects.InsertInvoiceLinkBean Status: Spezifiziert / Rumpf Beschreibung: Legt einen InvoiceLink zwischen zwei vorher ermittelten Invoices an. Wird eine der beiden nicht gefunden, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_INVOICE_SOURCEInvoiceRD_IN / mandatoryDer erste Teil des zu erstellenden InvoiceLinksRD_INVOICE_TARGETInvoiceRD_IN / mandatoryDer zweite Teil des zu erstellenden InvoiceLinksRD_INVOICELINKInvoiceLinkRD_OUT / mandatoryDer neu erstellte InvoiceLinkDeleteInvoiceLink Bean: de.Com42Bill.ebppsystem.invoice.businessobjects.DeleteInvoiceLinkBean Status: Spezifiziert / Rumpf Beschreibung: Entfernt ein oder mehrere InvoiceLinks. Wird ein voher ermittelter InvoiceLink aufgefunden, wird dieser einfach gelöscht. Das gleiche passiert mit einer InvoiceLink-Collection. Werden zwei Invoices aufgefunden, wird der InvoiceLink zwischen diesen beiden entfernt. Wird nur eine Invoice gefunden, werden alle InvoiceLinks, die von dieser Invoice abgehen entfernt. Wird nichts dergleichen aufgefunden, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_INVOICELINKInvoiceLinkRD_IN / optionalEin einzelner zu löschender InvoiceLinkRD_INVOICELINK_COLLECTIONCollectionRD_IN / optionalEine Collection von zu löschenden InvoiceLinksRD_INVOICE_SOURCEInvoiceRD_IN / optionalDer erste Teil, der zwei Invoices, zwischen denen der InvoiceLink gelöscht werden sollRD_INVOICE_TARGETInvoiceRD_IN / optionalDer zweite Teil der zwei Invoices, zwischen denen der InvoiceLink gelöscht werden soll.RD_InvoiceInvoiceRD_IN / optionalDie Invoice, von der alle abgehenden InvoiceLinks entfernt werden sollen. InsertInvoice Bean: de.Com42Bill.ebppsystem.invoice.businessobjects.InsertInvoiceBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Erzeugt eine neue Rechnung und setzt sie zu den beiden zugehörigen BusinessPartnern in Beziehung. Sollte einer der beiden fehlen, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_INVOICERECIPIENTInvoiceRecipientRD_IN / mandatoryDer zuzuordnende RechnungsempfängerRD_INVOICINGPARTYInvoicingPartyRD_IN / mandatoryDer zuzuordnende RechnungsstellerRD_INVOICEBEANInvoiceRD_OUT / mandatoryDie neu erzeugte RechnungDetermineInvoice Bean: de.Com42Bill.ebppsystem.invoice.businessobjects.DetermineInvoiceBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Ermittelt Rechnungen entweder für den Datenkonverter anhand der InvoiceNumber oder zur GUI-Anzeige anhand der übergebenen Suchkriterien. KeyDatentypTypBeschreibungRD_INVOICEBEAN_COLLECTIONCollectionRD_OUT / optionalDie ermittelten Rechnungen. Package Payment/InvoiceContainer AddInvoiceContainerItems Bean: de.Com42Bill.ebppsystem.payment.invoicecontainer.businessobjects.AddInvoiceContainerItemsBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Dieses BusinessObject fügt neue Invoices in den aktuellen InvoiceContainer ein. Vorher muss der aktuelle InvoiceContainer ermittelt werden. Falls ein Fehler auftritt, wird eine BusinessObjectException ausgelöst. Das BusinessObject erhält als Input ein Invoice, zu den dann InvoiceContainerItem angelegt wird, welche wiederum mit dem InvoiceContainer in Beziehung gesetzt wird. Wird keine Rechnung vorgefunden, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_INVOICEBEANCollectionRD_IN / mandatoryCollection mit Invoices, für die ein InvoiceContainerItem erstellt werden soll, welches dann zum aktuellen InvoiceConatiner in Beziehung gesetzt wird.RD_INVOICECONTAINERInvoiceContainerRD_IN / mandatoryThe actual InvoiceContainer.UpdateInvoiceContainerItems Bean: de.Com42Bill.ebppsystem.payment.invoicecontainer.businessobjects.UpdateInvoiceContainerItemsBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Dieses BusinessObject aktualisiert die Attribute der InvoiceContainerItems. KeyDatentypTypBeschreibungFV_INVOICECONTAINERITEM_UUIDStringRD_IN / mandatoryAktualisiert die Attribute des InvoiceContainerItems.DeleteInvoiceContainerItems Bean: de.Com42Bill.ebppsystem.payment.invoicecontainer.businessobjects.DeleteInvoiceContainerItemsBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Dieses Businessobject löscht ein InvoiceContainerItem aus dem aktuellen InvoiceContainer Wird jedoch kein aktueller InvoiceContainer im Dictionary vorgefunden, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_INVOICEBEANCollectionRD_IN / optionalEine Collection mit Invoices, für die die entsprechenden InvoicerContainerItems gelöscht werden müssen. Diese befinden sich am aktuellen InvoiceContainer.RD_INVOICECONTAINERInvoiceContainerRD_IN / mandatoryThe actual InvoiceContainer.DetermineInvoiceContainer Bean: de.Com42Bill.ebppsystem.payment.invoicecontainer.businessobjects.DetermineInvoiceContainerBean Status: Spezifiziert / Teilimplementiert / In Betrieb Beschreibung: Ermittelt ein oder mehrere InvoiceContainer für den aktuellen InvoiceRecipient. Je nachdem, wie die Properties gesetzt wurden, wird nur der aktuelle, nur die History-Container oder alle ermittelt. Sollte kein aktueller existieren, jedoch angefordert worden sein, muss er angelegt werden. In der aktuellen Implementierung wird nur der aktive InvoiceContainer zurückgegeben. Ist kein InvoiceRecipient vorhanden, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_INVOICERECIPIENTInvoiceRecipientRD_IN / mandatoryDer InvoiceRecipient, dessen InvoicerContainer ermittelt werden soll(en).DetermineActualbooleanPROP / optionalSet to ‚false’, if you don’t want the actual InvoiceContainer to be determined (default is ‚true’).DetermineHistoryBooleanPROP / optionalSet to ‘true’, if you want the History-InvoiceContainers to be determined (default is ‘false’).RD_INVOICECONTAINERInvoiceContainerRD_OUT / optionalThe actual InvoiceContainer.RD_INVOICECONTAINER_COLLECTIONCollectionRD_OUT / optionalCollection with History-InvoiceContainer for the current InvoiceRecipientCheckoutInvoiceContainer Bean: de.Com42Bill.ebppsystem.payment.invoicecontainer.businessobjects.CheckoutInvoiceContainerBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Beim Container-Checkout wird der Typ geändert und das Checkout-Date gesetzt. KeyDatentypTypBeschreibungRD_INVOICECONTAINERInvoiceContainerRD_IN / mandatoryThe actual InvoiceContainer, that has to be checked out.RD_INVOICECONTAINERITEM_COLLECTIONCollectionRD_Out / mandatoryThe collection of invoices, that were in InvoiceContainer. Package Payment ExecuteScheduledPaymentTransactions Bean: de.Com42Bill.ebppsystem.payment.businessobjects.ExecuteScheduledPaymentTransactionsBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Ermittelt die ScheduledTransactionLists die fällig sind und erzeugt JobTransactionList. KeyDatentypTypBeschreibungDetermineExportPaymentTransactions Bean: de.Com42Bill.ebppsystem.payment.businessobjects.DetermineExportPaymentTransactionsBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Ermittelt alle JobTransactionLists für die Ausführung von Jobs. KeyDatentypTypBeschreibungRD_PAYMENTTRANSACTION_COLLECTIONCollectionRD_Out / mandatoryDer übergebene Paymenttransactionliste.InsertPaymentTransaction Bean: de.Com42Bill.ebppsystem.payment.businessobjects.InsertPaymentTransactionBean Status: Spezifiziert / Implementiert / In Betrieb Beschreibung: Dieses Businessobject holt sich eine Rechnung aus der InvoiceCollection und erzeugt eine neue Überweisung. KeyDatentypTypBeschreibungRD_INVOICECONTAINERITEM_COLLECTIONCollectionRD_IN / mandatoryDer InvoiceCollection mit den zu überweisende Rechnungen.RD_FINANCIALACCOUNTFinancialAccountLocalRD_IN / mandatoryFinancialAcount von InvoiceRecipientRD_PAYMENTTRANSACTIONLISTPaymentTransactionListLocalRD_IN / optionalWenn eine PaymentTransactionlist angegeben ist, wird es in Beziehung zu PaymentTransaction gesetzt.RD_PAYMENT_TRANSACTION_LOCALPaymentTransactionLocalRD_Out / mandatoryUpdatePaymentTransaction Bean: de.Com42Bill.ebppsystem.payment.businessobjects.UpdatePaymentTransactionBean Status: Rumpf Beschreibung: Aktualisiert die Attributte von PaymentTransaction. KeyDatentypTypBeschreibungInsertPaymentMethod Bean: de.Com42Bill.ebppsystem.payment.businessobjects.InsertPaymentMethodBean Status: Rumpf Beschreibung: Erzeugt eine Zahlungmethode für ein Konto. KeyDatentypTypBeschreibungUpdatePaymentMethod Bean: de.Com42Bill.ebppsystem.payment.businessobjects.UpdatePaymentMethodBean Status: Rumpf Beschreibung: Aktualisiert die Attribute von der Zahlungmethode. KeyDatentypTypBeschreibungDeletePaymentMethod Bean: de.Com42Bill.ebppsystem.payment.businessobjects.DeletePaymentMethodBean Status: Rumpf Beschreibung: Löscht eine Zahlungmethode KeyDatentypTypBeschreibungDeterminePaymentMethod Bean: de.Com42Bill.ebppsystem.payment.businessobjects.DeterminePaymentMethodBean Status: Rumpf Beschreibung: Ermittelt die Zahlungsmethode. KeyDatentypTypBeschreibungInsertPaymentTransactionList Bean: de.Com42Bill.ebppsystem.payment.businessobjects.InsertPaymentTransactionListBean Status: Spezifiziert / Implementiert Beschreibung: Dieses erzeugt ein PaymentTransactionList Object und setzt es in Beziehung mit der PaymentTransaction. KeyDatentypTypBeschreibungRD_PAYMENT_TRANSACTION_LOCALPaymenttransactionLocalRD_IN / mandatoryDer PaymentTranscaction zu dem eine Beziehung erstellt werden soll.DeterminePaymentTransactionList Bean: de.Com42Bill.ebppsystem.payment.businessobjects.DeterminePaymentTransactionListBean Status: Spezifiziert / Implementiert Beschreibung: Dieses Business Objekt ermittelt alle PaymentTransactions. KeyDatentypTypBeschreibungRD_INVOICERECIPIENTStringRD_IN / mandatoryDer Rechnungsempfänger, für den alle PaymenttansactionList ermittelt werden sollen.InsertJobTransaction Bean: de.Com42Bill.ebppsystem.payment.businessobjects.InsertJobTransactionBean Status: Spezifiziert / Implementiert Beschreibung: Dieses Business Objekt erzeugt eine neue JobTransaction. KeyDatentypTypBeschreibungRD_PAYMENT_TRANSACTION_LOCALPaymenttransactionLocalRD_IN / mandatoryDer PaymentTranscaction zu dem eine Beziehung erstellt werden soll. Package Core InsertJob Bean: de.Com42Bill.ebppsystem.core.businessobjects.InsertJobBean Status: Spezifiziert / Rumpf / In Betrieb Beschreibung: Legt eine neue JobConfiguration und den dazugehörigen JobTimer an. KeyDatentypTypBeschreibungRD_JOBCONFIGURATIONJobConfigurationRD_OUT / mandatoryDie neu erzeugte JobConfigurationRD_JOBTIMERJobTimeRD_OUT / mandatoryDer neu erzeugte JobTimer, der mit der JobConfiguration in Bezihung gesetzt wurde.DeleteJob Bean: de.Com42Bill.ebppsystem.core.businessobjects.DeleteJobBean Status: Spezifziert / Rumpf / In Betrieb Beschreibung: Löscht eine JobConfiguration und den zugehörigen Timer. Es wird z. Zt. Nicht berücksichtigt, ob der Job in der Ausführung ist. Anschliessend muss der Job aus dem Dictionary entfernt werden, damit die GUI nicht auf die gelöschte Instanz zugreifen kann. KeyDatentypTypBeschreibungRD_JOBCONFIGURATIONJobConfigurationRD_IN / mandatoryDie zu löschende JobConfigurationDetermineJobs Bean: de.Com42Bill.ebppsystem.core.businessobjects.DetermineJobsBean Status: Spezifziert / Rumpf /In Betrieb Beschreibung: Ermittelt ein oder mehrere JobConfigurations. Wird die UUID einer JobConfiguration vorgefunden, wird eine einzelne ermittelt, ansonsten alle. KeyDatentypTypBeschreibungFV_JOBCONFIGURATION_UUIDStringRD_IN / optionalDie UUID der zu ermittelnden JobConfiguration.RD_JOBCONFIGURATIONJobConfigurationRD_OUT / optionalDie anhand der UUID ermittelte JobConfigurationRD_JOBCONFIGURATION_COLLECTIONCollectionRD_OUT / optionalAlle ermittelten JobConfigurationsUpdateJob Bean: de.Com42Bill.ebppsystem.core.businessobjects.UpdateJobBean Status: Spezifiziert / Rumpf / In Betrieb Beschreibung: Aktualisiert eine vorhandene JobConfiguration oder den zugehörigen JobTimer. Falls keine JobConfiguration vorhanden íst, wird eine BusinessObjectException ausgelöst. KeyDatentypTypBeschreibungRD_JOBCONFIGURATIONJobConfigurationRD_IN / mandatoryDie zu aktualisierende JobConfigurationInsertUserInformartion Bean: de.Com42Bill.ebppsystem.core.businessobjects.InsertUserInformation Status: Spezifiziert / Rumpf / In Betrieb Beschreibung: Legt einen neuen User an. Das Passwort wird verschlüsselt. Der Passwortvergleich muss bei der Eingabe durch die GUI erfolgen, da das Kontrollpasswort nicht bis hierhin durchgereicht wird. KeyDatentypTypBeschreibungRD_USERINFORMATIONUserInformationRD_OUT / mandatoryDie neu erzeugte Userinformation DeleteUserInformation Bean: de.Com42Bill.ebppsystem.core.businessobjects.DeleteUserInformationBean Status: Rumpf Beschreibung: Löscht die UserInformation. KeyDatentypTypBeschreibung Workflows BusinessPartner StartNodeFunktionalitätTypInsertAddressPflegt eine neue die Adresse ein.PrivateUpdateAddressAktualisiert die AdresseGUIUpdateDataSheet/CompanySheetAktualisiert persönliche Daten.GUIInsertFinancialAccountFügt eine neue Bankverbindung ein.GUIUpdateFinancialAccountAktualisiert die Bankverbindung, fügt neue hinzu, wenn keine UID mitgegeben wurdeGUIRemoveFincialAccountEntfernen der BankverbindungGUIUpdateInformationUserInformation aktualisierenGUIDetermineInformationUserInformation ermittelnGUIDetermineFinancialAccountsFinancialAccounts ermittelnGUIDetermineFinancialAccountFinancialAccount ermittelnGUIInvoiceRecipient: StartNodeFunktionalitätTypLoginHolt InvoiceRecipient anhand von Userinformation und übermittelt evtl. neu eingetroffene, fällige Rechnungen und Mahnungen an die Komponente GUI.GUIRegisterLegt eine neue InvoiceRecipient an. Danach wird diese mit eine neuen erzeugten PersonalDatasheet, Adresse in Beziehung gesetzt.GUIDetermineAllErmittelt alle InvoiceRecipientsAdminDetermineFinancialAccountsErmittelt alle FinancialAccounts des eingeloggten BenutzerGUIInvoicingParty: StartNodeFunktionalitätTypLoginHolt InvoicingParty anhand von Userinformation und übermittelt evtl. neu eingetroffene, fällige Rechnungen und Mahnungen an die Komponente GUI.GUIRegisterLegt eine neue InvoicingParty an. Danach wird diese mit eine neuen erzeugten PersonalDatasheet, Adresse in Beziehung gesetzt.GUIInvoiceForInvoicingParty: StartNodeFunktionalitätTypSummaryErmittelt alle Rechnungen GUIDetailViewErmittelt eine einzelne RechnungGUIInsertErmittelt den InvoicingParty und InvoiceRecipient. Danach wird eine neue Rechnung erzeugt, die in Beziehung zu beteiligten gesetzt wird.DataConverterCancellationErmittelt eine Rechnung und storniert sie.DataConverterUpdate???DataConverterSearchSuche alle Rechnungen nach bestimmten SuchkriterienGUIInvoiceForInvoiceRecipient: StartNodeFunktionalitätTypSummaryErmittelt alle offenen RechnungenGUIDetailViewErmittelt eine einzelne RechnungGUISearchSuche alle Rechnungen nach bestimmten SuchkriterienGUIInvoiceContainer: StartNodeFunktionalitätTypCreateContainerErzeugt einen neuen Container für den RechnungsempfängerPrivateAddItemsErzeugt für übergebenen Invoices Items, die in Container eingefügt werden.GUIRemoveItemsEntfernt für übergebenen Invoices Items aus dem Container.GUICheckoutItemsErzeugt für jede Item in den Container einen PaymentTransaktion und fügt diese in den JobList.GUIUpdateItemsSetzt weitere Attribute des ContainerItems, wie höhe des Betrages beispielweise bei Rechnungskurzungen, Ttransaktionsdatum, Kontenauswahl.GUIDetermineContainerErmitteln von Container eines bestimmten TypsGUIUpdateItemsAddItems + RemoveItemsGUIDetermineItemsInvoices im ContainerGUIPayment: StartnodeFunktionalitätTypScheduledTransactionExportieren von PaymentTransaction aus der ScheduledTransactionList zu einem angebebenen Zeitpunkt in die ExportTransactionListJobDetermineExportTransactionsErmitteln der zu exportierende Transaction.JobInsertPaymentTransactionErzeugt die PaymentTransaction und setzt die ZahlungsartPrivateJobManagment: StartnodeFunktionalität:TypInsertEinfügen eines Jobs AdminRemoveLöschen eines JobsAdminDetermineAllErmittelt alle JobConfigurationsAdminUpdateÄderungen der Parameters eines bestehenden JobsAdminDetailErmittelt einen einzelnen Job für die DetailansichtAdminAlert: StartnodeFunktionalitätTypSendInvoiceRemindersBenachrichtigung der fälligen Rechnungen JobSendNewInvoicesBenachrichtigung über neu eingetroffene RechnungDataConverterSendPaymentWarningsMahnung per Email verschickenJobCreatePaymentWarningsSucht überfällige Rechnungen und erzeugt Mahnungen. JobUserManagement: StartnodeFunktionalitätTypInsertAnlegen eines neuen UsersAdminRemoveLöschen eines neuen bestehenden UsersAdminUpdateÄderung der Parameter eines UsersAdminInsertUsergroupAnlegen einer neuen GruppeAdminRemoveUsergroupLöschen einer neuen bestehenden Gruppe AdminUpdateUsergroupÄderung der Parameter einer GruppeAdminAssignUserGroupErstellung einer Beziehung zwischen den Users und einer GruppeAdminAssignWorklfowErstellung einer Beziehung zwischen mehreren Gruppen und einem Workflow AdminRemoveUserGroup-AssignmentEntfernen einer Beziehung zwischen den Users und einer GruppeAdminRemoveWorklfow-AssignmentEntfernen einer Beziehung zwischen einer Gruppe und einem Workflow Admin Qualitätsmanagement: Testplan Das Testen sollte als eigenes Projekt neben der Entwicklung des Programms angesehen werden. Der Testplan legt fest, wie bei dem Testprojekt „Com42Bill-Test“ vorgegangen wird. Zunächst wird in der Testprojektbeschreibung kurz das Ziel der Tests beschrieben und eine Unterteilung der Tests in Testphasen nach Art und Umfang der Tests vorgenommen. Der Testhintergrund beschreibt die Besonderheiten des zu testenden Systems, wie die eingesetzte Serversoftware und die Programmiersprache. In dem Abschnitt Testgegenstände werden die Testlinge und die Testfälle in Abhängigkeit zu den einzelnen Testphasen aufgeführt. Eine Teststrategie ist bereits durch die jeweilige Phase grob festgelegt, das Testszenario und die genauen Ziele des speziellen Tests werden erst bei der Einzeltestplanung bestimmt. Es werden danach konkrete Testziele aufgeführt und festgelegt, wo der Schwerpunkt der Tests liegen soll. Im Allgemeinen sind Testprojekte immer wirtschaftlichen Einschränkungen unterworfen. Die Einschränkungen für diesen Testplan werden in dem Abschnitt Testeinschränkungen konkretisiert. Da Tests nicht unendlich fortgesetzt werden können, werden im nächsten Abschnitt deshalb Kriterien definiert, die für das Ende der Tests erfüllt werden müssen. Die Tests müssen nachweisbare Ergebnisse liefern, die in den Testergebnisdokumenten festgehalten werden. Diese sind im entsprechenden Abschnitt aufgeführt. Die Aufgaben, die bei den Tests anfallen und die Verantwortlichkeiten für diese Aufgaben werden in den folgenden Abschnitten aufgezählt. Abschließend wird ein Zeitplan für die Durchführung der Tests festgelegt. Beschreibung des Testplans Das durch diesen Testplan beschriebene Testprojekt „Com42Bill-Test“ wird von der Projektgruppe 411 durchgeführt, um zu überprüfen, ob die implementierte Anwendung mit den Anforderungen an das Projekt übereinstimmt und ob die Anwendung die geforderten Aufgaben fehlerfrei ausführt. Testprojektbeschreibung Mit dem Testprojekt soll nachgewiesen werden, dass alle Aktivitäten, die in den entsprechenden Aktivitätsdiagrammen beschrieben sind, fehlerfrei vom System ausgeführt werden. Das Testprojekt wird vom Qualitätsmanagement geleitet. Für die Tests werden abhängig von der jeweiligen Teststrategie Endanwender, Entwickler oder zusammengestellte Testgruppen unter der Aufsicht des Qualitätsmanagement verantwortlich sein. Ein abschließender Systemtest ist als Gesamttest nicht ausreichend, da zum einen nicht alle Anwendungsfälle getestet werden können und zum anderen bei einem Gesamtsystemtest entdeckte Fehler schwierig zu lokalisieren sind. Deswegen wird das System nach einem inkrementellen, induktiven Testansatz in mehreren Phasen von Grund auf geprüft werden. In der ersten Testphase werden White-Box-Tests als Code-Reviews oder Build-In-Tests bei einzelnen Klassen durchgeführt, aufbauend auf diesen Tests werden in der nächsten Phase Black-Box-Tests bei den Komponenten durchgeführt. In der anschließenden Phase der Integrationstests werden die Komponenten durch nachrichtenbasierte Grey-Box-Tests geprüft. Dabei werden die Nachrichten an den Schnittstellen zwischen den zu testenden Komponenten kontrolliert. Die abschließende Phase des Systemtests stellt auch den Abnahmetest dar. Hierbei werden die durch die Aktivitätsdiagramme beschriebenen Funktionen der Applikation in einem Black-Box-Test getestet.  Abbildung 83: Testphasen Testhintergrund Das Software-System Com42Bill ist als Client/Server-System realisiert und setzt sich aus fünf Komponenten zusammen. Die Implementierung erfolgt in der Programmiersprache Java (Enterprise-Edition, J2EE 1.3). Als Middleware wird der Application Server BEA Weblogic 6.1 eingesetzt. Für die Persistierung der Daten wird auf das relationale Datenbanksystem Oracle 8i zurückgegriffen. Der Testprozess soll bereits parallel zu der Entwicklung beginnen. Während der Implementierungsphase können bereits fertig gestellte Klassen getestet werden. Komponenten- und Integrationstests können erfolgen, sobald die ersten Komponenten vollständig implementiert sind. Der Systemtest kann dagegen erst erfolgen, wenn die Entwicklungsphase abgeschlossen ist. Testumfang nur elementare Klassen; ca. 30% aller im System existierenden Klassen Fünf Komponenten 100% aller im System definierten Schnittstellen zwischen den einzelnen Komponenten Gesamtsystemtest Testgegenstände Bei den Klassentests werden folgende Klassen getestet: a) Code-Review GUI: ausgewählte Klassen Sicherheit: ausgewählte Klassen Datenkonverter: ausgewählte Klassen Business Logic: ausgewählte Klassen Datenbank: ausgewählte Klassen b) Build-In Test: GUI: Response-Presenter Sicherheit: SessionManager Datenkonverter: MsgReceiver, MsgExtractor Business Logic: InvoiceMgr Datenbank: PaymentTransaction Bei den Komponententests werden alle Komponenten getestet: GUI Sicherheit Datenkonverter Business Logic Datenbank Folgende Schnittstellen werden bei dem Top-Down-Integrationstest getestet: GUI – Business Logic GUI – Sicherheit Datenkonverter – Busines Logic Datenkonverter – Sicherheit GUI – Datenkonverter Business Logic – Datenbank Im Systemtest wird das gesamte System Com42Bill getestet. Hierbei werden folgende Anwendungsfälle, die durch die Aktivitätsdiagramme beschrieben werden, untersucht: a) Rechnungssteller: Registrieren Login Finanzkonto anlegen Finanzkonto löschen Finanzkonto editieren Rechnungsstellerkonto editieren Rechnungsdaten importieren b) Rechnungsempfänger: Registrierung Login Verwaltung der persönlichen Daten Kontenverwaltung Rechnungsverwaltung Rechnungspräsentation c) Betreiber (Sicherheit): Benutzer anlegen Benutzer editieren Benutzer löschen Gruppe anlegen Gruppe editieren Gruppe löschen Testziele Das allgemeine Testziel ist es, zu verifizieren, ob die an das System gestellten Erwartungen erfüllt werden. Ein Schwerpunkt sind hierbei die funktionalen Anforderungen an das System. Der Test soll sicherstellen, dass die zuvor definierten Anwendungsfälle vollständig und korrekt abgearbeitet werden. Desweiteren muss überprüft werden, ob die nicht-funktionalen Anforderungen einen bestimmten Erfüllungsgrad erreichen. Ein wichtiger Faktor ist an dieser Stelle die Zuverlässigkeit bzw. Robustheit des Systems. Das Software System Com42Bill hat den Test bestanden, wenn die einzelnen Testzielkriterien den jeweils vorgegebenen Prozentsatz erfüllt haben: Funktionalität: >90% Korrektheit: >95% Robustheit: >90% Testeinschränkungen Die Leistungsbeschränkung des Servers und die maximal mögliche Anzahl von acht Clients im Versuchsaufbau ermöglichen keinen Belastungstest des Systems. Aufgrund der geringen Zeit, die für das Testen zur Verfügung steht, wird auf einen vollständigen Klassentest verzichtet und stattdessen ein Klassentest nur exemplarisch an einigen elementaren Klassen durchgeführt werden. Aus dem gleichen Grund wird bei den Build-In-Tests auf eine vollständige Isolierung des Testlings, also ein Ersetzen aller von dem Testling benötigten Klassen durch Dummyklassen, verzichtet. Auf Klassen, die fast ausschließlich zur Speicherung von Daten dienen, darf in diesen Tests zugegriffen werden. Teststrategie Folgende Teststrategien werden bei den Tests verwendet: Klassentest: Statische Programmanalyse, Build-In-Tests Komponententest: Build-In-Tests Integrationstest: Top-Down-Strategie (nachrichtenbasiert) Systemtest: Anwendungsfallstrategie Kriterien für das Ende des Tests Um die Kriterien für das Testende zu beschreiben, sind folgende Begriffe wichtig: C0-Überdeckung: Quotient aus der Anzahl der durchlaufenen Anweisungen und der Anzahl aller Anweisungen des Testlings C1-Überdeckung: Quotient aus der Anzahl der durchlaufenen Zweige und der Anzahl aller Zweige des Testlings Damit der Test als erfolgreich absolviert gelten kann, müssen die einzelnen Testphasen folgende Kriterien erfüllen. Klassentest: Aus Zeitgründen kann eine vollumfängliche Überprüfung der C0-Überdeckung bzw. der C1-Überdeckung in den Klassen nicht erfolgen. Stattdessen können die C0-Überdeckung und C1-Überdeckung nur stichprobenartig überprüft werden. Komponententest: Alle definierten Schnittstellen einer Komponente müssen mit korrekten und fehlerhaften Nachrichten angestoßen werden. Die Schnittstellen und die dafür definierten Nachrichtentypen ergeben sich aus der Spezifikation des Request Dictionaries der betroffenen Komponente. Integrationstest: Es müssen alle Nachrichten, die für die jeweilige Schnittstelle spezifiziert worden sind, getestet werden. Die Schnittstellen und die dafür definierten Nachrichtentypen ergeben sich aus der Spezifikation des Request Dictionaries der betroffenen Komponenten. Systemtest: Alle für das System spezifizierten Anwendungsfälle müssen durchlaufen werden (vgl. Anhang E.3). Testergebnisse Das Testprojekt liefert die folgenden Testdokumente. Sollte bei einem Test ein Fehler nachgewiesen werden, der eine weitere Behandlung des Testlings erfordern, so müssen die entsprechenden Korrekturen durch die betroffenen Entwickler durchgeführt werden. Der Test muss danach wiederholt werden. Testplan (dieses Dokument) Testentwurf Testfallspezifikation Testprozeduren Testobjektverzeichnis Testlog Testvorfallbericht Testabschlussbericht Testaufgaben In dem Testprojekt ergeben sich die im Folgenden beschriebenen Testaufgaben, die sich in die drei Bereiche „vorbereitende Aufgaben“, „Testausführung“ und „Testauswertung“ unterteilen lassen. Testvorbereitungsaufgaben Testanforderungen ermitteln Testansatz festlegen Testszenarien ausarbeiten Kriterien für das Testende setzen Testfälle spezifizieren Testumgebung aufbauen Testausführungsaufgaben Klassen-Code-Reviews durchführen Build-In-Klassentests durchführen Klassen abnehmen Build-In-Komponententests durchführen Komponenten abnehmen Integrations-/Schnittstellentest durchführen Komponentenintegration abnehmen Gesamtsystemtest durchführen Gesamtsystem abnehmen Testauswertungsaufgaben Testprotokolle auswerten Testüberdeckung bestimmen Mängelbericht verfassen Testbericht schreiben Testumgebungsanforderungen An die Testumgebung werden folgende Anforderungen gestellt: Hardware: Zwei PCs (Client & Server), LAN Software: Betriebssystem Windows 2000, Java Entwicklungsumgebung Together Control Center 6.0, Application Server BEA Weblogic 6.1, Datenbank Oracle 8i Personell: Für die einzelnen Testphasen muss jeweils mind. ein Vertreter des Qualitätsmanagements und ein Vertreter des betroffenden Testlings anwesend sein. Testverantwortlichkeiten Im Folgenden wird die Aufgabenverantwortung festgelegt. Bei den Testaufgaben steht das Qualitätsmanagement, wie in der Testaufgabenverteilung zu sehen, den Entwicklern beratend zur Seite. Die testenden Entwickler können zwar ihre selbstgeschriebene Komponente Testen, jedoch sollte ein Entwickler seinen eigenen Code testen. Teststrategie ► Qualitätsmanagement Tes► Qualitätsmanagement Testumgebung ► Systemadministration Klassentests ► Entwickler Komponententests ► Entwickler Integrationstest ► Entwickler (Testgruppe) Systemtest ► Testgruppe Systemabnahme ► Projektbetreuer Testaufgabenverteilung Die Einzelaufgaben werden unter den Gruppen wie folgt verteilt: Testanforderungen ermitteln ► Qualitätsmanagement Testansatz festlegen ► Qualitätsmanagement Testszenarien ausarbeiten ► Entwickler, Qualitätsmanagement Testendekriterien setzen ► Qualitätsmanagement Testfälle spezifizieren ► Entwickler Testumgebung aufbauen ► Systemadministration Klassen-Code-Reviews durchführen ► Entwickler, QM, Beisitzer Build-In-Klassentests durchführen ► Entwickler Klassen abnehmen ► Qualitätsmanagement Build-In-Komponententests durchführen ► Entwickler Komponenten abnehmen ► Qualitätsmanagement Integrations-/Schnittstellentest ► Entwickler Komponentenintegration abnehmen ► Qualitätsmanagement Gesamtsystemtest durchführen ► Testgruppe Gesamtsystem abnehmen ► Projektbetreuer Testprotokolle auswerten ► Qualitätsmanagement Testüberdeckung bestimmen ► Qualitätsmanagement Mängelbericht verfassen ► Qualitätsmanagement Testbericht schreiben ► Qualitätsmanagement Fehlerbehebung ► Entwickler Testzeitplan Die Spezifikation der Testfälle und die Vorbereitung der Tests müssen spätestens bis zur Fertigstellung der ersten Klassen erfolgen, damit die ersten Klassentests umgehend durchgeführt werden können. Die Klassentests erfolgen also parallel zur Implementierungsphase. Eine Klasse wird zwar schon während der Entwicklungsphase durch den Entwickler Tests unterzogen, jedoch wird sie erst als korrekt getestet angesehen, wenn die vollständig implementiNr. NameZeitraumArt des TestsTestzielVerantwortlichkeiten1DK-Review I28.11.2002-02.12.2002Code-Review (White-Box-Test)Überprüfen des Codes einer ausgewählten Klasse auf Logikfehler auch unter besonderer Begutachtung von Sonderfällen. Check, ob der Codeguide eingehalten wurdeZahir, Alexander 2GUI-Review I28.11.2002-02.12.2002Code-Reviews. Nr. 1Dino, Christian3Sicherheit-Review I02.12.2002-09.12.2002Code-Reviews. Nr. 1Dennis, Alexander, Christian4BL-Review I02.12.2002-09.12.2002Code-Reviews. Nr. 1Narcisse, Alexander, Christian5DB-Review I28.11.2002-02.12.2002Code-Reviews. Nr. 1Andre, Alexander, Christian6DK-Klassentest I02.12.2002-09.12.2002Build-In-Klassentest (White-Box-Test)Möglichst vollständiger Test der Funktionen einer ausgewählten Klasse durch Überdeckung möglichst aller Entscheidungsteilbäume der Funktion (C1-Überdeckung)Zahir, Christian7GUI-Klassentest I02.12.2002-09.12.2002Build-In-Klassentests. Nr. 6Matthias8Sicherheit-Klassentest I09.12.2002- 16.12.2002Build-In-Klassentests. Nr. 6Bastian9BL-Klassentest I09.12.2002-16.12.2002Build-In-Klassentests. Nr. 6Timo, Alireza10DB-Klassentest I02.12.2002- 09.12.2002Build-In-Klassentests. Nr. 6Andre11DK-Komponententest I09.12.2002- 16.12.2002Build-In-Komponententest (Black-Box-Test)Test der Funktionen einer Komponente durch Aufruf der Komponente mit allen spezifizierten Nachrichten. Dabei sollen sowohl richtige als auch fehlerhafte Nachrichten verarbeitet werden. (Äquivalenzklassenabdeckung)DK12GUI-Komponententest I09.12.2002-16.12.2002Build-In-Komponententests. Nr. 11GUI13Sicherheit-Komponententest I16.12.2002- 23.12.2002Build-In-Komponententests. Nr. 11Sicherheit14BL-Komponententest I16.12.2002- 23.12.2002Build-In-Komponententests. Nr. 11BL15DB-Komponententest I09.12.2002- 16.12.2002Build-In-Komponententests. Nr. 11DB16Integrationstest I DK-Sicherheit06.01.2003-13.01.2003Build-In-Integrationstest (Nachrichten-basierend) (Grey-Box-Test)Check der Nachrichten, die zwischen den Komponenten ausgetauscht werden. DK, Sicherheit17Integrationstest II GUI-Sicherheit06.01.2003- 13.01.2003Build-In-Integrationstests. Nr. 16GUI, Sicherheit18Integrationstest III Sicherheit-DB13.01.2003- 20.01.2003Build-In-Integrationstests. Nr. 16Sicherheit, DB19Integrationstest IV BL-DB13.01.2003- 20.01.2003Build-In-Integrationstests. Nr. 16BL, DB20Integrationstest V GUI-BL20.01.2003- 27.01.2003Build-In-Integrationstests. Nr. 16DK, BL21Integrationstest VI DK-BL20.01.2003- 27.01.2003Build-In-Integrationstests. Nr. 16DK, BL22Gesamtsystemtest27.01.2003- 03.02.2003Black-Box-TestDie durch die Aktivitäts-diagramme geforderten Anwendungsfälle werden getestet.Testgruppe Testrisiken und Notfallplan Risiken bei den Tests sind ein unerwartet hoher Zeitaufwand bei der Planung und Durchführung der Tests zu Lasten der Entwicklung. Sollte sich ein solches Szenario abzeichnen, so müssen die Tests auf notwendige Bereiche gekürzt werden oder aber einige Tests ausgesetzt werden. Ein weiteres Risiko bei diesem Vorgehen ist es allerdings, dass der Aufwand, spät entdeckte Fehler zu beheben, sehr gross sein kann. Das gleiche Vorgehen der Kürzung bzw. Aussetzung von Tests bietet sich an, wenn die Entwickler den Implementatierungszeitplan nicht einhalten können, so dass auch die geplanten Tests nicht rechtzeitig durchgeführt werden können. Fazit Aufgrund von Problemen bei der Vorabintegration der Komponenten in der Implementierungsphase wurde die zuvor festgelegte Teststrategie geändert. Wie geplant, wurden Klassenreviews, Klassentests, Integrationstests und ein abschliessender Systemtest durchgeführt. Die Komponententests, die zwischen den Klassen- und den Integrationstests angesetzt waren, wurden nicht durchgeführt. Zu dem dafür vorgesehenen Zeitpunkt bestand das Problem, dass die Komponenten im Rahmen von Vorabintegrationen ständig angepasst werden mussten und somit kein abschließender Zustand vorherrschte, der hätte getestet werden können. Die Durchführung der Klassentests konnte bei der Komponente Business Logic nicht vollzogen werden. Bei einem Klassentest muss der Testling weitestgehend von anderen Klassen isoliert werden. Die Klassen der Business Logic können erst im Rahmen einer Workflowkonfiguration sinnvoll miteinander verknüpft werden. Separat betrachtet enthalten sie zu wenig Funktionalität, um getestet werden zu können. Die Integrationstests waren ebenfalls Einschränkungen unterlegen. Zwischen den Komponenten Business Logic und Datenbank gab es keine einheitlichen Schnittstellen, an der Daten hätten abgegriffen werden können. Aus Zeitgründen konnten die Tests in den einzelnen Testphasen nicht vollständig durchgeführt werden. Bei den Klassenreviews und Klassentests wurde jeweils exemplarisch von jeder Komponente nur eine Klasse getestet. Die Integrationstests wurden im Rahmen eines demonstrativen Tests durchgeführt, bei dem die im Systementwurf erstellten Anwendungsfälle zugrunde gelegt wurden. Ein destruktiver Test wäre zu aufwendig gewesen. Bei der Durchführung des Testprojektes konnten in jeder Testphase Fehler gefunden werden. Aufgrund der erwähnten Einschränkungen hätte ein Großteil der Fehler aber wahrscheinlich früher aufgedeckt werden können. Da die Komponententests nicht durchgeführt wurden, konnten Fehler in den einzelnen Komponenten erst während der Integrationstests gefunden werden. Das hat die Integration erheblich verkompliziert. Ein Komponententeam musste auf ein anderes warten, während dieses die Fehler in ihrer Komponente beheben. Dadurch hat sich diese Phase stark in die Länge gezogen. Auch wenn die einzelnen Testphasen eingeschränkt wurden, war das Durchführen des Testprojektes mit einem nicht zu unterschätzenden Aufwand verbunden. Es hat sich aber in jedem Fall gelohnt, da eine Vielzahl von Fehlern verschiedenster Schwierigkeitsgrade aufgedeckt und rechtzeitig behoben werden konnte. : Qualitätsmanagement: Reviews Im Folgenden werden die Berichte, die sich aus den durchgeführten Klassenreviews ergeben haben, dargestellt. de.Com42Bill.components.security.Authentification.java Review- Bericht Review-Name: _Authentification_ Review-Nr.: _1_____ Seite _1___ von _2__2____ Datum: 13.12.2002 Zeit von: _9:50_ bis _10:20_Testling Name / Version Authentification.java Referenzunterlagen Name / Version Anforderungen Bewertung / Maßnahmen ■ akzeptiert □ keine Änderungen notwendig □ nicht akzeptiert ■ kleine Änderungen □ Review nicht beendet □ grosse Änderungen □ Überarbeitung  Review-TeamNameFunktionUnterschriftAlexander SchmitzModeratorChristian KotthoffEntwurfskontrolleDennis MüllerCodierung FreigabeNameDatumUnterschriftAlexander Schmitz13.12.2002 Review-Nr.: _1_____ Seite _2___ von _2____ Liste der Befunde □ im Testling ■ in den Referenzunterlagen Nr.OrtBefundBewertung1 2 3 4S20 S23 Anforderung entfällt Anforderung entfällt Anforderung entfällt Wurden an die BL abgegebenmin/e min/e min/e min/w Bewertung: Fehlerart: wrong / missing / extra Fehlertyp: major / minor de.Com42Bill.components.security.RequestAuthorizationBean.java Review- Bericht Review-Name: _RequestAuthorizationBean_ Review-Nr.: _1_____ Seite _1___ von _2____ Datum: 13.12.2002 Zeit von: _10:20_ bis _10:45_Testling Name / Version RequestAuthorizationBean.java ReferenzunterlagenReferenzunterlagen Name / Version Anforderungen Bewertung / Maßnahmen ■ akzeptiert ■ keine Änderungen notwendig □ nicht akzeptiert □ kleine Änderungen □ Review nicht beendet □ grosse Änderungen □ Überarbeitung  Review-TNameFunktionUnterschriftAlexander SchmitzModeratorChristian KotthoffEntwurfskontrolleDennis MüllerCodierung FreigabeNameDatumUnterschriftAlexander Schmitz13.12.2002 Review-Nr.: _1_____ Seite _2___ von _2____ Liste der Befunde □ im Testling □ in den Referenzunterlagen Nr.OrtBefundBewertung1GUIMuss SessionID speichern und bei jedem folgenden Aufruf mitgebenmaj/m Bewertung: Fehlerart: wron□ im Testling □ in den Referenzunterlagen Nr.OrtBefundBewertung1GUIMuss SessionID speichern und bei jedem folgenden Aufruf mitgebenmaj/m Bewertung: Fehlerart: wrong / missing / extra Fehlertyp: major / minor de.Com42Bill.components.gui.HistoryCReview- Bericht Review-Name: HistoryControllerBean__ Review-Nr.: _1____ Seite __1__ von __2___ Datum: 06.12.2003 Zeit von: _13:30_ bis _14:15_Testling Name / Version HistoryControllerBean.java Version 1.8 Referenzunterlagen Name / Version Anforderungen Bewertung / Maßnahmen □ akzeptiert □ keine Änderungen notwendig ■ nicht akzeptiert ■ kleine Änderungen □ Review nicht beendet ■ grosse Änderungen □ Überarbeitung  akzeptiert □ keine Änderungen notwendig ■ nicht akzeptiert ■ kleine Änderungen □ Review nicht beendet ■ grosse Änderungen □ Überarbeitung  Review-TeamNameFunktionUnterschriftAlexander SchmitzModeratorChristian EntwurfskontrolleDino HasanbegovicCodierung FreigabeNameDatumUnterschriftAlexander Schmitz06.12.2002 Review-Nr.: __1____ Seite __2__ von __2___ Liste der Befunde ■ im Testling □ in den Referenzunterlagen Nr.OrtBefundBewertung1 2 3 4 5 6 7 8 9 Zeile 235 267-269 84-89 198-199 207 219 ? G-055 G-062 Widerspricht G-062 (DB-Speicherung) ExceptionHandling unzureichend Dokumentati■ im Testling □ in den Referenzunterlagen Nr.OrtBefundBewertung1 2 3 4 5 6 7 8 9 Zeile 235 267-269 84-89 198-199 207 219 ? G-055 G-062 Widerspricht G-062 (DB-Speicherung) ExceptionHandling unzureichend Dokumentation fehlt Nicht alle Keys vorhanden, die ignoriert werden sollen Ignorieren bestimmter Keys fehlt SessionContext für den Lookup bei Passivate fehlt Backbuttenbehandlung (getLastPage) fehlBewertung: Fehlerart: wrong / missing / extra Fehlertyp: major / minor de.Com42Bill.components.dataconverter.impExpMgr.ImpExpMgrBean.java Review- Bericht Review-Name: ImpExpMgrBean__ Review-Nr.: _1____ Seite __1__ von __2___ Datum: 09.01.2003 Zeit von: _16:20_ bis _17:00_Testling Name / Version ImpExpMgrBean.java Version 1.13 Referenzunterlagen Name / Version Anforderungen Bewertung / Maßnahmen □ akzeptiert □ keine Änderungen notwendig ■ nicht akzeptiert ■ kleine Änderungen □ Review nicht beendet □ grosse Änderungen □ Überarbeitung  Review-TeamNameFunktionUnterschri akzeptiert □ keine Änderungen notwendig ■ nicht akzeptiert ■ kleine Änderungen □ Review nicht beendet □ grosse Änderungen □ Überarbeitung  Review-TeamNameFunktionUnterschriftAlexander SchmitzModeratorChristian KotthoffEntwurfskontrolleZahir AmiriCodierung FreigabeNameDatumUnterschriftAlexander Schmitz09.01.2003 Review-Nr.: __1____ Seite __2__ von __2___ Liste der Befunde ■ im Testling □ in den Referenzunterlagen Nr.OrtBefundBewertung1 2 3 4 5 6 7 8 9 10 11Zeile 90-94 134-136 178-182 216-220 274 287-290 294-296 328-331 362-364 452-453 509-511WorkflowIdentifier mit Konstanten arbeiten, die komponentenübs. 1min/mi min/mi min/mi maj/mi min/mi maj/mi min/mi min/mi min/mi min/mi min/mi Bewertung: Fehlerart: wrong / missing / extra Fehlertyp: major / minor Qualitätsmanagement: Klassentests Im Folgenden werden die Ergebnisdokumente der durchgeführten Klassentests dargestellt. Zu jeder Methode werden alle Kombinationen von Eingabeparametern, die sich aus der Inspektion des Quellcodes der Methode ergeben haben, getestet. Für jede Eingabe wird die erwartete Ausgabe mit der Ausgabe des Testprogramms verglichen. Wenn diese nicht übereinstimmen, enthält die Methode einen Fehler. de.Com42Bill.components.security.Authentification.java Methode: isAuthentification(String startNode) Eingabe: ParameterWertstartNodenullErwartete Ausgabe: ParameterWertCom42BillSecurityExceptionRESULT_NULL_ARGUMENTBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.isAuthentification(null) ### TEST ### Result: Com42BillSecurityException:'RESULT_NULL_ARGUMENT' Eingabe: ParameterWertstartNode„login“Erwartete Ausgabe: ParameterWertReturn-WerttrueBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.isAuthentification("login") ### TEST ###: Result: true Eingabe: ParameterWertstartNode„logout“ Erwartete Ausgabe: ParameterWertReturn-WerttrueBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.isAuthentification("logout") ### TEST ###: Result: true Eingabe: ParameterWertstartNode„XXX“Erwartete Ausgabe: ParameterWertReturn-WertfalseBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.isAuthentification("XXX") ### TEST ###: Result: false Methode: isLogin(String startNode) Eingabe: ParameterWertstartNodenullErwartete Ausgabe: ParameterWertCom42BillSecurityExceptionRESULT_NULL_ARGUMENT Beobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.isLogin(null) ### TEST ### Result: Com42BillSecurityException:'RESULT_NULL_ARGUMENT' Eingabe: ParameterWertstartNode„login“Erwartete Ausgabe: ParameterWertReturn-WerttrueBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.isLogin("login") ### TEST ### Result: true Eingabe: ParameterWertstartNode„XXX“Erwartete Ausgabe: ParameterWertReturn-WertfalseBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.isLogin("XXX") ### TEST ### Result: false Methode: isLogout(String startNode) Eingabe: ParameterWertstartNodenullErwartete Ausgabe: ParameterWertCom42BillSecurityExceptionRESULT_NULL_ARGUMENTBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.isLogout(null) ### TEST ### Result: Com42BillSecurityException:'RESULT_NULL_ARGUMENT' Eingabe: ParameterWertstartNode„logout“Erwartete Ausgabe: ParameterWertReturn-WerttrueBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.isLogout("logout") ### TEST ### Result: true Eingabe: ParameterWertstartNode„XXX“ Erwartete Ausgabe: ParameterWertReturn-WertfalseBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.isLogout("XXX") ### TEST ### Result: false Methode: authenticate(Request request) Eingabe: ParameterWertrequestnullErwartete Ausgabe: ParameterWertCom42BillSecurityExceptionRESULT_NULL_ARGUMENTBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.authenticate(null) java.lang.NullPointerException at de.Com42Bill.components.security.Authentification.authenticate (Authentification.java:106) at de.Com42Bill.components.gui.RequestDispatcherBean.test (RequestDispatcherBean.java:344) at de.Com42Bill.components.gui.RequestDispatcherBean.doRequest (RequestDispatcherBean.java:661) at de.Com42Bill.components.gui.RequestDispatcherBean_v6pmbq_EOImpl.doRequest (RequestDispatcherBean_v6pmbq_EOImpl.java:37) at de.Com42Bill.components.gui.RequestServlet.doPost (RequestServlet.java:211) at de.Com42Bill.components.gui.RequestServlet.doGet (RequestServlet.java:242) at javax.servlet.http.HttpServlet.service (HttpServlet.java:740) at javax.servlet.http.HttpServlet.service (HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:265) at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:200) at weblogic.servlet.internal.WebAppServletContext.invokeServlet (WebAppServletContext.java:2546) at weblogic.servlet.internal.ServletRequestImpl.execute (ServletRequestImpl.java:2260) at weblogic.kernel.ExecuteThread.execute (ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run (ExecuteThread.java:120) Eingabe: ParameterWertrequestrequest.requestDictionarynullErwartete Ausgabe: ParameterWertCom42BillSecurityExceptionRESULT_NULL_ARGUMENTBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.authenticate(request) request.requestDictionary = null java.lang.NullPointerException at de.Com42Bill.components.security.Authentification.authenticate (Authentification.java:109) at de.Com42Bill.components.gui.RequestDispatcherBean.test (RequestDispatcherBean.java:393) at de.Com42Bill.components.gui.RequestDispatcherBean.doRequest (RequestDispatcherBean.java:661) at de.Com42Bill.components.gui.RequestDispatcherBean_v6pmbq_EOImpl.doRequest (RequestDispatcherBean_v6pmbq_EOImpl.java:37) at de.Com42Bill.components.gui.RequestServlet.doPost(RequestServlet.java:211) at de.Com42Bill.components.gui.RequestServlet.doGet(RequestServlet.java:242) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:265) at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:200) at weblogic.servlet.internal.WebAppServletContext.invokeServlet (WebAppServletContext.java:2546) at weblogic.servlet.internal.ServletRequestImpl.execute (ServletRequestImpl.java:2260) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) Eingabe: ParameterWertrequestrequest.requestDictionary(FV_USERINFORMATION_LOGIN)nullErwartete Ausgabe: ParameterWertCom42BillSecurityExceptionRESULT_NULL_ARGUMENTBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.authenticate(request) request.requestDictionary("FV_USERINFORMATION_LOGIN"=null) java.lang.NullPointerException at java.util.Hashtable.put(Hashtable.java:375) at de.Com42Bill.ebppsystem.core.request.RequestDictionary.putFormValue (RequestDictionary.java:93) at de.Com42Bill.components.gui.RequestDispatcherBean.test (RequestDispatcherBean.java:443) at de.Com42Bill.components.gui.RequestDispatcherBean.doRequest (RequestDispatcherBean.java:661) at de.Com42Bill.components.gui.RequestDispatcherBean_v6pmbq_EOImpl.doRequest (RequestDispatcherBean_v6pmbq_EOImpl.java:37) at de.Com42Bill.components.gui.RequestServlet.doPost(RequestServlet.java:211) at de.Com42Bill.components.gui.RequestServlet.doGet(RequestServlet.java:242) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:265) at weblogic.servlet.internal.ServletStubImpl.invokeServlet (ServletStubImpl.java:200) at weblogic.servlet.internal.WebAppServletContext.invokeServlet (WebAppServletContext.java:2546) at weblogic.servlet.internal.ServletRequestImpl.execute (ServletRequestImpl.java:2260) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) Eingabe: ParameterWertrequestrequest.requestDictionary(FV_USERINFORMATION_LOGIN)„XXX“ (ungültiger Userlogin)Erwartete Ausgabe: ParameterWertCom42BillSecurityExceptionRESULT_WRONG_LOGINBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.authenticate(request) request.requestDictionary("FV_USERINFORMATION_LOGIN"="XXX") ### TEST ### Result: Com42BillSecurityException:'RESULT_WRONG_LOGIN' Eingabe: ParameterWertrequestrequest.requestDictionary(FV_USERINFORMATION_LOGIN)„Admin“ (gültiger Userlogin)request.requestDictionary(FV_USERINFORMATION_PASSWORD)„XXX“ (ungültiges Passwort)Erwartete Ausgabe: ParameterWertCom42BillSecurityExceptionRESULT_WRONG_LOGINBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Calling Authentification.authenticate(request) request.requestDictionary("FV_USERINFORMATION_LOGIN"="Admin") request.requestDictionary("FV_USERINFORMATION_PASSWORD"="XXX") ### TEST ### Result: Com42BillSecurityException:'RESULT_WRONG_LOGIN' Eingabe: ParameterWertrequestrequest.requestDictionary(FV_USERINFORMATION_LOGIN)„Admin“ (gültiger Userlogin)request.requestDictionary(FV_USERINFORMATION_PASSWORD)„Com42Bill“ (gültiges Passwort)Erwartete Ausgabe: ParameterWertReturn-WertUserLocalHomeBeobachtete Log-Ausgabe: ### TEST ### Result: Com42BillSe ### TEST ########################################################### ### TEST ###: Calling Authentification.authenticate(request) request.requestDictionary("FV_USERINFORMATION_LOGIN"="Admin") request.requestDictionary("FV_USERINFORMATION_PASSWORD"="Com42Bill") ### TEST ### Result: return UserInformationLocal Bewertung der Beobachtungen: Die als nicht schwerwiegend betrachteten Fehler des ersten Klassentests wurden ignoriert. Der Fehler, dass selbst gültige Benutzer nicht authentifiziert wurden, konnte auf die Encrypt-Methode zurückgeführt werden, mit der die Passworte der Benutzer verschlüsselt werden. Die Verschlüsselung erzeugte auch nicht druckbare Zeichen, die beim Abspeichern in der Datenbank zu einer Verkürzung der Strings führte, so dass der Vergleich der gespeicherten Passworte mit den übergebenen Fehlschlug. Die Encrypt-Methode wurde so modifiziert, dass jetzt nur noch druckbare Zeichen erzeugt werden. de.Com42Bill.components.gui.RequestDispatcherBean.java Methode: doRequest(Request request) Eingabe: ParameterWertrequestNullErwartete Ausgabe: ParameterWertLog-Ausgabe ExceptionStacktraceBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### request = NULL ##### ##### Ausgabe: java.lang.NullPointerException at de.Com42Bill.components.gui.RequestDispatcherBean.doRequest(RequestDispatcherBean.java:88) ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionarynullErwartete Ausgabe: ParameterWertLog-Ausgabe ExceptionStacktrace Beobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary = NULL ##### ##### Ausgabe: java.lang.NullPointerException at de.Com42Bill.components.gui.RequestDispatcherBean.doRequest(RequestDispatcherBean.java:89) ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„SecurityFlag“)RESULT_NULL_ARGUMENTErwartete Ausgabe: ParameterWertLog-Ausgabe Com42BillSecurityExceptionRESULT_NULL_ARGUMENTBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "RESULT_NULL_ARGUMENT" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): securityException:'RESULT_NULL_ARGUMENT' ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„SecurityFlag“)RESULT_NO_WORKFLOWIDENTIFIERErwartete Ausgabe: ParameterWertLog-Ausgabe Com42BillSecurityExceptionRESULT_NO_WORKFLOWIDENTIFIERBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "RESULT_NO_WORKFLOWIDENTIFIER" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): securityException:'RESULT_NO_WORKFLOWIDENTIFIER' ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„SecurityFlag“)RESULT_NO_STARTNODEErwartete Ausgabe: ParameterWertLog-Ausgabe Com42BillSecurityExceptionRESULT_NO_STARTNODEBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "RESULT_NO_STARTNODE" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): securityException:'RESULT_NO_STARTNODE' ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„SecurityFlag“)RESULT_WRONG_LOGINErwartete Ausgabe: ParameterWertLog-Ausgabe Com42BillSecurityExceptionRESULT_WRONG_LOGINBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "RESULT_WRONG_LOGIN" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): securityException:'RESULT_WRONG_LOGIN' ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„SecurityFlag“)RESULT_SESSION_NOT_IN_LISTErwartete Ausgabe: ParameterWertLog-Ausgabe Com42BillSecurityExceptionRESULT_SESSION_NOT_IN_LISTBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "RESULT_SESSION_NOT_IN_LIST" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): securityException:'RESULT_SESSION_NOT_IN_LIST' ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„SecurityFlag“)RESULT_UNKNOWN_REQUESTSOURCEErwartete Ausgabe: ParameterWertLog-Ausgabe Com42BillSecurityExceptionRESULT_UNKNOWN_REQUESTSOURCEBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "RESULT_UNKNOWN_REQUESTSOURCE" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): securityException:'RESULT_UNKNOWN_REQUESTSOURCE' ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„SecurityFlag“)RESULT_NO_INITIAL_CONTEXTErwartete Ausgabe: ParameterWertLog-Ausgabe Com42BillSecurityExceptionRESULT_NO_INITIAL_CONTEXTBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "RESULT_NO_INITIAL_CONTEXT" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): securityException:'RESULT_NO_INITAL_CONTEXT' ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„SecurityFlag“)RESULT_NO_SESSIONErwartete Ausgabe: ParameterWertLog-Ausgabe Com42BillSecurityExceptionRESULT_NO_SESSIONBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "RESULT_NO_SESSION" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): securityException:'RESULT_NO_SESSION' ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„SecurityFlag“)RESULT_WRONG_CLASSErwartete Ausgabe: ParameterWertLog-Ausgabe Com42BillSecurityExceptionRESULT_WRONG_CLASSBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "RESULT_WRONG_CLASS" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): securityException:'RESULT_WRONG_CLASS' ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„SecurityFlag“)RESULT_CREATE_EXCEPTIONErwartete Ausgabe: ParameterWertLog-Ausgabe Com42BillSecurityExceptionRESULT_CREATE_EXCEPTIONBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "RESULT_CREATE_EXCEPTION" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): securityException:'RESULT_CREATE_EXCEPTION' ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„SecurityFlag“)RESULT_UNKNOWN_REQUESTErwartete Ausgabe: ParameterWertLog-Ausgabe Com42BillSecurityExceptionRESULT_UNKNOWN_REQUESTBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "RESULT_UNKNOWN_REQUEST" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): securityException:'RESULT_UNKOWN_REQUEST' ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„SecurityFlag“)RESULT_SHA_NOT_AVAILABLEErwartete Ausgabe: ParameterWertLog-Ausgabe Com42BillSecurityExceptionRESULT_SHA_NOT_AVAILABLEBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "RESULT_SHA_NOT_AVAILABLE" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): securityException:'RESULT_SHA_NOT_AVAILABLE' ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„ErrorList“)ArrayListrequest.requestDicitionary(„SecurityFlag“)NO_SECURITY_EXCEPTIONrequest.Com42BillSessionLocalNicht NULLErwartete Ausgabe: ParameterWertLog-Ausgabe: request.requestDicitionary.put(„FV_USERINFORMATION“) ausgeführtLog-Ausgabe: RequestDispatcherBean.doRequest(): errorList!=null -> Syntaxfehler vorhandenBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "NO_SECURITY_EXCEPTION" ##### requestDictionary("ErrorList") = "ArrayList" ##### request("Com42BillSessionBean") = "nicht NULL" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): requestDictionary.put("FV_USERINFORMATION", userInformation) RequestDispatcherBean.doRequest(): errorList!=null -> Syntaxfehler vorhanden ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„ErrorList“)ArrayListrequest.requestDicitionary(„SecurityFlag“)NO_SECURITY_EXCEPTIONrequest.Com42BillSessionLocalNULLErwartete Ausgabe: ParameterWertLog-Ausgabe:RequestDispatcherBean.doRequest(): errorList!=null -> Syntaxfehler vorhandenBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "NO_SECURITY_EXCEPTION" ##### requestDictionary("ErrorList") = "ArrayList" ##### request("Com42BillSessionBean") = "NULL" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): errorList!=null -> Syntaxfehler vorhanden ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„ErrorList“)NULLrequest.requestDicitionary(„SecurityFlag“)NO_SECURITY_EXCEPTIONrequest.Com42BillSessionLocalNicht NULLrequest.requestDicitionary(„RequestStatusFlag“)GRANTEDErwartete Ausgabe: ParameterWertLog-Ausgabe:request.requestDicitionary.put(„FV_USERINFORMATION“) ausgeführtLog-Ausgabe:RequestDispatcherBean.doRequest(): checkRequest - HistoryController.GRANTEDBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "NO_SECURITY_EXCEPTION" ##### requestDictionary("ErrorList") = "NULL" ##### requestDictionary("RequestStatusFlag") = "GRANTED" ##### request("Com42BillSessionBean") = "nicht NULL" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): requestDictionary.put("FV_USERINFORMATION", userInformation) RequestDispatcherBean.doRequest(): checkRequest - HistoryController.GRANTED ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„ErrorList“)NULLrequest.requestDicitionary(„SecurityFlag“)NO_SECURITY_EXCEPTIONrequest.Com42BillSessionLocalNicht NULLrequest.requestDicitionary(„RequestStatusFlag“)CACHED_GRANTEDErwartete Ausgabe: ParameterWertLog-Ausgabe:request.requestDicitionary.put(„FV_USERINFORMATION“) ausgeführtLog-Ausgabe:RequestDispatcherBean.doRequest(): checkRequest - HistoryController.CACHED_GRANTEDBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "NO_SECURITY_EXCEPTION" ##### requestDictionary("ErrorList") = "NULL" ##### requestDictionary("RequestStatusFlag") = "CACHED_GRANTED" ##### request("Com42BillSessionBean") = "nicht NULL" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): requestDictionary.put("FV_USERINFORMATION", userInformation) RequestDispatcherBean.doRequest(): checkRequest - HistoryController.CACHED_GRANTED ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„ErrorList“)NULLrequest.requestDicitionary(„SecurityFlag“)NO_SECURITY_EXCEPTIONrequest.Com42BillSessionLocalNicht NULLrequest.requestDicitionary(„RequestStatusFlag“)FORBIDDENErwartete Ausgabe: ParameterWertLog-Ausgabe:request.requestDicitionary.put(„FV_USERINFORMATION“) ausgeführtLog-Ausgabe:RequestDispatcherBean.doRequest(): checkRequest - HistoryController.FORBIDDENBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "NO_SECURITY_EXCEPTION" ##### requestDictionary("ErrorList") = "NULL" ##### requestDictionary("RequestStatusFlag") = "FORBIDDEN" ##### request("Com42BillSessionBean") = "nicht NULL" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): requestDictionary.put("FV_USERINFORMATION", userInformation) RequestDispatcherBean.doRequest(): checkRequest - HistoryController.FORBIDDEN ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„ErrorList“)NULLrequest.requestDicitionary(„SecurityFlag“)NO_SECURITY_EXCEPTIONrequest.Com42BillSessionLocalNULLrequest.requestDicitionary(„RequestStatusFlag“)GRANTEDErwartete Ausgabe: ParameterWertLog-Ausgabe:RequestDispatcherBean.doRequest(): checkRequest - HistoryController.GRANTEDBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "NO_SECURITY_EXCEPTION" ##### requestDictionary("ErrorList") = "NULL" ##### requestDictionary("RequestStatusFlag") = "GRANTED" ##### request("Com42BillSessionBean") = "NULL" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): checkRequest - HistoryController.GRANTED ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„ErrorList“)NULLrequest.requestDicitionary(„SecurityFlag“)NO_SECURITY_EXCEPTIONrequest.Com42BillSessionLocalNULLrequest.requestDicitionary(„RequestStatusFlag“)CACHED_GRANTEDErwartete Ausgabe: ParameterWertLog-Ausgabe:RequestDispatcherBean.doRequest(): checkRequest - HistoryController.CACHED_GRANTEDBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "NO_SECURITY_EXCEPTION" ##### requestDictionary("ErrorList") = "NULL" ##### requestDictionary("RequestStatusFlag") = "CACHED_GRANTED" ##### request("Com42BillSessionBean") = "NULL" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): checkRequest - HistoryController.CACHED_GRANTED ##### Test doRequest ENDE... ####################################### Eingabe: ParameterWertrequest.requestDicitionary(„ErrorList“)NULLrequest.requestDicitionary(„SecurityFlag“)NO_SECURITY_EXCEPTIONrequest.Com42BillSessionLocalNULLrequest.requestDicitionary(„RequestStatusFlag“)FORBIDDENErwartete Ausgabe: ParameterWertLog-Ausgabe:RequestDispatcherBean.doRequest(): checkRequest - HistoryController.FORBIDDENBeobachtete Log-Ausgabe: ####################################### ##### Test doRequest START... ##### Eingabe: ##### requestDictionary("SecurityFlag") = "NO_SECURITY_EXCEPTION" ##### requestDictionary("ErrorList") = "NULL" ##### requestDictionary("RequestStatusFlag") = "FORBIDDEN" ##### request("Com42BillSessionBean") = "NULL" ##### ##### Ausgabe: RequestDispatcherBean.doRequest(): checkRequest - HistoryController.FORBIDDEN ##### Test doRequest ENDE... ####################################### Bewertung und Beobachtung: Die geprüften Methoden funktionieren in allen untersuchten Fällen fehlerfrei. Die Ausgaben stimmen stets mit den erwarteten Ausgaben überein. Die erzeugten NullpointerExceptions können aufgrund der Interaktion mit den anderen Komponenten nicht auftreten, da niemals Null-Referenzen, sondern stets belegte Parameter übergeben werden. de.Com42Bill.components.dataconverter.businessServiceInterface.AttachmentConstructorBean.java Methode: createDefaultAttachmentpart() Eingabe: ParameterWertkeineErwartete Ausgabe: ParameterWertAttachmentPartLeere ObjektinstanzBeobachtete Log-Ausgabe: ####################################### ##### Test createDefaultAttachmentpart START... ##### Eingabe: ##### keine ##### ##### Ausgabe: ##### Instanz von AttachmentPart wurde erzeugt. ##### Test createDefaultAttachmentpart ENDE... Methode: createBankTransferData(PaymentTransactionLocal paymentTransaction) Eingabe: ParameterWertpaymentTransactionSiehe untenpaymentTransaction.amount999.99paymentTransaction.paymentTransactionId03020401paymentTransaction.paymentReasonCom42Bill 3020401Daten des Auftraggebers:contractor.setAccountNo: 30204901contractor_financialServiceProvider.setBlz03020401contractor_financialServiceProviderCompanyDataSheet.setCompanyNameVolksbankcontractor_PersonDataSheet.setFirstNamePetercontractor_PersonDataSheet.setLastNameMeierDaten des Empfängers:recipient.setAccountNo30204701r_financialServiceProvider.setBlz03020401r_invoicingPartyCompanyDataSheet.setCompanyNameKarstadt Sportr_financialServiceProviderPartyCompanyDataSheet.setCompanyNameSparkasse DortmundErwartete Ausgabe: ParameterWertBankTransferData btdSiehe untenbtd.paymentTransactionId03020401btd.orderingParty_nameMeier, Peterbtd.orderingParty_bankCode30204901btd.orderingParty_bankVolksbankbtd.orderingParty_accountno30204901btd.recipient_nameKarstadt Sportbtd.recipient_bankCode03020401btd.recipient_bankSparkasse Dortmundbtd.recipient_accountno30204701btd.reasonForPaymentCom42Bill 3020401btd.amount999.99Beobachtete Log-Ausgabe: ####################################### ##### Ausgabe: AttachmentConstructorBean.createBankTransferData(): start AttachmentConstructorBean.createBankTransferData(): end BankTransferData btd = attachmentConstructor.createBankTransferData(this.paymentTransaction); Betrag = 999.99 Auftraggeber Kontonr.30204901 Auftraggeber Bank = Volksbank Auftraggeber Bank BLZ = 03020401 Auftraggeber Name = Meier, Peter Zahlungsgrund = Com42Bill 3020401 Empfõnger Kontonr. = 30204701 Empfõnger Bank = Sparkasse Dortmund Empfõnger BLZ= 03020401 Empfõnger Name = Karstadt Sport PaymentTransaction Id = 03020401 Eingabe: ParameterWertpaymentTransactionNULLErwartete Ausgabe: ParameterWertExceptionStacktraceBeobachtete Log-Ausgabe: ####################################### ##### Test createBankTransferData START... ##### Eingabe: ##### PaymentTransactionLocal paymentTransaction = NULL ##### ##### Ausgabe: java.lang.NullPointerException at de.Com42Bill.components.dataconverter.businessServiceInterface.AttachmentConstructorBean.createBankTransferData(AttachmentConstructorBean.java:91) ##### Test createBankTransferData ENDE... Methode: createAttachmentPart(Object obj) Eingabe: ParameterWertobjNULLErwartete Ausgabe: ParameterWertAttachmentPartLeere InstanzBeobachtete Log-Ausgabe: ####################################### ##### Test createAttachmentPart START... ##### Eingabe: ##### Object obj = NULL ##### ##### Ausgabe: ##### AttachmentPart als XML Stream: ##### Test createAttachmentPart ENDE... Eingabe: ParameterWertobjInstanceof PaymentTransactionLocal = paymentTransactionpaymentTransaction.amount999.99paymentTransaction.paymentTransactionId03020401paymentTransaction.paymentReasonCom42Bill 3020401Daten des Auftraggebers:contractor.setAccountNo: 30204901contractor_financialServiceProvider.setBlz03020401contractor_financialServiceProviderCompanyDataSheet.setCompanyNameVolksbankcontractor_PersonDataSheet.setFirstNamePetercontractor_PersonDataSheet.setLastNameMeierDaten des Empfängers:recipient.setAccountNo30204701r_financialServiceProvider.setBlz03020401r_invoicingPartyCompanyDataSheet.setCompanyNameKarstadt Sportr_financialServiceProviderPartyCompanyDataSheet.setCompanyNameSparkasse DortmundErwartete Ausgabe: ParameterWertAttachmentPartEnthält die im Objekt „btd“ enthaltenen Daten in XML konvertiertBankTransferData btdZwischenergebnisbtd.paymentTransactionId03020401btd.orderingParty_nameMeier, Peterbtd.orderingParty_bankCode30204901btd.orderingParty_bankVolksbankbtd.orderingParty_accountno30204901btd.recipient_nameKarstadt Sportbtd.recipient_bankCode03020401btd.recipient_bankSparkasse Dortmundbtd.recipient_accountno30204701btd.reasonForPaymentCom42Bill 3020401btd.amount999.99Beobachtete Log-Ausgabe: ####################################### ##### Test createAttachmentPart START... ##### Eingabe: ##### Object obj = instanceof PaymentTransactionLocal (= paymentTransaction) ##### ##### Ausgabe: Meier, Peter30204901Com42Bill 3020401030204010302040130204701Karstadt Sport999.99Volksbank03020401Sparkasse Dortmund ##### Test createAttachmentPart ENDE... ####################################### Eingabe: ParameterWertobjInstanceof BillingDataWorkflowResultList = resultListresultList.isSecurityExceptionFALSEresultList.invoiceDataTypes.invoiceContainer.invoice(0). invoiceNr123444resultList.invoiceDataTypes.invoiceContainer.invoice(0). invoiceRecipientNr123555resultList.invoiceDataTypes.invoiceContainer.invoice(0). invoicingPartyNr123666resultList.status(invoice(0).invoiceNr)okresultList.invoiceDataTypes.invoiceContainer.invoice(1). invoiceNr321444resultList.invoiceDataTypes.invoiceContainer.invoice(1). invoiceRecipientNr321555resultList.invoiceDataTypes.invoiceContainer.invoice(1). invoicingPartyNr321666resultList.status(invoice(1).invoiceNr)okresultList.invoiceDataTypes.incoiceCancellationContainer. invoiceCancellation(0).invoiceNr456777resultList.invoiceDataTypes.incoiceCancellationContainer. invoiceCancellation(0).invoiceRecipientNr456888resultList.invoiceDataTypes.incoiceCancellationContainer. invoiceCancellation(0).invoicingPartyNr456999resultList.status(invoiceCancellation(0).invoiceNrokresultList.invoiceDataTypes.incoiceCancellationContainer. invoiceCancellation(1).invoiceNr654777resultList.invoiceDataTypes.incoiceCancellationContainer. invoiceCancellation(1).invoiceRecipientNr654888resultList.invoiceDataTypes.incoiceCancellationContainer. invoiceCancellation(1).invoicingPartyNr654999resultList.status(invoiceCancellation(1).invoiceNrokErwartete Ausgabe: ParameterWertAttachmentPartEnthält die im Objekt „bdc“ enthaltenen Daten in XML konvertiertBillingDataConfirmation bdcZwischenergebnisbdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(0).invoiceNr123444bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(0).invoiceRecipientNr123555bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(0).invoicingPartyNr123666bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(0).statusokbdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(1).invoiceNr321444bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(1).invoiceRecipientNr321555bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(1).invoicingPartyNr321666bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(1).statusokbdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (0).invoiceNr456777bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (0).invoiceRecipientNr456888bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (0).invoicingPartyNr456999bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (0).statusokbdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (1).invoiceNr654777bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (1).invoiceRecipientNr654888bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (1).invoicingPartyNr654999bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (1).statusokBeobachtete Log-Ausgabe: ####################################### ##### Test createAttachmentPart START... ##### Ausgabe: ##### AttachmentPart als XML Stream: ok456888456777456999ok654888654777< invoicing-party-nr>654999ok123555123444123666ok3215553214443216 66 ##### Test createAttachmentPart ENDE... Eingabe: ParameterWertobjInstanceof BillingDataWorkflowResultList = resultListresultList.isSecurityExceptionTRUEErwartete Ausgabe: ParameterWertAttachmentPartEnthält die im Objekt „bdc“ enthaltenen Daten in XML konvertiertBillingDataConfirmation bdcZwischenergebnisbdc.confirmationInvoiceMessageAuthentifizierung fehlgeschlagen !!!Beobachtete Log-Ausgabe: ####################################### ##### Test createAttachmentPart START... ##### Eingabe: ##### Object obj = instanceof BillingDataWorkflowResultList (= resultList) ##### resultList.setIsSecurityException(TRUE) ##### ##### Ausgabe: ##### BillingDataConfirmation bdc ##### bdc.confirmationInvoiceMessage = "Fehlerhafte Authentifizierung !!!" ##### AttachmentPart als XML Stream: Fehlerhafte Authentifizierung !!! ##### Test createAttachmentPart ENDE... Eingabe: ParameterWertobjInstanceof InvoiceStatusWorkflowResultList = resultListresultList.isSecurityExceptionFALSEresultList.invoiceStatusContainer.invoiceStatus(0). invoiceNr123444resultList.invoiceStatusContainer.invoiceStatus (0). invoiceRecipientNr123555resultList.invoiceStatusContainer.invoiceStatus(0). invoicingPartyNr123666resultList.status(invoiceStatus(0).invoiceNr)bezahltresultList.invoiceDataTypes.invoiceContainer.invoiceStatus(1). invoiceNr321444resultList.invoiceDataTypes.invoiceContainer.invoiceStatus(1). invoiceRecipientNr321555resultList.invoiceDataTypes.invoiceContainer.invoiceStatus(1). invoicingPartyNr321666resultList.status(invoiceStatus(1).invoiceNr)1. Rate bezahltErwartete Ausgabe: ParameterWertAttachmentPartEnthält die im Objekt „bdsc“ enthaltenen Daten in XML konvertiertBillingDataStatusConfirmation bdscZwischenergebnisbdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(0).invoiceNr123444bdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(0).invoiceRecipientNr123555bdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(0).invoicingPartyNr123666bdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(0).statusbezahltbdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(1).invoiceNr321444bdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(1).invoiceRecipientNr321555bdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(1).invoicingPartyNr321666bdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(1).status1. Rate bezahltBeobachtete Log-Ausgabe: ####################################### ##### Test createAttachmentPart START... ##### Ausgabe: ##### AttachmentPart als XML Stream: ok< /status>123555123444123666ok321555321444321666 ##### Test createAttachmentPart ENDE... Eingabe: ParameterWertobjInstanceof InvoiceStatusWorkflowResultList = resultListresultList.isSecurityExceptionTRUEErwartete Ausgabe: ParameterWertAttachmentPartEnthält die im Objekt „bdsc“ enthaltenen Daten in XML konvertiertBillingDataStatusConfirmation bdscZwischenergebnisbdsc.confirmationInvoiceMessageAuthentifizierung fehlgeschlagen !!!Beobachtete Log-Ausgabe: ####################################### ##### Test createAttachmentPart START... ##### Eingabe: ##### Object obj = instanceof InvoiceStatusWorkflowResultList (= resultList) ##### resultList.setIsSecurityException(TRUE) ##### ##### Ausgabe: ##### BillingDataStatusConfirmation bdsc ##### bdsc.confirmationInvoiceStatusMessage = "Fehlerhafte Authentifizierung !!!" ##### AttachmentPart als XML Stream: Fehlerhafte Authentifizierung !!! ##### Test createAttachmentPart ENDE... Methode: createBillingDataConfirmation(BillingDataWorkflowResultList resultlist) Eingabe: ParameterWertresultListSiehe untenresultList.invoiceDataTypes.invoiceContainer.invoice(0). invoiceNr123444resultList.invoiceDataTypes.invoiceContainer.invoice(0). invoiceRecipientNr123555resultList.invoiceDataTypes.invoiceContainer.invoice(0). invoicingPartyNr123666resultList.status(invoice(0).invoiceNr)okresultList.invoiceDataTypes.invoiceContainer.invoice(1). invoiceNr321444resultList.invoiceDataTypes.invoiceContainer.invoice(1). invoiceRecipientNr321555resultList.invoiceDataTypes.invoiceContainer.invoice(1). invoicingPartyNr321666resultList.status(invoice(1).invoiceNr)okresultList.invoiceDataTypes.incoiceCancellationContainer. invoiceCancellation(0).invoiceNr456777resultList.invoiceDataTypes.incoiceCancellationContainer. invoiceCancellation(0).invoiceRecipientNr456888resultList.invoiceDataTypes.incoiceCancellationContainer. invoiceCancellation(0).invoicingPartyNr456999resultList.status(invoiceCancellation(0).invoiceNrokresultList.invoiceDataTypes.incoiceCancellationContainer. invoiceCancellation(1).invoiceNr654777resultList.invoiceDataTypes.incoiceCancellationContainer. invoiceCancellation(1).invoiceRecipientNr654888resultList.invoiceDataTypes.incoiceCancellationContainer. invoiceCancellation(1).invoicingPartyNr654999resultList.status(invoiceCancellation(1).invoiceNrokErwartete Ausgabe: ParameterWertBillingDataConfirmation bdcSiehe untenbdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(0).invoiceNr123444bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(0).invoiceRecipientNr123555bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(0).invoicingPartyNr123666bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(0).statusokbdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(1).invoiceNr321444bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(1).invoiceRecipientNr321555bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(1).invoicingPartyNr321666bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer. confirmationInvoice(1).statusokbdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (0).invoiceNr456777bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (0).invoiceRecipientNr456888bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (0).invoicingPartyNr456999bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (0).statusokbdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (1).invoiceNr654777bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (1).invoiceRecipientNr654888bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (1).invoicingPartyNr654999bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer. confirmationInvoiceCancellation (1).statusokBeobachtete Log-Ausgabe: ####################################### ##### Test createBillingDataConfirmation START... ##### Ausgabe: ##### BillingDataConfirmation bdc ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer.confirmationInvoice(0).invoiceNr = "123444" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer.confirmationInvoice(0).invoiceRecipientNr = "123555" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer.confirmationInvoice(0).invoicingPartyNr = "123666" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer.confirmationInvoice(0).status = "ok" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer.confirmationInvoice(1).invoiceNr = "321444" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer.confirmationInvoice(1).invoiceRecipientNr = "321555" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer.confirmationInvoice(1).invoicingPartyNr = "321666" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceContainer.confirmationInvoice(1).status = "ok" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer.confirmationInvoiceCancellation(0).invoiceNr = "456777" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer.confirmationInvoiceCancellation(0).invoiceRecipientNr = "456888" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer.confirmationInvoiceCancellation(0).invoicingPartyNr = "456999" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer.confirmationInvoiceCancellation(0).status = "ok" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer.confirmationInvoiceCancellation(1).invoiceNr = "654777" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer.confirmationInvoiceCancellation(1).invoiceRecipientNr = "654888" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer.confirmationInvoiceCancellation(1).invoicingPartyNr = "654999" ##### bdc.confirmationInvoiceDataTypes.confirmationInvoiceCancellationContainer.confirmationInvoiceCancellation(1).status = "ok" ##### Test createBillingDataConfirmation ENDE... Eingabe: ParameterWertresultListNULL Erwartete Ausgabe: ParameterWertExceptionstacktraceBeobachtete Log-Ausgabe: ####################################### ##### Test createBillingDataConfirmation START... ##### Eingabe: ##### BillingDataWorkflowResultList resultList = NULL ##### ##### Ausgabe: java.lang.NullPointerException at de.Com42Bill.components.dataconverter.businessServiceInterface.AttachmentConstructorBean.createBillingDataConfirmation(AttachmentConstructorBean.java:242) Methode: createBillingDataStatusConfirmation(InvoiceStatusWorkflowResultList resultlist) Eingabe: ParameterWertresultListSiehe untenresultList.invoiceStatusContainer.invoiceStatus(0). invoiceNr123444resultList.invoiceStatusContainer.invoiceStatus (0). invoiceRecipientNr123555resultList.invoiceStatusContainer.invoiceStatus(0). invoicingPartyNr123666resultList.status(invoiceStatus(0).invoiceNr)bezahltresultList.invoiceDataTypes.invoiceContainer.invoiceStatus(1). invoiceNr321444resultList.invoiceDataTypes.invoiceContainer.invoiceStatus(1). invoiceRecipientNr321555resultList.invoiceDataTypes.invoiceContainer.invoiceStatus(1). invoicingPartyNr321666resultList.status(invoiceStatus(1).invoiceNr)1. Rate bezahltErwartete Ausgabe: ParameterWertBillingDataStatusConfirmation bdscSiehe untenbdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(0).invoiceNr123444bdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(0).invoiceRecipientNr123555bdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(0).invoicingPartyNr123666bdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(0).statusbezahltbdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(1).invoiceNr321444bdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(1).invoiceRecipientNr321555bdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(1).invoicingPartyNr321666bdsc.confirmationInvoiceStatusContainer. confirmationInvoiceStatus(1).status1. Rate bezahltBeobachtete Log-Ausgabe: ####################################### ##### Test createBillingDataStatusConfirmation START... ##### Eingabe: ##### InvoiceStatusWorkflowResultList resultList) ##### resultList.invoiceStatusContainer.invoiceStatus0.setInvoiceNr("123444" ##### resultList.invoiceStatusContainer.invoiceStatus0.setInvoiceRecipientNr("123555" ##### resultList.invoiceStatusContainer.invoiceStatus0.setInvoicingPartyNr("123666" ##### resultList.put(invoiceStatus0.getInvoiceNr(), "ok" ##### resultList.invoiceStatusContainer.invoiceStatus1.setInvoiceNr("321444" ##### resultList.invoiceStatusContainer.invoiceStatus1.setInvoiceRecipientNr("321555" ##### resultList.invoiceStatusContainer.invoiceStatus1.setInvoicingPartyNr("321666" ##### resultList.put(invoiceStatus1.getInvoiceNr(), "ok" ##### ##### Ausgabe: ##### BillingDataStatusConfirmation bdsc ##### bdsc.confirmationInvoiceContainer.confirmationInvoiceStatus(0).invoiceNr = "123444" ##### bdsc.confirmationInvoiceContainer.confirmationInvoiceStatus(0).invoiceRecipientNr = "123555" ##### bdsc.confirmationInvoiceContainer.confirmationInvoiceStatus(0).invoicingPartyNr = "123666" ##### bdsc.confirmationInvoiceContainer.confirmationInvoiceStatus(0).status = "ok" ##### bdsc.confirmationInvoiceContainer.confirmationInvoiceStatus(1).invoiceNr = "321444" ##### bdsc.confirmationInvoiceContainer.confirmationInvoiceStatus(1).invoiceRecipientNr = "321555" ##### bdsc.confirmationInvoiceContainer.confirmationInvoiceStatus(1).invoicingPartyNr = "321666" ##### bdsc.confirmationInvoiceContainer.confirmationInvoiceStatus(1).status = "ok" ##### Test createBillingDataStatusConfirmation ENDE... Eingabe: ParameterWertresultListNULLErwartete Ausgabe: ParameterWertExceptionstacktraceBeobachtete Log-Ausgabe: ####################################### ##### Test createBillingDataStatusConfirmation START... ##### Eingabe: ##### InvoiceStatusWorkflowResultList resultList = NULL ##### Ausgabe: java.lang.NullPointerException at de.Com42Bill.components.dataconverter.businessServiceInterface.AttachmentConstructorBean.createBillingDataStatusConfirmation(AttachmentConstructorBean.java:341) Methode: createBillingDataSecurityFailureConfirmation() Eingabe: ParameterWertkeineErwartete Ausgabe: ParameterWertBillingDataConfirmation bdcSiehe untenbdc.confirmationInvoiceMessageAuthentifizierung fehlgeschlagen !!!Beobachtete Log-Ausgabe: ####################################### ##### Test createBillingDataSecurityFailureConfirmation START... ##### Eingabe: ##### keine ##### ##### Ausgabe: ##### BillingDataConfirmation bdc ##### bdc.confirmationInvoiceMessage = "Fehlerhafte Authentifizierung !!!" ##### Test createBillingDataSecurityFailureConfirmation ENDE... Methode: createBillingDataStatusSecurityFailureConfirmation() Eingabe: ParameterWertkeineErwartete Ausgabe: ParameterWertBillingDataStatusConfirmation bdscSiehe untenbdsc.confirmationInvoiceMessageAuthentifizierung fehlgeschlagen !!! Beobachtete Log-Ausgabe: ####################################### ##### Test createBillingDataStatusSecurityFailureConfirmation START... ##### Eingabe: ##### keine ##### ##### Ausgabe: ##### BillingDataStatusConfirmation bdsc ##### bdsc.confirmationInvoiceStatusMessage = "Fehlerhafte Authentifizierung !!!" ##### Test createBillingDataStatusSecurityFailureConfirmation ENDE... ####################################### ##### ENDE TEST AttachmentConstructorBean................ Bewertung und Beobachtung: Die geprüften Methoden funktionieren in allen untersuchten Fällen fehlerfrei. Die Ausgaben stimmen stets mit den erwarteten Ausgaben überein. Die erzeugten NullpointerExceptions werden in jeder Methode abgefangen und an eine andere Klasse zur Behandlung durchgereicht. Aufgrund der Interaktion mit den anderen Komponenten werden aber keine Null-Referenzen, sondern stets belegte Parameter übergeben. de.Com42Bill.ebppsystem.core.UserInformation.java Anmerkung: Die zum großen Teil durch Together automatisch generierten Funktionen zu testen ist sinnlos, daher wurde kein strikter Klassentest durchgeführt, sondern auch die Relationen zweier Entity-Beans. Bean-Generierung (mit Relation zu einer Entity-Bean InvoiceRecipient) Beobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Creating UserInformation ### TEST ###: setAddress("Mr.") ### TEST ###: setDescription("First user JohnDoe") ### TEST ###: setDisabled(false) ### TEST ###: setLogin("JohnDoe") ### TEST ###: setPassword("12345) ### TEST ###: setPasswordReminder("Count Numbers") ### TEST ###: setPasswordReminderEmail("JohnDoe@test.invalid") ### TEST ###: Creating InvoiceRecipient ### TEST ###: InvoiceRecipient.setCustomerNumber("123456"); ### TEST ###: Setting Relation between UserInformation and InvoiceRecipient Methode: findByLogin (Test mit Kontrolle der generierten Bean und der Relation) Eingabe: ParameterWertlogin„JohnDoe“Erwartete Ausgabe: ParameterWertReturn-WertUserInformationLocalBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Find Userinformation by Login - findByLogin("JohnDoe") ### TEST ### Result: Found UserInformationLocal ### TEST ### Result: UserInformationLocal.getAddress() = Mr. ### TEST ### Result: UserInformationLocal.getDescription() = First user JohnDoe ### TEST ### Result: UserInformationLocal.getDisabled() = false ### TEST ### Result: UserInformationLocal.getLogin() = JohnDoe ### TEST ### Result: UserInformationLocal.getPassword() = 123456 ### TEST ### Result: UserInformationLocal.getPasswordReminder() = Count ### TEST ### Result: UserInformationLocal.getPasswordReminderEmail() = JohnDoe@test.invalid ### TEST ### Checking if a relation to InvoiceRecipient exists: ### TEST ### Result: found InvoiceRecipient with CustomerNumber: 123456 ### TEST ### Checking if the revert relation from UserInformation to InvoiceRecipient exists: ### TEST ### Result: found UserInformation with Login: JohnDoe Eingabe: ParameterWertlogin„JOHNDOE“ (ungültiger Login)Erwartete Ausgabe: ParameterWertReturn-WertNullBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Find Userinformation by Login - findByLogin("JOHNDOE") javax.ejb.ObjectNotFoundException: Bean not found in 'findByLogin'. at de.Com42Bill.ebppsystem.core.user.UserInformationBean_4n1tv3_ _WebLogic_CMP_RDBMS.ejbFindByLogin(UserInformationBean_4n1tv3__WebLo gic_CMP_RDBMS.java:1338) at java.lang.reflect.Method.invoke(Native Method) at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.scalarFinder (RDBMSPersistenceManager.java:212) at weblogic.ejb20.manager.BaseEntityManager.scalarFinder (BaseEntityManager.java:539) at weblogic.ejb20.manager.BaseEntityManager.localScalarFinder (BaseEntityManager.java:489) at weblogic.ejb20.internal.EntityEJBLocalHome.finder (EntityEJBLocalHome.java:377) at de.Com42Bill.ebppsystem.core.user.UserInformationBean_4n1tv3_ LocalHomeImpl.findByLogin (UserInformationBean_4n1tv3_LocalHomeImpl.j ava:157) Eingabe: (Test bei dem zunächst eine zweite Bean mit gleichem Login angelegt wird) ParameterWertlogin„JohnDoe“ Erwartete Ausgabe: ParameterWertReturn-WertNullBeobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Creating UserInformation with Login "JohnDoe" again ### TEST ###: setAddress("Mr.") ### TEST ###: setDescription("Second user JohnDoe") ### TEST ###: setDisabled(false) ### TEST ###: setLogin("JohnDoe") ### TEST ###: setPassword("654321") ### TEST ###: setPasswordReminder("Count Numbers backwards") ### TEST ###: setPasswordReminderEmail("JohnDoe@test.invalid") ### TEST ########################################################### ### TEST ###: Find Userinformation by Login - findByLogin("JohnDoe") javax.ejb.FinderException: finder/ejbSelect 'findByLogin'has returned more than one value. We were expecting only ONE value. See EJB Spec 10.5.6.1, 10.5.7.1 at de.Com42Bill.ebppsystem.core.user.UserInformationBean_4n1tv3_ _WebLogic_CMP_RDBMS.ejbFindByLogin(UserInformationBean_4n1tv3__WebLo gic_CMP_RDBMS.java:1341) at java.lang.reflect.Method.invoke(Native Method) at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.scalarFinder (RDBMSPersistenceManager.java:212) at weblogic.ejb20.manager.BaseEntityManager.scalarFinder (BaseEntityManager.java:539) at weblogic.ejb20.manager.BaseEntityManager.localScalarFinder (BaseEntityManager.java:489) at weblogic.ejb20.internal.EntityEJBLocalHome.finder (EntityEJBLocalHome.java:377) at de.Com42Bill.ebppsystem.core.user.UserInformationBean_4n1tv3_Local HomeImpl.findByLogin(UserInformationBean_4n1tv3_LocalHomeImpl.j ava:157) Löschen der Bean (Es befindet sich nur eine Bean mit Login „John.Doe“ in der DB) Beobachtete Log-Ausgabe: ### TEST ########################################################### ### TEST ###: Find Userinformation by Login - findByLogin("JohnDoe") ### TEST ### Result: Found UserInformationLocal ### TEST ### Deleting User "John.Doe" ### TEST ###: Find Userinformation by Login - findByLogin("JohnDoe") javax.ejb.ObjectNotFoundException: Bean not found in 'findByLogin'. at de.Com42Bill.ebppsystem.core.user.UserInformationBean_4n1tv3_ _WebLogic_CMP_RDBMS.ejbFindByLogin(UserInformationBean_4n1tv3__WebLo gic_CMP_RDBMS.java:1338) at java.lang.reflect.Method.invoke(Native Method) at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.scalarFinder (RDBMSPersistenceManager.java:212) at weblogic.ejb20.manager.BaseEntityManager.scalarFinder (BaseEntityManager.java:539) at weblogic.ejb20.manager.BaseEntityManager.localScalarFinder (BaseEntityManager.java:489) at weblogic.ejb20.internal.EntityEJBLocalHome.finder (EntityEJBLocalHome.java:377) at de.Com42Bill.ebppsystem.core.user.UserInformationBean_4n1tv3_Local HomeImpl.findByLogin(UserInformationBean_4n1tv3_LocalHomeImpl.j ava:157) Bewertung der Beobachtungen: Die Methoden der getesteten Entity Beans funktionieren wie erwartet, bis auf eine Ausnahme: die ausgelösten FinderExceptions müssen bei Verwendung der Beans abgefangen und behandelt werden, besonders die vermutlich oft vorkommene „Bean not found“-Exception. Die „returned more than one value“-Exception bei einer N:1 oder 1:1-Relation hat zur Folge, dass bei Generierung von Beans überprüft werden muss, ob die neu zu generierende Bean solche Bedingungen verletzt. Es sollte noch geprüft werden, ob solche Fälle nicht durch Regeln in der DB abgefangen werden können. Der Test der Relation, in diesem Fall eine 1:1-Relation, war erfolgreich, der Vollständigkeit wegen wird in einem weiteren QM-Test noch eine M:N-Relation getestet werden. Qualitätsmanagement: Systemtest Nachfolgend werden die Ergebnisse des Systemtests dargestellt. Ausgeführte AktionErgebnisRechnungsempfänger registrierenEinleitungsseite anzeigenokRegistrierungsformular anzeigenokBenutzerdaten eingeben (stichprobenartiger Check der Syntaxkontrolle)okLogindaten eingebenokKontoninformationen eingebenokKontrolle der Daten (Übersicht)okBestätigungsmeldung der Registrierungok Rechnungsempfänger anmeldenLogindaten eingeben (Quick Login)okLogindaten eingeben (Normales Login)okAnzeige der Übersichtsseite „MyCom42Bill“ok Persönliche Daten editierenPersönliche Daten anzeigenokÄnderungen speichernok Kontodaten editierenListe der Konten anzeigenokKonto editierenokEditiertes Konto speichernokNeues Konto anlegenokNeues Konto speichernok Rechnungen importierenRechnung importierenok RechnungsübersichtSortieren nach Fälligkeitskriterienok, außer Sortieren nach RechnungsstellernRechnungen zur Bezahlung auswählenok Bezahlvorgang startenAnzeige des RechnungskorbsokEntfernen einer Rechnung aus dem RechnungskorbokKontoauswahlokBestätigung des Zahlungsauftragesok Rechnungsstatus importierenRechnungsstatus importierenok Rechnung stornierenStorno importierenok Verzeichnisse Abbildungsverzeichnis Sofern in den Grafiken nicht anders gekennzeichnet, wurden die Abbildungen durch die Autoren selbst erstellt. Abbildung 1: Welche Zahlungsarten würden Sie im Internet bevorzugen? 6 Abbildung 2: Aufbau eines 3- und mehrschichtigen Systems 10 Abbildung 3: Rollenmodell 16 Abbildung 4: Teilarchitektur der Komponente GUI 21 Abbildung 5: Teilarchitektur der Komponente Sicherheit 23 Abbildung 6: Beispiel-Workflow 25 Abbildung 7: Teilarchitektur der Komponente Business Logic 29 Abbildung 8: Kommunikation von Com42Bill mit anderen Systemen 30 Abbildung 9: Collaboration Protocol Profile (CPP) 31 Abbildung 10: Collaboration Protocol Agreement (CPA) 32 Abbildung 11: Beispielszenario 33 Abbildung 12: Struktur von Geschäftstransaktionen 34 Abbildung 13: Struktur einer ebXML-Nachricht 36 Abbildung 14: Teilarchitektur der Komponente Datenkonverter 38 Abbildung 15: Teilarchitektur der Komponente Datenbank 41 Abbildung 16: Begrüßungsseite 42 Abbildung 17: Popup-Menü 43 Abbildung 18: Aktuelles 43 Abbildung 19: MyCom42Bill 44 Abbildung 20: Login 44 Abbildung 21: Rechnungsübersicht 45 Abbildung 22:Bezahlvorgang – Schritt 1 46 Abbildung 23: Bezahlvorgang – Schritt 2 46 Abbildung 24: Bezahlvorgang – Bestätigung 47 Abbildung 25: Persönliche Daten ändern 47 Abbildung 26: Zahlungsmethode ändern 48 Abbildung 27: Kontodaten ändern 48 Abbildung 28: Logout 49 Abbildung 29: Registriervorgang – Erklärung 49 Abbildung 30: Registriervorgang – Persönliche Daten 50 Abbildung 31: Registriervorgang – Wahl des Logins 50 Abbildung 32: Registriervorgang – Kontoinformationen eingeben 51 Abbildung 33: Registriervorgang - Kontrollansicht 51 Abbildung 34: Support 52 Abbildung 35: FAQ 53 Abbildung 36: Anmeldung für den Administrator 54 Abbildung 37: Begrüßungsseite für den Administrator 54 Abbildung 38: Administrationsseite "Aktuelles" 55 Abbildung 39: FAQ-Übersicht 55 Abbildung 40: FAQ editieren 56 Abbildung 41: Benutzerauswahl 56 Abbildung 42: Benutzer editieren 57 Abbildung 43: Kontenauswahl 57 Abbildung 44: Konto editieren 58 Abbildung 45: Rechnungssteller auswählen 58 Abbildung 46: Rechnungssteller editieren 59 Abbildung 47: Finanzkonto editieren 59 Abbildung 48: Rechnungen suchen 60 Abbildung 49: Jobübersicht 60 Abbildung 50: Job konfigurieren 61 Abbildung 51: Berichte 61 Abbildung 52: Grobe Package-Struktur des Systems 63 Abbildung 53: Struktur des Package ebppsystem 63 Abbildung 54: Package-Struktur des Sub Package core 64 Abbildung 55: Struktur des Package common 65 Abbildung 56: Struktur des Package job 66 Abbildung 57: Struktur des Package user 67 Abbildung 58: Struktur des Package workflow 68 Abbildung 59: Struktur des Sub Package alert 69 Abbildung 60: Struktur des Sub Package businesspartner 70 Abbildung 61: Struktur des Sub Package invoice 71 Abbildung 62: Struktur des Package payment 72 Abbildung 63: Package-Struktur des Package components 73 Abbildung 64: Struktur des Package gui 74 Abbildung 65: Struktur des Package security 75 Abbildung 66: Notation 83 Abbildung 67: Entwicklungsprozess 85 Abbildung 68: Anforderungsanalyse 85 Abbildung 69: Anforderungen 86 Abbildung 70: Modelle 87 Abbildung 71: Technologieentscheidung 88 Abbildung 72: Auswahl von Key-Features 88 Abbildung 73: GUI-Design 89 Abbildung 74: Klassenmodell 89 Abbildung 75: Testplan 90 Abbildung 76: Prototyping 91 Abbildung 77: Implementierung 92 Abbildung 78: Komponentenschnittstellen 93 Abbildung 79: Projektplan, Teil 1 150 Abbildung 80: Projektplan, Teil 2 151 Abbildung 81: Projektplan, Teil 3 152 Abbildung 82: Projektplan, Teil 4 153 Abbildung 83: Testphasen 208 Literaturverzeichnis [APA01]Apache Jakarta Project (2001): BeanUtils, , 15.12.2002[As02]Ausarbeitungen zum Seminar Application Server (2002), Universität Dortmund 2002, [BPM00]BPMI.org (2000): The Business Process Management Initiative, , 20.07.2002[Bei01]Beijing, Cambridge, Farnham, et al. (2001): XML Pocket Reference, O'Reilly, 2001[BMI97]Bundesministerium für Bildung, Wissenschaft, Forschung und Technologie und Bundesministerium für Gesundheit (1997): Telematik im Gesundheitswesen – Perspektiven der Telemedizin in Deutschland, München, August 1997[Boe86]B. W. Boehm (1986): A Spiral Model of Software Development and Enhancement, In: Software Engineering Notes (1986) 11, 22-42[Bro02]Bronstein, Ilja N. u.a. (2000): Taschenbuch der Mathematik, Verlag Harry Deutsch AG, Thun, 2000[C42B02_2]Zwischenbericht der Projektgruppe 411 „Com42Bill“, interner Bericht, Universität Dortmund - Lehrstuhl für Software-Technologie, 2002[C42B02]Webseite des Projekts Com42Bill; z.Zt. sind die Ausarbeitungen zu dem Seminar nur über die Autoren bzw. die Projektgruppe erhältlich. Kontaktadressen siehe www.Com42Bill.de[Che01]T. M. Chester (2001): Cross-Platform Integration with XML and SOAP, IT Pro, September / Oktober 2001, S. 26-34[Ebx02]ebXML.org (2002): Enabling a global electronic market, , (15.04.2002)[Geo01]B. Georg (2001): Begriffswirrwarr beim Datenaustausch, e-commerce magazin (2001), August, S. 40-42[Has02]Hasanbegovic, D., Schmitz, A. (2002): E-Bill Anwendungen – Systeme, Produkte, Anbieter, PG-Seminar PG411, Dortmund / Nordhelle 2002[Kah01]B. Kahlbrandt (2001): Skript zur Vorlesung Software-Engineering II, 16.12.2001, (17.03.2002)[Kru98]P. Kruchten (1998): The Rational Unified Process – An Introduction, 1998, Addison-Wesley[IESE02]Fraunhofer Institute of Experimental Software Engineering (IESE) (2002): Vorgehensmodell (V-Modell) , (18.03.2002)[ISO00]EN ISO 8402 / EN ISO 9000:2000 / EN ISO 9001:2000 / EN ISO 9004:2000 [Jec01]M. Jeckle (2001): XML Tutorial, , 22.02.2002[Jep01]T. Jepsen (2001): SOAP Cleans up Interoperability Problems on the Web, IT Pro, Januar / Februar 2001, S. 52-55[Kie01]Kieser, M. (2001): Mobile Payment – Vergleich elektronischer Zahlungssysteme, HMD 220, 27-36[Kla01]A. Klafs (28.11.2001): Electronic Payment, (04.03.2002)[Kro96]Kron,Thomas (1996): Secure Electronic Transaction, (05.03.2002)[LBE01]Landesverband des Bayerischen Einzelhandels e.V.(2001): Positionspapier Telematik im Verkehr, München, Januar 2001[Mül02]Müller, D., Schlich, B. (2002): Softwareentwicklungsprozesse, PG-Seminar PG411, Dortmund / Nordhelle 2002[Mül99]G. Müller-Ettrich (1999): Objektorientierte Prozessmodelle – UML einsetzten mit OOIC, V-Modell, Objectory, Addison-Wesley[Mus02]Mustafa, N., Oberweis, A., Schnurr, T. (2002): Mobile Banking und Sicherheit im Mobile Commerce. In Silberer, G., Wohlfahrt, J., Wilhelm, T. (Hrsg.) (2002): Mobile Commerce – Grundlagen, Geschäftsmodelle, Erfolgsfaktoren. Gabler Verlag.[Obe98]Oberschelp, Walter (1998): Rechneraufbau und Rechnerstrukturen, 7. Auflage, München; Wien: Oldenbourg, 1998[Ogb00]U. Ogbuji (2000): Using WSDL in SOAP-Applications, (03.03.2002)[OM01]P. O’Connell und R. McCrindle (2001): Using SOAP to Clean up Configuration Management, Institute of Electrical and Electronics Engineers, 0-7695-1372-7/01, S. 555-560[Pay01]Paybox (2001): Zahlungsdienst per Handy, , (20.03.2002)[Pe01]Mathias Peick (2001): Mut zur Lücke – Erfahrungen mit Versionsmanagement, iX 2001, Heft 1, S.91ff.[RSA02]RSA Security Inc. (2002): RSA Laboratories FAQ about todays Cryptography, Version 4.1, [Sch00]Oliver Schade (2000): Kontroletti – Werkzeuge zur Versionsverwaltung, iX 2000, Heft 9, S.102ff.[So02]Solomon To, Ray Plant (2002): EBPP – Is this the end of the paper bill? (02.04.2002)[SQI02]Software Quality Institute (SQI) (2002): An Introduction to the Documents, (19.03.2002)[Sta01]G. Starke (2001): Datenaustausch im Web, IT FOKUS, Heft 7, Juni 2001, S. 72-75[Ste00]Dirk Stelzer (2000), Qualitätsmanagement in der Softwareentwicklung, Computer Reseller News Nr. 13/2000, 13.März 2000 [TDG02] Teledienstgesetz (TDG) in der Fassung vom 1.1.2002, §6: Allgemeine Informationspflichten[Udd00]Uddi.org (2000), UDDI Technical White Paper, (15.03.2002)[Wel99a]J. D. Wells (1999): The XP Philosophy, (13.03.2002)[Whb01]T. Weitzel, T. Harder, P. Buxmann (2001): Electronic Business und EDI mit XML, dpunkt-Verlag, 2001[Wie02]T. Wieland (2002): Werkzeuge für die Softwareentwicklung, (3.3.2002)[Wuv99]Werben & Verkaufen (1999): Fachzeitschrift zu Werbung, Kommunikation und Marketing, Juni 1999 (12.03.2002)[Ze00]Andreas Zeller, Jens Krinke (2000): Programmierwerkzeuge, 1. Aufl., Heidelberg, dpunkt Verlag 2000 Endbericht Endbericht Seite 68 von 1 Universität Dortmund – Projektgruppe 411 Universität Dortmund – Projektgruppe 411 Seite 62 von 296  Version 1.0 vom 26.03.2003 Zwischenbericht Universität Dortmund – Projektgruppe 411 Seite 141 von 141 Zwischenbericht Universität Dortmund – Projektgruppe 411 Seite 296 von 296 Timo Albert, Zahir Amiri, Dino Hasanbegovic Narcisse Kemogne Kamdem, Christian Kotthoff Dennis Müller, Matthias Niggemeier Andre Pavlenko, Stefan Pinschke Alireza Salemi, Bastian Schlich, Alexander Schmitz Volker Gruhn, Lothar Schöpe, Ursula Wellen Timo Albert, Zahir Amiri, Dino Hasanbegovic Narcisse Kemogne Kamdem, Christian Kotthoff Dennis Müller, Matthias Niggemeier Andre Pavlenko, Alireza Salemi, Bastian Schlich, Alexander Schmitz Volker Gruhn, Lothar Schöpe, Ursula Wellen