Établissement des contrats d'E/S et de réécriture de la tâche

Établissez les contrats d'entrée, de sortie et de réécriture dans Maestro Case afin que les tâches lisent les bons champs et mettent à jour l'entité du cas de manière cohérente.

Vue d'ensemble (Overview)

Le mappage des entrée/sortie (E/S) de la tâche définit le contrat de données entre l'entité d'incident [Bientôt disponible] et chaque tâche d'un plan d'incident. Le mappage d'entrée contrôle les champs de l'entité d'incident qu'une tâche reçoit, et le mappage de sortie (réécriture) contrôle les champs de l'entité d'incident qu'une tâche enrichit après l'exécution. L'établissement de contrats d'E/S clairs garantit que chaque tâche lit les données correctes, écrit les résultats dans les bons champs et conserve l'entité d'incident comme source unique de vérité fiable.

Audience : intermédiaire - Automation Developers et Solution Architects élaborant des plans d'incident dans Studio Web.

Prérequis

• Accédez à Studio Web.
• Un projet d'incident créé dans Studio Web avec au moins une étape et une tâche définies. Consultez Créer un projet d'incident pour obtenir des instructions de configuration.
• Une entité d'incident [Bientôt disponible] avec des champs définis - soit en tant qu'entité Data Fabric native, un Virtual Data Object (VDO) ou des champs transmis via un déclencheur d'incident. Consultez Vue d'ensemble de l'entité d'incident pour plus de détails.
• Familiarité avec les types de tâches pris en charge : Action humaine, RPA, workflow d'API, Exécuter le connecteur, Agent d'IA, Processus agentique Maestro et Incident enfant.

Étape 1 : conception du schéma de l'entité d'incident pour les E/S

Avant de mapper les entrées et les sorties de la tâche, définissez le schéma de l'entité d'incident pour distinguer entre les champs remplis lors de la création de l'incident (champs d'entrée) et les champs écrits par les tâches pendant le traitement (champs de sortie).

Identification des champs d'entrée

Les champs d'entrée sont remplis lorsque l'incident est créé, via un déclencheur Data Fabric, un événement de connecteur ou un appel d'API. Ces champs fournissent le contexte de départ pour toutes les tâches.

Exemples de champs d'entrée :

• policyNumber - transmis du système de déclenchement.
• claimantName - fourni par le créateur de l'incident.
• lossDescription - description en texte libre fournie lors de la soumission.

Identification des champs de sortie

Les champs de sortie sont écrits par les tâches au fur et à mesure de l'avancement de l'incident. Chaque champ de sortie doit avoir une tâche propriétaire unique pour éviter les collisions d'écriture.

Exemples de champs de sortie :

• validationResult - écrit par une tâche de connecteur « Valider la politique ».
• damageEstimate - écrit par une tâche d'agent « Estimer les dommages ».
• adjusterDecision - écrit par une tâche humaine « Examen de l'expert en sinistres ».

Documentation de la propriété du champ

Annotez chaque champ de sortie avec la tâche responsable de l'écrire. Bien que le schéma n'applique pas la propriété lors du runtime, cette documentation évite les collisions accidentelles pendant la conception.

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

Remarque :

Utilisez des noms de champs avec espace de noms (par exemple, validation.result vs. categorization.result) lorsque plusieurs tâches produisent une sortie structurellement similaire. Cela évite l'ambiguïté et évite le problème où le dernier rédacteur l'emporte.

Étape 2 : configurer le mappage d'entrée pour une tâche

Le mappage de l'entrée sélectionne les champs spécifiques de l'entité d'incident et les transmet en tant que paramètres à l'implémentation de la tâche (workflow, formulaire, connecteur ou agent). Cela contrôle les données que la tâche peut voir.

Ouverture du panneau de configuration de la tâche

1. Dans le concepteur de plan d'incident, sélectionnez l'étape cible.
2. Sélectionnez la tâche que vous souhaitez configurer.
3. Ouvrez la section Entrée/Sortie du panneau de configuration de la tâche.

Mappage des champs de l'entité d'incident aux paramètres de la tâche

1. Dans la section Entrée, sélectionnez Ajouter un mappage d'entrée.
2. Pour chaque paramètre de tâche, choisissez le champ d'entité d'incident correspondant dans le sélecteur de champs.
3. Répétez l'opération pour chaque paramètre que la tâche nécessite.

Par exemple, une tâche « Valider les reçus » peut utiliser le mappage d'entrée suivant :

Paramètre de la tâche	Champ d'entité d'incident
receipts	caseEntity.lineItems[*].receiptUrl
policyId	caseEntity.department
totalAmount	caseEntity.totalAmount
currency	caseEntity.currency

Suivre le principe du moindre privilège

Transmettez uniquement les champs dont la tâche a besoin. Évitez de mapper l'ensemble de l'entité d'incident [Bientôt disponible] à une seule tâche. L'établissement de l'étendue des entrées réduit le risque d'exposition involontaire des données et rend le contrat de tâche explicite.

Étape 3 : configurer le mappage de sortie (réécriture) pour une tâche

