Entwerfen eines persistenten Schemas für eine Fallentität

Überblick

Die Fallentität [in Kürze verfügbar] ist das zentrale, persistente Datenmodell, aus dem jede Phase, Aufgabe und Regel während der gesamten Lebensdauer eines Falls liest und in dieses schreibt. Ein gut gestaltetes Entitätsschema trennt Eingabefelder (Daten, die bei der Fallerstellung bereitgestellt werden) von berechneten Feldern (Daten, die von Aufgaben während der Verarbeitung erzeugt werden) und weist eine klare Feldbezeichnung zu, sodass nicht zwei Aufgaben in dasselbe Feld schreiben. Folgen Sie dieser Anleitung, um ein Schema zu definieren, das Datenkonflikte während des Zurückschreibens verhindert und zuverlässige Phasenregeln unterstützt.

Voraussetzungen

• Zugriff auf Studio Web.
• Ein definierter Geschäftsprozess mit identifizierten Phasen und Aufgaben.
• Vertrautheit mit den Kernkonzepten von Maestro Case.
• Eine Data Fabric-Instanz, die in Ihrer UiPath-Umgebung verfügbar ist (empfohlen für die native Entitätserstellung).

Schritt 1: Verstehen der sofort einsatzbereiten Datenobjekte

Jedes Fallprojekt erstellt automatisch drei Datenobjekte:

Objekt	Zweck
Fallentität [In Kürze verfügbar]	Enthält alle strukturierten Geschäftsdaten, die aus Phasen, Aufgaben und Regeln gelesen und in die geschrieben werden.
Falldokumente	Speichert Anhänge und Dateien, die mit dem Fall verknüpft sind (Belege, Fotos, Verträge).
Fallkommentare	Speichert Hinweise, Anmerkungen und Mitteilungen, die von Fallbearbeitern während des gesamten Lebenszyklus hinzugefügt wurden.

Alle drei teilen sich ein unveränderliches caseID -Systemfeld, das bei der Fallerstellung automatisch generiert wird. Dieses Feld verknüpft alle Falldaten zusammen und kann nicht geändert werden.

Konzentrieren Sie sich beim Schemadesign auf die Fallentität – sie ist die einzige Source of Truth für die gesamte Fallverarbeitungslogik.

Schritt 2: Auswählen, wo die Entität existiert

Bevor Sie Felder definieren, entscheiden Sie, wie Sie die Entität nutzen möchten. Wählen Sie die Option aus, die am besten zu Ihrem Dateneigenschaftsmodell passt:

Quelle	Beschreibung	Einsatzbereich
Nativ in Data Fabric (empfohlen)	Erstellen Sie die Entität als native Geschäftsentität in Data Fabric und verknüpfen Sie sie mit Ihrem Fall.	Neue Prozesse, bei denen Sie das Datenmodell besitzen.
Virtual Data Object (VDO) in Data Fabric	Registrieren Sie eine externe Quelle als VDO in Data Fabric und verknüpfen Sie das VDO mit dem Fall.	Entitätsdaten befinden sich in einem externen System (CRM, ERP) und Sie möchten ohne Duplikate darauf verweisen.
Nutzlast des Falltriggers	Übergeben Sie vorhandene Daten im Trigger der Fallerstellung (z. B. einen API-Connector). Die Nutzlastfelder werden zu Fallfeldern, die über alle Phasen hinweg verfügbar sind.	Einfache Integrationen, bei denen Sie den Fall zum Zeitpunkt der Erstellung hydratisieren.

Schritt 3: Identifizieren und Kategorisieren Ihrer Felder

Zuordnung des vollständigen Falllebenszyklus

Listen Sie jede Phase und jede Aufgabe in Ihrem Fallplan auf. Identifizieren Sie für jede Aufgabe:

• Welche Daten gelesen werden müssen (Eingaben).
• Welche Daten es erzeugt (Ausgaben).

Klassifizieren von Feldern in zwei Kategorien

Trennen Sie jedes Feld in Ihrem Schema in eine von zwei Gruppen:

