Dynamics Data Export Service – uważaj co usuwasz z systemu 😉

Dynamics Data Export Service jest darmowym dodatkiem do systemu Dynamics 365. Pozwala on na automatyczny eksport danych przechowywanych w naszym CDS do wybranej instancji bazy SQL w chmurze Azure. W artykule tym opiszę problem, na który natrafiliśmy, korzystając z tej usługi w środowisku, w którym wykorzystujemy procedury automatycznych wdrożeń systemu (w kronikarskiego obowiązku wspomnę, że zostały one zbudowane na platformie Azure DevOps). Mam nadzieję, że dzięki temu być może unikniecie przykrych niespodzianek powodowanych sytuacją, którą opiszę poniżej.

Do czego wykorzystywany jest Data Export Service i baza danych, do której replikowane są dane z posiadanej instancji usugi Common Data Service? Większość przypadków, z którymi do tej pory się spotykałem, związane było to z zamiarem wykorzystania wspomnianych komponentów do budowy systemu raportowego lub innego rozwiązania, udostępniającego dane ze źródłowego systemu. Intencja jest w tym przypadku jak najbardziej chwalebna. Chodzi głównie o to, żeby nie obciążać operacyjnej bazy dodatkowymi zapytaniami. Dodatkowym profitem omawianej konfiguracji jest oszczędność operacji, wykorzystujących usługi sieciowe CDS, których to liczba jak zapewne wiecie, nie jest obecnie nieograniczona. Na początku pozwolę sobie opisać środowisko, którego dotyczył problem. Wszystkie systemy wchodzące w skład rozwiązania znajdowały się w chmurze. Zarówno środowisko developerskie, jak i pozostałe (w tym prezentowane na poniższym diagramie środowisko testowe) korzystały z rozwiązania Data Export Service do przesyłania danych z systemu Dynamics do zewnętrznej bazy Azure SQL Server. Z bazy tej z kolei korzystała stworzona przez nas aplikacja, która udostępniała dane znajdujące się w systemie Dynamics. Co jest istotne dla naszego przypadku – warstwa dostępu do danych omawianej aplikacji wykorzystywała bibliotekę Entity Framework oraz klasy kontekstu generowane w sposób automatyczny na podstawie schematu bazy przechowującej dane (podejście database-first). Kod rozszerzeń systemu Dynamics oraz aplikacji korzystającej z on-line’owego SQL-a wdrażany był na środowisko testowe w sposób automatyczny za pomocą procesów skonfigurowanych na platformie Azure DevOps. Natomiast za zarządzanie schematem oraz zawartością bazy danych Azure SQL odpowiedzialna była aplikacja Dynamics Export Service.  

Prezentowana powyżej konfiguracja działała całkiem sprawnie do momentu, w którym odkryliśmy pewne niepożądane przez nas zachowanie rozszerzenia Data Export Service (dla ułatwienia – będę używał skrótu DES w dalszej części artykułu). Otóż w momencie usuwania atrybutów encji w usłudze Common Data ServiceDES nie usuwa automatycznie tożsamych atrybutów z bazy SQL, do której są przesyłane dane składowane w systemie Dynamics. Usługa działa w dalszym ciągu poprawnie (najwyraźniej wewnętrzny flow odpowiadający za przesyłanie konkretnego, usuniętego atrybutu jest również deaktywowany) natomiast w bazie danych pozostaje nam „osierocona” kolumna, która nie jest w żaden sposób wykorzystywana. W Internecie możemy znaleźć wiele dyskusji na temat niepoprawnego działania DES-u również w przypadku dodawania wielu niestandardowych atrybutów do encji Common Data Service. W naszym projekcie nie spotkaliśmy się jednak z tym problemem.

Co wydarzyło się w omawianym powyżej przypadku? Otóż na środowisku developerskim zostały dodane atrybuty encji, które zostały chwile później usunięte. Być może przyczyną była zmiana wymagań funkcjonalnych, błąd dostosowującego lub (bardziej prozaiczny powód) zwykła literówka w nazwie encji. Cała operacja wydarzyła się jednak na tyle szybko, że usunięty atrybut nie trafił nigdy na środowisko testowe. W międzyczasie Data Export Service zdążył jednak dodać usunięty atrybut do bazy danych, na podstawie której narzędzia Entity Frameworka wygenerowały nowe klasy kontekstu. Oczywiście zawierały one atrybuty odpowiadające kolumnom w bazie, które nigdy nie zaistniały w środowisku testowym. Możecie domyślić się, co wydarzyło się w momencie wdrożenia na środowisko testowe nowej wersji aplikacji. Oczywiście był to SPECTACULAR FAILURE :O, niedziałająca aplikacja, płacz i zgrzytanie zębów.

Jaki morał następuje z tej historii? Nie ufaj nikomu! 😉 A na pewno – nie ufaj usłudze Dynamics Export Service. W momencie jakichkolwiek zmian w modelu danych aplikacji wykorzystującej Common Data Service (dodawanie, usuwanie oraz zmiana atrybutów encji) kontroluj czy zmiany te przeniosły się poprawnie do bazy danych, wykorzystywanej w czasie synchronizacji. Oszczędzi Ci to siedzenia do późna w piątkowy wieczór i zastanawiania się, co mogło pójść nie tak. Tego na pewno każdy, a na pewno niżej podpisany 😊 wolałby uniknąć.

Total Views: 214 ,
Be the first to comment

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *