Hello Jeroen,

I don't have a whole lot of experience on this topic, but did you happen to look into the Documentation on this topic? This page might help you to check whether the way you call upon the task is correct: https://docs.thinkwisesoftware.com/docs/indicium/api#crud-operations-functions-and-procedures

Also, checking the Indicium log might help to figure out what is going wrong. Did you look into that as well?

Kind regards,

Renée

Hi Renee,

Thanks for the quick response and for the pointer to the docs.

The way I am calling the task seems to be correct, I have tried prepending it with task_ as well as just using the task name, both return a 404. The parameters I have sent in the request body are correct as well.

It seems there is something else going wrong, I will have a look at the logs as you suggested.

Thanks!

Hi @Jeroen de Klerk, is there a specific reason you want to use a task? I am asking this, because calling a task requires resource-staging (Resource Staging | Thinkwise Documentation (thinkwisesoftware.com))

If/when you need this, great, but for API's that need to perform a singular 'thing’ I usually use a subroutine (procedure) instead. This is a lot more straight-forward and you can do this in one go instead of creating a resource and the committing it. 

Hi Robert!

We use a fair few tasks, as our API forms a BFF (backend-for-frontend) for a mobile client using a subset of our Thinkwise apps’s functionalities. This normally works fine when a task is linked to a subject, but we now seem to be running into issues with tasks where this is not the case.

The logs seem to provide no additional information on what’s going wrong, other than “No suitable candidates were found for ‘/<task>’”. This suggests the task I am trying to call does not exist, however I have checked and verified it very much does.

Also, in another topic of mine I asked about this resource staging, and while in some cases it is required, there is also a way to directly call a task in one request. Universal will then run the staging process in the background itself.

Hello @Jeroen de Klerk,

Also, in another topic of mine I asked about this resource staging, and while in some cases it is required, there is also a way to directly call a task in one request. Universal will then run the staging process in the background itself.

This is correct, calling a task directly in a single request should work just fine.

My guess is that the authenticated user doesn't have permissions for the task. Can you double check that the user is part of a user group that is assigned a role that provides access to the task in question? And can you try to clear your cookies to ensure that you are actually signed in as the correct user and not as another user from a lingering authentication cookie?

If you're testing against an SF metasource, another option is that the task is new and Indicium has not reloaded its internal application model. Indicium cannot detect model changes against SF metasources so the only way to force a refresh is to call the /refresh_model endpoint with a POST request or to log out and log back in.

A third option is that you're calling the API on the wrong application (e.g. the wrong branch). If you're using an IAM metasource, please have a look at Applications in IAM and check if the ID/alias of the application that you're using actually refers to the model/branch that contains the task. If you're using an SF metasource, check the same thing at Runtime configurations.

I hope this helps.

Hi Vincent,

Can you double check that the user is part of a user group that is assigned a role that provides access to the task in question? And can you try to clear your cookies to ensure that you are actually signed in as the correct user and not as another user from a lingering authentication cookie?

We verified my user’s rights, the rights of the user groups assigned to me, roles, everything points to me having permissions to call and access this task. I have also refreshed my authentication cookie multiple times, to no avail.

If you're testing against an SF metasource, another option is that the task is new and Indicium has not reloaded its internal application model. Indicium cannot detect model changes against SF metasources so the only way to force a refresh is to call the /refresh_model endpoint with a POST request or to log out and log back in.

This task has existed for several years, so it should have been detected by now I would guess.

A third option is that you're calling the API on the wrong application (e.g. the wrong branch). If you're using an IAM metasource, please have a look at Applications in IAM and check if the ID/alias of the application that you're using actually refers to the model/branch that contains the task. If you're using an SF metasource, check the same thing at Runtime configurations.

The application checks out, however I did realise the task is added to a different menu than the standard one. I however should have access to that menu as well, and I saw no immediate difference in the URLs for Universal, so I am not sure if that would be what is getting in the way.

For now we have decided to attach it to a logical subject, so we have an immediate solution.

However, the docs say this should be possible, so perhaps it is worth investigating why this issue is occuring.

Thanks everyone for the help so far!

Hello @Jeroen de Klerk,

That's strange, can you share URL that you are using to call the task? You can make it relative starting at /iam/appl or /sf/appl if you don't want to leak the domain.

@Jeroen de Klerk Do you have any additional information for Vincent, or have you already managed to fix the issue by now?

Hi @Renée Evertzen and @Vincent Doppenberg,

Sorry for the late reply, work got busy and the issue had indeed already been resolved! It turned out, in doing the same trick over and over again, I assumed all the basics were correct when they, in fact, were not…

I was using the base URL of Indicium Universal (<server>/indicium_universal/) itself, not the application (<server>/indicium_universal/iam/<app_id>).