A Python service submits a Dataverse custom API as a background operation and receives a 202 Accepted response. The service must later learn when the operation has finished and whether it succeeded, without keeping the original connection open. Which approach meets this requirement?
Select an answer to reveal the explanation.
Short Explanation
A 202 is a claim ticket, not the result, so you need a way to check back. You can poll the status monitor URL or the backgroundoperation row, or hand Dataverse a callback URL to ping you. The trap is hunting for the old System Job record, which isn't where background operations report.
Full Explanation
When Dataverse accepts a background operation, it returns two handles: the Location header, which is a status monitor resource outside the Web API data path, and the background operation ID, which identifies a row in the backgroundoperation table. The client can poll the status monitor with GET to receive state, status, error details, and, after success, the output parameters. It can poll the backgroundoperation row and read the state and status columns plus outputparameters, errorcode, and errormessage. Alternatively it can include a callback URL so Dataverse posts a completion notice, after which the receiver reads the result from the status monitor; an asynchronous step on the OnBackgroundOperationComplete message is another notification route. The asyncoperation table tracks system jobs such as asynchronous plug-in steps and workflows; it is not the record that represents a background operation. HTTP responses are not updated after they are sent; the 202 is final and carries handles, not results. The plug-in trace log is a diagnostic aid that may be disabled and is not a supported channel for returning output parameters. Exam caveat: avoid aggressive polling; Microsoft advises an interval of a minute or more. Operational check: read the backgroundoperation row and confirm its status reason moves from In Progress to Succeeded or Failed.