Solved

Indicium 403 error - How to debug

  • 19 December 2022
  • 5 replies
  • 106 views
Blommetje
Userlevel 5
Badge +12

Hi, 

I’m running into some things with Indicium I don’t understand. 


We have some dev environments - all copies from each other and we want to use an API for a patch-request. 

We have an All Rights users. Every environment has its own Indicium. In 1 everything works fine, in 1 some columns in Table Item give a 401 or 403, but table Activity works fine. But then in number 3 Activity throws a 403 but Item is fine. 

So, it feels a bit random. All have the same version, upgraded to last versions of Indicium. 

A GET works fine, a Patch is denied.  

I have no errors in the Indicium log. 

How can I debug this? And, what can cause this? Any guidance would be appreciated. 

Thanks, 


Alexander

icon

Best answer by Dick van den Brink 19 December 2022, 09:17

View original
This topic has been closed for comments

5 replies

E
Rank
Userlevel 6
Badge +16

Some things to check: Do you use the all rights user to call the API? I assume you call the API using postman/insomnia did you try clearing the cookies? Did you check the IAM effective user rights on all the environments for the tables/columns that give an error. 

Blommetje
Userlevel 5
Badge +12

Yes, same user with all rights. Cookies cleared/not set. 

I think I have one table figured out. Due to imperial/metric settings in the user profile the metric fields are read-only. After changing this, the patch req. worked. I assume the other table might have something similar. However, I don’t develop the external app so not sure what is called / can’t verify lay_proc. 

Can this perhaps be debugged in a different way? Or can we ignore procs if calling the api? Sometimes a field cannot be modified in the GUI, but has to be modified in the Android app.


 

D
Rank
Userlevel 4
Badge +2

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

 

Blommetje
Userlevel 5
Badge +12

Yes, found it. 

Also the encoded string helps a lot. It was indeed a layout proc and somewhere a hidden field which was also mand. Therefore patching wasn’t possible. 

 

But the reason we run into this, we have an Android app, and at a certain moment the whole thing is moved from (web) gui to the Android app. Things must be scanned, photographed and measured and such. There we lock the gui (read only or set it to not-editable). 
BUT this also locks things for the app… 

What would be the best way to get around this. 
Practically we would like that Indicium only looks at the data model and ignores the procs. 

Any thoughts/advice on this? 

Alexander 

D
Rank
Userlevel 4
Badge +2

Indicium calls the layout/default logic automatically, that is the same as the Windows GUI (or Web GUI) would do. This is to make sure the data is valid and business rules are applied. Also the Universal (because it calls the Indicium API) requires this procedures to be called (if enabled in the model).

If you want to create custom API's, tailored to a specific need, I think it might be best to look  at https://docs.thinkwisesoftware.com/docs/sf/subroutines#subroutine-as-api.
 

Terms & ConditionsCookie settings