Archivos Planos con XML Publisher

En está nueva entrada vamos estudiar la forma de generar archivos planos utilizando XML Publisher y sin necesidad de crear objetos por el app designer ni de escribir código. 

Para poder poner en práctica la información que vamos a generar en está entrada,  es necesario tener conocimientos básicos de XML y del Gestor de Consultas de PEOPLESOFT. 

Las plantillas XML Publisher que nos permiten generar archivos planos son las plantillas eText. Estas plantillas son creadas en MS WORD y son formato RTF igual que las que se usan normalmente para generar los reportes en PDF. 

La diferencia de estás plantillas con las plantillas normales es la estructura que se debe definir.

Para el ejercicio de generación de plantillas eText de esta entrada vamos a utilizar la consulta conectada que creamos en la entrada anterior. 

Al igual que para una plantilla XML Publisher normal, lo primero que tenemos que tener para desarrollar nuestra plantilla es la estructura XML sobre la cual vamos a trabajar. Para nuestro ejemplo la estructura será la siguiente: Estructura XML. Está estructura se descarga desde la consulta conectada. .


Luego de definir la estructura XML definimos que tipo de plantilla vamos a generar.  Generalmente los archivos planos se pueden generar: de longitud fija o delimitados. 


Para definir una plantilla eText de longitud fija utilizamos el siguiente encabezado:

La propiedad <TEMPLATE TYPE> define que queremos un archivo plano de longitud fija o delimitado. Para un archivo plano delimitado la cabecera que se debe utilizar es la siguiente:

Luego de definir las  propiedades generales de la plantilla, se procede a definir los datos que se van a generar dentro del archivo plano. Para lo anterior debemos definir las siguientes propiedades. 

1. Definir el nivel dentro del XML del cual vamos a extraer la información. En nuestro caso el archivo plano debe tener un primer tipo de fila que contenga los datos del rol. Estos datos se deben tomar de la ruta ConnectedQuery/PE_CQ_ROLES. Con este dato definimos la propiedad <LEVEL> (Esto aplica tanto para los archivos delimitado como para los de longitud fija.)

Luego de definir el nivel se definen las propiedades de cada uno de los datos que se incluirán en el archivo y dentro del nivel que estamos configurando. Para un archivo de longitud fija se deben definir las siguientes propiedades:

<POSITION>Indica a partir de que posición se empezará a escribir el dato dentro de la fila que se está generando

<LENGTH>Indica la longitud que va a tener el campo dentro de la fila que se está generando

<FORMAT>Define el formato del campo. Las opciones son NUMBER, ALPHA y DATE

<PAD>Indica el carácter con el cual se debe rellenar el campo para completar la longitud total del campo.  Por ejemplo si queremos rellenar el campo con espacios a la derecha está propiedad debe ser R, ' ', si deseamos llenar el campo con ceros a la izquierda el valor debe ser L, '0'

<DATA>Indica el elemento xml del cual se extraerá la información. Dentro de este campo se pueden usar funciones como condicionales y funciones XPATH que permitan extraer información de niveles diferentes al que se está trabajando. 

<COMMENTS>Comentarios que no afectarán en nada la generación del archivo. 

En nuestro ejemplo para una plantilla de longitud fija está sección para los roles debe lucir de la siguiente forma:

Dentro de una plantilla delimitada la propiedades a definir para cada uno de los campos que  formaran una fila del archivo plano

<MAXIMUM LENGTH>Máxima longitud que podrá tener el campo

<FORMAT>Define el formato del campo. Las opciones son NUMBER, ALPHA y DATE

<DATA>Indica el elemento xml del cual se extraerá la información. Dentro de este campo se pueden usar funciones como condicionales y funciones XPATH que permitan extraer información de niveles diferentes al que se está trabajando. 

<COMMENTS>Comentarios que no afectarán en nada la generación del archivo. 

En nuestro ejemplo está sección para los roles debe lucir de la siguiente forma:


Longitud Fija

Delimitada

Cada vez que inicializamos una sección <LEVEL> debemos terminar esa sección con un <END LEVEL> en nuestro caso no hemos puesto aún el <END LEVEL> debido a que los roles tienen dos secciones hijas: Usuarios y Listas de Permiso,  entonces para lograr este comportamiento lo que hacemos es anidar otras secciones <LEVEL> antes de cerrar la que pertenece a los roles. 


