Integracja Dynamics 365 CE i Azure Functions

Azure Functions, Dynamics 365, top5

„Serverless computing” jest ostatnio jednym z najpopularniejszych tematów w świecie IT. Czym właściwie są owe „bez-serwerowe” operacje obliczeniowe? W zamierzchłych czasach do uruchomienia napisanego kodu potrzebna była zaawansowana infrastruktura (komputery, system operacyjne, skonfigurowana sieć itp.). Sprawiało to, że często tylko najwięksi gracze na rynku byli w stanie pozwolić sobie na określone, zaawansowane rozwiązania technologiczne, ponieważ ich wdrożenie związane było każdorazowo z ogromnymi kosztami. Te były często nieakceptowalne dla mniejszych, mniej zasobnych finansowo organizacji. Minimalizacje kosztów częściowo osiągnięto za pomocą wirtualizacji. W międzyczasie na rynku pojawiło się wiele możliwości hostingu oprogramowania lub wdrożenia go w jednej z dostępnych na rynku chmur obliczeniowych w modelu PaaS (Platform-as-a-Service). Zdejmowało to z barków specjalistów tworzących oprogramowanie konieczność zajmowania się niskopoziomową infrastrukturą. Cały czas jednak, w czasie implementacji kodu aplikacji, musieli oni brać pod uwagę platformę na której będzie ona wdrożona (np. serwer WWW lub serwer aplikacyjny) oraz jej konfigurację i ograniczenia.

Operacje obliczeniowe bez udziału serwera stanowią ostatni, najnowszy etap ewolucji procesu, polegającego na minimalizacji konieczności wytwarzania oprogramowania z myślą o konkretnym środowisku uruchomieniowym. Dzięki omawianemu sposobowi pisania i wdrażania oprogramowania programista nie musi się już przejmować tematami w rodzaju serwera WWW, używanej wersji frameworka, ustawieniami firmowej zapory ogniowej itp. Może on natomiast skoncentrować się na implementacji pożądanej funkcjonalności za pomocą (prawie ;)) dowolnie wybranego języka programowania.

Aktualnie najpopularniejszymi rozwiązaniami typu „severless” w chmurze Microsoft Azure są:

  • Azure Functions
  • Azure Logic Apps
  • Azure Event Grid

W ostatnim czasie miałem możliwość sprawdzenia możliwości wykorzystania pierwszej z wymienionych powyżej technologii w projektach wdrożeń systemu Dynamics 365 CE. Poniżej postaram się więc opisać możliwości integracji naszej ulubionej platformy CRM z mechanizmem funkcji Azure.

Więcej informacji o samych rozwiązaniach dostępnych na platformie Azure znajdziecie pod adresem: https://azure.microsoft.com/en-us/overview/serverless-computing/

Funkcja uruchamiana jako mikro-serwis

Najprostszym sposobem uruchamiania funkcji Azure jest udostępnienie ich jako mikro serwisów, które następnie będą uruchamiane z poziomu kodu JavaScript lub .NET rozszerzeń systemu CRM.  Opublikowana funkcja jest standardową usługą sieciową, do której możemy odwołać się za pomocą komunikatu POST protokołu HTTP.

Integracja za pomocą mechanizmu Webhooks

Wykorzystując technologię WebHooks, możemy przekazać kontekst operacji w systemie Dynamics 365 jako argument wywołania funkcji Azure. Jedyne co musimy zrobić (poza oczywiście stworzeniem funkcji wykonującej pożądane operacje na danych pochodzących z systemu CRM) to zarejestrowanie wywołania zwrotnego z poziomu Plugin Registration Toola.

 

