✒️ABAP Los Eventos
ABAP Los Eventos
1 | La definición de Eventos
Dado que los Workflows son procesos de negocio, es vital para una aplicación de negocio poder comunicarse con los Workflows.
Por ejemplo una aplicación de negocio necesita informar:
Cuando comienza un proceso de negocio.
Cuando termina un proceso de negocio o una actividad dentro del proceso.
Cuando una actividad o proceso que ha comenzado ya no se necesita.
Cuando dada una circunstancia ha cambiado el ambiente en el cual el proceso se ejecuta.
Para poder comunicarse la aplicación de negocio utiliza eventos.
Evento en WORKFLOW
Un evento en Workflow representa el cambio de estado de una instancia de un objeto de negocio (Business Object).
Por ejemplo, cuando un usuario modifica el maestro de materiales para el material XXXY
entonces el Business Object XXXY lanzará el evento “Changed”.
Para usar un evento como interfase entre la aplicación y un Workflow se necesita lo siguiente:
Definición del Evento:
Es el nombre técnico del evento definido en un tipo de objeto.
Se definen como un verbo en pasado (creado, modificado, liberado, etc.). Además el evento está definido por sus parámetros.
Los parámetros por defecto de un evento son: su nombre, el tipo de objeto, la instancia del objeto y el creador del evento.
No obstante se pueden definir parámetros adicionales que deben acompañar el evento.
Creador del Evento:
Es el programa, Workflow, persona que ha creado el evento.
Receptor del Evento:
Es el término genérico que se usa para denominar a todo aquello que reaccionará ante el evento.
Normalmente son Workflows o tareas de espera.
Linkage del Evento:
El linkage especifica la relación entre el evento y su receptor.
Se pueden a su vez especificar las reglas que gobiernan esta relación.
Las reglas determinan cuando y como el receptor recibirá el evento.
2 | La creación de Eventos
Los eventos se crean en el Business Object Repository correspondiente a la transacción SWO1.
Imagen 2.1 - Creación de eventos a través de SWO1
Debemos especificar el tipo de objeto para el cual queremos crear el evento. Al definir eventos nunca debemos codificar nada.
Los datos que deben ingresarse son:
El nombre del evento
Los parámetros del evento
Podemos ver en el business object BUS2105 (solicitud de pedido) el evento “released”.
Imagen 2.2 - El evento release del objeto de negocios bus2105
Y veremos su definición.
Imagen 2.3 - Visualzamos la definición del evento release
Y un parámetro que posee asociado, que es el código de liberación.
Imagen 2.4 - Visualzamos el parámetro asociado al evento
3 | Lanzando eventos desde aplicaciones SAP
Antes que un evento sea lanzado por una aplicación, la creación del evento debe programarse en el programa de la aplicación.
Afortunadamente en muchos de los programas estándar de SAP, ya están definidos los programas que lanzan los eventos
y solo es necesario realizar el event linkage y determinadas configuraciones de customizing.
No obstante puede que para un proceso de negocio particular tengamos que crear un evento nuevo.
En este caso deberemos definir como se lanzará el evento a partir de la aplicación.
En el caso que el evento deba lanzarse desde un programa propio (de cliente)
podremos programar el lanzamiento del evento muy fácilmente utilizando las funciones que SAP provee para tal caso.
En el caso que debamos lanzar un nuevo evento desde un programa estándar de SAP tenemos las siguientes posibilidades:
A través de documentos de cambio (Change documents).
A través del sistema de gestión de status.
A través de control de mensajes.
Utilizando el sistema de información logística (LIS).
A través de los datos maestros de HR.
A través de Business Transaction Events (Solo para Finanzas).
A través de customizing especifico de cada aplicación.
Los tres primeros casos son los más usados, el resto son específicos para determinados módulos (HR – FI) y para casos aislados.
4 | Lanzando eventos con Changed Documents
Muchas aplicaciones de negocio en SAP utilizan documentos de cambio para dejar registro de las modificaciones hechas
(generalmente transacciones de mantenimiento de datos maestros).
Los documentos de cambio definen la operación que provoca el cambio (modificación, creación o borrado)
y registran los datos del objeto de negocio que ha cambiado en forma de tablas con el valor antiguo y el nuevo.
Los documentos de cambio SOLO se escriben cuando un campo designado como “relevante para change document” cambia.
Antes de definir un evento basado en un documento de cambio deberemos controlar
que el cambio será escrito como un documento de cambio, controlando el customizing de los campos o bien haciendo pruebas.
Para crear un evento de este tipo utilizaremos la transacción SWEC.
Imagen 4.1 - La transacción estándar SWEC
Transacción SWEC (lanzar un workflow)
Utilizaremos la transacción estándar SWEC para lanzar un workflow cuando se crean documentos de cambio.
Debemos indicar:
El código de documento de cambio.
El business object.
El evento.
Bajo que actividad se lanzará (Creación, Modificación, Borrado).
Imagen 4.2 - Creación de eventos basados en documentos de cambio
Luego podremos restringir aun más bajo que circunstancias queremos que se lance el evento,
especificando campos de la tabla de campos relevantes, su valor antiguo y su valor actual.
5 | Lanzando eventos por Cambio de Status
Si una aplicación de negocio utiliza el sistema de gestión de status, podremos configurar el lanzamiento de eventos
a partir de un cambio de status del sistema.
El sistema estándar viene por defecto con status predefinidos llamados “status de sistema”,
no obstante y por customizing pueden definirse nuevos status (de cliente).
Los status de sistema siempre son fijados por el sistema automáticamente,
mientras que los de cliente tienen que ser fijados por el usuario.
Para crear un evento de este tipo utilizaremos la transacción BSVW.
Primero debemos seleccionar con que tipo de status trabajar, de sistema o de usuario.
Imagen 5.1 - La transacción estándar BSVW
Transacción BSVW (lanzar un workflow cuando se modifica el estado del sistema)
Utilizaremos la transacción estándar BSVW para lanzar un workflow cuando se modifica el estado del sistema.
Luego deberemos seleccionar el tipo de objeto y su evento. Finalmente lo activamos.
Imagen 5.2 - Completamos el tipo de objeto y su evento
6 | Unir el evento al WorkFlow
Para establecer el inicio automático de un workflow a partir de un evento debemos
indicarlo en la configuración del Workflow en el Workflow Builder ( transacción SWDD ).
Una vez posicionados en el Workflow que deseamos iniciar con un evento, debemos pasar a la cabecera del Workflow.
Imagen 6.1 - La cabecera del workflow
En la cabecera indicaremos que tipo de objeto y evento lanzarán el Workflow.
Al crear la relación automáticamente aparecerá un binding que pasará datos desde el contenedor del evento al del Workflow.
Podremos modificar el binding para agregar los parámetros que deseemos.
Imagen 6.2 - Completamos el tipo de objeto y el evento que lanzarán el workflow
Finalmente deberemos “activar” el binding entre el Workflow y el evento.
Imagen 6.3 - Activamos el binding
Esta activación en la jerga de workflow se denomina “event linkage”.
La acción de activar el binding entre el Workflow y el evento genera una orden de transporte de customizing.
Otra forma de activar el linkage entre el evento y el Workflow es a través de la transacción SWETYPV.
Imagen 6.4 - La transacción estándar SWETYPV
Transacción SWETYPV (activación del linkage entre el evento y el workflow)
Utilizaremos la transacción estándar SWETYPV para realizar la activación del linkage entre el evento y el workflow.
7 | Las condiciones de inicio
SAP provee una manera fácil de limitar el inicio de un Workflow al dispararse un evento y esto es a través de condiciones de inicio.
Para configurar condiciones de inicio ejecutamos la transacción SWB_COND.
Imagen 7.1 - La transacción estándar SWB_COND
Transacción SWB_COND (configuración de las condiciones de inici)
Utilizaremos la transacción estándar SWB_COND para realizar la configuración de las condiciones de inicio.
Para crear la condición seleccionamos el tipo de objeto (en el ejemplo es la solicitud de pedido),
aparecerán todos los eventos acoplados con Workflow y seleccionamos uno.
Imagen 7.2 - Completamos el tipo de objeto y el evento
Utilizando las variables del contenedor del evento, creamos las condiciones lógicas que deseemos
para que se cumpla o no el lanzamiento del Workflow.
Imagen 7.3 - Creamos las condiciones lógicas
Finalmente podemos verificar los eventos. Para ello, podemos usar la transacción para simular eventos SWU0.
Imagen 7.4 - La transacción estándar SWU0
Y la transacción SWUE para crear eventos.
Imagen 7.5 - Creación de eventos con la transacción SWUE
Transacciones SWU0 y SWUE (simular y crear eventos respectivamente)
Utilizaremos las transacciones estándar SWU0 y SWUE para simular y crear eventos respectivamente.
8 | Los desarrollos de programas lanza eventos
El programa que desee disparar un evento deberá utilizar el módulo de funciones SWE_EVENT_CREATE.
La estructura lógica del programa debería ser la siguiente:
Llenar el contenedor de eventos con los parámetros necesarios.
Componer la clave del objeto que debe instanciarse para llamar al evento.
Llamar la función SWE_EVENT_CREATE.
Controlar las excepciones.
Disparar el evento con COMMIT_WORK explicito.
 
 
 
Sobre el autor
Publicación académica de Alex Francisco Lemos Collazos, en su ámbito de estudios para la Carrera Consultor ABAP.
Alex Francisco Lemos Collazos
Profesión: Ingeniero en Sistemas - Colombia - Legajo: QS36A
✒️Autor de: 174 Publicaciones Académicas
🎓Cursando Actualmente: Master S/4HANA Material Management
🎓Egresado de los módulos:
- Máster Material Management en SAP S/4HANA LOGISTIC
- Carrera Consultor ABAP Nivel Avanzado
- Carrera Consultor ABAP Nivel Inicial
- Carrera Consultor en SAP SD Nivel Inicial