✒️ABAP / Los Eventos Por Josep Lopez Moyano

DEFINICION DE EVENTOS

Un evento en Workflow representa el cambio de estado de una instancia de un objeto de negocio (Business Object)

Por ejemplo si un usuario modifica el maestro de materiales para el material XXXY entonces el Business Object XXXY lanzará un evento “changed”

Para usar un evento interfase entre la aplicación y un workflow se necesita lo siguiente:

· DEFINICION 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 los parámetros son: su nombre, el tipo de objeto, la instancia del objeto y el creador del evento. 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: termino genérico que se usa para denominar todo aquello que reaccionará ante el evento. Normalmente Workflows o tareas en espera

· LINKAGE DEL EVENTO: especifica la relación entre el evento y se receptor. Se puede a su vez especificar las reglas que gobiernan esta relación. Estas determinan cuando y como el receptor recibirá el evento.

CREACION DE EVENTOS

Los eventos se crean en el BUSINESS OBJECT REPOSITORY, transacción SWO1

Debemos especificar el tipo de objeto para el cual crear el evento. No se debe codificar nada, los datos que se deben ingresar son:

· Nombre del evento

· Parámetros del evento

Por ejemplo: podemos ven el en business object BUS2105 (solicitud de pedido) el evento “released”, su definición, parámetro asociados

LANZANDO EVENTOS DESDE APLICACIONES SAP

Antes de poder lanzar un evento por una aplicación, la creación del evento debe programarse en el programa de la aplicación.

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

Pero puede ser que tengamos que crear un evento nuevo. En este caso debemos definir como se lanzará el evento a partir de la aplicación.

En el caso de que el evento deba lanzarse desde un programa propio (de cliente) podemos programar el lanzamiento del evento fácilmente utilizando funciones que sap provee para tal caso.

· A traes 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 específico para cada aplicación

Los tres primeros casos son los más usados, el resto son específicos para determinados módulos y casos aislados.

LANZANDO EVENTOS CON CHANGED DOCUMENTS

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 deberemos controlar que el cambio será escrito con un documento de cambio, controlando el customizing de los campos o bien haciendo pruebas.

Para crear un evento de este tipo usaremo al transacción SWEC

TRANSACCION SWEC: lanza un workflo 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)

Podemos restringir más bajo que circunstancias queremos que se lacen el evento especificando campos de la tabla de campos relevantes su calor antiguo y su valor actual.

LANZANDO EVENTOS POR CAMBIO DE STATUS

El sistema viene por defecto con status predefinidos llamados “status de sistema”, no obstante y por customizing puede definirse nuevos status (de cliente).

Los status de sistema siempre son fijados por el sistema automáticamente.

L estatus de cliente deben ser fijados por el usuario

Para crear un evento de este tipo ejecutamos la transacción BSVW

TRANSACCION BSVW: para lanzar Workflows cuando se modifica el estado del sistema.

· Primero debemos seleccionar con qué tipo de status trabajar.

· Luego deberemos seleccionar el tipo de objeto

· Su evento

· Finalmente lo activamos.

LANZANDO EVENTOS MEDIANTE CONTROL DE MENSAJES

Si una aplicación de negocio usa el método de control de mensaje, para intercambiar información entro los involucrados en el proceso de negocio. Podemos configurar una mensaje para lanzar eventos.

La configuración de mensaje se realiza a través de la transacción NACE

UNIR EL EVENTO AL WORKFLOW

A través del WorkFlow Builder (transacción SWDD) podemos establecer el inicio automático de un workflow.

· Una vez posicionados en el workflow que deseamos iniciar con un evento, debemos parar a la cabecera del workflow.

· Indicamos 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. Podremos modificar el binding para agregar el parámetro que deseemos.

· Finalmente debemos activar el binding

Esta activación en la jerga de workflow se denomina “event lingkage”

NOTA: 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 evento y el workflow es a través de la transacción SWETYPV

Transacción SWETYPV: para realizar la activación del linkage entre el evento y el workflow.

CONDICIONES DE INICIO

Para configurar condiciones de inicio ejecutamos la transacción SWB_COND.

TRANSCCION SWB_COND: para realizar la configuración de las condiciones de inicio de Workflows.

Seleccionamos el tipo de objeto (en un ejemplo sería solicitud de pedido), aparecerán todos los eventos acoplados con workflow y seleccionamos uno.

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

Podemos verificar los eventos mediante la transacción SWU0 (simula eventos) y la transacción SWUE (crea eventos)

TRANSACCIONES SWU0 y SWUE: para simular y crear eventos respectivamente.

DESARROLLOS DE PROGRAMAS LANZA EVENTOS

El programa debe utilizar el módulo de funciones SWE_EVENT_CREATE

La estructura logis 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

Ejemplo de código:

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: objet_key like sweistcou-objkey.

Swc_container evt_contanier.

* WRITE PARAMETER INTO EVENT CONTAINET

swc_set_element evt_container ‘flag_equi_aender’ ‘X’.

* Compose objet key

asset_key_-company_code = ‘0001’.

assekt_key-asset_mo = ‘000000123456’.

asset_key-sub_number = ‘0100’.

objet_key = asset_key.

* Trigger the event

call function ‘SWE_EVENT_CREATE’

exporting

objtype = ‘BUS1022’

objkley = object_key

event = ‘changed’

tables

event_container = evt_container

exceptions

others = 01.

If sy-subrc ne 0.

Do your own error handling

endif

*start tRFC processing

commit work