Kategorie	Definition	Eigenschaften	Beispiele
Eingabefelder	Daten, die bei der Erstellung des Falls bereitgestellt werden, entweder durch eine Trigger-Nutzlast, eine Formularübermittlung oder ein externes System.	Aufgefüllt bei der Erstellung. In der Regel schreibgeschützt nach Hydratisierung. Erforderlich für die anfängliche Weiterleitung und Aufgabenausführung.	policyNumber, claimantName, dateOfLoss, lossDescription
Berechnete Felder	Von Aufgaben während der Fallverarbeitung erzeugte Daten. Diese Felder beginnen leer und werden beim Abschluss der Aufgaben zurückgeschrieben.	Bei Erstellung leer. Geschrieben von einer bestimmten Aufgabe. Wird von nachgelagerten Aufgaben und Regeln verbraucht.	validationResult, damageEstimate, adjusterDecision, paymentReference

Markieren von Eingabefeldern als schreibgeschützt

Eingabefelder wie employeeId, policyNumber oder reportId dürfen niemals von Aufgaben überschrieben werden. Dokumentieren Sie diese Felder in Ihrem Schema als schreibgeschützt, um versehentliche Änderungen während der Verarbeitung zu verhindern.

Schritt 4: Ermittlung der Feldbesitze

Das Feld ist das kritischste Prinzip zur Vermeidung von Datenkonflikten. Jedes berechnete Feld in der Entität muss von genau einer Aufgabe geschrieben werden.

Zuweisen eines Schreibers pro Feld

Bestimmen Sie für jedes berechnete Feld die einzelne Aufgabe, die für das Schreiben darauf verantwortlich ist. Wenn zwei Aufgaben in dasselbe Feld schreiben, gewinnt der letzte Schreiber und vorherige Daten gehen verloren.

Versehen Sie den Besitz in Ihrem Schema mit Anmerkungen

Verwenden Sie eine writtenBy -Anmerkung (oder einen gleichwertigen Kommentar), um zu dokumentieren, welche Aufgabe jedes berechnete Feld besitzt. Während die Plattform diese Anmerkung zur Laufzeit nicht erzwingt, dient sie als Designvertrag, der Konflikte während der Entwicklung verhindert.

Verwenden von Namespace-Feldern zur Vermeidung von Mehrdeutigkeiten

Wenn mehrere Aufgaben ähnliche Ausgabetypen erzeugen, benennen Sie Ihre Felder, um sie unterscheidbar zu halten. Zum Beispiel:

• Verwenden Sie photoAnalysis für die Ausgabe einer Agent-Aufgabe zur Bildanalyse.
• Verwenden Sie fieldInspection für die Ausgabe einer Aufgabe zur menschlichen Feldinstanz.
• Vermeiden Sie ein generisches analysisResult -Feld, um das mehrere Aufgaben konkurrieren könnten.

Schritt 5: Definieren des Schemas

Erstellen der Entität in der von Ihnen gewählten Quelle

Gehen Sie zum Designer für die Fallentität in Studio Web. Erstellen Sie eine neue Entität mit einem beschreibenden Namen, der Ihrer Geschäftsdomäne entspricht (z. B. AutoInsuranceClaim oder ExpenseReport).

Zuerst Eingabefelder hinzufügen

Definieren Sie alle Eingabefelder mit ihren Typen, erforderlichen Flags und allen Standardwerten. Legen Sie required: true für Felder fest, die bei der Fallerstellung vorhanden sein müssen.

Hinzufügen von berechneten Feldern mit Besitzanmerkungen

Definieren Sie alle berechneten Felder mit ihren Typen, legen Sie required: false fest (diese Felder sind bei der Erstellung leer) und versehen Sie jedes mit der Aufgabe, die darin schreibt.

Überprüfen eines Referenzschemas

Folgendes Beispiel veranschaulicht das Muster zwischen Eingabe und Berechnung mit dem Feldbesitz für einen Schadensfall aus einer Autoversicherung:

