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.

crm3

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

crm2

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)

Comments (4)

  1. Gintautas says:

    Hey Duilio,
    Can we integrate NAV 2017 CU4 wtih CRM2015 (IFD)?

    1. dtacconi says:

      Hi Gintautas,
      yes, this is supported. You have to use NAV 2017 CU 4 or higher (both platform and application as per this blog) AND ZIP solution must come from NAV 2016 CU 16 or higher. Note that 2016 ZIP Solution do not support Item Availability feature within CRM. Thanks to your heads up, we have also updated NAV 2017 CRM Integration System Requirements accordingly
      https://msdn.microsoft.com/en-us/dynamics-nav/system-requirements-for-microsoft-dynamics-nav

  2. Gord says:

    Hi,

    Are there any more SDK upgrades coming in the near future? As this is costing a lot of $$ for us to update our NAV due to this new SDK and there is no mention of the new SDK in the KB article or the Read Me for the December update that was pushed down via Windows update. I need to know before having to installing more NAV cumulative updates because CRM broke something.

  3. dtacconi says:

    @Gintautas. It should be supported and working as per current system requirements.
    https://msdn.microsoft.com/en-us/dynamics-nav/system-requirements-for-microsoft-dynamics-nav#CRM
    I will double check that in my own lab.
    @Gord. The answer is not so simple. Let me reformulate this a bit. With NAV in general (On Premise, PAAS, SAAS) we could only have ONE CRM SDK dispatched. That is the CURRENT design. This means that when CRM vNext will be published, a new CRM SDK should be used to cope with this new integration. A new CRM SDK implies typically both platform and application changes.
    This is the current design of CRM Integration. I cannot stat what will come with NAV vNext but I am sure this will be improved version after version both from a deployment/platform and application perspective.

Skip to main content