Planung einer etwas umfangreicheren Workflowlösung

[ernstla]

Hallo,

wie ihr links sehen könnt, ist das mein erster Beitrag hier. Nur ganz kurz zu meiner Person: Ich entwickle seit gut zwei Jahren hauptberuflich Notes-Datenbanken für unsere (nicht IT) Firma. Ich komme aus der Microsoft-Ecke (meist VB, etwas .NET). Dies ist mein aller erster Beitrag zum Thema Notes überhaupt. Ich bin also ein "Notes-Lurker". So eine Foren-Suchfunktion ist halt ne prima Sache. Ich hoffe ihr seht es mir nach. Ich versuche mich zu bessern.

Nun zum eigentlichen Thema (es wird wahrscheinlich etwas länger):

Wir starteten vor ca. einem Jahr das Thema Notes basierendes Workflow-Management und sind eigentlich immernoch in der Pilotphase. Bis jetzt wurde nur ein Prozess in Notes abgebildet. Wir verwenden eine eingekaufte Lösung für die Steuerung (Benachrichtigung, Berechtigungssteuerung, Vetretung, Eskalation etc.).

Das Pilotprojekt begleitet ca. 20 Arbeitsschritte und bildet wie gesagt nur einen Geschäftsprozess ab. Die Anwendungsdatenbank ist relativ komplex (60 Ansichten, 40 Masken, 30 Skript-Libs, ...). In Zukunft soll der Großteil der Prozesse abgebildet werden. Ich denke ihr wisst bereits auf was ich hinaus will.

Ist-Situation:
Die aktuelle Datenbank ist bereits die zweite, komplett überarbeitete Version. Jeder Arbeitsschritt ist in einem eigenen Dokument abgebildet, weil Schritte auch parallel laufen können, und über eine Antwort-Hierarchie organisiert. Es werden aktuell an die 20 weitere Geschäftsprozesse aufgenommen. Wobei verschiedene Prozesse auch andere anstoßen und auf eine Antwort warten.

Nun stellt sich die Frage, wie man so etwas dynamischer lösen kann und man dem Benutzer nicht abverlangen muss, sich im Dschungel der verschiedenen Datenbanken zurecht zu finden.

Die Idee:
Es gibt eine zentrale Steuerdatenbank, in der alle Abläufe definiert werden. Ist in einer Datenbank ein Arbeitsschritt abgeschlossen, benachrichtigt diese die Steuerungsdatenbank und diese reagiert. Das kann das Erzeugen eines neuen Dokuments in der informierenden oder einer anderen Datenbank sein. Es kann aber auch die Steuerung eines anderen Systems sein (Webservice, SQL-Server). Außerdem erstellt die Steuerungsdatenbank in einer Aufgabendatenbank ein Aufgabendokument, welches dann auf den eigentlichen Arbeitsschritt verlinkt. Dadurch soll es für den Benutzer transparenter werden. Wir haben dann also:

- eine Steuerungsdatenbank, in der Arbeitsschritte definiert werden und diese steuert.
- eine Aufgabendatenbank, die sozusagen als Portal dient.
- n Anwendungsdatenbanken, die evtl miteinander und anderen Systemen interagieren müssen.

Große Prozesse bekommen eine eigene Datenbank. Kleinere werden evtl. themenbezogen zusammengefasst.

Für Benachrichtigungen zwischen den Datenbanken dachte ich an Sachen wie Webservices (würde wohl Version 7 bedeuten), das Erstellen von Notes-Dokumenten und anschließendem abarbeiten durch einen Agenten oder Mails.

Und falls ihr euch das fragt: Ja, ich bin mir der Komplexität einer Eigenentwicklung durchaus bewusst. Wir haben verschiedene kommerzielle Lösungen betrachtet und uns für eine unterstützende entschieden. Flexibilität ist gewünscht.

So, könnt ihr euch vorstellen, dass das ein gangbarer Weg wäre? Seht ihr Verbesserungspotential? Würdet ihr es ganz anders machen?

Ich bin für jeden Tipp dankbar. Entschuldigt bitte die Länge.

[smoki]

Zu erst... eine eigene Workflow-Engine bauen ist nicht ganz trival. Insbesondere wenn man dann auch noch Leser und Autorenfelder usw. mit setzen will, automatische Mailbenachrichtigung und automatisierte Stati-Wechsel z. B. zur Eskaltion.

In der Regel ist einen Workflow richtig zusammen zu bekommen meist schwerer als man denkt

Eine Konfigurationsdatenbank für "fast" alle Parameter zu verwenden, die verschiedene Workflows verwenden ist aus meiner Sicht auch die Saubere Lösung. Zumal bei Datenbanken die die User ggf. mit viel Datenzumüllen, die Zugriffe dort langsamer werden und bei der Konfigurationsdatenbank seperat ist, die Zugriff weiterhin schnell sind.

Zu bedenken gilt bei der Eigenentwicklung!!... Du findest sicherliche einige Notes-Bugs die du hierbei umschiffen musst.

Wenn du gut Programmieren kannst und VB erfahrung ist ja schon mal ein Anfang... Ist es durchaus möglich das in einem halben Jahr so eine Engine zu Programmieren, natürlich nur wenn dich keiner stört hierbei, was man bei mir dauernt tut, so dass ich selbst sagen würde... Ich schaffe es nicht in einem halben Jahr (man ist ja auch nebenbei noch der Admin....) Und es kommt halt auch wirklich darauf an, was alles die Engine machen können soll. Und so wie ich das lese, ist es nicht trivial...

Ich wünsch dir viel erfolg, egal wie du dich entscheidest

Schönes Wochenende!

[ernstla]

Hallo smoki,

sorry, ich habe mich oben wahrscheinlich etwas undeutlich ausgedrückt. Wir verwenden ein kommerzielles Produkt, das uns bei die grundsätzlichen Workflowsachen, also wie du schon schreibst: Berechtigungen, Benachrichtigung, Eskalation etc., unterstützt.

Diese Engine wird hauptsächlich durch neue Dokumente in bestimmten Ansichten initial angetriggert. Um das Erstellen der Dokumente, oder auch Feldänderungen zur Steuerung müssen wir uns kümmern.

Wir versuchen nun eine (nahezu) einheitliche Lösung für alle Prozesse zu finden, und dachten da eben an eine zentrale Steuerdatenbank.

Die alte Datenbank ist genau auf den einen Fall zugeschnitten und verwendet sehr viel sehr speziellen Code. Darum bemühen wir uns um eine allgemeine Lösung.

Zu den zu umschiffenden Notes-Bugs: Nicht falsch verstehen, ich finde Notes grundsätzlich klasse, aber ich musste schon einige Male kämpfen. Am schlimmsten finde ich den Designer. Wie oft musste ich schon feststellen, dass ein Neustarten von Notes ein resultatloses Debugging verkürzt hätte. Da Lobe ich mir, auch wenn's manch einer nicht gerne lesen mag, die IDEs von MS oder Eclipse.

P.S. Glücklicherweise durfte ich schon vor einiger Zeit die Admin-Schiene verlassen.

[flaite]

Ich würde auch externe Beratung hinzuziehen.
Persönlich glaube ich übrigens nicht an zentrale Steuerungsdatenbanken.
Man kann auch die Workflow-Gestaltungselemente in jede Datenbank von einer speziellen Schablone reinschiessen.

Wir starteten vor ca. einem Jahr das Thema Notes basierendes Workflow-Management und sind eigentlich immernoch in der Pilotphase.

Viele Köpfe und zu wenig Arme, hmm Aber die Ideen von xTreme Programming und Agile Alliance sind natürlich völlig abwegig. 

Große Prozesse bekommen eine eigene Datenbank. Kleinere werden evtl. themenbezogen zusammengefasst.

Nix gegen Kompromisse im allgemeinen, aber das sind gefährliche Kompromisse. Wo ziehst du (und andere) die Grenze.

Für Benachrichtigungen zwischen den Datenbanken dachte ich an Sachen wie Webservices (würde wohl Version 7 bedeuten), das Erstellen von Notes-Dokumenten und anschließendem abarbeiten durch einen Agenten oder Mails.

carefull.  Das hört sich zwar schick an. Frag dich aber wirklich, wofür du Webservices eigentlich brauchst. Solange die durch Webservices aufgebaute Infrastruktur in Notes bleibt, brauchst du sie imho nicht. Webservices sind gut, um mit anderen Systemen plattformübergreifend zu kommunizieren. Als Kern einer Webservice Infrastruktur hat Notes aber aus meiner Sicht den eindeutigen Nachteil, dass ihm Transaktionsfeatures fehlen (im Sinne von commit/rollback und eigentlich sogar 2pc-> 2 phase commit).
Wenn du in Notes bleibst. Prima. Dann brauchst du aber keine Webservices. Notes hat selbst ein optimiertes Protokoll, um unter verschiedenen Datenbanken auf unterschiedlichen Servern Daten auszutauschen. Webservices würden da nur einen zusätzlichen Layer einfügen. Das kompliziert Dinge wie ExceptionHandling, Debugging, Security, Austausch komplexerer Datentypen, Deployment, Monitoring, etc.. Wo ist der Vorteil von Webservices in einer Notes-Notes Kommunikation?
Ausserdem sind Webservices in Notes noch nicht 100% stabil. Ich bin ziemlich davon überzeugt, dass ich einen eindeutigen Bug bei der Übertragung von DateTime Werten gefunden. Auf notes.net gepostet und bisher keine Antwort erhalten. Der Fall ist ziemlich eindeutig.
Ausserdem gibt es öffentliche Verlautbarungen von Lotus, dass man das Haupt-Encoding Schema von soap/enc auf doc/lit ändern will und das ist eine großer Wandel. Die doc/lit Sachen, die IBM raushaut, halte ich noch nicht für 100% koscher. Mir ist als doc/lit Beispiel nur eine Integration mit vb.net bekannt. Nix Java zum Beispiel.
[out_of_topic]
Auch ich neige manchmal dazu, coole Technologien in geschäftsrelevanten Bereichen zu benutzen, ohne sie zu verstehen. Aber ich muß dann auch am WE nachsitzen. Morgen zum Beispiel. For the record: Spring-Http-Remoting nach Lehrbuch ist nur für Situationen gedacht, in denen auf Client und Serverseite Spring integriert wird.
Das sollte man sich abgewöhnen.
[/out_of_topic]

