Skip to main content

In Indicium Universal, executing seems to contain 2 steps;

A staging step, in which a task's default and layout procedures are called, and the context of the parent subject is checked to see whether the user is authorized to execute the task.
The URL for this task looks as such:

http://<server>/indicium/(iam|sf)/<app_alias>/subject(id=1,idtwo=2,idthree=3)/task_execute_task/stage

The response of this request contains a Location header, in which a URL to the staged task is supplied with a GUID.

Step 2, which is the actual execution of the task, is much simpler; we simply make a POST request to http:///indicium/(iam/sf)//staged_execute_task()/commit, which will execute the task on the resource specified when staging the task (subject with id 1, idtwo 2 and idthree 3) and returns a response.

 

We implemented this in our external API based on what happens in the Universal GUI, where we had previously implemented Indicium Basic. However, we noticed a pretty severe downgrade in performance when using Universal as explained above. We ran a simple performance comparison test between Universal and Legacy, in which we repeatedly executed the same two tasks for 10 minutes each.

Below are the results of these tests;

Request times performance test Indicium Universal versus Basic.

Please note when reading:

  • In the Universal results, the execution of both steps is counted as one request, as in Legacy task execution simply requires a single POST call be made to the task itself.
  • In Basic, we did not include calls to defaults and layouts or contexts.

 

As can be seen in the results, Indicium Basic executed just over twice as many requests as Universal over the same timespan, with an average response time roughly a third of Universal's average response time. Of course, we are talking microseconds and to the human eye it will be barely noticeable, however in technical terms this is quite significant.

This difference in performance can, in part, be explained by the simple fact Indicium Universal does much more background work than Indicium Basic. That background work is, apart from soon to be discontinued support for Indicium Basic, our main reason for this switch. However, this performance downgrade is quite severe, moreso than we feel it should be.

 

As said above, we implemented these steps based on how the Universal GUI handles task execution. When executing a task in the Universal GUI whilst having an open network inspector, these same requests can be seen in the inspector, and so we implemented this method as such.

However, we are now wondering whether there is, or whether there should be, a more efficient way of executing these tasks. One that does the same as these 2 steps we have now implemented, but in a single request for example. Having to incur and wait for 2 separate HTTP requests to finish only adds to the “expected” performance cost in Universal due to all the background jobs.

 

Should you have any questions, do please ask in a comment!

Thank you in advance!

Have you tried executing the task without staging so you won't have the separate requests which will cause a lot of overhead?

In that case you can do a post request to the endpoint with a request body for the fields you want to fill in.

In the above example it will be:

http://<server>/indicium/(iam|sf)/<app_alias>/subject(id=1,idtwo=2,idthree=3)/task_execute_task


See the documentation https://docs.thinkwisesoftware.com/docs/indicium/api (Executing a task on a record) for an example.

Hello Jeroen,

Indicium Universal also offers an API to execute tasks in a single request (and the same goes for inserts, updates, etc.).

When executing the task without any context (i.e. not in the context of a selected record), the API is simply this:

POST
/my_task_id

{
   "my_task_parmtr_1": 123,
   "my_task_parmtr_2": "abc",
}

When executing the task in the context of a selected record, the API is this:

POST
/my_table(my_pk_col_1=123, my_pk_col_2='abc')/task_my_task_id

{
   "my_task_parmtr_1": 123,
   "my_task_parmtr_2": "abc",
}

Please note the task_ prefix before the task_id in this example.

These APIs are documented here. And I have written a blog post on this specific topic here. Please note the Simplifying the APIs paragraph.

For these APIs it is important to realize that you should only supply the task parameters that the user would enter in the request body. Tasks parameters that receive their value through the table-task link, default values of the task parmtr, default procedure or expression queries should all be omitted from the request body. Indicium will take care of entering these values for you and these parameters are often hidden or readonly and Indicium will not allow them to be entered in the request body.

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

Hello Jeroen,

Indicium Universal also offers an API to execute tasks in a single request (and the same goes for inserts, updates, etc.).

When executing the task without any context (i.e. not in the context of a selected record), the API is simply this:

POST
/my_task_id

{
   "my_task_parmtr_1": 123,
   "my_task_parmtr_2": "abc",
}

When executing the task in the context of a selected record, the API is this:

POST
/my_table(my_pk_col_1=123, my_pk_col_2='abc')/task_my_task_id

{
   "my_task_parmtr_1": 123,
   "my_task_parmtr_2": "abc",
}

Please note the task_ prefix before the task_id in this example.

These APIs are documented here. And I have written a blog post on this specific topic here. Please note the Simplifying the APIs paragraph.

For these APIs it is important to realize that you should only supply the task parameters that the user would enter in the request body. Tasks parameters that receive their value through the table-task link, default values of the task parmtr, default procedure or expression queries should all be omitted from the request body. Indicium will take care of entering these values for you and these parameters are often hidden or readonly and Indicium will not allow them to be entered in the request body.

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

Hello Vincent,

 

Thank you for the quick reply!

I am trying this method, but it throws a 415 Unsupported Media Type without a request body.

The task parameters are defined as such;

(
   @id                smallint,
   @idtwo             smallint,
   @idhtree           smallint,
   @user_id           varchar(45),
   @start_date_time   date_time
)

id, idtwo and idthree are the combined PK of the subject, which are supplied in the URL as this task must be executed in the context of a subject.The URL therefore looks as such:
POST /subject(id=1,idtwo=3,idthree=36)/task_execute_task

The parameters user_id and start_date_time are auto-filled in the default procedure belonging to the task. According to your blog post I should be able to POST this task without a request body, or an empty one at least. When I POST to the task with either a request body containing the to-be-filled parameters or an empty body, the request appears to at least come through.

Should I be able to POST to this task without a request body, if it is entirely auto-filled? Or does the implied parameter list require a request body, regardless of where the actual values come from?

 

Thanks again!

Hello Jeroen,

You should always supply a Content-Type header with the value application/json and provide an empty JSON object {} in the request body if you have no parameters to supply.

I hope this helps.

Terms & ConditionsCookie settings