Über Warteschlangen und Transaktionen

Eine Warteschlange ist ein Container, der es Ihnen ermöglicht, eine unbegrenzte Anzahl an Objekten zu halten. Warteschlangenobjekte können mehrere Datentypen speichern, wie Rechnungsinformationen oder benutzerdefinierte Details. Diese Informationen können in anderen Systemen verarbeitet werden - SAP oder Salesforce zum Beispiel.

Die in Warteschlangenelementen gespeicherten und aus Warteschlangenelementen ausgegebenen Daten sind standardmäßig formfrei. In Situationen, in denen ein bestimmtes Schema erforderlich ist, z. B. bei Integrationen in andere Anwendungen, bei der Verarbeitung von maschinengenerierten Formularen oder Analysen, können Sie benutzerdefinierte JSON-Schemas hochladen, um sicherzustellen, dass alle Warteschlangenelementdaten im richtigen Format vorliegen.

Im Orchestrator sind neu erstellte Warteschlangen standardmäßig leer. Um sie mit Elementen aufzufüllen, können Sie entweder die Upload-Funktion im Orchestrator oder Studio-Aktivitäten verwenden. Mit Letzterem können Sie auch Elementstatus ändern und verarbeiten. Sobald Warteschlangenelemente verarbeitet sind, werden sie zu Transaktionen.

Warteschlangenübersicht

Mit Warteschlangen können Sie große Automatisierungsprojekte erstellen, denen komplexe Logik zugrunde liegt. Sie können zum Beispiel einen Prozess erstellen, der alle Rechnungsinformationen erfasst und für jeden Datensatz ein Warteschlangenobjekt zu dessen Speicherung erstellt. Nachfolgend können Sie einen weiteren Prozess erstellen, der die Informationen vom Orchestrator aufnimmt und zur Durchführung weiterer Aufgaben verwendet wird, etwa:

• Bezahlen der Rechnungen in eine andere Anwendung.
• Aufschieben ihrer Zahlung entsprechend ihrem Fälligkeitsdatum oder Wert.
• Senden von E-Mails an die Buchhaltung, jedes Mal, wenn eine Rechnung bezahlt wird. Auf der Seite Warteschlangen können Sie neue Warteschlangen erstellen, zuvor erstellte Warteschlangen anzeigen und auf Diagramme zugreifen, die den Fortschritt des Transaktionsstatus im Zeitverlauf anzeigen, zusammen mit verschiedenen anderen Details, wie der durchschnittlichen Ausführungsdauer und der Gesamtzahl erfolgreicher Transaktionen.

Die verfügbaren Daten im Warteschlangenraster werden in regelmäßigen Abständen aktualisiert, was bedeutet, dass sie nicht immer in Echtzeit angezeigt werden und leichte Verzögerungen möglich sind. Außerdem sind sie nicht von Aufbewahrungsrichtlinien betroffen, sodass sich die in der Tabelle verfügbaren Informationen durch das Archivieren von Elementen der Datenbank nicht ändern.

Objektstatus (Item statuses) werden von RPA-Entwicklern beim Erstellen von Automationsprojekten kontrolliert, während Revisionsstatus in Orchestrator kontrolliert werden und Ihnen die Versionskontrolle ermöglichen, jedoch nur für Warteschlangenobjekte, die ausgemustert wurden oder bei einer Anwendung oder Geschäftsausnahme fehlgeschlagen sind.

Fehlgeschlagene oder aufgegebene Elemente können bei Bedarf auch einem Prüfer zugeordnet und jederzeit geändert oder gelöscht werden. Jede dieser Änderungen ist auf der Registerkarte Verlauf im Fenster Prüfdetails nachzuverfolgen. Der Prüfer ist dafür verantwortlich, den aktuellen Status der Transaktionen, für die er zuständig ist, zu überprüfen und den Überprüfungsstatus zu ändern. Der Status der zu überprüfenden Warteschlangenelemente kann auf der Seite Anforderungen überprüfen geändert werden.

Wichtig:

Um sicherzustellen, dass die Verarbeitung von Warteschlangenelementen erfolgreich durchgeführt wird, muss beim Entfernen aus der Warteschlange nach Referenz eine eindeutige Referenz auf Warteschlangenebene festgelegt sein. Wenn die Referenz nicht eindeutig bleibt, führt das zu Problemen beim gleichzeitigen Zugriff, z. B. zu Fehlern, weil keine Transaktionsdaten gefunden werden (Fehlermeldung No Transaction Data ). Wenn die Referenz nicht eindeutig sein kann, ist es ratsam, ohne Referenz aus der Warteschlange zu entfernen.

Schemadefinitionen

Beim Erstellen oder Bearbeiten einer Warteschlange können Sie ein benutzerdefiniertes JSON-Schema für die Spezifischen Daten, Ausgabedaten und/oder Analysedaten hochladen. Wenn die Schemas vorhanden sind, werden alle Transaktionen anhand des angegebenen Formats überprüft, und wenn die resultierenden Daten nicht übereinstimmen, schlägt dieses Element mit einer Geschäftsausnahme fehl.

Wichtig:

• Das Schema wird nicht rückwirkend auf vorhandene Transaktionen angewendet, sondern nur auf welche, die ausgeführt werden, nachdem Sie die Schemas hochgeladen haben.
• Your schema(s) must not contain an array.
• Zu Validierungszwecken wird DateTime als Typ string akzeptiert.
• Use of and validation of an Analytics Data schema requires Robots and Activities of version 19.10 or greater.
• Wenn die hochgeladenen Schemata keine gültige Schemadefinition URIenthalten, wird die draft-07 -Definition wie im folgenden Beispiel als Fallback verwendet.

Hinweis:

Um eine bessere Kontrolle hinsichtlich der Leistung des Orchestrators zu erreichen, ist die Größe der spezifischen Daten von Warteschlangenelementen auf 256.000 Zeichen oder 512.000 Bytes begrenzt. Alles, was über diesen Grenzwert hinausgeht, kann nicht zu einer Warteschlange hinzugefügt werden und gibt den Fehlercode 403 - Payload Too Large zurück. Wenn Sie größere Elemente hochladen müssen, speichern Sie die großen Daten in einem externen Speicher und verweisen Sie nur auf den Link innerhalb des Elements.

Entwurf-07-Schemafelder

Wenn der $schema -URI fehlt oder nicht mit einer erkannten Schemaversion übereinstimmt, überprüft der Orchestrator Warteschlangenelementdaten anhand der Spezifikation des JSON-Schemas für Entwurf 07. In der folgenden Tabelle werden die Felder beschrieben, die Sie in ein Entwurfs-07-Schema aufnehmen können.

Felder auf Stammebene gehören in das Schemaobjekt der obersten Ebene. Felder auf Eigenschaftsebene gehören in jeden Eintrag im properties -Objekt.

Feld	Ebene	Erforderlich	Beschreibung
type: "object"	Stamm	Ja	Deklariert, dass es sich bei den Warteschlangenelementdaten um ein strukturiertes Objekt handelt.
properties	Stamm	Ja	Definiert jedes erwartete Feld und dessen Datentyp.
$schema	Stamm	Nein	URI der JSON-Schemaversion. Wenn er fehlt oder nicht erkannt wird, verwendet der Orchestrator die Entwurfs-07-Validierung.
required	Stamm	Nein	Array von Eigenschaftsnamen, die in jedem Warteschlangenelement vorhanden sein müssen.
additionalProperties	Stamm	Nein	Steuert, ob Eigenschaften, die nicht in properties aufgeführt sind, akzeptiert werden.
type	Eigenschaften	Ja	Gibt den Datentyp des Felds an. Siehe die unterstützten Typen im nächsten Abschnitt.
default	Eigenschaften	Nein	Standardwert für das Feld, wenn nicht angegeben.
examples	Eigenschaften	Nein	Beispielwerte nur zu Dokumentationszwecken.
pattern	Eigenschaften	Nein	Regulärer Ausdruck, mit dem ein string -Wert übereinstimmen muss.
$id	Stamm oder Eigenschaft	Nein	Eindeutiger Bezeichner für das Schema oder eine bestimmte Eigenschaft.
title	Stamm oder Eigenschaft	Nein	Klar lesbare Beschriftung für das Schema oder die Eigenschaft.

Unterstützte Datentypen

Das Feld type in jeder Eigenschaftsdefinition gibt das erwartete Format für den Wert dieses Felds an. Die folgenden Werte sind für Typdefinitionen auf Eigenschaftsebene gültig:

Typ	Beschreibung
string	Textwerte. Verwenden Sie diesen Typ für DateTime -Felder.
integer	Ganze Zahlen ohne Dezimalkomponente.
boolean	true oder false -Werte.
number	Numerische Werte, einschließlich Dezimalstellen.
object	Ein verschachteltes strukturiertes Objekt mit einer eigenen properties -Definition.

Die folgende Vorlage ist ein Beispiel für ein einfaches gültiges Entwurfs-07-Schema mit einem erforderlichen Textfeld:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "fieldName": {
      "type": "string"
    }
  },
  "required": ["fieldName"]
}

Beispiel für das vollständige Schema

Das folgende Beispiel veranschaulicht mehrere Eigenschaftstypen und optionale Felder:

