Gegevensuitwisseling tussen Dynamics Customer Engagement en andere applicaties in je organisatie – deel 2: Gegevens synchroniseren

In deel 1 van deze blogserie zijn we ingegaan op de mogelijkheden die er zijn om in Dynamics 365 CE gegevens uit externe systemen te tonen zonder deze op te slaan in Dynamics 365 CE.

Natuurlijk is het vaak toch nodig om gegevens uit externe systemen daadwerkelijk op te slaan in Dynamics 365 CE (of andersom). Denk bijvoorbeeld aan een situatie waarin de basisgegevens van de klanten die je vanuit de klantenservice wilt bedienen worden beheerd in een ander systeem. Een praktijkvoorbeeld hierbij is een pensioenuitvoerder waarbij deelnemers en hun polissen worden beheerd in een pensioensysteem maar waarbij de klantenservice in Dynamics CE werkt en daar vragen van deze deelnemers moet afhandelen.

Technische invulling synchronisatie van gegevens

Om de juiste technische oplossing voor gegevenssynchronisatie te kiezen is het van belang om eerst een aantal te zaken te beantwoorden:

Welke technische mogelijkheden heeft de bronapplicatie? Als dit bijvoorbeeld een verouderde applicatie is zonder API, dan heb je simpelweg minder mogelijkheden dan met een moderne applicatie die wel heeft.

Naast de technische mogelijkheden is het van belang na te denken over hoe snel je nieuwe data wilt synchroniseren, hoe veranderlijk de brondata is en om hoeveel data het gaat.
Als data relatief weinig verandert dan kan het prima zijn om bijvoorbeeld elke nacht de data te synchroniseren, als data direct na aanmaken in het bronsysteem een proces moet starten in het doelsysteem dan moet de data daar ook met minimale vertraging beschikbaar zijn.

Als het om erg veel data gaat, zoals bijvoorbeeld bij de initiële vulling vlak voor de ingebruikname van het systeem, dan is vaak de snelheid waarmee de totale data kan worden overgezet van belang.

Hieronder stippen we een aantal methoden aan die in de praktijk vaak langskomen.

Batchgewijze gegevensuitwisseling

Bij deze manier van gegevensuitwisseling worden de gegevens uit het bronsysteem geëxporteerd naar een bestand, bijvoorbeeld een tekst- of Excel-bestand. Vaak is er daarna bewerking op de data nodig om het geschikt te maken voor import in het doelsysteem. In het Engels heten deze stappen Extract, Transform en Load, afgekort ETL. Gelukkig is er voor ETL veel tooling beschikbaar. Binnen het Microsoft Azure platform is hiervoor Azure Datafactory voorhanden. Azure Datafactory is ontworpen om met hoge snelheid extreme hoeveelheden data (Big Data) te kunnen verwerken. Voor Azure Datafactory is een bestand met bijvoorbeeld 1 miljoen contactpersonen een peuleschil.

Realtime gegevensuitwisseling

In het geval van realtime gegevensuitwisseling is het de bedoeling dat een wijziging in het ene systeem direct wordt doorgevoerd in het andere. Een voorbeeld kan zijn een nieuwe klant die via lead in Dynamics CE wordt aangemaakt, ook direct leidt tot een nieuw account het ERP systeem om een levering af te handelen. Om de processen in beide systemen niet te blokkeren zal de synchronisatie meestal via een achtergrondproces worden uitgevoerd. Aangezien er in dat geval altijd een kleine vertraging de werking van het achtergrond proces zit, wordt er ook vaak gesproken van Near-realtime gegevensuitwsseling. Om pieken in het data aanbod op te kunnen vangen wordt er vaak gebruikgemaakt berichtenverkeer die eerst in een zg. wachtrij of queue worden geplaatst, daarna kan de ontvangende applicatie de berichten in eigen tempo verwerken. Voor het queue-ing mechanisme wordt vaak een (Azure) service bus ingezet. Deze kan naast berichten vasthouden in een queue ook routering uitvoeren. Erg handig als er niet 1 maar meerdere applicaties zijn die de berichten willen verwerken

Een veelgebruikte oplossing is in dit scenario een Azure Logic App die reageert op wijzigingen in de ene applicatie, uit die wijziging een bericht samenstelt en op een queue of topic op een service bus aanbiedt. Daarna is er een tweede proces, bijvoorbeeld ook weer een Azure Logic App, dat de berichten een voor een van de service bus haalt en zorgdraagt voor verdere verwerking naar in de doel applicatie. Net als bij de batchgewijze gegevensuitwisseling kan er hier sprake zijn van allerlei bewerkingen op de aangeboden data alvorens in te laden in de doel applicatie.

Realtime gegevensuitwisseling is vaak complexer dan batchgewijze uitwisseling: er is technische kennis nodig van zowel het versturende- als het ontvangende systeem. Dat kan betekenen dat zowel de leverancier van het bron- als van het doel-systeem moeten worden ingeschakeld om tot een werkende oplossing te komen

Overdenkingen

Voor een succesvolle implementatie van Dynamics CE is het van belang direct na te denken welke datastromen essentieel zijn voor de gebruikers adoptie. Maar integraties zijn vaak complex en er zijn de nodige ontwikkel- en operationele kosten mee gemoeid. De verschillende integratiemogelijkheden kennen hun eigen kostenplaatje, de een is minder complex en dus goedkoper te realiseren dan de ander.

Denk, zeker bij realtime uitwisseling, goed na over de kritische paden. Hoe erg als er om wat voor reden dan ook een bericht uitval? Wil je daar actief een signaal van ontvangen? En welke voorzieningen zijn er nodig een synchronisatiefout te kunnen herstellen?

Maak de integraties niet complexer dan nodig. Denk goed na welke applicatie de natuurlijke eigenaar is van de gegevens en probeer een tweeweg synchronisatie indien mogelijk te vermijden. Als er gaandeweg meerdere point-to-point integraties ontstaan kan dit snel ontaarden in een spaghetti architectuur. Een goed ontwerp van het landschap en een vooruitziende blik helpt dit te voorkomen.

Meer weten?

BusinessBase is naast Customer Engagement specialist ook een integratiespecialist. Alle genoemde technieken passen wij in de praktijk toe voor onze klanten. Een goede applicatie integratie begint met een analyse van het applicatielandschap, de bedrijfsprocessen, de gewenste gegevensstromen en de technische mogelijkheden.