WebSphere Message Broker, Versión 8.0.0.5 Sistemas operativos: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte la información sobre la última versión del producto en IBM Integration Bus, Versión 9.0

Caso de ejemplo 1: proceso de business partner y de relaciones en un solo flujo

Debe establecer la propiedad Modalidad de transacción de forma adecuada en un nodo SAPRequest cuando esté procesando un flujo de mensajes simple.

Este caso de ejemplo es uno de los dos ejemplos que ilustran los conceptos que se describen en Confirmaciones de transacción BAPI de SAP; consulte también Caso de ejemplo 2: proceso de creación de pedidos y aplicación de consultas con dos flujos.

En este caso de ejemplo, se utiliza un flujo de mensajes para crear un business partner y una relación nueva con el partner ya existente utilizando dos llamadas BAPI:
BAPI_BUPA_CREATE_FROM_DATA
BAPI_BUPR_RELATIONSHIP_CREATE
El flujo de mensajes consta de dos nodos SAPRequest con la propiedad Modalidad de transacción establecida en en ambos nodos para que permita la confirmación o retrotracción en el caso de que hubiera excepciones. Cuando la propiedad Modalidad de transacción se ha establecido en , la confirmación final del flujo de mensajes se realiza al final del flujo cuando el adaptador solicita a SAP que confirme el pedido.
Diagrama que muestra cómo interactúan los nodos SAPRequest en un flujo de mensajes con el servidor SAP. El diagrama se describe en los pasos siguientes.
  1. Una aplicación desencadena el flujo transaccional que crea el business partner.
  2. El nodo SAPRequest envía una creación BUPA y devuelve el número de business partner. La confirmación se produce cuando el flujo de mensajes se completa porque el nodo participa en una transacción de nivel de flujo de mensajes.
  3. El segundo nodo SAPRequest intenta crear una relación entre un business partner y el nuevo business partner; sin embargo, SAP todavía no ha confirmado la creación del business partner nuevo en la base de datos.

    Si se utiliza el mismo adaptador para ambas BAPI, el adaptador garantiza una conexión simple a SAP porque ambos nodos tienen que participar en la misma unidad de trabajo lógica. La conexión simple significa que la creación BUPA está visible en la llamada de actualización de relaciones (3 en el diagrama), aún cuando la transaccionalidad del flujo no haya iniciado todavía la confirmación.

    Si la propiedad Modalidad de transacción se hubiera establecido en en la llamada de creación BUPA, pero en No en la llamada de relaciones de creación, el adaptador tendría que utilizar dos conexiones distintas a SAP; es decir, las propiedades transaccionales de las conexiones serían distintas. Por lo tanto, la llamada de relaciones de creación fallaría porque el business partner nuevo no estaría visible hasta que no haya finalizado el flujo de mensajes y la confirmación transaccional.

  4. El nodo MQOutput coloca un mensaje MQ en la cola de salida pendiente de la confirmación transaccional.
  5. El flujo de mensajes finaliza y el intermediario empieza a confirmar todos los recursos implicados en ese flujo, incluido SAP (5 en el diagrama). Las aplicaciones se confirman en SAP.

En este escenario se ilustra la posibilidad del intermediario de utilizar su control transaccional de flujos de mensajes para proporcionar la información necesaria e los nodos SAPRequest para que lleven a cabo los procesos relacionados, aún cuando el sistema externo SAP esté confirmando el trabajo de modo asíncrono.

Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Comentarios

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última actualización:
        
        Última actualización: 2015-02-28 16:58:55


Tema de conceptoTema de concepto | Versión 8.0.0.5 | ac66400_