# Workflows entwickeln ### Variablen und Parameter Kundenspezifische Konfigurationswerte, Instanzspezifische Einstellungen, übergebene Werte aus externen Prozessen und Authentifizierungsdaten stehen in Workflows als Variablen zur Verfügung. Wir unterscheiden nach folgender Logik | output.xxxxx | Variablen, die innerhalb eines Workflows generiert wurden | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | parameter.xxxx | Variablen, die außerhaklb des workflows generiert und im Workflow bereitgestellt wurden (z.B. über die Komponente “Workflow-Trigger” oder über Events) | | preset.xxxxx | Variablen, die über eine Sales Channel Management App erfasst wurden und im Workflow zur Verfügung stehen (kundenindividuelle Werte) | | auth.xxxx | Kundenspezifische Authentifizierungsdaten | Variablen ermöglichen es dir ,identische Workflows instanzspezifisch auszuführen und Workflows weitreichend zu dynamisieren. Tipp: Definiere für die Entwicklung alle benötigten Variablen am Beginn des Workflows über die Zuordnungskomponente. Diese können dann später in einem Arbeitsschritt als Felder in die SCMA eingefügt und so kundenindividuell bereitgestellt werden ### Umgang mit Variablen Variablen loggen Zu Beginn des Customizings sollten die benötigten Variablen aus dem Elternprozess geloggt werden.
Variablen zu Beginn des Workflows definieren Um den Zugriff auf die benötigten Variablen zu vereinfachen, können diese zu Beginn eines Workflows mit Hilfe der Zuordnungskomponente in eine eigene Variable überführt werden (z.B. “order\_mapped > CustomOrderMapped”) So steht die Variable immer als automatischer Vorschlag in Inputfeldern zur Verfügung und man spart sich die manuelle Dot.Notation ### Komponenten dokumentieren #### Labels für Komponenten Bitte unbedingt sprechende Labels für alle verwendeten Komponenten verwenden, idealerweise immer mit Angabe der jeweiligen Funktion. Vorschlag als Standard: “\[AKTION] Variable” **Beispiele** * \[LOG] Mapped Order * \[IF] Feld A = ABC #### Beschreibung für Komponenten Wo nötig Komponenten kurz extra beschreiben. Das macht vor allem bei logischen Operatoren Sinn, insbesondere bei Verzweigungen. ### Eltern-Kind-Prozesse Eine sinnvolle Architektur eurer Integration ist Grundvoraussetzung für hohe Stabilität und Performance auch bei großen Datenmengen. Essentiell ist es dabei, das nicht ein Workflows alle Aufgaben eines Datenaustausches erfüllt, sondern dass die Umsetzung modular und hierarchisch organisiert erfolgt. Xentral Connect bietet euch dazu die Möglichkeit Workflows aus anderen Workflows heraus zu starten und so eine Eltern-Kind-Logik abzubilden. Diese Verschachtelung kann analog auch in der Workflow-Übersicht abgebildet werden. Verschachtelungen von Workflows eignen sich z.B. um
* Wiederkehrende Workflows aus verschiedenen Elternprozessen aufzurufen * Listen mit Items zu iterieren und einen Kindprozess pro Element zu starten * Lange, komplexe Workflows in mehrere überschaubare Prozessschritte zu unterteilen.
Die Arbeit mit internen Prozesstriggern bietet dir eine große Flexibilität in der Workflowgestaltung und ist essentiell für ein skalierbares, performantes Workflow-Design. Über die Komponenten im Workflow-Designer hast du zudem die Möglichkeit Variablen aus Elternprozessen an Kindprozesse zu übergeben und in Elternprozessen auf den Response eines Kindprozesses zu warten. ### Interne und externe Events Xentral Connect ist durch die nahtlose Integration auf Basis von Auth0 in der Lage, direkt auf die in Xentral produzierten Kafka-Events zu reagieren. Ziel der Standardintegrationen ist es einen Datenaustausch wo möglich in Echtzeit oder nahe Echtzeit anzubieten. Dazu bietet der Workflow-Designer 3 verschiedene Möglichkeiten
* Externe Events um auf definierte Ereignisse in Xentral zu reagieren * Interne Events um innerhalb von Connect Events produzieren und konsumieren zu können * Webhooks, um in Echtzeit auf Ereignisse in externen Systemen reagieren zu können Die Verwendung von eventbasierten Triggern zum Auslösen von Connect-Workflows bietet verschiedene Vorteile und ist daher als grundlegendes Trigger-Prinzip zu empfehlen.
* keine zeitlichen Verzögerungen * Direkte Nachvollziehbarkeit * Sparsamer Ressourceneinsatz ### Content Identifier und Case identifier #### Case Identifier Am Anfang eines Workflows sollte immer ein Case Identifier gesetzt werden. Dieser sollte analog zum Elternprozess einen sprechenden Identifier enthalten, z.B. die SKU oder die External Order Number **Beispiel:**\ Case Identifier: {{parameter.mapped\_order.orderHeader.externalOrderNumber}} #### Content Identifier Content Identifier sollten immer gesetzt werden. Diese sollten immer einen aussagefähigen Status des Workflows abbilden. Insbesondere sollte man erkennen können bis zu welcher Stelle ein Workflow durchgelaufen ist und ob die gewünschte Transformation durchgeführt wurde. Wenn der Workflow beispielsweise vorzeitig beendet wird (z.B. durch einen Endpunkt in einer Verzweigung) sollte dies immer für einen Content Identifier transparent gemacht werden. Wenn ein Workflow nur in definierten Fällen zu einer Transformation führt sollte direkt erkennbar sein, ob die entsprechende Regel eingetreten ist oder nicht. **Beispiel:** Content Identifier: Workflow erfolgreich. Regel A angewendet ### Hooks Customizations sind eines der zentralen Alleinstellungsmerkmale von Connect. Customizations werden dabei über sogenannte Hook-Elemente ermöglicht, die an sinnvollen Stellen in den einzelnen Workflows eingesetzt werden. Sie ermöglichen es, einen Customizing-Workflow an der durch den Hook definierten Stelle ansetzen zu lassen, der über den Hook auf alle an dieser Stelle des Workflows verfügbaren Datenvariablen Zugriff hat und diese beeinflussen kann. * Alle Standardschnittstellen sollten über entsprechende Hooks in den Workflows individual anpassbar sein * Hooks sollten sinnvoll benannt sein * Hooks sollten vor- und nach einem mapping möglich sein * Dazu sollten an sinnvollen Stellen in den Workflows Hook-Komponenten eingefügt werden. Diese Komponenten sollten klar benannt sein --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://connect.xentral.com/guidelines/workflows-entwickeln.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.