Epitafium dla odchodzących technologii

Kilka dni temu Microsoft ogłosił pojawienie się nowego SDK dla systemu Common Data Service / Dynamics 365 Customer Engagement. Zostało zbudowane w oparciu o platformę .NET Core. Wspomniany pakiet jest w tym momencie przeznaczony do tworzenia aplikacji klienckich, które korzystają z platformy CDS za pomocą usługi Web-API. Niby nie jest to jakiś ogromny przełom, a aplikacje zbudowane w .NET Core i wykorzystujące Common Data Service jako źródło danych powstawały już od dawna. Wydarzenie to wpędziło mnie jednak w mocno refleksyjny nastrój i skłoniło do przemyśleń na temat przemijania… technologii informatycznych :P.

Zakładam, że fakt pojawienia się bibliotek CDS SDK dla .NET Core zapoczątkuje proces stopniowego odchodzenia od developmentu aplikacji wykorzystujących CDS za pomocą starego, dobrego .NET Frameworka. Zapewne jedynie kwestią czasu będzie umożliwienie tworzenia rozszerzeń systemu (plugins) również w oparciu o nową, szybszą i co ważniejsze stale rozwijaną platformę .NET Core. Docelowo, cały Common Data Service oraz wszystkie zbudowane na jego bazie aplikacje zostaną zmigrowane na tą platformę. Co oznacza to dla nas – ludzi, którzy na programowaniu systemu Dynamics CRM, Dynamics 365 Customer Engagement i w końcu Common Data Service zjedli zęby? Na pewno – ostateczne pożegnanie z dwoma komponentami systemu, które towarzyszą nam od dawna, a w związku z tym, że technologie, w których zostały zbudowane, nie staną się nigdy częścią frameworka .NET Core, odejdą prawdopodobnie w zapomnienie.

Organization Service

Jest to usługa sieciowa, która powstała w czasach, kiedy na topie były technologie takie jak SOAP, SOA, czy w końcu WCF, a o architekturze mikro-serwisów mało kto słyszał. Przez wiele lat była ona podstawą standardowego API umożliwiającego dostęp i operacje na danych w systemie. Większość osób tworzących aplikację oparte o „CRM-a” mówiąc o API systemu miały na myśli właśnie Organization Service.

Niestety protokół SOAP, jak i cały WCF (który, pomimo dużo większych możliwości, przez lata stał się synonimem frameworka do budowy usług sieciowych, które wykorzystującą wspomniany wyżej, oparty na XML-u protokół) powoli odchodzą na zasłużoną emeryturę i (przynajmniej w świecie technologii Microsoftu) zostaną zastąpione przez dużo bardziej nowoczesne rozwiązanie Web-API.

Sytuacja ta ma swoje dobre i złe strony. Dzięki zastosowaniu architektury REST oraz opartej na niej usłudze sieciowej Web-API mogliśmy zapomnieć o żmudnym „klejeniu” wiadomości SOAP z poziomu kodu JavaScript. Kto tego nigdy nie robił, nie zna życia 😊… Z drugiej jednak strony z poziomu „klasycznego” Visual Studio dużo wygodniej korzystało się z wygenerowanych klas proxy (stanowiących lokalną abstrakcję usługi WCF) niż z siermiężnego obiektu HttpClient. Teoretycznie, dzięki SDK dostarczanego przez Microsoft, mogliśmy się tym nie przejmować. Z drugiej jednak strony, cały czas zdarza mi się trafiać na klientów, którzy żądają udostępniania „końcówek” systemu właśnie przez protokół SOAP. Dlaczego? Odpowiedź: „Bo znamy, umiemy i lubimy tę technologię”.

Silnik Workflow

Podobnie jak w przypadku omawianej wcześniej usługi silnik workflow systemu Dynamics CRM/365 powstał w oparciu o technologię, która najprawdopodobniej nigdy nie stanie się częścią frameworka .NET Core. Mowa oczywiście o WF (Windows Workflow Foundation, jedno „W” ze skrótowca zniknęło, w wyniku interwencji organizacji z pandą w logo). W tym przypadku następcą silnika procesów ma być plafroma Power Automate (znana również niegdyś pod nazwą Microsoft Flow). Niestety do tej decyzji architektonicznej podchodzę nad wyraz sceptycznie. Po pierwsze – brak jest w tym przypadku natywnej integracji z platformą aplikacjami Dynamics 365. Power Automate to osobna usługa, która może działać niezależnie od platformy Common Data Service. Co prawda – poczyniono w tym temacie ostatnio pewne postępy, takie jak: możliwość przenoszenia procesów w ramach solucji oraz nowy connector zinegrowany z bieżącą organizacją (tzw. „current environment”), ale do idealnej sytuacji droga jeszcze daleka. Dodatkowo, w przypadku silnika workflow, korzystanie z niego do automatyzacji było zupełnie darmowe i nie generowało ryzyka dodatkowych kosztów dla klienta. Tymczasem radosna, bezrefleksyjna twórczość w Power Automate lub też oparcie logiki biznesowej systemu na tej platformie w przypadku naprawdę dużych wdrożeń – może stać się utrapieniem oraz dodatkowym kosztem dla właściciela systemu. Wszystkim sceptykom twierdzącym, że domyślne, udostępnione w ramach „standardowych” licencji liczby uruchomień procesów są na tyle duże, że ciężko jest je przekroczyć, odpowiadam – wcale nie jest to takie trudne i widziałem taką sytuację u jednego z klientów na własne oczy. I wcale nie był to żaden ogromy „enterprise”.

Nie chciałbym być źle zrozumiany. Power Automate to świetny produkt, ale służący do integracji między różnymi systemami. Budowanie w oparciu o niego wewnętrznych przepływów danych i logiki biznesowej jest po prostu niewygodne, w tym momencie mocno upierdliwe i może być dodatkowo związane z ryzykiem ponoszenia dodatkowych kosztów przez klienta. 

Nasuwa się również pytanie – co z całą resztą mechanizmów, które wyewoluowały z podstawowego silnika procesów? Wiadomo już, że okna dialogowe znikają z systemu. Procesy biznesowe (business process flows) z kolei zostaną i będą coraz bardziej zintegrowane z plaformą Power Automate. Co z niestandardowymi akcjami (requestami) oraz worflowem synchronicznym? Chyba nawet Microsoft tego obecnie nie wie (albo przynajmniej nie chce powiedzieć).

Żegnajcie stare technologie! Niedługo tylko stare dziady* oraz archeolodzy IT **będą o Was pamiętać.

Odpoczywajcie w spokoju…

* Do których zalicza się np. autor tego bloga

** Nowa specjalizacja na studiach oraz zawód, których powstanie przewiduje w ciągu kilku najbliższych lat.

Total Views: 838 ,
This Article Has 1 Comment
  1. Moja strona

    Ciekawy wpis. Dobrego dnia!

Comments are now closed.