Para anidar el <LEVEL> que nos mostrará los usuarios, debemos agregar una sección igual a la anterior pero en el campo <LEVEL> asociamos el nodo XML que pertenece a los usuarios,  y adicionalmente agregamos en <END LEVEL> ya que los usuarios no tienen ningún otro nivel anidado. La sección de usuarios quedaría de la siguiente forma: 


Longitud Fija

Delimitada

De la misma forma la sección para las listas de permisos quedaría asi:


Longitud

Delimitada

Listo, por último agregamos el <END LEVEL> de nuestra sección de roles y con esto finalizamos nuestra plantilla;




Longitud Fija

Delimitada

Las plantillas completas las podemos descargar de los siguientes enlaces: Longitud Fija y Delimitada


2. El siguiente paso es crear la definición del informe. Podemos utilizar el mismo origen de datos que utilizamos en la entrada anterior. El tipo de plantilla que debemos seleccionar es eTexto. 

3. Por último podemos ejecutar nuestro reporte por la ruta Inicio > Herramientas de Informes > XML Publisher > Gestor de Informes de Consulta.  Al ejecutarlo debemos seleccionar en formato "Texto" para que genere nuestro archivo plano.  Este proceso tiene un bug al momento de ejecutar un reporte que genera un archivo plano mediante una plantilla eText.  

Para corregir este bug se debe reemplazar el siguiente código que se encuentra en en app engine PSXPQRYRPT en la sección MAIN en el paso ExecRpt:

&oRptDefn.ProcessReport(&TemplateId, &LanguageCd, &AsOfDate, &oRptDefn.GetOutDestFormatString(&OutDestFormat));

Por el siguiente: 

      /*INICIO CHGA #001 */

      If &oRptDefn.TemplateType = "ETX" Then

         REM         Local File &fileCSV;

         REM         &fileCSV = GetFile(&ReportName | String(&ProcessInstance) | ".txt", "w", "UTF-8", %FilePath_Relative);

         REM         &fileCSV.WriteString(&oRptDefn.ProcessETextReport(&TemplateId, %Language_User, %Date));

         &oRptDefn.ProcessReport(&TemplateId, &LanguageCd, &AsOfDate, "TXT");

      Else

         

         /*FIN CHGA #001 */

         &oRptDefn.ProcessReport(&TemplateId, &LanguageCd, &AsOfDate, &oRptDefn.GetOutDestFormatString(&OutDestFormat));

      End-If;

Y listo con esto hemos creado un archivo plano utilizando las herramientas que el XML Publisher nos suministra, sin necesidad de escribir código (Bueno casi. ). 

Espero que esta entrada les sea de utilidad y nos vemos en la siguiente. 

Connected Queries

En esta entrada vamos a tratar una nueva característica presente en las tools 8.51 que lleva el nombre de Consultas Conectadas.

Como siempre para poder hacer una mejor explicación vamos a empezar con un Ejemplo.

Digamos que deseamos hacer un listado o reporte rápido que nos muestre cada uno de los roles que hay dentro del aplicativo y que adicionalmente liste cada uno de los usuarios relacionados al rol. Para cumplir con este requerimiento lo más facil es hacer una consulta por el gestor de consultas y listarla rápidamente. El select de la consulta quedaría de la siguiente forma:

SELECT A.ROLENAME, A.DESCR, B.ROLEUSER
FROM PSROLEDEFN A, PSROLEUSER B, PSOPRDEFN C
WHERE A.ROLENAME LIKE :1
AND A.ROLENAME = B.ROLENAME
AND B.ROLEUSER = C.OPRID
ORDER BY 1

Digamos que ahora queremos el listado de todos los roles junto a todos sus usuario y adicionalmente a sus listas de permisos. Para el requerimiento anterior ya no sería factible crear una única consulta. La opciones para cumplir este requerimiento serían las siguientes:

• Crear 2 consultas independientes por medio del gestor de consultas: una para los usuarios y otra para las listas de permisos
• A partir de las 2 consultas creadas previamente, crear un crystal que utilice subreportes para incluir las 2 consultas y asi generar un solo listado.
• Por último utilizar el Application Designer para crear la página de ejecución del reporte y poder generarlo. 

En conclusión demasiadas horas de desarrollo para un listado tan simple. Con la nueva herramienta de Consultas Conectadas este proceso no necesitará crear ningún objeto por el Application Designer, ni escribir una sola línea de código. Los pasos para solucionar el requerimiento serían:

• Crear una consulta que traiga todos los roles y su descripción (Consulta padre)
• Crear una consulta que traiga los roles junto a los usuarios asociados
• Crear una última consulta con los roles y cada una de las listas de permisos. 
• Crear la consulta conectada que enlace las 3 consultas creadas previamente
• Crear la plantilla XML PUBLISHER para generar el reporte
• Crear la definición del reporte XML PUBLISHER
• Y por último ejecutar el reporte por la ruta Inicio - Herramientas de Informes - XML Publisher - Gestor de Informes de Consulta

En conclusión ni una sola línea de código. 

Ahora si manos a la obra

1. Crear una consulta que traiga todos los roles y su descripción (Consulta padre). La consulta se va a llamar PE_CQ_ROLES y debe generar un select como el siguiente:

SELECT A.ROLENAME, A.DESCR
  FROM PSROLEDEFN A
  WHERE A.ROLENAME LIKE :1

2. Crear una consulta que traiga los roles junto a los usuarios asociados. La consulta se va a llamar PE_CQ_USERS_X_ROL y el select debe lucir de la siguiente forma:

SELECT A.ROLENAME, A.DESCR, B.ROLEUSER
  FROM PSROLEDEFN A, PSROLEUSER B, PSOPRDEFN C
  WHERE A.ROLENAME = B.ROLENAME
     AND B.ROLEUSER = C.OPRID
  ORDER BY 1

3. Crear una última consulta con los roles y cada una de las listas de permisos. La consulta se va a llamar PE_CQ_LISTAS_X_ROLES y el select debe lucir de la siguiente forma:

 SELECT A.ROLENAME, A.DESCR, C.CLASSID, C.CLASSDEFNDESC
  FROM PSROLEDEFN A, PSROLECLASS B, PSCLASSDEFN C
  WHERE A.ROLENAME = B.ROLENAME
     AND B.CLASSID = C.CLASSID
  ORDER BY 1

4. Crear la consulta conectada que enlace las 3 consultas creadas previamente. Ahora si lo importante. Primero vamos a Inicio - Herramientas de Informes - Consultas Conectadas - Inicio Rápido Cnslt Conectada y Agregamos una consulta conectada como se ve en las imagenes:

Paso 1

 Paso 2

Paso 3: En este paso agregamos el primer hijo de la consulta principal,  los hijos adicionales se deben hacer por  Inicio - Herramientas de Informes - Consulta Conectada - Gestor de Consultas Conectadas

 Paso 4: En este paso asociamos la consulta padre con la consulta hijo a través de un campo, en nuestro caso a través del campo ROLENAME que se encuentra asociado en las 3 consultas que componen nuestra consulta conectada.

 Paso 5:

Luego de finalizar con el asistente se debe ir a Inicio - Herramientas de Informes - Consulta Conectada - Gestor de Consultas Conectadas y completar la definición de la consulta, agregando el hijo faltante. La consulta conectada debe quedar como se ve en la siguiente imagen:

Paso 1: Se agrega la otra consulta hija

 Paso 2: Se relaciona la consulta padre con la consulta hija a través del ROLENAME

 Paso: Se finaliza la creación de la consulta conectada.

5.  Crear la plantilla XML PUBLISHER para generar el reporte. Lo primero que tenemos que hacer es dar clic en "Vista Pvia XML" en la ventada Inicio - Herramientas de Informes - Consulta Conectada - Gestor de Consultas Conectadas y a partir de este XML ROL_USER_LIST.xml generar una plantilla RTF de XML Publisher como la siguiente Plantilla.rtf. 

6. Crear la definición del reporte XML PUBLISHER. 

Lo primero es crear un origen de datos de XML PUBLISHER tal como se puede ver en la figura

Luego creamos una definición del reporte XML PUBLISHER como podemos ver en las imagenes siguientes:

7. Y por último ejecutar el reporte por la ruta Inicio - Herramientas de Informes - XML Publisher - Gestor de Informes de Consulta. Habiendo terminado los pasos anteriores podemos ejecutar nuestro reporte por la ruta referenciada. 

Y listo hemos creado un reporte con múltiples secciones sin necesidad de usar crystal ni de escribir una sola línea de código.  Espero que les sea de utilidad.

Herramientas de Notificación Parte III: Notification Framework

Para nuestra última entrada dedicada a los frameworks de notificación, vamos a hablar del “Notification Framework” el cual nos permite generar correos electrónicos y notificaciones a las listas de trabajo de los usuarios.

Digamos que queremos hacer una notificación que se dispare al momento de modificar o crear un nuevo cliente en nuestra aplicación.

Para lograr lo anterior lo primero que tenemos que hacer es agregar un proceso y una categoría al "Notification Framework". El proceso puede ser CustomerManagement y la categoría UpdateOrCreate. Para crear estos objetos nos dirigimos a Inicio - Componentes de Empresa - Eventos y Notificaciones - Entorno de Notificaciones - Registro de Notificaciones y creamos un registro que se vea como la imagen mostrada a continuación: 

El siguiente paso es crear el registro de contexto de nuestro proceso. El registro de contexto de un proceso contiene datos que nos permiten identificar los objetos a los que corresponde la notificación, además el registro de contexto de un proceso se puede visualizar en la consola de notificaciones lo cual hace más facil identificar las razones de la notificación.

Todo registro de contexto debe tener como mínimo el subrecord EOEN_LOG_KEY, adicionalmente para nuestro ejemplo vamos a incluir el  SETID y el CUST_ID del cliente que está siendo modificado; y el OPRID del usuario que está modificando o creando el cliente. El registro lo llamaremos PE_CUST_CTX. 

El registro debe quedar de la siguiente forma

Después de crear el registro de contexto vamos al registro CUSTOMER, al campo SETID y al evento SAVEPOSTCHANGE. 

Lo primero que vamos a hacer es importar los paquetes del "Notifications Framework" que vamos a utilizar:

import EOEN_MVC:EOEN_MODEL:*;

Luego vamos a declarar un objeto del tipo EOENInteface que es la clase que nos permite generar las notificaciones.

Local EOEN_MVC:EOEN_MODEL:EOENInterface &oEwnInterface;

A continuación creamos el objeto de tipo EOENInterface para el proceso CustomerManagement que acabamos de crear, el segundo parámetro es una instancia de proceso para la cual generamos un aleatorio (si estamos usando la clase EOENInterface dentro de un app engine podemos utilizar el ProcessInstance como segundo parámetro):

&oEwnInterface = create EOEN_MVC:EOEN_MODEL:EOENInterface("CUSTOMERMANAGEMENT", Int(Rand() * 100000000));  

Luego creamos el registro de contexto 

Local Record &ContextRec;

&ContextRec = CreateRecord(Record.PE_CUST_CTX);

Asignamos los valores del ContextRecord empezando por el proceso y la categoría; y continuando con los datos adicionales que definimos.

&ContextRec.EOEN_PRCS_NAME.Value = "CUSTOMERMANAGEMENT";

&ContextRec.EOEN_CATEGORY.Value = "UpdateOrCreate";

&ContextRec.SETID.Value =CUSTOMER.SETID.Value;

&ContextRec.CUST_ID.Value =CUSTOMER.CUST_ID.Value;

&ContextRec.OPRID.Value = %OperatorId;

Ahora iniciamos la categoría del objeto &oEwnInterface

&oEwnInterface.EOENCategory = "UpdateOrCreate";

Agregamos el Record de contexto al objeto:

&oEwnInterface.AddContextRecord(&ContextRec);

Digamos que queremos notificar al administrador (VP1)  vía correo electrónico sobre la modificación o creación del usuario, para lograr esto utilizamos el método  AddEmailByOprID. 

&oEwnInterface.AddEmailByOprID(%OperatorId);
&oEwnInterface.GenerateEmail( True);

Supongamos que también queremos notificar a los usuarios vía lista de trabajo a los miembros del rol "CUST_MANAGERS". Para lo anterior utilizamos el método GenerateWL:

&oEwnInterface.GenerateWL( True, "", "CUST_MANAGERS");

Lo otro que nos permite el "Notification Framework" es definir la URL a la que referencia la notificación, en nuestro caso sería la dirección del componente de clientes para el cliente que fue modificado.  

