We’ve developed some resources to help you work effectively from home during COVID-19 Click to learn more

REST FindAgent - Restriction on Udef can cause IIS to go into melt down

Hi,

Recently we came across a strange behaviour when using the FindAppointment provider.

We were calling FindFromRestrictionsColumns using a simple restriction below:

ArchiveRestrictionInfo[] restrictions =
{
   new ArchiveRestrictionInfo()
   {
      Name = "appointmentUdef/SuperOffice:16"
      Operator = "=",
      Values = new [] { "123" },
      IsActive = true
   }
};

This was meant to return all appointments where the UDEF had the value 123.

However, the Udef was setup to have a data width of zero:

When we executed the code, the function eventualy returned a WCF error, with the inner expection detailing a timeout.

Then the IIS worker process (w3wp.exe) took the majority of the CPU and did not release it. It seemed it was in some sort of indefinate loop.

When we changed the UDEF Data width to be somthing other than zero, the code when executed worked as expected.

I believe this may be some sort of bug, and wanted to make you aware of it.

Cheers

Rich

 

 

 

RE: REST FindAgent - Restriction on Udef can cause IIS to go into melt down

Hi,

This sounds really strange. I have a hard time understanding in which way the Data Width actually could be involved in such a API call...

Are you sure it isn't related to something like that the UDEF-field isn't enabled for indexing or something like that?

Have you executed multiple A/B-tests, with width = 0 vs width = >0?

It would be really interesting with some feedback from RnD on this question.

/Marcus

By: Marcus Svenningsson 3 Jun 2020

RE: REST FindAgent - Restriction on Udef can cause IIS to go into melt down

Marcus,

I will happily re-create the issue and post some more details. It is very Odd however, my understanding that making the width of the field=0 does intentionally have an effect of the UDEF within SuperOffice functionality, and wondered if it was related?

Cheers

Rich

 

By: Rich Hacker 3 Jun 2020

RE: REST FindAgent - Restriction on Udef can cause IIS to go into melt down

My understanding of the parameter width is that it should only affect the visibility of the field in the GUI, it shouldn't affect the data layer of the field. One could think of some kind of implicit GUI optimization feature that excludes data with width = 0 as it isn't shown in the GUI anyway. But still, it seems like an unreasonable architecture that this should be able to affect the pure data layer of the field.

The appointment type of the appointment you're looking for could probably affect the behaviour of the call from an analysis perspective. So it could be interesting if you executed the same call for different appointment types, to see if there is any differences.

If you are Onsite, you could always add some logging on Net Server-level as well, to see if you could get some more info.


/Marcus

 

By: Marcus Svenningsson 3 Jun 2020

RE: REST FindAgent - Restriction on Udef can cause IIS to go into melt down

I recall something similar. The width property of the a udef field controls more than only the UI. It also affects archive providers.

By: Matthijs Wagemakers 4 Jun 2020

RE: REST FindAgent - Restriction on Udef can cause IIS to go into melt down

Whether or not this a bug is not for me to say but I can tell you a little bit about what is happening behind the scenes.
A UDef data field whose width = 0 is an old hack for giving you a means of tuning the GUI layout.
You can then use its label as some group header/separator.
These fields are not expected to have any data, so the provider tags these as "not slectable" or "hidden" from the column configuration dialog. These fields are not part of the Available columns. What's more, and this is the bit that causes your issue, these columns have no resrtriction type and canRestrictBy=false.
Consequently, they will be removed from your collection of required restrictions.

What you are left with in the case of the FindAppointment provider is a hidden virtual restrictionn for "visibleInDiary".
Ergo, I suspect you get all appointments that are visible to you. 

/conrad

 

By: Conrad Weyns 4 Jun 2020

RE: REST FindAgent - Restriction on Udef can cause IIS to go into melt down

Hi All,

I have an update on this for you and a link to my Onedrive with a video demoing the behaviour.

It appears as if the UDEF is ignored if the data width of the UDEF is set to Zero. Therefore is the size is set to zero and you use the following:

{
  "providerName": "FindAppointment",
  "desiredColumns": [
    "appointmentId"
  ],
  "restrictions": [
  {
    "name": "appointmentUdef/SuperOffice:16",
    "operator": "Equals",
    "values": [
      "482"
    ],
    "isActive": true,
    "interOperator": "And"
  }
  ],
  "page": 0,
  "pageSize": 100
}

It appears as if it simply tries to return all appointment records (i.e. in this example there is no restriction). This kind of makes sense in terms of the CPU going up and sometimes getting a timeout error.

However the issue, and where I think the problem lies, if that the specified PageSize of 100 is ignored and it returns 1000's of rows instead.

Strangely when testing within my enviroment it returned 462227 rows, but I have 717400 records in the database.

I hope watching the video will clear up any questions you may have: https://puresynergy-my.sharepoint.com/:v:/g/personal/rich_hacker_synergytechnology_co_uk/EerF5T7sdYxKotUEuEhw-Q0B3IW-E7fBzEGSEsPKbz_bVg?e=DfMN0W

Cheers

Rich

 

Edit: Conrad, Thanks for that, this is exactly what I have discovered - still not sure about the PageSize problem though?

 

By: Rich Hacker 4 Jun 2020

RE: REST FindAgent - Restriction on Udef can cause IIS to go into melt down

Thanks for all interesting input in this case! This is implicit behaviour that is quite good to know when working with archives.

/Marcus

By: Marcus Svenningsson 4 Jun 2020

RE: REST FindAgent - Restriction on Udef can cause IIS to go into melt down

Hi Rich,

The hanging/crashing part is obviously a bug, however, the idea that you are placing data in a field that isn't shown is code smell as well.

As Conrad pointed out, the behavior to not return data from fields with a length of 0 is by design. It's a hard way for you to discover this point but let's get back to what you want to do. 

To store hidden data for appointments (or any entity), use the foreign keys - it's what they're there for. 

As Christian recently pointed out, you can access foreign keys via the ExtraFields entity property (appointments, documents, sale, contact, person and project). This makes it easy to attach non-UI/hidden data to entities these days, and would probably be the best way to go for your scenario.

Note, this property is not to be confused with extra fields created in Service. Those fields (and udefs) are accessed on the CustomFields entity property.

How you search for these appointments would need to change, but not by much. 

Hope this helps!

By: Tony Yates 4 Jun 2020

RE: REST FindAgent - Restriction on Udef can cause IIS to go into melt down

Tony,

Yes this is exactly what we are currently using the UDEF for. To record against the entity (in this case Appointment) a value that should be hidden to the user and only get/set via code.

Many thanks for pointing me in the right direction and I will re-code using the correct method, as you have described.

Once again, many thanks to everyone for their input!

Cheers

Rich

 

By: Rich Hacker 4 Jun 2020