Integration Broker (Parte 13) Version Tools hasta 8.46

Conversión de Datos

La conversión de datos resulta más adecuada para modificar el contenido de un mensaje que su estructura, aunque también se pueden realizar cambios de estructura locales. Este proceso resulta más apropiado cuando los sistemas de emisión y recepción utilizan valores de campos diferentes o combinaciones distintas de campos y sus valores, para representar la misma información.


La aplicación A transmite nombres de clientes utilizando cuatro campos: cargo, nombre, segundo nombre y apellido.

La aplicación B utiliza dos campos: nombre y apellido. No utiliza cargo y considera el segundo nombre parte del primero.

La aplicación C sólo utiliza un campo: número de cuenta.

Interpretar las representaciones que utilizan las otras dos. Integración con Mensajería puede aplicar un programa de transformación para convertir cada una de estas representaciones a una versión adecuada a la aplicación de destino.
Un nodo de Integración con Mensajería puede almacenar en su depósito de conjuntos de códigos los campos y valores equivalentes que utilice otro nodo. Cuando recibe un mensaje del nodo que contiene un nombre de cliente, puede utilizar su depósito de conjuntos de códigos para convertir la información como desee. Asimismo, puede invertir el proceso para los mensajes que envíe al otro nodo.

Para una integración determinada, las circunstancias y preferencias del usuario determinan la forma de realizar una conversión de datos. Puede repartir la actividad de la conversión entre los nodos participantes, o bien designar un nodo de la Integración con Mensajería para que realice todas las conversiones de datos, ya se trate de mensajes de entrada, de salida o redirigidos a otros nodos. En la medida de lo posible, utilice un único nodo, ya que se reducirá la necesidad de duplicar los datos del depósito.

Codeset Group, Codeset Name, Codeset Value

El depósito de conjuntos de códigos contiene los siguientes elementos, gestionados como componentes de PIA.

• Code Setgroup/Grupo de conjuntos de códigos


• Codeset Name/ Conjunto de códigos


• Codeset Value/ Valores de conjuntos de códigos

Code Setgroup/Grupo de conjuntos de códigos: contiene una lista de los principales campos de datos y sus valores que un determinado nodo podría enviar en un mensaje inicial.

Codeset Name/ Conjunto de códigos: contiene un determinado conjunto de parejas de valores de coincidencia/nombre seleccionados del grupo de conjuntos de códigos existente.

Codeset Value/ Valores de conjuntos de códigos: contiene el valor predefinido como valor de retorno.

El otro elemento clave en la conversión de datos es el programa de conversión, que activa los conjuntos de códigos y los valores del conjunto de códigos diseñados por el usuario.

Filtrado

El filtrado se utiliza para determinar si un mensaje debe enviarse a su destino en función del filtrado de su contenido.

Ejemplo:
Si la unidad de negocio = “USA”, el mensaje se enviará a su destino.Se realiza mediante Peoplecode. Si actualmente el mensaje está en un proceso de transformación, el desarrollador simplemente deberá añadir un paso de PeopleCode. Normalmente, este paso será el primero de la transformación, pero es el desarrollador quien debe decidir en qué paso se debe realizar el filtrado.


/* Get the data from the AE Runtime */
Local TransformData &incomingData = %TransformData;

/* Set a temp object to contain the incoming document */
Local XmlDoc &tempDoc = &incomingData.XmlDoc;

/* Find the status code */
Local string &statusCode = &tempDoc.DocumentElement.FindNode(“STATUS”).NodeValue;

/* Make sure the status code is “Open” */
If &statusCode <> “Open” Then

/* Clear out the doc and put in the “Filter” root node */
If (&tempDoc.ParseXmlString(““)) Then

/* Set the root node value to be the reason for failing filter */
&tempDoc.DocumentElement.NodeValue = “Status Code of '“ &statusCode “' is not allowed.”;

/* Set the status of the transformation to 1 for failed filter*/
&incomingData.Status = 1;
End-If;
End-If;

