Consider some field population on a transaction record, sourced from an API or a search from NS. Suppose I put that block of code in before submit and it takes 2 seconds to execute. If I do that in aftersubmit, that will take 2 seconds + ~2-5 seconds to load and save the record. Now let’s suppose there is an integration that pushes 2000 transactions. I am assuming putting logic on aftersubmit will improve the performance of integration. Since whatever is happening on AS is not relevant to integration. 2000*2 = 4000 seconds will be saved for integration. Am I thinking right?

Somebody will correct me if I am wrong but IIRC the integration waits for the AfterSubmit as well so you are just moving the logic, not really saving time. If you can process those records in a batch in a Scheduled Script/Map Reduce then that would improve the performance for sure.

My experience as well☝️

afterSubmit

is synchronous, yes, and integrations will wait for them all to complete. I believe only SuiteCommerce Advanced has the capability of executing async

afterSubmit

Wow, TIL for me. Thank you guys for this one. @borncorp does that mean it runs asynchronously when the context is Map Reduce or Scheduled. I am curious, How can someone verify that, is it in the doc somewhere or just by running/testing it in the code ?

I am pretty sure it runs synchronously for Scheduled and Map/Reduce script too, no real exception, however since you can process several records in parallel, you decrease the total processing time despite that.

@scottvonduhn I think the idea is to let the api create the record without an aftersubmit script that executes and then trigger a map/reduce that does the call to the API and updates whatever needs to updated on the record. So, from the perspective of the integration that creates the records, it runs async.

Yeah, after I wrote that I realized there are many different ways asynchronously could be interpreted, and that also depends upon whether or not multiple scripts are involved, for example the UE with afterSubmit and scheduled or map/reduce script could both be in play. I generally agree with letting integrations or UI actions complete in a reasonable amount of time, and waiting on an external service is too long in many instances. Delaying any updates or sourcing of values to a scheduled process (which is asynchronous from the user or integration events) is a very good idea. The actual API calls running in the map/reduce or scheduled script may still be synchronous, but they are synchronous to a background process, so no one will notice.