Entwerfen eines persistenten Fallentitätsschemas

Entwerfen Sie ein persistentes Schema für die Fallentität mit Eingabefeldern, berechneten Feldern und Regeln für den Feldbesitz für ein zuverlässiges Zurückschreiben von Maestro Case.

Überblick

Die Fallentität [Demnächst verfügbar] ist das zentrale, persistente Datenmodell, aus dem jede Phase, Aufgabe und Regel während der Lebensdauer eines Falls liest und schreibt.Ein gut gestaltetes Entitätsschema trennt Eingabefelder (Daten, die bei der Erstellung des Falls bereitgestellt werden) von berechneten Feldern (Daten, die von den Aufgaben während der Verarbeitung erstellt werden) und weist einen eindeutigen Feldbesitz zu, sodass keine zwei Aufgaben in dasselbe Feld schreiben. Befolgen Sie diesen Leitfaden, um ein Schema zu definieren, das Datenkollisionen 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 Erstellung nativer Entitäten).

Schritt 1: Verständnis der sofort einsetzbaren Datenobjekte

Jedes Fallprojekt erstellt automatisch drei Datenobjekte:

Objekt	Zweck
Fallentität [Demnächst verfügbar]	Enthält alle strukturierten Geschäftsdaten, aus denen Phasen, Aufgaben und Regeln lesen und in die sie schreiben.
Falldokumente	Speichert Anhänge und Dateien, die mit dem Fall verknüpft sind (Belege, Fotos, Verträge).
Fallkommentare	Speichert Hinweise, Anmerkungen und Kommunikation, die von Fallmitarbeitern während des gesamten Lebenszyklus hinzugefügt werden.

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

Konzentrieren Sie sich beim Schema-Design auf die Fallentität – sie ist die zentrale Quelle für die gesamte Fallverarbeitungslogik.

Schritt 2: Auswählen, wo sich die Entität befindet

Bevor Sie Felder definieren, entscheiden Sie, wie die Entität als Quelle verwendet werden soll.Wählen Sie die Option aus, die am besten zu Ihrem Datenbesitzmodell passt:

Quelle	Beschreibung	Einsatzbereich
Native 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 Processes, 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 darauf verweisen, ohne sie zu duplizieren.
Fall-Trigger-Nutzlast	Übergeben Sie vorhandene Daten im Trigger zur Fallerstellung (z. B. einen API-Connector). Die Nutzlastfelder werden zu Fallfeldern, die in allen Phasen verfügbar sind.	Leichte Integrationen, bei denen Sie den Fall zum Zeitpunkt der Erstellung füllen.

Schritt 3: Identifizieren und Kategorisieren Ihrer Felder

Zuordnen des vollständigen Falllebenszyklus

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

• Welche Daten sie lesen muss (Eingaben).
• Welche Daten sie produziert (Ausgaben).

Klassifizieren von Feldern in zwei Kategorien

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

Kategorie	Definition	Merkmale	Beispiele
Eingabefelder	Daten, die bereitgestellt werden, wenn der Fall erstellt wird, entweder durch eine Trigger-Nutzlast, eine Formularübermittlung oder ein externes System.	Wird bei der Erstellung ausgefüllt. In der Regel schreibgeschützt nach der Hydrierung.Erforderlich für das erste Routing und die Aufgabenausführung.	policyNumber, claimantName, dateOfLoss, lossDescription
Berechnete Felder	Daten, die von Aufgaben während der Fallverarbeitung erzeugt werden. Diese Felder beginnen leer und werden zurückgeschrieben, sobald Aufgaben abgeschlossen sind.	Leer bei der Erstellung. 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 sollten 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: Festlegen des Feldbesitzes

Feldbesitz ist das wichtigste Prinzip zur Vermeidung von Datenkollisionen.Jedes berechnete Feld in der Entität muss von genau einer Aufgabe geschrieben werden.

Zuweisen eines Schreibers pro Feld

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

Anmerkung des Besitzes in Ihrem Schema

Verwenden Sie eine writtenBy Anmerkung (oder einen gleichwertigen Kommentar), um zu dokumentieren, welcher Aufgabe das berechnete Feld gehört. Die Plattform erzwingt diese Anmerkung zwar nicht zur Runtime, sie dient aber als Designvertrag, der Kollisionen während der Entwicklung verhindert.

Verwenden von Namensbereich-Feldern zur Vermeidung von Mehrdeutigkeit

Wenn mehrere Aufgaben ähnliche Arten von Ausgabe erzeugen, versehen Sie Ihre Felder mit einem Namensraum, damit sie sich unterscheiden.Zum Beispiel:

• Verwenden Sie photoAnalysis für die Ausgabe einer Bildanalyse-Agenten-Aufgabe.
• Verwenden Sie diese Option fieldInspection für die Ausgabe einer Inspektionsaufgabe vor Ort durch Personen.
• Vermeiden Sie ein generisches analysisResult Feld, um das mehrere Aufgaben konkurrieren könnten.

Schritt 5: Definieren des Schemas

Erstellen der Entität in der ausgewählten Quelle

Navigieren Sie zum Designer der 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 Hinzufügen von Eingabefeldern

Definieren Sie alle Eingabefelder mit deren Typen, erforderlichen Markierungen und Standardwerten. Legen Sie required: true fest für Felder, 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 fügen Sie jedem Feld eine Anmerkung hinzu, welche die schreibende Aufgabe angibt.

