Erstellen von Task-E/A- und Write-Back-Verträgen

Erstellen Sie Aufgabeneingabe-, Ausgabe- und Rückschreibverträge in Maestro Case, damit Aufgaben die richtigen Felder lesen und die Case Entität übereinstimmend aktualisieren.

Überblick

Die Zuordnung der Aufgabeneingabe/Ausgabe (E/A) definiert den Datenvertrag zwischen der Fallentität [Demnächst verfügbar] und jeder Aufgabe in einem Fallplan.Die Eingabezuordnung steuert, welche Fallentitätsfelder eine Aufgabe erhält, und die Ausgabezuordnung (Write Back) steuert, welche Fallentitätsfelder eine Aufgabe nach der Ausführung anreichert. Das Erstellen klarer E/A-Verträge stellt sicher, dass jede Aufgabe die richtigen Daten liest, Ergebnisse in die richtigen Felder schreibt und die Fallentität als zuverlässige zentrale Quelle beibehält.

Zielgruppe: Zwischenstufe – Automation Developers und Lösungsarchitekten, die Fallpläne in Studio Web erstellen.

Voraussetzungen

• Zugriff auf Studio Web
• Ein in Studio Web erstelltes Fallprojekt mit mindestens einer Phase und einer definierten Aufgabe. Anweisungen zum Einrichten eines Fallprojekts finden Sie unter „Erstellen eines Fallprojekts “
• Eine Fallentität [Demnächst verfügbar] mit definierten Feldern – entweder als native Data Fabric-Entität, als Virtual Data Object (VDO) oder als Felder, die über einen Fall-Trigger übergeben werden. Weitere Informationen finden Sie in der Übersicht über die Fallentität.
• Vertrautheit mit den unterstützten Aufgabentypen: Menschliche Aktion, RPA, API-Workflow, Connector ausführen, KI-Agent, Maestro Agent-Prozess und untergeordneter Fall.

Schritt 1: Entwerfen des Fallentitätsschemas für E/A

Bevor Sie Aufgabeneingaben und -ausgaben zuordnen, definieren Sie das Fallentitätsschema, um zwischen Feldern zu unterscheiden, die bei der Erstellung des Falls ausgefüllt werden (Eingabefelder), und Feldern, die von Aufgaben während der Verarbeitung geschrieben werden (Ausgabefelder).

Identifizieren von Eingabefeldern

Eingabefelder werden ausgefüllt, wenn der Fall erstellt wird – durch einen Data Fabric-Trigger, ein Connector-Ereignis oder einen API-Aufruf. Diese Felder bieten den Startkontext für alle Aufgaben.

Beispiele für Eingabefelder:

• policyNumber – vom Trigger-System übergeben.
• claimantName – vom Fallersteller bereitgestellt.
• lossDescription – Freitextbeschreibung, die bei der Übermittlung bereitgestellt wird.

Identifizieren von Ausgabefeldern

Ausgabefelder werden im Laufe des Falls von Aufgaben geschrieben. Jedes Ausgabefeld sollte eine einzige besitzende Aufgabe haben, um Schreibkollisionen zu vermeiden.

Beispiele für Ausgabefelder:

• validationResult – geschrieben von einer Connector-Aufgabe „Richtlinie validieren“.
• damageEstimate – geschrieben von einer Agent-Aufgabe „Schaden schätzen“.
• adjusterDecision – erstellt im Rahmen der menschlichen Aufgabe „Schadensregulierer-Überprüfung“.

Dokumentation des Feldbesitzes

Fügen Sie jedem Ausgabefeld eine Anmerkung mit der Aufgabe hinzu, die für das Schreiben verantwortlich ist.Während das Schema nicht die Inhaberschaft zur Runtime erzwingt, verhindert diese Dokumentation versehentliche Kollisionen während des Entwurfs.

{
  "entityName": "AutoInsuranceClaim",
  "fields": {
    "policyNumber":      { "type": "string",  "required": true },
    "claimantName":      { "type": "string",  "required": true },

    "policyValid":       { "type": "boolean", "writtenBy": "Validate Policy" },
    "extractedDetails":  { "type": "object",  "writtenBy": "Extract Details" },
    "damageEstimate":    { "type": "decimal", "writtenBy": "Estimate Damage" },
    "adjusterDecision":  { "type": "string",  "writtenBy": "Adjuster Review",
                           "enum": ["approve", "deny", "investigate_more"] },
    "payoutAmount":      { "type": "decimal", "writtenBy": "Calculate Payout" },
    "paymentReference":  { "type": "string",  "writtenBy": "Issue Payment" }
  }
}

Hinweis:

Verwenden Sie Feldnamen mit Namensbereich (z. B. validation.result vs. categorization.result), wenn mehrere Aufgaben eine strukturell ähnliche Ausgabe erzeugen.Dies vermeidet Mehrdeutigkeit und verhindert das Last-Writer-Wins-Problem.

Schritt 2: Konfigurieren der Eingabezuordnung für eine Aufgabe

Die Eingabezuordnung wählt bestimmte Fallentitätsfelder aus und übergibt sie als Parameter an die Aufgabenimplementierung (Workflow, Formular, Connector oder Agent).Dies bestimmt, welche Daten die Aufgabe sehen kann.

Öffnen des Aufgabenkonfigurationsbereichs

1. Wählen Sie im Fallplan-Designer die Zielphase aus.
2. Wählen Sie die Aufgabe aus, die Sie konfigurieren möchten.
3. Öffnen Sie den Abschnitt Eingabe/Ausgabe des Aufgabenkonfigurationsbereichs.

Zuordnen von Fallentitätsfeldern zu Aufgabenparametern

1. Wählen Sie im Abschnitt Eingabe die Option „Eingabezuordnung hinzufügen“ aus.
2. Wählen Sie für jeden Aufgabenparameter das entsprechende Fallentitätsfeld in der Feldauswahl aus.
3. Wiederholen Sie diesen Vorgang für jeden Parameter, der für die Aufgabe erforderlich ist.

Beispielsweise könnte eine Aufgabe „Belege validieren“ die folgende Eingabezuordnung verwenden:

Aufgabenparameter	Fallentitätsfeld
receipts	caseEntity.lineItems[*].receiptUrl
policyId	caseEntity.department
totalAmount	caseEntity.totalAmount
currency	caseEntity.currency

Nach dem Prinzip der geringsten Berechtigung

Übergeben Sie nur die Felder, die für die Aufgabe erforderlich sind. Vermeiden Sie es, die gesamte Fallentität [Demnächst verfügbar] einer einzigen Aufgabe zuzuordnen.Das Scoping von Eingaben reduziert das Risiko einer unbeabsichtigten Datenoffenlegung und macht den Aufgabenvertrag explizit.

Schritt 3: Konfigurieren der Ausgabezuordnung (Rückschreiben) für eine Aufgabe

Die Ausgabezuordnung nimmt das Ergebnis der Aufgabe auf und schreibt bestimmte Werte zurück in die Fallentität [Demnächst verfügbar]. Dies ist der Rückschreibmechanismus, der die zentrale Quelle bereichert.

Definieren von Ausgabefeldzuordnungen

1. Suchen Sie im selben Abschnitt Eingabe/Ausgabe des Aufgabenkonfigurationsbereichs den Abschnitt Ausgabe.
2. Wählen Sie „Ausgabezuordnung hinzufügen“ aus.
3. Wählen Sie für jedes Ergebnisfeld, das die Aufgabe erzeugt, das Zielfeld der Fallentität aus.

Beispielsweise könnte eine Aufgabe „Belege validieren“ die folgende Ausgabezuordnung verwenden:

Fallentitätsfeld	Aufgabenausgabefeld
caseEntity.validationResult	taskOutput.validationResult
caseEntity.validationStatus	taskOutput.status
caseEntity.invalidReceipts	taskOutput.failedItems

Sicherstellen von „Ein Verfasser pro Feld“

