SwiftlySalesforce
SwiftlySalesforce copied to clipboard
mike4aday
better support within Swiftly Salesforce for multi-record inserts
@perbrondum can you provide more details? Are you looking for 'direct' support of the composite API insert capability? https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_sobjects_collections_create.htm
Looking for a way to do bulk inserts of records of same type. Hoping for a way that allows the bulk inserts to count as 1 as opposed to n as we keep getting ‘cut off’ by the activity limits while transferring configuration data from client to SFDC.
We’ll pass an array of inserts and get an array of Id’s back. I’ll assume that all inserts either fail or succeed.
Thanks,
Per
On Jan 22, 2019, at 3:02 PM, Michael Epstein [email protected] wrote:
@perbrondum can you provide more details? Are you looking for 'direct' support of the composite API insert capability? https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_sobjects_collections_create.htm
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@perbrondum the new-ish Composite API does just that - inserts up to 200 records, and has an "all or nothing" option. I can add a method to Swiftly Salesforce that uses the Composite API, but AFAIK it does "cost" 1 API call per object inserted. That is, even though it's a single HTTP request, if the request to the Composite API post insert method contains 'n' sub request records, then your API allotment is reduced by 'n.'
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_sobjects_collections_create.htm
Thanks for looking into this. Having the 'all or nothing' option would be great as we could not have to code for dangling commits (if we get cut off). So event if we don't reduce the cost, it's still worth it.
Thanks,
Per Jakobsen
Regular mail : [email protected] Secure Mail: [email protected]
On Thu, Jan 24, 2019 at 8:47 AM Michael Epstein [email protected] wrote:
@perbrondum https://github.com/perbrondum the new-ish Composite API does just that - inserts up to 200 records, and has an "all or nothing" option. I can add a method to Swiftly Salesforce that uses the Composite API, but AFAIK it does "cost" 1 API call per object inserted. That is, even though it's a single HTTP request, if the request to the Composite API post insert method contains 'n' sub request records, then your API allotment is reduced by 'n.'
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_sobjects_collections_create.htm
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mike4aday/SwiftlySalesforce/issues/102#issuecomment-457268855, or mute the thread https://github.com/notifications/unsubscribe-auth/AA4tYmhQkCuSc6sYqD0nV-Hp_8lSEHcqks5vGeOegaJpZM4aJ3wV .
I'm confused by the definition of 'cost' of the API calls. From your recent reply to the thread on 'group by example' it was clear that 'select count' cost 1 API, whereas 'select count, group by n' costs n API calls. So the reasonable person would argue that the cost of passing an Array of inserts once and getting 1 response back should only incur 1 API call (ie. 1 network roundtrip).
Alternatively, if we end up creating a JSON file with all the records and wrote an APEX script on the server to perform the inserts, would it still count as n API calls?
Thanks again for all the good work you're doing here,
Per Jakobsen
Regular mail : [email protected] Secure Mail: [email protected]
On Fri, Jan 25, 2019 at 8:24 AM Michael Epstein [email protected] wrote:
@perbrondum https://github.com/perbrondum will do! Thanks
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mike4aday/SwiftlySalesforce/issues/102#issuecomment-457629417, or mute the thread https://github.com/notifications/unsubscribe-auth/AA4tYjOOydSxN7r04yaKYY3lPBAW_lxoks5vGy_IgaJpZM4aJ3wV .
Hi @perbrondum - which recent reply are you referring to? Can you link to it? From your description, both queries, with and without the "group by" clause, would cost 1 API call.
The cost of an API call refers to the allocations detailed here. Each call to the standard REST API reduces the available API count by 1.
The newer composite API essentially allows you to make a single HTTP request and pass a list of up to 200 records that will be inserted, updated, etc. Salesforce will take care of iterating through the list, but still "charges" 1 API call per record in that list. You get improved performance, however, because your mobile client doesn't have to open an HTTP connection for each record.
As you noted, you could create your open Apex method, expose it as a REST endpoint, and call it with Swiftly Salesforce's apex method. Even if that Apex method operates on 'n' records, you're still only charged 1 API call.
BUT whenever possible you should favor the out-of-box Salesforce REST API endpoints over custom Apex REST endpoints. Salesforce takes care of optimizing and testing the out-of-box endpoints. Your Apex methods, however, are subject to all the platform governor limits, e.g. heap size limit, number of query results, query time, etc. You have to implement your own result set pagination, and test for unexpectedly high data volumes, etc.
Below is the link you referred us to in a thread re: example of group by queries. See the details re: group by. https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_SOQL_agg_fns.htm “For COUNT() or COUNT(fieldname)queries, limits are counted as one query row, unless the query contains a GROUP BY clause, in which case one query row per grouping is consumed”
Per
On Jan 28, 2019, at 5:19 PM, Michael Epstein [email protected] wrote:
Hi @perbrondum - which recent reply are you referring to? Can you link to it? From your description, both queries, with and without the "group by" clause, would cost 1 API call.
The cost of an API call refers to the allocations detailed here. Each call to the standard REST API reduces the available API count by 1.
The newer composite API essentially allows you to make a single HTTP request and pass a list of up to 200 records that will be inserted, updated, etc. Salesforce will take care of iterating through the list, but still "charges" 1 API call per record in that list. You get improved performance, however, because your mobile client doesn't have to open an HTTP connection for each record.
As you noted, you could create your open Apex method, expose it as a REST endpoint, and call it with Swiftly Salesforce's apex method. Even if that Apex method operates on 'n' records, you're still only charged 1 API call.
BUT whenever possible you should favor the out-of-box Salesforce REST API endpoints over custom Apex REST endpoints. Salesforce takes care of optimizing and testing the out-of-box endpoints. Your Apex methods, however, are subject to all the platform governor limits, e.g. heap size limit, number of query results, query time, etc. You have to implement your own result set pagination, and test for unexpectedly high data volumes, etc.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
@pbrondum that refers to a different limit: the total number of query rows. The API limit, however, refers to the number of calls into the Salesforce platform from an external client. An external client running a query via the REST API would be subject to both limits - on the number of API calls within a rolling 24 hour period, and the total number of query rows.
I think I over complicated this request by driving the conversation into API cost. The real issue for us is that we need to generate X tasks instantaneously (or as fast as possible) so that a subsequent query either returns 0 or X records. Having an update(object: , [SalesforceRecord]) that would return after creating X records would do just that. I can image other scenarios where this could come in handy.