einfache Vorgehensweise um Dokumente zu approven

[krmagic]

Hallo,

wir haben für die Freigabe von Dokumenten einen Workflow der über einige Stationen geht [zb. Draft, Validation 1, Validation 2, Publication]. Jede Station wird mit einem Ordner abgebildet und man kann über einen advanced workflow den nächsten Step anfragen (zb. Request Valdiation 1, Request Validation 2 …). Das betroffene Dokument wird dann in nächsten Ordner verschoben.

Jede Benutzer muss dokumentieren, was er gemacht hat (z.B: Dokument erstellt, Dokument Validation 1 gemacht ok, wenn Dokument rejected wird warum usw.) Das soll aber nicht direkt im Dokument sein. Derzeit lösen wir das, indem wir eine Diskussion zu jedem Dokument starten. Diese Vorgehensweise ist extrem mühsam.

Die Approval Funktion ist nicht wirklich anwendbar, da die Historie von Tasks nicht beim Dokument aufgehoben wird.

Bitte um Lösungsvorschläge. Kann man die Historie von Tasks vielleicht speichern?

[jpfi_4454]

Hi,
ja, man kann die Historie eines Dokuments "frei" speichern.
Im Rahmen eurer Anwendungsfall bspw. im Rahmen einer multiple d:text property…
Wie man sowas umsetzt hängt immer vom Anwendungsfall ab….
Soll das ganze bspw, nur angezeigt werden wenn ich das Dok inAlfresco anzeige oder soll ich z.B. nach einem solchen Kommentar auch suchen können und dann das Dokument treffen?
…der teufel steckt im Detail -jdf. bei der Frage nach "best practice".
VG, Jan

[krmagic]

Hallo,

Danke für die rasche Antwort.
Es genügt wenn die Details angezeigt werden ,wenn man das Dokument in Alfresco angezeigt. Ziel des Ganzen ist einfach den "publication workflow" aufzuzeichnen, und damit zu wissen wer hat wann was gemacht (wer hat approved, wer hat rejected und warum …).

[afaust]

Hallo,

wie Jan schon geschrieben hat, ist eine Möglichkeit, die Beschreibung des Ablaufs direkt an dem Dokument zu hinterlegen - ob strukturiert oder unstrukturiert kommt dann wie gesagt auf die Anforderungen drauf an.

Es sollte aber auch darauf hingewiesen werden, dass die Daten eines jeden Workflows grundsätzlich erstmal nicht gelöscht werden und weiterhin zur Verfügung stehen - es fehlt nach Beendigung des Workflows lediglich eine Anzeige dieser Daten in der Oberfläche. Mit der neuen Workflow UI in Alfresco Share 3.4 ist es ein relativ geringer Aufwand, die gleiche UI wie für die Bearbeitung von Workflows auch für die Nach-Betrachtung zu nutzen - es müssen lediglich in der Document Details Page zusätzliche Links für die abgeschlossenen Worfklows generiert werden.

Sobald unser betroffener Kunde auf 3.4 migriert, werden wir diesen Ansatz bei ihm einsetzen. Für ältere Versionen ist der Metadaten-Ansatz ggf. der einfachere bzgl. UI, jedoch je nach Suchbarkeit-Anforderung aufwändiger im Datenmodell.

Gruß
Axel

[jpfi_4454]

Hi,
ja vollkommen korrekt. Allerdings sollte man gerade bei größeren Datenmenge in Betracht ziehen, die Daten der abgeschlossenen Workflows periodisch aufzuräumen.
Außerdem steht ein "langsamer" Wechsel in der Workflow-Engine (von jbmp -> activiti) an. Ich würde mich also langfristig nicht darauf verlassen das in kommenden Versionen eine Nutzung der Daten von abgeschlossenen WF 1:1 übernommen werden kann.
Eine weitere Möglichkeit wurde noch nicht genannt. Alfresco hat vor einiger Zeit ein neues und gut nutzbares Audit-Framework bekommen. Mit ein bisschen Konfig und ein bisschen Coding kann man sich auch hier ein ganz gute Lösung für den Zweck bauen.mehr dazu hier:  http://wiki.alfresco.com/wiki/Auditing_(from_V3.4)
VG, jan

[afaust]

Hallo,

gerade bei dem anstehenden Engine-Wechsel (wann auch immer der kommt) bin ich gespannt, ob Alfresco in der Lage ist, einen architektonisch sauberen Wechsel hin zu kriegen - und der beinhaltet aus meiner Sicht, dass die Schnittstelle des Workflow Service im Kern/Konzept unverändert bleibt, schließlich soll dieser ja verschiedene Engines abstrahieren. Damit erwarte ich auch in irgendeiner Form die weitere Verfügbarkeit von Daten zu abgeschlossenen Workflows - wie schlecht wäre dass denn in Bezug auf Nachvollziehbarkeit und Ease-of-Use, wenn ohne komplexe, zusätzliche Implementierung direkt alle Daten gelöscht würden?

Grundsätzlich müssen die Daten ja nicht wie bei einem laufenden Workflow zur Verfügung stehen - es reicht, wenn der Workflow-Service eine abstrakte History anbieten würde, ungefähr vergleichbar zur JBPM 4 Variablen History und History Service.

Mit dem Audit-Service, glaube ich, gibt es mind. eine gravierende Lücke, die nicht kontrolliert und damit historisiert werden könnte: JBPM-interne Aktionen als Folge von Action, Script oder Timer, die nicht über z.B. den WorkflowService laufen, können nicht aufgezeichnet/registriert werden.

Eine (vergleichsweise) triviale, aber die bzgl. reinem State bei Beendigung des Workflows umfassendste Lösung wäre wohl eine Action beim end-node, welche den Zustand direkt aus JBPM heraus in ein anderes Format exportiert (z.B. als XML-basiertes History-Attachment am Dokument/Space, welches durch den Workflow lief).

Auf alle Fälle ein nicht langweiliges Thema…

Gruß
Axel

[jpfi_4454]

Hallo,
ja, mit ein bisschen Codingerfahrung würde ich vorschlagen ein eigenen wHistoryModel Objekttyp (oder Typen) zu definieren welche in einem separaten Store liegen und mit den Dokumenten verknüpft sind.
Eine solche Lösung habe ich für ein stark auf Workflows aufbauenden Vertragsmanagement schonmal entwickelt. Geht eigentlich schnell von der Hand.
Bzgl. des Schwenks von jbpm auf Activiti bin ich mir nicht sicher ob Axel's Wünsche alle erfüllt werden (müssen)…
VG, jan

[afaust]

Servus,

bezüglich History bei Activiti stimmt mich der bisherige User Guide optimistisch. Zumindest gibt es einen Abschnitt zur [History|http://www.activiti.org/userguide/index.html#history]. Ich werde mir wohl demnächst in den Abendstunden mal die aktuelle Community Version anschauen. Unter Umständen ist unser kleiner Exkurs in Architektur und Software "Evolutionstheorie" gar nicht nötig gewesen.

Zum eigentlichen Thema:
Wenn man unabhängig von Workflow Technologie sicherstellen möchte, dass die Daten erhalten bleiben, und man ggf. auch danach suchen will, dann ist der Ansatz, den Jan im letzten Post dargestellt hat, der sinnvollste Weg. Zusätzlich zu dem Model Type sind dann natürlich Aktionen / Skripte innerhalb des Workflows notwendig, welche diese Strukturen anlegen / füllen. Vorteil der Sache: Man hat alles selbst unter Kontrolle, es werden keine unnötigen Daten persistiert und man kann (theoretisch) für jeden fachlich angepasste History Typen verwenden.

Auf der UI erscheinen die Informationen natürlich nicht automatisch, sodass man - für Share - in der Document Details eine Komponente braucht, welche entweder die Daten aggregiert darstellt oder auf eine derartige Darstellung verlinkt.

Dafür sind jedoch Codingerfahrungen auf allen Ebenen (Model, BPM, Web Script, Surf, YUI) notwendig. Wenns nur um die Aufzeichnung geht und Darstellung sekundär/tertiär ist, dann dürfte es in der Tat schnell von der Hand gehen.

Gruß
Axel