logicline entwickelt für den Finanzbereich eines Konzerns eine umfassende Compliance Lösung auf Basis der Cordys Business Operation Platform (BOP). Der Kunde setzt damit konzernweite Compliance-Vorgaben bezüglich Bankkonten und Zahlungsverkehr um und überwacht diese.

Die Umsetzung umfasst dabei den Hauptprozess einer Approval Process Plattform (TAPP)  (als generischen Prozess) mit maximaler Verästelung (Approvalstufen) und damit alle vorkommenden Approvalarten. Die konkreten Sub-Prozesse werden abgeleitet, angepasst und erweitert. Die Konfigurationsmöglichkeiten umfassen dabei Entscheidungstabellen (vom Fachbereich pflegbar), gewünschte Approvalschritte, E-Mail-Benachrichtigungen, Druckfunktionalitäten sowie die aufzurufenden Sub-Prozesse.

Zu Beginn des Projektes stand die Anforderung, basierend auf leicht (auch vom Fachbereich) veränderbaren Templates, Inhalte aus der Cordys BPMS Suite in PDF und Excel zu exportieren und damit speicher- und druckbar zu machen. Nach einer Analyse- und Auswahlphase entschieden wir uns für das eclipse BIRT Framework in der Version 2.6.1 (wobei die Version nicht maßgeblich war für die späteren Probleme). Entscheidungskriterien waren die Verfügbarkeit eines aktuellen Cordys Connectors für die BOP Version 4, Stand-Alone Template Designer, Open Source und Java als Programmiersprache. Damit ging der „Ärger“ los…

Die Installation und die Konfiguration des BIRT Reporting Connectors für Cordys klappte problemlos. Auch die Installation des Stand-Alone Designer (RCP Version) und des eclipse Plug-ins für die Entwicklung gingen ohne größere Probleme vonstatten, das erste rudimentäre Template war rasch erstellt. Ich spreche hier von einem Aufwand unter einem Tag. Dann begannen sich aber die Probleme (insbesondere nach dem ersten Deployment in der Kundenumgebung) zu häufen:

  1. Die Unterstützung für https war im BIRT Connector nicht vorgesehen.
  2. Der Zugriff der BIRT Runtime (dedizierte Java Runtime) aus der Infrastruktur des Kunden auf den von Cordys bereitgestellten Webservice war nicht ohne Änderungen möglich.
  3. Die Data Source (Webservice) und daraus abgeleitete Data Sets unterstützten nicht alle XPath Funktionen.

Unter diesen Prämissen entschieden wir uns den Cordys BIRT Connector und die Open Data Access (ODA) Komponenten an den geeigneten Stellen zu erweitern. Diese Erweiterung stellen wir im folgenden kurz dar:

Erweiterungen Cordys BIRT Connector

Im Cordys BIRT Connector wurde die Unterscheidung zwischen http und https, basierend auf im Cordys BOP zu setzten Properties eingefügt.

BIRT Connector

Erweiterung BIRT ODA Webservice

Im eclipse Plug-in Projekt für den ODA Webservice wurden einige Erweiterung für https eingebaut. Diese unterscheiden im Wesentlichen, wie der SOAP Endpoint aufgerufen werden soll und wie die Autorisierung und Authentifizierung (Zertfikate) erfolgen soll [ HTTPSClientConnector ]. Zusätzlich kann über SSL Properties der Zugriff auf den Keystore gesteuert werden.

Die wesentlichste Änderung ist der [ SoapResponseConnector ] der einen eingehenden SOAP Response erkennt, diesen behandelt und ihn in das bestehende BIRT Framework einspeist. Dazu wird nun in Cordys direkt der Webservice aufgerufen und das erhaltene Ergebnis als Parameter (PARAM) in die BIRT Runtime gegeben. Damit wird zwar das Grundprinzip vom BIRT (der unabhängige Zugriff auf eine Datenquelle) etwas ausgehebelt, aber nur so funktioniert die Druckfunktionalität in der speziellen Kundenumgebung (un das war die ursprüngliche Anforderung)…

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/">
    <SOAP:Body>
        <GetReport SAMLart="" xmlns="http://schemas.cordys.com/BIRT/">
            <ReportName>/birt.rptdesign</ReportName>
            <OutputFormat>pdf</OutputFormat>
            <Embeddable>false</Embeddable>
            <OutputToFile>true</OutputToFile>
            <EncodeFile>true</EncodeFile>
            <PARAMS>
                <PARAM>
                    <Name>SOAP_RESPONSE</Name>
                    <Value>[ this is the actual SOAP response ]</Value>
                </PARAM>
            </PARAMS>
        </GetReport>
    </SOAP:Body>
</SOAP:Envelope>

Im Template wurde eine spezielle Data Source „SOAP_RESPONSE“ definiert, die als Parameter einen SOAP Response erwartet. Weiterhin ist die reguläre Data Source „SOAP_ENDPOINT“ noch enthalten (hier wird der Webservice direkt aufgerufen). Es kann also bei Bedarf zwischen den beiden Aufrufmöglichkeiten gewechselt werden. Die darunter liegenden Data Sets sind unabhängig davon. Die Vielzahl der Data Sets liegt darin begründet, dass BIRT in der Version nicht alle XPath Funktionen zur Verfügung stellt.

BIRT WS ODA  Report Parameter
eclipse Plug-in Projekt Angepasste Report Parameter

BIRT Template Designer

Als Template Designer für den „Fachbereich“ (technisch versiert) wird die Eclipse RCP Version eingesetzt. Hier kann der Benutzer mittels Drag&Drop Felder hinzufügen und entfernen. Weiterhin kann er, bei entsprechender Kenntnis, neue Data Sets ableiten, diese enthalten wiederum neue Felder für den Report. Layout, Farben, Felder Positionen, Schriften, etc. können ebenfalls einfach verändert werden.

BIRT RCP Designer

Im Übrigen ist das resultierende Template im XML-Format und kann daher auch ohne speziellen Editor beliebig verändert werden.

XML Template

Das Resultat ist eine flexible Lösung, die sowohl http als auch https unterstützt (konfigurierbar über Properties) und die einen an die BIRT Runtime gesendeten SOAP Response (Webservice Aufruf) erkennt, umwandelt und das Ergebnis der Template Schnittelle zur Aufbereitung für den Druck übergibt.

Haben Sie eine vergleichbare Aufgabenstellung? Interessiert Sie die genaue Lösung? Eine E-Mail an info@logicline.de genügt.