Generating BODs
These are the steps the system goes through in generating a BOD.
The system uses its replication engine to generate every BOD.
Two types of 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, if you do not want a BOD to be generated every time something touches anything in that table—you can use the Replication Categories form to 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.Example 2 - Function generation
When a simple table-update based trigger is inadequate, you can use a function to generate a trigger. 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, suppose 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. 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: A user runs a Purchase Order Report form 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 by means of a remote method call are not actual stored procedures that exist in the database. The call might or might not pass parameters. If the call does pass parameters, the Replication Document forms refer to these by sequence; that is, P1 refers to the first parameter, P2 to the second parameter, and so on. This 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 = @InfobarThe system retrieves the replication category information required.
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 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.
The system adds appropriate entries to the Replication tables.
If a replication rule exists between a local site and an Infor ESB site where the category is set to , 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.
The Replicator picks up rows from the Replication Tables and places them in MSMQ.
The Replication Queue Listener service processes the data.
The Replication Queue Listener service picks up the data 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 previously, parameters might be passed by the event.
Example 2, continued
Suppose 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 and Replication Document Elements 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.
The Replication Queue Listener service places the generated BOD XML in the Replication Document Outbox.
Generic XML documents, instead of going to the Replication Document Outbox, are sent to the intranet URL that is defined for non-transactional replication.