Parallelaktion zum Überprüfen mehrerer Zustände
Warten Sie im Workflow auf eine bestimmte Zustandsänderung in der Liste? Sie haben zwei Möglichkeiten das zu realisieren:
- Mehrere Workflows pro Listenladung, die im ersten Aktivitäten die Bedingungen überprüfen.
- Ein Workflow mit einer parallelen Aktivität, der jeweils eine Bedingung überprüft. Danach werden abhängig von der Erfüllung Sub-Workflows gestartet.
Wegen des Mehraufwandes für Hydratisierung und Dehydratisierung pro Workflow sollten Sie unbedingt die zweite Variante nutzen.
Audit Trail
Dieser Punkt ist sehr kontrovers. Äußerst interessant ist die Diskussion zu diesem Thema .
- Die Zuordnung zwischen den Listen und dem Workflow-Verlauf wird automatisch nach 60 Tagen gelöscht (Tabelle 1: Einschränkungen).
- Die Elemente in der Workflow-Verlaufsliste können bei Standardeinstellung sehr leicht modifiziert werden. Entfernen von Elementen, Hinzufügen von erledigten Aufgaben im Namen von Dummy-Usern usw.
- Nach Beenden des Workflows werden die zugehörigen Aufgaben gelöscht.
Sicherheit, Rechteverwaltung
Denken Sie an folgendes Szenario: Sie haben eine Dokumentenbibliothek mit geschützten Dokumenten und verschiedenen Usern, die auf diese Bibliothek zugreifen dürfen. Die Rechte der Dokumente werden auf Einzeldokumentenebene verwaltet. Zu jedem Workflow können Sie eine Aufgabenliste und eine Workflow-Verlaufsliste definieren. Beachten Sie, dass standardmäßig alle Elemente in dieser Liste für jeden Teilnehmer der Bibliothek sichtbar sind. Jetzt denken Sie an ein Dokument mit dem Titel: "Vertrag_Kauf_von_Sun_geheim_Oracle.docx". Genau das kann jeder in der Workflow-Verlaufsliste sehen. Ein bisschen ungeschickt angestellt und schon können diverse Aktien an den Börsen den Besitzer wechseln. Jedes Mitglied der SharePoint-Bibliothek kann sogar in ein Freigabeformular gehen, nur das Absenden generiert einen Fehler. Erstellen Sie nach Möglichkeit separate Aufgabenlisten und Verlaufslisten pro Workflow. Überlegen Sie sich dafür eine Nameskonvention wie z. B. workflowName_history, workflowName_tasks. Verwenden Sie gegebenenfalls die Rechtevergabe nur auf Bibliotheksebene. Das hat auch den angenehmen Nebeneffekt, dass man pro Workflow die Aufgabe in Outlook abonnieren kann. Es gibt aber nicht nur Vorteile. Eine zusätzliche Aggregation pro User ist vielleicht trotzdem notwendig.
Flexible Abfolge
Versuchen Sie nicht alles als sequentiellen Workflow abzubilden (das ist auch die einzige Art von Workflows, die Ihnen im SharePoint Designer angeboten werden). Haben Sie Freigabeprozesse, die mehrfache Abstimmungen brauchen? Denken Sie an folgendes Szenario: Der Autor gibt einen Artikel an das dot.net Magazin, es wird zurückgeschickt mit Kommentaren und Änderungswünschen. Der Autor liefert eine neue Version. Auch diese wird nicht akzeptiert. Erst nach drei Interaktionen geht der Artikel an die Designabteilung. Verwenden Sie dafür State-Machine als Modellierungsparadigma.
Modellieren
Gehen Sie nicht sofort in das Abbilden der Workflows in SharePoint Designer oder in Visual Studio über. Sorgen Sie für eine gute Dokumentation und eine klare Struktur der Abläufe. Nur dann können Sie erfolgreich Workflows realisieren. Für die erste Version empfiehlt sich ein Tool wie Visio. Hier hat man volle Flexibilität und muss den Fachanwender nicht sofort mit den technischen Details konfrontieren. Sie als Business Analyst kennen die technischen Einschränkungen des Systems. Es kann sich als nachteilig erweisen, erst mit der Technik anzufangen ("Wir haben doch das Freigabe-Workflow in SharePoint"). Stattdessen sollte vorerst der tatsächliche Prozess abgebildet werden. Es ist wichtig, den Ablauf der Prozesse in der Workflow-Verlaufsliste entsprechend zu dokumentieren. Dabei unterscheiden Sie zwischen technischen und fachlichen Kommentaren. Auf dem produktiven System sollte man die Anzahl der Ausgaben sehr stark einschränken (es hat Auswirkungen auf die Performance ("Best Practice – Audit Trail" und "Festplattenbedarf für die Log-Files"). Bei der Modellierung der Prozesse mit Nintex können Sie mit der "Action Box" die technischen Details vor dem Fachanwender verstecken.
Binding
Workflows können an eine Liste oder einen Content Type gebunden werden (Binding). Listen-Binding:
- Verschiebt man eine Listenladung (z. B. ein Dokument), so wird der Workflow nicht umgezogen. Der Workflow hängt an der Listen-ID und nicht an der GUID.
- Laufende Workflows und deren Verlauf werden nicht verschoben.
- Die Workflows greifen auf alle Listen zu, die von einem Content Type erben.
- Laufende Workflows und deren Verlauf werden nicht verschoben