Konfiguracja webhook’a jest banalnie prosta (szczegółowy opis znajdziecie np. w tym miejscu: https://rajeevpentyala.com/2018/07/15/dynamics-365-using-webhooks-to-post-data-from-plugin-to-azure-function/ ). Natomiast rejestracja wywołania w systemie Dynamics 365 nie różni się niczym od rejestracji kroku pluginu.

 

Operacje wykonywane w określonych przedziałach czasie (time-scheduled)

Wielu z Was spotkało się na pewno z wymaganiem okresowych importów / przekształceń / „czyszczenia” (niepotrzebne skreślić 😉) danych w systemie Dynamics CRM/365, który został wdrożony jako usługa dostępna w chmurze. Pierwsze tego typu rozwiązanie stworzone z moim udziałem (w roku 2015, jeżeli mnie pamięć nie myli) oparte było o maszynę wirtualną udostępnioną w chmurze. Na wspomnianej „wirtualce” zainstalowany był serwer FTP oraz uruchamiany za pomocą harmonogramu zadań systemu Windows proces, który przekształcał i importował dane z plików udostępnianym przez serwer FTP do systemu Dynamics. Rozwiązanie to, na pozór toporne, działało jednak bardzo dobrze. Generowało jednak koszty utrzymaniowe, których dałoby się w łatwy sposób uniknąć, używając dostępnej aktualnie technologii.

 

Kolejnym krokiem ewolucji była możliwość wykorzystania Azure Web Jobs (o których pisałem już jakiś czas temu na blogu w artykule: „Konsolowa aplikacja działająca w chmurze, czyli Azure WebJobs okiem początkującego”. Zastosowanie wymienionej powyżej technologii wyeliminowało konieczność posiadania dedykowanej maszyny wirtualnej w chmurze. Zamiast tego, otrzymaliśmy możliwość uruchamiania zadań w ramach zdefiniowanego harmonogramu bezpośrednio w naszej aplikacji internetowej, która została wdrożona w chmurze. Muszę powiedzieć, że byłem dużym zwolennikiem tego rozwiązania i wykorzystywania go w projektach wdrożeń Dynamics 365 do momentu… pojawienia się Azure Functions 😊.

Tworząc proces komunikujący się z systemem Dynamics 365 z wykorzystaniem platformy Web Jobs oraz Azure Functions dostajemy do ręki praktycznie ten sam zestaw możliwości. Na czym polega więc przewaga drugiej z wymienionych powyżej technologii? Są to przede wszystkim… koszty użycia. Kod zaimplementowany jako zadanie sieciowe i uruchamiany na podstawie zdefiniowanego harmonogramu wymaga do działania usługi aplikacyjnej działającej w trybie „always-on”. Tymczasem – w przypadku użycia funkcji – płacimy de facto jedynie za zasoby wykorzystywane w momencie uruchomienia funkcji. W przypadku implementowanego przeze mnie rozwiązania (proces odczytujący plik z danymi z zasobu zewnętrznego, wykonujący konwersję odczytanych danych i zapisujący je w bazie danych Dynamics 365), przepisanie i wdrożenie kodu tak, aby uruchamiał się on jako funkcja, spowodowało spadek kosztów z ~30$ do (uwaga!) 0,3$ miesięcznie! W przypadku dużych rozwiązań – może robić to naprawdę dużą różnicę.

Drobna uwaga: tworząc nową funkcję, która będzie komunikować się z systemem CRM za pomocą OrganizationService’u – zdecydowanie polecam wybrać wersję V1 platformy Azure Function. Wersja ta wspiera „pełen” .NET Framework, w przeciwieństwie do wersji V2, która działa w oparciu o platformę .NET Core. Niestety, pomimo wielu starań, nie udało mi się zestawić komunikacji z systemem Dynamics 365 z poziomu kodu .NET Core. Próba wywołania bibliotek z .NET SDK kończyła się w moim przypadku komunikacją o brakujących zależnościach, które (pomimo tego, że były dodane do projektu i wdrożone jako część pakietu funkcji) nie były widziane przez środowisko uruchomieniowe w chmurze. Ponieważ wersja V2 platformy Azure Functions nie jest jeszcze wersją finalną, być może w przyszłości coś zmieni się w tym temacie. Być może również grupa produktowa Dynamics 365 dostarczy biblioteki w SDK, które będą oficjalnie wspierać platformę .NET Core. W tym momencie – polecam jednak development funkcji, komunikującej się z systemem CRM, za pomocą „dużej” wersji .NET Framework.

Przyszłość?

Z pewnością nie są to jedyne możliwe scenariusze wykorzystania „bezserwerowych” komponentów chmury Microsoft Azure w projektach Dynamics 365. Znana sentencja: „Sky is a limit” wydaje się w tym przypadku być jak najbardziej na miejscu. Dodatkowo niski koszt wdrożenia („pay-per-use”) sprawia, że adopcja rozwiązań opartych tę platformę może stać się w przyszłości podstawowym sposobem rozbudowy aplikacji biznesowych Microsoft. Internetowi futurolodzy przewidują już zastąpienie starego, dobrego mechanizmu rozszerzania funkcjonalności systemu za pomocą pluginów, właśnie integracją z funkcjami Azure. Czy tak się faktycznie stanie? Przekonamy się zapewne w niedalekiej przyszłości.

 

 

Total Views: 177 ,

One thought on “Integracja Dynamics 365 CE i Azure Functions

  • Super wpis Piotrek 🙂 Swoją drogą bezproblemowo możesz połączyć się z .NET Core do CRMa poprzez WebApi i Adala, David Yack ma fajny framework do tego 🙂 także SDK nie jest potrzebne do niczego 🙂

Dodaj komentarz