The Salesforce Bulk API allows batches of data to be submitted to Salesforce for processing asynchronously to the running of the ss_Loader stored procedure (i.e. once the data payload is delivered you do not need to concern yourself with the immediate stored procedure process completing. There are pros and cons to this api, vs the standard web services SOAP api (which runs synchronously to your ss_Loader stored procedure).

The main advantage of the Bulk API is for handling large volumes of data that you’d prefer to pass up to Salesforce and leave for Salesforce to process. The main disadvantage is that the overhead associated with checking the load is not as seamless as the SOAP or REST API (i.e. the operations Insert, Update, Delete, Undelete, Upsert which have been considered thus far are all via the SOAP or REST API). The following sections are going to consider the same operations.

Version 1 of the Bulk API is the original version and still fully supported by Salesforce. The main different to the later Version 2 is that whilst a specified batchsize as such is not supported in v1, SQL Sales can control the size of each submitted batch (as V1 allows this specification), thereby in effect allowing a batchsize to be defined. Version 1 also allows a concurrency mode to be specified (i.e. either Serial or Parallel). Some use cases of submitting data against objects that have a lot of associated code, may encounter a higher chance of failure (Salesforce apex code, triggers, workflows, governor limits etc, nothing to do with SQL Sales), for such objects it can be safer to submit serially rather than in parallel, but each use case needs to be judged on its own merits. Version 1 is also more predictable in terms of how batches are created, which allows (for Inserts) SQL Sales to tie a response batch of new Ids back to the submitted data (in a similar way to the SOAP API Insert operation), provided the “WAIT” switch is employed.

Version 2 is more “automatic” in the sense you cannot specific how to define the contents of a given batch (Salesforce will decide if this will be spit across multiple batches or contained within one batch), as such batchsize is not supported with the Bulk API Version 2. Similarly, concurrency mode (Serial/Parallel) is not controllable as Salesforce again defines how a given batch or set of batches will be processed. Finally, Version 2 has no set way of predicting how a batch of responses will be returned vs how they were submitted, hence Bulk API Inserts cannot be tied back to the submitted data payload, even with the WAIT switch. This will therefore have to be done by the User, keying the payload by for example an embedded key field that is part of the given target Salesforce object field definition. For example if you have a field “CustomId__c” on the given object and you pass in an appropriate custom Id as part of your BulkAPIv2Insert, when replicating the data back (via ss_Replica or ss_Delta) you can analyse how your Bulk API V2 has behaved.

These key differences will be reflected in the subtle switch differences in the following Version 1 vs Version 2 documented operations.