Veel recente implementaties van Dynamics 365 lijken erop te wijzen dat de strategie van Microsoft om Dynamics AX en CRM binnen één Dynamics 365-familie te verenigen, zijn vruchten afwerpt. Steeds meer klanten kiezen voor een combinatie van Operations en Sales. In dit blog lees je hoe je Microsoft Dynamics 365 for Sales (CRM) en Microsoft Dynamics 365 for Finance & Operations (ERP) succesvol integreert.

Inleiding

De meesten van ons hebben waarschijnlijk enige affiniteit met de Common Data Service. Deze kan ook worden gebruikt voor de uitwisseling van gegevens tussen Dynamics 365 for Sales (CRM) en Dynamics 365 for Finance and Operations (ERP). Er zijn echter twee problemen. Ten eerste biedt de Common Data Service op het moment van schrijven nog geen real-time mogelijkheden. Ten tweede vindt de gegevensuitwisseling achter de schermen plaats, op het niveau van data en services. Om D365S en D365FO voor de gebruiker als één systeem te laten aanvoelen, hebben we echter een andere vorm van interactie nodig, een die is gebaseerd op real-time gegevensuitwisseling en data-interactie op het niveau van formulieren. Het aanmaken van een verkooporder in D365FO vanuit D365S zou een gebruikservaring moeten opleveren die de ‘native’ D365FO-ervaring sterk benadert.

Concepten voor de interactie tussen de CRM- en ERP-omgeving

Voor een recent project wilde een klant de nadruk leggen op D365S als primair systeem voor klantenbeheer en -interactie en de nadruk leggen op D365FO als verkoopsysteem. Het idee was om alle gebruikers te laten werken vanuit een dashboard in D365S dat een 360 graden klantenoverzicht bood, alsook ondersteuning voor CTI (integratie met het telefoonsysteem). De klanteninteractie in D365S kon resulteren in het aanbieden van een offerte of in directe verkoop. In beide gevallen was het nodig om de gebruiker door te leiden naar de D365FO-omgeving. Om daarbij voor een naadloze ervaring te zorgen, evalueerden we de volgende twee concepten:

  1. Hub-2-Hub (knooppunt naar knooppunt): Bij dit concept heeft de gebruiker de beschikking over een “Open in Call Center”-knop waarmee die het klantenserviceformulier in D365FO kan openen voor de klant die op dat moment is D365S is geselecteerd. Dit formulier biedt kant-en-klare D365FO-functies voor het aanmaken of bewerken van een bestaande verkooporder of retourorder (de offerte werd toegevoegd door het aanbrengen van een kleine aanpassing).
  2. Master-slave: Bij dit concept heeft de gebruiker van D365S rechtstreeks toegang tot de snelle-invoerformulieren voor het aanmaken van nieuwe verkooporders en offertes en de detailformulieren in D365FO. Dit maakt het mogelijk om direct wijzigingen aan te brengen in de verkooporder of offerte. Voor dit project besloten we daarnaast om de orderwachtstanden in D365FO te koppelen aan taken in D365S. Dit bood callcenter-medewerkers de mogelijkheid om uitzonderingen voor orders in D365S (zoals openstaande rekeningen) te signaleren, die bij klanten aan te kaarten en waar nodig de orderwachtstand met één muisklik op te heffen in D365FO.

Bij beide concepten wordt de data die in D365FO is aangemaakt of gewijzigd gesynchroniseerd met de data in D365S via de op dat moment beschikbare standaard CDS-templates. Wanneer de gebruiker na een paar minuten het dashboard met het 360 graden klantenoverzicht opent in D365S, zullen de wijzigingen daarin zijn overgenomen. In een paar gevallen was het bestaande, niet-real-time CDS-gedrag ontoereikend om ondersteuning te bieden voor het zakelijke scenario. Zo moeten nieuwe klantrekeningen die in D365S worden aangemaakt direct in D365FO beschikbaar zijn. Als dat niet het geval is, kan het snelle-invoerformulier voor het aanmaken van de offerte of verkooporder in D365FO niet vooraf worden gevuld met de gegevens van de klant die zojuist is aangemaakt in D365S (master-slave-concept), en kan het klantenserviceformulier in D365FO evenmin vooraf worden gefilterd voor die nieuwe klant (Hub-2-Hub-concept). In dit geval moesten we dus voor real-time integratie met Azure LogicApp zorgen om het gewenste resultaat te verkrijgen (iets wat we in dit blog verder buiten beschouwing laten).

De truc: interactie op het niveau van formulieren bewerkstelligen

De ‘truc’ om voor interactie tussen D365S en D365FO te zorgen op het niveau van formulieren is om gebruik te maken van de relatieve vrijheid die we hebben om in D365FO met aangepaste URL-achtervoegsels te werken. Een doorsnee D365FO-URL voor het openen van het verkooporderformulier ziet er als volgt uit: https://<CustomerSpecific>.sandbox.ax.dynamics.com/?mi=MCRCustomerService&cmp=<Company>

Dit is de URL die vanuit D365S werd geopend in het Master-Slave-offertescenario:
https://<CustomerSpecific>.sandbox.ax.dynamics.com/?mi=MCRCustomerService&cmp=<Company>&customerid=575342

