Diseñar un esquema de entidad de caso persistente

Diseña un esquema de entidad de caso persistente con campos de entrada, campos calculados y reglas de propiedad de campos para una reescritura fiable de Maestro Case.

Información general

La entidad de caso [próximamente] es el modelo de datos central y persistente en el que cada etapa, tarea y regla lee y escribe a lo largo de la vida útil de un caso. Un esquema de entidad bien diseñado separa los campos de entrada (datos proporcionados al crear casos) de los campos calculados (datos producidos por las tareas durante el procesamiento) y asigna claramente el responsable del campo para que no haya dos tareas que escriban en el mismo campo. Sigue esta guía para definir un esquema que evite las conflictos de datos durante la reescritura y admita reglas de etapa fiables.

Requisitos previos

• Accede a Studio Web
• Un proceso empresarial definido con etapas y tareas identificadas.
• Familiaridad con los conceptos principales de Maestro Case.
• Una instancia de Data Fabric disponible en tu entorno de UiPath (recomendada para la creación de entidades nativas).

Paso 1: comprender los objetos de datos predeterminados

Cada proyecto de caso crea automáticamente tres objetos de datos:

Objeto	Propósito
Entidad del caso (próximamente)	Contiene todos los datos empresariales estructurados que las etapas, tareas y reglas leen y en los que escriben.
Documentos del caso	Almacena archivos adjuntos y archivos asociados con el caso (recibos, fotos y contratos).
Comentarios del caso	Almacena notas, anotaciones y comunicaciones añadidas por los trabajadores de los casos a lo largo del ciclo de vida.

Los tres comparten un campo del sistema caseID inmutable que se genera automáticamente al crear el caso. Este campo une todos los datos del caso y no se puede cambiar.

Concéntrate en el diseño de tu esquema en la entidad de caso: es la fuente única de verdad para toda la lógica de procesamiento de casos.

Paso 2: elegir dónde reside la entidad

Antes de definir campos, decide cómo obtener el origen de la entidad. Selecciona la opción que mejor encaje en tu modelo de propiedad de datos:

Origen	Descripción	Cuándo usarlo
Nativo de Data Fabric (recomendado)	Crea la entidad como una entidad empresarial nativa en Data Fabric y enlázala a tu caso.	Procesos nuevos en los que eres propietario del modelo de datos.
Virtual Data Object (VDO) en Data Fabric	Registra un origen externo como VDO en Data Fabric y vincula el VDO al caso.	Los datos de la entidad viven en un sistema externo (CRM o ERP) y quieres hacer referencia a ellos sin duplicarlos.
Carga útil del desencadenador de casos	Pasa los datos existentes en el desencadenador de creación de casos (por ejemplo, un conector de API). Los campos de carga útil se convierten en campos de caso disponibles en todas las etapas.	Integraciones ligeras en las que el caso se completa con datos en el momento de la creación.

Paso 3: identificar y categorizar tus campos

Asignar el ciclo de vida completo del caso

Enumera cada etapa y cada tarea en tu plan del caso. Para cada tarea, identifica lo siguiente:

• Qué datos necesita leer (entradas).
• Qué datos produce (salidas).

Clasificar campos en dos categorías

Separa cada campo de tu esquema en uno de dos grupos:

Categoría	Definición	Características	Ejemplos
Campos de entrada	Datos proporcionados cuando se crea el caso, ya sea por una carga útil de desencadenador, un envío de formulario o un sistema externo.	Rellenado en la creación. Normalmente en modo SOLO LECTURA después de que se completa con datos. Necesario para el redireccionamiento inicial y la ejecución de la tarea.	policyNumber, claimantName, dateOfLoss, lossDescription
Campos calculados	Datos producidos por las tareas durante el procesamiento del caso. Estos campos comienzan vacíos y se rellenan a medida que se completan las tareas.	Vacío en la creación. Escrito por una tarea específica. Consumido por tareas y reglas posteriores.	validationResult, damageEstimate, adjusterDecision, paymentReference

Marcar campos de entrada como de SOLO LECTURA

Las tareas nunca deben sobrescribir campos de entrada como employeeId, policyNumber o reportId. Documenta estos campos como de SOLO LECTURA en tu esquema para evitar que se envíen accidentalmente modificaciones durante el procesamiento.

Paso 4: establecer el responsable del campo

El responsable del campo es el principio más crítico para evitar conflictos de datos. Cada campo calculado de la entidad debe escribirse solamente por una tarea.

Asignar un escritor para cada campo

Designa la tarea única responsable de escribir en cada campo calculado. Si dos tareas escriben en el mismo campo, la última que escribe gana y se pierden los datos anteriores.

Anotar el responsable en tu esquema

Usa una anotación writtenBy (o comentario equivalente) para documentar qué tarea es responsable de cada campo calculado. Aunque la plataforma no aplica esta anotación en runtime, sirve como contrato de diseño que evita conflictos durante el desarrollo.

Usar campos con espacio de nombres para evitar ambigüedades

Cuando varias tareas produzcan tipos de salidas similares, asigna espacios de nombres a tus campos para mantenerlos diferenciados. Por ejemplo:

• Usa photoAnalysis para la salida de una tarea de agente de análisis de imágenes.
• Usa fieldInspection para la salida de una tarea humana de inspección de campo.
• Evita usar un campo genérico analysisResult por el que puedan competir varias tareas.

