2

I am currently using Bulk API 2.0 to insert, update and delete data in Salesforce.

What I am confused about is uploading more than 1 batch of CSV records to a job before it is closed?

I create a Bulk API 2 job, I can then upload to that job once, but I cannot upload a second batch of data to the same job id. The examples do not show a second batch of data being uploaded to the same job id but the REST API suggests it can be done by :

  1. having a URL that ends with the word batches and not batch singular i.e. services/data/v44.0/jobs/ingest/jobid/batches
  2. having a separate PATCH (for URL services/data/v44.0/jobs/ingest/jobid) method to mark the job as complete. If you weren't expecting more batches of CSV data to be uploaded why not mark the job as complete automatically and dispense with this API call.

Is it possible to upload multiple batches to the same Job ID?

3
  • Are you doing a PUT request to /services/data/vXX.X/jobs/ingest/JOB ID/batches/ ? Documentation implies that it exists. Jun 14, 2019 at 15:12
  • This example I am linking here shows Java code that adds multiple batches to a job. developer.salesforce.com/page/… Jun 14, 2019 at 15:15
  • @SebastianKessel - yes that's right. I'm doing a PUT for the first upload of data but a second PUT for the next batch fails - implying that Bulk API 2.0 only supports a single batch of data. I think the page you have posted is for Bulk API 1.0, in which you were allowed to upload multiple batches of data and take advantage of parallelism. Bulk API 2.0 appears to be different in this regard Jun 17, 2019 at 8:45

1 Answer 1

2

I saw a Bulk API 2.0 presentation at TrailheaDX where this came up... I think it's a no, Bulk 2.0 is designed to ingest one data file and then start processing. Recall though that the limits on Bulk 2.0 are by volume of records not number of batches.

If you weren't expecting more batches of CSV data to be uploaded why not mark the job as complete automatically and dispense with this API call.

One possible reason is, networks can be unreliable. A disruption in the transfer could create a state where, for example, the client believes the transfer was incomplete because it didn't receive an acknowledgement packet, but in fact the server did receive the file. If it got marked as complete automatically, it would start processing even though the client thought it had failed.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .