Technische Rahmenbedingungen

Berücksichtigung von Prozess-Änderungen im Customizing-Transport

Folgende Änderungen an BPM-Prozessen werden vom Customizing-Transport berücksichtigt:

Über die Details informiert Sie die Dokumentation zum Customizing-Transport.

Rechtekonzept

Im CURSOR-BPM werden generell die Benutzerrechte aus dem CURSOR-CRM berücksichtigt für das Lesen und Schreiben von Daten berücksichtigt.

Für die nachfolgend aufgelisteten Prozessaktionen bedeutet das im Einzelnen:

• Prozessstart: Der Prozess wird mit den Rechten des Benutzers gestartet, der den betreffenden Prozess ausgelöst hat. Wird ein Prozess z. B. aufgrund der Datenänderung in einer Entität ausgelöst, so werden die Rechte herangezogen, die der Benutzer hatte, der diese Datenänderung vorgenommen hat.

• Benutzeraktion: Eine Benutzeraktion wird mit den CRM-Rechten des Zuständigen Benutzers ausgeführt.

• Script-Aktionen: Eine Script-Aktion wird mit nach dem Prozessstart mit den Rechten ausgeführt, mit denen der Prozess gestartet wurde. Im weiteren Prozessverlauf werden Script-Aktionen mit den Rechten der vorherigen Benutzeraktion ausgeführt.

• E-Mail-Import: Der E-Mail-Import erhält analog zu den vorherigen allgemeinen Beschreibungen die Rechte vom E-Mail-importierenden Benutzer bzw. die des dafür eingerichteten BCC-Importers.

• XML-Import: Der XML-Import wird mit den Rechten entsprechend der Webservice-Authentifikation ausgeführt.

Dieses Berechtigungskonzept gilt innerhalb des Prozesses auch für die Ausführung von Suchen.

Beim Speichern von Daten wird zudem zwischen Satzrechten und Feldrechten differenziert. Ist zum Speichern eines Datensatzes nicht die notwendige Berechtigung vorhanden, so läuft der Prozess auf einen Fehler. Der Prozessadministrator kann den Prozess dann einem anderen berechtigten Mitarbeiter durch Umdelegation der Instanz zuweisen oder dem ursprünglich zuständigen Mitarbeiter die entsprechenden Rechte zuweisen. Anschließend kann der Mitarbeiter die Aktion erneut in der Aktionsliste aufrufen und fortführen.

Ist zum Speichern von einzelnen Feldern einer Entität nicht die nötige Berechtigung vorhanden, so werden nur die Felder, für die die Rechte vorhanden sind, gespeichert.

Informationen über nicht ausreichende Benutzerrechte
Hat ein Benutzer nicht ausreichend Rechte auf Satzebene im Rahmen einer BPM-Benutzeraktion, so erhält der Benutzer für folgende Aktionen eine entsprechende Meldung und kann sich an seinen BPM-Administrator wenden:

• myCRM- und Maskenskript-Start von Prozessen

• Speichern, Neuanlage, Löschen von Datensätzen

• Weiterführen von Prozessen

Die Benutzer-Aktion erhält einen Fehlerstatus und kann vom BPM-Administrator wieder zur Bearbeitung freigeschaltet werden, z. B. durch die Änderung der Rechte des Benutzers oder Delegation einen anderen Benutzer.

Datenhaltung zwischen BPM-Prozess und CRM

Wichtig zu wissen:

• In/durch Benutzer-Aktionen können keine Daten in der CRM-Datenbank modifiziert werden.

Standardverhalten

Konfliktfall in Datenhaltung durch Standardverhalten

Optionales Verhalten ab Version 2015 zur Vermeidung von Konfliktfällen

Wenn BPM-Prozesse Daten aus dem CRM nutzen, so verfügen sie während der Ausführung über eine eigene Datenhaltung. Läuft eine Instanz sehr lange, weil z. B. die Bearbeitung von Benutzer-Aktionen durch Liegezeiten verzögert ist, dann kann daraus die Gefahr von abweichenden Daten zwischen dem laufenden Prozess und dem CRM entstehen, sofern dort nach dem Prozessstart Daten verändert wurden. Bislang wurden die gegebenenfalls aktuelleren Daten im CRM durch Prozesse überschrieben. Jetzt wird vom System überprüft, ob die Daten zwischen Prozess und CRM abweichen.
Technisch wird dabei für den zu speichernden Datencontainer anhand des Updatedatums im CRM überprüft, ob die Daten zum Lesezeitpunkt von den jetzt aktuell gespeicherten abweichen.
Falls eine Abweichung vorliegt, erhält der Anwender der relevanten Benutzer-Aktion den im CRM üblichen Dialog zur Bearbeitung des Datenkonflikts mit dem die Feldwerte wie vom Anwender angegeben weiterverwendet werden.

Synchrone und asynchrone Ausführung von Prozessen

Prozesse können sowohl synchron als auch asynchron ausgeführt werden.

Synchron bedeutet, dass während der Laufzeit des Prozesses (oder eines Teiles davon) keine weiteren Aktionen und Tätigkeiten im CRM-Client ausgeführt werden können und gewartet wird, bis der Prozess oder ein Teil davon vollständig abgeschlossen sind. Die parallele Ausführung mehrerer Client-Aktionen ist nur im asynchronen Modus möglich. Client-Aktionen sind nicht gleichzusetzen mit Benutzer- oder System-Aktionen innerhalb eines Prozesses. Diese Parallelisierung ist derzeit noch nicht im CURSOR-BPM möglich.

Ausgelöst werden synchrone Script-Aktionen durch Start im Vordergrund (z.B. via Maskenskript, myCRM-Bereich oder durch Reaktion auf datenbezogene Ereignisse wie Speichern u.Ä.). Asynchrone Prozessstarts erfolgen durch den Aufruf im Hintergrund (z.B. via Webservice oder Timer). Hier ist folgende Feinheit zu beachten: Aus Sicht des Webservice-Aufrufers sind Webservice-Starts synchron.

Die Ausführungsmodi unterscheiden sich zusätzlich in ihrem Verhalten wie folgt:

Bei synchroner Ausführung werden sämtliche Datenänderungen erst zum Prozess- bzw. synchronen Prozessteilende (z. B. Wartezustände, Timer und Benutzer-Aktionen, jedoch nicht Teilprozesse) in die Datenbank geschrieben. Dies dient dazu, die Datenkonsistenz bzw. -Sicherheit zu gewährleisten. Denn so werden keine Teiländerungen geschrieben, falls ein Prozess während der Ausführung auf einen Fehler stößt oder anderweitig unterbrochen bzw. abgebrochen wird.

Das bedeutet auch, dass mehrere Suchen auf einen gemeinsamen Datenraum (z.B. eine Menge von Aktivitäten) innerhalb eines Prozesses immer auf den Datenraum zugreifen, der bei Prozess- oder Suchstart gültig war. Änderungen in der Datenmenge durch den Prozess beeinflussen den gefundenen Datenbestand von synchron nachfolgenden, ebenfalls zur Instanzlaufzeit ausgeführten Suchen nicht. Andere Änderungen, z.B. aus dem CRM, können trotzdem die Datenmenge zur Instanzlaufzeit beeinflussen. Soll auf den zuvor geänderten Daten gearbeitet werden, muss auf den entstehenden bzw. geänderten Workspaces weitergearbeitet werden.

Im Gegensatz zur synchronen Ausführung werden bei der asynchronen Ausführung alle Änderungen sofort in die Datenbank geschrieben. Das liegt daran, dass ein Zwischenspeichern der Daten im Prozessverlauf nicht möglich ist oder nur mit bestimmten primitiven Datentypen (z. B. Integer) und Objekten funktioniert (siehe Prozessvariablen, die nur eben diese Datentypen unterstützen).  Entsprechend können Suchen, die während der Prozesslaufzeit von der Prozessinstanz ausgeführt werden, auf demselben Datenbestand arbeiten und verfügen dabei immer über die aktuellen Änderungen der vorherigen Prozessschritte oder Codeausführungen.

Ein eigentlich synchroner Prozess kann asynchron zur Ausführung gebracht werden, indem ein zeitliches Zwischenereignis vor den Teil des Prozesses geschaltet wird, ab dem man die asynchrone Ausführung wünscht.

Dies ist nur dann zu empfehlen, wenn die Sicherheit des Prozesses im produktiven Umfeld gegeben ist und alle Fehlerquellen ausgeschlossen werden können, da Teiländerungen am Datenbestand bei Prozessabbruch nicht zurückgenommen werden.

Beim asynchronen Prozessverlauf sollte auf Datenintegrität geachtet werden: der relevante Prozessabschnitt ist so zu gestalten, dass mögliche Prozessunterbrechungen (z. B. Serverabsturz) möglichst wenig zu bereinigende Daten produzieren.

Tipp

Datenänderungen am Ende dieser Prozessabschnitte in To-Do-Blöcke zusammenfassen.

Beispiel: Daten vorher in Variablen sammeln, erst am Ende in die Datenbank schreiben