Events Framework (Como Disminuir el Impacto de las Personalizaciones)

Una de las grandes desventajas de los procesos de “Customización” de los aplicativos PEOPLESOFT  es que se modifica el código estándar que viene con la aplicación,  lo cual deriva en un aumento considerable de la complejidad de los procesos de actualización del aplicativo, llegando hasta al punto de que las empresas optan por eliminarlos de su estrategia debido al costo que estos implicarían. 

Otra desventaja es que en algunos casos la modificación del código estándar entregado  por Oracle en dentro de sus aplicativos PEOPLESOFT lleva a la perdida de la garantía.

Una vez en la que estuve involucrado en un proceso de implantación de Oracle e-Business, me enteré de la existencia de algunas herramientas que hacen el proceso de “customización” de las aplicaciones de Oracle e-Business totalmente independiente del estándar, a continuación las enuncio (No se desesperen después de algunos renglones más entraremos en materia con PEOPLESOFT):

• Oracle Alert: Esta utilidad permite crear acciones a partir eventos que se ejecuten contra la base de datos (Actualizaciones, inserts, deletes etc). ¿En qué se diferencia esto de crear un trigger en la base de datos?  En que Oracle cancela la garantía de sus productos cuando uno utiliza triggers en la base de datos. Adicionalmente toda la administración y el desarrollo de estos comportamientos se puede realizar directamente a través del aplicativo (Resulta que para esta característica PEOPLESOFT tiene su par).

• Flexfields: Está característica permite a e-Business personalizar sus objetos del negocio sin la necesidad de modificar el estándar, por ejemplo si quieres agregar un nuevo campo a un proveedor, es solo configurar un flexfield y listo,  no tienes que hacer ningún desarrollo (Lo más cercano que he encontrado en people es la página de  personalización del componente de información de proveedores).

• Personalizaciones: Cada Form de Oracle Ebusiness tiene una opción de personalización,  esta opción permite modificar la interacción entre el usuario y el aplicativo, agregando mensajes,  cálculo de campos,  errores, etc. (Nada parecido he visto en peoplesoft)

Luego de ver y utilizar estas herramientas busque dentro de PEOPLESOFT algunos equivalentes y encontré un Equivalente al Oracle Alert y es el Events and Notifications Framework.

En esta entrada  a nosotros nos atañe la parte de Events. Según el peoplebook Events es una característica que permite definir, implementar y ejecutar lógica del negocio para eventos del negocio (un Evento del Negocio es por ejemplo la creación de un comprobante).

Para que nos puede servir a nosotros está utilidad (No desesperen, más adelante les mostrare un ejemplo de la  utilización):

• Podemos independizar el código que nosotros creamos del código estándar que viene con PEOPLESOFT. Algunas ventajas de este proceso serían:

o   Esto disminuirá el esfuerzo de los futuros upgrades.

o Volverá nuestro código transportable: cada vez que he hecho una customización en los proyectos la he perdido debido a lo difícil que se hace mudarla a las nuevas implementaciones debido a que incluye modificaciones a objetos estándar, y estos cambian de versión a versión etc. Con el Events Framework el código se encuentra en Applications Packages independientes que se pueden mover sin necesidad de transportar objetos estándar

• Múltiples comportamientos para un mismo evento del negocio:

o   Podemos crear diferentes códigos o diferentes versiones del mismo código que se ejecuta para cada evento del negocio: por ejemplo creamos un código que al crear un cliente envíe una notificación al administrador de clientes de la empresa; además otro código que llame a un servicio web para crear el cliente en otro repositorio

o   Podemos administrar que códigos queremos que se ejecuten dependiendo de las necesidades de cada cliente: resulta que nuestro primer cliente desea que se llame el servicio web y que envíe la notificación, el segundo cliente solo quiere llamar al servicio web y el tercer cliente quiere el comportamiento estándar,  solo con activar o desactivar el código se pueden obtener estos 3 comportamientos.

• El Events Framework permite monitorear y mantener detalladamente los eventos generados.

o   Se puede dejar un rastro de la ejecución de cada evento con información de su  ejecución.

o   Si un evento falla se puede reiniciar sin afectar el proceso estándar, por ejemplo si el llamado al web service que se hace al crear un cliente falla porque el servidor destino no estaba disponible en el momento,  podemos relanzar el evento desde el monitor cuando el servidor esté disponible.

Bueno ahora si manos a la obra, vamos a realizar un ejemplo de cómo generar, ejecutar, administrar y monitorear un Evento dentro de nuestro aplicativo PEOPLESOFT.