Weisen Sie jedes Ausgabefeld der Fallentität genau einer Aufgabe zu.Wenn zwei Aufgaben in dasselbe Feld schreiben, gewinnt der letzte Schreiber und frühere Daten gehen verloren.

Schützen schreibgeschützter Felder

Felder, die bei der Fallerstellung ausgefüllt werden (z. B. claimantName, policyNumber), sollten niemals als Ausgabenziele angezeigt werden. Ordnen Sie Aufgabenausgaben diesen Feldern nicht zu.

Schritt 4: Überprüfen der Rückschreibkette phasenübergreifend

Sobald die einzelnen Aufgabenzuordnungen vorhanden sind, überprüfen Sie über die Fallentität [Demnächst verfügbar], ob die Daten korrekt von einer Phase zur nächsten fließen.

Verfolgen des Datenflusses

Gehen Sie durch jede Phase und bestätigen Sie:

1. Aufgabe A in Phase 1 liest Eingabefelder aus der Fallentität.
2. Aufgabe A schreibt das Ergebnis über die Ausgabezuordnung in ein bestimmtes Fallentitätsfeld.
3. Der Fallmanager wertet die Phasenregeln aus (zuerst Regeln, Fallback zu Case Manager Agent) mithilfe der aktualisierten Felder der Fallentität.
4. Aufgabe B in Phase 2 liest das Feld, das Aufgabe A geschrieben hat, als eigene Eingabe.

Das Muster folgt dieser Sequenz:

Aufgabe schreibt in Entität → Entitätsstatus ändert sich → Regeln werden bewertet → Nächste Phase wird aktiviert → Downstream-Aufgabe liest aktualisierte Entität

Validieren von Regelabhängigkeiten

Bestätigen Sie für jede Phaseneintritts-, Abschluss-, Austritts- und Wiedereintrittsregel, dass das Fallentitätsfeld, auf das in der IF-Klausel verwiesen wird, mit der Ausgabezuordnung einer vorgelagerten Aufgabe ausgefüllt ist.Wenn eine Regel auf ein Feld verweist, in das keine Aufgabe schreibt, kann die Regel niemals als „true“ ausgewertet werden.

Zum Beispiel:

• Phaseneintrittsregel: IF caseEntity.adjusterDecision == "approve"— Bestätigen Sie, dass die Aufgabe „Schadensregulierer-Überprüfung“ ihre Entscheidungsausgabe caseEntity.adjusterDecision zuordnet.
• Stufenaustrittsregel: IF caseEntity.policyValid == false – Bestätigen Sie, dass die Aufgabe „Richtlinie validieren“ ihr Ergebnis caseEntity.policyValid zuordnet.

Schritt 5: Umgang mit Szenarien für den Wiedereintritt

Standardmäßig wird jede Aufgabe in einer erneut eingegebenen Phase erneut ausgeführt und überschreibt ihre vorherige Ausgabe in der Fallentität. Verwenden Sie das Flag runOnlyOnce„Pro Aufgabe“, um bestimmte Aufgaben von der erneuten Ausführung auszuschließen, wenn ihre vorherige Ausgabe noch gültig ist.

Aufgaben, die beim Wiedereintritt erneut ausgeführt werden sollen

Lassen Sie runOnlyOnce: false (Standard) für Aufgaben, deren Ausgabe sich nach der Nacharbeit ändern kann. Diese Aufgaben werden erneut ausgeführt und überschreiben ihre vorherige Ausgabe in der Fallentität [Demnächst verfügbar].

Beibehalten von Ausgaben der Aufgaben, die nicht erneut ausgeführt werden sollen

Legen Sie runOnlyOnce: true bei Aufgaben fest, deren vorherige Ausgabe noch gültig ist (z. B. eine anfängliche Kategorisierung, die nicht von korrigierten Daten abhängt).Diese Aufgaben werden beim Wiedereintritt übersprungen; ihre Fallentitätsfelder bleiben unverändert.