Paso 5: definir el esquema

Crear la entidad en el origen elegido

Ve al Diseñador de entidades de casos de Studio Web. Crea una entidad nueva con un nombre descriptivo que coincida con el dominio de tu empresa (por ejemplo, AutoInsuranceClaim o ExpenseReport).

Añadir primero campos de entrada

Define todos los campos de entrada con sus tipos, indicadores de obligatoriedad y valores predeterminados.Establece required: true para los campos que deben estar presentes en la creación del caso.

Añadir campos calculados con anotaciones de propiedad

Define todos los campos calculados con sus tipos, establece required: false (estos campos están vacíos al crearse) y anota en cada uno la tarea que escribe en él.

Revisar un esquema de referencia

El siguiente ejemplo demuestra el patrón de entrada frente a cálculo con el responsable del campo para un caso de reclamaciones de seguros de automóviles:

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

Paso 6: conectar las asignaciones de entrada y salida a tareas

Después de definir el esquema, conéctalo a las tareas a través de asignaciones de entrada y salida.

Configurar las asignaciones de entrada

Para cada tarea, selecciona solo los campos de entidad de caso que la tarea necesita leer. Esto controla qué datos la tarea puede ver.

Ejemplo, la asignación de entradas de la tarea Validar póliza:

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

Configurar las asignaciones de salida

Para cada tarea, asigna el resultado de la tarea al campo específico de la entidad de caso que la tarea posee. Este es el mecanismo de reescritura.

Ejemplo, la asignación de salidas de la tarea Validar póliza:

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

Verificar que las asignaciones de salida respeten al responsable del campo

Comprueba la asignación de salidas de cada tarea con las anotaciones de tu esquema. Confirma que no haya dos tareas que escriban en el mismo campo Entidad de caso.

Paso 7: validar el esquema con las reglas

Las reglas de etapa (entrada, finalizar, salida y reingreso) se evalúan en función de los campos de entidad de caso. Verifica que:

• Cada campo al que se hace referencia en la cláusula IF de una regla está presente en el esquema.
• El campo lo escribe una tarea que se completa antes de que se evalúe la regla.
• El tipo de campo coincide con el operador utilizado en la regla (por ejemplo, no utilices una comparación de string en un campo decimal).

Ejemplo, una regla de salida de una etapa de entrada depende del campo policyValid:

WHEN PolicyCheckCompleted event arrives
  IF caseEntity.policyValid == false

Confirma que la tarea Validar póliza escriba policyValid y se complete dentro de la etapa de entrada antes de que esta regla de salida se evalúe.

Resultado esperado

Después de completar estos pasos, tienes un esquema de entidad de caso que:

• Separa claramente los campos de entrada (rellenados en la creación del caso) de los campos calculados (escritos por las tareas durante el procesamiento).
• Asigna el responsable explícito del campo para que solamente una tarea escriba en cada campo calculado.
• Usa nombres de campos con espacio de nombres para evitar ambigüedades y conflictos.
• Admite la reescritura fiable de las tareas en la entidad, lo que garantiza que las reglas y tareas posteriores consuman datos precisos y no conflictivos.
• Documenta el contrato de datos entre el plan del caso y sus tareas a través de anotaciones writtenBy.

Fragmento de código

El siguiente es un segundo esquema de referencia para un caso de uso de informe de gastos, que demuestra el mismo patrón de entrada frente a cálculo:

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

Solución de problemas

Problema	Causa	Resolución
Un campo calculado contiene datos inesperados u obsoletos.	Varias tareas escriben en el mismo campo. La última que escribe sobrescribe el valor anterior.	Realiza una auditoría de tus asignaciones de salida. Asigna cada campo únicamente a una tarea y utiliza nombres de campo con espacios de nombre.
Una regla nunca devuelve en true.	El campo al que se hace referencia en la cláusula IF de la regla no está escrito en el momento en el que se evalúa la regla.	Verifica que la tarea responsable de escribir en el campo se complete dentro de la etapa actual o de una anterior.
Una variable no aparece en el selector de entidades.	El campo no está definido en la versión implementada del esquema de entidad de caso.	Añade el campo al esquema y vuelve a publicar e implementar el plan del caso.
Los campos de entrada se sobrescriben durante el procesamiento.	Una asignación de salida de la tarea tiene como objetivo un campo de entrada.	Elimina la asignación de salida que tiene como destino el campo de entrada. Documenta los campos de entrada como de SOLO LECTURA en tu esquema.

Limitaciones

• El soporte nativo de entidades de caso en Data Fabric aún no está disponible. Usa una de las tres opciones de abastecimiento descritas en el paso 2.
• La anotación writtenBy es una convención de documentación en tiempo de diseño. La plataforma no aplica restricciones de escritor único en runtime.Los desarrolladores deben verificar el responsable del campo a través de una revisión.
• La compatibilidad con los roles de usuario y el acceso por caso (restringir qué perfiles pueden editar campos de entidad específicos) aún no está disponible.

Próximos pasos

• Cómo modelar etapas principales y secundarias: aprende a configurar reglas de etapa que consumen campos de tu entidad.
• Referencia de asignación de entradas y salidas: referencia detallada para asignar campos de entidad a parámetros de la tarea.
• Tutorial de Maestro Case: reclamaciones de seguros del hogar: completo tutorial que aplica estos principios de diseño de esquemas a un plan integral de casos.