Integration Broker (Parte 12) Version Tools hasta 8.46

Transformaciones

La finalidad de aplicar una transformación a un mensaje es que su estructura cumpla con los requisitos del sistema de destino.

En un sistema de destino, existe un campo denominado Purchase Order (pedido), mientras que en PeopleSoft se denomina PO. El programa de transformación interpretará las etiquetas XML para que sean coherentes con las del sistema de destino.

PeopleSoft admite la utilización de código XSLT (Extensible Stylesheet Language Transformation) y de PeopleCode, incluidos en su programa de transformación como una o más acciones del tipo XSLT o PeopleCode respectivamente.

Las transformaciones pueden ser utilizadas tanto en mensajes inbound como en mensajes outbound para cambiar la estructura o el valor de los datos enviados o recibidos.

Las transformaciones se utilizan asociadas a RelationShip.



Los campos tienen la misma longitud y tipo pero se llaman distintos. Se puede utilizar Alias.

1. Una Transformación es automáticamente invocada por el Integration Engine basada en la RelationShip seteada entre los nodos.
   


2. Uno de los pasos del programa contiene una acción definida como XSLT.
   
   
3. Para utilizar esta estructura, el Application Engine del tipo Transform Only (sólo transformación)
   
   

XSLT: (NOTA: se saco de todas las lineas el primer "<" porque el blog no deja visualizarlo correctamente.)

?xml version="1.0"?>
xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
xsl:template match="IC_MSG_CUST">
IC_MSG_CUST>
xsl:apply-templates/>
/C_MSG_CUST>
/xsl:template>
xsl:template math= "IC_MSG_EMPL">
MSG_EMPL>
SETID>
EMPLID>
EMPL_STATUS>
NAME2>
NAMESHORT>
/MSG_EMPL>
/xsl:template>
xsl:template match = "FieldTypes">
FieldTypes>
IC_MSG_EMPL class="R">
SETID type="CHAR"/>
EMPLID type="CHAR"/>
EMPL_STATUS type="CHAR"/>
NAME2 type="CHAR"/>
NAMESHORT TYPE="CHAR"/>
/IC_MSG_EMPL>
PSCAMA class="R">
LANGUAGE_CD type="CHAR"/>
AUDIT_ACTN type="CHAR"/>
BASE_LANGUAGE_CD type="CHAR"/>
MSG_SEQ_FLG type="CHAR"/>
PROCESS_INSTANCE type="NUMBER"/>
PUBLISH_RULE_ID type="CHAR"/>
MSGNODENAME type="CHAR"/>
/PSCAMA>
/FieldTypes>
/xsl:template>
/xsl:stylesheet>

Existen programas para la edición de XSLT (No Peoplesoft)

Relationship

Para usar las transformaciones primero se hace una RELATIONSHIP que indica con que NODOS existen TRANSFORMACIONES. Es quien indica las transformaciones que hay entre nodos (relación entre nodos)

El programa de AE del proceso de transformaciones se activa automáticamente mediante el motor de integración, en función de las relaciones (Relationship) entre nodos que se hayan definido para una determinada transacción.

La relación puede contener varias transformaciones diferentes para diversos mensajes, por lo que el nombre de la relación debe identificar al nodo.

La relación se define en la base de datos de la que parte el proceso de transformación.

En el ejemplo siguiente, vamos a utilizar la relación PSFT_HR para indicar que contiene transformaciones entre el nodo local y el nodo PSFT_CR.

Esta relación sólo puede utilizar las transacciones que se hayan incluido en las definiciones de los nodos seleccionados.

1. Se agregan las transacciones que vas a ser relacionadas
   
   
   
   



2. Initial Node/ Result Node: Seleccione el nodo inicial y el nodo resultante a los que está asociada cada transacción. Éstos deben ser los dos nodos definidos para la relación seleccionada.
   Request Message Name: Seleccione el nombre del mensaje de petición inicial y resultante que debe transmitir cada transacción. (Origen/Destino) Request Message Version : Seleccione la versión del mensaje de petición de origen y de destino que debe transmitir cada transacción

Esta relación sólo puede utilizar las transacciones que se hayan incluido en las definiciones de los nodos seleccionados. Como ha seleccionado cada parámetro de la transacción (nodo, tipo de transacción, nombre del mensaje de petición y versión del mensaje de petición), las opciones disponibles para el resto de los parámetros se reducen en función de los que acaba de seleccionar para definir transacciones existentes. Por ejemplo, si ha seleccionado un nodo que sólo tiene definidas transacciones de entrada asincrónicas, el único tipo de transacción disponible será Inbound Asynchronous.

El programa de transformación de peticiones se utiliza tanto para transacciones sincrónicas como asincrónicas.
El programa de transformación de respuestas sólo se utiliza para transacciones sincrónicas.

Integration Broker (Parte 11) Version Tools hasta 8.46

Testeo de Mensajes

Un mensaje de prueba proporciona información muy útil sobre la definición de mensaje seleccionada y su PeopleCode asociado. Puesto que el mensaje no se envía realmente, la creación de un mensaje de prueba no constituye una prueba completa de envío y recepción.

1. En la definición de mensaje, haga clic con el botón derecho del ratón en la versión del mensaje que desee probar y, a continuación, seleccione Create Test Message, Create Test Message en el menú.
   
   
2. El sistema muestra la vista Create Test Message.Se ve un mensaje de prueba que muestra la estructura del mensaje, como si se enviara. Active la casilla de selección Show Common Message Attributes para visualizar los campos PSCAMA del mensaje de prueba. PSCAMA, que es la abreviatura de PeopleSoft Common Application Message Attributes, es un registro que añade PeopleTools a cada nivel de la estructura del mensaje durante el proceso. No está visible en la utilidad de diseño de mensajes, pero puede hacer referencia a él en los programas de PeopleCode de publicación y subscripción, y visualizar su contenido en el monitor de mensajes.
   
   Para introducir valores de prueba, haga doble clic en el campo y añada los datos.
   
   Haga clic en OK cuando haya añadido los datos
   

3. El sistema le indicará el número del mensaje creado. Visualice el mensaje en el monitor de mensajes.
   
   
   

Prueba del PeopleCode de suscripción

Una vez añadido el PeopleCode de suscripción a la definición de mensaje, se puede probar el proceso de suscripción en Application Designer sin dejar que el sistema de publicación envíe el mensaje. También puede depurar el PeopleCode de suscripción, en caso de que se hayan producido errores, activando la utilidad de depuración de PeopleCode.
En primer lugar, debe crear un mensaje de prueba para que el PeopleCode de suscripción se procese en la base de datos suscriptora.

1. Haga clic con el botón derecho del ratón en el PeopleCode de suscripción y seleccione Run PeopleCode.
   
   
   
2. El sistema presentará un cuadro de diálogo para el ID de publicación. Este número se ha generado automáticamente al crear el mensaje de prueba. En este ejemplo, el ID de publicación es 1.
   


3. Cuando el PeopleCode de suscripción haya terminado de ejecutarse, el sistema presentará el siguiente mensaje:

Testeo de Mensajes con SendMaster

Send Master es una utilidad que le permite probar el proceso general de mensajería de Integración con Mensajería, incluidas las funciones de conector de interpretación, conector de destino, reconocimiento de conectores y las transacciones de Integración con Mensajería.

Puede utilizar Send Master para enviar mensajes mediante conectores HTTPs. Send Master le permite realizar las siguientes actividades:

Generar mensajes y enviarlos mediante conectores HTTPs a servidores Web o a servidores de aplicaciones de PeopleSoft, para probar las funciones de conector de destino y de interpretación en la pasarela de integración.

• Probar la función de reconocimiento de conectores.


• Activar funciones de GET y ejecutar pings para las pasarelas de Mensajería y para los servidores externos.


• Imitar el envío de mensajes a Integración con Mensajería, así como los mensajes enviados desde el motor de integración a la pasarela de integración.


• Automatizar el proceso de prueba, de manera que pueda crear grupos de diferentes tipos de mensajes y probarlos con un simple clic.


• Destacar los grupos de prueba que contienen proyectos con un simple clic.
  

(Para acceder a Send Master, debe tener instalada la pasarela de integración. Para abrir Send Master, ejecute los archivos startsendmaster.bat (Windows) o startsendmaster.sh (UNIX), ubicados en el directorio de la pasarela de integración.)

1. Nombre del Proyecto
   
2. Server URL: El URL del servidor indica el conector de interpretación que se va a utilizar para probar el mensaje.
   
3. Project Type (tipo de proyecto): Al tratarse de un archivo externo que no tiene el formato de PeopleSoft, el project type será un archivo de entrada.
   Headers (cabeceras): La información de la cabecera debe incluir el nombre del mensaje y el nombre del nodo que está enviando los datos.
   • MessageName (nombre del mensaje)
   • From (nodo de origen)
   
4. Input Information (información de entrada): XML en este caso. (permite probar los servidores que van a recibir datos de MIME en formato de PeopleSoft a través de HTTPs.)
   
5. La respuesta al mensaje aparecerá en la ventana Output Information (información de salida).
   

Integration Broker (Parte 10) Version Tools hasta 8.46

Monitoreo de Mensajes

El Message Monitor es una herramienta del sistema similar al Process Monitor, pero dedicada a los Mensajes. Es utilizada para el monitoreo de la información de las transacciones de mensajes Sincrónicos como asincrónicos, datos sobre el estado de los mensajes y otra información relacionada con el motor de integración. Permite visualizar errores y realizar correcciones, así como reenviar los mensajes en el caso necesario.

Monitor de Mensajes

Mediante este es posible visualizar el nodo de donde se envió el mensaje, y hacia donde, como así también que datos fueron enviados.

Overview: Provee información del estado de los mensajes.

Message Instance: Se muestran todos los mensajes asincrónicos de nodos remotos o que fueron publicados

Pub Contracts: Muestra todos los mensajes outbound enviados a otros nodos

Sub Contracts: Muestra los trabajos ordenados por ejecución de los PeopleCode.

Synchronous Messages: Muestra los mensajes sincrónicos inbound de los nodos remotos que publicaron.

Channel Status: Muestra en estado de los canales

Node Status: Muestra el estado del nodo local. También se puede hacer un Ping a otros nodos para ver si están habilitados.

Domain Status: Estado del Dominio, Activo-Inactivo.

Estadisticas

Queries: Provee un numero de Querys.

Visualización de Errores

El Monitor de Mensajes provee una pagina con información de Errores, si es que los hubo en el envió del Mensaje.

XML Transmitido

Integration Broker (Parte 9) Version Tools hasta 8.46

Mensajes de Publicación Asincrónicos

1. Un evento de gestión activa el mensaje - &MSG.Publish(). El mensaje pasa a la cola de mensajes.

• Estado de la instancia del mensaje = NUEVO.
  
• El emisor encuentra la instancia del mensaje NUEVA y la envía al gestor.
  

2. El gestor lee el mensaje de publicación y realiza lo siguiente:
Estado de la instancia del mensaje = EN PROCESO.

• Ejecuta las reglas de la ruta de publicación para saber el destino de la publicación especificada.
  
• Ejecuta las reglas de la ruta de suscripción para saber si la publicación se va a procesar de forma local.

3. Como se ha indicado el envío a un nodo remoto, el gestor del mensaje realiza lo siguiente:

• Crea un contrato de publicación para que lo trate el emisor de la publicación.
  
• Envía una llamada asincrónica al emisor de la publicación para notificarle que tiene trabajo.
  

4. El emisor de la publicación lee el contrato de publicación y realiza lo siguiente:

• Estado del contrato de publicación = NUEVO.
  
• Estado de la instancia del mensaje = FINALIZADO.

5. Notifica al gestor de la publicación que debe realizar un envío HTTP del mensaje de publicación a la Pasarela de Integración con Mensajería.

6. La Pasarela de Integración con Mensajería envía el mensaje de publicación al nodo remoto. Si el nodo remoto pertenece a PeopleSoft, mediante una llamada sincrónica a través de Jolt se envía el mensaje a un servidor PSAPPSRV del dominio del servidor de aplicación.

6A. El nodo de destino está disponible.

• Estado del contrato de publicación = EN PROCESO.
  
• PSAPPSRV muestra que el mensaje ha sido enviado al nodo remoto. Este estado se envía mediante la pasarela al emisor de la publicación, al nodo original.
  
• Estado del contrato de publicación = FINALIZADO.
  

6B. El nodo de destino no está disponible.

• Estado del contrato de publicación = REINTENTO.
  
• En el servidor de aplicación se puede determinar el número de reintentos posibles para el gestor de la publicación. Cuando se han ejecutado todos los reintentos, el estado del contrato de publicación es de superación del tiempo límite.
  
  

Mensajes de Suscripción Asincrónicos

1. El mensaje llega mediante la Pasarela de Integración con Mensajería. A continuación, PSAPPSRV crea un mensaje de publicación para que gestione de manera local.

• Estado de la instancia del mensaje = NUEVO.

2. El gestor del mensaje de publicación crea el contrato de suscripción.

• Estado de la instancia del mensaje = EN PROCESO.
  
• Crea un contrato de suscripción para que lo trate un segundo emisor de la publicación.

3. Envía una llamada asincrónica a este segundo emisor de la publicación para notificarle que tiene trabajo.

4. El emisor de la suscripción lee el contrato de suscripción y realiza lo siguiente:

• Estado del contrato del mensaje = NUEVO.
  
• Estado de la instancia del mensaje = FINALIZADO

5. Empieza a trabajar en la suscripción.

• Estado del contrato de suscripción = INICIADO.
  

6. Notifica al gestor de la suscripción que debe ejecutar el PeopleCode de suscripción para el contrato.

• Estado del contrato de suscripción = EN PROCESO.

7. Todos los programas PeopleCode permiten actualizar las tablas de datos de la aplicación.

7A. Si la actualización de la aplicación es correcta: Estado del contrato de suscripción = FINALIZADO.

7B. Si la actualización de la aplicación es incorrecta: Estado del contrato de suscripción = ERROR.

Mensajes Sincrónicos

Las transacciones sincrónicas sólo pueden tener dos estados: finalizado o error. El evento de gestión enviará la petición sincrónica mediante la Pasarela de Integración.

Si el nodo de destino está disponible, se recibirá una respuesta correcta. Por el contrario, si el nodo de destino no está disponible, se recibirá un mensaje de error.

Estado de los Mensajes Asincrónicos

Estado de los Mensajes SincrónicosMensajes Sincrónicos: Este tipo de mensajes pueden tener solamente 2 estados, DONE o ERROR.

Error: Cuando ocurre un error durante el procesamiento del mensaje. Hay que intervenir.

New: Se ha escrito en la base, pero no fue despachado.

Started: Cuando el despachador lo pasa al Handler, pero este no lo recibe.

Working: Cuando el Handler lo acepta y es procesado.
Done: Cuando el Handler lo procesa correctamente. Dependiendo del tipo de proceso, se estara
monitoreando: Message Instante.—Publication Constracts.--- Suscription Constracts.
Retry: Cuando surge un error y el sistema reenvia el mensaje.
TimeOut: El sistema ha reenviado un numero de veces el mensaje sin éxito.
Edited: Los datos publicados por el mensaje han sido editados.
Cancelled: Cuando se cancela el mensaje. Este no se precesa hasta que se reenvie.

Integration Broker (Parte 8) Version Tools hasta 8.46

People code de Publicación de MESSAGES

Local Message &MSG;

&MSG = CreateMessage(Message.SCHOOL_SYNC);

If &MSG.IsActive Then
&MSG.CopyRowsetDelta(GetRowset());
&MSG.Publish();
End-if;


Peoplecode de Suscripción de MESSAGES
(Este código esta en el Mensaje y se ejecuta cuando llega Mensaje.)

Local Message &Message;
Local Rowset &Rowset;
Local Record &rSCHOOL, &Record;
&Message = GetMessage();
&rSCHOOL = CreateRecord(Record.PSU_SCHOOL_TBL);
&Rowset = &Message.GetRowset();
/* Multiple level 0 rows may exist in AE batch programs,
but not with online panel processing... */
&Record = &Rowset(1).PSU_SCHOOL_TBL;
&Action = &Message.GetRowset()(1).PSCAMA.AUDIT_ACTN.Value;
Evaluate &Action
When = "A"
/* School was added in the publication database, so add it in this database. */

/* New high order key inserted in publishing node */
&Record.CopyFieldsTo(&rSCHOOL);
&rSCHOOL.Insert();
When = "C"
/* School was changed in the publication database, so update it in this database. */

&Record.CopyFieldsTo(&rSCHOOL);
&Update = &rSCHOOL.Update();
/* School does not exist in this database, so add it instead */
If &Update = False Then
&rSCHOOL.Insert();
End-If;


Propiedades de Peoplecode de Suscripción:

Integration Broker (Parte 7) Version Tools hasta 8.46

¿Qué es el Mensaje?

Message Definition
La definición fundamental de la arquitectura Messaging. Almacena la información de cómo el mensaje esta compuesto y esta basado en una estructura similar a un Component (multi-level) o un Record con tablas padre-hijo. Dentro del message esta compuesto por CAMPOS que serán llenados en el momento de la publicación del mensaje o en la recepción del mismo.


Estructura del Mensaje: Cada nodo participante debe contener el mensaje con el mismo nombre y la misma estructura.

Un mensaje debe estar únicamente en un canal.

La columna Alias de la vista de lista permite especificar un valor de etiqueta de campo XML para los mensajes cuyo nombre de campo original es diferente. El sistema de suscripción utilizará este valor en lugar del nombre de campo original del sistema de publicación. Si no especifica ningún valor de alias, el sistema subscriptor utiliza el nombre de campo original.

El campo Alias resulta útil para versiones cruzadas e integración con terceros. La casilla de selección Publish es una función de seguridad que controla si el campo se publica en el mensaje o no.

Active: Determina que el mensaje està habilitado para ser publicado. Si se limpia este check, todas las Transacciones, Relationships asociadas al mensaje, son deshabilitadas, pero si se lo vuelve a chequear, estas no se habilitan automáticamente.

Non-Repudiation — NR: Seleccionado, se envian y reciven mensajes en forma nonrepudiated.

Validate Structure – Validate: Seleccione para indicar que cuando se recibe el mensaje, el tipo de datos de cada campo y la longitud se debe validar contra el formato del campo en la base de datos local. Si un campo falla esta validación, la transacción falla con un error. Si no se tilda el check box, la validación todavía se realiza, pero la transacción no falla. En su lugar, los datos en campos de la definición destino se truncan para caber en la longitud del campo en la definición local.

Message Channel: Se especifica el Message Chanel. Obligatorio.

Default Version: Se especifica la Versión por defecto que será enviada o recibida por PeopleCode.Cada Mensaje tiene una Versión por defecto (Versión n). Cada vez que se crea una nueva versión, esta, recibirá el valor n que le sigue a la ultima versión creada.Se puede tener una cantidad ilimitada de Versiones en el mensaje, pero una será la Versión por Defecto.
Esta Versión por Defecto es utilizada en el caso de que el Mensaje sea Transformado por PeopleCode.
Ya que una definición de Mensaje soporta múltiples Versiones, entonces se puede decir que el Mensaje soporta múltiples estructuras.

Message Viewing/Correction: Es para ver las instancias del Mensaje.

Una vez creado el mensaje, se debe asociar a un canal de Mensaje. ¿PARA QUE ESTA ASOCIACION?: Se asocia por seguridad par poder manejar grupos de mensajes.