Betriebsausnahme versus Anwendungsausnahme

Es ist wichtig, den richtigen Typ der Ausnahme, mit der eine Transaktion fehlgeschlagen ist, zu wählen, da diese Auswahl beeinflusst, ob Orchestrator (Orchestrator) versucht, die Transaktion des Warteschlangenobjekts erneut auszuführen oder nicht:

• Eine Anwendungsausnahme beschreibt einen Fehler, der durch ein technisches Problem verursacht wird, z. B. eine Anwendung, die nicht reagiert.

  Eine solche Situation ist z. B. ein Projekt, das Telefonnummern aus einer Mitarbeiterdatenbank extrahiert und Warteschlangenelemente für jeden von ihnen erstellt. Diese Elemente werden dann verarbeitet und in eine Finanzanwendung eingefügt. Wenn die Finanzanwendung beim Versuch der Transaktion hängen bleibt, kann der Roboter das Feld, in dem er die Telefonnummer einfügen soll, nicht finden und gibt schließlich einen Fehler aus.

  Solche Probleme können eventuell einfach durch ein Wiederholen der Transaktion gelöst werden, da die Anwendung dann möglicherweise nicht mehr hängt.

• Eine Geschäftsausnahme beschreibt einen Fehler, der darin beruht, dass bestimmte Daten, von denen das Automatisierungsprojekt abhängt, unvollständig sind oder fehlen.

  Eine solche Situation ist z. B. ein Projekt, das Telefonnummern aus einer Mitarbeiterdatenbank extrahiert und Warteschlangenelemente für jeden von ihnen erstellt. Diese Elemente werden dann verarbeitet und in eine Finanzanwendung eingefügt. Wenn in einer bestimmten Telefonnummer aufgrund eines menschlichen Fehlers eine Ziffer fehlt, wird das Warteschlangenelement, das sie enthält, ungültig. Dies bewirkt, dass die Automatisierung eine Ausnahme auslöst, da das Telefonnummer-Feld in der Finanzanwendung kein Warteschlangenelement akzeptiert, das eine unvollständige Nummer enthält.

  Es besteht nicht die Chance, dass das Wiederholen der Transaktion das Problem löst, und es gibt andere bessere Vorgehensweisen, wie z. B. die Benachrichtigung des menschlichen Benutzers über diesen Fehler.

Die Aktivität Transaktionsstatus festlegen (Set Transaction Status) kann verwendet werden, um die Logik Ihres Projekts in einer Weise zu formen, die diese Unterscheidung auf mehrere Arten kapseln:

• Wenn die Aktivität Set Transaction Status bei der Transaktion mit einer Anwendungsausnahme fehlschlägt und die Option Automatische Wiederholung auf der Seite Warteschlange erstellen auf Ja festgelegt ist, wenn die Warteschlange erstellt wird, wird das Warteschlangenelement wiederholt.
• Standardmäßig macht Orchestrator nicht (not) Wiederholungsversuche mit Transaktionen, die aufgrund von Betriebsausnahmen fehlgeschlagen sind. Dies ist deshalb der Falls, weil eine Inkonsistenz zwischen dem Transaktionswert und den geschäftlichen Anforderungen bedeutet, dass es Fehler in den Ausgangsdaten, aus denen die Warteschlangenobjekte erstellt wurden, geben könnte. Zusätzliche Aktionen können eventuell erforderlich sein, um diese Art von Problem zu lösen, und die Protokollierung dieser Art von Ausnahme kann nützlich sein.
• Eine Wenn (If)- oder Flow-Entscheidung (Flow Decision)-Aktivität kann verwendet werden, um unterschiedliche Aktionsabfolgen zu nehmen, wenn eine Transaktion mit einem bestimmten Typ Ausnahme fehlgeschlagen ist, wie mithilfe der Aktivität Protokollmeldung (Log Message) zum Protokollieren einer benutzerdefinierten Meldung oder der Aktivität Nachrichtenbox (Message box) zur Anzeige eines Fensters, das Informationen über das Ereignis enthält.

Nachfolgend sehen Sie ein Beispiel für solch ein Projekt:

Der nachfolgende Screenshot zeigt die Zuordnung der Eigenschaften in der Aktivität Transaktionsstatus festlegen (Set Transaction Status (auf der linken Seite) und deren entsprechende Felder im Fenster Transaktionsdetails (Transaction Details) in Orchestrator.

Der Zweig Wahr (True) der Aktivität Flow-Entscheidung (Flow Decision) setzt den Transaktionsstatus auf Fehlgeschlagen mit einer Betriebsausnahme (Business Exception), während der Zweig Falsch (False) ihn auf Fehlgeschlagen mit einer Anwendungausnahme setzt.