Konzept: Richtlinien für Integrationsgeschäftsprozesse

Administrator Guide

Übersicht

Ein Integrationsgeschäftsprozess ist ein konfigurierbarer Workflow, der die mit der Ausführung einer Integration verbundenen Aufgaben für den Datenaustausch zwischen Workday und externen Endpunkten orchestriert. Er verwendet die Geschäftsprozessart

Integration Process Event

, die eine komplexere Verarbeitung als nur einen einfachen Integrationsstart ermöglicht. Siehe: Konzept: Integrationsgeschäftsprozesse.

Dies sind die Abschnitte in diesem Thema:

Allgemeine Geschäftsprozess-Workflows und Richtlinien

Workflow-Schritte

Integration

Benachrichtigungen

Probleme und Lösungen

Unterprozesse

Sie können eine Integration in einen anderen Geschäftsprozess einbetten, indem Sie den Schritt Integration zur Definition dieses Geschäftsprozesses hinzufügen. Wenn der übergeordnete Geschäftsprozess diesen Schritt erreicht, startet er das angegebene Integrationsprozessereignis als Untergeschäftsprozess.

Voraussetzungen

Siehe: Geschäftsprozess für Integration erstellen.

Prozessinitiatoren

Ein Integrationsgeschäftsprozess kann auf verschiedene Arten initiiert werden:

Manuell

Ein Benutzer mit entsprechenden Berechtigungen kann die Integration direkt über den Bericht

View Integration System

oder über die Aufgabe

Launch/Schedule Integration

starten.

Geplant

Sie können die Integration über die Aufgabe

Integration starten/planen

so planen, dass sie zu einem bestimmten Zeitpunkt oder wiederkehrend ausgeführt wird.

Als Untergeschäftsprozess