{
  "definitions": {},
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": "http://example.com/root.json",
  "type": "object",
  "title": "The Root Schema",
  "additionalProperties": { "type": "string" },
  "required": [
    "stringTest",
    "intTest",
    "boolTest"
  ],
  "properties": {
    "stringTest": {
      "$id": "#/properties/stringTest",
      "type": "string",
      "title": "The Stringtest Schema",
      "default": "",
      "examples": [
        "stringTest"
      ],
      "pattern": "^(.*)$"
    },
    "intTest": {
      "$id": "#/properties/intTest",
      "type": "integer",
      "title": "The Inttest Schema",
      "default": 0,
      "examples": [
        30
      ]
    },
    "boolTest": {
      "$id": "#/properties/boolTest",
      "type": "boolean",
      "title": "The Booltest Schema",
      "default": false,
      "examples": [
        false
      ]
    }
  }
}

Transaktionsübersicht

Auf der Seite Transaktionen (Transactions) werden die Transaktionen einer bestimmten Warteschlange angezeigt. Sie zeigt auch deren Status, die Termine, an denen sie bearbeitet werden sollten, den Roboter, der sie verarbeitet hat, und den Typ der Ausnahme, die generiert wurde, oder ggf. die zugewiesene Referenz an.

Sie können eine bestimmte Transaktion oder eine Gruppe von Transaktionen entsprechend einem benutzerdefinierten Verweis suchen, der mit der Eigenschaft Verweis (Reference) der Aktivitäten Warteschlangenobjekt hinzufügen (Add Queue Item) und Transaktionsobjekt hinzufügen (Add Transaction Item) hinzugefügt wird. Der Verweis kann dazu verwendet werden, Ihre Transaktionen mit anderen Anwendungen zu verknüpfen, die in einem Automationsprojekt verwendet werden. Des Weiteren ermöglicht Ihnen diese Funktion, bestimmte Transaktionen entsprechend dem angegebenen benutzerdefinierten Verweis in Orchestrator zu suchen.

Bei Transaktionsreferenzen kann auch erzwungen werden, dass sie auf Warteschlangenebene eindeutig sind. Diese Funktion ist beim Erstellen der Warteschlange aktiviert und gilt für alle Transaktionen, außer für gelöschte oder wiederholte. Dies erleichtert die Ermittlung eines bestimmten Objekts und vereinfacht den Reviewprozess.

Wenn auf einen doppelter Verweis beim Hinzufügen von Objekten in eine Warteschlange gestoßen wird, bricht der Job mit dem Status Mit Fehler beendet ab und zeigt die Fehlermeldung Execution error: UiPath.Core.Activities.OrchestratorHttpException: Error creating Transaction. Duplicate Reference. im Fenster Jobdetails an.

Verarbeitungsreihenfolge

Innerhalb einer bestimmten Warteschlange werden die Transaktionen in einer hierarchischen Weise verarbeitet, entsprechend dieser Reihenfolge:

1. Elemente mit einer Frist wie folgt:
   • In der Reihenfolge der Priorität; und
   • Gemäß der festgelegten Frist für Elemente mit der gleichen Priorität.
2. Elemente ohne Frist in der Reihenfolge der Priorität und
   • Gemäß der Regel First In, First Out für Elemente mit der gleichen Priorität.

Wenn Sie eine Deadline oder ein Verschiebungsdatum festlegen, empfehlen wir, die entsprechenden Felder mit relativen Datumsangaben aufzufüllen. Zum Beispiel DateTime.Now.AddHours(2), DateTime.Now.AddDays(10) und DateTime.Now.Add(New System.TimeSpan(5, 0, 0, 0)). Zudem können Sie die US-Notation verwenden, um eine genaue Uhrzeit hinzuzufügen, beispielsweise 10/15/2019 07:40:00. Die automatische Korrektur dieses Datums ist verfügbar, wenn Sie beispielsweise 15 10 2019 9:0 schreiben, wird es automatisch in 15/10/2019 09:00:00 umgewandelt.

Frist ist nützlich, um Aufgaben mit ähnlichen Prioritäten zu ordnen, während Verschieben sicherstellt, dass eine Aufgabe nicht vor der angegebenen Zeit initiiert wird. Die beiden Parameter sollten jedoch nicht zusammen verwendet werden.

Die Datumsangaben, die in den Feldern Frist und Verschieben in Studio hinzugefügt werden, werden im Orchestrator auf der Seite Transaktionen in den Spalten Frist und Verschieben angezeigt.

Transaktionen exportieren