&oEwnInterface.EOENRedirectURL =
GenerateComponentPortalURL("EMPLOYEE", "ERP", MenuName.MAINTAIN_CUSTOMERS, "GBL", Component.CUSTOMER_GENERAL, "" ,"U", CUSTOMER.SETID, CUSTOMER.CUST_ID);

Por último llamamos el método log para generar la notificación:

Local array of string &ArrayOfBindVals;
&ArrayOfBindVals = CreateArray(CUSTOMER.CUST_ID, %OperatorId);  

&oEwnInterface.Log(0, 0, "Fue modificado un cliente", &ArrayOfBindVals);

Debemos recordar agregar el rol CUST_MANAGERS  a los usuarios a los cuales deseamos les sean notificadas las actualizaciones de los clientes en las listas de trabajo. También debemos recordar asignarle un correo electrónico al usuario VP1.

Luego podemos ir a cualquier cliente y modificarlo,  y revisar la notificación por la consola de notificaciones y se verá de la siguiente forma:  

 

Si damos clic en el link de ver contexto el sistema nos mostrará el registro de contexto que agregamos a nuestra notificación

Si damos cliente en el link  Ver Detalle Transacción el sistema nos llevará al cliente que fue modificado. 

Si ingresamos al sistema con un usuario que pertenezca al rol. CUST_MANAGERS y vamos a la lista de trabajo vamos a encontrar las notificaciones generadas, como se puede ver a continuación:

 Está información también la podemos visualizar en el correo del usuario VP1. 

Por último si queremos parametrizar el rol al cual queremos notificar, podemos hacer para todo el sistema o por unidad de negocio, para eso vamos a las ruta Inicio - Componentes de Empresa - Eventos y Notificaciones - Entorno de Notificaciones - Modific. Sistema Notificaciones o Modific. UniNeg Notificaciones, y ahí adicionamos un registro para el proceso y categoría que creamos, y asignamos el rol al que queremos notificar y el correo electrónico también. 

Bueno espero que podamos poner en práctica estas herramientas de las que hablamos en las últimas 3 semanas y que logren hacer nuestro trabajo más facil y de mejor calidad. Nos vemos la próxima semana nuevamente. Se me olvidaba acá les dejo el código completo:

import EOEN_MVC:EOEN_MODEL:*;

Local EOEN_MVC:EOEN_MODEL:EOENInterface &oEwnInterface;

&oEwnInterface = create EOEN_MVC:EOEN_MODEL:EOENInterface("CUSTOMERMANAGEMENT", Int(Rand() * 100000000));

Local Record &ContextRec;
&ContextRec = CreateRecord(Record.PE_CUST_CTX);
&ContextRec.EOEN_PRCS_NAME.Value = "CUSTOMERMANAGEMENT";
&ContextRec.EOEN_CATEGORY.Value = "UpdateOrCreate";
&ContextRec.SETID.Value = CUSTOMER.SETID.Value;
&ContextRec.CUST_ID.Value = CUSTOMER.CUST_ID.Value;
&ContextRec.OPRID.Value = %OperatorId;
&oEwnInterface.EOENCategory = "UpdateOrCreate";
&oEwnInterface.AddContextRecord(&ContextRec);
rem &oEwnInterface.AddEmailByOprID(%OperatorId);
rem &oEwnInterface.GenerateEmail( True);

&oEwnInterface.GenerateWL( True, "", "CUST_MANAGERS");
&oEwnInterface.EOENRedirectURL = GenerateComponentPortalURL("EMPLOYEE", "ERP", MenuName.MAINTAIN_CUSTOMERS, "GBL", Component.CUSTOMER_GENERAL, "", "U", CUSTOMER.SETID, CUSTOMER.CUST_ID);

Local array of string &ArrayOfBindVals;
&ArrayOfBindVals = CreateArray(CUSTOMER.CUST_ID, %OperatorId);

&oEwnInterface.Log(0, 0, "Fue modificado un cliente", &ArrayOfBindVals);

Herramientas de Notificación Parte II: Alert Framework

Bueno en esta segunda entrega sobre notificaciones vamos a ver el “Alert Framework”. Si no les gusto las notificaciones por medio de los FEEDS por las limitaciones que estos presentan, como son:  

• Tener que utilizar un software adicional para poder utilizarlo (el FeedReader) o

• que para usarlo nuestra aplicación debe estar publicada en internet si queremos que estas notificaciones no lleguen a cualquier sitio, sino solo nos servirán dentro de la red donde se encuentre instalada la aplicación.

