Moje boje z wirtualnymi encjami

CRM Plugin Registration Tool, CRM SDK, Dynamics 365

Jedną z najbardziej oczekiwanych nowości, wprowadzonych w systemie Dynamics 365 CE w wersji 9., była możliwość tworzenia wirtualnych encji. Mechanizm ten pozwala na prezentacje w ramach interfejsu systemu danych, które znajdują się poza bazą Dynamics 365. Dzięki zastosowaniu wirtualnych encji struktury danych, które znajdują się poza głównym repozytorium systemu, z punktu widzenia użytkownika końcowego nie różnią się w żaden sposób od jego natywnych obiektów. Do ich prezentacji możemy wykorzystywać większość mechanizmów systemu Dynamics 365 (listy, widoki, wyszukiwanie zaawansowane, itp.).  Do tej pory implementacja podobnej funkcjonalności wiązała się z koniecznością fizycznego importu danych do bazy systemu. Wirtualne encje miały wyeliminować wspomniane wymaganie i „domknąć” zestaw możliwości łatwego budowania widoku 360 stopni klienta.

Z użyciem wirtualnych encji wiążą się obecnie pewne ograniczenia. Po pierwsze, dane udostępniane za pomocą omawianego mechanizmu są dostępne jedynie w trybie „tylko do odczytu”. Po drugie, jedynym dostępnym w „pudełku” dostawcą danych jest w tym momencie OData v4 Data Provider.  Na szczęście Microsoft pozwolił programistom na tworzenie własnych bibliotek, pozwalających na pobieranie danych i prezentowanie ich w postaci wirtualnych encji. Ogłoszenie wprowadzenia do systemu tej możliwości spowodowało wybuch ogromnego entuzjazmu w społeczności programistów Dynamics 365.

Teraz, kiedy wirtualne encje są już dostępne na rynku od kilku dobrych miesięcy, postanowiłem zapoznać się z tym mechanizmem i stworzyć własnego, niestandardowego dostawcę danych. Źródłem danych dla mojej wirtualnej encji, która reprezentowała w systemie obiekt faktury, była usługa sieciowa, udostępniająca dane faktur w formacie SOAP. Niestety, po spędzeniu kilku wieczorów nad wspomnianym powyżej zadaniem, mogę jedynie napisać że pobieranie danych z zewnętrznych systemów za pomocą niestandardowych bibliotek dostawców danych jest i … jakoś działa.

Nie chciałbym zostać w tym miejscu źle zrozumiany. Idea integracji z zewnętrznymi źródłami danych i możliwość prezentacji ich wewnątrz interfejsu Dynamics 365, w identyczny sposób w jaki prezentowane są dane z natywnych źródeł, to wspaniała rzecz. Niestety, po raz kolejny w przypadku nowości wprowadzanych w naszym ulubionym systemie – wykonanie udostępnionej użytkownikom funkcjonalności momentami woła o pomstę do nieba.

Jak to działa?

Jak już wspomniałem powyżej, postanowiłem zbudować niestandardowy provider dla usługi sieciowej WCF, udostępniającej dane o fakturach w postaci klasycznego SOAP-a. Przystąpiłem do pracy z dużą ilością entuzjazmu, niestety po około dwóch godzinach odszedłem od komputera z wielkim „WTF?” w głowie.

Dla standardowego dostawcy danych OData V4 Microsoft dostarczył dość dobry opis konfiguracji tego mechanizmu. Niestety, w przypadku chęci skorzystania z niestandardowych bibliotek, dokumentacja jest tak bardzo ogólna jak jest to tylko możliwe. Na stronach Microsoftu dostępne jest jedynie teoretyczne wprowadzanie oraz bardzo prosty  przykład implementacji rozszerzenia (pluginu), obsługującego metodę RetrieveMultiple. Dzięki Cthulhu, mamy jeszcze blogosferę, gdzie można uzupełnić brakującą wiedzę i informacje. Szczególny #szacun należy się Jasonowi Lattimerowi, który dostarczył opis „krok po kroku” konfiguracji niestandardowego dostawcy danych (https://jlattimer.blogspot.com/2017/12/creating-custom-virtual-entity-data.html) oraz przykład jego implementacji (https://github.com/jlattimer/D365CustomDataProvider).

Błąd na błędzie

Osobny akapit należy poświęcić naszemu ukochanemu narzędziu do rejestracji Pluginów, które w czasie rejestracji nowego dostawcy oraz źródła danych potrafi wywalić się nawet kilkukrotnie. Dobrze, że Microsoft zdecydował się dostarczyć nam gotowe narzędzie (mógł przecież powiedzieć to, co w przypadku auto-numeracji: „Droga społeczności, oto jest API, używajcie go sobie jak tylko chcecie” ;)), szkoda jedynie że nie przetestował go solidnie. Ilość pojawiających się w różnych momentach błędów sugeruje, że być może nie uruchomił go nawet po zakończeniu implementacji :/.

 

