In CRM 2013 haben wir nun die Möglichkeit, einen Workflow auf synchronen Ablauf einzustellen, was auch als Echtzeit-Workflow bezeichnet wird. Dies eröffnet großartige neue Möglichkeiten für die Nutzung von Workflows in der Gestaltung automatisierter Prozesse,und für sofort sichtbares Feedback für den Endnutzer beim Erstellen oder Ändern von CRM-Daten. Wird der Workflow-Prozess in Echtzeit ausgeführt, bietet das noch eine zusätzliche Funktion, die traditionelle, asynchrone Workflows nicht beherrschen: die Durchführung einer Transaktion zu verhindern.
This article first appeared on Surviving CRM blog.
Benutzerdefinierte Fehlermeldungen konfigurieren
Ähnlich wie synchrone Plugins können Echtzeit-Workflows dem Benutzer einen Geschäftsprozess-Fehlerdialog anzeigen, wenn der durchgeführte Vorgang gegen die Regeln der konfigurierten Geschäftslogik verstößt. Da Echtzeit-Workflows innerhalb der aktuellen Transaktion ablaufen, sind sie in der Lage, die Änderungen zurückzusetzen, die der Benutzer gerade durchführen wollte, während ein asynchroner Workflow lediglich etwas ansehen könnte, was bereits abgeschlossen ist.
Wie funktioniert das in der Praxis? Sehen wir uns die Funktion näher an, indem wir eine ganz einfache Workflow-Regel zur Verifizierung eines Datensatz-Besitzers anlegen, in diesem Fall den Projektmanager (Besitzer) einer benutzerdefinierten Projekt-Entität. Beim Anlegen des Workflow haben wir das Kästchen „diesen Workflow in Hintergrund ausführen“ deaktiviert und somit festgelegt, dass er in Echtzeit ablaufen soll. (Falls Sie darauf vergessen haben, greifen Sie einfach nach dem „In Echtzeit-Workflow umwandeln“-Knopf in der Werkzeugleiste, da das Kästchen nicht direkt im Formular bearbeitet werden kann.) Wir werden den Workflow an das Zuweisen-Ereignis der Entität anheften.
In den Workflow-Regelkriterien führen wir eine Überprüfung durch, ob der Projektmanager die für den Job notwendigen Qualifikationen aufweist. Falls nicht, halten wir den Workflow an und setzen seinen Status auf Storniert. Neu im Vergleich zu CRM 2011 Workflows ist, dass wir eine Statusmeldung für das Stornieren von Workflows setzen können. Anstatt eines lediglichen Protokoll-Eintrags hinter den Kulissen wird der Inhalt dieses Textfeldes im Falle einer Stornierung des Workflow-Prozesses auch tatsächlich dem Benutzer angezeigt. Also sollten Sie an dieser Stelle Anweisungen darüber anbieten, warum die Stornierung stattgefunden hat und wie der Benutzer sie vermeiden kann.
Aktivieren wir also unseren Workflow, gehen in einen bestehenden Datensatz und versuchen, diesen einem weniger kompetenten CRM-Projektmanager zuzuweisen, wie etwa Teppo:
Nach Klick auf OK im Zuweisen-Dialog wird eine Geschäftsprozess-Fehlermeldung angezeigt, zusammen mit dem Text unserer Statusmeldung, der erklärt, warum der Vorgang nicht zugelassen werden kann.
Die Transaktion wird zurückgesetzt, womit die Zuweisung nie stattgefunden hat und unser Projekt in den Händen einer zertifizierten Fachperson verbleibt. CRM-Workflows retten den Tag!
Hier noch ein paar Überlegungen, die man im obigen Beispiel bedenken sollte:
- Hätte ich den Workflow so eingestellt, dass er vor dem Zuweisen-Ereignis abläuft, hätte ich keine Fehlermeldung erhalten. Das liegt daran, dass wir mit einem Voraus-Abbild des Datensatzes gearbeitet hätten, in welchem der Besitzerwechsel noch nicht stattgefunden hatte. Die Verfügbarkeit dieser Optionen in der Workflow-Editor-Oberfläche verleiht mehr Flexibilität bei der Gestaltung der Geschäftslogik, jedoch sollte man zumindest ein wenig über die zugrundeliegende Dynamics CRM Event Execution Pipeline Bescheid wissen, um das Meiste herauszuholen.
- Hätte ich einfach auf die Projektmanager (Besitzer)-Suche geklickt und den Wert geändert, hätte ich so oder so keine Fehlermeldung erhalten. Das liegt daran, dass aus Sicht der Plattform das Zuweisen-Ereignis etwas anderes ist als das Ereignis, das Feld mit der Besitzer-Suche zu aktualisieren. Beachten Sie auch, dass das Anlegen eines Datensatzes für einen neuen Benutzer ebenfalls kein Zuweisen-Ereignis ist, und Sie daher die Kriterien für das Auslösen der Workflow-Regel entsprechend erweitern sollten, um dies abzufangen.
Unerwünschte Datenänderungen verhindern
In was für einer Art echtem Szenario könnte es also erforderlich werden, dass das System dem Benutzer einen Geschäftsprozess-Fehler vorsetzt? Nehmen wir eine typische CRM-Implementierung, in der die Kundendaten mit einem ERP-System integriert sind. Solange man mit Interessenten arbeitet, die bisher noch keinen Auftrag erteilt haben, sollte es im CRM nicht allzu viele Einschränkungen dafür geben, wie diese Daten geändert werden können. Sobald die Firmeninformationen allerdings zum Zweck der Bestellungs- und Rechnungsabfertigung an das ERP-System übermittelt worden sind, ist wohl der Bedarf gegeben, bestimmte Operationen an den Firmen-Datensätzen einzuschränken.
Nehmen wir an, dass wir die integrierten ERP-Firmen über das Feld Firmennummer in der Firmen-Entität im CRM identifizieren. Wenn das Feld Daten enthält, handelt es sich um einen Datensatz, an dem Änderungen beschränkt sein sollten. Durch Nutzung der neuen CRM 2013-Geschäftsregeln können wir die Formularfelder so konfigurieren, dass sie im Fall einer vorhandenen Firmennummer deaktiviert sind. Wie sieht es aber mit Datensatz-Änderungen aus, die nicht als das Ändern von Werten in Formularfeldern ausgeführt werden? Auf diesen Bereich haben Geschäftsregeln keinen Einfluss, mit Hilfe von Echtzeit-Workflows können wir hier jedoch benutzerdefinierte Geschäftslogik in das CRM einbringen, für die wir traditionell einen .NET-Entwickler gebraucht hätten, der uns ein Plugin schreibt.
Wir möchten zum Beispiel sicherstellen, dass Firmen-Datensätze im CRM nicht deaktiviert werden können, wenn sie im ERP-System existieren. So eine Deaktivierung könnte über einen Vorgang in der Datenverwaltung ausgelöst werden, wie etwa einer Duplikats-Zusammenführung, infolge derer der Masterdatensatz den aktiven Status beibehält und der untergeordnete Datensatz deaktiviert wird. Wir können den Workflow-Prozess nicht direkt durch Klicken der Schaltfläche Zusammenführen in der Firmenansicht-Befehlsleiste auslösen, aber wir können unsere Geschäftslogik auf dem Statusänderungs-Ereignis laufen lassen. Bauen wir also eine neue Echtzeit-Workflow-Regel „Firmen-Zusammenführung verhindern“ mit den folgenden Kriterien:
Tatsächlich wird dies ausgeführt, nachdem die Deaktivierung bereits erfolgt ist, aber das macht nichts, da wir den gesamten Vorgang immer noch stornieren können. Wir suchen nach allen Firmen, die ein Statusänderungs-Ereignis verzeichnet haben und sich derzeit im inaktiven Zustand befinden. Weist der Firmen-Datensatz eine Firmennummer auf, halten wir den Workflow mit einem Status ‚Storniert‘ an und liefern dem Benutzer eine Meldung, welche die erforderlichen Schritte zur korrekten Durchführung aller Änderungen in beiden Systemen, CRM und ERP, erklärt.
Versuchen wir dies zunächst bei einem einzelnen Firmen-Datensatz. Wenn wir auf den Deaktivieren-Knopf in der Befehlsleiste des Firmen-Formulars klicken, wird uns der Geschäftsprozess-Fehlerdialog angezeigt, zusammen mit der Nachricht, die wir im Workflow definiert haben. Eine Deaktivierung kann nicht erfolgen, also wird die Firma zurück in den aktiven Zustand versetzt. Genauer gesagt hat sich der Status des Firmen-Datensatzes nie gändert, wie man im Überwachungsverlauf-Protokoll (so es aktiviert ist) sehen kann.
Fein, gehen wir nun weiter zum Zusammenführungs-Szenario und versuchen wir, zwei aktive Firmen mit Firmennummern zu einer einzigen Firma zusammenzuführen. Wir wählen die Firmen aus, klicken auf Zusammenführen, durchlaufen den Dialog zur Zusammenführung von Datensätzen, missachten sämtliche Instruktionen, die uns der CRM Key-User unserer Organisation zum Thema gegeben hat, und versuchen eine Zusammenführung von zwei separaten ERP-Firmen in CRM. Sobald wir den OK-Knopf zum Ausführen der Zusammenführung geklickt haben, eilt uns der Geschäftsprozess-Fehlerdialog zu Hilfe und hält den Vorgang an.
Moment mal, warum ist der Text im Geschäftsprozess-Fehlerfenster jetzt anders? „ISV-Code hat den Vorgang abgebrochen“, was soll das bedeuten?Nun, es scheint, als ob dadurch, dass wir die Statusänderungs-Aktion nicht direkt am Datensatz durchführen, sondern den eingebauten Dialog zum Zusammenführen von Datensätzen – und die damit verbundene Geschäftslogik für die Deaktivierung von Datensätzen – nutzen, unser Statusmeldungs-Text nicht zu dieser Anzeige durchdringt. Das Ereignis selbst jedoch „blubbert hoch“, und so wird durch die verhinderte Statusänderung gleich die gesamte Transaktion zurückgesetzt, und keines der Felder in jenen Datensätzen, die von der Zusammenführung betroffen waren, wird geändert. Und das ist die Hauptsache.
Ergänzungen zu Geschäftsregeln
Werfen wir noch einen Blick auf einen letzten Anwendungsfall für Echtzeit-Workflow-Fehlermeldungen, bevor ich Sie wieder in Ruhe herumsurfen lasse. Das vorhergehende Beispiel beschäftigte sich mit einem Ereignis, das deswegen nicht von Geschäftsregeln gesteuert werden kann, da diese nur am Entitäten-Formular laufen. In einem CRM & ERP-Integrationsszenario ist es jedoch eventuell notwendig, die Firmendaten-Felder an mehreren Stellen als nur im Formular zu sperren. Bedenken Sie, dass sämtliche Änderungen, die der Benutzer auf anderem Wege, etwa als Excel-Export/Rückimport oder über eine benutzerdefinierte Client-Anwendung, durchführen könnte, die Geschäftsregeln nicht auslösen würden, die ja grundsätzlich nur Client-seitige Scripts am Formular sind. Wenn Sie diese Logik jedoch Server-seitig als Plugins oder Workflows bauen, kann niemand einen Vorgang durchführen, der die Regeln verletzt (lassen Sie jedoch stets irgendeine unterstützte Möglichkeit offen, die notwendigen Änderungen durchzuführen, und blockieren Sie während der Erstellung eines solchen Torwächter-Workflows nicht Ihre Integrationen).
Ein eingebautes Formular, auf dem die Geschäftsregeln nicht laufen, ist das Mobil-Formular. Sowohl in der Mobile Express-Browserversion als auch den Mobil-Anwendungen für Windows Phone, iPhone und Android bieten diese Formulare einen eingeschränkten Funktionsumfang zum Lesen, Erstellen und Schreiben von Datensätzen. Während Sie in den Mobil-Formularen ein Feld auf reinen Lesezugriff setzen können, ist es nicht möglich, eine bedingte Logik zu bauen, die ermittelt, wann ein Feld gesperrt sein sollte.
Nehmen wir an, Sie möchten es Leuten ermöglichen, Firmen auf die Schnelle über ihr Mobilgerät anzulegen und zu bearbeiten, aber Sie möchten auch die Firmennamen in jenen Datensätzen sperren, die auf das ERP-System synchronisiert worden sind. Um die erste Anforderung zu erfüllen, müssen Sie das Formularfeld in einem bearbeitbaren Zustand belassen. Um zu verhindern, dass jemand beim Rumfummeln im CRM auf ihren winzigen kleinen iPhone-Schirmen versehentlich den Firmennamen Ihres größten Kunden mit „Aasd,abhoignldfiiiiii” oder ähnlichem Unsinn überschreibt, können Sie einen Echtzeit-Workflow erstellen, der diese Felder vor unerwünschten Eingaben schützt. Lassen Sie ihn auf den Feldänderungs-Ereignissen laufen, prüfen Sie, ob es sich um eine ERP-Firma mit Firmennummer handelt, und stornieren Sie gegebenenfalls das Ereignis.
In der Mobile Express-Oberfläche (um auf diese Version zuzugreifen, einfach ein /m/ vor die URL der CRM-Organisation setzen) wird bei einer versuchten Bearbeitung des Firmennamen-Feldes nun die gleiche Nachricht angezeigt wie im vollen Browser-Client. Das Geschäftsprozess-Fehlerdialogfenster hat scheinbar keine für mobile Geräte optimierte Version, es erledigt aber immerhin den benötigten Job, indem die Änderung verhindert wird. Auf den Dynamics CRM Mobilanwendungen habe ich dies nicht ausgetestet, da die App jedoch zumindest auf Android mit der Mobile Express Browserversion so gut wie identisch ist, gehe ich davon aus, dass das Erlebnis dort nicht viel anders ist.
Nun gut, dies wäre fürs Erste das Ende meiner Experimente mit den Fehlermeldungen von Echtzeit-Workflowprozessen. Ich bin sicher, dass es auch in Zukunft einen Bedarf an fortgeschritteneren Lösungen zur Überprüfung von Dateneingaben durch Benutzer geben wird, wozu das Verbergen von Oberflächen-Komponenten über Scripts gehört oder das Erzwingen von Geschäftslogik mittels Plugins, insbesondere bei einem hohen erwarteten Transaktionsvolumen. Die neuen Workflowfunktionen bieten jedoch in jedem Fall eine Möglichkeit, auf die Schnelle benutzerdefinierte Fehlermeldungen zu konfigurieren und unerwünschte Ereignisse zu verhindern, während Sie mit den Gestaltungsmöglichkeiten für Ihre Lösungen experimentieren und sich Ihren Weg zum fertigen Produktions-System iterieren.