Keep it simple. Lotus Notes kann seit Jahren erfolgreich für Workflows eingesetzt werden. Man kann auch Notes Workflow Logik prima über Konfigurationsdokumente parametrisieren. Nur gibt es da eben Leute, die damit schon Erfahrung haben. Und davon kann man profitieren.
Es gibt bestimmt auch Workflow-Szenarien, in denen andere Systeme überlegen sind (Transaktionalität). Jedoch braucht man da auch massiv know how.
Ein organisations-globale Notes-Workflow-Infrastruktur aufzubauen, macht sicher Sinn. Nur überleg dir gut, was du wirklich brauchst und belaste dich nicht mit Zeugs, dass du nicht brauchst. Das man Webservices hier nicht braucht, heisst nicht, dass sie grundsätzlich keinen Sinn machen. Nur, dass sie vermutlich in deinem Kontext sich als eine zusätzliche Belastung herausstellen könnten.

Gruß Axel

[ernstla]

Hallo Axel,

vielen Dank für deine Stellungnahme.

Wir lassen uns bereits beraten und es stehen auch noch Termine aus. Allerdings waren die ersten Beratungen nicht so ergiebig. Aber die Hoffnung stirbt zuletzt.

Viele Köpfe und zu wenig Arme, hmm Aber die Ideen von xTreme Programming und Agile Alliance sind natürlich völlig abwegig.

Ich würde unsere Vorgehensweise eher mit dem "Leuchtspurmonitions-Prinzip" der  Pragmatic Programmers vergleichen: Frühe Veröffentlichung, die Anwendung wächst mit den Anforderungen. Das birgt aber auch Gefahren. Einige Sachen von XP sind mir sehr sympatisch. Allerdings kannst du das in einem mittelständischen Unternehmen, das in erster Linie nichts mit IT zu tun hat, niemanden verklickern. Denk nur mal an Pair Programming.

carefull.  Das hört sich zwar schick an. Frag dich aber wirklich, wofür du Webservices eigentlich brauchst.

Ich denke du hast mich zum Teil falsch verstanden. Webservices sind nur eine Idee von mehreren. In erster Linie dachte ich an diese, da wir mit anderen Systemen zusammenarbeiten müssen und wir so eine einheitliche Schnittstelle, egal von welchem System kommend, implementieren könnten. Du hast mich aber schon überzeugt. Vor allem ob deiner Webservice-Beiträge an anderer Stelle im Forum. Wenn du schon meinst sie wären hier nicht angebracht ... 

Persönlich glaube ich übrigens nicht an zentrale Steuerungsdatenbanken.
Man kann auch die Workflow-Gestaltungselemente in jede Datenbank von einer speziellen Schablone reinschiessen.

Was hast du gegen zentrale Steuerungs-DBs. Einige kommerzielle Produkte basieren auf diesem Prinzip (was vielleicht nichts heißen mag). Performance könnte vielleicht eine Rolle spielen. Vielleicht noch Transaktionssicherheit, aber die muss ich in einer einzelnen DB auch gewährleisten. Was hat dich noch vom Glauben abrücken lassen?   
Ich möchte eigentlich davon abkommen, für alles den Designer anschmeißen zu müssen. Es sollen schließlich auch mal Nichtentwickler einen Workflow konfigurieren/anpassen.
Dachte da sogar schon daran Masken über DXL-Definitionen aus der Konfigurationsdatenbank dynamisch erstellen zu lassen.

Auch ich neige manchmal dazu, coole Technologien in geschäftsrelevanten Bereichen zu benutzen, ohne sie zu verstehen.

