Hello ​@Ricky,

The start_commit and end_commit endpoints are meant for asynchronous processing of tasks, meaning that the requests can return their response before the task is actually done. The start_commit request will return a 202 Accepted status code that indicates that the task has been started in the background. The end_commit requests can be polled and will return a 202 Accepted status code if the task is still running in the background or a 204 No Content or 200 OK result if the task has finished. Whether or not you are listening on the signalr connection for progress is not relevant to the execution of the task.

You wrote "every request sends back a 200 status”, but since start_commit can't return 200, I'm assuming that you meant a 200-range status, i.e. a success status. If so, the simplest explanation for getting a success status but the task seemingly not having done its job is that it simply wasn't finished yet. If you think that the task did finish, then it would be interesting to have a look at the database event log to find the execution of the stored procedure.

Everything I wrote above assumes that you want to do the exact same thing as the Windows GUI and therefore stick to start_commit and end_commit. But it is also possible to simply do a single commit request which would make things easier. The behavior would be largely identical, except that this commit request is a blocking request and if the task takes very long, you could run into a timeout.

I hope this helps, please let me know if you have additional questions.

​@Vincent Doppenberg, I stand corrected, indeed the start_commit gives me a 202. And your assumption is right, we do want to do the exact same thing as the Windows GUI. I happened to get a working set of requests on the same task, but with more simple set of business logic that is executed (apparently), so we are now looking at the business logic where the one that does not work may give us a hunch on what we’ve missed(because the end_commit gave back a 200 - it should be finished right?). So far I do was delighted to see (in another task) that missed mandatory fields/parameters are handled with the start_commit. 

What took me a while and I still have a hard time understanding (the logic on why) is this for example: I want to deactivate a a subject(in this case the subject is a relation) row. I start the task and it shows me a popup, it has a mandatory field called activation_reason_id. To apply this to the staging resource, I do not PATCH it(which I expected), I have to POST it, and not with an expected POST+payload, but the payload is in the URL - this baffles me somehow.

/iam/197/staged_deactivate_relation({{stage_token}})/list_activation_reason_id(system_company_id=6,activation_reason_id=68)/choose?include_layout=true&include_resource=true

^^ to patch the stage resources with a reason_id=68

I also do still miss some documentation on this...

Hello ​@Ricky,

The POST request with this in the URL  /list_activation_reason_id(system_company_id=6,activation_reason_id=68)/choose is used by the GUI to indicate that a certain lookup record is to be chosen for a certain lookup column or parameter. The reason that this request differs from a regular PATCH request is that the GUI might lack the permissions to the corresponding data column in the lookup table. In fact, the GUI doesn't even know what the reference columns are to begin with.

The API call here is very analogous to the user action, which is opening the lookup dialog, picking a record and clicking ‘Select’. The list_activation_reason_id is an OData navigation property (a foreign key, basically) that refers to the lookup table. Between the parentheses, a reference is made to a specific record in the lookup table by means of the primary key. The choose action is simply an indication that the specified record should be applied to the staged resource.

Note that it is also possible to do a PATCH call to enter a value for activation_reason_id, if you already know which value (i.e. data value) you want to enter. So lookups can be entered in the same way as regular columns and parameters, but also have an additional API that is used by GUIs which lack the knowledge and perhaps permissions to be able to know which data value should be entered.

The documentation on this front is indeed incomplete. I will make sure to give this the attention it deserves.

As an aside, using /commit instead of /start_commit and /end_commit may help you troubleshoot the problem that you have. After solving it you can swich back to /start_commit and /end_commit. The TSFMessages response header in particular may help you pinpoint the cause.

I hope this helps.