✒️ABAP / Los Eventos Por Miguel Acosta Acosta

EVENTOS

1.- Definiciòn de eventos:

Dado que los workflows son procesos de negocio, es vital para una aplicaciòn poder comunicarse con los workflows.

Por ejemplo una aplicaciòn de negocios necesita informar:

- Cuando comienza un proceso de negocio.

- Cuando termina un proceso de negocio.

- 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.- representa el cambio de estado de una circunstancia de un objeto de negocio (business Object).

Por ejemplo, cuando un usuario modifica el maestro de materiales para el material xxxxy entonces el Business Object xxxxy lanzarà el evento "Changed".

Para usar un evento como interface 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 de 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:

Los eventos se crean en el Business Object Repository y correspondiente a la transacciòn 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 ingresar son:

- El nombre del evento.

- Los paràmetros del evento.

Podemos ver en el business Object BUS2105 (solicitud de pedido) el evento "released".

Y veremos 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 de que un evento sea lanzado por una aplicaciòn, la ceraciòn del evento debe programarse en el programa de la aplicaciòn.

Afortunadamente en muchos de los programas estàndar del 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.

Para 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 Transacciòn 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 negocios en SAP utilizan documentos de cambio para dejar un registro de las modificaciones hechas (generalmente transacciones de mantenimiento de datos maestros).

Los documentos de cambio SOLO se escribe 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 (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).

Luego 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 su valor actual.

5.- Lanzamiento de 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.

Es sistema estàndar viente 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 autmà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 (cuando se modifica el estado del sistema). Primero debemos seleccionar con que tipo de status trabajar, de sistema o de usuario.

Luego debemos seleccionar el tipo de objeto y su evento. Finalmente lo activamos.

Tambièn podemos lanzar eventos mediante control de mensajes, si una aplicaciòn usa control de mensajes para intercambiar informaciòn entre los distintos involucrados en el proceso de negocios, podemos configurar un mensaje para el lanzamiento de eventos.

Cuando el sistema de control de mensajes se ejecute, cualquier mensaje creado serà lanzado. Ejemplo en O. C. se utilizan mensajes para imprimir la orden. Tambièn podemos usar el mismo sistema para lanzar eventos

La configuraciòn de mensajes se realiza a travès de la transacciòn NACE.

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òm 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.

Finalmente deberemos "activar" el binding entre el workflow y el evento.

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.

7.-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.

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.

Finalmente podemos verificar los eventos. Para ello, podemos usar la transacciòn para simular eventos SWU0.

Y la transacciòn SWUE, para crear eventos.

Utilizaremos las transacciones estàndar SWU0 y SWUE para simular y crear eventos respectivamente.

8.- Desarrollo 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 a la funciòn SWE_EVENT_CREATE.

- Controlar las excepciones.

- Disparar el evento con COMMIT_WORK explìcito.

Ejemplo:

include <CNTN01>.

data: begin of asset_key,

company_code like anla-bukrs,

asset_no like anla-anlnl,

sub_numer like anla/anln2,

end of asset_key.

data: object_key like sweinstcu-objkey,

swc_container evt_container.

* Write parameters into event container

swc_set_element evt_container 'flag_equi_aendern' 'x'.

* Compose object key

asset_key-company:code = '0001'.

asset_key-asset_no = '0000000123456'.

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.

MESSAGE id sy-MSGID type sy-msgty number sy-msgno

with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4

endif.

* start trfc processing

commit work.