Solved

Indicium post on mandatory / readonly field?

  • 14 October 2020
  • 3 replies
  • 89 views

Userlevel 5
Badge +15

I'm trying to add data to IAM 2020.2 via an external program*. I try to do this via Indicium. What I can do with the Windows / Web GUI, I can't do with Indicium. I've managed to find out that the following error happens:

dbug: Indicium.Controllers.TableController[0]      Cannot commit the resource for entity 'gui_appl'. The layout procedure has made the property 'mobile_proxy_address' mandatory, but no value was supplied.

This happens when I do a post call (with PostMan i.e.) to https://localhost:5001/iam/iam/gui_appl

with the following content:

{    "project_id": "my_project",    "project_vrs_id": "1.00",    "active": "true",    "db_name": "my_database",    "order_no": 10,    "server_id": 2,    "max_concurrent_sessions_per_account": 1,    "claim_timeout": 1,    "gui_appl_alias": "my_database"}

It only happens when the application platform "Mobile" is enabled. According to the log message the field mobile_proxy_address is missing. So I've tried to add it, with "", null and '127.0.0.1' as value to the json post data, but then it returns:

dbug: Indicium.Controllers.TableController[0]      Cannot change the value of the property 'mobile_proxy_address' of 'gui_appl'.The application model prohibits editing this property.

Then I remembered something about resource staging (https://community.thinkwisesoftware.com/blogs-21/resource-staging-1070). I've applied this method and then it works as expected. But it needs for each individual property a http call. That is a bit overwhelming I guess, so I want to reduce it to a single POST call.

The post about also says something about a single request:

Simplifying the APIs

In version 2020.1.1 of Indicium we have re-enabled the single request APIs and built their implementations on top of resource staging. Clients can send all column/parameter values in a single request and Indicium will go through the process of resource staging and stage the values in the order that they’re supplied in. This does mean that the client should only include the values that are entered by the user and that the order of the properties in the request body is important.

I've tried to emulate the sequence as I would enter the gui_appl in the web or windows gui, but that didn't help. Any clues about how to add this record, with this invisible thus mandatory field without having to do it the n-patch-requests resource staging way?

 

 (*If you're interested why we're accessing IAM on this way: As ISV we try to simplify our 'new customer' process: Creating an Azure database, GUI Application, add a user, send some mails, add an internal administration record within 1 application / click. This all works, until we've recently enabled the 'mobile' platform flag.)

icon

Best answer by Vincent Doppenberg 15 October 2020, 12:12

View original

This topic has been closed for comments

3 replies

Userlevel 6
Badge +4

Hello René,

You've mentioned that you can get it to work with resource staging, i.e. with a stage_add request, several PATCH requests and then a commit request. Are you certain that, when you try to do it in a single request, you include the columns for which you made PATCH requests in your POST body and that you've ordered them in the same way as the PATCH requests? 

The two methods below should be equivalent

POST
/iam/myAppl/myTable/stage_add

PATCH
/iam/myAppl/staged_myTable(...)

{
"col_1": "abc"
}

PATCH
/iam/myAppl/staged_myTable(...)

{
"col_2": 123
}

PATCH
/iam/myAppl/staged_myTable(...)

{
"col_3": "def"
}

POST
/iam/myAppl/staged_myTable(...)/commit

 

POST
/iam/myAppl/myTable

{
"col_1": "abc",
"col_2": 123,
"col_3": "def"
}

However it is important to only specify the columns that a user would enter and not those that are determined through a default value, a default procedure or expression query, for instance.

Since you are trying to insert a record into the gui_appl table of IAM, I can test it out myself as well. I'll give it a shot and I'll return to this topic with my findings.

Userlevel 6
Badge +4

Hello René,

As you say, it is not possible to insert a record in the gui_appl table through Indicium because of the inconsistent application logic on the table. The column “mobile_proxy_address” is both readonly and mandatory, but is never given a value by means of a default value in the model or the default procedure. Because of this, it is not possible for a user to satisfy the constraints for an insert.

I was unable to replicate what you described. In my case neither with a single request nor through resource staging was it possible to insert a record, which is the behavior I had expected as well.

You're right that it is possible with the Windows GUI, because the Windows GUI doesn't actually check the mandatory state of hidden columns. This is a known difference that we have discussed before internally and we have agreed that Indicium is handling this situation correctly.

First and foremost, this is an issue in the application logic of the gui_appl table in IAM. Secondly, it is an issue in the Windows GUI that makes the assumption that hidden columns that are made mandatory by the layout procedure should not be considered mandatory. Indicium does not make this assumption because it is unclear whether it is the mandatory state that is wrong or the lack of a value. Only someone with domain knowledge can make that decision and should fix the application logic to make it consistent. I will report this issue with the IAM team. As a workaround, you can alter the lay_gui_appl procedure to set @mobile_proxy_address_mand to 0.

I hope this explains why this is happening and helps you work around it.

Userlevel 5
Badge +15

Hello René,

As you say, it is not possible to insert a record in the gui_appl table through Indicium because of the inconsistent application logic on the table. The column “mobile_proxy_address” is both readonly and mandatory, but is never given a value by means of a default value in the model or the default procedure. Because of this, it is not possible for a user to satisfy the constraints for an insert.

I was unable to replicate what you described. In my case neither with a single request nor through resource staging was it possible to insert a record, which is the behavior I had expected as well.

You're right that it is possible with the Windows GUI, because the Windows GUI doesn't actually check the mandatory state of hidden columns. This is a known difference that we have discussed before internally and we have agreed that Indicium is handling this situation correctly.

First and foremost, this is an issue in the application logic of the gui_appl table in IAM. Secondly, it is an issue in the Windows GUI that makes the assumption that hidden columns that are made mandatory by the layout procedure should not be considered mandatory. Indicium does not make this assumption because it is unclear whether it is the mandatory state that is wrong or the lack of a value. Only someone with domain knowledge can make that decision and should fix the application logic to make it consistent. I will report this issue with the IAM team. As a workaround, you can alter the lay_gui_appl procedure to set @mobile_proxy_address_mand to 0.

I hope this explains why this is happening and helps you work around it.

Hi Vincent, Thanks for the answer and workaround, we'll keep an eye on it :-).