Truly very informative session. We have implemented similar pattern of dynamically bulkifying the transacations using sobject-work-queue framework with below design goals 1) Error notification (Email / Case / Slack) 2) Error retry 3) Contrlling the executon by prioritizing the transactions 4) Process the transactions in serial to avoid row lock issues 5) Defined custom threshold limits to safely halt the processing and resume in the next job 6) Skip execution of classes to process them later. Ex if the external system is down stop making API calls and resume processing after the external system is up and running. The above framework has successfully addressed multiple point of failures in our Salesforce CPQ implementation for Auto Renewals and on top of that, we built an Inbound Integration framework where the external systems will send the data in JSON up to 3 levels of object hierarchy, which then processed by the sobject-work-queue framework based on configurations mapped.
This is a good Integration pattern. I believe this is not a new concept. This is already happening in the Middleware layer. Mule can be configured to perform this 'Dynamic Bulkifications" .
Salesforce already has the number of API calls you can make into the org as 1 Lakh !! Wouldn't we reach this first?, if yes then any better work around
Truly very informative session. We have implemented similar pattern of dynamically bulkifying the transacations using sobject-work-queue framework with below design goals
1) Error notification (Email / Case / Slack)
2) Error retry
3) Contrlling the executon by prioritizing the transactions
4) Process the transactions in serial to avoid row lock issues
5) Defined custom threshold limits to safely halt the processing and resume in the next job
6) Skip execution of classes to process them later. Ex if the external system is down stop making API calls and resume processing after the external system is up and running.
The above framework has successfully addressed multiple point of failures in our Salesforce CPQ implementation for Auto Renewals and on top of that, we built an Inbound Integration framework where the external systems will send the data in JSON up to 3 levels of object hierarchy, which then processed by the sobject-work-queue framework based on configurations mapped.
23:45 "Process Builder is evil" - love the brutal honesty, Dan!😃
"Process Builder is evil." It hurts. Process builder was my first crush
Sorry about that
to think I knew exactly what the solution is as soon as you mentioned asynch apex, I must be getting sharper!
This is a good Integration pattern. I believe this is not a new concept. This is already happening in the Middleware layer. Mule can be configured to perform this 'Dynamic Bulkifications" .
Great Session. 👍 I will cover this in my videos too
Please do!
Salesforce already has the number of API calls you can make into the org as 1 Lakh !! Wouldn't we reach this first?, if yes then any better work around