El evento que vamos a manipular va a ser la creación de un nuevo cliente dentro de PEOPLESOFT. Al momento de la creación de un cliente vamos a simular la creación del mismo cliente en 2 aplicativos externos a PEOPLESOFT. Esto podríamos hacerlo llamando 2 servicios web, uno para cada aplicativo que necesitemos, pero en este caso, con el fin de no salirnos del tema y de simplificar nuestro ejemplo lo aremos insertando la información del cliente en un registro para cada uno de los supuestos aplicativos.
 

• El Primer paso es crear el evento que vamos a manipular en nuestro ejemplo: para eso vamos a Inicio – Componentes de Empresa – Eventos y Notificaciones – Entorno de Eventos – Registro de Eventos y añadimos un valor (Por Ejemplo “NUEVO_CLIENTE”).

Evento	NUEVO_CLIENTE
Descr	Creación de Clientes
Descripción	Se dispara al momento de crear un nuevo cliente en el aplicativo.
Conexión Activada	Verdadero (Esto activa el log de los eventos)

• El segundo paso es crear los Gestores (El código que queremos que se ejecute al momento de crear un cliente). Un gestor es un Aplication Class, el cual se puede encontrar dentro de cualquier application package, pero debe incluirse dentro de un Subpackage llamado Handlers. A continuación podemos ver un ejemplo de cómo debe quedar la estructura:

• Cada application Class que vayamos a usar como gestor de nuestro evento debe tener un un método llamado ProcessEvent que recibirá como parámetro un objeto de tipo EOEN_EVENT_MANAGER:Base:baseEvent.  Nuestra Application Class debe quedar de la siguiente forma: 

import EOEN_EVENT_MANAGER:Base:baseEvent;

import EOEN_EVENT_MANAGER:Base:Types:ExceptionType;

class GestorEvent1

   /** Dummy Constructor. */

   method GestorEvent1();

   /** Process Event. */

   method ProcessEvent(&inEvent As EOEN_EVENT_MANAGER:Base:baseEvent);

private

   method Trace(&inHeader As string, &inDetail As string);

  

   instance EOEN_EVENT_MANAGER:Base:baseEvent &myEvent;

  

end-class;

method GestorEvent1

end-method;

method ProcessEvent

   /+ &inEvent as EOEN_EVENT_MANAGER:Base:baseEvent +/

  

   Local Record &recContext, &recAplicacion1;

  

  

   /* the following lines are required only if you want to pass detail information

    about Errors, Warnings  or other messages back to the Event Framework */

   Local EOEN_EVENT_MANAGER:Base:Types:ExceptionType &myExceptionType = create EOEN_EVENT_MANAGER:Base:Types:ExceptionType();

  

      &myEvent = &inEvent;

  

   If Not &inEvent.HasContextRecord Then

      &myExceptionType.MESSAGE_SET_NBR = 18137;

      &myExceptionType.MESSAGE_NBR = 6509;

      &myExceptionType.MSG_SEVERITY = "E";

      &myExceptionType.MESSAGE_TEXT = MsgGetText(18137, 6509, "no message found", &inEvent.EventID, &inEvent.EventNode);

      &myExceptionType.EXPLAIN_TEXT = "";

      &inEvent.HandlerStatus.AddException(&myExceptionType);

   Else

      try

        

         &recContext = &inEvent.ContextRecord;

        

         &myExceptionType.MESSAGE_SET_NBR = 0;

         &myExceptionType.MESSAGE_NBR = 0;

         &myExceptionType.MSG_SEVERITY = "M";

         &myExceptionType.MESSAGE_TEXT = MsgGetText(0, 0, "SE ha insertado el cliente: %1", &recContext.CUST_ID.Value);

         &myExceptionType.EXPLAIN_TEXT = "";

         &inEvent.HandlerStatus.AddException(&myExceptionType);

        

         &recAplicacion1 = CreateRecord(Record.PE_APP1_TBL);

         &recContext.CopyFieldsTo(&recAplicacion1);

         &recAplicacion1.Insert();

        

        

         %This.Trace("ProcessEvent", "Se insertó el registro para el cliente: " | &recContext.CUSTID.Value);

        

        

      catch Exception &ex

         &myExceptionType.MESSAGE_SET_NBR = 0;

         &myExceptionType.MESSAGE_NBR = 0;

         &myExceptionType.MSG_SEVERITY = "E";

         &myExceptionType.MESSAGE_TEXT = MsgGetText(0, 0, "Al intentar insertar el cliente %1 se genero la excepción %2", &recContext.CUST_ID.Value, &ex.ToString());

         &myExceptionType.EXPLAIN_TEXT = "";

         &inEvent.HandlerStatus.AddException(&myExceptionType);

      end-try

   End-If;

