El objeto de negocio es el puente entre una traza y un responsable
Por Equipo Quantum Developers
Resumir:
Una traza puede mostrar exactamente qué servicio falló y seguir sin responder qué factura, embarque u orden quedó en riesgo. La tesis es específica: la observabilidad se convierte en control solo cuando cada evento técnico puede vincularse a un objeto de negocio estable, una decisión y un responsable. El identificador del objeto es la clave que permite pasar de “la llamada devolvió error” a “esta obligación está bloqueada, esta persona debe decidir y esta evidencia falta”.
Logs, métricas y spans describen sistemas. Operaciones necesita estados, consecuencias y propietarios. El objeto de negocio no reemplaza la telemetría; ofrece el punto de unión entre ambos lenguajes.
Tres identidades que no deben confundirse
Una implementación madura conserva al menos tres claves:
- event_id: identifica una observación o cambio único y permite detectar duplicados.
- trace_id: correlaciona trabajo técnico que cruzó servicios.
- business_object_id: mantiene la identidad operacional a través de múltiples ejecuciones y trazas.
CloudEvents exige atributos como id, source, specversion y type, y define subject y time para describir el contexto del evento (especificación CloudEvents). La combinación source más id permite reconocer duplicados. Subject puede transportar una referencia al objeto, pero la semántica y privacidad del identificador siguen siendo responsabilidad del productor.
OpenTelemetry explica que la propagación de contexto permite ensamblar spans en una traza aunque se generen en componentes distintos (OpenTelemetry Traces). Esa correlación termina normalmente cuando concluye la ejecución. Una factura, en cambio, puede atravesar varias ejecuciones: ingestión, validación, aprobación, pago y conciliación. Por eso trace_id y business_object_id son complementarios.
Esquema mínimo de evento operacional
Este esquema es una propuesta utilizable, no una norma:
| Campo | Propósito |
|---|---|
| event_id | unicidad e idempotencia |
| event_type | cambio expresado en pasado |
| occurred_at | momento real del hecho |
| recorded_at | momento de ingestión |
| source | sistema o actor productor |
| business_object_type | factura, orden, embarque u otro |
| business_object_id | clave estable dentro de su alcance |
| trace_id | ejecución técnica relacionada |
| causation_id | evento o decisión que provocó este |
| actor | persona, regla, agente o servicio |
| decision | aprobar, rechazar, proponer, observar |
| policy_version | regla usada para permitir la acción |
| outcome | estado resultante conocido |
| evidence_uri | artefacto o registro verificable |
| schema_version | contrato con el que se interpreta |
No todos los campos deben exponerse en cada interfaz, pero el registro persistente debe permitir responderlos. La versión del esquema es esencial: un estado que cambia de significado sin versión rompe comparaciones históricas.
W3C PROV-O modela entidades, actividades y agentes, y permite expresar uso, generación, derivación y responsabilidad (W3C PROV-O). El esquema anterior toma esa idea de procedencia de forma pragmática: el objeto es una entidad; la ejecución, una actividad; el actor carga responsabilidad; causation_id y evidence_uri explican la cadena.
Reglas que convierten campos en contrato
Un esquema sin invariantes solo uniforma nombres. Defina reglas verificables:
- source y event_id deben ser únicos para una ocurrencia.
- occurred_at nunca se reemplaza con recorded_at; si se desconoce, declare la limitación.
- business_object_id debe incluir un alcance para evitar colisiones entre empresas o sistemas.
- los eventos se anexan; una corrección referencia el evento corregido.
- todo cambio material de estado exige actor y policy_version.
- una decisión humana conserva identidad, momento y alcance de aprobación.
- evidence_uri apunta a un artefacto inmutable o versionado.
- datos sensibles no se copian al evento si una referencia protegida es suficiente.
Estas reglas pueden validarse antes de aceptar el evento. Los fallos deben ir a una cola de contrato, no desaparecer del tablero.
Ejemplo ilustrativo: una orden bloqueada
Suponga una orden de compra que llega al ERP y activa validación. La primera ejecución crea trace A y emite ORDER_RECEIVED sobre el objeto PO-417. Otra ejecución, trace B, consulta presupuesto y emite POLICY_CHECK_FAILED con la política vigente y evidencia del centro de costo ausente. Una persona corrige el dato; una tercera ejecución referencia el evento fallido mediante causation_id y emite ORDER_RELEASED.
Un ingeniero puede recorrer cada trace para depurar latencia. El responsable de compras puede consultar el objeto PO-417 y ver la secuencia completa, incluida la decisión humana. Auditoría puede verificar política y artefacto sin leer cada log. Los identificadores y nombres son ilustrativos; el valor está en mantener la relación.
Preguntas operativas que la clave permite
Con business_object_id como unión, el sistema puede responder:
- ¿qué objetos están bloqueados por la misma razón?;
- ¿qué decisiones se tomaron con una versión de política retirada?;
- ¿qué ejecuciones afectaron este objeto?;
- ¿qué excepciones no tienen dueño?;
- ¿qué acción produjo el resultado y qué evidencia la soporta?;
- ¿cuánto tiempo pasó el objeto en cada estado?
Las respuestas económicas requieren además datos de resultado; una traza no demuestra ROI. Pero sin la cadena de objeto, evento y decisión tampoco es posible atribuir un cambio con rigor.
Cómo representarlo en Quantum
Quantum Automation Center puede exponer catálogo, estado de ejecuciones, líneas de tiempo, artefactos y logs. El objeto de negocio conecta esas superficies. Una vista de ejecución sirve al operador técnico; una vista de objeto reúne varias ejecuciones; la analítica agrega estados sin perder la posibilidad de volver a evidencia.
La documentación de objetos de negocio debería ser el lugar para definir alcance, identificadores y estados. Los permisos deben controlar quién ve el objeto y quién puede aprobar un cambio, mientras la línea de tiempo conserva la separación entre propuesta, aprobación y resultado.
El contrapunto: no etiquete cada span
Un equipo que depura un servicio de corta duración puede obtener todo lo necesario con traces y logs. Copiar identificadores de negocio en cada span eleva cardinalidad, superficie de privacidad y costo de almacenamiento. Propague el mínimo contexto necesario y asócielo en límites importantes: ingreso, decisión, acción y resultado.
El objeto tampoco corrige una taxonomía confusa. Si operaciones no acuerda qué significa “cerrado”, una clave común solo hace más visible el desacuerdo.
Cuándo no usar una capa de objetos
No la construya para procesos efímeros sin identidad persistente ni para telemetría que jamás guiará una decisión. Tampoco empiece con una ontología empresarial completa. Seleccione un objeto que cruce sistemas, defina estados y preguntas concretas, y pruebe que la clave mejora escalamiento o evidencia.
El criterio final es operativo: si una alerta no puede nombrar qué objeto cambió, qué decisión falta y quién responde, todavía tiene observabilidad técnica. Cuando sí puede hacerlo, empieza a tener control gobernado.
Sources
Temas del artículo
