Microsoft Dynamics CRM 2016 Integration On Premises and Online with Microsoft Dynamics NAV 2016 / 2017
Since the advent of Microsoft Dynamics 365 in November 2016, NAV Development Team worked hard to move from the old Microsoft Dynamics CRM 2015 SDK (7.0) to the shining latest one from Microsoft Dynamics CRM 2016 (8.2).
Moving from the old SDK to the new one, required not only platform changes but also a deep code review. In this blog, I am trying to explain what is changed within latest versions and cumulative updates and also which tables are allowed to be integrated as entities within NAV CRM Integration feature.
PLATFORM AND CODE CHANGES : A BIT OF HISTORY
New SDK libraries, platform and code changes has been introduced in December 2016 cumulative update wave for versions that do support this kind of integration (Microsoft Dynamics NAV 2016 and 2017). Basically, the DLLs that are changed are the following – just for completeness –.
NAV 2016 CU 13 and backwards and NAV 2017 RTM
Microsoft.Xrm.Sdk.Deployment.dll File Version 7.0
Microsoft.Xrm.Sdk.dll File Version 7.0
Microsoft.Xrm.Client.dll File Version 7.0
Microsoft.IdentityModel.Clients.ActiveDirectory.dll File Version 2.18
- All of the above comes from the CRM 2015 SDK (version 7.0)
- Integration are guarantee with CRM 2015 RTM and SP1 On Premise, CRMOL 2015 and CRMOL 2015 SP1
- These are mainly deployed Server side (used to make CRM Web Service calls from NAV Server / NAS Services)
- These are also deployed Client side (because of CSIDE Compilation and PowerShell cmdlet New-NAVCrmTable execution)
NAV CU 14 and forwards and NAV 2017 CU 1 and forwards
Microsoft.Crm.Sdk.Proxy.dll File Version 8.2
Microsoft.Xrm.Sdk.Deployment.dll File Version 8.2
Microsoft.Xrm.Sdk.dll File Version 8.2
Microsoft.Xrm.Tooling.Connector.dll File Version 2.2
Microsoft.IdentityModel.Clients.ActiveDirectory.dll File Version 2.28
- All of the above comes from the Dynamics 365 SDK (version 8.2)
- Integration are possible with CRMOL 2016 and Microsoft Dynamics 365
- These are mainly deployed Server side (used to make CRM Web Service calls from NAV Server / NAS Services)
- These are also deployed Client side (because of CSIDE Compilation and PowerShell cmdlet New-NAVCrmTable execution)
Changes in DLLs, in this case, not only means a brand new platform deployment but also a changes in CSIDE in order to cope with these brand new library methods and artifacts.
To give you one short example, on top of all, with the new 2.28 ActiveDirectory library, used for connection calls, the connection string has been modified a bit and this reflects in an application change in the following global text constants within Table 5330 CRM Connection Setup
Older versions
Name ConstValue
ConnectionWithCallerIdStringFormatTok Url=%1; UserName=%2; Password=%3; CallerID=%4
Newer versions
Name ConstValue
ConnectionWithCallerIdStringFormatTok Url=%1; UserName=%2; Password=%3; CallerID=%4; authtype=Office365
This is just one of the changes that has been introduced since NAV 2016 CU 14 / NAV 2017 CU 1 in order to cope with the new DLLs handling.
Roughly speaking, then, not only it has to be deployed the client and server platform stack but also a typical activity of code compare and merge is required in order to have CRM Integration working appropriately with the new assemblies.
What I am suggesting partners, if they cannot perform a full compare and merge of all objects – as per best practice -, is to simply filter in the Object Designer, all the NAV Objects that have a ‘CRM’ substring in their Name with a filter like *@crm*. This will roughly cover all of the objects that might potentially be in need to be changed / merged.
Resuming this chapter, then, to integrate with CRMOL 2016 and Dynamics 365, you must deploy NAV 2016 CU 14 or higher / NAV 2017 CU 1 or higher versions. But what about, CRM 2016 On Premise integration?…
CRM 2016 On Premise integration
The platform and code changes introduced with March 2017 Cumulative Updates for both NAV 2016 (Cumulative Update 17) and NAV 2017 (Cumulative Update 4) are letting now performing smooth integrations also with CRM 2016 On Premise.
Stated the above, then, by deploying these cumulative updates or performing an update of both platform files and application objects, it is now possible to integrate also with CRM 2016 On Premise (8.1 and higher).
If you are working with CRM 2016 On Premise or On Line, we warmly recommend you to move your current platform and application to March 2017 cumulative update 17 for NAV 2016 or CU 4 for NAV 2017.
See below a screenshot of Page 5330 that shows its changes (NAV 2017 CU 4).
Worth a notice the Authentication Type field. Considering the currently CRM SDK available types (Office365,Ad,IFD,OAuth), these lead to different connection string formats. For IFD and OAuth this string is even editable to provide all required parameters manually, where and if needed.
Text Constant ConnectionWithCallerIdStringFormatTok does not include authtype=Office365 anymore. Authtype has now become an optional parameter that can be seen in the Connection String field and managed by the “Authentication Type” field.
NAV CRMTable type supportability
Working with NAV Table objects whom structure comes from CRM (also typically known as CRMTables), you might have noticed that here are some of these that could be generated using New-NAVCrmTable, imported and compiled into NAV, but they cannot be run inside NAV and also they cannot be referenced by CSIDE code. E.G. any filtering on them will result in an error mesage.
One example of these is standard CRM table ‘activityparty’ – this could be used to easily reproduce the design limitation. Please be sure that in this table there is at least one record and by running that CRMTable you will receive an error like the following
Other examples are any CRM relational table (used to simply maintain relations between 2 CRM tables) which are created in CRM for N:N relations.
Why this is happening?
The current implementation of the CRM data provider only gives access to table entities (same logic for all entities).
NAV CRM Integration require entities to support the following operations:
Retrieve
RetrieveMultiple
Create
Update
Delete
Associate/Disassociate (simple version with fields like id1, id2)
Execute (only for setting state)
Considering the ‘activitypart’ example, the following references:
https://msdn.microsoft.com/en-us/library/gg328549.aspx
https://msdn.microsoft.com/en-us/library/hh372955.aspx
Reveals it is a special type of relationship not managed by intersections but though a list of ‘activityparty’ (called ‘partylist’’).
This is not what NAV CRM Integration feature consider as an “Entity” and therefore it is not intended nor possible to create a relationship to this entity. While the ‘activityparty’ table might contain data in the CRM organization database, the only way to handle the data is through the list in a property of another CRM entity field (e.g. Letter.To).
So, in shorts, CRM does not support Retrieve on the ‘activityparty’ type and NAV can only represent “arrays” as relationships to other tables making this kind of relationship impossible to be represented in the current implementation.
Any workaround or investigation path?
We recommend to stick with and use typical NAV CRM Integration entity as much as possible in your projects. If it is vital, partner and customer might look into writing e.g. a custom ‘activityparty’ .NET object to perform this type of association and use natively CRM SDK.
These postings are provided “AS IS” with no warranties and confer no rights. You assume all risk for your use.
Duilio Tacconi (dtacconi)
Microsoft Dynamics Italy
Microsoft Customer Service and Support (CSS) EMEA
Special thanks to:
Niels-Henrik Sejthen, Steffen Balslev and Stan Pesotskiy from Microsoft Dynamics NAV Development Team.
Stefan Mrosh (Mattern Consult GmbH), Mikkel Bang Matthiasen (ELBEK-VEJRUP.DK), Matteo Montanari (EOS-SOLUTIONS.IT), Sergio Montanari, Matteo Veronesi, Claudio Marchetti (XDATANET.COM), Tomas Pavliček, Ivo Molek (WEBCOM a.s.), Narender Rajan (TECMAN.CO.UK), Michal Relich (ESSENCEBS.COM)
