Idioma: Español
ActivityInfo 4.0 introdujo los webhooks: una base de datos podía registrar una URL y ActivityInfo le enviaba un mensaje JSON cada vez que se añadía, editaba o eliminaba un registro. Muchas organizaciones crearon integraciones sobre esta base: flujos de trabajo de notificación en Power Automate o Pipedream, trabajos de sincronización y el propio conector de ActivityInfo para Power Automate.
El nuevo motor de automatización generaliza esta idea, y vale la pena entender qué cambió, qué no cambió deliberadamente y cómo elegir entre los formatos de carga útil del webhook.
Qué cambió
Un webhook 4.0 era un único proceso fijo: un evento, una fórmula de filtro opcional y una solicitud HTTP en un formato fijo. Una automatización es un flujo de pasos: un desencadenador que produce datos, seguido de cualquier combinación de pasos de filtro, correo electrónico y webhook.
El nuevo concepto fundamental son los datos de los pasos. Cada desencadenador produce una tabla — para los desencadenadores de registros, una única fila que contiene los campos del registro junto con las columnas reservadas _previous, _user y _trigger. Cada paso posterior trabaja a partir de esa misma fila: el filtro evalúa su condición contra ella, el paso de correo electrónico la interpola en plantillas y el paso de webhook puede serializarla o interpolarla en un cuerpo personalizado. Un modelo de datos, que se aprende una vez y se usa en todas partes — y es el mismo lenguaje de fórmulas utilizado en todo ActivityInfo para los campos calculados y las medidas.
Esta es también la razón por la que los filtros se volvieron más capaces: una fórmula de filtro 4.0 solo podía ver el registro en sí, mientras que un paso de filtro puede comparar con la instantánea previa a la edición (_previous.STATUS != STATUS), navegar por las referencias (CLINIC.NAME == "Mangina Health Post") e inspeccionar el actor (_user.email).
Las importaciones ahora activan los desencadenadores
Los webhooks de ActivityInfo 4.0 no se activaban para los cambios derivados de las importaciones. La exclusión tenía como objetivo proteger los sistemas receptores de ráfagas, pero en la práctica creaba problemas reales: los registros importados en masa omitían silenciosamente los flujos de trabajo creados sobre los webhooks, y los consumidores nunca podían confiar en haber visto todos los cambios. Las automatizaciones eliminan la exclusión — los desencadenadores de registros se activan para cada cambio, sea cual sea su origen: entrada de datos, la aplicación móvil, la API y las importaciones por igual, una ejecución por registro.
Este es un cambio de comportamiento para los webhooks migrados: una automatización migrada desde un webhook 4.0 empieza a recibir eventos también para los registros importados. Si su sistema receptor no puede absorber una ráfaga de una solicitud por registro importado, añada un paso de filtro para limitar qué eventos proceden, o adapte el receptor para poner en cola las solicitudes entrantes.
Qué no cambió deliberadamente
Los webhooks existentes siguen funcionando, byte por byte. Un webhook creado en ActivityInfo 4.0 aparece en el nuevo editor como una automatización — un desencadenador de registro, su fórmula de filtro si la tenía, y un paso de webhook — y su formato de carga útil es compatible con ActivityInfo 4.0: la forma JSON exacta que producía la 4.0, mantenida como un contrato publicado y fijada por un conjunto de pruebas de regresión contra una instantánea de los eventos de producción. Las integraciones creadas con los webhooks 4.0, incluidos los flujos que utilizan el conector de Power Automate, siguen funcionando sin cambios en la carga útil que reciben — la única diferencia de comportamiento es que las importaciones ahora también activan eventos, como se ha descrito anteriormente.
La firma también se mantiene sin cambios: los mismos encabezados estándar de los webhooks y el mismo esquema de firma v1 HMAC-SHA256, calculado sobre el cuerpo exacto de la solicitud.
Por qué hay nuevos formatos de carga útil
El formato 4.0 está orientado a eventos: su cuerpo de update solo lleva los campos cambiados por el evento, y los valores de sus campos fueron diseñados para el modelo de datos 4.0. Eso lo hace preciso para el seguimiento de cambios, pero incómodo para dos casos comunes:
"Solo deme el registro." Los consumidores que querían el estado actual completo del registro tenían que fusionar
updateenpreviousellos mismos — y los campos calculados faltaban por completo, porque el formato 4.0 se construye a partir de los valores almacenados del registro y los campos calculados se computan en la lectura. El formato Estándar envía en su lugar los datos del paso del desencadenador: cada campo del formulario en cada evento, incluidos los campos calculados, en una forma estable, con_previous,_usery_triggeral lado — exactamente lo que ven las fórmulas, así que lo que usted prueba en un filtro es lo que recibe su consumidor."El receptor dicta el formato." Las herramientas de chat y muchas API requieren un cuerpo específico. Anteriormente, esto significaba un servicio intermediario solo para remodelar el JSON. El formato Personalizado elimina ese salto: usted escribe el cuerpo como una plantilla con referencias
${...}, y ActivityInfo rellena los valores — con escape JSON, para que el documento siga siendo válido contenga los datos que contenga. Una notificación de Google Chat se convierte en un único paso de webhook con una plantilla de una línea.
Elegir un formato
| Si usted... | Elija ||------------|--------|| Mantiene una integración creada con los webhooks 4.0, o utiliza el conector de Power Automate | Compatible con ActivityInfo 4.0 | | Crea una nueva integración que consume el estado del registro | Estándar | | Publica directamente en un sistema que dicta el cuerpo — Google Chat, Slack, una API | Personalizado |
Los webhooks migrados y las conexiones de Power Automate mantienen el formato compatible con ActivityInfo 4.0, por lo que nada cambia para las integraciones existentes; los nuevos pasos de webhook utilizan el formato Estándar por defecto. El formato es una configuración por paso, por lo que puede añadir un webhook Estándar o Personalizado junto a uno existente compatible con 4.0 y migrar los consumidores a su propio ritmo.