Hello Harm,

There is not a lot of information to work with here, so it's difficult to say anything definitive. But the 404 responses could definitely be explained by the proxy. It is very possible that these requests aren't even reaching Indicium and that it is the proxy server that is returning the 404 responses. You can check if the response headers contain Server-Timing, which is a good indicator that the request reached Indicium.

You could also check if /iam/iam and/or /iam/sf are accessible to those users which are getting 404 responses. If those URLs do work, then at least Indicium can be reached for sure and the problem is specific to the application or process flow. Since you are testing against the SF, it's possible that the runtime configuration was deactivated or the user was unlinked from the runtime configuration. Or perhaps the ID of the runtime configuration changed if you're not using an alias. In general it's a much better idea to do tests like these against IAM instead of the SF.

When the issue starts, you can run the following SQL script on the SF database to determine if the requested application and the requested process flow are available to the user. Be sure to use the values from the actual requests that are failing, rather than values you know to be correct.

-- Enter the username that is used for the authentication of the failing request
declare @username varchar(200) = ?;

-- If your URL looks like /sf/123 then set @gui_appl_id to 123 and @gui_appl_alias to NULL
-- If your URL looks like /sf/appl then set @gui_appl_alias to 'appl' and @gui_appl_id to NULL
declare @gui_appl_id int = ?
declare @gui_appl_alias varchar(50) = ?;

-- This should give a result, if it does not then the requested runtime configuration 
-- does not exist or the user is not linked to it.
exec i_api_get_role_set @username, @gui_appl_id, @gui_appl_alias

-- Fill out these values based on the response of the stored procedure above
declare @gui_appl_id2 int = ?;
declare @role_set_id int = ?;

-- This should give a result, if not then the process flow does not exist in the model linked to this runtime configuration
select *
from i_api_process_flow
where gui_appl_id = @gui_appl_id2
and role_set_id = @role_set_id
and process_flow_id = ? -- The ID of the process flow in question here

I hope this helps.

Hi Vincent,

I have done the first check, but without success…

../sf/api

.. iam/iam

…/iam/sf

Any more ideas?

Hello Harm,

Is the RDBMS user of that public user also set to public? This field is the actual link between the authenticated user on the request and the user record in the SF.

Vincent,

Hero!

It seems like that this was the problem. The field RDBMS user was indeed empty (NULL).

But what I not understand, is how it is possible that it has worked, before this was set.

I cannot remember that I have ever set this value for other users. Is that because IAM authentication is applied for this user?

Could you imagine a scenario where the RDBMS username differs from the username?

Br,

Harm

@Vincent Doppenberg,

Just to avoid this problem in the future...

Should the field RDBMS not be mandatory and/or always be equal to the User Name?