UiPath® Automatisierungs-Framework

Konfigurieren Sie das Communications Mining Dispatcher-Framework, eine UiPath Studio-Vorlage zum Erstellen von Automatisierungsworkflows, die Communications Mining-Daten verbrauchen.

Hinweis:

Der Aktivitätsinhalt wurde in den Communications Mining™-Aktivitätenleitfaden verlagert.

Ü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 entnehmen und sie einzeln in eine oder mehrere Warteschlangen mit eindeutigen UiPath Orchestrator-Referenzen einzufügen.

Sie sollten eine Warteschlange für jeden nachgelagerten Prozess definieren, der die Daten aus einem Stream 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:

Lesen Sie vor der Arbeit mit dem Communications Mining Dispatcher die offizielle REFramework-Dokumentation, 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 Fortschrittszyklus, wenn er das Ende des Streams erreicht, 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.

This setting allows the framework to cycle infinitely, and whenever new data becomes available in the stream, it will process it instantly, with no need to wait for when the process of the framework is scheduled to run.

Warteschlangenausgabe

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.

Validierungsregeln

Die Kommunikation wird nicht in die entsprechende Warteschlange hinzugefügt, ohne die Validierungsregeln zu übergeben. Es sind bereits einige grundlegende Validierungsregeln im Framework definiert – hauptsächlich um zu verstehen, zu welchem Prozess jedes Element gehört – aber Sie können dem Code Ihre eigenen Validierungsalgorithmen hinzufügen.

Außerdem haben wir als Beispiel 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 Processes konfiguriert wurden, können Sie Ihre eigenen Blätter und Einstellungen hinzufügen.

Wichtig:

• Make sure you do not have multiple settings with the same name in the Config file, even if they are on different sheets. They will all be added to the same Config dictionary and override each other. In the file, we offered some examples of naming conventions for the validation settings that might be useful. The logic in the workflow that checks the validation rules follows the same conventions, so be careful when implementing your own, in case you want to change them. If the validation fails, the information is added to a human-in-the-loop queue, which also requires unique references, for a human to validate in Action Center. You can add the name of your human-in-the-loop queue in the Config file. Config file, even if they are on different sheets. They will all be added to the same Config dictionary and override each other.

  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.

  If the validation fails, the information is added to a human-in-the-loop queue, which also requires unique references, for a human to validate in Action Center. You can add the name of your human-in-the-loop queue in the Config file.

• You are recommended to define a trigger on the human-in-the-loop queue, which starts a new Orchestration Process for each new item, creating a task in Action Center. The task would contain the data retrieved from Communications Mining for the current item, and the human should validate it before sending it into its corresponding downstream automation process queue.

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.

The integration of UiPath® Studio with Communications Mining consists of the consumption of each of the comments from the Communications Mining stream. Each of the communication's predictions can then be used in one or multiple downstream processes. In the diagram below, the generic UiPath and Communications Mining integration is described:

Unser Ansatz empfiehlt, dass für n Automatisierungen n + 1 Prozess in UiPath konfiguriert ist: n RPA-Prozesse und ein Warteschlangen-Feeder. 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 relevanten RPA-Prozesse zu verteilen.

Alle Ausnahmen, die aufgrund der Extraktion von Communications Mining auftreten können, können dann für die manuelle Validierung durch Menschen markiert werden. Die Prozesse, die Elemente aus den Warteschlangen abrufen, sind Standardautomatisierungen von UiPath, 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.

Sie können ihn als solche verwenden, da ohne Änderung am Code (einfach durch Hinzufügen Ihrer Einstellungen in der Excel-Konfigurationsdatei) jeder der Kommentare aus dem definierten Stream abgerufen wird (als Objekte des Typs CommunicationsMining.Result, definiert in der Kommunikation). Mining-Paket) und fügt ihre Daten in eine entsprechende Warteschlange ein. Weitere Informationen finden Sie im Abschnitt Abhängigkeiten.

Alternativ kann sie vollständig angepasst werden und Sie können Ihre eigene Logik nach Bedarf hinzufügen (z. B. die Regeln zur Validierung der Communications Mining™-Vorhersagen).

The Communications Mining Dispatcher Framework uses the Fetch and Advance Loop approach as previously described, and we can advance one comment at a time, or one batch of comments at a time (we can set up the size of the batch in the Config file).

Denken Sie daran, dass der Verteiler als Feeder 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.