Aufgabe	runOnlyOnce	Verhalten beim Wiedereintritt
Belege validieren	false (Standard)	Erneut ausführen und überschreiben validationResult
Ausgaben kategorisieren	true	Übersprungen; behält den vorherigen categories Wert bei
Richtlinienlimits überprüfen	false (Standard)	Führt die Richtlinienprüfung erneut aus und überschreibt die Ausgabe

Erwartetes Ergebnis

Nach Ausführen dieser Schritte:

• Jede Aufgabe im Fallplan verfügt über explizite Eingabezuordnungen, die die Daten von der Fallentität [Demnächst verfügbar] umfassen.
• Jede Aufgabe hat explizite Ausgabezuordnungen, die Ergebnisse in ausgewiesene Felder der Fallentität zurückschreiben.
• Jedes Ausgabefeld der Fallentität hat eine einzige besitzende Aufgabe, wodurch Schreibkollisionen verhindert werden.
• Phasenregeln verweisen auf Felder der Fallentität, die vorgelagerte Aufgaben zuverlässig ausfüllen.
• Das Wiedereintrittsverhalten ist so konfiguriert, dass Aufgaben je nach Bedarf eine neue oder beibehaltene Ausgabe erzeugen.
• Die Fallentität dient während des gesamten Falllebenszyklus als zentrale Quelle.

Anwendungsbeispiel

Szenario: Verarbeitung von Kfz-Versicherungsansprüchen mit vier Stufen – FNOL-Aufnahme, Untersuchung, Bewertung und Abrechnung.

Phase	Aufgabe	Eingabe (aus Fallentität [In Kürze verfügbar] )	Ausgabe (an Fallentität)
FNOL-Aufnahme	Richtlinie validieren	policyNumber	policyValid
FNOL-Aufnahme	Details extrahieren	lossDescription, photos	extractedDetails
Untersuchung	Fotos analysieren	photos, vehicleInfo	photoAnalysis
Untersuchung	Feldinspektion	claimId, vehicleInfo, lossDescription	fieldInspection
Bewertung	Schaden schätzen	photoAnalysis, fieldInspection, extractedDetails	damageEstimate
Bewertung	Überprüfung durch Schadensregulierer	damageEstimate, photoAnalysis, policeReport	adjusterDecision
Abrechnung	Auszahlung berechnen	damageEstimate, policyNumber	payoutAmount
Abrechnung	Zahlungsauftrag erteilen	payoutAmount, claimantName	paymentReference
Abrechnung	Anspruchsteller benachrichtigen	claimantEmail, payoutAmount, paymentReference	–

In diesem Beispiel verbraucht die Aufgabe „Schaden schätzen“ in der Bewertungsphase drei Felder, die von vorgelagerten Aufgaben in früheren Phasen geschrieben wurden (photoAnalysis, fieldInspection, extractedDetails). Der Fallmanager verwendet adjusterDecision – geschrieben von der Aufgabe „Schadensregulierer-Überprüfung“ – um die Eintrittsregel der Abwicklungsphase auszuwerten.

Code Snippet

Das folgende JSON zeigt eine vollständige E/A-Zuordnungskonfiguration für zwei Aufgaben in der FNOL-Aufnahmestufe:

{
  "stage": "FNOL Intake",
  "tasks": [
    {
      "name": "Validate Policy",
      "type": "connector",
      "required": true,
      "runOnlyOnce": false,
      "input": {
        "policyNumber": "caseEntity.policyNumber"
      },
      "output": {
        "caseEntity.policyValid": "taskOutput.isValid"
      }
    },
    {
      "name": "Extract Details",
      "type": "agent",
      "required": true,
      "runOnlyOnce": true,
      "input": {
        "description": "caseEntity.lossDescription",
        "photos": "caseEntity.photos"
      },
      "output": {
        "caseEntity.extractedDetails": "taskOutput.structuredData"
      }
    }
  ]
}

Fehlersuche und ‑behebung

