Warum BiPRO und ich keine Freunde mehr werden

Seit nun fast schon sieben Jahren programmiere ich Anbindungen von Webservices für Internet Makler, die der BiPRO Norm unterliegen. BiPRO ist die Abkürzung für „Brancheninitiative Prozessoptimierung“. Dahinter steckt ein Verein, in dem sich Versicherungen, Dienstleister und Vertriebspartner zusammengetan haben, um immer wiederkehrende Prozesse zwischen allen Beiteiligten zu optimieren. Zu diesem Zweck wurde die BiPRO Norm entwickelt. Mit dieser Norm soll, neben vielen anderen nützlichen Diensten, auch die Tarifierung, Angebotserstellung und der Antragsversand auf elektronischem Wege vereinfacht werden. Im Klartext: Standards beim Versand von Daten.
Woran diese gut gemeinte Idee in der Realität eines PHP Entwicklers scheitert, möchte ich in den folgenden Zeilen erklären.

Was ist eigentlich eine Norm?

Ich habe mal in den Duden geschaut, um mir die genaue Definition einer Norm zu Gemüte zu führen. Im Duden steht folgendes:

(in Wirtschaft, Industrie, Technik, Wissenschaft) Vorschrift, Regel, Richtlinien o. Ä. für die Herstellung von Produkten, die Durchführung von Verfahren, die Anwendung von Fachtermini o. Ä.

Ist die BiPRO Norm also eine Vorschrift? Also in meinen Augen ist sie weit davon entfernt. Ist die BiPRO Norm eine Regel? Nein, definitiv nicht. Die BiPRO Norm ist in meinen Augen einfach nur eine Richtlinie, an die man sich zu halten hat. Genau hier beginnt die eigentliche Katastrophe für mich als PHP Entwickler. Denn anders als normale Webservices, die dem Endnutzer klare Vorschriften machen, wie man sie zu benutzen hat, sieht die endgültige Fassung der BiPRO Norm von Versicherer zu Versicherer unterschiedlich aus. Diese sich immer wieder unterscheidende Umsetzung der BiPRO Norm verwässert die Norm als solches und sorgt für einen teilweise unkalkulierbaren Arbeitsaufwand.

Was sind die Schwierigkeiten?

Grundsätzlich scheint es schon an der Basis wesentliche Schwierigkeiten zu geben. Ich nahm an einer Schulung teil, die von einem Mitglied des BiPRO e.V. durchgeführt wurde, um weitere Webservices einer anderen großen Versicherung für einen Makler zu realisieren. An sich waren die Abläufe von zuvor für PHP umgesetzte Webservices bekannt. Detaillierte Fragen, wie sich gewisse Abläufe für PHP verhalten würden, konnte man mir aber nicht beantworten. Letztendlich würde man sich auf JAVA beschränken. Mit PHP hätte man überhaupt keine Erfahrung. Schon war diese Schulung für mich als PHP Entwickler irgendwie wertlos. Wie kann soetwas sein? Die serverseitige Programmiersprache PHP wird auf über 81% aller Websites verwendet. Die Antwort: Für die Realisierung der Anbindung sind die Anwender selbst zuständig. Im Klartext heißt dies, dass man einfach zusehen soll, wie man damit klar kommt.

Der BiPRO e.V. an sich macht auch ein ziemlich großes Geheimnis daraus, was er eigentlich im Detail macht. Versucht man als nicht Mitglied an detaillierte Daten zu kommen, findet man im Netz höchstens PDF Dateien, die die Norm oberflächlich beschreiben, aber keinerlei technische Details enthalten, die für eine Umsetzung mit PHP wichtig wären. Wichtige Daten wie zum Beispiel XSD Dateien, die die verschiedenen in der BiPRO Norm angewandten Datentypen und -konstrukte beschreiben, findet man im Netz gar nicht. Lediglich ein altes Tutorial in Markus Heussen ’s Weblog, welches zahlreiche Links beinhaltet, die ins Nichts führen, ist noch vorhanden. Um Zugriff auf die Standard Norm zu bekommen, ist eine kostenlose Registrierung auf bipro.net erforderlich. Selbst dieser Anmeldeprozess ist unnötig kompliziert.
Natürlich könnte man sich Funktionen und Datentypen auch über die Webservices selbst von PHP anzeigen lassen. Leider gehen hieraus Abhängigkeiten und Vererbungen nicht hervor, die für eine Realisierung wichtig wären.