Sie müssen das CommunicationsMining-Paket in einem Ihrer Feeds haben, damit das Dispatcher-Framework korrekt geladen werden kann. Es wurde aus dem Marketplace heruntergeladen: hier.

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

The variables below are declared in the Main.xaml file and shared as arguments to the workflows invoked in the Framework or they simply decide the execution flow through the framework:

Variablenname	BESCHREIBUNG
ShouldStop(Boolean)	„true“, wenn der Auftrag zwangsweise (von Orchestrator) angehalten wird.
TransactionItem(CommunicationsMining.Result)	The Transaction Item is represented by one comment from the Communications Mining stream. We're processing one item at a time and adding its data to the corresponding queue.
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)	The number of items that don't fit the filter that was defined for the stream in Communications Mining and were filtered out by the latest Fetch (filtered out of the Current Fetched Batch).
CommunicationsMiningApiToken(SecureString)	The API token defined in Communications Mining. Its value should be stored in a Credential Asset in Orchestrator.
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	We're trying to get the next Stream Batch of Communications Mining™ comments. The Fetch Stream activity will connect to Communications Mining and will populate the Fetch output object with: - the collection of results (of the size we requested) - the Sequence ID of the current batch (the Sequence ID of the last comment in the retrieved batch) - the number of filtered out comments (in case we applied filters on our Communications Mining stream, the comments that don't match the filter will be skipped) The Fetch activity performs an HTTPs request to Communications Mining.
AdvanceStreamBatch	We're trying to advance the stream of CommunicationsMining comments. The Advance Stream activity will connect to CommunicationsMining and using as an input the Sequence ID of one of the comments in the stream, it will mark the comments (before and including the one with the given Sequence ID) as read in the stream so that we do not return the same ones next time we fetch from a stream. If you fetch multiple times in a row without advancing a stream, you will get the same emails every time. The Advance activity performs an HTTPs request to CommunicationsMining.
GetTransactionData	Get a transaction item from an array of comments. Since there are multiple transactions, we use the argument in_TransactionNumber as an index to retrieve the correct transaction to be processed. If there are no more transactions left in the current batch, we need to advance the stream and fetch the next batch. If we fetch multiple times in a row without advancing a stream, you will get the same results every time. If there are items in the batch and there are still some left to process we take the instance of the next Transaction Item in the batch. Otherwise, we flag the fact that there are no more items left to process in the current batch and that we need to advance the stream. We don't set io_TransactionItem to nothing here as that would stop the processing of the whole framework, and maybe there are still items in next batches. The STOP condition is set in the Get Transaction Data STATE
CheckValidationRules	This is a basic validation algorithm example that decides whether the predictions are valid solely on the number of labels predicted for the current item. If we have one label, we have a successful validation and we just need to get the name of the downstream process from the config file. If we have multiple labels, the automatic validation is set as unsuccessful. Add your own logic for deciding the name of the Consumer process and whether the predictions on the items are Valid OR need human validation. If we have only one label predicted for the current item, we have to get the name of its corresponding process. We take the name of the Downstream (Consumer) Process from the Config file, based on that ONE label predicted for the current item. In the Config file, the naming convention of the process name setting is : The label of the comment + "_"+"Label" keyword. If the current item was predicted to have multiple labels, we need the human to decide how to proceed in the downstream automation. So the automatic validation success should be marked as false so that the current item will be added to the Human in the Loop queue for later manual Validation.
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	The purpose of the Dispatcher is to populate corresponding queues with the information obtained in Communications Mining for each of the items so that they can be processed by Consumer Processes in the Downstream Automation. In this workflow, we have to add the current item to its corresponding queue. Steps: 1. We're creating a dictionary based on the TransactionItem. We'll use the dictionary for adding the defining properties of the new queue item. 2. Based on the information obtained in Communications Mining for the current item, we're deciding its corresponding Consumer Process and checking the validation rules against the predicted data.3. If the validation is successful, we're adding the item to the queue of the Consumer Process. If not, we're adding it into the Human In The Loop queue, to be validated and potentially processed by a human. For the current Transaction: - If a BusinessRuleException is thrown, the transaction is skipped. - If another kind of exception occurs, the current transaction can be retried.
ExceptionsHandler	This workflow should be used as a final Exception Handler in the Framework. If the input DataTables are populated, they contain details on all the Application and/or Business Rule Exceptions that occurred during the current run of the process.

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.