Wer hat dieses Problem nicht.   

[flaite]

Hi,

Ich würde unsere Vorgehensweise eher mit dem "Leuchtspurmonitions-Prinzip" der  Pragmatic Programmers vergleichen: Frühe Veröffentlichung, die Anwendung wächst mit den Anforderungen.

Allgemeinplatz: Das schwierige für mich (und ich denke für alle) bei größeren Projekten besteht darin, dass Projekt voranzutreiben und trotzdem gleichzeitig nicht den großen Überblick behalten/gelben Faden nicht zu verlieren.
 

wir so eine einheitliche Schnittstelle, egal von welchem System kommend, implementieren könnten.

Ich frag mich ernsthaft, ob es so etwas wie eine einheitliche Schnittstelle, egal von welchem System überhaupt gibt.
Wenn ich z.B. in meinem Client für !!!Help!!! eine Notes-ähnliche Funktion: "Wähle einen Supporter aus dem NAB aus" einbaue, dann kann das bei größeren NABs ein sehr langsames/speicherbelastendes Feature sein. Notes hat das aber eingebaut. Man kann daraus nicht den radikalen Rückschluß ziehen, dass Systemintegration Unsinn ist. Es zeigt aber, dass es "egal welches System" in konsequenter Radikalität auch nicht so sein kann.

Du hast mich aber schon überzeugt. Vor allem ob deiner Webservice-Beiträge an anderer Stelle im Forum. Wenn du schon meinst sie wären hier nicht angebracht ... 

Es gibt auf jeden Fall neue Möglichkeiten. Der Teufel steckt aber immer im Detail. Und da gibts einiges zu berücksichtigen. Das ist einer der Gründe, warum ich die HELP Integration mache.

Was hast du gegen zentrale Steuerungs-DBs.

Vielleicht ist es besser, die speziellen Workflow Designelemente zu zentralisieren. Es müssen ja nicht alle Gestaltungselemente von der selben Schablone erben. Man kann auch sagen, dass bei Datenbanken, die Workflow benötigen, diese Workflowschablonen aus einer speziellen Workflowschablonen-DB gezogen werden. Die Möglichkeit gibt es in Notes. Und ich kenne ein paar Fälle, in denen sowas gut geklappt hat. Zentral wird eben schnell aufgebläht. Und ausserdem bin ich extrem der Meinung, dass man Remote Calls möglichst gering halten sollte. Bei der Idee der zentralen Gestaltung sind die konkreten Gestaltungselemente lokal und die Gestaltung zentral. Eigentlich brauchst du nur eine zentrale Gestaltung. Alle Ansichten, Konfig-Docs, etc. wären aber lokal (d.h. schneller). 

Was hat dich noch vom Glauben abrücken lassen?   

Ich bin für die Trennung von Kirche und Staat. 

Ich möchte eigentlich davon abkommen, für alles den Designer anschmeißen zu müssen. Es sollen schließlich auch mal Nichtentwickler einen Workflow konfigurieren/anpassen.

Auf jeden Fall. Nur ist das eben nicht an eine zentrale Workflow-DB gebunden. Zentralisierung der Gestaltung ist völlig in Ordnung. Jede Duplizierung von Logik vermeiden, ist in 99.9% der Fälle der richtige Weg. Das heisst aber nicht, dass die KONKRETEN OBJEKTE zentral sind. Und das ist ein gewaltiges Missverständnis. Ted Neward hat Recht, wenn er immer wieder betont, dass die meisten in dieser Branche den Unterschied zwischen Remote und Local Call nicht richtig berücksichtigt. Und gerade leider die innovationsfreundlichen.
Im übrigen übersieht man leicht Dinge

Wer hat dieses Problem nicht.   

Ich glaub, dass im Grunde viele der wirklich guten Innovationen der letzten Jahre von Leuten gemacht worden sind, die sich einer sehr konkreten und bedrohlichen Situation gegenübersahen. Spring ist so ein Beispiel. Rod Johnson war mit dem EJB des Jahrs 1999 einfach nicht gegenüber den Anforderungen der Kunden gewachsen. Ruby on Rails ist vermutlich auch so entstanden. Auch z.B. Hibernate. Wenn das Framework erfolgreich ist, haben die Leute eine wirklich sehr existentielle Verantwortung.

Und letztlich kommt es sowieso immer auf den Kontext an.

Gruß Axel

[Christopher]

Hallo schon mal was von der Fima IMG ( www.img.de ) gehört? Wir realisieren solche Sachen mit AllDoc vielleicht ist das was für Euch.

[flaite]

Ja. Das ist mein Arbeitgeber.
Aber Alldocs ist mehr ein Dokumenten-Management-System mit Workflow-Bestandteilen.