Establecer contratos de entrada/salida y de escritura diferida de tareas

Establece contratos de entrada, salida y reescritura de tareas en Maestro Case para que las tareas lean los campos correctos y actualicen la entidad del caso de forma coherente.

Información general

La asignación de entrada/salida (E/S) de la tarea define el contrato de datos entre la entidad de caso [próximamente] y cada tarea de un plan del caso. La asignación de entradas controla qué campos de entidad de caso recibe una tarea, y la asignación de salida (reescritura) controla qué campos de entidad de caso enriquece una tarea después de la ejecución. Establecer contratos de entrada/salida claros sirve para garantizar que cada tarea lea los datos correctos, escriba los resultados en los campos correctos y mantenga la entidad de caso como fuente única y fiable de la verdad.

Audiencia: intermedia; Automation Developers y arquitectos de soluciones que crean planes de casos en Studio Web.

Requisitos previos

• Accede a Studio Web
• Un proyecto de caso creado en Studio Web y en el que han definido, al menos, una etapa y una tarea. Consulta Crear un proyecto de caso para obtener instrucciones sobre su configuración.
• Una Entidad de caso [próximamente] con campos definidos, ya sea como entidad nativa de Data Fabric, como Virtual Data Object (VDO) o como campos pasados a través de un desencadenador de casos. Consulta Información general sobre la Entidad de caso para obtener más información.
• Familiaridad con los tipos de tarea compatibles: acción humana, RPA, flujo de trabajo de API, ejecutar conector, agente de IA, proceso agéntico de Maestro o caso secundario.

Paso 1: diseñar el esquema de la entidad de caso para la entrada/salida

Antes de asignar las entradas y salidas de la tarea, define el esquema de la entidad de caso para distinguir entre los campos que se rellenan en la creación del caso (campos de entrada) y los campos que se escriben por las tareas durante el procesamiento (campos de salida).

Identificar campos de entrada

Los campos de entrada se rellenan cuando se crea el caso, a través de un desencadenador de Data Fabric, un evento de conector o una llamada a la API. Estos campos proporcionan el contexto inicial para todas las tareas.

Ejemplos de campos de entrada:

• policyNumber: pasado desde el sistema desencadenante.
• claimantName: proporcionado por el creador del caso.
• lossDescription: descripción de texto libre proporcionada en el envío.

Identificar campos de salida

Las tareas escriben los campos de salida a medida que avanza el caso. Cada campo de salida se debe gestionar por una única tarea para evitar conflictos de escritura.

Ejemplos de campos de salida:

• validationResult: escrito por una tarea de conector "Validar póliza".
• damageEstimate: escrito por una tarea de agente "Estimar daños".
• adjusterDecision: escrito por una tarea humana "Revisión del ajustador".

Documentar el responsable del campo

Anota cada campo de salida con la tarea responsable de escribirlo. Aunque el esquema no aplica el responsable en runtime, esta documentación evita conflictos accidentales durante el diseño.

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

Nota:

Usa nombres de campos con espacios de nombres (por ejemplo, validation.result ocategorization.result) cuando varias tareas produzcan salidas estructuralmente similares. Esto evita la ambigüedad y evita el problema de que prevalezca la última escritura.

Paso 2: configurar la asignación de entradas para una tarea

La asignación de entrada selecciona campos específicos de la entidad de caso y los pasa como parámetros a la implementación de la tarea (flujo de trabajo, formulario, conector o agente). Esto controla qué datos la tarea puede ver.

Abrir el panel de configuración de la tarea

1. En el diseñador de planes de casos, selecciona la etapa de destino.
2. Selecciona la tarea que quieres configurar.
3. Abre la sección Entrada/Salida del panel de configuración de tareas.

Asignar campos de la entidad de caso a los parámetros de la tarea

1. En la sección Entrada, selecciona Añadir asignación de entrada.
2. Para cada parámetro de tarea, elige el campo Entidad de caso correspondiente en el selector de campos.
3. Repítelo para cada parámetro necesario para la tarea.

Por ejemplo, una tarea "Validar recibos" puede utilizar la siguiente asignación de entradas:

Parámetro de la tarea	Campo Entidad de caso
receipts	caseEntity.lineItems[*].receiptUrl
policyId	caseEntity.department
totalAmount	caseEntity.totalAmount
currency	caseEntity.currency

Seguir el principio de privilegio mínimo

Pasa solo los campos que la tarea necesita. Evita asignar toda la entidad de caso [próximamente] a una sola tarea. La definición del ámbito de las entradas reduce el riesgo de exposición accidental de datos y hace que el contrato de la tarea sea explícito.

Paso 3: configurar la asignación de salida (reescritura) para una tarea

La asignación de salida toma el resultado de la tarea y escribe valores específicos en la entidad de caso [próximamente] . Este es el mecanismo de reescritura que enriquece la fuente única de verdad.

