Totgeburt, die Dritte.

Es ist ein Trauerspiel. Nach einer Crystal Reports-Integration und dem Versuch, BIRT als Reporting-Backend für ERP LN zu nutzen, probiert es jetzt Infor (konzernstragtegisch aufoktroyiert?) mit den Microsoft-Reporting-Services. Und leider, leider, auch wenn's wieder ein bisschen mehr integriert ist als die Vorversionen, das Ergebnis wird das gleiche sein: Ein paar große Kunden werden's vielleicht nehmen, und ein paar schlecht beratene kleine ohne Erfahrung auch. Der Rest der Baan-Welt wird weiter Courier-12pt-Reports drucken oder sich eine Spooling Software anschaffen. Sequest, Hidox und wie sie alle heißen, wird's freuen, dass ihnen Infor auch diesmal nicht das Geschäftsmodell unter dem Hintern wegzieht.

Ok, wie komm ich zu der Einschätzung? Ich habe mir eben mal die Administrationshandbücher und Developmenthandbücher angesehen. Gehen wir mal davon aus, dass das Version 1.0 ist, und dass sich in den nächsten Jahren noch ein bisschen was tun könnte (obwohl: Weder bei der Crystal-Integration noch beim BIRT hat sich nach dem ersten Release irgendwas grundsätzliches getan). Aber die Basisarchitektur wird die selbe bleiben, und die ist einfach krumm.

Die sieht so aus, dass man aus den Baan-4gl-Reportdesigns einen Report in den Microsoft-Reporting-Services ableitet. Der Datenstrom, der aus dem Baan-Report (oder der Baan-Session? - so klar sagt das die Dokumentation nicht) kommt, wird an die Microsoft-Report-Engine geschickt. Dort dient dieser XML-Strom als Datenquelle (soweit ich das seh, gibt's sogar mehr Stöme, einen für die Daten, einen für die Labels, einen für Report-Metadaten). Die Report-Engine, die ein separater Serverprozess (auf einem MS-Server-Betriebssystem) ist, formatiert diese Daten dann  anständig und bringt sie zu Papier (oder zu pdf). Sie kann - das konnten die vormaligen Versuche nicht - dabei sogar auf die laufende Bshell zurückgreifen, und bspw. Baan-DLLs aufrufen.

Allerdings muss man, um diese Baan-DLLs aufzurufen, das ganze recht komplex im (Microsoft-)Reportskript programmieren. Und das tut man dort nicht mit den Baan-Tools, sondern mit Visual Basic. Das kann man zwar lernen, aber man muss es halt zusätzlich zu Baan C lernen - außer das Anwenderunternehmen ist so groß, dass es sich einen hauptamtlichen Reportschönmacher leistet, aber welches ist das schon?

Das eigentliche strukturelle Problem ist aber das: Im Developer Guide heißt es: "You can use the ERP LN Reporting plug-in to redesign ERP LN session reports". Genau das ist es: Ich habe einen Report in den ERP LN Tools definiert, mit Layouts, allem Schnick und Schnack, und dann muss ich den ganzen Kram (von Null!) im BIDS (Microsoft Business Intelligence Development Studio) nochmal machen! Was die Dokumentation leider nicht verrät: Was passiert, wenn sich der zu grunde liegende Baan Report (minimal, oder in größerem Ausmaß) ändert? Fang ich dann im BIDS wieder komplett von vorne an? Das war bei der Crystal- und bei der BIRT-Integration der wichtigste Grund, aus dem ich jedem Kunden von diesen Technologien hochgradig abgeraten habe.

Die ganze Architektur ist wieder ein Doppelmoppel, das die Anwender zwingt, in zwei komplett getrennten Umgebungen zu hantieren, zwei getrennte Welten zu sehen, zwei Technologiestacks zu haben, zwei Terminologien verstehen zu müssen. Diesen beiden Softwarepaketen, ERP LN und Microsoft Reporting Services, hat man mühsam eine Schnittstelle abgerungen. Aber man hat wieder keine echte Integration zustande bringen können. Nicht weil man unfähig wäre, sondern weil es zwei Welten sind. ERP LN lebt "Push-Reporting": Die Session arbeitet Daten auf, der Report zeigt diese an, aber kann mit Zusätzlichem Code zusätzliche Daten zu den von der Session gelieferten Datensätzen holen. Standard-Reporting-Pakete leben "Pull-Reporting": Es kommt ein linearer Datenstrom an, und die Daten in diesem Datenstrom werden aufbereitet, aber was nicht im Datenstrom ist, kann auch nicht dazugelesen werden.

Jetzt kommt vielleicht eine Überraschung für Infor: Reports werden von den Kunden angepasst. Und zwar alle regelmäßig gedruckten. Bestellungen, Lieferscheine, Rechnungen, Stücklisten, Produktionsauftragspapiere. Und weil das, was im Standard-Datenstrom von der Session geliefert wird, meistens nicht ausreicht, um den armen Kerlen in der Halle, die die Papiere nutzen sollen, alle Informationen zu geben die sie für ihren Job brauchen, werden zusätzliche Daten in den Reportskripten dazugelesen. Und das muss einfach und aufwandsarm passieren können.

Nun muss man, um mal ein Beispiel aus dem Developerguide zu zitieren, in Visual Basic folgendes programmieren

Dim methodArgs as new System.Collections.ArrayList()

methodArgs.add(New Object() {"in", "long", year} )

ret = Infor.ReportingServices.Utilities.LNUtils.DoErpLnDllCall (Report.Parameters!ConnectionString.Value, "otccomdll0350", "tccom.dll0350.is.leap.year", "boolean", retval, methodArgs)

if retval then ...

um folgende Zeile in einem ERP-LN-Reportskript in einem Microsoft-Report nachzubilden:

if tccom.dll0350.is.leap.year (year) then ...

Entschuldigung, aber das ist nicht aufwandsarm. Und es ist ist dem typischen ERP-Programmierer bei einem mittelständischen Maschinenbauer auch nicht zu erklären.

Und deshalb kann man Kunden nur abraten, auf die Reporting-Services zu vertrauen, wenn es darum geht, Reports "hübsch" zu machen. Wie gesagt, ich halte sie für eine weitere Totgeburt. Sie steht technologisch auf den selben tönernen Füßen wie die vormaligen Versuche.

Stattdessen sollten die Kunden, und die Anwendergruppen insbesondere, und vielleicht auch die Infor-PSO-Organisation, die die Versprechungen wird ausbaden müssen, die die Verkäufer jetzt aufgrund dieser wenig hilfreichen Schnittstelle machen werden, weiter bei den zuständigen Produktmanagern darauf drängen, eine eine echte, integrierte Lösung zu entwicklen, die innerhalb der Baan-Tools einen grafischen Reporteditor zur Verfügung stellt.

Vor allem aber sollte Infor ein echtes Interesse an einer integrierten statt einer "simulierten" Lösung haben: Dass das einfache(!!!) Generieren von ordentlichen Ausdrucken ein Problem ist, hat Garnter jetzt schon - zu recht - zum zweiten Mal in Folge in seiner Magic-Quadrant-Studie moniert. Der Markt wird das Fehlen dieser grundlegenden Features nicht mehr lange ungestraft hinnehmen, und Pseudo-Lösungen verfangen im Markt eben nicht. Sie werden vielleicht noch gekauft, aber nicht eingesetzt.