In the case of an error, in moest cases a header is returned called "TSFMessages”.

This is a Base64 encoded string which you can decode to see the real error message. For example with https://www.base64decode.org/

More info can be found here: https://docs.thinkwisesoftware.com/docs/indicium/api#tsfmessages-header.

In this case maybe something went wrong because a column was readonly? 

I see we don’t have a good example for inserting on a detail, maybe that was the case here?
In that case you can do a post request to /iam/<appl>/base_table(PK)/detail_<referenceName>)

For instance:

A post to iam/10/movie(522431)/detail_ref_movie_movie_review, with the following contents:

{
	"review": "My test review"
}

Will automatically fill-in the movie_id for the movie_review table.

Note, you can not set readonly/hidden columns (the model and the layout stored procedure will be checked) and also mandatory columns must be set.

Hello tiago,

You are most likely supplying a hidden or readonly property in your JSON request body. It looks like you are trying to insert a record into a detail subject and you're supplying the key values from the parent subject as well, which are most likely hidden or readonly.

The way to insert a value into a detail subject is like this.

URL:

https://prova.lef.tec.br/indicium/sf/esm/service_task(tenant_id=1, service_id=1106, service_task_id=743)/detail_ref_service_task_service_task_dependency

JSON body:

{
    "previous_service_task_id": 740,
    "connection_type": 0,
    "tsf_user": "PROVA\tiago",
    "transaction_date": "2023-01-19T11:29:27.067Z"
}

Please note that I have made a few assumptions here which might be incorrect:

• The parent subject is service_task
• The primary key of service_task is tenant_id, service_id, service_task_id
• The ID of the detail reference between service_task and service_task_dependency is ref_service_task_service_task_dependency.

If any of these assumptions are incorrect, you will have to change my example accordingly.

The main idea here is that the POST request is executed on the detail reference, which is identified by the prefix detail_ followed by the reference ID in the SF. The key values that belong to the parent subject are supplied from the parent record to the detail record along the reference columns, and should not be supplied in the JSON body.

I hope this helps.

HI @Vincent Doppenberg , 

The tenant_id is a hidden field indeed. 

However if I create the example URL. https://prova.lef.tec.br/indicium/sf/esm/service_task(tenant_id=1, service_id=1106, service_task_id=745)/detail_ref_service_task_service_task_dependency_proper it returns a Invalid OData URL. Whilst the reference does exists. What could cause the error? 

Hello Freddy,

It could be several things, I would start by trying:

GET
https://prova.lef.tec.br/indicium/sf/esm/service_task(tenant_id=1, service_id=1106, service_task_id=745)

If this one does not work, then tenant_id (int), service_id (int) and service_task_id (int) is not the primary key of service task.

GET
https://prova.lef.tec.br/indicium/sf/esm/service_task(tenant_id=1, service_id=1106, service_task_id=745)/detail_ref_service_task_service_task_dependency_proper

If this one does not work, then ref_service_task_service_task_dependency_proper is not a detail reference of the source table service_task.

The reason could also be the permissions of the user making the request, i.e. service_task or the detail reference is unavailable to that user.

I hope this helps.

Hi @Vincent Doppenberg  what is the reason the references only works when it has ‘show detail’  checked?  In this case I don't want to see the detail in the GUI, but would like to add dependencies via an API call..  With the ‘checked’  show detail the API call works.. I however now need to make a special variant to make the API work and not have the depency visible in the GUI. 

Hello Freddy,

This is definitely something to consider. The Universal GUI is of course one of the primary consumers of Indicium's API and it will only need the detail reference if show detail is checked. However I understand your situation as well. I think it could be a nice idea to have separate checkboxes for the UI and API or ignore ‘Show detail’ and ‘Show lookup’ in Indicium and allow the API to be limited through permissions.

Could you create an idea for this?