Con las nuevas tecnologías, es el iFlow el que se está convirtiendo en el principal protagonista en cuanto a los flujos de trabajo se refiere, pero no hay que olvidar los míticos Workflows de backend. En este caso se quiere recordarlos, pero no haciendo mención de los clásicos Business Objects, sino a las Clases utilizadas en Programación Orientada a Objetos.
Para ello se crea una clase Z desde la transacción SE24, añadiendo los siguientes objetos, imprescindibles para su correcto funcionamiento, en la pestaña Interfaces: BI_OBJECT, BI_PERSISTENT y IF_WORKFLOW.
De esta manera se heredan automáticamente los siguientes métodos:
Es muy importante el método FIND_BY_LPOR, que se ejecutará cada vez que implícitamente sea necesario instanciar la clase ABAP. De esta manera, la sentencia necesaria en ella será el CREATE OBJECT, devolviendo en el parámetro RESULT el resultado de su ejecución.
Se añade un evento en su pestaña correspondiente, en este caso el nombre del evento elegido para este fin, es el CREATED con parámetro de entrada su ID y sus propiedades “Evento de Instancia Público”.
A continuación, se crea el Workflow de la misma manera que siempre; se realiza de la misma forma independientemente se trate de una clase ABAP o un BO, utilizando las transacciones tradicionales como la PFTC o SWDD.
En la pestaña de eventos desencadenantes se especifica el evento recién creado (asociado a la clase):
A la hora de la programación, para lanzar el evento que desencadena el Workflow, mencionar que si antes se utilizaba la función SWE_EVENT_CREATE (o bien SAP_WAPI_CREATE_EVENT…), en el caso de eventos de clases es necesario utilizar el método RAISE de la clase CL_SWF_EVT_EVENT.
Se añade al container del Workflow un nuevo objeto haciendo referencia a la clase protagonista en el mismo:
En este caso se ha creado una copia de la tarea estándar de decisión general en la que se añade un nuevo objeto del mismo tipo que la clase que se está tratando.
Se realiza la asignación de responsables, marcando la propiedad de Tarea General, para que pueda ser tratada por cualquier persona que la reciba en el Workplace o Bandeja de Entrada.
Se modifica el binding entre el Workflow y la Tarea añadiendo el objeto entre ambas.
Se realiza una prueba unitaria de este pequeño Workflow pulsando el botón de testear en el Workflow Builder. Se indica como parámetro de entrada al mismo un ID, como por ejemplo el 0000000100 y se comprueba que en la tarea de decisión está el objeto correctamente:
Al hacer doble-click en el mismo se ejecuta la lógica programada en el método heredado del Objecto BI_OBJECT “BI_OBJECT~EXECUTE_DEFAULT_METHOD” en el que, a su vez, se indica que se realiza la llamada al método display del mismo (mostrando su contenido):
Como se puede comprobar, utilizando las clases no son necesarias las macros (temidas en alguna que otra ocasión) utilizadas por el motor de SAP, a la hora de realizar la lógica de programación para un determinado Workflow.
Aunque no serán fáciles de olvidar, ya que hay muchos Workflows estándares que se utilizan y de los cuales nos aprovecharemos en todas las ocasiones posibles.
Esperamos que este artículo te hayan sido de utilidad. Si tienes alguna pregunta no dudes en dejarla en los comentarios o ponerte en contacto con nosotros.