end-method;

method Trace

   /+ &inHeader as String, +/

   /+ &inDetail as String +/

   If &myEvent.HandlerTraceEnabled Then

      &myEvent.HandlerStatus.AddTraceEntry(&inHeader, &inDetail);

   End-If;

end-method;

• En el método ProcessEvent escribimos el código que deseamos que se ejecute al momento de llamar el Evento. El Objeto &inEvent de tipo baseEvent tiene una propiedad llamada “ContextRecord” que contiene el registro para el cual se está generando el evento. En nuestro ejemplo el ContextRecord se referirá al registro CUSTOMER que se está insertando dentro de nuestra base de datos.

• Para poder realizar registros en el log, tanto de mensajes como de errores (Al registrar errores el Events Framework nos permitirá relanzar los eventos), el parámetro &inEvent posee el método AddExceptions que recibe como parámetro un objeto de tipo EOEN_EVENT_MANAGER:Base:Types:ExceptionType. Con este método podemos agregar mensajes de severidad “E” (errores), “M” (mensajes) y “W” (Advertencias). Si agregamos algún mensaje de tipo “E” el Event Framework automáticamente marcará el evento como finalizado con error.

• La otra característica que posee el Event Framerwork es la activación del trace del proceso, para eso creamos el método Trace dentro de nuestro gestor.

• El segundo gestor va a ser exactamente igual, lo único que vamos a cambiar es el registro en el que vamos a insertar la información.

• Ahora tenemos que agregar los gestores al Evento que creamos previamente, en la mismo componente que se encuentra en la ruta a Inicio – Componentes de Empresa – Eventos y Notificaciones – Entorno de Eventos – Registro de Eventos buscamos el Evento NUEVO_CLIENTE y le agregamos los gestores para que quede de la siguiente forma:

 

• Activamos para los gestores el registro de todos los mensajes para que no solo incluya los errores en el log sino todos los mensajes que vamos a generar.

• Ahora vamos a hacer el llamado de nuestro evento, para esos debemos ir al registro CUSTOMER, ahí es donde debemos registrar el llamado a nuestro evento. Vamos al campo setid y al evento SavePostChange y agregamos el siguiente código:

 import EOEN_MVC:EOEN_MODEL:EOENInterface;

Local EOEN_MVC:EOEN_MODEL:EOENInterface &myEvent;

Local Record &recContext;

If GetRow().IsNew Then

   &myEvent = create EOEN_MVC:EOEN_MODEL:EOENInterface("", 0);

  

   &recContext = GetRecord();

   &myEvent.AddContextRecord(&recContext);

   &myEvent.RaiseEvent("NUEVO_CLIENTE");

End-If;

• Y listo, con lo anterior ya nuestro sistema empieza a generar eventos cada vez que creemos un nuevo cliente. Además el evento va a quedar registrado en el Monitor de Eventos que se encuentra en Inicio – Componentes de Empresa – Eventos y Notificaciones – Entorno de Eventos - Monitor de Eventos. El monitor se verá de la siguiente forma cada vez que alguien ejecute el evento:

• Si damos clic en gestores podemos ver el estado de nuestro evento.

• Como se puede ver uno de nuestros gestores finalizó en error, esto sucedió porque inserte la siguiente línea antes de llamar el insert del record.  Esta es una de las mayores ventajas que veo de este framework, ya que si nos equivocamos a la hora de escribir el gestor, y en algún momento se genera una excepción dentro del éste, tenemos la capacidad de ejecutar nuevamente el gestor (Opción Reejecutar) luego de corregir el código.

insert throw CreateException(0, 0, "El servicio no se encuentra disponible en el momento");

• Eliminamos la línea de código que se agregó para generar el error y reejecutamos el gestor.  Luego podemos ver que ya se finalizó correctamente la ejecución.  Todo esto sin la necesidad de detener los procesos de los usuarios.

Bueno algunas consideraciones finales:

• El integration Broker debe estar activo  para poder utilizar este framework.

• Se debe verificar que la cola EOEN_MSG_CHNL y las operaciones de servicio asociadas se encuentren activas y en ejecución

Listo eso es todo en esta entrada, espero que les haya parecido interesante y que les sea de utilidad en sus desarrollos.

Para nuestra próxima entrada veremos una forma de hacer notificaciones disminuyendo al máximo el componente técnico.