{
  "entityName": "AutoInsuranceClaim",
  "fields": {
    // --- Input fields (populated by trigger, read-only after creation) ---
    "claimId":            { "type": "string",  "required": true,  "generated": true },
    "policyNumber":       { "type": "string",  "required": true },
    "claimantName":       { "type": "string",  "required": true },
    "claimantEmail":      { "type": "string",  "required": true },
    "dateOfLoss":         { "type": "date",    "required": true },
    "lossDescription":    { "type": "string",  "required": true },
    "vehicleInfo":        { "type": "object",  "required": true },
    "photos":             { "type": "array",   "items": "url" },
    "policeReportNumber": { "type": "string",  "required": false },

    // --- Computed fields (written by tasks during processing) ---
    "policyValid":        { "type": "boolean", "writtenBy": "Validate Policy" },
    "extractedDetails":   { "type": "object",  "writtenBy": "Extract Details" },
    "photoAnalysis":      { "type": "object",  "writtenBy": "Analyze Photos" },
    "fieldInspection":    { "type": "object",  "writtenBy": "Field Inspection" },
    "policeReport":       { "type": "object",  "writtenBy": "Retrieve Police Report" },
    "damageEstimate":     { "type": "decimal", "writtenBy": "Estimate Damage" },
    "adjusterDecision":   { "type": "string",  "enum": ["approve", "deny", "investigate_more"] },
    "payoutAmount":       { "type": "decimal", "writtenBy": "Calculate Payout" },
    "paymentReference":   { "type": "string",  "writtenBy": "Issue Payment" }
  }
}

Schritt 6: Verknüpfen von Eingabe- und Ausgabezuordnungen mit Aufgaben

Nachdem Sie das Schema definiert haben, verbinden Sie es über Eingabe- und Ausgabezuordnungen mit Aufgaben.

Konfigurieren von Eingabezuordnungen

Wählen Sie für jede Aufgabe nur die Felder für die Fallentität aus, die die Aufgabe lesen muss. Dadurch wird gesteuert, welche Daten die Aufgabe sehen kann.

Beispiel – Eingabezuordnung der Richtlinienvalidierung :

"input": {
  "policyNumber": "caseEntity.policyNumber"
}

Konfiguration von Ausgabezuordnungen

Ordnen Sie für jede Aufgabe das Ergebnis der Aufgabe dem spezifischen Feld Entität zu, das die Aufgabe besitzt. Dies ist der Zurückschreibungsmechanismus.

Beispiel – Zuordnung der Ausgabe der Richtlinienaufgabe :

"output": {
  "caseEntity.policyValid": "taskOutput.policyValid"
}

Überprüfen, ob Ausgabezuordnungen die Feldinhaberschaft respektieren

Vergleichen Sie die Ausgabezuordnung jeder Aufgabe mit Ihren Schemaanmerkungen. Bestätigen Sie, dass keine zwei Aufgaben in dasselbe Feld für die Fallentität schreiben.

Schritt 7: Validieren des Schemas anhand von Regeln

Phasenregeln (Eintritt, Abschließen, Beenden, erneuter Eintritt) werden anhand von Fallentitätsfeldern ausgewertet. Vergewissern Sie sich, dass:

• Jedes Feld, auf das in der IF- Klausel einer Regel verwiesen wird, ist im Schema vorhanden.
• Das Feld wird von einer Aufgabe geschrieben, die abgeschlossen wird, bevor die Regel ausgewertet wird.
• Der Feldtyp entspricht dem in der Regel verwendeten Operator (verwenden Sie z. B. keinen Zeichenfolgenvergleich für ein Dezimalfeld).

Beispiel – Eine Austrittsregel in einer Aufnahmephase hängt vom Feld policyValid ab:

WHEN PolicyCheckCompleted event arrives
  IF caseEntity.policyValid == false

Bestätigen Sie, dass die Aufgabe Richtlinie validieren policyValid schreibt und innerhalb der Erfassungsphase abgeschlossen wird, bevor diese Austrittsregel ausgewertet wird.

Erwartetes Ergebnis

Nach Abschluss dieser Schritte haben Sie ein Fallentitätsschema, das:

• Trennt eindeutige Eingabefelder (bei der Fallerstellung ausgefüllt) von berechneten Feldern (von Aufgaben während der Verarbeitung geschrieben).
• Weist explizit den Feldbesitz zu, sodass genau eine Aufgabe in jedes berechnete Feld schreibt.
• Verwendet Namespace-Feldnamen, um Mehrdeutigkeit und Konflikte zu vermeiden.
• Unterstützt ein zuverlässiges Zurückschreiben von Aufgaben in die Entität, sodass nachgelagerte Regeln und Aufgaben genaue und nicht widersprüchliche Daten verbrauchen.
• Dokumentiert den Datenvertrag zwischen dem Fallplan und seinen Aufgaben durch writtenBy -Anmerkungen.