Zoals je kunt zien wordt het rekeningnummer in D365S (die voortdurend wordt gesynchroniseerd met de klantenrekening in D365FO via LogicApp) doorgegeven aan D365FO door middel van een aangepast URL-achtervoegsel. Om dit te bewerkstelligen moet je twee aanpassingen maken:

  1. Een knop op basis van JavaScript in D365S (in het vorige voorbeeld de knop “Create quote”, oftewel Offerte maken). De JavaScript-code wordt gehost als webresource. Deze bevat de functie voor het bouwen van de volledige D365FO-URL voor een bepaalde klik op de knop (zie het simpele voorbeeld hieronder).
  2. X++ code in D365FO voor de interpretatie van het aangepaste URL-achtervoegsel: een form event handler-uitbreiding voor het Initialize-event van het formulier die de volgende taken uitvoert (in dit specifieke voorbeeld):
    • Het onderdeel “customerid=<value>” in de URL lezen
    • De overeenkomstige klantrecord vinden in de CustTable
    • De actieve klant in het klantenserviceformulier instellen op deze klant.

Vanwege de Single-Sign-On die Azure AD mogelijk maakt voor D365S en D365FO, zal de D365FO-client ongeveer twee seconden na het klikken op de met JavaScript geprogrammeerde knop worden geopend (de eerste keer verloopt dit altijd iets langzamer als gevolg van caching). En omdat de Master-Slave-aanpak op basis van één klik vergelijkbaar is met het gedrag binnen D365FO, zullen de meeste gebruikers dit als een naadloos proces ervaren.

Een evaluatie van de concepten

Ik geef de voorkeur aan de Master-Slave-aanpak boven de Hub-2-Hub-aanpak, en wel om de volgende redenen:

  1. Bij de Hub-2-Hub-aanpak is het niet mogelijk om parameterwaarden door te geven als die betrekking hebben op nieuwe records. Een goed voorbeeld hiervan is de workflow voor een nieuwe offerte van D365S naar D365FO (zie de bovenstaande Master-Slave-afbeelding). In dit verband is het van cruciaal belang om de verkoopkans-id in D365S door te geven aan D365FO en die op te slaan in de nieuwe offerterecord die in D365FO is aangemaakt. Alleen in dat geval kan deze nieuwe offerterecord, na het omvormen daarvan tot een D365S-record via synchronisatie met CDS, aan de oorspronkelijke verkoopkansrecord in D365S worden gekoppeld (hetgeen voorkomt dat de integriteit in D365S wordt aangetast).
  2. De Master-Slave-aanpak benadrukt een wezenlijk verschil in het eigendom van de klantenentiteit. Dit maakt het duidelijk voor gebruikers dat zij hun proces altijd moeten beginnen in het 360 graden klantenoverzicht op het dashboard van D365S. Door vanuit D365S rechtstreekse toegang te bieden tot alle verkoopfuncties in D365FO, kan de toegang tot de klantgerelateerde formulieren worden geminimaliseerd en/of worden beperkt tot ‘view only’-rechten. Dit vereenvoudigt het gebruik van beide systemen voor de doorsnee gebruiker.
  3. Het Master-Slave-concept bespaart de gebruiker de nodige muisklikken vergeleken met de Hub-2-Hub-aanpak.

Het sterkste punt van de Hub-2-Hub-aanpak is dat deze de noodzaak van aanpassingen tot een minimum beperkt. Ik denk echter dat de minimale programmeerinspanning die nodig is voor het toepassen van het Master-Slave-concept niet opweegt tegen de hierboven beschreven nadelen.

Evaluatie van de oplossing

Hoewel deze oplossing goed door de klant werd ontvangen in de context van dit specifieke project, is het nodig om een paar kritische kanttekeningen te plaatsen:

  1. De oplossing die in dit blog wordt gepresenteerd, scharniert op het gegeven dat de D365FO-kernel de mogelijkheid biedt om aangepaste URL-parameters te gebruiken. Omdat dit in de toekomst zou kunnen veranderen (met deze techniek kan ook kwaadaardige code worden geactiveerd!), vertegenwoordigt dit een significant zwak punt.
  2. Het basisgedeelte van de URL is idealiter niet hardgecodeerd in JavaScript, maar wordt dynamisch opgehaald op basis van een ‘Active environment’-parameter die in D365S is ingesteld.
  3. Men zou ervoor kunnen kiezen om de mogelijkheid te bieden om de naam van de parameter (in het bovenstaande voorbeeld: “customerid”) te configureren met behulp van een parameter. Dit zou potentiële conflicten kunnen voorkomen met nieuwe ‘kernel’-parameters die Microsoft zou kunnen introduceren. Aan de andere kant: als de aangepaste URL-achtervoegsels als een ‘service’ worden beschouwd, zou dat tegen deze ‘configureerbare’ aanpak pleiten.

Deze blog verscheen eerder op de site van Patrick Mouwen: http://patrickmouwen.com/functional/dynamics-365-crm-and-erp-interaction/