Generating BODs

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   = @Infobar

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.