Ponadto różne wersje Plugin Registration Toola, które możemy pobrać z repozytorium Nuget, współpracują jedynie z konkretnymi wersjami Dynamics 365 (różniącymi się czasem trzecią cyfrą po przecinku). Jeżeli używacie danej, działającej wersji, a Microsoft w międzyczasie postanowił zaktualizować po cichu Waszą organizację to być może… macie pecha :O.

Błędy pojawiają się również w interfejsie przeglądarkowym samej aplikacji. Jeżeli zechcecie utworzyć nowe źródło danych z poziomu listy dostępnych źródeł – wszystko przebiegnie prawidłowo i system wyświetli okno pozwalające na wybór skonfigurowanego uprzednio dostawcy danych. Jeżeli zrobicie to jednak z innego miejsca w systemie (np. z poziomu zapisanego wcześniej źródła lub wyszukiwania zaawansowanego) – wspomniane okno nie pojawi się, a operacja zapisu rekordu zakończy się błędem.

Potencjalne i rzeczywiste trudności

Projektując narzędzia, pozwalające na konfigurację źródeł danych dla wirtualnych encji, Microsoft wykazał się sporym brakiem konsekwencji. Jak już wspomniałem powyżej, źródła danych muszą być konfigurowane z poziomu ich listy (znajdującej się w sekcji „Dostosowania” -> „Administracja”). Pomimo że dla każdego z dostawców są one zapisywane wewnątrz encji systemu CRM – aktualnie nie jest możliwe stworzenie nowego źródła z poziomu np. listy zaawansowanego wyszukiwania. Co więcej, w przypadku encji reprezentującej zewnętrzne źródło danych, aplikacja wymaga konfiguracji mapowania klucza głównego tego obiektu na klucz, pochodzący z zewnętrznego systemu. Po diabła, skoro za pobieranie danych odpowiedzialny jest zewnętrzna biblioteka, która w żaden sposób nie korzysta z ww. atrybutu? Dodatkowo dla wszystkich wirtualnych encji, korzystających z niestandardowych dostawców, możliwe jest zdefiniowanie mapowań atrybutów w module dostosowań systemu, co również nie jest w żadnej sposób wykorzystywane przez implementowane rozszerzenia. Tym razem wspomniane mapowania nie są na szczęście wymagane, ale twórcy systemu mogliby to uwzględnić i w stosowny sposób zmodyfikować interfejs aplikacji. W tym momencie dostępny konfigurator konfunduje użytkowników, którzy rozpoczynają przygodę z omawianym mechanizmem oraz wprowadza niepotrzebne zamieszanie.

Niestety, opisane powyżej błędy i niedoróbki, w powiązaniu z niemalże całkowitym brakiem dokumentacji, mogą spowodować to, że w teorii rewelacyjny mechanizm nie będzie wykorzystywany. Duża bariera wejścia i możliwy, wynikający z niej, niski poziom adopcji może w kolei spowodować sytuację, w której Microsoft nie zdecyduje się na jego dalsze rozwijanie. Niestety, z uwagi na dużą ilość błędów oraz niejasności, nie mogę w tym momencie zarekomendować wykorzystania mechanizmu niestandardowych dostawców danych dla wirtualnych encji w rzeczywistych, produkcyjnych wdrożeniach. Wydaję mi się, że dużo lepszym podejściem będzie stworzenie usługi REST, która będzie pośredniczyć w komunikacji między systemem Dynamics 365 i zewnętrznym źródłem danych (o tym, w jaki sposób zaimplementować taką usługę pisałem nieco w tym miejscu: http://xrmlabs.piotrgaszewski.pl/2018/03/09/dynamics-365-ce-wirtualne-encje-i-protokol-odata-v4/), a następnie użycie standardowego providera dla protokołu OData V4. Mam jedynie nadzieję, że w kolejnych aktualizacjach systemu Microsoft poprawi działanie omawianego mechanizmu oraz uzupełni jego dokumentacje. Aktualna wersja nie jest niestety „enterprise-ready”.

Smuteczek.

Mechanizm niestandardowych dostawców danych dla wirtualnych encji – podsumowanie:

Plusy:

  • Jest i (po przebrnięciu przez wszystkie trudności) działa.

Minusy:

  • Niepełna dokumentacja
  • Niedoróbki narzędzi konfiguracyjnych
  • Liczne błędy
Total Views: 221 ,

Dodaj komentarz