Sobald ich Zugriff auf die aktuelle Norm habe, kann ich auf Basis dieser Informationen schon mal PHP Objekte mit den nötigen Eigenschaften auf Basis der BiPRO Norm entwickeln. Im Grunde genommen dachte ich auch, dass ich mit dieser Sammlung von Objekten auf der sicheren Seite wäre. Aber Pustekuchen. Nicht nur, dass die unterschiedlichen Versicherer von dieser Norm abweichen. Es werden auch verschiedene Versionen dieser Norm genutzt. Unter Umständen besitzt also ein PHP Objekt in einer älteren Version der Norm nicht die gleichen Eigenschaften, die eine neuere Version mit sich bringt. Bedeutet im Klartext, dass der Makler, der mehrere Webservices von verschiedenen Versicherern nutzen möchte, enormen Aufwand betreiben muss, um es jedem Recht machen zu können.

Hat man dann die Versionsunterschiede endlich beachtet, wird einem das Leben abermals unnötig schwer gemacht. Keine Anbindung an einen BiPRO Webservice gleicht der anderen. Eigentlich sollte man davon ausgehen, da sie ja schließlich einer Norm unterliegen. Leider ist das Gegenteil der Fall. So gut wie jeder Versicherer kocht hier sein eigenes Süppchen. Hier mal ein eigenständiges Attribut, dort mal ein anderer Datentyp und identische Parameter bei Funktionsaufrufen eines Webservices? Wäre ein Traum. Aber das Leben ist nunmal kein Ponyhof.

Was könnte man besser machen?

Zunächst könnten die Versicherer und deren technische Dienstleister dafür sorgen, dass man als PHP Entwickler nicht immer belächelt wird. Das wäre sehr nett. Ich weiß ja, dass JAVA Entwickler auf einem sehr hohen Ross reiten. Aber wir PHP Entwickler können, obwohl ihr das immer wieder in Frage stellt, ziemlich coole Sachen mit Euren Webservices machen. Darüber hinaus könnten die Unterlagen auch mal komplett sein, die einem zur Verfügung gestellt werden. Bei der letzten Umsetzung erhielt ich einen Folder, der frei von beispielhaften Requests und Responses war, keine XSD Dateien, Zugansdaten oder geschweige richtige URLs zu den Webservices enthielt.
Mir persönlich reichen ein Ablaufdiagram im UML Format, die XSD Dateien, die Adresse zu den WSDL Dateien und beispielhafte Requests und Responses schon aus. Kommt schon. So viel ist das doch gar nicht.

Wünschenswert wäre auch, wenn der Verein BiPRO e.V. seine Normen verbindlicher für die Versicherer machen könnte, so dass man eben nicht für jede Anbindung der einzelnen Versicherer von vorn anfangen kann oder Abweichungen beachten und entwickeln muss. Ein strikter Standard für alle. Ansonsten macht diese BiPRO Norm in meinen Augen überhaupt gar keinen Sinn. Sie gleicht eher einem aufgeblähten Verwaltungsapparat, der ursprünglich mal etwas Gutes im Sinn hatte, mittlerweile aber eher einem in die Jahre gekommenen Dinosaurier gleich kommt: zu groß, zu aufwendig, zu träge. So funktionieren Standards einfach nicht.