Der Geschäftsprozess „Integration“ kann von einem Schritt in einem anderen Workday-Geschäftsprozess aus initiiert werden (Beispiel: Ausführung einer E-Verify-Integration nach dem Geschäftsprozess

Complete Form I-9

Einschränkungen

Das Integration Business Process-Framework ist flexibel, die zugrunde liegende Integrationstechnologie weist jedoch bestimmte Einschränkungen auf.

Webservicestart

: Beim Start einer Integration über den

Launch_Integration

oder

Launch_EIB

Für Webservicevorgänge können Sie keine bestimmte organisationsspezifische Version des Geschäftsprozesses angeben. Die oberste Definition (Standard) für dieses Integrationssystem wird verwendet.

Dateigrößenlimit für Dokumentabruf

: Eingehende Dateien haben ein Limit von 1 GB für XML und 300 MB für XLSX. Siehe: Referenz: Integrationen und Webservice-Limits.

Allgemeine Geschäftsprozess-Workflows und Richtlinien

Pfad 1: Standard-Integrations-Workflow: Standardmäßig besteht das
Integrationsprozessereignis
aus zwei grundlegenden Schritten:
A: Initiierung
>
B: Service (Field Integration)

Der Schritt
Service (Fire Integration)
führt das Integrationssystem selbst aus. Bei einer ausgehenden Integration wird die Ausgabedatei generiert. Bei einer eingehenden Integration werden Daten in Workday geladen.
Pfad 2: Ausgehende Integration mit Genehmigung: Dieser Workflow ist gängig, wenn ein Benutzer Daten prüfen muss, bevor diese an Workday gesendet werden.
A: Initiierung
>
B: Genehmigung
>
C: Service (Fire Integration)
>
D: Service: Document Delivery

Nach der Genehmigung wird der
Serviceschritt (Fire Integration)
ausgeführt, der die Daten aus Workday extrahiert und die Ausgabedatei generiert.

Der Schritt
Service: Document Delivery
übermittelt die generierte Datei an den externen Endpunkt, z. B. einen SFTP-Server.
Pfad 3: Inbound Integration Workflow: Dieser Workflow ist ein Standard-Workflow, um Daten aus einer externen Quelle in Workday zu übertragen.
A: Initiierung
>
B: Service: Dokumentabruf
>
C: Service (Fire Integration)

Der Schritt
Service: Document Retrieval
ruft eine Datei aus einer externen Quelle (z. B. einem FTP-Server) ab oder leitet eine Aufgabe an einen Benutzer weiter, um eine Datei manuell hochzuladen.

Der Schritt
Service: Fire Integration
führt die Integration aus, verwendet die abgerufene Datei und lädt die Daten in Workday.
Pfad 4: Verketteter Integrations-Workflow: Dieses Muster ist hilfreich, wenn die Ausgabe einer Integration die Eingabe für eine andere Integration ist.
A: Initiierung
>
B: Integration
>
C: Integration

Der erste
Integrationsschritt
triggert die Ausführung des ersten Integrationssystems (z. B. einen EIB oder eine Studio-Integration) und erstellt eine Ausgabedatei.

Der zweite
Integrationsschritt
triggert ein zweites Integrationssystem, das die Ausgabedatei der ersten Integration nutzt.

Workflow-Schritte

Initiierung: Reihenfolge
A (Erster Schritt)
Durchgeführt von
Der Benutzer oder das System, der die Integration startet. Dies kann ein Integrationssystembenutzer (ISU) für geplante oder vom System getriggerte Ereignisse oder ein interaktiver Benutzer für manuelle Starts sein.
Sicherheitsdomäne nach Rolle
ISU oder Integrationsadministrator, der die Integration startet: "Ändern"/"Put"
-Zugriff auf Integration Build
, Integration Configure
, Integration Debug
, Integration Event
.
Best Practices
Der Schritt
Initiierung
ist ein obligatorischer erster Schritt für alle Geschäftsprozesse. Er kann nicht entfernt werden. Er dient als Eingabepunkt und Auditdatensatz für den startenden Prozess.
Beispiel:
Ein HR Administrator navigiert zur Aufgabe
Integration starten/planen
und klickt auf "
OK
", um einen Export für neue Einstellungen in einen externen Zusatzleistungsanbieter auszuführen. Diese Aktion schließt den Schritt
Initiierung
ab und startet den Geschäftsprozess-Workflow.

Schrittarten

Hier sind die allgemeinen Schrittarten, die Sie zu einem Integrationsgeschäftsprozess hinzufügen können.

Genehmigung: Reihenfolge
Kann nach dem Schritt
Initiierung
an einer beliebigen Stelle platziert werden. Beispielsweise können Sie ihn nach einem Schritt
Integration
triggern, aber vor einem Schritt
Dokumentenübermittlung
platzieren.
Durchgeführt von
Angegebene Sicherheitsgruppe (z. B. HR Partner, Compensation Administrator, Manager).
Sicherheitsdomänen
ISU, Integration Administrator oder Business Process Administrator: "Ändern"/"Put"
-Zugriff auf das Integrationsereignis "
".
Angeben
Sie müssen die Sicherheitsgruppe(n) angeben, die für die Genehmigung zuständig sind.
Bedingungsregel

Anwendungsfall: Erzwingen Sie, dass ein Manager eine Datei mit Mitarbeiterbonusdaten prüft und genehmigt, bevor sie an den Entgeltabrechnungsanbieter übermittelt wird.
Best Practice: Verwenden Sie Bedingungsregeln, um Genehmigungen nur bei Bedarf zu triggern. Beispielsweise können Sie eine Regel erstellen, die den Genehmigungsschritt überspringt, wenn der Gesamtbetrag für den Bonus unter einer bestimmten Schwelle liegt.
Beispiel: Im Genehmigungsschritt wird eine Bedingungsregel konfiguriert, die prüft, ob das Feld „Bonusbetrag gesamt“ in der Integrationsausgabe größer als 50.000 USD ist. Ist dies der Fall, wird der Schritt zur Genehmigung an die Sicherheitsgruppe „Compensation Administrator“
weitergeleitet. Andernfalls wird der Schritt übersprungen.

Anwendungsfälle, Best Practices und Beispiel für Schrittarten:

Anwendungsfall: Sicherstellen der Datengenauigkeit bei sensiblen ausgehenden Integrationen wie Entgeltabrechnung oder Aktienzuteilungen.
Best Practice: Weisen Sie Genehmigungen einer rollenbasierten Sicherheitsgruppe und nicht einem bestimmten benannten Benutzer zu, um Prozessverzögerungen aufgrund von Abwesenheiten von Mitarbeitern zu vermeiden.
Beispiel: Vor der Bereitstellung einer Datei mit Führungskräftevergütungsänderungen an ein externes System wird ein
Genehmigungsschritt
an die Sicherheitsgruppe „Executive Compensation Administrator“
weitergeleitet, um die Daten zu validieren.

Service: Reihenfolge
Kann nach
der Initiierung
an einer beliebigen Stelle platziert werden. Die Reihenfolge ist kritisch. Bei einer eingehenden Integration muss
der Dokumentabruf
erfolgen, bevor
Sie die Integration triggern
. Für ein ausgehendes Element muss
Trigger-Integration
vor
der Dokumentübermittlung
erfolgen.
Durchgeführt von
Integrationssystembenutzer (ISU)
Sicherheitsdomänen nach Rolle
ISU: "Ändern/Put"
-Zugriff auf Integration Build
, Integration Configure
.
Angeben
Sie müssen den auszuführenden Service angeben:
"Dokumentabruf"
,
"Dokumentübermittlung"
oder
"Integration triggern"
.
Bedingungsregel

Anwendungsfall: Bei einer Integration, die täglich ausgeführt wird, müssen Sie eine Datei möglicherweise nur am ersten Tag der Woche abrufen.
Best Practice: Verwenden Sie Bedingungsregeln für Schritte bei
der Dokumentübermittlung
, um zu verhindern, dass leere Dateien gesendet werden. Sie können eine Regel erstellen, die prüft, ob die Anzahl Datensätze für das Integrationsereignis größer als 0 ist.
Beispiel: Eine Bedingungsregel in einem Schritt
Dokumentenübermittlung
prüft ein berechnetes Feld, das die Anzahl der vom Schritt
Integration triggern
verarbeiteten Datensätze zählt. Der Übermittlungsschritt wird nur ausgeführt, wenn die Anzahl größer als 0 ist. Dadurch wird verhindert, dass das System eine leere Datei an den Anbieter sendet.

Überlegungen zu Schrittarten

Dokumentabruf: Wird in eingehenden Integrationen verwendet, um eine Datei aus einer externen Quelle (wie einem SFTP-Server) abzurufen.
Integration triggern: Dies ist der zentrale Schritt, mit dem das Hauptintegrationssystem ausgeführt wird. Entweder wird eine Ausgabedatei generiert (ausgehend) oder Daten werden in Workday geladen (eingehend).
Dokumentübermittlung: Wird in ausgehenden Integrationen verwendet, um eine generierte Datei an ein externes Ziel zu senden (z. B. einen SFTP-Server oder einen Webservice-Endpunkt).

Aktion: To-do: Reihenfolge
Sie können überall im Prozess platziert werden, wo eine manuelle Aktion oder Anweisung erforderlich ist.
Durchgeführt von
Angegebene Sicherheitsgruppe oder einen angegebenen Benutzer.
Sicherheitsdomänen
ISU, Integration Administrator oder Business Process Administrator: "Ändern"/"Put"
-Zugriff auf das Integrationsereignis "
".
Bedingungsregel
Hilfreich, um ein manuelles Eingreifen nur bei Bedarf zu triggern. Beispielsweise könnte eine Regel prüfen, ob der Status des Integrationsereignisses "
Abgeschlossen mit Warnungen
" lautet, was eine
To-do
für einen Administrator triggert, um die Warnungen zu prüfen.
Anwendungsfälle, Best Practices und Beispiele für Schrittarten

Anwendungsfall: Benachrichtigung eines Administrators, damit dieser eine manuelle Aufgabe außerhalb von Workday ausführt oder Daten in Workday nach einem Prozessschritt verifiziert.
Best Practice: Machen Sie die Anweisungen im
To-do-
Schritt klar und umsetzbar. Fügen Sie nach Möglichkeit Links zu relevanten Berichten oder Aufgaben ein.
Beispiel: Ein Inbound EIB lädt neue externe Mitarbeiter. Ein
To-do
-Schritt ist so konfiguriert, dass er nach dem Schritt
Service - Integration
ausgelöst wird. Er ist der Gruppe „HRIS Analyst“
mit der Anweisung zugewiesen: „Externe Mitarbeiter geladen. Führen Sie den Bericht "Audit-Neueinstellungen" aus, um ihre Daten zu prüfen und fehlende Lokalisierungen abzuschließen.

Integration

Mit dieser Schrittart können Sie ein weiteres, separates Integrationssystem innerhalb des aktuellen Geschäftsprozesses starten. Auf diese Weise verketten Sie Integrationen.

Reihenfolge: Kann nach dem Schritt
Initiierung
an einer beliebigen Stelle platziert werden.
Durchgeführt von: Integrationssystembenutzer (ISU)
Angeben: Sie müssen das Integrationssystem auswählen, das als Unterprozess gestartet werden soll.
Bedingungsregeln mit Anwendungsfällen, Best Practices und Beispielen: Anwendungsfall: Nach der Ausführung einer ausgehenden Hauptintegration möchten Sie eine zweite Integration ausführen, um die generierte Datei an einem langfristigen Speicherort zu archivieren. Die ist aber nur möglich, wenn die erste Integration erfolgreich war.

Verwenden Sie eine Bedingungsregel, um den Status eines vorherigen Schritts (
Integration triggern
) zu prüfen, um sicherzustellen, dass er erfolgreich abgeschlossen wurde, bevor Sie eine nachfolgende Integration starten, die von seiner Ausgabe abhängig ist.

Beispiel: Ein
Integrationsschritt
ist für den Start einer „Archive Integration“ konfiguriert. Eine Bedingungsregel in diesem Schritt prüft den Status des vorherigen Schritts
Integration
triggern. Die Archivintegration wird nur ausgeführt, wenn der Status des vorherigen Schritts "
Abgeschlossen
" lautet.; Anwendungsfall: Sie möchten eine Datei abrufen, ohne eine Integration zu starten, oder eine Integration starten, ohne eine Datei bereitzustellen.

Verwenden Sie eine Bedingungsregel, die immer als falsch evaluiert wird. Beispiel: „1=2“ für den Schritt, der übersprungen werden soll.
Anwendungsfälle für Schrittarten: Anwendungsfall (Data Enrichment): Bei einer anfänglichen Integration werden grundlegende Mitarbeiterdaten extrahiert. Ein zweiter
Integrationsschritt
ruft eine andere Integration auf, die die Erstausgabe verwendet, Daten aus einer anderen Quelle (z. B. einem benutzerdefinierten Bericht) hinzufügt und eine endgültige, erweiterte Datei erstellt.
Anwendungsfall (Prozessorchestrierung): Nachdem ein Inbound EIB Neueinstellungen geladen hat, könnte ein
Integrationsschritt
eine Outbound Integration triggern, um Konten für diese Neueinstellungen in einem externen IT-System zu provisionieren.
Anwendungsfall (Umleitung von Fehlern): Wenn ein Integrationsschritt fehlschlägt, leiten Sie die fehlgeschlagene Integration an bestimmte Benutzer weiter, anstatt den Geschäftsprozess automatisch zu beenden.
Konfigurieren Sie Sicherheitsgruppen mit
Umleitungs-
Berechtigungen in der Geschäftsprozess-Sicherheitsrichtlinie.
Verwenden Sie die mögliche Aktion
Umleitung verwalten
für den Schritt
Integration
der Geschäftsprozessdefinition.
Wählen Sie eine oder mehrere Umleitungsaktionen und wählen Sie eine oder mehrere Sicherheitsgruppen, die den Umleitungsschritt erhalten sollen.
Beispiel für Schrittart: Der Geschäftsprozess wird gestartet und im ersten Schritt,
Service (Fire Integration)
, wird die Integration
PayData Extract
ausgeführt, die eine Datei mit Rohdaten der Entgeltabrechnung generiert. Der nächste Schritt,
Integration
, wird für den Start der Integration
der Entgeltdatentransformation
konfiguriert. Diese zweite Integration soll die Datei aus der ersten Integration übernehmen, sie in das vom Anbieter erforderliche XML-Layout neu formatieren und die neue Datei im ausgehenden Wartebereich speichern. Der letzte Schritt,
Service (Dokumentübermittlung)
, stellt die umgewandelte XML-Datei an den Entgeltabrechnungsanbieter bereit.

Benachrichtigungen

Benutzerdefinierte Benachrichtigungen werden durch den endgültigen Status des übergeordneten Integrationsprozessereignisses getriggert. Sie können Benachrichtigungen in der Geschäftsprozessdefinition selbst konfigurieren (z. B. bei Schrittabschluss oder Fehler).

Anwendungsfälle mit Best Practice und Beispiel:

Anwendungsfall (Erfolg): Senden Sie eine E-Mail an das Entgeltabrechnungsteam, in der bestätigt, dass die wöchentliche Abrechnungsschnittstelle erfolgreich generiert und an den Anbieter übermittelt wurde.

Anwendungsfall (Fehler): Wenn eine Integration fehlschlägt, senden Sie eine Benachrichtigung mit hoher Priorität mit den Ereignisdetails und Fehlermeldungen an das Integrationsadministrationsteam, damit das Problem sofort untersucht werden kann.

Best Practice: Verwenden Sie bestimmte rollenbasierte Sicherheitsgruppen (z. B. Integration Administrators
) als Empfänger und nicht als einzelne Benutzer. Erstellen Sie eindeutige und aktionsfähige Benachrichtigungen, die wichtige Informationen enthalten, z. B. den Namen der Integration, die Zeit, in der sie ausgeführt wurde, und einen Link zum Prozessmonitor, um Details zu erhalten.

Beispiel: Eine Integrationsbenachrichtigung wird so konfiguriert, dass sie ausgelöst wird, wenn der Status des Geschäftsprozesses "

Fehlgeschlagen

" lautet. Er sendet eine E-Mail an die Sicherheitsgruppe „Integrationssupport“
. Der E-Mail-Text wird folgendermaßen angepasst: „Die Integration

CCB - Outbound Demografie

ist fehlgeschlagen. Details finden Sie im Prozessmonitor. Ereignis-ID: [Event ID]".

Probleme und Lösungen

Ausgabe	Ursache und Lösung
Der externe Endpunkt empfängt die erwartete Integrationsdatei nicht.	Verwenden Sie die Berichte Prozessmonitor und Vollständiger Prozessdatensatz, um zu ermitteln, welche Elemente nicht wie erwartet funktioniert haben. Siehe Problembehebung für Integrationsprozessereignisse in Konzept: Integrationsgeschäftsprozesse.
Ausgehende Datei wurde nicht an den externen Endpunkt übermittelt.	Ursache: Möglicherweise ist der Geschäftsprozess vor dem Schritt "Dokumentübermittlung" fehlgeschlagen oder der Übermittlungsschritt selbst ist fehlgeschlagen. Lösung: So zeigen Sie den Status und die Fehlermeldungen im Zusammenhang mit dem Fehler an: Suchen Sie im Bericht Prozessmonitor für die Prozessart Integration Ihre Integrationsanforderung. Klicken Sie auf der Seite Hintergrundprozess anzeigen auf Parent Event , welches das Integrationsprozessereignis ist. Auf der Seite Ereignis anzeigen werden in der Tabelle Nachfolgende Prozesse die Integrationsereignisse für die Schritte Integration und Dokument bereitstellen angezeigt. Prüfen Sie den Status und die Fehlermeldungen für beide, um den Fehler zu ermitteln. Überprüfen Sie die Zugangsdaten und die Adresse des Endpunkts in der Übermittlungskonfiguration.
Die eingehende Integration hat keine Daten geladen.	Ursache: Der Schritt "Dokumentabruf" hat die Datei möglicherweise nicht gefunden, die Datei ist möglicherweise leer oder der Schritt "Integration triggern" ist während des Ladens der Daten fehlgeschlagen. Lösung: Stellen Sie sicher, dass sich die Datei am angegebenen externen Speicherort befindet und der Dateiname mit der Konfiguration übereinstimmt. Prüfen Sie den Bericht Integrationsereignisse . Um die Prozessfehlermeldungen im Zusammenhang mit dem Parsing von Dateien oder der Datenvalidierung anzuzeigen, wählen Sie die Spalte Erstellt aus Trigger für das Integrationsereignis.
Ein Genehmigungsschritt wurde falsch weitergeleitet oder übersprungen.	Ursache: Die Bedingungsregel für den Genehmigungsschritt ist möglicherweise falsch konfiguriert oder die Mitglieder der angegebenen Sicherheitsgruppe sind falsch. Lösung: Verwenden Sie den Bericht Geschäftsprozessdefinition anzeigen , um die Bedingungsregellogik des Schritts zu prüfen. Verwenden Sie den Bericht View Security Group , um die Zugehörigkeit zur zugewiesenen Genehmigergruppe zu prüfen.
Die Integration schlägt mit einem Sicherheitsfehler fehl.	Ursache: Dem mit der Integration verknüpften Integrationssystembenutzer (ISU) fehlen Berechtigungen für eine erforderliche Sicherheitsdomäne. Lösung: Prüfen Sie die Fehlermeldung in den Details der Integrationsereignisse , um die geschützten Daten oder Aktionen zu identifizieren. Öffnen Sie den Bericht Domänen-Sicherheitsrichtlinien für funktionalen Bereich, um die relevante Domäne zu suchen und sie zu den Sicherheitsgruppen hinzuzufügen, die dem ISU zugewiesen sind.
Alle Integrationen starten nicht mit folgendem Fehler: „Für die Geschäftsprozessart 'Integrationsprozessereignis' ist keine Standarddefinition vorhanden …	Ursache: Die Standard-Geschäftsprozessdefinition für das Integrationsprozessereignis wurde inaktiviert, gelöscht oder falsch bearbeitet und mit Fehlern gespeichert. Alle Integrationen basieren auf dieser Definition. Lösung: Führen Sie die Geschäftsprozessarten für den Bericht mit Standarddefinitionen in Verwendung aus. Filtern Sie nach der Art Integrationsprozessereignis, um die Definition zu suchen. Prüfen Sie die Definition und stellen Sie sicher, dass sie aktiv ist und mindestens einen Initiierungsschritt und einen Serviceschritt (Fire Integration) enthält. Korrigieren Sie alle Fehler und speichern Sie.
Benachrichtigungen zu Integrationsgeschäftsprozessen sind konfiguriert, werden jedoch nicht per E-Mail übermittelt.	Ursache: Die Routing-Regeln für Benachrichtigungen auf Mandantenebene sind nicht für das Senden Integrations-Benachrichtigungen per E-Mail eingerichtet. Lösung: Öffnen Sie die Aufgabe Mandanten-Setup - Benachrichtigungen . Suchen Sie in den Einstellungen für Benachrichtigungsunterart für System die Zeile Integrationen . Setzen Sie die Routing-Regel für Benachrichtigungen auf E-Mail/Sofort oder eine andere geeignete, für E-Mail aktivierte Regel.
Eine verkettete Integration (über einen Integrationsschritt gestartet) schlägt fehl, wodurch der gesamte übergeordnete Geschäftsprozess beendet wird.	Ursache: Dies ist das geplante und erwartete Verhalten in Workday. Wenn ein Schritt in einem Geschäftsprozess, einschließlich eines Integrationsschritts , fehlschlägt, wird der Prozess standardmäßig angehalten, um weitere Fehler zu verhindern. Lösung: Dies ist kein zu korrigierender Fehler, sondern ein zu verwaltendes Verhalten. Stellen Sie sicher, dass die untergeordnete Integration über eine robuste Fehlerbehandlung und eigene spezifische Benachrichtigungen verfügt. Prüfen Sie den übergeordneten Prozess, um festzustellen, ob die untergeordnete Integration wirklich kritisch ist. Ist dies nicht der Fall, muss der Prozess möglicherweise entkoppelt und als separater geplanter Prozess ausgeführt werden, anstatt verkettet zu werden.
Ein Integrationsschritt in Studio mit Fehlern wird nicht umgeleitet, auch wenn er mit "Umleitung verwalten" konfiguriert wurde.	Ursache: Derzeit funktioniert das Feature "Umleitung verwalten" nur für Integrationen in Studio, die mit dem Status " Fehlgeschlagen " abgeschlossen werden. Wenn eine Integration in Studio mit dem Status " Abgeschlossen mit Fehlern " abgeschlossen wird, wird dies von der Funktionalität zum Verwalten der Umleitung nicht als Fehler betrachtet. Lösung: Dies ist kein zu korrigierender Fehler, sondern ein zu verwaltendes Verhalten. Stellen Sie sicher, dass die Integration über eine robuste Fehlerbehandlung und eigene spezifische Benachrichtigungen verfügt. Siehe: Umleitung für Geschäftsprozessschritte konfigurieren.