Wykorzystanie bazy NoSQL do przenoszenia danych między organizacjami Dynamics 365 CE

Dynamics 365, Dynamics CRM, MongoDb, top5

Wiele wody w Wiśle upłynęło od czasu pojawienia się poprzedniego wpisu na blogu. Niżej podpisany nie ma niestety nic na swoje usprawiedliwienie, może poza udziałem w kilku mocno zajmujących przedsięwzięciach (zarówno na stopie zawodowej jak i prywatnej). Tymczasem…

 

… w dzisiejszym wpisie chciałbym przedstawić sposób, za pomocą którego możemy wykorzystać bazę danych typu NoSQL do przenoszenia danych między organizacjami Dynamics 365 CE.

 

Do tej pory do przenoszenia danych między organizacjami Dynamics CRM/365 wykorzystywałem następujące narzędzia:

 

  • Standardowe mechanizmy eksportów/importów danych do plików
  • Narzędzie Data Configuration Migration Ulitity dostępne w ramach pakietu CRM SDK (w czasach, kiedy SDK jeszcze istniało :)).
  • Pakiety integracyjne SSIS takie jak KingswaySoft Dynamics 365 Integration Toolkit lub Cozyroc Dynamics CRM Connector
  • Zaawansowane platformy do wymiany danych takie jak np. Scribe
  • Niestandardowe aplikacje .NET, wykorzystujące usługi sieciowe Dynamics CRM/365 do przenoszenia danych

 

Przenoszenie danych za pomocą plików sprawdza się całkiem dobrze w przypadku prostych, niezbyt licznych i niepowiązanych ze sobą zbiorów danych. Metoda ta działa gorzej w przypadku kilku encji, powiązanych ze sobą wzajemnymi relacjami (np. Lead <-> Opportunity). Oczywiście, import danych jest możliwy (zwłaszcza jeżeli wspomożemy się zewnętrznymi narzędziami umożliwiającymi łatwe przekształcenie danych zapisanych w plikach, np. Excelem :)). Cały proces można jednak określić (cytując Tomka Kruza) jako: „pain in the ass” :O.

 

Narzędzie Data Configuration Migration Ulitity sprawdzało się w tym przypadku dużo lepiej. Niestety wersja dedykowana dla systemu w wersji 9.0 nie była dostępna w momencie pisania artykułu. Natomiast ta, pochodząca z SDK 8.X, nie chciała współpracować z moją instancją Dynamics 365 9.0. Z kolei wyżej wymienione pakiety SSIS lub platformy integracyjne mogą odstraszyć potencjalnych użytkowników dużym stopniem skomplikowania i (w przypadku bardziej zaawansowanych scenariuszy) koniecznością wykupienia odpowiednich licencji.

 

Ostatnia z wymienionych metod – niestandardowa aplikacja .NET, odczytująca i zapisująca dane w bazach organizacji za pomocą Dyn365 API/usług sieciowych – zazwyczaj sprawdza się dość dobrze. Niestety (poza umiejętnością kodowania) wymaga ona zazwyczaj dodatkowego repozytorium danych. Oczywiście, możemy przeprowadzić cały proces eksportu/importu w pamięci aplikacji, ale w przypadku dużych zbiorów danych może się to wiązać z dodatkowymi problemami, takimi jak konieczność wykorzystania dużej ilości pamięci operacyjnej lub implementacji dodatkowej logiki związanej z przetwarzaniem danych w przypadku błędów, nieobsłużonych wyjątków, itp. Zastosowanie zewnętrznego repozytorium danych do importu wydaje się więc dużo bardziej pewną opcją. Role takiego repozytorium może pełnić właśnie baza dokumentowa.

 

Proces przenoszenia danych wygląda w tym przypadku następująco:

 

Zaletą omawianego rozwiązania jest fakt, że wyeksportowane dane możemy „odłożyć na półkę” i zaimportować je do docelowego systemu w dowolnym momencie w przyszłości. Łatwość korzystania z bazy NoSQL sprawia z kolei, że implementacja całego rozwiązania jest dużo szybsza niż w przypadku klasycznej bazy relacyjnej, systemów kolejkowych, zbiorów plikowych lub innych lokalnych repozytoriów danych. Nie musimy również martwić się jakimkolwiek przekształcaniem danych ponieważ np. w przypadku drivera bazy MongoDb dla .NET – serializacja obiektów .NET do formatu obsługiwanego przez bazę odbywa się w sposób automatyczny i wykonywana jest w momencie zapisu danych przez stosowną bibliotekę.

Poniżej znajdziecie krótki opis przykładowej implementacji omawianego mechanizmu.  Do przechowywania danych pobranych z organizacji Dynamics 365 wykorzystamy wspomnianą powyżej bazę MongoDb. Link do pełnego kodu omawianego rozwiązania znajdziecie na końcu artykułu.

Pierwszym komponentem który musimy dodać do naszego projektu, jest biblioteka umożliwiająca komunikację z bazą NoSQL. W tym celu z poziomu Visual Studio instalujemy pakiet Nuget o nazwie MongoDB.Driver. Omawiana biblioteka umożliwia dostęp do bazy danych MongoDb z poziomu aplikacji .NET.

