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.

Integration Broker (Parte 6) Version Tools hasta 8.46

¿Qué es Canal?

Canal de Mensajes: Un Canal, agrupa Mensajes. En cada nodo participante debe tener el mismo nombre de Canal para la comunicación del mensaje que este contiene. El canal es una agrupación lógica de mensajes.

Creación y definición del Canal de Mensaje

Los canales se utilizan para:

• Establecer un procesamiento secuencial.


• Mantener la seguridad en la mensajeria

Message Partitioning: sólo el mensaje con el mismo valor en un campo dividido se procesará secuencialmente. Si el valor es diferente, el mensaje puede ser procesado en paralelo.

Partición de Canal

Los canales de mensajes admiten una funcionalidad de ajuste del rendimiento denominada partición de mensajes. Puede seleccionar uno o varios campos comunes de los registros de nivel 0 de los mensajes de ese canal para realizar particiones. Al seccionar un campo común, en lugar de procesar cada mensaje en su orden de publicación, sólo se procesará secuencialmente los mensajes con el mismo valor en un campo de partición. Si los valores son diferentes, el mensaje puede procesarse en paralelo.

En la ventana Use These Fields to Partition, verá una lista de todos los campos comunes para todos los mensajes asignados a ese canal, además de los cuatro campos siguientes (siempre):

MSGNAME
MSGNAMEDETAIL
PUBLISHER
PUBPROC

Estos cuatro campos se han añadido en la versión 8.4 para permitir particiones de los mensajes sin campos comunes.

Envio de mensajes sin Partición

Todos los mensajes posteriores para todos los empleados mantienen el estado NEW hasta que se corrija el error

En este ejemplo podemos ver el paso de un nodo a otro de una serie de mensajes relacionados con empleados, con un error en el mensaje inicial para el ID de empleado 8101. El campo común de todos los mensajes es EMPLID, pero la utilidad de partición está desactivada.

Sin particiones, los demás campos EMPLID (por ejemplo, el 8508) no se procesarán hasta que se corrija el error. Esto se debe a que, sin particiones, no podemos saber dónde termina el mensaje de un empleado y empieza el del siguiente.

Envio de mensajes con Partición

El campo EMPLID se utiliza para realizar particiones de los mensajes del canal. Por tanto, los procesos de suscripción de los mensajes del canal se llevarán a cabo secuencialmente respecto al campo EMPLID.

Aquí podemos ver que se ha producido el mismo error para el EMPLID 8101 que en el ejemplo anterior. Puesto que la utilidad de partición se encuentra activada, los mensajes correspondientes al EMPLID 8508 se procesarán en orden, sin obstáculos, y los mensajes con errores esperarán en la cola (con el estado Error) hasta haber sido corregidos y reenviados.

Propiedades del Canal

Para acceder al cuadro de diálogo Message Channel Properties, utilice el icono de propiedades de la barra de herramientas o seleccione File, Definition Properties.

Message Channel Status:

• Run : los mensajes asignados al canal son recibidos y procesados normalmente.


• Pause: Los mensajes son recibidos pero no son precesados hasta que se encuentra en Run.

Archive Messages? : Para que se puedan guardar o eliminar los mensajes.

Unordered?: Se selecciona para que los mensajes dentro del canal, puedan correr en forma paralela.

Los mensajes de los contrario en el canal correran en forma secuencial.

Quality of Service:

Best Effort: hasta 8.44 no esta implementado.
Guaranteed: Si el IB falla al enviar un mensaje, se reenvia hasta que termina el tiempo (TimeOut). Se marca el mensaje como TimeOut.

Seguridad para los Canales

Para poder consultar el canal de mensajes en el monitor de Integración con Mensajería, el usuario debe disponer de permisos de seguridad para el mismo. La seguridad se establece en la lista de permisos.

El permiso puede ser completo (Full) o de sólo lectura (Read Only).

Integration Broker (Parte 5) Version Tools hasta 8.46

¿Qué son Transacciones?

Son configuraciones que deben existir en la Base Local y Remota para la interacción de las mismas por medio de mensajes. Se asocian a NODOS

Se accede a traves de PeopleTools - Integration Broker - Integration Setup - Node Definitions - y en la solapa de Transactions

Se agrega una transaccion haciendo Click en el boton de Add Transaction.

1. Se define el Nodo, la fecha efectiva y el tipo de Transacción que puede ser:

• Asincrónica Entrante
  
• Sincrónica Entrante
  
• Asincrónica Saliente
  
• Sincrónica Saliente

2. Se selecciona el mensaje y la versión y se hace click en Add.

Transacción Entrante Asincrónica

1. Solapa de Detalle de la transacción.
   
2. Status: Determina si la transacción esta activa o inactiva
   
3. Override Connector (Sola para mensajes Salientes se explica en mensajes Salientes)
   
   


4. Messages (Se define para los mensajes Sincrónicos)

Transacción Entrante Sincrónica

1. Solapa de Detalle de la transacción. (idem transaccion Entrante Asincrónica
   
   


2. Messages (Definición del mensaje)


3. Synchronous Logging : Esta opción le permite definir el nivel de la información de registro (Log) para los mensajes síncronos. Los valores válidos son:
   Header Only.:
   Header and Detail
   No Logging (Default).


4. Response Message: Se define el mensaje de respuesta con su versión.

Transacción Saliente Asincrónica

1. Solapa de Detalle de la transacción.
2. Override Connector: Configuración de Conectores y Gateway
   
   


3. Messages: (Definición del mensaje)
   
   
   
4. Conectores: Se definen los conectores para la transacción. Esta pagina solamente aparecerá cuando esta seleccionada la opcion Override Connector de la solapa Transactions y se haya guardado (salvado) la transacción.
   
   
   

Transacción Saliente Sincrónica

1. Solapa de Detalle de la transacción. (Idem Transacciones Salientes Asincrónicas)
   
   



2. Messages: (Definición del mensaje, Idem mensajes Entrantes Sincrónicas)
   
   


3. Conectores: Se definen los conectores para la transacción. Esta pagina solamente aparecerá cuando esta seleccionada la opcion Override Connector de la solapa Transactions y se haya guardado (salvado) la transacción. (Idem Transacciones Salientes Asincrónicas)
   

Los conectores se configuran únicamente en las transacciones salientes ya que Peoplesoft en las transacciones sincrónicas entrantes devuelve su mensaje de donde fue llamado (la configuración de conectores se hace en el otro nodo de donde provino el mensaje)

Integration Broker (Parte 4) Version Tools hasta 8.46

¿Qué es Gateway?

Gateway o Pasarela de Integración es una plataforma que gestiona la recepción y el envío de los mensajes que se intercambian los sistemas a través de Integración con Mensajería. Admite los protocolos TCP/IP y proporciona interfaces ampliables para el desarrollo de nuevos conectores para la comunicación con sistemas antiguos, sistemas de Planificación de Recursos de Empresa (ERP) o basados en internet.

¿Qué son los Nodos?

Existen varios tipos de nodos definidos en la base de datos de PeopleSoft

Nodo de base de datos

Cada base de datos de PeopleSoft tiene un nodo local por defecto. Éste es el nodo autentificado. El nombre del nodo debe ser exclusivo para la identificación de la base de datos. Los clientes cambiarán el nombre del nodo. Si tiene varias instancias de la base de datos, por ejemplo de desarrollo, de control de calidad y de producción, cada una de ellas debe tener un nombre de nodo de base de datos exclusivo.

Nodo proveedor de contenido

Las bases de datos de aplicaciones PeopleSoft que incluyen el contenido de transacción se denominan “proveedoras de contenido”.

Nodo de registro

Es un nodo local del Portal de Empresa que actúa como sistema principal

Integration Broker (Parte 3) Version Tools hasta 8.46

¿Qué es Application Messaging?

Es la forma de interacción entre sistemas mediante Mensajes.Permite a las aplicaciones interactuar con los web services en respuesta a requerimientos PS o terceros

¿En que casos se utiliza Application Messaging internamente en Peoplesoft?

• Duplicación de tablas de definición: Existen varias tablas de definición en las aplicaciones de PeopleSoft (por ejemplo, Departamento, Cuenta, Proveedor y Cliente). Mensajería se utiliza para reproducir los contenidos de estas tablas entre los sistemas PeopleSoft y los sistemas de otros proveedores.
  
• Notificaciones de envío anticipado: Desde el inventario se envía a un cliente una notificación de envío anticipado relativa a un pedido introducido en Ventas mediante una transacción de Intercambio Electrónico de Datos (EDI) de salida a través de Mensajería.
  
• Datos de contacto/cliente/dirección. Se utilizan en Gestión de Relaciones con el Cliente (CRM) para sincronizar los clientes y los contactos con HRMS y FDM, así como para sincronizar productos e ítems con FDM.
  
• Integración de gestión de almacenes. PeopleSoft está integrado con destacadas soluciones de gestión de almacenes. Mensajería comparte datos entre PeopleSoft Almacenes y estos sistemas para transacciones como liberación de pedidos, inventario físico, ajuste de inventario, transferencias de inventario y balance de inventario.
  
• Datos Personales. PeopleSoft HRMS se ocupa del mantenimiento de la información sobre los empleados que necesitan muchos sistemas de otros proveedores. Mensajería sincroniza estos datos con los sistemas de otros proveedores
  
• Mensajería entre versiones.

Conceptos Generales

Definicion de Mensajeria

Es una arquitectura de interfaz basada en mensajes que facilita la interacción entre sistemas y procesos mediante el uso de servicios web

Tipos de mensaje (sincrónicos y asincrónicos)

• Los mensajes sincrónicos se usan para obtener una respuesta de otro sistema en tiempo real, o para devolver un valor a otro sistema y seguir con el proceso.
  
• Los mensajes asincrónicos pueden usarse para despachar datos desde PS, sin la necesidad de tener una respuesta inmediata de retorno o sino para provocar una acción fuera de PS.

XML (eXtensible Markup Language) el XM L sirve para describir información y el HTML sirve para darle formato y presentarla a través de un navegador.Xml estructurado.

Se crea una orden de venta y se necesita saber si tenemos la cantidad suficiente a mano para satisfacer dicha orden.

1. Luego de ingresar QTY e ITEM, un proceso sincrónico de app.messaging es iniciado con el objetivo de verificar si en el sistema externo de inventario existe la cantidad necesaria.
   
2. El XML es enviado por el IB y retorno al instante un XML hacia el IB permitiéndole saber al usuario si la orden puede ser completada.
   
3. El resultado de este proceso es mostrado en la pagina Order, mediante un WinMesagge.
   
4. La orden es completada y grabada. En este instante se genera otro mensaje XML y es enviado asincrónicamente a 2 sistemas A y B subscriptos.
   
5. El IB garantiza el despacho de los datos de la orden a estos 2 sistemas.

Elementos de la Integración

Elementos Administrativos (Tecnológicos)

Elementos administrativos: definiciones PIA que describen el entorno de mensajería, incluidas las aplicaciones participantes, sus pasarelas locales, los tipos de transmisión y las instrucciones de envío.

• Definición de pasarela (Gateway)
  
• Definición de nodo (Node)
  
• Transacción (Transaction)

Elementos de Desarrollo (Técnicos)

Elementos de desarrollo: Las definiciones de Application Designer y su PeopleCode asociado. Puede desarrollar estos elementos independientemente del entorno de mensajería en el que se vayan a utilizar.

Message Channel Definition
Agrupación lógica de mensajes. Se debe llamar de igual forma tanto en el Nodo local como en el Remoto.

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.

Sending PeopleCode
Evento que se ejecuta y es peoplecode usado como Trigger para que el mensaje sea creado y disparado hacia la publicación o nodo subscriptores.

Subscription PeopleCode
Evento diseñado para recibir mensajes desde otros nodos, en forma asincrónica. Se coloca dentro del la definición del mensaje.

OnRequest PeopleCode – Solo para Mensajes Sincrónicos
Ídem al anterior pero este evento se ejecuta para mensajes recibidos en forma sincrónica.