Sie können alle Transaktionen und Informationen zu einer bestimmten Warteschlange in eine CSV- Datei exportieren, indem Sie auf der Seite Transaktionen die Taste Exportieren wählen. Alle Optionen zur Seitenfilterung gelten auch für die generierte Datei.

Abbildung 1. CSV-Datei

Um beste Leistung sicherzustellen, beachten Sie bitte, dass die exportierten Einträge nicht in umgekehrter chronologischer Reihenfolge aufgeführt sind.

Warteschlangen-SLA-Vorhersagen

Mit diesem Tool können Sie eine SLA (Elementfrist) für neu hinzugefügte Elemente in einer Warteschlange festlegen. Auf diese Weise können Sie beurteilen, ob sie zeitgerecht verarbeitet werden können und welche Ressourcen Sie so zuweisen müssen, dass ihre SLA nicht verletzt wird. Wenn die SLA Gefahr läuft, nicht eingehalten zu werden, werden Sie entsprechend benachrichtigt, damit Sie geeignete Anpassungen vornehmen können.

Das SLA gilt nur für die Elemente, für die keine Frist festgelegt ist, d. h., ein neu hinzugefügtes Element ohne zuvor definierte Frist wird automatisch gemäß dem als SLA festgelegten Wert ausgefüllt. Insbesondere wird die Frist jedes Elements durch den Wert dargestellt, der für die Warteschlangen-SLA festgelegt wurde, ab dem Moment, in dem das Element in die Warteschlange hinzugefügt wurde. Wenn ich z. B. die SLA auf 2 Stunden festgelegt habe und 3 Elemente um 16, 17 und 18 Uhr in die Warteschlange einfüge, dann haben meine Elemente die Fristen von 18, 19 bzw. 20 Uhr.

Die Warnung für den SLA-Verstoß wird alle 30 Minuten ausgelöst, beginnend 7 Minuten nach der vollen Stunde.

Elemente mit Frist (entweder in Studio oder in einer CSV-Datei festgelegt, die für den Upload verwendet wird), sind von der SLA-Einstellung nicht betroffen.

Wichtig:

• The Priority of the items added in a queue after enabling SLA predictions is automatically set to High, regardless of how it was set in Studio or in the .csv file used for upload.
• Sie können einen Prozess, der einer Warteschlange mit aktivierten SLA-Vorhersagen zugeordnet ist, nicht löschen.
• If at least one queue item exceeds its deadline, Over Capacity is displayed in the Necessary Robots (SLA) column and predictions are no longer calculated.
• Vorhersagen werden für Warteschlangenelemente mit Fristen in den nächsten 24 Stunden vorgenommen und berücksichtigen nicht die Verschiebedaten der Elemente.

Warteschlangen-Trigger und SLA-Vorhersagen sind in Bezug auf die Warteschlangenprozesszuordnung voneinander abhängig. Wenn Sie also einen konfigurieren, wird der andere vorab ausgefüllt, um eine Parität zwischen den Konfigurationen zu haben. Angenommen ich definiere einen Warteschlangen-Trigger für Warteschlange Y, um Prozess X zu verwenden. SLA-Vorhersagen für Warteschlange Y können nur mit Prozess X gemacht werden, daher ist X vorab aufgefüllt und schreibgeschützt, wenn das Warteschlangen-SLA für Y aktiviert wird.

Risiko-SLA

Sie können auch ein Risiko-SLA für Ihre Elemente definieren, das wie eine Pufferzone vor dem eigentlichen SLA funktioniert. Dabei werden die Risikofristen Ihrer Elemente basierend auf dem Risiko-SLA ab dem Zeitpunkt berechnet, an dem das Warteschlangenelement der Warteschlange hinzugefügt wurde. Angenommen, Sie setzen das Risiko-SLA auf 2 Stunden und fügen 3 Elemente um 16:30, 17:15 und 18:45 Uhr in die Warteschlange ein, dann haben die Elemente die Risikofristen 18:30, 19:15 und 20:45 Uhr.

Nachdem das Risiko-SLA abgelaufen ist und das Warteschlangenelement nicht verarbeitet wurde, besteht die Gefahr, dass die Frist des Elements nicht eingehalten wird. Der Benutzer wird entsprechend benachrichtigt, sodass er geeignete Anpassungen vornehmen kann.

Warteschlangen-SLA-Berechtigungen

Um SLA-Vorhersagen für eine Warteschlange konfigurieren zu können, erhalten Sie die folgenden Berechtigungen:

• Anzeigen für Prozesse
• Anzeigen für Warteschlangen
• Bearbeiten für Warteschlangen (zum Konfigurieren von SLA beim Bearbeiten einer Warteschlange)
• Erstellen für Warteschlangen (zum Konfigurieren von SLA beim Erstellen einer Warteschlange)