Concevoir un schéma d'entité de cas persistant

Concevez un schéma d'entité de cas persistant avec des champs d'entrée, des champs calculés et des règles de propriété de champ pour une réécriture des Maestro Case fiable.

Vue d'ensemble (Overview)

L'entité d'incident [Bientôt disponible] est le modèle de données central et persistant que chaque étape, tâche et règle lit et écrit tout au long de la vie d'un incident. Un schéma d'entité bien conçu sépare les champs d'entrée (données fournies lors de la création de l'incident) des champs calculés (données produites par les tâches pendant le traitement) et affecte une propriété claire des champs afin qu'aucune tâche n'écrive dans le même champ qu'un autre. Suivez ce guide pour définir un schéma qui empêche les collisions de données pendant la réécriture et prend en charge des règles d'étape fiables.

Prérequis

• Accédez à Studio Web.
• Un processus métier défini avec les étapes et les tâches identifiées.
• Familiarité avec les concepts de base de Maestro Case.
• Une instance Data Fabric disponible dans votre environnement UiPath (recommandée pour la création d'entités natives).

Étape 1 : comprendre les objets de données prêts à l'emploi

Chaque projet d'incident crée automatiquement trois objets de données :

Objet	Objectif
Entité du cas [Bientôt disponible]	Contient toutes les données métier structurées que les étapes, les tâches et les règles lisent et écrivent.
Documents d'incident	Stocke les pièces jointes et les fichiers associés à l'incident (reçus, photos, contrats).
Commentaires sur les cas	Stocke les notes, les annotations et les communications ajoutées par les chargés de dossiers tout au long du cycle de vie.

Les trois partagent un champ système caseID immuable qui est automatiquement généré lors de la création de l'incident. Ce champ lie toutes les données de l'incident et ne peut pas être modifié.

Concentrez vos efforts de conception de schéma sur l'entité d'incident - elle est la source unique de vérité pour toute la logique de traitement des incidents.

Étape 2 : choisir l'endroit où vit l'entité

Avant de définir les champs, décidez comment extraire l'entité. Sélectionnez l’option qui correspond le mieux à votre modèle de propriété des données :

Source	Description	Quand l'utiliser
Natif dans Data Fabric (recommandé)	Créez l'entité en tant qu'entité métier native dans Data Fabric et liez-la à votre incident.	Nouveaux processus où vous possédez le modèle de données.
Virtual Data Object (VDO) dans Data Fabric	Enregistrez une source externe en tant que VDO dans Data Fabric et liez le VDO à l'incident.	Les données de l'entité se trouvent dans un système externe (CRM, ERP) et vous souhaitez les référencer sans les dupliquer.
Charge utile du déclencheur d'incident	Transmettez les données existantes dans le déclencheur de création d'incident (par exemple, un connecteur d'API). Les champs de charge utile deviennent des champs d'incident disponibles à toutes les étapes.	Intégrations légères dans lesquelles vous attribuez une valeur à l'incident au moment de la création.

Étape 3 : identifier et catégoriser vos champs

Mappage du cycle de vie complet de l'incident

Répertoriez chaque étape et chaque tâche de votre plan d'incident. Pour chaque tâche, identifiez :

• Quelles données elle doit lire (entrées).
• Les données qu'elle produit (sorties).

Classification des champs en deux catégories

Séparez chaque champ de votre schéma dans l'un des deux groupes suivants :

Catégorie	Définition	Caractéristiques	Exemples
Champs d'entrée	Données fournies lorsque l'incident est créé, soit par une charge utile de déclencheur, une soumission de formulaire ou un système externe.	Rempli lors de la création. Généralement en lecture seule après l'attribution de valeur. Requis pour le routage initial et l'exécution de la tâche.	policyNumber, claimantName, dateOfLoss, lossDescription
Champs calculés	Données produites par les tâches pendant le traitement de l'incident. Ces champs commencent vides et sont réécrits lorsque les tâches sont terminées.	Vide lors de la création. Écrits par une tâche spécifique. Consommé par les tâches et les règles en aval.	validationResult, damageEstimate, adjusterDecision, paymentReference

Marquage des champs d'entrée comme lecture seule

Les champs d'entrée tels que employeeId, policyNumber, ou reportId ne doivent jamais être écrasés par les tâches. Documentez ces champs en lecture seule dans votre schéma pour éviter toute modification accidentelle pendant le traitement.

Étape 4 : établissement de la propriété du champ

La propriété des champs est le principe le plus critique pour éviter les collisions de données. Chaque champ calculé de l'entité doit être écrit par exactement une tâche.

Affectation d'un rédacteur par champ

Pour chaque champ calculé, désignez la tâche unique responsable de l'écriture dans celui-ci. Si deux tâches écrivent dans le même champ, la dernière à écrire l'emporte et les données précédentes sont perdues.

Annotation de la propriété dans votre schéma

Utilisez une annotation writtenBy (ou un commentaire équivalent) pour documenter la tâche propriétaire de chaque champ calculé. Bien que la plateforme n'applique pas cette annotation lors du runtime, elle sert de contrat de conception qui empêche les collisions pendant le développement.

Utilisation de champs avec espace de noms pour éviter toute ambiguïté

Lorsque plusieurs tâches produisent des types de sortie similaires, utilisez des espaces de noms pour vos champs afin de les distinguer. Par exemple :

• Utilisez photoAnalysis pour la sortie d'une tâche d'agent d'analyse d'image.
• Utilisez fieldInspection pour la sortie d'une tâche d'inspection de terrain par un humain.
• Évitez un champ générique analysisResult pour lequel plusieurs tâches pourraient entrer en conflit.

Étape 5 : définir le schéma

Création de l'entité dans la source choisie

Accédez au concepteur de l'entité d'incident dans Studio Web. Créez une nouvelle entité avec un nom descriptif qui correspond à votre secteur d'activité (par exemple, AutoInsuranceClaim ou ExpenseReport).

Ajouter d'abord les champs d'entrée

Définissez tous les champs d'entrée avec leurs types, les indicateurs requis et toutes les valeurs par défaut. Définissez required: true pour les champs qui doivent être présents lors de la création de l'incident.

Ajout de champs calculés avec des annotations de propriété

Définissez tous les champs calculés avec leurs types, définissez required: false (ces champs sont vides lors de la création) et annotez chacun avec la tâche qui y écrit.

Examen d'un schéma de référence

L'exemple suivant démontre le modèle d'entrée par rapport au calcul avec la propriété des champs pour un incident de réclamation d'assurance automobile :

{
  "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" }
  }
}