Le mappage de sortie prend le résultat de la tâche et écrit des valeurs spécifiques dans l'entité d'incident [Bientôt disponible] . Il s'agit du mécanisme de réécriture qui enrichit la source centrale de vérité.

Définition des mappages de champs de sortie

1. Dans la même section Entrée/Sortie du panneau de configuration de la tâche, localisez la section Sortie.
2. Sélectionnez Ajouter un mappage de sortie.
3. Pour chaque champ de résultat que la tâche produit, choisissez le champ d'entité d'incident cible.

Par exemple, une tâche « Valider les reçus » peut utiliser le mappage de sortie suivant :

Champ d'entité d'incident	Champ de sortie de la tâche
caseEntity.validationResult	taskOutput.validationResult
caseEntity.validationStatus	taskOutput.status
caseEntity.invalidReceipts	taskOutput.failedItems

Garantie d'un rédacteur par champ

Affectez chaque champ de sortie de l'entité d'incident à exactement une tâche. Si deux tâches écrivent dans le même champ, la dernière opération d'écriture l'emporte et les données antérieures sont perdues.

Protection des champs en lecture seule

Les champs remplis lors de la création de l'incident (par exemple, claimantName, policyNumber) ne doivent jamais apparaître comme cibles de sortie. Ne mappez pas les sorties de tâche à ces champs.

Étape 4 : vérification de la chaîne de réécriture dans les étapes

Une fois les mappages de tâches individuels en place, validez que les données circulent correctement d'une étape à l'autre via l'entité d'incident [Bientôt disponible] .

Traçage du flux de données

Parcourez chaque étape et confirmez :

