...
...
| Info |
|---|
A fecha de la publicación de esta guía, SAP no ha liberado el evento local R_JournalEntryTP-Created que permitiría poder automatizar la creación del registro TicketBAI sin necesidad de configurar el servicio de EventMesh, ya solicitamos a SAP liberar el evento y prevé liberarlo en 2025. +info |
En esta sección se describen los pasos a seguir para llevar a cabo la configuración de la solución EventMesh para la gestión del evento de creación de la factura, y así habilitar la declaración del registro TicketBAI de manera automática y asíncrona.
...
Las tareas las dividiremos en 4 partes5 pasos:
Habilitar la comunicación desde SAP S/4Hana Public Cloud a SAP BTP (Provider).
| Info |
|---|
En el ejemplo que se muestra en el video, se configura el evento |
Notas: Al crear el SAP S/4Hana Cloud Extensibility, nos pedirá un valor para el campo “Instance name” recomendamos usar el id del sistema S/4Hana Cloud. Al crear la instancia de Event Mesh consumer nos pedirá un valor para el campo “Receiver system” (minuto 4:00), recomendamos usar el id del sistema S/4Hana concatenando una C (de consumer) al final.
...
| Info |
|---|
Guardar el nombre de la Queue que hemos creado en la instancia de Event Mesh (minuto 4:47) lo vamos a necesitar en el paso 34. (Como aparece en el listado una vez creado). |
...
Habilitar la comunicación desde BTP a S/4Hana Cloud (Consumer).
En este paso vamos a configurar en nuestro sistema lo necesario para consumir los eventos de la instancia de EventMesh.
| Info |
|---|
El usuario que realice esta tarea deberá tener acceso al Tile Communication Arrangement, para ello deberá tener asignado el rol SAP_BR_ADMINISTRATOR. |
...
El Service Key lo tenemos que generar desde BTP, desde la instancia de Event Mesh que creamos en el paso anterior (minuto 4:00). Vamos al listado de instancias y localizamos nuestra instancia de Event Mesh, y seleccionamos “Create Service Key”.
...
Con esto ya tenemos disponible la opción de consumir eventos de esta instancia de Event Mesh desde nuestro sistema.
Creación del handler.
| Info |
|---|
Este paso puede no ser necesario si está implemetado ya desde el desarrollo de algún producto, como es el caso del evento de creación del JournalEntry de b+ TicketBAI Cloud |
Para capturar el evento desde una clase que ejecutará nuestra lógica. Lo primero que tenemos que hacer es ir al canal que funciona como proveedor, desde la App “Enterprise Event Enablement - Configure Channel Binding”, reconoceremos el canal que funciona como proveedor porque es el contiene el evento que queremos capturar en la sección Outbound Topic Binding.
Vamos a la sección Event Metadata y copiamos el contenido entre llaves en un fichero .json que crearemos en nuestro pc.
En Eclipse, debemos crear un nuevo Event Consumption Model usando dicho json. Una vez terminado, se nos generarán varios objetos, entre ellos la clase donde podremos implementar la lógica que queremos ejecutar cuando se capture el evento. Por ejemplo:
...
Para terminar, desde Eclipse, necesitaremos crear un Communication Scenario que tenga como servicio de Inbound nuestro Event Comptumption Model. Después de añadir el Event Consumption Model debemos pulsar el botón Publish Locally.
En el Tile de Communication Arrangement, crearemos uno nuevo en base al Communication Scenario que acabamos de crear.
Creación del communication arrangement de handler.
En la app Communication Arrangement, debemos crear un nuevo acuerdo basado en el Communication Scenario que hemos creado en el paso anteriorescenario /TBAI/CS_EVENT_MESH.
...
Crearemos un nuevo Communication System, llamado, por ejemplo, XXX_ EVENT_MESH_CONSUMER. Marcaremos el flag General>Inbound Only, activaremos la sección Event Mesh y añadiremos el Canal que creamos en el paso 2 (Communication Arrangement de la instancia consumer de Event Mesh).
...
Volvemos al Communication Arrangement y guardamos.
Configurar el canal de eventos.
Esta tarea será llevada a cabo en el Tile “Enterprise Event Enablement - Configure Channel Binding” y será necesario realizarla de forma manual en cada uno de los sistemas.
...
Entramos en el canal que tiene el mismo ID que el Communication ArrangementSystem que creamos en el paso anterior, y comprobamos que tiene lo siguiente:
...
Solo debemos crear un Subscription de la cola (Queue) que creamos en el paso 1, y que deberíamos haber guardo el ID, como se comenta en dicho paso.
...
Si después de añadir la cola, en la columna Status podemos leer Acknowledged, entonces es que hemos realizado todos los pasos de la configuración correctamente, podemos pasar al último paso.Con esto ya tendríamos terminada la configuración.
Implementar el acuerdo SAP_COM_0002 para el usuario de comunicaciones.
| Info |
|---|
No importa que el acuerdo ya esté creado para otro sistema, debemos crear uno nuevo para el sistema de comunicaciones que creamos en el paso 3 “EVENT_MESH_CONSUMER” |
Para proveer al usuario de comunicaciones de los permisos necesarios para consumir las vistas estándar de FI que se utilizan en la solución debemos crear un acuerdo de comunicaciones basado en el escenario de Finanzas, para el mismo usuario y sistema que usamos en el paso 3. Esto puede resultar poco intuitivo, pero así el usuario de integración de EventMesh tendrá los permisos necesarios para consultar vistas como I_JournalEntry y demás vistas necesarias por el producto.
En la aplicación “Communication Arrangement” debemos implementar el escenario SAP_COM_0002 y en la configuración usaremos el mismo sistema que usamos en el paso 3 y el mismo usuario, deshabilitando los servicios de salida, así el campo Outbound User dejará de ser obligatorio y nos dejará grabar.
...
Para validar que la configuración es correcta, podemos acceder a la aplicación “Enterprise Event Enablement - Event Monitor”, donde es posible visualizar los canales de salida y entrada. En esta herramienta, podremos observar cómo los eventos se generan en el canal de salida, se envían a BTP a través del servicio EventMesh y, finalmente, llegan al canal de entrada del sistema, confirmando que el flujo se ejecuta correctamente.
Durante nuestras pruebas, desde la creación del JournalEntry hasta la recepción del evento, el proceso tiene una duración aproximada de 10 segundos.