Definir asignaciones de campos de salida

1. En la misma sección Entrada/Salida del panel de configuración de la tarea, localiza la sección Salida.
2. Selecciona Añadir asignación de salida.
3. Para cada campo de resultado que la tarea produce, elige el campo Entidad de caso de destino.

Por ejemplo, una tarea "Validar recibos" puede utilizar la siguiente asignación de salidas:

Campo Entidad de caso	Campo de salida de la tarea
caseEntity.validationResult	taskOutput.validationResult
caseEntity.validationStatus	taskOutput.status
caseEntity.invalidReceipts	taskOutput.failedItems

Asegurar que haya un escritor para cada campo

Asigna cada campo de salida de la entidad de caso a exactamente una tarea. Si dos tareas escriben en el mismo campo, la última que escribe gana y se pierden los datos anteriores.

Proteger los campos de SOLO LECTURA

Los campos rellenados en la creación del caso (por ejemplo, claimantName y policyNumber) nunca deben aparecer como destinos de las salidas. No asignes las salidas de la tarea a estos campos.

Paso 4: verificar la cadena de reescritura en todas las etapas

Cuando se hayan establecido las asignaciones individuales de tareas, valida que los datos fluyan correctamente de una etapa a la siguiente a través de la entidad de caso [próximamente].

Realizar un seguimiento del flujo de datos

Revisa cada etapa y confirma lo siguiente:

1. La Tarea A de la Etapa 1 lee los campos de entrada de la entidad de caso.
2. La Tarea A escribe su resultado en un campo específico de la entidad de caso a través de la asignación de salida.
3. El Gestor de casos evalúa las reglas de la etapa (reglas primero, alternativa al agente del gestor de casos) con los campos Entidad de caso actualizados.
4. La Tarea B de la Etapa 2 lee el campo que la Tarea A escribió, como su propia entrada.

El patrón sigue esta secuencia:

La tarea escribe en la entidad → Cambios de estado de la entidad → Evaluación de las reglas → La siguiente etapa se activa → La tarea posterior lee la entidad actualizada

Validar las dependencias de la regla

Para cada regla de entrada, finalización, salida y reingreso de etapa, confirma que el campo Entidad de caso al que hace referencia en su cláusula IF está rellenado con la asignación de salida de una tarea anterior. Si una regla hace referencia a un campo en el que ninguna tarea escribe, la regla nunca puede evaluar como verdadero.

Por ejemplo:

• Regla de entrada de etapa: IFcaseEntity.adjusterDecision == "approve": confirma que la tarea "Revisión del ajustador" asigna a caseEntity.adjusterDecision la salida de su decisión.
• Regla de salida de etapa: IFcaseEntity.policyValid == false: confirma que la tarea "Validar póliza" asigna su resultado a caseEntity.policyValid.

Paso 5: gestionar escenarios de reingreso

De forma predeterminada, se vuelve a ejecutar cada tarea de una etapa reingresada y sobrescribe su salida anterior en la entidad de caso. Usa el marcador por tarea runOnlyOncepara elegir no volver a ejecutar tareas específicas cuando su salida anterior siga siendo válida.

Tareas que deben volver a ejecutarse en el reingreso

Deja runOnlyOnce: false (el valor predeterminado) para las tareas cuya salida puede cambiar después de un reprocesamiento. Estas tareas se vuelven a ejecutar y sobrescriben su salida anterior en la entidad de caso [próximamente].

Conservar las salidas de las tareas que no deben volver a ejecutarse

Establece runOnlyOnce: true en las tareas cuya salida anterior siga siendo válida (por ejemplo, una categorización inicial que no dependa de datos corregidos). Estas tareas se omiten al reingresar; sus campos de entidad de caso no se cambian.

Tarea	runOnlyOnce	Comportamiento al reingresar
Validar recibos	false (Predeterminada)	Vuelve a ejecutar y sobrescribe validationResult
Clasificar gastos	true	Omitido; conserva el valor anterior categories
Comprobar los límites de la póliza	false (Predeterminada)	Vuelve a ejecutar y sobrescribe la salida de la comprobación de la póliza

Resultado esperado

Después de completar estos pasos:

• Cada tarea del plan del caso tiene asignaciones de entrada explícitas que tienen como ámbito los datos que recibe de la entidad de caso [próximamente].
• Cada tarea tiene asignaciones de salida explícitas que escriben los resultados en campos de entidad de caso designados.
• Cada campo de salida de la entidad solo está asignado a una tarea, lo que evita conflictos de escritura.
• Las reglas de etapa hacen referencia a los campos de la entidad de caso que las tareas previas rellenan de forma fiable.
• El comportamiento de reingreso está configurado para que las tareas produzcan una salida nueva o conservada, según corresponda.
• La entidad de caso sirve como fuente única de verdad a lo largo de todo el ciclo de vida del caso.

