✒️ABAP Los Eventos

Eventos. Que son los eventos, como se crean, como se lanzan, y demás cuestiones relacionadas al manejo de los eventos de los WorkFlows.

1.-Definición de Eventos.

Dado que los WF son objetos de negocio, es vital poder comunicarse entre ellos.

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.

NOTA: 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, el Business Object lanzará el evento “Changed”.

Para usar un evento como interface entra la aplicación y un WorkFlow se necesita:

• 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. Por defecto son nombre, el tipo de objeto, la instancia del objeto, y el creador del evento.
• Creador del evento: es el programa WorkFlow, persona que ha creado el evento.
• Receptor del evento: es el termino genérico que se usa para denominar a todo aquello que reaccionará ante el evento. Normalmente son WorFlowd 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.-Creación de Eventos.

NOTA: Se crean en el Business Object Repository correspondiente a la TX SW01.

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 con:

• El nombre del evento.
• Los parámetros del evento.

Podemos ver en el Business Object BUS2105 (solicitud de pedido) el evento “released”, su definición, y un parámetro que posee asociado que es el código de liberación.

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.

En SAP, en muchos programas estándar ya están definidos los programas que lanzan los eventos. Solo es necesario realizar el event linkage y determinadas configuraciones de customizing.

Si tenemos que enviar 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 del control de mensajes.

· Utilizando el sistema de información Logistica (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 específico 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. Y registran los datos del objeto de negocio que ha cambiado en forma de tablas con el valor antiguo y nuevo.

Los documentos de cambio SOLO se escriben cuando un campo designado como “relevante para changed document” cambia.

Antes de definir un evento basado en un documento de cambio, deberemos controlar que el cambio será escrito como tal, controlando el customizing de los campos o bien haciendo pruebas.

Para crear un evento de este tipo utilizaremos la TX SWEC.

NOTA: utilizaremos la transacción 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 qué actividad se lanzará (creación, modificación, borrado).

Después podremos restringir aún más, bajo que circunstancias queremos que se lance el evento, especificando campos de la tabla de campos relevantes, su valor antiguo y el actual.

5.-Lanzando eventos por cambio de estatus.

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 estatus 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 clientes).

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 ese tipo utilizaremos la TX BSVW.

NOTA: Utilizaremos la TX BSVW para lanzar un WorkFlow cuando se modifica el estado del sistema.

Seleccionaremos el tipo de status a trabajar, de sistema o usuario.

Después seleccionamos el tipo de objeto y su evento.

Finalmente activamos.

6.-Unir el evento al WorkFlow.

Para establecer el inicio automático de un WorkFlow a partir de un evento debemos indicarlo en el WorkFlow Builder (TX SWDD).

Una vez posicionados en el WorkFlow que deseamos iniciar con el evento, debemos pasar a la cabecera del WorkFLow.

Indicaremos que tipo de objeto y evento lanzaran el WorkFlow

Al crear la relación, automáticamente aparecerá un binding que pasará datos desde el contenedor del evento al del WorkFlow. Podemos modificar el binding para agregar los parámetros que deseemos.

Finalmente deberemos “activar” el binding entre el WorkFlow y el evento ( event linkage).

NOTA: la acción de activar el binding entre el WorkFlow y el evento genera una orden de transporte de customizing.

También se puede activar desde la TX SWETYPV.

NOTA: Binding. Juego de reglas que definen cuales son los datos que se pasarán y a que parte del proceso del WorkFLow)

7.-Condiciones de inicio.

Para limitar el inicio de un WorkFlow al dispararse un evento se hace a través de las condiciones de inicio.

Para configurarlas ejecutamos la TX SWB_COND.

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.

Utilizando las variables del contenedor del evento, creamos las condiciones lógicas que deseemos para que se cumpla o no el lanzamiento del WorkFlow.

Podemos verificar los eventos con la TX SWU0.

Con la TX SWUE cremamos los eventos.

8.-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 debería ser:

· 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 explícito.

Código de ejemplo:

Include <CNTN01>

Data: begin of asset_key,

Company_code like anla-bukrs,

Asset_no like anla-anln1,

Sub_number like anla-anln2.

End of asset_key.

Data: object_key like sweinscou-objkey.

Swc_container evt_container.

*Write parameters into event container

Swc_sert_element evt_container ‘flag_equi_aendern’ ‘X’.

*Compose object key

Asset_key-company_codi = ‘0001’.

Asset_key-asset_no = ‘0000001234560’.

Asset_key-sub_number = ‘0100’.

Object_key = asset_key.

*Trigger the event

Call function ‘SWE_EVENT_CREATE’

Exporting

Objtype = ‘BUS1022’

Objkey = object_key

Event = ‘changed’

Tables

Event_container = evt_container

Exceptions

Others = 01.

If sy-subrc ne 0.

“mensaje

Endif.

*Start tRFC processing

Commit work.