While our video dude is stuffing himself with turkey (who’d want to listen even to Morgan Freeman with a mouthful of dry meat?), I’d take this Friday to clarify few things about asking CRM server to do few things at once. There are two ways to do it.

ExecuteMultiple

ExecuteMultipleRequest has been around for quite some time (since 2011, in fact) and it’s been designed to improve performance of bulk operations. It improves the performance by removing the need to “chat” with the server – just package all requests that need to be processed, send single request over to the server and optionally get a bunch of responses back. Requests in the batch are independent of each other though you do have ability to stop the batch if something goes wrong (this is not a transaction, whatever happened prior to the error, will stay in the database). Repeat after me:

ExecuteMultiple is not a transaction

One interesting discovery I came across recently is that using ExecuteMultiple in plugins can be detrimental to the performance. Makes sense when you think about it – you’re already on the server, network latency is absent, conversation overhead is negligible and time is wasted on bundling/unbundling the requests.

If you’re doing what ExecuteMultiple is designed to assist with, bulk data load, and you’re also using multithreading to squeeze the last bit of performance, then you probably have seen the “server is too busy” error. As one of the “insiders” (or British scientist, make your pick) explained it to me:

The server too busy error with executemultiple usually means that they are issuing too many calls concurrently. Online instances are limited to 2 calls concurrently (although you may get more in some cases depending on how your calls are load balanced).

The batch size is not directly related to this, but smaller batches may be finishing faster and hence reducing that actual number of calls concurrently operating on the server.

If you’re planning to use ExecuteMultiple, do some reading (unless you are a cat on your 9th life, of course).

ExecuteTransaction

ExecuteTransactionRequest, introduced in CRM 2015 Update1, does wrap multiple requests as a single transaction. Note that if you are thinking of improving your application by bundling creation of a contact and 72 related tasks, the capability to perform transactional creation of related records has existed since 2011 days, and I would still recommend that over ExecuteTransaction.

Some good articles about ExecuteTransaction has existed for over half a year; and it’s very encouraging to see them coming from the vendors (meaning that their software just got better). There are some good takeaways, essential ones being throttling limit still applies and there could be a performance penalty due to a locking nature of the transactions.

Plugins

There seems to be some confusion how these messages behave inside the plugins. Anything executed at pre-validation step (i.e. outside of the database transaction) will behave as described above. At all other stages, according to the authority, things are wrapped inside the plugin transaction and

If a plug-in executes within a database transaction, the plug-in executes ExecuteMultipleRequest, and a transaction rollback is initiated, the rollback includes any data changes resulting from requests executed by ExecuteMultipleRequest

But the point is moot, however, because ExecuteTransaction is, uhm, transactional by default and using ExecuteMultiple inside the plugin does not do you any good, anyway.