Pierwszym krokiem procesu, który będziemy musieli zaimplementować, jest pobranie danych ze źródłowego systemu i zapisanie ich w bazie dokumentowej. Nie będę w tym miejscu opisywał w jaki sposób za pomocą bibliotek SDK lub usług sieciowych pobrać dane z organizacji Dynamics 365. Przykładowy kod, który wykorzystuje wzorzec repozytorium i który pobiera dostępne rekordy typu „Subject” z omawianego systemu może wyglądać następująco:

var subjectsRepository = factory.Get<SubjectsRepository>();
var subjectsList = subjectsRepository.GetAllSubjects().ToList<Subject>();

Kolejnym krokiem w procesie będzie zapisanie pobranych danych w lokalnej bazie dokumentowej. Na potrzeby tego artykuły wykorzystamy bazę o nazwie „Dyn365Backup” dostępną na lokalnie zainstalowanej instancji MongoDb. Na początku tworzymy w kodzie obiekt klienta ww. bazy danych:

var documentDbClient = new MongoClient();
var documentDb = documentDbClient.GetDatabase("Dyn365Backup");

Ważnym krokiem, o którym musimy pamiętać jest zarejestrowanie wymaganych przez platformę Dynamics 365 typów danych. Nie mają one odpowiedników typów w formacie JSON, który domyślnie jest wykorzystywany do zapisywania informacji w bazie NoSQL. Rejestracja ww. klas jest w tym wypadku niezbędna do ich prawidłowej serializacji lub deserializacji.

Przykładowa linia kodu rejestrująca typ danych EntityReference:

BsonClassMap.RegisterClassMap<EntityReference>();

Warstwa dostępu do danych zapisanych w bazie MongoDb może wyglądać następująco:

Zapisanie danych o pochodzących z systemu Dynamics 365 tematach („subjectach”) w bazie dokumentowej będzie już tylko formalnością:

 

subjectsRepository.InsertMany(subjectsList);

 

Przykładowy, zserializowany i zapisany w formacie JSON rekord będzie w tym przypadku wyglądał następująco:

Kolejnym krokiem w naszym procesie jest odczytanie zapisanych w bazie dokumentowej danych oraz wysyłka ich do nowej, docelowej organizacji Dynamics 365.

Ponownie korzystamy w tym przypadku z załączonej powyżej klasy SubjectsRepository. Metoda GetAll tej klasy serializuje obiekty JSON z bazy MongoDb do obiektu reprezentującego encję Dynamics 365. Wszystko dzieje się w pamięci aplikacji i nie wymaga żadnego dodatkowego kodowania z naszej strony:

public List<Subject> GetAll()
{
   return this.dataCollection.Find<Subject>(Builders<Subject>.Filter.Empty).ToList<Subject>();
}

Posiadając w pamięci aplikacji zbiór obiektów typu Subject nie powinniśmy mieć żadnych problemów z wysyłką ich do systemu Dynamics 365. Należy jedynie pamiętać, aby usunąć wartość atrybutu obiektu o nazwie EntityState ponieważ w innym przypadku API Dynamics 365 nie będzie w stanie zaimportować obiektu z pamięci jako nowego rekordu. Ważnym faktem w omawianych procesie jest to, że identyfikatory (GUIDy) rekordów w docelowym systemie CRM będą identyczne jak w organizacji, z której importowaliśmy dane. Nie będziemy mieć więc żadnych problemów z ustawianiem relacji między importowanymi obiektami.

Kod importujący dane do systemu CRM załączam jedynie dla formalności 🙂 :

Zalety omawianej techniki przenoszenia danych między organizacjami Dynamics 365 omówiłem na początku artykułu. Pozwolę sobie w tym miejscu przypomnieć niektóre z nich:

 

  1. Brak konieczności korzystania z dodatkowych, często płatnych narzędzi do importu danych między organizacjami CRM.
  2. Możliwość pobrania danych z systemu źródłowego i „odłożenia ich na półkę” w celu importu w późniejszym terminie.
  3. Brak konieczności posiadania i utrzymywania lokalnej, relacyjnej bazy, pośredniczącej w procesie przenoszenia danych.
  4. Łatwość implementacji
  5. <Nerd mode>Możliwość zapoznania się z podstawami działania bazy NoSQL oraz sposobami dostępu do niej </Nerd mode> 🙂

 

Z wad do głowy przychodzi mi jedynie konieczność lokalnej instalacji bazy dokumentowej (w moim przypadku instalacja MongoDb sprowadziła się do kilku kliknięć w przycisk „Next”) oraz opanowania podstaw klienckiego API tejże platformy. To czy gra jest warta świeczki musicie ocenić samodzielnie 😉

 

To już wszystko na dziś. Tymczasem, ponieważ jest to prawie na pewno ostatni wpis na blogu w tym roku:

 

 

Przydatne linki:

Introduction to Document Databases with MongoDB:

https://derickrethans.nl/introduction-to-document-databases.html

C# and .NET MongoDB Driver:

https://docs.mongodb.com/ecosystem/drivers/csharp/

Use the Organization Service to read and write data or metadata:

https://msdn.microsoft.com/en-us/library/gg309449.aspx

 

Pełen kod źródłowy przykładowych aplikacji do wymiany danych między bazą dokumentową i systemem Dynamics 365.

https://github.com/gashupl/Dyn365withMongoDb

Total Views: 515 ,

One thought on “Wykorzystanie bazy NoSQL do przenoszenia danych między organizacjami Dynamics 365 CE

Comments are closed.