1. Das Problem Datenstruktur

Beruflich habe ich ein Formularbasierte Applikation mit Sharepoint und Infopath als Frontend realisiert. Schön brav habe ich im Infopath die Variablen sprechend bezeichnet, Feldgruppen strukturiert, alle Regeln im Infopath sprechend bezeichnet, Quickinfos gepflegt, alles getan, um im Editor nachvollziehbar und wartbar zu modellieren.

Diese Lösung stößt, den Restriktionen des sharepoint geschuldet (!!!), an Grenzen z.B. bezüglich Datenumfang max 10K Einträge Listobergrenze, unterirdische Performance, Schnittstellen etc. Also muss mittelfristig eine professionellere Lösung her, die dann aber nicht mehr sharepoint als Backend sein kann. Damit sich der Aufwand für die Entwickler in Grenzen hält, wurde auch eine .net middleware zwischen Infopath und neuem Backend verworfen. Infolgedessen heisst das Neuentwicklung auch auf Formularseite. Ich hatte ja alles IM Infopath schön dokumentiert, dachte ich. Als ich daher das Infopath-Formular zu dokumentieren versuchte, stieß ich auf einige für mich sehr unerfreuliche Sachverhalte.

Es war mir nicht möglich, auf einfache Art Felder und deren Eigenschaften mit Infopath-Bordmitteln zu beschreiben, zu exportieren und weiterzuverarbeiten.

Weder Struktur noch Tabellen mit ihren Feldern und deren Felddefinitionen sind auf vernünftige Weise so exportierbar, dass das Ergebnis ordentlich und leicht weiterzuverarbeiten wäre.

Natürlich war Dr. Google der erste Anlaufpunkt. Dann habe ich intern herumgefragt, Man erntet in der Regel ??? für die Frage nach Dokumentation in der IT. (Typische Aussage: Ich bin zun Programmieren hier, nicht zum dokumentieren. Oder: Wozu musst du Dokumentieren?) Also nichts herausgefunden.

2. Lösungsversuche zum Export der Datenstruktur aus Infopath

Was ich alles mit "Microsoft Bordmitteln" versucht habe:

2.1 Versuch mit XML-Export der Struktur

Export des Formulars und Entpacken der XML

Über Veröffentlichen->Quelldateien exportieren -> Pfadangabe..  wird das das Formular mit xsn-Endung automatisch entpackt, es ist eine CAB-Datei. Das Ergebnis ist eine Anzahl von Dateien im XML, XSD-Format und die Bilder. Diese Dateien enthalten die Datenstrukturen im Microsoft-Rohformat und sind somit erst mal direkt unbrauchbar.

Nächster Schritt: Import der Datenstruktur in ACCESS

Es werden designbedingt nur Teile der Tabellen importiert, der Ausreden und Ausflüchte die Microsoft anführt, sind da viele warum es nicht geht. Die wollten einfach nicht!

Ich erhalte also nun eine Datenbank mit Teilstrukturen des Formulars. Es fehlen auch die im Formular vorhandenen Beziehungen, wie auch eine gemeinsame ID. Beziehungen sind jedoch in der Infopath-Entwurfsansicht (Felder) deutlich erkennbar vorhanden.

Sieht man sich die Tabellen in ACCESS dann an, gibt es wieder keine einfache Möglichkeit, die Strukur zu Dokumentationszwecken zu exportieren.

Doch halt, da gibt es doch unter --> Datenbanktools den --> Datenbankdokumentierer. Also flux alles markiert und exportiert. Das erzeugte Word ist zwar als Beweismittel zu gebrauchen, aber zu sonst nichts weiter, die Daten sind schlicht für die Ablage und nicht weiterzuverarbeiten. Nächster Versuch: Excel-Export statt Word. Nun wird es spannend: Das Excel hat eine Gliederung, die in ihrer Struktur teiltransponiert ist. Der Tabellenname steht in Zeilen über den Feldern Das Feld ist zeilenweise abgebildet mit Feldnamen und Feldtyp und Feldlänge. Die weiteren Feldattribute (Property, Value) sind in unbenannten Zeilen unter dem Feld selbst angeordnet. Eigenartigerweise ist die Zugehörigkeit zu einer Tabelle als Property abgebildet, und damit um 90° abgeknickt (transponiert) für mich nicht vernünfitg aufwandsarm auswertbar. Was aber fehlt, sind die Quickinfos etc.

Das ist wieder nicht brauchbar und ein nicht unwesentlicher Teil fehlt. Die Weiterverarbeitung ist aufwendig.

Versuch: Infopath direkt nach Excel exportieren

