UiPath® Automatisierungs-Framework

Hinweis:

Verbesserte Zugänglichkeit – Verschieben von Aktivitätsinhalten

Wir arbeiten ständig daran, Ihre Erfahrung zu verbessern und unsere Ressourcen benutzerfreundlicher zu gestalten.

Wir haben unseren Entwicklerleitfaden neu organisiert und die Aktivitäten in den neuen Communications Mining™-Aktivitätenleitfaden verlagert. Sie haben jetzt einen einfacheren Zugriff und eine verbesserte Navigation.

Wir glauben, dass diese Änderung Ihre Erfahrung optimiert und Ihnen hilft, die benötigten Informationen effizienter zu finden. Wir legen Wert auf Ihr Feedback und freuen uns darauf, Ihren weiteren Erfolg mit unserer Plattform zu unterstützen.

Überblick

Das Communications Mining™ Dispatcher-Framework ist eine UiPath® Studio-Vorlage, die Sie bei der Integration von Communications Mining in RPA-Implementierungen verwenden können. Das Ziel besteht darin, die Kommentare aus einem Communications Mining-Stream zu nehmen und sie nacheinander zu einer oder mehreren eindeutigen Referenzwarteschlangen im UiPath Orchestrator hinzuzufügen. Sie sollten eine Warteschlange für jeden nachgelagerten Prozess definieren, der die Daten eines Streams als Eingabe benötigt. Standardmäßig haben wir in der Konfigurationsdatei zwei Prozesswarteschlangen (für Prozess A und B) und eine generische Warteschlange eingerichtet, aber Sie können so viele konfigurieren, wie Sie benötigen.

Sie können das Framework von Studio unter Templates abrufen, indem Sie nach Communications Mining Dispatcher suchen.

Wichtig: Wählen Sie beim Erstellen Ihrer Warteschlangen die Option Eindeutige Referenzen erzwingen aus.

Die Vorlage basiert auf dem Robotic Enterprise Framework (REFramework) und deckt alle wesentlichen Best Practices in RPA-Projekten ab, wie z. B. flexible Konfiguration über die Config.xlsx-Datei, Ausnahmebehandlung, Wiederholungsmechanismen und aussagekräftige Protokollierung.

Hinweis: Bevor Sie mit dem Communications Mining Dispatcher arbeiten, sollten Sie die offizielle REFramework-Dokumentation lesen, wenn Sie mit dieser nicht vertraut sind.

Ausgehend von einem REFramework-Projekt haben wir die beiden wichtigsten Vorgänge abgekapselt, die ausgeführt werden müssen, wenn Daten aus einem Communications Mining-Stream verbraucht werden: Abrufen und Vorrücken. Beim Abrufen werden Daten aus einem Communications Mining-Stream abgerufen. Beim nächsten Abrufen werden die Kommentare im Wesentlichen als gelesen markiert, sodass wir beim nächsten Abrufen nicht dieselben zurückgeben. Wir werden im nächsten Abschnitt ausführlicher darauf eingehen.

Standardmäßig beendet das Framework den Abruf- und Weiterleitungszyklus, wenn der Stream beendet ist, d. h. wenn der Stream keine ungelesenen Kommentare mehr enthält. Sie können das Framework jedoch so konfigurieren, dass es kontinuierlich ausgeführt wird, auch wenn es das Ende des Streams erreicht. Dazu können Sie die Einstellung ExitOnEmptyStream als False in der Datei Config.xlsx markieren. Mit dieser Einstellung kann das Framework unendlich wechseln und neue Daten werden sofort verarbeitet, wenn neue Daten im Stream verfügbar werden, ohne auf den Zeitpunkt warten zu müssen, an dem der Prozess des Frameworks ausgeführt werden soll.

Das Ziel ist, dass die Kommentare in einer nutzbaren Orchestrator-Warteschlange verfügbar sind, einem Warteschlangenelement pro Kommentar, das die entsprechenden Daten und vorhergesagten Beschriftungen und allgemeinen Felder enthält. Auf diese Weise haben die nachgelagerten Automatisierungen Zugriff auf die vorhergesagten Informationen.

