Behind the scenes: How the system generates a BOD
These are the steps the system goes through in generating a BOD.
- 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
- The Replicator picks up rows from the Replication Tables and places them in MSMQ.
- 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 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.
- 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.