Ejemplo de caso de uso

Escenario: procesamiento automático de reclamaciones de seguros con cuatro etapas: Admisión de FNOL, Investigación, Evaluación y Liquidación.

Estado	Tarea	Entrada (de Entidad de caso [próximamente])	Salida (a la entidad de caso)
Admisión de FNOL	Validar póliza	policyNumber	policyValid
Admisión de FNOL	Extraer detalles	lossDescription, photos	extractedDetails
Investigación	Analizar fotos	photos, vehicleInfo	photoAnalysis
Investigación	Inspección de campo	claimId, vehicleInfo, lossDescription	fieldInspection
Evaluación	Estimar daños	photoAnalysis, fieldInspection, extractedDetails	damageEstimate
Evaluación	Revisión del ajustador	damageEstimate, photoAnalysis, policeReport	adjusterDecision
Liquidación	Calcular pago	damageEstimate, policyNumber	payoutAmount
Liquidación	Emitir pago	payoutAmount, claimantName	paymentReference
Liquidación	Notificar al asegurado	claimantEmail, payoutAmount, paymentReference	—

En este ejemplo, la tarea "Estimar daños" de la etapa de evaluación consume tres campos escritos por tareas previas en etapas anteriores (photoAnalysis, fieldInspection y extractedDetails). El gestor de casos utiliza adjusterDecision —escrito por la tarea "Revisión del ajustador"— para evaluar la regla de entrada de la etapa de liquidación.

Fragmento de código

El siguiente JSON ilustra una configuración completa de una asignación de entrada/salida para dos tareas de la etapa de entrada de 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"
      }
    }
  ]
}

Solución de problemas

Síntoma	Causa más probable	Resolución
La tarea posterior recibe entradas vacías o nulas	La asignación de salida de la tarea anterior no rellena el campo Entidad de caso esperado	Verifica que la asignación de salida de la tarea anterior apunte al nombre correcto del campo Entidad de caso.
La regla de etapa nunca devuelve verdadero	El campo Entidad de Caso al que se hace referencia en la regla no está escrito por ninguna tarea	Añade al campo de referencia una asignación de salida de la tarea responsable.
La tarea sobrescribe los datos escritos por otra tarea	Dos tareas asignan su salida al mismo campo Entidad de Caso	Asigna un campo Entidad de Caso único para cada tarea. Usa nombres de campos con espacios de nombres para evitar conflictos.
La reentrada produce resultados obsoletos	La tarea ha establecido true para runOnlyOnce pero su salida depende de los datos corregidos	Establece false para runOnlyOnce para las tareas que deben volver a validar o a procesar datos actualizados.
El campo de SOLO LECTURA se sobrescribe durante el procesamiento	Una asignación de salida de la tarea tiene como objetivo un campo que debe ser inmutable (por ejemplo, policyNumber)	Elimina la asignación de salida. Asegúrate de que los campos de solo entrada nunca se utilicen como de salida.
La ejecución de Agentic Case Manager se realiza correctamente, pero no se desencadena ninguna tarea	La salida del agente no coincide con la forma caseManagerDecisions.tasksToRun requerida (por ejemplo, una matriz simple de nombres de tareas)	Coincide con el contrato exacto en el contrato de entrada y salida del Gestor de casos.

Esta advertencia aparece en la sección Salidas de las propiedades de la tarea Agente de Case Manager cuando falta caseManagerDecisions o no devuelve el formato de valor correcto. Consulta Contrato de entrada y salida del Gestor de casos para ver la forma exacta que se debe utilizar.

Limitaciones

• El filtrado de variables de la vista de supervisión se aplica solo a las instancias que se ejecutan después de habilitar el filtro. Las instancias existentes no se filtran de forma retroactiva.
• La anotación writtenBy del esquema de la entidad es una convención usada durante el diseño para documentar. Maestro no hace cumplir reglas de un solo escritor en runtime.
• El control de acceso a nivel de campo en Entidad de caso [próximamente] no está disponible en esta versión de vista previa. Todas las tareas que tienen asignaciones de salida a un campo pueden escribir en él.

Próximos pasos

• Cómo configurar las reglas de etapa: aprende a utilizar los campos Entidad de caso en las reglas de entrada, finalización, salida y reingreso.
• Cómo configurar el comportamiento de reingreso: define qué tareas se vuelven a ejecutar cuando un caso vuelve a una etapa completada anteriormente.
• Información general de la Entidad de caso: comprende los tres objetos de datos listos para usar (Entidad de caso [próximamente], Documentos de caso y Comentarios de caso) y cómo introducir datos en un caso.
• Referencia de tipos de tarea: revisa todos los tipos de tarea compatibles y sus opciones de configuración.