Entre bastidores: Cómo genera el sistema un BOD

Estos son los pasos que sigue el sistema para generar un BOD.

1. Esta aplicación utiliza su motor de réplica para generar todos los BOD. Dos procesos separados pueden desencadenar la generación de BOD.
   • Generación de tablas: Se realiza un cambio a una tabla que activa una solicitud UpdateCollection.
   • Generación de función: Un evento de negocio se produce en el sistema que activa una llamada del método remoto.

   Cada uno se considera un Punto de integración de generación BOD. Los eventos de negocio que generan un BOD son enumerados en el formulario Referencias cruzadas de salida de documento réplica.

   Ejemplo 1 - Generación de tablas: Cuando le agrega un nombre de tabla a una categoría de réplica, entonces cualquier cambio realizado al registro en esa tabla activa la generación de un BOD. Si es demasiado general, es decir, que no desea que se genere un BOD cada vez que se toque algo en esa tabla, puede restringir la generación BOD usando el atributo Filtrar para definir un filtro que determine si un cambio en la tabla desencadenará la generación del BOD. Solamente se incluyen registros que coinciden con el filtro. También hay tres casillas de verificación que puede utilizar para restringir la generación de BOD en función del tipo de cambio en la tabla: Omitir insertar, Omitir actualizar y Omitir eliminar. Se realiza todo esto a través del formulario Categorías de réplica.

   Ejemplo 2 - Generación de funciones: Utilice esta técnica cuando un activador basado en actualización de tabla simple es inadecuado. Por ejemplo, supongamos que desea activar un BOD cuando se crea una nueva orden de compra. Debido a que una orden de compra son datos jerárquicos y puede tener cualquier número de líneas y liberaciones, no será posible identificar una sola tabla que pudiera desencadenar la generación de BOD; no hay manera de saber cuándo se insertó la última línea o liberación.

   Como otro ejemplo, si desea desencadenar la generación de BOD cuando se produce otro evento de aplicación sin relación alguna con la actualización de la tabla, puede programar y desencadenar la actualización BOD utilizando un desencadenante "Función". El nombre de "Función" especificado en el formulario Categorías réplica no corresponde necesariamente a un procedimiento almacenado real y posiblemente no lo hará. Es tan solo un parámetro que se pasa a uno de los procedimientos almacenados de réplica que básicamente desencadena la generación de BOD. El procedimiento almacenado se llama RemoteMethodForReplicationTargetSp. También puede llamar a este procedimiento almacenado desde un desencadenante, otro SP o una clase de extensión IDO.

   Para ilustrar el desencadenante de la orden de compra anteriormente comentada: Un usuario ejecuta el Informe de orden de compra para crear una nueva orden de compra. Como parte de la lógica ejecutada, se realiza una llamada de método remoto al procedimiento almacenado TriggerPurchaseOrderSyncSp que desencadena la lógica de réplica de generación BOD.

   Los procedimientos almacenados llamados con una llamada de método remoto no son realmente procedimientos almacenados que existen en la base de datos. La llamada puede o no pasar parámetros. Si la llamada pasa parámetros, los formularios Documento réplica harán referencia a los mismos mediante secuencia; es decir, P1 hace referencia al primer parámetro, P2 al segundo parámetro y así sucesivamente. El siguiente fragmento de código muestra los dos parámetros por los que pasó la llamada de método remoto a TriggerPurchaseOrderSyncSp:

   
    EXEC @Severity  = dbo.RemoteMethodForReplicationTargetsSp                          
      @IdoName        = 'SL.ESBSLPos'
    , @MethodName = 'TriggerPurchaseOrderSyncSp'
    , @Infobar           = @Infobar OUTPUT
    , @Parm1Value   = @PoPoNum
    , @Parm2Value   = @Infobar

2. En el formulario Categorías réplica, cada categoría contiene todas las tablas y funciones necesarias para la réplica de un área en particular del sistema. Una categoría llamada ESB contiene todas las llamadas de método remoto definidas o Nombres de objeto referido por los Documentos réplica, para puntos de integración a otras aplicaciones que requieren XMLs en el formato Infor BOD. Por ejemplo, se muestra TriggerPurchaseOrderSyncSp en la categoría ESB.

   Para documentos XML genéricos (es decir, documentos para aplicaciones que requieren XMLs que no estén en formato Infor BOD), tendrá que crear una categoría réplica separada que contenga las llamadas de método remoto o nombres de objeto apropiados.

3. Si existe una regla de réplica entre el sitio local y un sitio Infor ESB en el que la categoría establecida es ESB, entonces, cuando se da lugar a un evento de negocio o cambio de tabla con un punto de integración en el sitio local, el sistema añade una entrada en las Tablas réplica.

   Para documentos XML genéricos, crearía una regla de réplica entre un sitio local y el sitio definido para la aplicación. Este sitio debe estar configurado en una intranet definida para utilizar con el protocolo de transporte HTTP.

4. El Replicador recoge las filas de las Tablas réplica y las coloca en MSMQ.
5. ReplQListener recoge las filas de MSMQ y determina que estas son filas unidas por otras aplicaciones habilitadas por BOD. Entonces genera un BOD para el evento de negocio o cambio de tabla. Como ya se ha comentado, se pueden transmitir parámetros por el evento.

   En nuestro Ejemplo 2 anterior, un usuario ejecuta el Informe de orden de compra, que llama a TriggerPurchaseOrderSyncSp. Ya que existe una regla para una categoría en la que se define este Sp, el sistema crea un documento réplica. Este encuentra una referencia cruzada de réplica para PurchaseOrder.Sync donde el método Aplicable a es TriggerPurchaseOrderSyncSp, con lo que recupera la plantilla del documento de réplica PurchaseOrder y crea un documento XML de BOD utilizando el sustantivo y el verbo del formulario Referencia cruzada de salida de documento réplica junto con información de elementos y atributos definida en los formularios Documentos de réplica, Elementos de documentos de réplica y Atributos de documentos de réplica.

   En este ejemplo, el número de orden de compra se pasa como primer parámetro (P1). El documento réplica utiliza esta información en un filtro (PoNum=FP(P1)) para que el BOD generado contenga datos solamente de la orden de compra específica.

6. ReplQueueListener sitúa el XML de BOD generado en la Bandeja salida de documento réplica.

   En lugar de ir a la Bandeja de salida, se envían los documentos XML genéricos a la URL de la intranet definida para réplicas no transaccionales.