Code-Snippet

Es folgt ein zweites Referenzschema für einen Anwendungsfall für eine Ausgabenberichterstattung, das dasselbe Muster für Eingabe und Berechnung demonstriert:

{
  "entityName": "ExpenseReport",
  "fields": {
    // --- Input fields (populated at case creation) ---
    "reportId":          { "type": "string",  "required": true,  "generated": true },
    "employeeId":        { "type": "string",  "required": true },
    "employeeName":      { "type": "string",  "required": true },
    "department":        { "type": "string",  "required": true },
    "totalAmount":       { "type": "decimal", "required": true },
    "currency":          { "type": "string",  "default": "USD" },
    "lineItems":         { "type": "array",   "items": "ExpenseLineItem" },

    // --- Computed fields (written by tasks during processing) ---
    "validationResult":  { "type": "object",  "required": false, "writtenBy": "Validate Receipts" },
    "categories":        { "type": "array",   "required": false, "writtenBy": "Categorize Expenses" },
    "anomalyFlags":      { "type": "array",   "required": false, "writtenBy": "Flag Anomalies" },
    "managerDecision":   { "type": "string",  "enum": ["approved", "rejected", "needs_info"] },
    "financeDecision":   { "type": "string",  "enum": ["approved", "rejected", "hold"] },
    "paymentRef":        { "type": "string",  "required": false, "writtenBy": "Process Payment" }
  }
}

Fehlersuche und ‑behebung

Problem	Ursache	Resolution
Ein berechnetes Feld enthält unerwartete oder veraltete Daten.	Mehrere Aufgaben schreiben in dasselbe Feld. Der letzte Schreiber überschreibt den vorherigen Wert.	Prüfen Sie Ihre Ausgabezuordnungen. Weisen Sie jedes Feld genau einer Aufgabe zu und verwenden Sie Namespace-Feldnamen.
Eine Regel wird nie als true ausgewertet.	Das Feld, auf das in der IF-Klausel der Regel verwiesen wird, ist zum Zeitpunkt der Auswertung der Regel noch nicht geschrieben.	Stellen Sie sicher, dass die für das Schreiben des Felds verantwortliche Aufgabe innerhalb der aktuellen oder einer vorherigen Phase abgeschlossen wird.
Eine Variable wird nicht im Entitätsselektor angezeigt.	Das Feld ist in der bereitgestellten Version des Schemas für die Fallentität nicht definiert.	Fügen Sie das Feld zum Schema hinzu, veröffentlichen Sie es erneut und stellen Sie den Fallplan erneut bereit.
Eingabefelder werden während der Verarbeitung überschrieben.	Eine Aufgabenausgabezuordnung zielt auf ein Eingabefeld ab.	Entfernen Sie die Ausgabezuordnung, die auf das Eingabefeld abzielt. Dokumentieren Sie Eingabefelder als schreibgeschützt in Ihrem Schema.

Einschränkungen

• Native Unterstützung für Fallentitäten in Data Fabric ist noch nicht verfügbar. Verwenden Sie eine der drei in Schritt 2 beschriebenen Quellenoptionen.
• Die Anmerkung writtenBy ist eine Dokumentationskonvention zur Entwurfszeit. Die Plattform erzwingt keine Einschränkungen für einen einzelnen Schreiber während der Runtime. Entwickler müssen den Feldbesitz durch eine Überprüfung verifizieren.
• Die Unterstützung für Fallbenutzerrollen und den Zugriff (Einschränkung, welche Personen bestimmte Entitätsfelder bearbeiten können) sind noch nicht verfügbar.

Nächste Schritte

• Modellieren von primären und sekundären Phasen – Erfahren Sie, wie Sie Phasenregeln konfigurieren, die Ihre Entitätsfelder nutzen.
• Referenz für Eingabe- und Ausgabezuordnung – Detaillierte Referenz für die Verknüpfung von Entitätsfeldern mit Aufgabenparametern.
• Maestro Fall-Tutorial: Schadensregulierer – End-to-End-Tutorial, das diese Schemadesignprinzipien auf einen vollständigen Fallplan anwendet.