Entity changes from contact to person by selecting an extra field

PARTNER Erik Westra

Hello,

 

I am making the following request:

https://sod2.superoffice.com/Cust34362/api/v1/Contact?$select=contactId%2Ccode%2Cname%2CcontactAssociate%2FpersonId%2Ccategory%2Cbusiness%2Corgnr%2Cnumber&$top=5&$skip=0

This results in a list of entities with EntityName set to `contact`.

If I add the field `phone/formattedNumber`, this changes to 'person':

https://sod2.superoffice.com/Cust34362/api/v1/Contact?$select=contactId%2Ccode%2Cname%2CcontactAssociate%2FpersonId%2Ccategory%2Cbusiness%2Cphone%2FformattedNumber%2Corgnr%2Cnumber&$top=5&$skip=0

On top of that, the amount of entities returned changes.

What is happening here?

 

Erik

 

STAFF /no/My-Page/4973/

RE: Entity changes from contact to person by selecting an extra field

Because the contact archive tries to handle contacts + persons, and phone/formattedNumber looks a person phone numbers. This joins in the person table, and would be why you get different rows (you can now get the same contact multiple times).

 

Try using contactPhone/formattedNumber to get contact phonenumbers

 

We need a pure contact archive provider here obviously.

Av: Christian Mogensen 10. jun 2020
PARTNER /no/My-Page/13945/

RE: Entity changes from contact to person by selecting an extra field

That would explain part of it. Maybe a good idea to update the documentation to reflect this.

https://community.superoffice.com/documentation/sdk/SO.NetServer.Web.Services/html/Reference-ArchiveProviders-FindContactArchiveProvider.htm

It lists only `contacts` under `Supported Entities`

 

It would however not explain me getting less enitities. I can image there being less rows if an inner join is used in the background.

And the EnitityName switching from 'contact' to 'person' while the columns remain the same is a bit strange as well. Does this have any significance?

Is there any way to figure out which fields trigger a join operation?

Av: Erik Westra 10. jun 2020
PARTNER /no/My-Page/13945/

RE: Entity changes from contact to person by selecting an extra field

Hmm, I noticed something strange.

When I add `email/emailAddress` to the fields, the field displayed on the Company (Contact) is shown, but an inner join with person is done. All Company records without an 'Our contact' are not returned.

Is this a bug or am I missing something?

Av: Erik Westra 11. jun 2020
PARTNER /no/My-Page/13945/

RE: Entity changes from contact to person by selecting an extra field

Hello?

Av: Erik Westra 25. jun 2020
STAFF /no/My-Page/5821/

RE: Entity changes from contact to person by selecting an extra field

Hi Erik,

What you are experiencing is partly legacy and the result of architecting an API around a product. You may know that before version 8, there was no concept of a standalone Person, not in Sales anyway. Therefore, the data providers responsible for fetching company information were also responsible for fetching person information as well. Sure, there are internal flags that can be set to get just company information (providing that's all you asked for), as well as company information with just the responsible person for that company, and/or both company and person information. Unfortunately you have to be pretty close to the database access code to manipulate these switches, impossible via the Services API.

Therefore, the fields you ask for represent the closest indicators as to what switches should be set. With regards to the FindContact provider, this is not trivial. In order to understand that, you must understand the inner workings of the Wizard of Oz.

If all you need is company information, I suggest you use the SimpleContact archive provider instead. That should be able to give you everything you need about that company. If you need more fields related to that company, but not found in the available columns list, you will likely have to use the Dynamic archive provider instead. The syntax is documented here.

Hope this helps!

Av: Tony Yates 3. jul 2020
PARTNER /no/My-Page/13945/

RE: Entity changes from contact to person by selecting an extra field

Hi Tony,

thank you for the detailed explanation. I'll have to check whether it is a problem if Companies that do not have an 'our contact' are not included. And if that is a problem I would need to investigate the workaround you described.

 

Erik 

Av: Erik Westra 3. jul 2020
STAFF /no/My-Page/10289/

RE: Entity changes from contact to person by selecting an extra field

Hi Erik,

A comment regarding companies (DB contacts) that are missing a "Our contact".

Defintion: I use the term company and by that mean the entity contact in the DB (so that's clear :))

From a SuperOffice GUI business logic perspective, a company without an "Our contact", is an invalid company that wouldn't be possible to save. Well, there isn't even an option so select "not set" in that listbox in the GUI.

When objects, such as a company, are imported or sometimes created using more low level techniques, it might be possible to create records in the database that doesn't have mandatory fields, such as "Our Contact", filled.

That's the reason for the SetDefaults-function often available (maybe always available) in the Agents-API, so that you always pre set the mandatory fields with default values and then set your own settings. That way the mandatory fields are always set and you ensure the creation of a valid object, from a SO business logic perspective.

So, don't necessary expect invalid objects to behave in expected ways and do clean up your database and make sure that the companies that are invalid by missing an "Our Contact", gets that set. That might save you from trouble in other use cases involving these companies.

That is just my humble, but firm, suggestion. :)

/Marcus

Av: Marcus Svenningsson 7. jul 2020
PARTNER /no/My-Page/13945/

RE: Entity changes from contact to person by selecting an extra field

So, don't necessary expect invalid objects to behave in expected ways and do clean up your database and make sure that the companies that are invalid by missing an "Our Contact", gets that set. That might save you from trouble in other use cases involving these companies.

You make it sound like I had any influence on the data currently present, haha.

From a SuperOffice GUI business logic perspective, a company without an "Our contact", is an invalid company that wouldn't be possible to save. Well, there isn't even an option so select "not set" in that listbox in the GUI.

This is very valuable information. We will investigate if the 'missing "our contact"' fields are indeed the problem.

Av: Erik Westra 7. jul 2020
PARTNER /no/My-Page/13945/

RE: Entity changes from contact to person by selecting an extra field

Aparently the missing 'our contacts' were not the problem.

Using GET /api/v1/Contact (FindContact archive provider) yields different results than using GET /api/v1/Archive/SimpleContact while providing the same selection.

Removing the email/emailAddress field from the selection ensure they are giving the same results. To me that sounds like a bug in the implementation of the FindContact archive provider.

Av: Erik Westra 7. jul 2020
STAFF /no/My-Page/5821/

RE: Entity changes from contact to person by selecting an extra field

Hi Erik,

Are you still referring to the same query paramters as your original post?

These two queries return the same contact list, even though email/emailAddress is in the SimpleContact query parameters.

GET https://sod.superoffice.com/Cust12345/api/v1/Contact?$select=contactId%2Ccode%2Cname%2CcontactAssociate%2FpersonId%2Ccategory%2Cbusiness%2Corgnr%2Cnumber,contactAssociate/associateDbId 


GET https://sod.superoffice.com/Cust12345/api/v1/Archive/SimpleContact?$select=email/emailAddress,contactId%2Ccode%2Cname%2CcontactAssociate%2FpersonId%2Ccategory%2Cbusiness%2Corgnr%2Cnumber,contactAssociate/associateDbId 
 
Adding email/emailAddress to the FindContact provider does then include person details. It doesn't seem to exhibit the same behavior when invoked via the FindDialog in the client with a contact email address criteria. I'll have to look into this and determine what's different. I suspect it's just a query parameter or configuration issue rather than actual API bug. 
 
 
Av: Tony Yates 8. jul 2020