Dazu muss man nun das Formular erst mal in Vorschaumodus öffnen, um es anschließend exportieren zu können. Der Export führt zu einer flachen Tabelle (Struktur geht also verloren), es wird in der 1 Zeile der Feldname mit Präfix  "ns1:" ausgegeben, in der Zeile darunter der Dateninhalt, keine weiteren Informationen. Die von Microsoft empfohlene Lösung heisst, Einzelne Sichten definieren und diese dann zu exportieren. Als ob ich sonst nichts besseres zu tun hätte! Das ist wieder nicht brauchbar und weiterzuverarbeiten und ein nicht wesentlicher Teil fehlt.

2.2 Export einzelner Tabellen aus Access mittels Exel.

Die in Access bestehenden Tabellen kann man direkt nach Excel exportieren.

Vorteil: Ich erhalte eine Liste der Feldnamen.

Nachteil: Die Attributierung (Felddefinition) fehlt. Es sind nicht alle Tabellen enthalten, da schon der Import unvollständig war.

3. Das Problem Regeln

Infopath hat einen relativ mächtigen Regeleditor. Man kommt aber nicht an eine Dokumentationsfunktion oder Exportfunktion heran.

Also ein Umweg: Aufruf des Regelinspektors --> Drucken --> PDF-Drucken --> PDF in Word wandeln (Adobe Acrobat Prof.)  Besonders dämlich ist, dass hier die internen IDs der Schaltflächen angegeben wird, keine Labels oder Bezeichnungen. Das bedeutet manuelle Nacharbeit. Beim Label für Regeln möglichst sprechend schreiben, sonst wird es hinterher noch aufwendiger.

4. Bewertung

Beschaue ich mir mal die Konkurrenz (APEX, JASPER,....) so kommt Infopath funktional und von der direkten Ergonomie erst mal sehr gut weg. Für eine Modellierung ist Infopath jedoch trotzdem ein sehr zweischneidiges Schwert, schnell gestrickt, benutzerfreundlich aber praktisch undokumentiert und maschinell nicht mit einfachen Mitteln dokumentierbar. Wenn ich bereits bei der Modellierung parallel mitdokumentiere, geht das am Besten und kostet auch am meisten Zeit. Das macht eh keiner.

Die mangelhafte Interoperabilität der Microsoft-Produkte schränkt deren Nutzung ein. Die Synergie der Microsoftprodukte wird von den gewollten Inkompatibilitäten der einzelnen Komponenten (Bezahlschranken!) mehr als aufgefressen.

Was für mich erwartbar ist, ist hier konkret ein vernünftiger Export der Datenstrukturen ohne besondere zusätzliche Mittel und Wege. Das wird jedoch nicht angeboten.

Besonders ärgerlich finde ich auch die künstliche Beschneidung der Funktionen von Infopath. Es ist nicht möglich, Access und sharepoint und Excel in einem Formular zu verbinden. hier ist dann plötzlich zur "Kopplung" Visual Studio erforderlich. Damit auch eine Code-Signierung mit zusätzlichen Kosten und durch die "Sicherheit" bedingte Updates z.B. wegen Schlüsselverfall alle zwei Jahre etc.. So was geht gar nicht! Insbesondere, da man für jede Applikation auch so unabhängig Infopath-Formulare machen kann.

Die Abhängigkeit von .net und sharepoint ist ein riesengroßer Nachteil und von MS$ so gewollt.

Nun ist Infopath von Microsoft auch noch mit 2013 als letzte Version abgekündigt worden. (Quelle: http://www.golem.de/news/microsoft-office-2013-infopath-wird-eingestellt-1402-104352.html) Die angekündigte Nachfolgeversion "Office Forms" stinkt nach Cloud. und Cloud spricht man auf gutdeutsch "Klaut" aus.

Für mich heißt das, der Formulargenerator Infopath von Microsoft ist quick&dirty, für die Entscheider im Management auf den ersten Blick verführerisch, zum nachhaltigen Nutzen auf Arbeitsebene aber eine Gefahr für jede Firma, weil schlicht eine Kostenfalle.

Konsequenz: Wir brauchen wie LibreOffice als Office-Alternative einen OpenSource-Formulargenerator (Jasper hat z.B. naturgemäß einen anderen Fokus), den man überall einfach anklinken kann, sowohl online wie offline.

Also mal nachgesehen bei Formulargeneratoren, es erschlägt einen schier. Es gibt aber nichts brauchbares außer Cloud-Lösungen mit eingeschränktem Funktionsumfang. Gerne auch diverse Kaufversionen, da kauft man oft die Katze im Sack. Auch der Trick, das APEX kostenfrei ist, zieht bei mir nicht, alldieweil ich mit Oracle, den amerikanischen Datendieben, nichts zu schaffen haben möchte.

 

 

 

   
© Alle Rechte bleiben beim Autor!