El “Alert Framework” nos permite generar alertas a partir de un Query de la misma forma en que lo hacen los FEEDS, pero utilizando el correo electrónico, con esto superamos las limitantes anteriormente mencionadas.

Digamos que tenemos el mismo ejemplo que utilizamos con los FEEDS, el administrados de PEOPLESOFT de la organización desea recibir alertas cada vez que es creado o modificado un usuario dentro del aplicativo.

Lo primero que tenemos que hacer es crear el Query que vamos a utilizar. Para los FEEDS utilizamos el Query

SELECT A.OPRID,
                 A.OPRDEFNDESC,
                 TO_CHAR(CAST((A.LASTUPDDTTM) AS TIMESTAMP),'YYYY-MM-DD-HH24.MI.SS.FF')
  FROM PSOPRDEFN A

Así como está el Query no nos sirve para utilizarlo dentro del “Alert Framework” debido a lo siguiente:  

• El “Alert Framework” genera alertas para cada uno de los registros que retorne el Query, no como los FEEDS en los cuales el FeddReader se encargaba de identificar que alertas ya habían sido generadas y genera solo las faltanes.

• También es necesario informarle al ”Alert Framework” quien es el destinatario de la alertar, con los FEEDS el destinatario era aquel que se suscribía al FEED.

Para solucionar los anteriores inconvenientes vamos a modificar nuestro Query de la siguiente forma:

Primero vamos a agregar el rol PE_ALERT, el cual lo asignaremos a todos los usuarios a los que queramos notificarles.

También agregaremos una condición al Query para que solo nos traiga los usuarios modificados en la última hora.

Después de las anteriores modificaciones el Query nos queda de la siguiente forma:

SELECT A.OPRID, A.OPRDEFNDESC, TO_CHAR(CAST((A.LASTUPDDTTM) AS TIMESTAMP),'YYYY-MM-DD-HH24.MI.SS.FF'), C.EMAILID
  FROM PSOPRDEFN A, PSROLEUSER_VW B, PSUSEREMAIL C
  WHERE  ( B.ROLENAME = 'PE_ALERT'
     AND B.OPRID = C.OPRID
     AND C.PRIMARY_EMAIL = 'Y'
     AND ROUND((CAST(( CAST(SYSTIMESTAMP AS TIMESTAMP)) AS DATE) - CAST((A.LASTUPDDTTM) AS DATE)) * 1440, 0) < 60 )

La Expresión ROUND((CAST(( CAST(SYSTIMESTAMP AS TIMESTAMP)) AS DATE) - CAST((A.LASTUPDDTTM) AS DATE)) * 1440, 0) se forma a partir del MetaSql %datetimediff(A.LASTUPDDTTM, %Currentdatetimein).

Ya con este Query podemos empezar a crear nuestra alerta. Lo primero que tenemos que hacer es definir una notificación, para esto vamos a Inicio – Componentes de Empresa – Eventos y Notificaciones – Entorno de Notificaciones – Registro de Notificaciones, ahí agregamos un nuevo registro que quede de la siguiente forma:

Antes de crear nuestra alerta debemos definir el mensaje que queremos que se envíe en el correo electrónico, para eso creamos un registro en el catálogo de mensajes con el mensaje: “Se modificó o se agregó el usuario %1”

Después de que definamos nuestra notificación vamos a crear nuestra alerta. Esto lo hacemos por Inicio – Componentes de Empresa – Eventos y Notificaciones – Avisos – Definición de Alertas.

Utilizando la consulta PS_USER, el proceso PS_USERS y la categoría NOTIFICACIONES:

En la pestaña URL definimos los parámetros que el Framework va a utilizar para generar una URL para acceder al componente de perfiles de usuarios al usuario que fue creado o modificado, directamente desde el correo sin necesidad de hacer una búsqueda manual:

Nota: Para que este ejemplo funcione correctamente recomiendo realizarlo con el usuario VP1, adicionalmente para que el Link de Detalle de la Transacción funcione, debemos cambiar el nodo del objeto de portal PT_USERMAINT_GBL de LOCAL_NODE a ERP, esto lo puedes realizar por Inicio – Peopletools – Portal – Estructura y Contenido, y ahí se busca la ruta para encontrar el objeto.

