Event Driven Callback

Existen dos tipos de eventos: el tipo After (después) y el tipo Before (antes). Eventos del tipo After son ejecutados después que un objeto es creado, actualizado o eliminado en el Manager. Por ejemplo, si un usuario crea una app y existe un evento registrado como After App, la llamada será disparada después de la creación de la app en el backend.

Ya eventos del tipo Before son disparados antes de una acción en el Manager. Siendo así, la creación/actualización/eliminación podrá ser cancelada en el caso que la llamada a la URL registrada en el event-driven callback falle por cualquier motivo.

Un administrador crea un event-driven callback informando: a) cuál es el tipo de objeto que desea observar; y b) una URL. Cuando objetos del tipo seleccionado fueren creados/modificados/eliminados, el API Manager hará un POST para la URL informada. Decimos en este caso que el event-driven callback es «activado». El cuerpo de la petición contendrá una representación JSON del objeto en cuestión, más algunos datos, como la acción (created, updated o deleted) y el usuario responsable.

El event-driven callback registrado puede ser disparado ANTES o DESPUÉS, dependiendo de su tipo (Before o After). Después de disparado, un listener es notificado de un evento y, en el caso que el callback sea del tipo Before, el propio callback puede bloquear la acción de creación/actualización/eliminación de un objeto cualquiera, pues puede ser realizada una validación antes de que la acción se realice efectivamente.

En el caso de event-driven callbacks del tipo After, la acción (creación/actualización/eliminación) no será bloqueada, pero generará un mensaje de error o una advertencia sobre el evento que ocurrió.

Para crear un nuevo callback, haga clic en el botón Create Event-Driven Callback, representado por el símbolo + en la esquina inferior derecha de la pantalla. Se abrirá una ventana modal para rellenar los datos.

Entre con el nombre (Name), eleja el tipo de evento que será observado e informe una URL de un sistema creado para el propósito de notificar.

El campo Expected HTTP Status tendrá utilidad solamente para eventos del tipo Before y debe ser llenado con el estado HTTP esperado cuando se devuelva la llamada a la URL registrada. Esto es porque eventos de este tipo realizan la comparación del estado registrado con el estado retornado por la llamada para saber si pueden proseguir con la operación o no.

El campo Request Headers no es obligatorio. Como ya hemos mencionado, las llamadas se desencadenan a partir de la supervisión de las acciones de creación, actualización y eliminación de objetos. Si queremos usar sólo una o dos de las acciones como disparador, debemos insertar la propiedad action en el campo Request Headers.

Después de llenar los campos, haga clic en Save.

Para editar un callback ya registrado, haga clic en el icono , en la columna Actions de la lista de callbacks. Se abrirá una ventana modal que contiene las informaciones del callback, y podrá cambiar los datos. Cuando termine, haga clic en Save.

Para editar un callback ya registrado, haga clic en el icono , en la columna Actions de la lista de callbacks.

Un mensaje de confirmación será exhibido. Haga clic en Ok para llevar a cabo la eliminación.

En el caso que ocurra algún error durante el POST para la URL informada (incluyendo casos en los que el host es desconocido o rechaza conexiones), el procesamiento del API Manager no será afectado y no serán hechas nuevas tentativas de POST.

Sin embargo, el API Manager mantiene un historial de todas las notificaciones que intentó enviar. Para ver el historial de activación de un event-driven callback, haga clic en el enlace compuesto por la fecha y la hora en la columna Last triggered on en el listado de callbacks. Una pantalla como la siguiente mostrará los detalles de la llamada seleccionada.

Muchas veces, será deseable crear un callback para modificar complemente informaciones recibidas. Por ejemplo, puedes establecer que cuando se crea una app, el valor Java se toma siempre que no se especifique ningún valor en los campos extra fields.

Sin embargo, dado que el listener recibe el objeto después que él ya fue creado, será necesario llamar la API del Manager para hacer la modificación.

Observe, sin embargo, que modificaciones en el Manager pueden, a su vez, disparar otros listeners. Se debe tomar cuidado para no crear un loop infinito de eventos.

Note también que la API del Manager está, por si sola, protegida con credenciales de acceso (para mayores detalles, vea el tópico Users). Usted debe crear credenciales del tipo «Integration» para que su sistema interactúe con el Manager con éxito.