Hello René,

This issue is typically caused by redirect rules or URL rewrite rules in IIS. Do you have a reverse proxy in front of Indicium that routes requests to the Indicium web application? Or do you manipulate the URLs in any way by means of rewrite rules before they reach Indicium? If so, could you check if this issue also occurs when you request the following URL directly on that Indicium web application?

/iam/2098/usr(usr_id='user%40company.com')

Hi, 

It has indeed something to do with rewrite rules. A while ago we had some issues when upgrading with a certain version of Indicium, it had something to do with this: 

And I also uncommented this section (which afterwards isn't necessary, but at the time this wasn't known):

 <security>
      <requestFiltering allowDoubleEscaping="true">
        <requestLimits maxQueryString="8192" maxUrl="8192" />
      </requestFiltering>
    </security>

I replaced the web.config file with the one from the zip file and the 404 errors disappear. The 400 errors as described above still exists, also on Azure. Has something to do with this part of the url: &$expand=transl_appl_lang_id($select=appl_lang_id). If I trim it of the url works.

Hello René,

There were indeed two different issues at play here. The first issue was related to the URL rewrites, the second issue should be fixed in version 2021.1.13 of Indicium, which was released in TCP yesterday. Sorry for the inconvenience, please try updating Indicium to see if that fixes your remaining problems.

I hope this helps.

Hi Vincent,

I'm using 2021.1.13 and the second issue still exists. I see multiple similar calls with $expand which succeed with 200, except for the named one.

Br, René

Hello René,

You're right. At first glance, this issue resembled one that was recently fixed in Indicium, but I have managed to reproduce your issue. This looks like an issue in the Universal GUI, I have asked them to look at it.

I notice in an application we're currently developing that the 400 occurs for multiple random calls. When the $expand part is stripped from the url, it returns a valid 200.

What is $expand actually doing, and what / how is it visible in the Universal GUI?

Hello René,

The $expand parameter is part of OData, the protocol that is used between Indicium and its clients to describe queries. The purpose of $expand is to join a record with a record from another table, in order to select corresponding columns from that record as well. The Universal GUI uses $expand to fetch the display value of lookups.

For every lookup that has a display value that differs from its data value, Indicium will create a transl_{lookup_column_id} property which can be expanded. This property, called a navigation property, is a reference between two tables, the table with the lookup column and the table with the lookup display value.

$expand=transl_project_id($select=project_name)

A parameter like the one above means:

Expand the lookup column ‘project_id’ by joining with the table that contains the display value for this lookup and from that table, select that display value (project_name)

There is nothing inherently wrong with this feature, it is very important for lookups to be shown correctly in the GUI and you will find that most requests with $expand work just fine. The problem is that the Universal GUI is a little overeager and also tries to expand lookups that do not have a display value that differs from their data value. Indicium does not create these transl_ navigation properties for these lookups, because they would have no purpose. Universal trying to use these non-existing navigation properties is the cause of the errors you see.

Functionally speaking, these requests that go wrong have no purpose, this is why you don’t actually see anything going wrong in the GUI. The fix for this issue will be to make it so that these requests aren't sent in the first place.

The expand issue has been resolved in release 2021.1.13 of the Universal GUI.