Die Kommunikation wird nicht zur entsprechenden Warteschlange hinzugefügt, ohne die Validierungsregeln zu übergeben. Einige grundlegende Validierungsregeln sind bereits im Framework definiert – hauptsächlich um zu verstehen, zu welchem Prozess jedes Element gehört – aber Sie können dem Code eigene Validierungsalgorithmen hinzufügen. Außerdem gibt es in der Datei Config.xlsx separate Validierungseinstellungsblätter für jeden nachgelagerten Automatisierungsprozess, d. h. ProcessAValidations und ProcessBValidations. Da sie nur als Beispiele für theoretische Prozesse konfiguriert wurden, können Sie gerne Ihre eigenen Blätter und Einstellungen hinzufügen.

Wichtig:

• Stellen Sie sicher, dass Sie nicht mehrere Einstellungen mit demselben Namen in der Konfigurationsdatei haben, auch wenn sie sich auf verschiedenen Blättern befinden. Sie werden alle demselben Konfigurationswörterbuch hinzugefügt und überschreiben sich gegenseitig.

  In der Datei haben wir einige Beispiele für Namenskonventionen für die Validierungseinstellungen angegeben, die nützlich sein könnten. Die Logik im Workflow, die die Validierungsregeln überprüft, folgt denselben Konventionen, also sind Sie bei der Implementierung Ihrer eigenen vorsichtig, wenn Sie sie ändern möchten.

  Wenn die Validierung fehlschlägt, werden die Informationen zu einer Human-in-the-Loop-Warteschlange hinzugefügt, die auch eindeutige Referenzen erfordert, damit sie im Action Center von Menschen validiert werden können. Sie können den Namen Ihrer Human-in-the-Loop-Warteschlange in der Konfigurationsdatei hinzufügen.

• Es wird empfohlen, einen Trigger in der Human-in-the-Loop-Warteschlange zu definieren, die einen neuen Orchestrierungsprozess für jedes neue Element startet und eine Aufgabe im Action Center erstellt. Die Aufgabe würde die Daten enthalten, die von Communication Mining für das aktuelle Element abgerufen wurden, und der Mensch sollte sie validieren, bevor er sie in die entsprechende Warteschlange des nachgelagerten Automatisierungsprozesses sendet.

Streams

Nach dem erfolgreichen Training eines Modells in Communications Mining™ können wir einen neuen Stream erstellen und die Schwellenwerte für jedes der trainierten Konzepte konfigurieren. Ein Stream definiert eine Sammlung von Kommentaren in einem Dataset. Sie ermöglicht eine persistente, zustandsbehaftete Iteration durch die Kommentare, mit vorhergesagten Beschriftungen und allgemeinen Feldern, die mit einer bestimmten Modellversion berechnet werden.

Hinweis:

Wir empfehlen Ihnen, sich an die offizielle Communications Mining-Dokumentation und UiPath Academy zu halten, um die Schritte des Modelltrainings und Details zu allen beteiligten Konzepten zu erhalten.

Die Integration von UiPath® Studio in Communications Mining besteht aus dem Verbrauch jedes Kommentars aus dem Communications Mining-Stream. Jede der Vorhersagen der Kommunikation kann dann in einem oder mehreren nachgelagerten Prozessen verwendet werden. Im folgenden Diagramm wird die generische UiPath- und Communications Mining-Integration beschrieben:

Unser Ansatz empfiehlt, dass für n Automatisierungen n + 1 Prozesse in UiPath konfiguriert sind: n RPA-Prozesse und ein Warteschlangenfeed. Es wird ein einzelner Feeder-Prozess eingeführt, der dafür verantwortlich ist, die strukturierte Kommunikation aus dem Stream eines Communications Mining zu lesen und sie über Orchestrator-Warteschlangen an die entsprechenden RPA-Prozesse zu verteilen. Alle Ausnahmen, die aufgrund der Extraktion mit Communications Mining auftreten können, können dann für die manuelle menschliche Validierung markiert werden. Die Prozesse, die Elemente aus den Warteschlangen abrufen, werden standardmäßige UiPath-Automatisierungen sein, die ihre Eingabedaten aus den Daten des Warteschlangenelements lesen. Das bereitgestellte Verteiler-Framework erfüllt die Rolle des Warteschlangenfeeders.

Abruf-Vorwärts-Schleife

Um Kommentare aus einem Stream zu verbrauchen, muss unser Framework die Abruf- und Advance-Schleife implementieren, die wie folgt beschrieben wird:

1. Jeder Stream hat einen aktuellen Kommentar:
   
   

   

   
   
2. Wir können Kommentare ab diesem aktuellen Kommentar abrufen. In der folgenden Abbildung rufen wir zwei Kommentare ab:
   
   

   

   
   
3. Jeder Kommentar, der von einem Stream zurückgegeben wird, hat ein sequence_id:

   {
      "comment":{
         "messages":[ ... ],
         "user_properties":{ ... },
         "id":"comment 1"
      },
      "entities":[ ... ],
      "labels":[ ... ],
      "sequence_id":"ABC123"
   }

4. Wir können diese sequence_id verwenden, um den aktuellen Kommentar zum nächsten in der Warteschlange zu machen. Wenn wir jetzt 2 abrufen, geben wir die Kommentare 2 und 3 zurück:
   
   

   

   
   

Das Communications Mining-Framework implementiert diese Abruf- und Vorab-Schleife für Sie.

Verteiler-Framework – Übersicht

Durch einfaches Ändern der erforderlichen Einstellungen können Sie das Verteiler-Framework so konfigurieren, dass Kommentare aus Ihrem eigenen Stream verbraucht werden. Dadurch sparen Sie Implementierungszeit und stellen sicher, dass Best Practices befolgt werden.

Genau wie das REFramework kann es genau so verwendet werden, wie es ist, als Plug-and-Play-Lösung, da es ohne Änderung des Codes (nur durch Hinzufügen Ihrer Einstellungen in der Konfigurations-Excel-Datei) jeden Kommentar aus der definierten Vorlage abruft streamen (als Objekte vom Typ CommunicationsMining.Result, definiert im CommunicationsMining-Paket ( siehe Abschnitt Abhängigkeiten) und fügt ihre Daten zu einer entsprechenden Warteschlange hinzu. Alternativ kann sie vollständig benutzerdefiniert angepasst werden und Sie können bei Bedarf Ihre eigene Logik hinzufügen (z. B. die Regeln zur Validierung der Vorhersagen von Communications Mining™.

Das Communications Mining Dispatcher Framework verwendet den Abrufen und erweiterten Schleifen -Ansatz, wie zuvor beschrieben, und wir können einen Kommentar nach dem anderen oder einen Satz von Kommentaren gleichzeitig bereitstellen (wir können die Größe des Batches in der Konfigurationsdatei einstellen). Denken Sie daran, dass der Verteiler als Feed für einen oder mehrere nachgelagerte Prozesse verwendet wird. Deshalb definieren wir in der Konfigurationsdatei auch die entsprechende Warteschlange für jeden dieser Prozesse und die Regeln zum Hinzufügen des Elements zur Warteschlange.

Die Schritte sind insgesamt:

• Wir rufen einen ersten Stapel von Kommentaren ab. Dadurch wird ein Batch von Kommentaren aus dem Communications Mining-Stream, der sequence_id des letzten Elements im Batch und die Anzahl der Elemente zurückgegeben, die aus dem aktuellen Batch herausgefiltert werden.
• Wenn keine Ausnahme aufgetreten ist (wir haben die Verbindung mit dem Stream erfolgreich hergestellt) und wir nicht das Ende des Streams erreicht haben, überprüfen wir, ob im aktuellen Batch noch Elemente zu verarbeiten sind (wir können sogar Batches ohne Kommentare abrufen, wenn es welche gibt). Filter, die in Communications Mining für den aktuellen Stream angewendet wurden und keiner der Kommentare im aktuellen Batch zutrifft).
• Wenn Elemente zu verarbeiten sind, bearbeiten wir sie nacheinander: Je nachdem, zu welchem Verbraucher-RPA-Prozess das aktuelle Element gehört, überprüfen wir die Validierungsregeln der Daten des Elements.
• Wenn das Element die Prüfungen besteht, fügen wir der entsprechenden Warteschlange (wie in der Excel-Konfigurationsdatei festgelegt) ein neues Warteschlangenelement hinzu. Die UID des Kommentars wird als Referenz des Warteschlangenelements festgelegt. Wenn sie die Validierungsregeln nicht besteht, fügen wir ein Warteschlangenelement zur HilL-Warteschlange hinzu. Jedes Warteschlangenelement, das erstellt wird, enthält alle Vorhersagen des allgemeinen Felds und der Beschriftung des Kommentars zur Verwendung in nachgelagerten Prozessen.
• Nachdem jedes Element im aktuellen Batch verarbeitet wurde, rücken wir zuerst den Stream vor (mithilfe des sequence_id des letzten Elements des Batches) und rufen dann einen neuen Batch aus dem Stream ab.
• Wenn wir am Ende des Streams sind (da wir keine Kommentare im Batch abgerufen haben und keine gefilterten Kommentare vorhanden sind), wissen wir, dass wir das Ende des Streams überschritten haben und die Verarbeitung beendet ist.

Konfiguration

Alle Einstellungen, die wir zum Konfigurieren des Verteilers benötigen, finden Sie in der Datei Data/Config.xlsx.

Hinweis: Stellen Sie sicher, dass Sie alle entsprechenden Assets zum Orchestrator hinzufügen.

Die Blätter zu Einstellungen und Assets

Name	BESCHREIBUNG
OrchestratorProcessAQueueName	Dies ist die Warteschlange, in die unser Verteiler VALID-Kommentare einschieben wird, die vom RPA-Verbraucherprozess A verarbeitet werden sollen.
OrchestratorProcessBQueueName	Dies ist die Warteschlange, in die unser Verteiler VALID-Kommentare einschieben wird, die vom RPA-Verbraucherprozess B verarbeitet werden sollen.
OrchestratorHITLQueueNameA	Dies ist die Warteschlange, in die unser Verteiler Kommentare verschiebt, die die für den entsprechenden Prozess definierten Validierungsregeln nicht bestanden haben. HITLQueue wird vom Orchestrierungsprozess, der Validierungsaktionen für jedes der hinzugefügten Warteschlangenelemente erstellt, verarbeitet.
OrchestratorGeneralQueueName	Dies ist die Warteschlange, in die unser Verteiler Kommentare einreihen wird, die nicht für einen bestimmten RPA-Verbraucherprozess kategorisiert wurden.
Communications MiningApiTokenCredential	Das Communications Mining™-API-Token, das zum Abrufen aus dem Stream und zum Fortfahren innerhalb des Streams erforderlich ist, gespeichert in einem Anmeldeinformations-Asset.
ExitOnEmptyStream	Wenn diese Einstellung „False“ ist, wird das Framework kontinuierlich ausgeführt, auch wenn das Ende des Streams erreicht ist.

Jedes der Prozessvalidierungsblätter

Name	BESCHREIBUNG
{ProcessName}_Label	Die Namenskonvention der Einstellung ist die Bezeichnung, die einen Kommentar als vom aktuellen Prozess behandelt werden soll, + Schlüsselwort „_“+ „Bezeichnung“ Der Wert davon ist der Name des Downstream-Prozesses. Beispiel: Name Policy_Label, Wert ProcessA.

Da der Verteiler Eingabewarteschlangen für einen oder mehrere Downstream-Prozesse ausfüllen kann, empfehlen wir Ihnen, für jeden der Prozesse ein neues Blatt in der Konfigurationsdatei zu erstellen, in dem Sie die Validierungsregeln für diesen Prozess definieren. Die Namenskonvention des Blatts sollte „{ProcessName}Validations“ lauten. Standardmäßig enthält die Konfigurationsdatei 2 Validierungsblätter für Prozess A und Prozess B.

Ausnahmebehandlung

Das Framework sammelt jede Ausnahme, die während der Verarbeitung eines der Transaktionselemente (Communications Mining™-Kommentare) auftritt, in zwei Datentabellen: eine für Systemausnahmen und eine andere für Geschäftsregelausnahmen.

Im Status Endprozess können Sie die Tabellen zum Bearbeiten der Ausnahmen gemäß Ihrer Geschäftslogik verwenden (Excel-Dateien mit ihnen erstellen, an eine Berichts-E-Mail angehängt senden usw.).

Architektur

Abhängigkeiten

Wir haben benutzerdefinierte Aktivitäten erstellt, die die wichtigsten Vorgänge verarbeiten, die von UiPath® zur Integration in Communications Mining™ ausgeführt werden können: Stream abrufen, Advance Stream. Außerdem sind die Transaktionen des Frameworks vom Typ CommunicationsMining.Result, ein im Paket definierter Datentyp, der alle für jeden Kommentar definierten Informationen und die entsprechenden vorhergesagten Labels und allgemeinen Felder enthält.

You need to have the CommunicationsMining package in one of your feeds, in order for the Dispatcher Framework to load correctly, downloaded from the Marketplace: here.

Status (States)

Da es sich bei dem Framework im Grunde um ein REFramework handelt, handelt es sich um eine State Machine mit den gleichen Zuständen. Weitere Informationen zu den einzelnen Status finden Sie in der REFramework-Dokumentation.

Die einzige Änderung ist das Hinzufügen des erweiterten Stream-Übergangs zwischen dem Status „Transaktionsdaten abrufen“ und dem Prozesstransaktionsstatus. Falls im aktuellen abgerufenen Batch keine Elemente zu verarbeiten sind, kehrt die Ausführung zum Status „GetTransactionData“ zurück, um im Stream weiter voranzutreiben.

Gemeinsame Variablen

Die folgenden Variablen werden in der Datei „Main.xaml“ deklariert und als Argumente für die Workflows freigegeben, die im Framework aufgerufen werden, oder sie entscheiden einfach über den Ausführungsablauf durch das Framework:

Variablenname	BESCHREIBUNG
ShouldStop(Boolean)	„true“, wenn der Auftrag zwangsweise (von Orchestrator) angehalten wird.
TransactionItem(CommunicationsMining.Result)	Das Transaktionselement wird durch einen Kommentar aus dem Communications Mining-Stream dargestellt. Wir verarbeiten jeweils ein Element und fügen seine Daten zur entsprechenden Warteschlange hinzu.
SystemException(Exception)	Wird bei Übergängen zwischen Status verwendet, um andere Ausnahmen als Geschäftsausnahmen darzustellen.
BusinessException(BusinessRuleException)	Wird bei Übergängen zwischen Status verwendet und stellt eine Situation dar, die nicht den Regeln des zu automatisierenden Prozesses entspricht.
TransactionNumber(Int32)	Sequenzieller Zähler der Transaktionselemente.
Config(Dictionary(String,Object))	Dictionary structure to store configuration data of the process (settings, constants, assets and Validation properties).
RetryNumber(Int32)	Wird verwendet, um die Anzahl der Versuche zu steuern, die Transaktionsverarbeitung im Falle von Systemausnahmen zu wiederholen.
TransactionData(IList(CommunicationsMining.Result))	Der Batch der derzeit aus dem Stream abgerufenen Kommentare nach dem letzten Abruf.
ConsecutiveSystemExceptions(Int32)	Wird verwendet, um die Anzahl der aufeinanderfolgenden Systemausnahmen zu steuern.
BusinessExceptionsDT(DataTable)	Tabelle mit Details zu den BusinessRulesExceptions, die während der Verarbeitung der Transaktionen aufgetreten sind. Eine Zeile enthält Informationen über eine fehlerhafte Transaktion.
ApplicationExceptionsDT(DataTable)	Table with details on the System Exceptions occurred during the processing of the Transactions. One row contains info about one faulty transaction
GlobalRetryInterval(TimeSpan)	Das globale Wiederholungsintervall, das standardmäßig für jeden Wiederholungs-Scope im Framework festgelegt ist.
GlobalMaxAttempts(Int32)	The global number of Max Attempts set by default for every Retry Scope in the Framework.
CurrentSequenceId(String)	Die Sequence-ID, die vom letzten Abruf eines Stream-Batches abgerufen wurde. Dies ist die Sequence-ID des letzten Elements im aktuellen Stream-Batch.
CurrentBatchFilteredResults(Int32)	Die Anzahl der Elemente, die nicht dem Filter entsprechen, der für den Stream in Communication Mining definiert wurde und beim letzten Abruf herausgefiltert wurde (aus dem aktuell abgerufenen Batch herausgefiltert).
CommunicationsMiningApiToken(SecureString)	Das in Communication Mining definierte API-Token. Der Wert muss in einem Anmeldeinformations-Asset im Orchestrator gespeichert werden.
CurrentBatchNumber(Int32)	Es empfiehlt sich, den Stream in mehrere Batches aufzuteilen (um die Leistungszeit des Abrufens der Daten zu verbessern). Dadurch können Sie uns den aktuellen Batch mitteilen, der verarbeitet wird.
ShouldAdvanceTheStream(Boolean)	Falls im aktuell abgerufenen Batch keine Elemente zu verarbeiten sind, kehrt die Ausführung zum Status „GetTransactionData“ zurück, um im Stream weiter voranzutreiben.

Communications Mining™-spezifische Workflows

Workflowname	BESCHREIBUNG
GetNextStreamBatch	Wir versuchen, den nächsten Stream Batch von Communications Mining™ zu erhalten. Die Aktivität „Fetch Stream“ stellt eine Verbindung mit Communications Mining her und füllt das Abruf-Ausgabeobjekt mit:- der Sammlung von Ergebnissen (in der von uns angeforderten Größe)- Der Sequence-ID des aktuellen Batches (der Sequence-ID des letzten Kommentars im abgerufenen Batch ) – die Anzahl der herausgefilterten Kommentare (falls wir Filter auf unseren Communications Mining Stream angewendet haben, werden Kommentare, die nicht mit dem Filter übereinstimmen, übersprungen). Die Abrufaktivität führt eine HTTPs-Anforderung an Communications Mining aus .
AdvanceStreamBatch	Wir versuchen, den Stream der CommunicationsMining-Kommentare voranzutreiben. Die Aktivität Erweiterter Stream stellt eine Verbindung mit CommunicationsMining her und verwendet als Eingabe die Sequence-ID eines der Kommentare im Stream. Sie markiert die Kommentare (vor und einschließlich desjenigen mit der angegebenen Sequence-ID) als im Stream gelesen, sodass wir geben nicht die gleichen zurück, wenn wir das nächste Mal aus einem Stream abrufen. Wenn Sie mehrmals hintereinander abrufen, ohne einen Stream voranzutreiben, erhalten Sie jedes Mal die gleichen E-Mails. Die Aktivität Advance führt eine HTTPs-Anforderung an CommunicationsMining aus.
GetTransactionData	Rufen Sie ein Transaktionselement aus einem Array ab. Da es mehrere Transaktionen gibt, verwenden wir das Argument in_TransactionNumber als Index, um die richtige Transaktion abzurufen, die verarbeitet werden soll. Wenn im aktuellen Batch keine Transaktionen mehr übrig sind, müssen wir den Stream fortsetzen und den nächsten Batch abrufen. Wenn wir mehrmals hintereinander abrufen, ohne einen Stream vorrücken zu müssen, erhalten Sie jedes Mal die gleichen Ergebnisse. Wenn der Batch Elemente enthält und noch einige zu verarbeiten sind, übernehmen wir die Instanz des nächsten Transaktionselements im Batch. Andernfalls kennzeichnen wir die Tatsache, dass im aktuellen Batch keine Elemente mehr zu verarbeiten sind und dass wir den Stream vorantreiben müssen. Wir setzen io_TransactionItem hier nicht auf nichts, da dies die Verarbeitung des gesamten Frameworks stoppen würde und möglicherweise noch Elemente in nächsten Batches vorhanden sind. Die Stop-Bedingung wird im Get Transaction Data-State festgelegt
CheckValidationRules	Dies ist ein Beispiel für einen grundlegenden Validierungsalgorithmus, der entscheidet, ob die Vorhersagen gültig sind, ausschließlich auf der Anzahl der Beschriftungen, die für das aktuelle Element vorhergesagt wurden. Wenn wir eine Bezeichnung haben, haben wir eine erfolgreiche Validierung und müssen nur den Namen des Downstream-Prozesses aus der Konfigurationsdatei abrufen. Wenn mehrere Bezeichnungen vorhanden sind, wird die automatische Validierung als nicht erfolgreich festgelegt. Fügen Sie Ihre eigene Logik hinzu, um den Namen des Verbraucherprozesses zu entscheiden und ob die Vorhersagen für die Elemente Gültig sind ODER eine menschliche Validierung benötigen. Wenn für das aktuelle Element nur eine Bezeichnung vorhergesagt wird, müssen wir den Namen des entsprechenden Prozesses abrufen. Wir entnehmen den Namen des Downstream-(Verbraucher-)Prozesses aus der Konfigurationsdatei, basierend auf dieser Einen Bezeichnung, die für das aktuelle Element vorhergesagt wurde. In der Konfigurationsdatei lautet die Namenskonvention der Prozessnameneinstellung: Die Bezeichnung des Kommentars + das Schlüsselwort „_“+ „Beschriftung“. Wenn für das aktuelle Element mehrere Beschriftungen vorhergesagt wurden, muss der Mensch entscheiden, wie mit der nachgelagerten Automatisierung fortgefahren werden soll. Daher sollte die automatische Validierung erfolgreich als „false“ markiert werden, sodass das aktuelle Element zur späteren manuellen Validierung zur Warteschlange „Mensch in der Schleife“ hinzugefügt wird.
CreateDictionaryFromCommunicationsMiningItem	Wir müssen die Informationen, die aus CommunicationsMining für das aktuelle Element entnommen wurden, zu einer Warteschlange hinzufügen. Deshalb erstellen wir ein Wörterbuch darauf. Wir verwenden das Wörterbuch, um die definierenden Eigenschaften des neuen Warteschlangenelements hinzuzufügen.
AddTransactionItemToQueue	Hinzufügen eines neuen Elements zur Warteschlange. Alle seine Eigenschaften müssen bereits im Wörterbuch in_QueueItemProperties eingerichtet sein. Stellen Sie sicher, dass bei Ihrer Warteschlange das Kontrollkästchen Eindeutige Referenzen erzwingen aktiviert ist.
Prozess	Der Zweck des Verteilers besteht darin, entsprechende Warteschlangen mit den in Communications Mining™ für jedes der Elemente erhaltenen Informationen zu belegen, damit sie von Verbraucherprozessen in der nachgelagerten Automatisierung verarbeitet werden können. In diesem Workflow müssen wir das aktuelle Objekt der entsprechenden Warteschlange hinzufügen. Schritte:1. Wir erstellen ein Wörterbuch basierend auf dem TransactionItem. Wir verwenden das Wörterbuch, um die definierenden Eigenschaften des neuen Warteschlangenelements hinzuzufügen.2. Basierend auf den in Communications Mining für das aktuelle Element erhaltenen Informationen entscheiden wir über den entsprechenden Verbraucherprozess und überprüfen die Validierungsregeln mit den vorhergesagten Daten.3. Wenn die Validierung erfolgreich ist, fügen wir das Element zur Warteschlange des Verbraucherprozesses hinzu. Wenn nicht, fügen wir sie in die Warteschlange „Human in the Loop“ ein, um von einem Menschen validiert und möglicherweise verarbeitet zu werden. Für die aktuelle Transaktion:- Wenn eine BusinessRuleException ausgelöst wird, wird die Transaktion übersprungen.- Wenn eine andere Art von Ausnahme auftritt, kann die aktuelle Transaktion wiederholt werden.
ExceptionsHandler	Dieser Workflow sollte als endgültiger Ausnahmehandler im Framework verwendet werden. Wenn die Eingabe-Datentabellen aufgefüllt werden, enthalten sie Details zu allen Anwendungs- und/oder Geschäftsregelausnahmen, die während der aktuellen Ausführung des Prozesses aufgetreten sind.

Verwenden des Frameworks

Vor der Verwendung des Frameworks:

• Stellen Sie sicher, dass Sie alle erforderlichen Assets im Orchestrator konfigurieren (aktivieren Sie den Abschnitt Einstellungen und Assets) und nehmen Sie die erforderlichen Änderungen in der Datei Data/Config.xlsx vor.
• Stellen Sie sicher, dass die Warteschlangen, in die Sie die Elemente hinzufügen, im Orchestrator vorhanden sind und das Kontrollkästchen „Eindeutige Referenzen erzwingen“ aktiviert ist, um zu vermeiden, dass der Warteschlange Duplikate hinzugefügt werden und dasselbe Element in den nachgelagerten Automatisierungen mehrmals verarbeitet wird.
• Fügen Sie Ihre eigenen Validierungsregeln in Communications Mining/CheckValidationRules.xaml hinzu. Im Moment überprüfen wir nur, ob für das aktuelle Element mehrere Beschriftungen vorhergesagt wurden. Wenn ja, schlägt die Validierung fehl. Wenn nicht, wird der Prozessname für das aktuelle Element basierend auf seiner Bezeichnung verwendet.