Dynamics CRM Turbo Forms – fakty, mity i błędy

CRM SDK, Dynamics CRM

Jakiś czas temu (jeżeli mnie pamięć nie myli w wersji 2015 Update 1) Microsoft wprowadził w swoim systemie CRM zupełnie nowy silnik renderujący interfejs użytkownika w przeglądarce internetowej. W założeniu miał być to zupełnie nowy, rewolucyjny mechanizm, który znacznie przyśpieszy ładowanie formatek CRM poprzez zrównoleglenie ładowania skryptów oraz wykorzystanie zupełnie nowego, lżejszego szablonu HTML do generowania formatek w systemie. Jednocześnie w sieci (w tym również na stronach MSDN) pojawiły się informacja, że od tej pory przed uruchomieniem jakiegokolwiek skryptu na stronie powinniśmy zapewnić dostępność wszystkich skryptów zależnych, wykorzystując do tego np. znaną bibliotekę Require.Js.

Powyższe informacje jak zwykle ostatnio w przypadku naszego ulubionego systemu (sorry, MS) okazały się nie do końca prawdziwe.

Po pierwsze, CRM faktycznie wykorzystuje nowy szablon HTML/CSS do generowanie formularzy. Jeżeli więc pisaliście kod z wykorzystaniem ukochanej przez wszystkich funkcji JavaScript getDocumentById() istnieje duże prawdopodobieństwo, że Wasze skrypty po przejściu na nowy silnik przestaną działać.

Po drugie, pojawia się kwestia dostępności skryptów. Aktualnie faktycznie ładują się one w sposób równoległy, ale… żaden kod nie zostaje uruchomiony do czasu, aż zostaną ściągnięte z serwera wszystkie zasoby sieciowe podpięte pod formularz CRM. Dopóki wszystkie skrypty nie zostaną załadowane – dopóty CRM będzie wyświetlał komunikat pt. „Trwa ładowanie logiki biznesowej” i żadne elementy formularza nie zostaną wyświetlone użytkownikowi (nie dojdzie również do zdarzenia OnLoad). Jeżeli więc przypinamy skrypty do formularzy „po bożemu” (czyli tylko pod wspierane i opisane w SDK metody), to nie ma możliwości żeby coś się nam wywaliło. Biblioteka Require.Js jest więc w takim przypadku zupełnie zbędna. Nieco inaczej wygląda kwestia w przypadku niestandardowych elementów, np. aplikacji webowych zagnieżdżonych w CRM za pomocą IFrame’ów. Jest to jednak temat na oddzielny artykuł.

TurboForms

Po trzecie, w Turbo Forms pojawiło się kilka błędów o których trąbią już w internetach. Chyba najmniej przyjemnym z nich jest wystąpienie i uruchamianie skryptu na zdarzeniach OnChange dla pól typu Lookup lub Customer w momencie, w którym zmiany wartości następują w wyniku działania kodu JavaScript.  Przykładowo, jeżeli mamy 2 pola na formatce, z których pierwsze jest odpowiedzialne za zmianę wartości drugiego (za pomocą skryptu podpiętego pod zdarzenie OnChange) i na odwrót to… efektem działania będzie nieskończona pętla i niestety w najgorszym przypadku zupełny crash przeglądarki internetowej.

TurboForms2

Zachowanie opisane powyżej możemy łatwo zaobserwować uruchamiając na formularzu następujący fragment kodu, który:

  1. Dla każdego z atrybutów na formularzu podpina metodę wyświetlającą nazwę atrybutu w momencie zmiany wartości tego pola.
  2. Ustawia domyślne wartości pól.

Jak się na pewno domyślacie efektem działania poniższego kodu będzie wyświetlenie „alertów” dla atrybutów o nazwach „new_accountid” oraz „new_customer”.

Identyczna sytuacja występuje w momencie wywołania metody clearOptions na polu typu OptionSet.

Wróble ćwierkają, że aktualna wersja systemu CRM ma być ostatnią, wspierającą tzw. „legacy mode” do generowania formularzy systemu. Wygląda na to, że nie uciekniemy od Turbo-Forms i będziemy musieli się z nimi zaprzyjaźnić. Moje doświadczenia w tym obszarze wyglądają niestety tak, że jeżeli ktoś ma jakiekolwiek problemy z nowym silnikiem generowania formularzy, to pierwszą czynnością której dokonuje jest … przejście na „legacy mode”. Bądźcie jednak czujni (zwłaszcza osoby pracujące z wersją Online systemu), bo nie znacie dnia ani godziny. Głupio byłoby obudzić się z ręką w nocniku i być zmuszonym do wprowadzania poprawek w skryptach „na szybko”, kiedy po którejś (oczywiście niespodziewanej ;)) aktualizacji stary silnik w magiczny sposób zniknie z systemu CRM.

Total Views: 641 ,