1. La tâche A de l'étape 1 lit les champs d'entrée de l'entité d'incident.
2. La tâche A écrit son résultat dans un champ d'entité d'incident spécifique via le mappage de sortie.
3. Le gestionnaire d'incidents évalue les règles d'étape (les règles d'abord, solution de secours de l'agent du gestionnaire d'incidents) à l'aide des champs de l'entité d'incident mis à jour.
4. La tâche B de l'étape 2 lit le champ que la tâche A a écrit comme sa propre entrée.

Le modèle suit cette séquence :

La tâche écrit dans l'entité → L'état de l'entité change → Les règles s'évaluent → L'étape suivante s'active → La tâche en aval lit l'entité mise à jour

Validation des dépendances de la règle

Pour chaque règle d'entrée, d'achèvement, de sortie et de renouvellement d'une étape, confirmez que le champ d'entité d'incident auquel elle fait référence dans sa clause IF est renseigné par le mappage de sortie d'une tâche en amont. Si une règle fait référence à un champ dans lequel aucune tâche n'écrit, la règle ne peut jamais être évaluée comme vrai.

Par exemple :

• Règle d'entrée d'étape : IF caseEntity.adjusterDecision == "approve"- confirmez que la tâche « Examen de l'expert en sinistres » associe le résultat de sa décision à caseEntity.adjusterDecision.
• Règle de sortie de l'étape : IF caseEntity.policyValid == false- confirmez que la tâche « Valider la politique » associe son résultat à caseEntity.policyValid.

Étape 5 : gestion des scénarios de renouvellement

Par défaut, chaque tâche d'une étape renouvelée réexécute et écrase sa sortie précédente dans l'entité d'incident. Utilisez l'indicateur runOnlyOnce par tâche pour exclure certaines tâches de la réexécution lorsque leur sortie précédente est toujours valide.

Tâches qui doivent s'exécuter au renouvellement

Laissez runOnlyOnce: false (par défaut) pour les tâches dont la sortie peut changer après la révision. Ces tâches réexécutent et écrasent leur sortie précédente dans l'entité d'incident [Bientôt disponible].

Préservation des sorties des tâches qui ne doivent pas être réexécutées

Définissez runOnlyOnce: true pour les tâches dont la sortie précédente est toujours valide (par exemple, une catégorisation initiale qui ne dépend pas des données corrigées). Ces tâches sont ignorées lors du renouvellement ; leurs champs d'entité d'incident restent inchangés.

Tâche	runOnlyOnce	Comportement lors du renouvellement
Valider les reçus	false (par défaut)	Réexécute et écrase validationResult
Catégoriser les dépenses	true	Ignoré ; conserve la valeur categories précédente
Vérifier les limites de la politique	false (par défaut)	Réexécute et écrase la sortie de la vérification de la politique

Résultat attendu

Après avoir terminé ces étapes :

• Chaque tâche du plan d'incident dispose de mappages d'entrée explicites qui définissent le périmètre des données qu'elle reçoit de l'entité d'incident [Bientôt disponible] .
• Chaque tâche dispose de mappages de sortie explicites qui écrivent les résultats dans les champs de l'entité d'incident désignés.
• Chaque champ de sortie de l'entité d'incident a une seule tâche propriétaire, ce qui empêche les collisions d'écriture.
• Les règles d'étape font référence aux champs de l'entité d'incident que les tâches en amont remplissent de manière fiable.
• Le comportement de renouvellement est configuré de sorte que les tâches produisent une sortie nouvelle ou conservée selon les besoins.
• L'entité d'incident sert de source unique de vérité tout au long du cycle de vie de l'incident.

Exemple de cas d'utilisation

Scénario : traitement des demandes d'indemnisation d'assurance automobile avec quatre étapes - Saisie FNOL, Enquête, Évaluation et Règlement.

Étape	Tâche	Entrée (de l'entité d'incident [Bientôt disponible] )	Sortie (vers l'entité d'incident)
Admission FNOL	Valider la police	policyNumber	policyValid
Admission FNOL	Extraire les détails	lossDescription, photos	extractedDetails
Enquête	Analyser les photos	photos, vehicleInfo	photoAnalysis
Enquête	Inspection des champs	claimId, vehicleInfo, lossDescription	fieldInspection
Évaluation	Estimer les dommages	photoAnalysis, fieldInspection, extractedDetails	damageEstimate
Évaluation	Examen de l'expert en sinistres	damageEstimate, photoAnalysis, policeReport	adjusterDecision
Règlement	Calculer le paiement	damageEstimate, policyNumber	payoutAmount
Règlement	Émettre le paiement	payoutAmount, claimantName	paymentReference
Règlement	Notifier le requérant	claimantEmail, payoutAmount, paymentReference	—

Dans cet exemple, la tâche « Estimer les dommages » à l'étape d'évaluation consomme trois champs écrits par les tâches en amont aux étapes précédentes (photoAnalysis, fieldInspection, extractedDetails). Le responsable des sinistres utilise adjusterDecision - écrit par la tâche « Examen de l'expert en sinistres » - pour évaluer la règle d'entrée de l'étape de règlement.

Extrait de code

Le JSON suivant illustre une configuration complète de mappage d'E/S pour deux tâches de l'étape d'admission FNOL :

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

Résolution des problèmes

Symptôme	Cause probable	Résolution
La tâche en aval reçoit une entrée vide ou nulle	Le mappage de la sortie de la tâche en amont ne remplit pas le champ d'entité d'incident attendu	Vérifiez que le mappage de sortie de la tâche en amont cible le nom de champ de l'entité d'incident correct.
La règle d'étape n'est jamais évaluée comme vrai	Le champ de l'entité d'incident référencé dans la règle n'est écrit par aucune tâche	Ajoutez un mappage de sortie de la tâche responsable au champ référencé.
La tâche écrase les données écrites par une autre tâche	Deux tâches mappent leur sortie au même champ d'entité d'incident	Affectez un champ d'entité d'incident unique à chaque tâche. Utilisez des noms de champs avec espace de noms pour éviter les collisions.
Le renouvellement produit des résultats obsolètes	La tâche a runOnlyOnce défini sur true mais sa sortie dépend des données corrigées	Définissez runOnlyOnce sur false pour les tâches qui doivent revalider ou retraiter les données mises à jour.
Le champ en lecture seule est écrasé pendant le traitement	Un mappage de sortie de tâche cible un champ qui doit être immuable (par exemple, policyNumber)	Supprimez le mappage de sortie. Assurez-vous que les champs d'entrée uniquement ne sont jamais utilisés comme cibles de sortie.
L’exécution du gestionnaire de cas agentique réussit, mais aucune tâche ne se déclenche	La sortie de l'agent ne correspond pas à la forme caseManagerDecisions.tasksToRun requise (par exemple, un tableau simple de noms de tâches)	Faites correspondre le contrat exact dans le contrat d’entrée et de sortie du gestionnaire de cas.

Cet avertissement s'affiche dans la section Sorties des propriétés de la tâche de l'agent du gestionnaire de cas lorsque caseManagerDecisions est manquant ou ne renvoie pas le format de valeur correct. Pour obtenir la forme exacte à utiliser, consultez le contrat d'entrée et de sortie du gestionnaire de cas .

Limitations

• Le filtrage des variables dans la vue Surveillance s'applique uniquement aux instances qui s'exécutent après que vous avez activé le filtre. Les instances existantes ne sont pas filtrées rétroactivement.
• L'annotation writtenBy dans le schéma de l'entité est une convention de conception destinée à des fins de documentation. Maestro n'applique pas les règles d'auteur unique lors du runtime.
• Le contrôle d'accès au niveau du champ sur l'entité d'incident [Bientôt disponible] n'est pas disponible dans cette version d'aperçu. Toutes les tâches avec des mappages de sortie vers un champ peuvent y écrire.

Prochaines étapes

• Comment configurer les règles d'étape - Apprenez à utiliser les champs de l'entité d'incident dans les règles d'entrée, d'achèvement, de sortie et de renouvellement.
• Comment configurer le comportement de renouvellement - Définissez les tâches qui se réexécutent lorsqu'un incident revient à une étape précédemment terminée.
• Vue d'ensemble de l'entité d'incident - Comprendre les trois objets de données prêts à l'emploi (Entité d'incident [Bientôt disponible] , Documents d'incident, Commentaires d'incident) et comment intégrer les données dans un incident.
• Référence des types de tâches - Examinez tous les types de tâches pris en charge et leurs options de configuration.