A Python service uses the Dataverse Web API to create an order header, create three order lines that reference it, and update the customer's last order date. If any of the five operations fails, none of the changes may persist. How should the developer send the requests?
Select an answer to reveal the explanation.
Short Explanation
A change set is the all-or-nothing envelope inside a $batch. Put all five of your operations in one envelope and they commit or roll back together. Split them into separate envelopes, or leave them loose, and each one stands on its own.
Full Explanation
The Dataverse Web API supports OData $batch requests, which group multiple operations into a single HTTP request. Within a batch, operations placed in a change set are processed as an atomic unit: if any operation in the change set fails, all operations in that change set are rolled back. Placing the order header, the three lines and the customer update in one change set therefore satisfies the all-or-nothing requirement, and Content-ID references let the lines refer to the header created earlier in the same change set. Putting each operation in its own change set makes each one atomic only with itself, so a failure in one line would leave the header and other changes committed. Operations outside any change set in a batch are executed independently, and a failure does not roll back the others. Sending five parallel requests provides no transaction at all, and MSCRM.SuppressDuplicateDetection controls duplicate detection rules, not atomicity. Exam caveat: change sets can contain only write operations such as POST, PATCH, PUT and DELETE; GET requests must sit outside change sets. The SDK for .NET equivalent of an atomic change set is ExecuteTransactionRequest. Operational check: force the third order line to fail validation, send the batch, and confirm that neither the header nor any line exists and the customer's date is unchanged.