Behind the Scenes: How the System Generates a BOD

These are the steps the system goes through in generating a BOD.

1. This application uses its replication engine to generate every BOD. Two separate processes can trigger BOD generation:
   • Table generation: A change is made to a table that triggers an UpdateCollection request.
   • Function generation: A business event occurs in the system that triggers a remote method call.

   Each of these is considered a BOD generation integration point. The business events that generate a BOD are listed in the Replication Document Outbound Cross References form.

   Example 1 - Table Generation: When you add a table name to a replication category, then any change made to a record in that table triggers a BOD generation. If that is too general - that is, you do not want a BOD to be generated every time something touches anything in that table - you can restrict BOD generation by using the Filter attribute to define a filter that determines if a change to the table will trigger BOD generation. Only records that match the filter are included. There are also three check boxes that you can use to restrict BOD generation based on the type of change to the table: Skip Insert, Skip Update and Skip Delete. All of this is done through the Replication Categories form.

   Example 2 - Function Generation: Use this technique when a simple table-update based trigger is inadequate. For example, suppose you want to trigger a BOD when a new purchase order is created. Since a purchase order is hierarchical data and can have any number of lines and releases, it is not possible to identify a single table that triggers the BOD generation - there is no way to know when the last line or release has been inserted.

   As another example, if you want to trigger BOD generation when some application event occurs that is completely unrelated to a table update, you can programmatically trigger the BOD update using a "Function" trigger. The "Function" name specified in the Replication Categories form does not necessarily correspond to an actual stored procedure, and likely it will not. It is really just a parameter that is passed into one of the replication stored procedures that ultimately triggers the BOD generation. The stored procedure is named RemoteMethodForReplicationTargetSp. You could also call this stored procedure from a trigger, another SP, or an IDO extension class.

   To illustrate the purchase order trigger mentioned above: A user runs the Purchase Order Report to create a new purchase order. As a part of the logic executed, a remote method call is made to the stored procedure TriggerPurchaseOrderSyncSp, which triggers BOD generation replication logic.

   Stored procedures called via a remote method call are not actual stored procedures that exist in the database. The call may or may not pass parameters. If the call does pass parameters, the Replication Document forms will refer to these by sequence; that is, P1 refers to the first parameter, P2 to the second parameter, and so on. The following code snippet shows the two parameters passed by a remote method call to TriggerPurchaseOrderSyncSp:

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

2. In the Replication Categories form, each category contains all of the tables and functions required for replication of a particular area of the system. A category called ESB contains all the defined remote method calls, or Object Names referred to by Replication Documents, for integration points to other applications that require XMLs in the Infor BOD format. For example, TriggerPurchaseOrderSyncSp is listed in the ESB category.

   For generic XML documents (that is, documents intended for applications requiring XMLs not in the Infor BOD format), you would need to create a separate replication category that contains the appropriate remote method calls or object names.

3. If a replication rule exists between a local site and an Infor ESB site where the category is set to ESB, then whenever a business event or table change with an integration point occurs at the local site, the system adds an entry in the Replication tables.

   For generic XML documents, you would create a replication rule between a local site and the site defined for the application. That site must be set up on an intranet that is defined to use HTTP transport protocol.

4. The Replicator picks up rows from the Replication Tables and places them in MSMQ.
5. ReplQListener picks up the rows from MSMQ and determines that these are rows bound for other BOD-enabled applications. It then generates a BOD for the business event or table change. As mentioned above, parameters may be passed by the event.

   In our Example 2 above, a user runs the Purchase Order Report, which calls TriggerPurchaseOrderSyncSp. Since a rule exists for a category where this Sp is defined, the system builds a replication document. It finds a replication cross reference for PurchaseOrder.Sync where the Applies To method is TriggerPurchaseOrderSyncSp, so it retrieves the PurchaseOrder replication document template and builds the BOD XML document, using the noun and verb from theReplication Document Outbound Cross References form, plus element and attribute information defined in the Replication Documents, Replication Document Elements, and Replication Document Attributes forms.

   Also in this example, the purchase order number is passed as the first parameter (P1). The replication document uses this information in a filter (PoNum=FP(P1)) so that the generated BOD contains data for only the specified purchase order.

6. ReplQueueListener places the generated BOD XML in the Replication Document Outbox.

   Generic XML documents, instead of going to the Outbox, are sent to the intranet URL that is defined for non-transactional replication.