Überprüfen eines Referenzschemas

Das folgende Beispiel zeigt das Muster „Eingabe gegenüber berechnet“ mit Feldbesitz für einen Schadensfall bei einer Kfz-Versicherung:

{
  "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 zu Aufgaben

Verbinden Sie es nach der Definition des Schemas über Eingabe- und Ausgabezuordnungen mit Aufgaben.

Konfigurieren von Eingabezuordnungen

Wählen Sie für jede Aufgabe nur die Felder der Fallentität aus, die die Aufgabe lesen muss.Dies bestimmt, welche Daten die Aufgabe sehen kann.

Beispiel – Eingabezuordnung der Aufgabe „Validate Policy“:

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

Konfigurieren von Ausgabezuordnungen

Ordnen Sie für jede Aufgabe das Ergebnis der Aufgabe dem spezifischen Feld der Fallentität zu, das die Aufgabe besitzt.Dies ist der Rückschreibmechanismus.

Beispiel – Ausgabezuordnung der Aufgabe Validate Policy:

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

Überprüfen, ob die Ausgabezuordnungen den Feldbesitz respektieren

Überprüfen Sie die Ausgabezuordnung jeder Aufgabe anhand Ihrer Schema-Anmerkungen. Bestätigen Sie, dass keine zwei Aufgaben in dasselbe Fallentitätfeld schreiben.

Schritt 7: Validieren des Schemas anhand von Regeln

Phasenregeln (Eintritt, Abschluss, Austritt, Wiedereintritt) werden anhand von Fallentitätsfeldern ausgewertet.Verifizieren Sie Folgendes:

• Jedes Feld, auf das die IF-Klausel einer Regel verweist, ist im Schema vorhanden.
• Das Feld wird von einer Aufgabe geschrieben, die abschließt, bevor die Regel ausgewertet wird.
• Der Feldtyp entspricht dem in der Regel verwendeten Operator (verwenden Sie beispielsweise keinen String-Vergleich in einem Dezimalfeld).

Beispiel – Eine Austrittsregel auf einer Aufnahmestufe hängt vom policyValid-Feld ab:

WHEN PolicyCheckCompleted event arrives
  IF caseEntity.policyValid == false

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

Erwartetes Ergebnis

Nach dem Ausführen dieser Schritte verfügen Sie über ein Fallentitätsschema, das:

• Eingabefelder (bei der Fallerstellung ausgefüllt) von berechneten Feldern (die von Aufgaben während der Verarbeitung geschrieben werden) klar trennt.
• Den expliziten Feldbesitz zuweist, sodass genau eine Aufgabe in jedes berechnete Feld schreibt.
• Feldnamen im Namensbereich verwendet, um Mehrdeutigkeit und Kollisionen zu vermeiden.
• Zuverlässiges Zurückschreiben von Aufgaben in die Entität unterstützt, um sicherzustellen, dass nachgelagerte Regeln und Aufgaben genaue, nicht widersprüchliche Daten nutzen.
• Den Datenvertrag zwischen dem Fallplan und seinen Aufgaben mit writtenBy Anmerkungen dokumentiert.

Code Snippet

Folgendes ist ein zweites Referenzschema für einen Anwendungsfall von Spesenabrechnung, das dasselbe Eingabe-gegen-Berechnungsmuster zeigt:

{
  "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 Feldnamen im Namensbereich.
Eine Regel wird niemals als true ausgewertet.	Das Feld, auf das die IF-Klausel der Regel verweist, ist zum Zeitpunkt der Auswertung durch die Regel noch nicht geschrieben.	Überprüfen Sie, ob die Aufgabe, die für das Schreiben des Felds verantwortlich ist, in der aktuellen oder einer vorherigen Phase abgeschlossen ist.
Eine Variable wird im Entitätsselektor nicht angezeigt.	Das Feld ist in der bereitgestellten Version des Fallentitätsschemas nicht definiert.	Fügen Sie das Feld dem Schema hinzu, veröffentlichen Sie den Fallplan erneut und stellen Sie ihn erneut bereit.
Eingabefelder werden während der Verarbeitung überschrieben.	Eine Aufgabenausgabezuordnung hat ein Eingabefeld als Ziel.	Entfernen Sie die Ausgabezuordnung, die auf das Eingabefeld abzielt. Dokumentieren Sie Eingabefelder in Ihrem Schema als schreibgeschützt.

Einschränkungen

• Die Unterstützung nativer Fallentitäten in Data Fabric ist noch nicht verfügbar. Verwenden Sie eine der drei in Schritt 2 beschriebenen Beschaffungsoptionen.
• Die writtenBy-Anmerkung ist eine Dokumentationskonvention zur Entwurfszeit. Die Plattform erzwingt keine Einzelverfasser-Einschränkungen zur Runtime. Entwickler müssen den Feldbesitz durch eine Überprüfung bestätigen.
• Die Unterstützung für Fallbenutzerrollen und für den Zugriff (Einschränkung, welche Personas bestimmte Entitätsfelder bearbeiten können) ist 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 verwenden.
• Eingabe- und Ausgabezuordnungsreferenz – Detaillierte Referenz für die Zuordnung von Entitätsfeldern zu Aufgabenparametern.
• Maestro Case-Tutorial: Schadensfälle bei Sachversicherungen – End-to-End-Tutorial, das diese Schema-Designprinzipien auf einen vollständigen Fallplan anwendet.