Skip to main content
Solved

Windows GUI - indicium task staging resource start_commit end_commit

Ricky
Superhero
Forum|alt.badge.img+8

Hi,

Coming from Indicium Basic, we currently are working on letting our postman test and performance scripts and runs work like the windows gui version that is compatible with the indicium that is also used by the Universal GUI.

We got a large part of executing transactions working, but we encounter some issues with tasks.

We are trying to make a task work. The Windows GUI debugger seems to lack information about how it executes a task. According to the responses from indicium when doing a POST request that does a END_COMMIT, it replies that there should be something with a START_COMMIT. The debugger shows nothing of its kind, only the END_COMMIT. Now using fiddler, we could scrape out that (one?) missing request (START_COMMIT) and put it in the postman run. It seems that for some reason every request sends back a 200 status, but the task has not done its job. (Does the GET signal_r request have any influence on the whole transaction/conversation?) Also the documentation on resource staging shows nothing on this start_commit and so on...

We are missing something, but we can’t seem to figure out what…

Is there any other documentation found how this works with tasks?

rgds Ricky

Best answer by Vincent Doppenberg

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.

View original
Did this topic help you find an answer to your question?

3 replies

V
Moderator
Forum|alt.badge.img+4

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.

Ricky
1 person likes this
  • Ricky
    Ricky
Ricky
Superhero
Forum|alt.badge.img+8
  • RickySuperhero
  • Author
  • Superhero
  • 95 replies
  • April 7, 2025

​@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...

V
Moderator
Forum|alt.badge.img+4

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.

Ricky
1 person likes this
  • Ricky
    Ricky

Reply


Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings