ss_ReplicaBAll allows you to run ss_ReplicaB in bulk across multiple Salesforce objects.
It follows the same inclusion/exclusion model as ss_ReplicaAll, but each object is replicated using ss_ReplicaB and Salesforce Bulk API 2.0.
The optional @BAPIMethod parameter allows the same Bulk API execution methods used by ss_ReplicaB to be applied across all objects in scope.
Simple Example
exec ss_ReplicaBAll 'DEMO'By default, ss_ReplicaBAll uses the WAIT execution method for each object.
This means each object is submitted, waited for, retrieved and completed before the next object is processed.
With @ObjectNameFrom
exec ss_ReplicaBAll 'DEMO', 'Opportunity'This will commence the bulk ss_ReplicaB replication from the Object immediately following Opportunity, which could be OpportunityCompetitor if there is no other custom or standard object with a name closer to Opportunity when sorting alphabetically.
This is useful if a prior run of ss_ReplicaBAll has failed or been stopped and you wish to recommence from the point of failure.
Parameters
| Parameter | Purpose |
|---|---|
| @Env | SQL Sales Environment Name |
| @ObjectNameFrom | Commences the bulk ss_ReplicaB replication from the Object immediately following the one passed in. This is useful if a prior ss_ReplicaBAll run has failed or been stopped and you wish to recommence from that point. |
| @BAPIMethod | Optional Bulk API execution method applied to each object. Supported methods are WAIT, WAIT(n), BACK and CHECK(n). Default is WAIT. |
Bulk API Execution Methods
ss_ReplicaBAll passes the selected Bulk API execution method through to each individual ss_ReplicaB call.
| Method | Purpose |
|---|---|
| WAIT | Processes each object sequentially. SQL-Sales waits for the current Bulk API Query job to complete before moving to the next object. |
| WAIT(n) | Sequential resilient wait mode. The JobId for each object is recorded immediately and SQL-Sales checks the job every n seconds until complete before moving to the next object. Valid values are 1–3600 seconds. |
| BACK | Submits Bulk API Query jobs for all objects in scope without waiting for each job to complete. |
| CHECK(n) | Checks previously submitted outstanding Bulk API Query jobs and waits n minutes between checks until each completes. Valid values are 1–59 minutes. |
GET is intentionally not supported at the ss_ReplicaBAll level. GET is a one-shot check and is more appropriate when working with an individual object through ss_ReplicaB.
WAIT
WAIT is the default method.
exec ss_ReplicaBAll 'DEMO',
@BAPIMethod = 'WAIT'Each object is fully processed before SQL-Sales proceeds to the next object.
This is the simplest execution model and is equivalent to running each required ss_ReplicaB individually using the default WAIT method.
WAIT(n)
WAIT(n) provides the resilient synchronous execution model across all objects.
For example:
exec ss_ReplicaBAll 'DEMO',
@BAPIMethod = 'WAIT(10)'For each object, SQL-Sales submits the Bulk API Query job, records the JobId immediately and checks the job until Salesforce reports that it is complete.
The value of n is the number of seconds between subsequent checks and can be between 1 and 3600.
Once the current object has completed, ss_ReplicaBAll proceeds to the next object.
For example, to check each running job every five minutes:
exec ss_ReplicaBAll 'DEMO',
@BAPIMethod = 'WAIT(300)'BACK
BACK is particularly useful when you want to submit Bulk API Query jobs for multiple objects without waiting for each one to complete before the next is submitted.
exec ss_ReplicaBAll 'DEMO',
@BAPIMethod = 'BACK'SQL-Sales iterates through the objects in scope and submits a Bulk API Query job for each object.
The corresponding JobIds are recorded in ss_BulkAPILog.
Because each submission returns without waiting for Salesforce processing to complete, multiple Bulk API jobs can be outstanding at the same time.
A common pattern is therefore:
exec ss_ReplicaBAll 'DEMO',
@BAPIMethod = 'BACK'followed later by:
exec ss_ReplicaBAll 'DEMO',
@BAPIMethod = 'CHECK(5)'CHECK(n)
CHECK(n) is the companion method to a prior BACK execution.
For example:
exec ss_ReplicaBAll 'DEMO',
@BAPIMethod = 'CHECK(5)'For each object in scope, SQL-Sales identifies the applicable outstanding Bulk API Query job.
If the job is not yet complete, SQL-Sales waits the specified number of minutes and checks again.
Once the job completes, the results are retrieved and the replication is completed before SQL-Sales moves to the next object.
The value of n can be between 1 and 59 minutes.
Although a prior BACK may have submitted multiple jobs to Salesforce, CHECK(n) processes the outstanding jobs serially as ss_ReplicaBAll iterates through the objects.
Recommended detached pattern
For large-scale replication across many Salesforce objects, the following pattern allows the Salesforce Bulk API jobs to be submitted first and processed afterward.
First submit the jobs:
exec ss_ReplicaBAll 'DEMO',
@BAPIMethod = 'BACK'Then, either immediately or later, process the outstanding jobs:
exec ss_ReplicaBAll 'DEMO',
@BAPIMethod = 'CHECK(5)'This allows Salesforce to begin processing multiple submitted jobs without requiring each object to complete before the next job is created.
ss_BulkAPILog
ss_ReplicaBAll uses the same ss_BulkAPILog lifecycle as individual ss_ReplicaB operations.
Each submitted Bulk API Query job is recorded against the relevant Salesforce Object and target SQL table.
This allows a later CHECK(n) execution to identify the correct outstanding job for each object.
For normal operation there is no need to manually supply Bulk API JobIds when using ss_ReplicaBAll.
ss_ObjectInclusion inclusion table
| Field | Purpose |
|---|---|
| ObjectName | Defines Objects you wish to include in each ss_ReplicaBAll run. Only Objects contained in this table will be considered in scope. Accompanying table ss_ObjectExclusion is additionally referenced, therefore Objects contained there will be ignored. |
The inclusion model is the same as conventional ss_ReplicaAll.
This is generally the most appropriate approach where only a defined set of Salesforce objects needs to be maintained in the SQL replication database.
ss_ObjectExclusion exclusion table
| Field | Purpose |
|---|---|
| ObjectName | Add Objects to this table to have them excluded from each ss_ReplicaBAll run. On deployment, ss_EnableDatabase populates a number of known problem Objects together with their Salesforce API response details for reference. |
| ErrorMsg | Salesforce API Response Error Msg |
| ErrorCode | Salesforce API Response Error code |
It is a matter of choice whether you define an inclusion set using ss_ObjectInclusion or instead exclude unwanted objects through ss_ObjectExclusion.
Generally, where only a relatively small number of Salesforce objects are required, ss_ObjectInclusion is the simpler and more controlled approach.
Where you instead wish to replicate most or all available Salesforce objects, maintaining exclusions in ss_ObjectExclusion may be more appropriate.
Choosing an execution method
For a straightforward sequential run:
exec ss_ReplicaBAll 'DEMO'For resilient sequential execution:
exec ss_ReplicaBAll 'DEMO',
@BAPIMethod = 'WAIT(10)'For large-scale detached execution:
exec ss_ReplicaBAll 'DEMO',
@BAPIMethod = 'BACK'followed later by:
exec ss_ReplicaBAll 'DEMO',
@BAPIMethod = 'CHECK(5)'For most smaller or routine runs, WAIT or WAIT(n) will be the simplest approach. For larger full-Org style replication, BACK followed by CHECK(n) allows the Salesforce job-processing phase to be detached from the original submission process.