Warum eigentlich SOAP Webservices? Nicht erst seit gestern ist bekannt, dass weitaus mehr mobile Endgeräte verkauft werden, als PCs, Tablets und Laptops. Eigentlich ist man mit Hinsicht auf diese Entwicklung doch dazu angehalten die zu versendenden Daten so gering wie eben nur möglich zu halten. Also warum dann dieser Overhead an XML Daten, welcher mit jedem SOAP Request und jeder Response einher geht? Teilweise dauern Antworten mehr als zwei Sekunden. Bei einem Makler, der zur Tarifierung mehrere Webservices verschiedener Versicherer heran zieht, summiert sich diese Zeit. Wäre ein REST Request auf JSON Basis hier nicht sehr viel eleganter gewesen? Alle gängigen Webservices großer Unternehmen bieten diese Möglichkeit. Lediglich die Versicherungsbranche versteift sich auf dieses in meinen Augen nicht gerade praktikable BiPRO Format.

Am Ende stehe ich nun da, bin resigniert und dezent genervt, wenn mal wieder ein Makler die BiPRO Norm für den heiligen Gral hält und diese unbedingt in sein Framework integrieren möchte. Diese Norm bedeutet in erster Linie einen nicht zu knappen Arbeitsaufwand und entsprechende Kosten. Eine eigentliche Kostenersparnis relativiert sich dadurch erstmal. Dabei könnte alles so schön einfach sein, wenn diese Norm einfach nur ein allgemein gültiger Standard wäre.

 