En el link de claves de búsqueda, mapeamos las claves del componente de Perfiles de Usuario, en este caso solo el OPRID para que se acceda directamente al usuario solicitado. 

En la pestaña Mensaje colocamos los datos de la entrada que agregamos en el catálogo de mensaje y el campo de la consulta que trae el correo electrónico al cual queremos notificar.

En el link Parámetros Mensaje ingresamos para mapear los datos de la consulta con los parámetros que tiene nuestro mensaje, en este caso solo %1 que es el usuario que se modificó.

 

Con esta definición ya podemos poner a trabajar nuestro proceso de alertas.

Nota: Hay que verificar que se haya configurado el SMTP en el process scheduler y listo, podemos ejecutar el proceso.

Para ejecutar el proceso de alertas vamos a Inicio – Componentes de Empresa – Eventos y Notificaciones – Avisos – Ejecución de Alertas. Sí queremos que esto se haga automático debemos programar una recurrencia para el proceso y ya.

Para hacer la prueba podemos modificar cualquier usurario, ejecutar el proceso y verificar si se generó la alerta.

El “Alert Framework” deja registro de todas las notificaciones realizadas, este registro se puede ver por Inicio – Componente de Empresa – Eventos y Notificaciones – Entornos y Notificaciones – Consola de Notificaciones. En la ruta anterior buscamos todas las notificaciones del proceso PS_USERS. Ahí encontramos el detalle del proceso, incluso los correos electrónicos que fueron notificados. Si damos clic en detalles de la transacción el sistema nos llevará al componente de Perfiles de Usuario, al usuario que se modificó.

Adicionalmente el Alert Framework nos permite generar Alertas a la lista de trabajo de los usuarios, para lograr este comportamiento debemos ir a la ruta Inicio – Componente de Empresa – Eventos y Notificaciones – Entorno  de Notificaciones – Modific Sistema Notificaciones y agregar un registro como el siguiente:

Después de agregar este registro, el sistema además de enviar el correo, también  generará una entrada en la lista de trabajo de los miembros del rol PE_ALERT.

Nota: Para que el sistema agregué correctamente la entrada a la lista de trabajo debemos insertar el siguiente registro (Esto solo si no existe un registro previamente):

INSERT INTO PSWLINSTMAX VALUES ('EOEN_WL_NOTIFY','EOEN_WL_ROUTE' ,'ROUTE' ,'Error and Warning Notification', 1).

Bueno espero que les haya gustado está entrada, que puedan utilizar está información y que si tienen alguna duda me cuentan y vemos si yo también tengo la misma duda.

Herramientas de Notificación Parte I: FEEDS

