Praca z bibliotekami JavaScript w Dynamics CRM / Dynamics 365 Anno Domini 2016

Dynamics 365, Dynamics CRM, JavaScipt, top5

Na początku był chaos… Później pojawiły się zasoby sieciowe.

Niewiele osób pamięta wersje systemu CRM, które nie pozwalały na definiowanie zasobów sieciowych (web resources) w ramach budowanych w oparciu o omawianą platformę rozwiązań. Zaiste, były to mroczne czasy. Skrypty przechowywane były wówczas jako część dostosowań formatek CRM, co sprawiało, że o jakiejkolwiek reużywalności kodu nie było w tym przypadku mowy. Mogliśmy oczywiście przechowywać i wczytywać pliku bezpośrednio z dysku twardego serwera, niestety Microsoft postępowanie to podsumowywał jednym, wymownym słowem: „UNSUPPORTED”.

Dynamics CRM 2011 wprowadził w końcu możliwość tworzenia zasobów sieciowych przechowywanych w bazie danych i reprezentujących (między innymi) biblioteki JavaScript oraz dołączania ich do formatek obiektów w systemie. Dało to programistom możliwość zarządzania kodem JavaScript, tworzenia bibliotek, które były wykorzystywane w wielu miejscach w systemie i generalnie pracy w uporządkowany sposób. Dołączane do formularzy biblioteki wczytywały się w sposób synchroniczny w z góry zdefiniowanej kolejności. Próba zmiany tego stanu rzeczy miała miejsce w CRM 2011 Update Rollup 12, jednak problemy z istniejącym kodem oraz protesty dostawców i klientów spowodowały wycofanie się rakiem z tego pomysłu. Najczęściej spotykane podejście do pracy z zasobami sieciowymi wyglądało więc w następujący sposób: 1 biblioteka JavaScript = 1 zasób sieciowy. Biblioteki przechowywane były w ramach projektów Visual Studio i zapisywane w CRM ręcznie lub za pomocą narzędzi w rodzaju Web Resource Linkera. Podejście to było jak najbardziej słuszne do czasu pojawienia się… CRM Turbo Forms.

Niestety wymienione powyżej „Turbo-Formatki” są cały czas jedną z najmniej dopracowanych technologii w systemie Dynamics CRM / Dynamics 365. Microsoft twierdzi, że skrypty wczytywane są dla nich w sposób asynchroniczny, bez określonej kolejności, co nie jest do końca prawdą. W praktyce różne typy formatek zachowują się w różny sposób. O zgrozo, podobne rozbieżności występują niekiedy w przypadku różnych systemowych encji (formatka encji A ładuje skrypty zgodnie z ustaloną koniecznością, a encji B w sobie tylko wiadomy sposób).

Tak, czy inaczej, sposobem na uniknięcie powyższych problemów jest powrót do przechowywania całego kodu JS dla pojedynczej encji w 1 pliku (!). Historia zatoczyła koło i powrót do praktyk z początku dwudziestego pierwszego wieku w przypadku korzystania z Turbo Forms może wydawać się smutną koniecznością. Oczywiście możemy używać bibliotek w rodzaju Require.JS lub podobnych, moim skromnym zdaniem w przypadku skryptów uruchomianych z poziomu formatek CRM mija się to z celem. Nieco inaczej wygląda sytuacja w przypadku niestandardowych elementów interfejsu użytkownika, jest to natomiast temat na osobny artykuł.

Na szczęście w roku pańskim 2016 mamy już do dyspozycji darmowe narzędzia, dzięki którym development rozszerzeń CRM działających po stronie klienta nie jest nieustanną udręką. Poniżej znajdziecie krótki opis dwóch używanych przeze mnie rozszerzeń Visual Studio, które wykorzystuje w codziennej pracy i które być może okażą się przydatne również dla niektórych z Was.

Visual Studio Bundler & Minifier

Rozszerzenie do Visual Studio stworzone przez Madsa Kristensena pozwala na łączenie oraz minimalizację bibliotek JavaScript w ramach procesu buildu aplikacji. W przypadku solucji CRM daje nam to możliwość tworzenia pojedynczego zasobu sieciowego na podstawie wielu źródłowych plików JavaScript.

Na powyższym screenie widzimy zawartość prostego projektu Visual Studio zawierającego pliki account.js (odpowiedzialnego za obsługę formatki encji Account), contact.js (obsługa formatki encji Contact) oraz common.js (kod współdzielony przez obie ww. encje). Wynikiem kompilacji omawianego projektu, zawierającego dodatkowo plik bundleconfig.json, są pliki accountBundle.js (zawierający połączony kod, pochodzący z bibliotek account.js oraz common.js) oraz contactBundle.js (kod pochodzący z bibliotek contact.js oraz common.js). Zapisanie powstałych w ww. sposób bibliotek w bazie CRM i wykorzystywanie ich na formatkach systemu pozwoli nam na uniknięcie problemów związanych z asynchronicznym wczytywaniem bibliotek oraz rozwiązywaniem zależności między nimi.

Przykładowa zawartość pliku bundleconfig.json dla omawianego przypadku:

Warto również wspomnieć, że omawiane rozszerzenie wspiera również automatyczne tworzenie plików map, pozwalających na wygodne debuggowanie wynikowej biblioteki z poziomu przeglądarki.

CRM Web Resource Deployer

Jest to narzędzie pochodzące z Dynamics CRM & 365 Developer Extensions stworzonego z kolei przez Jasona Lattimera. Ww. pakiet jest w założeniu autora otwartą alternatywą dla CRM Developer Kit, dostarczanego przez Microsoft w ramach CRM SDK. Będący jednym z jego składników CRM Web Resource Deployer umożliwia nam zapisywanie bibliotek JavaScript (w naszym przypadku „bundli” powstałych w wyniku buildu aplikacji), pobierania bibliotek z istniejącej solucji CRM, a także powiązanie plików JS w Visual Studio z istniejącymi w CRM zasobami sieciowymi.

Uważajcie tylko proszę na wersję 1.3.4.0 omawianego rozszerzenia, które korzysta z bibliotek SDK w wersji 8.2 i niestety (w moim i nie tylko moim przypadku) nie działa. Z kolei wersja 1.3.3.0 (dostępna w tym miejscu), która działa doskonale, nie wspiera niestety najnowszej wersji Dynamics 365. Podejrzewam jednak, że jest to sytuacja chwilowa i stosowne łatki ukażą się lada dzień.

Podsumowując, praca z bibliotekami JavaScript dla systemu Dynamics CRM/ Dynamics 365 wygląda obecnie w moim przypadku następująco:

Total Views: 493 ,