Symptome	Wahrscheinliche Ursache	Resolution
Nachgelagerte Aufgabe erhält leere oder NULL-Eingaben	Die Zuordnung der Ausgabe einer vorgelagerten Aufgabe füllt das erwartete Feld „Fallentität“ nicht aus	Überprüfen Sie, ob die Ausgabezuordnung der vorgelagerten Aufgabe auf den richtigen Feldnamen der Fallentität ausgerichtet ist.
Die Phasenregel wird nie als „true“ ausgewertet	Das Fallentitätsfeld, auf das in der Regel verwiesen wird, wird von keiner Aufgabe geschrieben	Fügen Sie dem referenzierten Feld eine Ausgabezuordnung der verantwortlichen Aufgabe hinzu.
Aufgabe überschreibt Daten, die von einer anderen Aufgabe geschrieben wurden	Zwei Aufgaben weisen ihre Ausgabe demselben Fallentitätsfeld zu	Weisen Sie jeder Aufgabe ein eindeutiges Fallentitätsfeld zu. Verwenden Sie Feldnamen mit Namensbereichen, um Kollisionen zu vermeiden.
Der Wiedereintritt erzeugt veraltete Ergebnisse	Die Aufgabe hat runOnlyOnce auf true festgelegt, aber ihre Ausgabe hängt von korrigierten Daten ab.	Legen Sie runOnlyOnce auf false fest für Aufgaben, die aktualisierte Daten erneut validieren oder erneut verarbeiten müssen.
Das schreibgeschützte Feld wird während der Verarbeitung überschrieben	Eine Aufgabenausgabezuordnung hat ein Feld zum Ziel, das nicht veränderbar sein sollte (z. B. policyNumber)	Entfernen Sie die Ausgabezuordnung. Stellen Sie sicher, dass reine Eingabefelder niemals als Ausgabeziele verwendet werden.
Die Ausführung des agentischen Fallmanagers ist erfolgreich, aber es werden keine Aufgaben ausgelöst	Die Ausgabe des Agents entspricht nicht der erforderlichen caseManagerDecisions.tasksToRun -Form (z. B. einem einfachen Array von Aufgabennamen)	Stimmen Sie den genauen Vertrag im Eingabe- und Ausgabevertrag des Case Managers ab.

Diese Warnung wird im Abschnitt Ausgaben der Eigenschaften der Case Manager-Agent-Aufgabe angezeigt, wenn caseManagerDecisions fehlt oder nicht das richtige Wertformat zurückgibt. Die genaue zu verwendende Form finden Sie im Eingabe- und Ausgabevertrag für den Case Manager .

Einschränkungen

• Variablenfilterung in der Überwachungsansicht gilt nur für Instanzen, die ausgeführt werden, nachdem Sie den Filter aktiviert haben. Vorhandene Instanzen werden nicht rückwirkend gefiltert.
• Die writtenBy-Anmerkung im Entitätsschema ist eine Entwurfszeit-Konvention für Dokumentationszwecke. Maestro erzwingt keine Single-Writer-Regeln zur Runtime.
• Die Kontrolle des Zugriffs auf Feldebene für die Fallentität [In Kürze verfügbar] ist in dieser Vorschauversion nicht verfügbar.Alle Aufgaben mit Ausgabezuordnungen zu einem Feld können in dieses schreiben.

Nächste Schritte

• Konfigurieren von Phasenregeln – Erfahren Sie, wie Sie Fallentitätsfelder in Regeln für Eintritt, Abschluss, Austritt und Wiedereintritt verwenden.
• Konfigurieren Sie das Verhalten beim Wiedereintritt – Definieren Sie, welche Aufgaben erneut ausgeführt werden, wenn ein Fall zu einer zuvor abgeschlossenen Phase zurückkehrt.
• Übersicht über die Fallentitäten – Machen Sie sich vertraut mit den drei sofort einsetzbaren Datenobjekten (Fallentität [demnächst verfügbar], Falldokumente, Fallkommentare) und erfahren Sie, wie Sie Daten in einen Fall importieren.
• Referenz zu Aufgabentypen – Überprüfen Sie alle unterstützten Aufgabentypen und deren Konfigurationsoptionen.