Étape 6 : câblage des mappages d'entrée et de sortie aux tâches

Après avoir défini le schéma, connectez-le aux tâches via les mappages d'entrée et de sortie.

Configuration des mappages d'entrée

Pour chaque tâche, sélectionnez uniquement les champs de l'entité d'incident que la tâche doit lire. Cela contrôle les données que la tâche peut voir.

Exemple - Mappage d'entrée de la tâche Valider la politique :

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

Configuration des mappages de sortie

Pour chaque tâche, mappez le résultat de la tâche au champ spécifique de l'entité d'incident que la tâche possède. Il s'agit du mécanisme de réécriture.

Exemple - Mappage de sortie de la tâche Valider la politique :

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

Vérification que les mappages de sortie respectent la propriété du champ

Vérifiez le mappage de sortie de chaque tâche par rapport aux annotations de votre schéma. Confirmez qu'aucune tâche n'écrit dans le même champ de l'entité d'incident.

Étape 7 : validation du schéma par rapport aux règles

Les règles d'étape (entrée, achèvement, sortie, renouvellement) s'évaluent par rapport aux champs de l'entité d'incident. Vérifiez que :

• Chaque champ référencé dans la clause IF d'une règle est présent dans le schéma.
• Le champ est écrit par une tâche qui s'effectue avant que la règle ne soit évaluée.
• Le type de champ correspond à l'opérateur utilisé dans la règle (par exemple, n'utilisez pas une comparaison de chaîne sur un champ décimal).

Exemple : une règle de sortie sur une étape d'admission dépend du champ policyValid :

WHEN PolicyCheckCompleted event arrives
  IF caseEntity.policyValid == false

Confirmez que la tâche Valider la politique écrit policyValid et se termine dans l'étape d'admission avant que cette règle de sortie ne soit évaluée.

Résultat attendu

Après avoir terminé ces étapes, vous disposez d'un schéma d'entité d'incident qui :

• Sépare clairement les champs d'entrée (remplis lors de la création de l'incident) des champs calculés (écrits par les tâches pendant le traitement).
• Affecte la propriété explicite du champ afin qu'exactement une tâche écrive dans chaque champ calculé.
• Utilise des noms de champs avec espace de noms pour éviter l'ambiguïté et les collisions.
• Prend en charge la réécriture fiable des tâches vers l'entité, ce qui garantit que les règles et les tâches en aval consomment des données précises et non conflictuelles.
• Documente le contrat de données entre le plan d'incident et ses tâches via des annotations writtenBy.

Extrait de code

Ce qui suit est un deuxième schéma de référence pour un incident d'utilisation d'un rapport de dépenses, démontrant le même modèle d'entrée par rapport au calcul :

{
  "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" }
  }
}

Résolution des problèmes

Problème	Origine	Résolution
Un champ calculé contient des données inattendues ou obsolètes.	Plusieurs tâches écrivent dans le même champ. Le dernier processus d'écriture écrase la valeur précédente.	Auditez vos mappages de sortie. Affectez chaque champ à exactement une tâche et utilisez des noms de champs avec espace de noms.
Une règle n'est jamais évaluée sur true.	Le champ référencé dans la clause IF de la règle n'est pas encore écrit au moment où la règle est évaluée.	Vérifiez que la tâche responsable de l'écriture du champ se termine dans l'étape actuelle ou une étape précédente.
Une variable n'apparaît pas dans le sélecteur d'entité.	Le champ n'est pas défini dans la version déployée du schéma de l'entité d'incident.	Ajoutez le champ au schéma, republiez et redéployez le plan d'incident.
Les champs d'entrée sont remplacés pendant le traitement.	Un mappage de sortie de tâche cible un champ d'entrée.	Supprimez le mappage de sortie qui cible le champ d'entrée. Documentez les champs d'entrée comme étant en lecture seule dans votre schéma.

Limitations

• La prise en charge native de l'entité de l'incident dans Data Fabric n'est pas encore disponible. Utilisez l'une des trois options d'approvisionnement décrites à l'étape 2.
• L'annotation writtenBy est une convention de documentation au moment de la conception. La plateforme n'applique pas les contraintes d'auteur unique lors du runtime. Les développeurs doivent vérifier la propriété du champ via l'examen.
• Les rôles utilisateur d'incident et la prise en charge de l'accès (restreindre les personas pouvant modifier des champs d'entité spécifiques) ne sont pas encore disponibles.

Prochaines étapes

• Comment modéliser les étapes primaires et secondaires - Apprenez à configurer les règles d'étape qui consomment les champs de votre entité.
• Référence de mappage d'entrée et de sortie - Référence détaillée pour la mise en correspondance des champs de l'entité aux paramètres de la tâche.
• Tutoriel sur Maestro Case : réclamations d'assurance habitation - Tutoriel de bout en bout qui applique ces principes de conception de schéma à un plan d'incident complet.