14 Gedanken zu „Warum BiPRO und ich keine Freunde mehr werden“

  1. Hallo Marcel,

    hättest du vielleicht ein paar kleine Beispielskripte zur Hand, die den Einsatz des BiPRO Webservice demonstrieren? Ich schlage mich auch gerade mit dem Thema rum und konnte nur das alte Tutorial von Markus Heussen finden. Dieser Webservice ist ein riesen großer Krampf…

    Vielen Dank und viele Grüße, Matthias

    Antworten
    • Hi Matthias,

      leider ist es mit allgemeingültigen Beispielen für den Einsatz von BiPRO Webservices sehr schwierig, da die verschiedenen Dienstleister und Versicherungsunternehmen die Norm jeweils für sich auslegen und anwenden. Es gibt aber ein paar Tipps, die ich Dir hier geben kann.

      1. Registriere Dich auf bipro.net. Zwar bekommst Du hier keine direkte Hilfe, aber Du hast als normaler User Zugriff auf das jeweils aktuellste Release der BiPRO Norm. Somit hast Du zumindest schon mal die aktuellen Schemas und Prozessmodelle, aus denen hervor geht, wie die verschiedenen Methoden angewendet werden müssen. Aus den Prozessmodellen geht sehr schön hervor, wie zum Beispiel die TAA Norm funktioniert. Allerdings solltest Du Dir hier auch immer vor Augen halten, dass diese Sachen nur die Basis sind. Der spezifische Versicherer wird wahrscheinlich von dieser Norm abweichen.

      2. Mach Dich schlau über das Verhalten des PHP Soap Clients. PHP bietet hier die entsprechenden Soap Objekte mit allen Funktionen, die Du für die Realisierung benötigst. Für eine normale Umsetzung sind keine externen Libraries notwendig. Allerdings kannst Du auf Tools zurückgreifen, die Dir alle Datenmodelle aus den XSD Dateien automatisch als PHP Klassen erstellen. Bei derartigen Tools habe ich aber die Erfahrung gemacht, dass sie manchmal Abhängigkeiten nicht richtig erkennen. Ich persönlich erstelle die Datenmodelle auf Basis der XSD Dateien nach wie vor manuell.

      3. Testen … das wird Dich wahrscheinlich nah an die Verzweiflung treiben. Probiere aufgrund der gelieferten WSDL Datei oder dem gelieferten Link zur WSDL Datei einen Soap Client zu erstellen. Wahrscheinlich wirst Du hier auf wahnsinnige Probleme stoßen. Gerade die in der WSDL Datei verlinkten Schemas machen ganz große Probleme. Schemas, die z.B. bei der W3C gehostet werden, sind für den PHP Soap Client nicht erreichbar und führen zu Exceptions. Wenn die Verbindung also nicht klappen sollte, lege die WSDL Datei und sämtliche in der WSDL Datei verlinkten Schemata bei Dir lokal ab. Dafür ist es notwendig die Verlinkungen in der WSDL Datei entsprechend zu ändern. Dann sollte aber der PHP SoapClient auf alle Resourcen zugreifen können.

      4. Wenn Du die Verbindung zum BiPRO Webservice hergestellt hast, lasse Dir alle Funktionen und Typen ausgeben. Ich gehe normalerweise immer so vor, dass ich mir die benötigte Funktion heraus suche und mich daran orientiere, welche Structs und Types hier notiert sind. Immer im Hinterkopf behalten, dass die spezifischen Structs und Types der Versicherung sich wahrscheinlich von der BiPRO Norm (das Paket, was Du Dir auf bipro.net herunter geladen hast) unterscheiden. Wenn Du Funktionen aufrufst, lasse Dir immer den gesendeten XML Request ausgeben und gleiche diesen mit den Beispiel XML Requests, sofern sie im Folder des Versicherungsunternehmens vorhanden sind, ab.

      Wenn ein konkretes Problem bei der Umsetzung auftreten sollte, sage einfach bescheid. Ich versuche über die Feiertage mal ein einfaches Tutorial auf Basis der aktuellen Norm von bipro.net hier im Blog zu veröffentlichen. Ich kann ’s aber nicht versprechen …

      Antworten
  2. Hi,
    toll dass mal einer aus unserer PHP-BiPRO Consumer Ecke Klartext spricht.
    Meiner Ansicht nach sind die dort völlig festgefahren auf JAVA
    Habe ebenfalls seit mehreren Jahren mit diesem Thema zu tun und gerade erfahren dass ich einen BiPro-Konformen Provider Service zum Bestandsabgleich erstellen muss. Glaube nicht, dass dieses in PHP wirtschaftlich möglich ist. OASIS, STS, etc..
    Würde gerne mit Euch weitere Erfahrungen austauschen und hören was Ihr darüber denkt.

    Antworten
    • Hallo Olaf,

      irgendwie bin ich ja erleichtert, dass ich augenscheinlich nicht der einzige PHP Entwickler bin, der arge Probleme mit der Umsetzung von BiPRO Webservices hat. Der Bestandsabgleich ist technisch realisierbar. Das Security Token System bleibt dabei normalerweise das gleiche, wie z.B. bei der Tarifierung oder Policierung. Der wirklich kritische Punkt ist die Wirtschaftlichkeit. Erstmal kostet die Realisierung wegen der hier im Blog beschriebenen Probleme Unmengen an Zeit und darüber hinaus ist mit einer Realisierung des Bestandsabgleichs nicht garantiert, dass der gesamte Bestand auch wirklich abgeglichen werden kann. Buchstabendreher, lange Doppelnahmen, die über die Beschränkungen der Norm hinaus gehen, zeitliche Begrenzungen, etc.

      Die Erfahrungen in diesem Bereich sind wahrscheinlich ähnlich wie Deine. Der technische Support ist entweder gar nicht vorhanden oder kommt von ganz weit oben herab und hilft einem dann doch nicht weiter. Man trifft hier eben wirklich nur JAVA Entwickler, wenn man dann mal das Glück hat wirklich einen Entwickler als Kontakt zu haben. BiPRO ist alles, aber eben nicht die eierlegende Wollmilchsau, für die sie einige Makler und Versicherungsportale halten.

      Antworten
  3. Auch hier meldet sich, wenn auch etwas spät, ein genervter PHP Entwickler, der mit der BiPro Norm zu kämpfen hat.
    Am meisten stört mich nicht mal die Tatsache, dass die ganze Fraktion im Java festhängt, sondern, dass man schon fast gezwungen ist sich eines dieser Java-Monster-Frameworks ins Haus zu holen (Axis2, CXF, JBoss und wie sich nicht alle heissen …). Genau das möchte man mit PHP ja aber vermeiden, offensichtlich geht das aber wohl kaum. Eine Client-Anbindung umzusetzen scheint wohl noch zu gehen, aber den ganzen Standard per PHP zu schreiben halte ich auch für fast unmöglich.
    Derzeit wurde ich lediglich mit der Nutzung des Servers als Client konfrontiert, die eigene Umsetzung stand noch nicht an, kommt aber sicher noch.
    Derzeit komme ich fein raus, indem ich mir entsprechende SOAP-Nachrichten per XSL generieren lasse. Hier nehme ich dann auch das entsprechende Mapping vor.
    Das ganze ist dann zwar nicht mehr objektorientiert, aber für meine Zwecke derzeit noch völlig ausreichend. Aber auch das ist nicht das gelbe vom Ei, was die Wiederverwendbarkeit des Codes angeht.
    Gibt es schon neue Erfahrungen zu diesem Thema?

    Antworten
    • Ich habe inzwischen für die safe.me GmbH den BiPRO Webservice der Haftpflichtkasse Darmstadt (HKD) Versicherung umgesetzt. Zumindest Tarifierung, Angebot und Antrag. Die Probleme der BiPRO Norm bleiben die gleichen. Nur weiß man eben, wo die Probleme liegen, je öfter man es gemacht hat.

      Eine objektorientierte Umsetzung der BiPRO Norm mit PHP ist aus meiner jetzigen Sicht nicht möglich. Ich hatte im Vorfeld die aktuelle BiPRO Norm von bipro.net herunter geladen und auf Basis dessen entsprechende Klassen mit den in der Norm genannten Eigenschaften entwickelt. Genau hier setzt aber das Problem dieser Norm an. Im Grunde genommen konnte ich diese Klassen für die HKD Umsetzung nicht verwenden, da das einfache Vorhandensein von Eigenschaften, die in der BiPRO Norm genannt, aber in der HKD Umsetzung offensichtlich nicht vorhanden sind, führte zu SoapFaults und dem Abbruch des Vorgangs. Also wurden eigens für die HKD Klassen programmiert, die die HKD Eigenschaften enthielten. Die Wiederverwendbarkeit ist also nach wie vor ein riesiges Problem.

      Wenn ihr möchtet und die HKD sich damit auch einverstanden erklärt, kann ich gern mal ein How To hier im Blog veröffentlichen. Ich frag mal bei der HKD nach. Die Versicherer machen aus ihren Webservices ja manchmal auch ein riesiges Geheimnis. Weiß der Teufel warum.

      Antworten
      • Ich frage mich nach wie vor, wie viel Sinn eine objektorientierte Umsetzung der BiPro Normen macht, gerade im Zusammenhang mit einem Vergleichsprozess. Einen Webservice zu implementieren, der für eine Gesellschaft funktioniert mag die eine Sache sein, aber wie sieht es aus, wenn man für Vergleichsrechner die ganzen Anfragen zusammenbasteln muss? Die Wiederverwendbarkeit einzelner Codefragmente sollte ja nahezu bei null liegen, sodass jeder Webservice einzeln betrachtet werden muss, was der Fehleranfälligkeit natürlich überhaupt nicht zugute kommt.

        Ich bin grundsätzlich für eine Normierung, aber dieses ganze BiPro Ungeheuer hat meiner Meinung nach den Vogel abgeschossen, schon alleine aus dem Grund, dass es im XML Format vorgesehen ist und gerade über mobile Geräte absolut ungeeignet ist. Payload und Overhead stehen in keinem Verhältnis wie ich finde.

        Ist Ihnen auch aufgefallen, dass man grundsätzlich ohne Musterrequests keine vernünftigen Anfragen generieren kann? SOAPUI zum Beispiel generiert Requests aus der WSDLs, die mehrere hundert Zeilen lang sind. Die Gesellschaften brauchen aber nur einen winzigen Bruchteil davon und können überflüssige Zeilen oft gar nicht verarbeiten. Alles nur, weil die Norm versucht alles zu vereinen.
        Man kommt nur mit mühsamen Trial & Error über mehrere Tage oder in wenigen Stunden mit ein paar guten Request-Beispielen effizient voran.

        Erinnert mich irgendwie alles stark an das gute alte GDV Format, bei dem man Zeilen und Spalten zählen durfte, um die richtige Position der Daten zu rauszufinden. Wenn man Glück hatte … *hust*

      • Moin Ik,

        eine objektorientierte Umsetzung macht in meinen Augen nach wie vor Sinn. Die BiPRO Norm gibt quasi die Grundbausteine vor. Datenmodelle, von denen sich die Modelle der Versicherer ableiten. Man könnte die BiPRO Norm als Grundstock sehen. Zugegeben ist auch das sehr wage und bei manch einem Versicherer lassen sich von diesem Grundstock auch keine Ableitungen mehr bilden. In der Regel macht es aus meiner Erfahrung heraus aber Sinn die BiPRO Norm als Model in der Hinterhand zu haben. Es gibt also eine gewisse Wiederverwendbarkeit. Auch wenn ich quasi für fast jeden Versicherer diesen Grundstock erweitern muss.

        Trial and Error. Ja, das ist auch meine Erfahrung. Man kommt lediglich mit diesem Prinzip voran. In diesem Zusammenhang fällt mir ein Meeting mit einem meiner Kunden ein, bei dem auch ein Mitglied des BiPRO e.V. anwesend war. Nachdem wir ein wenig über die überwiegenden Nachteile der BiPRO Norm und deren Umsetzung der einzelnen Versicherer gesprochen haben, sagte man einfach nur, dass die Umsetzung der einzelnen Versicherer oftmals nur für einen spezifischen Endkunden optimiert wurde. Das erklärt in meinen Augen auch die jetzigen Schwierigkeiten, die wir als Entwickler mit diesen Webservices haben.

        Beispielhafte Requests und Responses sollten dazugehören. Aber Du kennst es wahrscheinlich selbst. Es gibt auch hier keine einheitliche Vorgehensweise. Manchmal bekommt man eben nur ein Ablaufdiagram (UML) inkl. falscher WSDLS oder XSDs und manchmal eben doch das komplette „Wunschlos glücklich“ Paket. Es nutzt nichts sich weiter über die Unzulänglichkeiten der BiPRO Umsetzungen der einzelnen Versicherer auszulassen. Vielleicht wäre es sinnvoll, wenn man sich mal mit ein paar PHP Entwicklern zusammen setzt und eine Art PHP Framework entwickelt, welches es erlaubt BiPRO Webservices relativ einfach umzusetzen.

  4. Hallo,
    gehört zwar nicht ganz hier her, aber ich brauche dringend Hilfe.
    Ich soll per per php soap einen client erstellen.
    Der Service Provider lässt aber nur application/soap+msbin1 zu.
    Gibt es dafür eine Lösung mit php Soap?
    Ich komme da nicht weiter.
    Schnipp:

    Dieses führt in allen getesteten Varianten zu folgender Fehlermeldung.:
    Schnapp:
    SOAP 1: Cannot process the message because the content type ‚text/xml; charset=utf-8‘ was not the expected type ‚application/soap+msbin1‘.
    SOAP 2: Cannot process the message because the content type ‚application/soap+xml; charset=utf-8; action=“https://AnbieterX/Service.svc/soap#LogOn“‚ was not the expected type ‚application/soap+msbin1‘.

    Antworten
  5. Hallo,

    ich bin mir sicher, dass sowohl PHP- als auch JAVA-Entwickler die gleichen Problemen haben….

    Beide bekommen nämlich die gleiche WSDL und müssten Clients dafür programmieren….
    Das Problem liegt an einer Norm, der von niemanden sauber eingehalten wird…

    Antworten
  6. Toll <3 – Da hatte schon 2014 jemand die Probleme mit denen wir hier bei mittlerweile über 50 Versicherungen rumkrebsen. Ein Standart 45 Interpretationen bisher. Die Dopplungen nur von Versicherungen, die die gleiche IT Abteilung haben.

    Viel Glück und nerven allen noch :D.

    Antworten

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.