Esta semana empezaremos una serie de 3 publicaciones enfocadas al tema de notificaciones. En esta primera entrada hablaremos de los FEEDS (http://es.wikipedia.org/wiki/Fuente_web). Para los que no estén familiarizados con los FEEDS a continuación podremos ver un ejemplo de un FEED y cómo se comporta; para los que ya estén familiarizados pueden pasar a la segunda parte.

A continuación vamos a ver un ejemplo de un FEED de una página de internet:

Digamos que nosotros somos muy fanáticos de la página de tecnología del periódico El Tiempo, y quisiéramos recibir una notificación cada vez que un artículo nuevo sea publicado en dicha página. Resulta que está página ofrece el servicio de FEEDS. Lo primero que debemos hacer para utilizar este servicio, es instalar un lector de rss o Feedreader (Outlook, Firefox, IE y Thunderbird lo tienen incorporado). Para nuestro ejemplo utilizaremos Feedreader el cual podemos descargarlo e instalarlo desde la dirección http://www.feedreader.com/download. Luego de instalarlo vamos a la página www.eltiempo.com y buscamos el siguiente link en la parte final de la página:

Luego le damos clic en la opción de tecnología y se copia la dirección http que aparece:

La dirección es la siguiente: http://www.eltiempo.com/tecnologia/rss.xml

Abrimos el FeedReader que acabamos de instalar. Luego vamos al menú Archivo - Nuevo - Canal y pegamos la dirección como podemos ver en la imagen y luego damos aceptar.

¿Qué sucederá a partir de ahora?, cada nuevo artículo de la sección de tecnología que sea publicado, será notificado al feedreader automáticamente y no nos perderemos ninguna información que allí publiquen.

Bueno ahora sí, ¿cómo aplicamos está tecnología a nuestras necesidades de notificación?, por ejemplo, que tal si el administrador de PEOPLESOFT del cliente quiere estar al tanto de todos los usuarios que se van creando o modificando dentro del aplicativo, entonces solicita que creemos una notificación para que cuando modifiquen un usuario o creen un usuario se genere un correo electrónico a su cuenta de correo o a la cuenta de correo de un grupo de usuarios para realizar el monitoreo.

La primera reacción del consultor es solicitar la modificación de la página del Administración de usuarios que incluya modificar el PEOPLECODE de los records involucrados y generar un correo electrónico, además de crear una página de parametrización donde se incluyan los usuarios a los que se les debe enviar el correo. Tiempo de Análisis, Diseño y Desarrollo 32 horas, resultado: modificación del estándar, posibles incidencias, necesidad de la disponibilidad del equipo técnico etc etc etc.

Con la tecnología del Feed Publishing Framework incluida en las Tools 8.51 podemos cumplir el anterior requerimiento con un mínimo esfuerzo técnico. El proceso sería crear un Query por el gestor de consultas que consulte la tabla de usuarios OPRDEFN, y el Feed Reader se encarga del resto; o sea nada de desarrollo técnico, nada de modificación del estándar etc. A Continuación podemos ver un ejemplo de cómo podemos solucionar el requerimiento:

creamos una consulta por el gestor de consultas que quede de la siguiente forma (Bueno cuanto tiempo le quitamos al técnico preguntandole como se llama el record donde se almacenan los usuarios?):


SELECT A.OPRID,
A.OPRDEFNDESC,
TO_CHAR(CAST((A.LASTUPDDTTM) AS TIMESTAMP),'YYYY-MM-DD-HH24.MI.SS.FF')
FROM PSOPRDEFN A

Despues de guardar la consulta, en la parte de abajo del gestor de consultas encontraremos un link que se llama “Publicar como Fuente”. Le damos clic:

En la siguiente pantalla dejamos los datos sin modificaciones.

 

Luego damos clic en el link Opciones Avanzadas y las dejamos como se ve en la imagen. Se deben verificar el Id Entrada y el Actz Entrada ya que esos campos son los que utiliza el feedreader para verificar si es una entrada nueva o una entrada ya actualizada, si esos campos no se parametrizan correctamente, cada vez que el feedreader consulte la información, cargará todas las entradas y las duplicará.

Ahora le damos acep y luego Publicar. Lo anterior nos lleva a la pantalla de administración del feed:

Haciendo clic en el link PR_USER, people nos lleva a la ruta donde queda publicado nuestro feed, o sea la ruta que debemos agregar a nuestro Feedreader.

Para mi caso la ruta que generó fue http://psappweb:8100/PSIGW/HttpListeningConnector/feeds/RealtimeQueryFeed?FEED_ID=ADMN_PR_USER&S=P&PORTAL_NAME=EMPLOYEE&NODE_NAME=ERP&languageCd=ESP&To=PSFT_EP

Por último vamos al FeedReader, y abrimos el menú Archivo - Nuevo - Canal, copiamos la ruta y le damos aceptar.

De ahora en adelante el FeedReader nos traerá los usuarios existentes hasta el momento, y cada vez que cambie un usuario o se cree uno nuevo, el FeedReader creará una nueva entrada informándonos.

Unas últimas consideraciones:

Si queremos que solo unos pocos usuarios puedan acceder a este Feed ,en las opciones avanzadas en vez de seleccionar Fuente Pública seleccionamos seguridad de consultas y así, a través de la administración de la seguridad de consultas, la cual puede ser por rol, administraríamos el acceso para que no todos puedan ver esa información.

Por último son necesarias algunas configuraciones a nivel del integration broker para que esto funcione en especial la configuración del usuario en el nodo ANONYMOUS para poder hacer la prueba.

Si desean información adicional sobre el tema o si quieren conocer las habilidades adicionales del Feed Publishing Framework pueden encontrarla en http://download.oracle.com/docs/cd/E18083_01/pt851pbr0/eng/psbooks/tfeed/book.htm.

Bueno acá termina la entrada de esta semana, espero les sea de utilidad. Esperen la próxima semana otras técnicas para generar notificaciones.