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

UserDefinedFieldInfo.GetPublishedUs­erDefinedFieldFromProgId crasches in on-premises environment

Hi,

When trying to provision a user defined field in online environment all works as expected.

var udFieldSale = udfAgent.GetPublishedUserDefinedFieldFromProgId("GetAcceptDocId:1", UDefType.Sale);

But when running the same code in an on-premises environment I get an exception:

The message with Action 'http://www.superoffice.net/ws/crm/NetServer/Services83/UserDefinedFieldInfo/GetPublishedUserDefinedFieldFromProgId' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver.  Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

SuperOffice environment info:

Version: 8.0
Netserver:  SuperOffice 8.0 SR6 Build 6465.b

As a temporary solution I use method GetUserDefinedFieldFromProgId instead. Not sure what the consequences are but someone maybe knows that.

Regards

Gunnar

 

RE: UserDefinedFieldInfo.GetPublishedUs­erDefinedFieldFromProgId crasches in on-premises environment

Hi Gunnar,

I don't recall when that method was introduced, but it's likely it was after services version 8.3. If you bump up the RemoteBaseURL to the latest supported version (see the folders in the Remote directory in the web client or web services installation) it will likely work as expected.Otherwise, you are using newer proxies (from nuget) that expose that method in that agent, but wasn't intended/supported in an earlier version of the client installation.

Best regards.

Av: Tony Yates 9. okt 2019

RE: UserDefinedFieldInfo.GetPublishedUs­erDefinedFieldFromProgId crasches in on-premises environment

Hi Tony,

From the documentation it seems like it was introduced in services version 8.3 which is the version my on-prem environment supports:

Regards

Gunnar

Av: Gunnar Stensby 9. okt 2019

RE: UserDefinedFieldInfo.GetPublishedUs­erDefinedFieldFromProgId crasches in on-premises environment

HI Gunnar,

Correct, it was introduced in Services83.

I'm not sure how your environment is configured, but I will assume your website is configured for Remote and NetServer web services is configured elsewhere with DefaultMode set to Local (where the RemoteBaseURL setting is irrelevant).

Is your website web.config settings for Services => RemoteBaseURL set to Services83 ?

<Services>
    <add key="DefaultMode" value="Remote" />
    <add key="RemoteBaseURL" value="http://YOUR_SERVER/Remote/Services83/" />
...
</Services>

The key differences between those methods is the implementation of the UDef caches from where the fields are returned. The newer one has a better up-to-date list of published fields, where as the old one only refreshs every hour.

Best regards.

Av: Tony Yates 10. okt 2019

RE: UserDefinedFieldInfo.GetPublishedUs­erDefinedFieldFromProgId crasches in on-premises environment

Hi Tony,

As you can see in the error message it's Services83 I'm using:
The message with Action 'http://www.superoffice.net/ws/crm/NetServer/Services83/UserDefinedFieldInfo/GetPublishedUserDefinedFieldFromProgId' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver.  Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

Think it's strange why I get the exception, but maybe it's something with that specific services version.

My current solution is to use method GetUserDefinedFieldFromProgId instead.
Do you see any problems with that?

Our app supports both on-premises and online using the same codebase so I think we're better off using GetUserDefinedFieldFromProgId to avoid problems on on-premises installations.

Best regards

Gunnar

Av: Gunnar Stensby 10. okt 2019

RE: UserDefinedFieldInfo.GetPublishedUs­erDefinedFieldFromProgId crasches in on-premises environment

Yes Gunnar, I see what you see. Question is: do you see what you think you see?

I see the namespace URL associated with the version used inside the proxies. This URL is not to be confused with the URL value specified in the RemoteBaseURL setting. Now the proxies should pick this up from the setting, but it's nice to verify this.

Yes, you can continue to use GetUserDefinedFieldFromProgId, but understand that it will not immediately contain newly created fields - only after the cache is refreshed.

Best regards.

Av: Tony Yates 11. okt 2019

RE: UserDefinedFieldInfo.GetPublishedUs­erDefinedFieldFromProgId crasches in on-premises environment

Hi Tony!

Yes, I can confirm that the RemoteBaseURL is using the Services83 endpoint.

The use case is that when a Tenant session starts up I check if all user defined fields exists.
I create the missing ones depending on the result from GetUserDefinedFieldFromProgId  (null => create field).

Our app runs both on-premises and online, which is the appropriate way to check if a fields exist?
This has to work for customers running on-premises version 7.5 and later, and for online customers.

Best regards,

Gunnar

 
Av: Gunnar Stensby 11. okt 2019