Wykorzystywanie zewnętrznych bibliotek w rozszerzeniach systemu Dynamics CRM

.NET, CRM SDK, Dynamics CRM

Każdy developer systemu Dynamics CRM rozszerzający jego funkcjonalność za pomocą bibliotek .NET (pluginy, workflow activities, itp.) prędzej czy później będzie zmuszony do skorzystania w swoim rozwiązaniu jakiegoś zewnętrznego komponentu. Obecnie w Internecie możemy znaleźć setki darmowych lub komercyjnych bibliotek programistycznych, których możemy używać w naszych projektach (hail to Nuget!). Wykorzystanie zewnętrznej biblioteki w kodzie uruchamianym przez system CRM jak najbardziej możliwe. Musimy jedynie rozważnie zaplanować, w jaki sposób zintegrujemy zewnętrzny plik z naszą aplikacją. Sposobów jest oczywiście kilka. Jak zapewne się domyślacie wybór każdego z nich niesie ze sobą pewne konsekwencje i wpływa chociażby na procedurę instalacji lub na docelowe koszty używania systemu (w przypadku aplikacji hostowanych w chmurze). Ponadto niektóre metody mają wpływ na funkcjonalności udostępniane przez system, np. na to czy aplikacja działa bez dostępu do Internetu.

Poniżej znajdziecie przygotowane przeze mnie opisy najpopularniejszych metod używania zewnętrznych bibliotek w kodzie rozszerzającym funkcjonalność CRM oraz informacje o plusach oraz minusach poszczególnych wzorców.

Dołączenie referencji w projekcie Visual Studio.  

Jest to najprostsza z pośród dostępnych opcji. W Visual Studio wybieramy opcję „Add Reference” i od razu możemy korzystać z funkcjonalności zewnętrznego komponentu. Instalacja biblioteki na serwerze polega w tym przypadku na umieszczeniu jej w Global Assembly Cache systemu operacyjnego lub w folderze „Assembly” aplikacji CRM. W przypadku instalacji CRM składającej się z więcej niż 1 serwera musimy pamiętać o tym, aby zainstalować omawianą bibliotekę na wszystkich maszynach, które wchodzą w skład farmy.

Plusy:

  • Łatwość budowy rozwiązania.

Minusy:

  • Rozszerzenia CRM korzystające z zewnętrznych plików DLL muszą być zarejestrowane na dysku, co generalnie jest rozwiązaniem nierekomendowanym przez MS.
  • Implementowana funkcjonalność nie będzie działać wewnątrz klienta CRM for Outlook w trybie off-line, który jest w stanie skorzystać jedynie z bibliotek zarejestrowanych w bazie danych.
  • Brak możliwości skorzystania z solucji systemu CRM w procesie instalacji dostosowań.
  • Konieczność każdorazowego restartu aplikacji (serwer WWW, usługi asynchroniczne) w przypadku instalacji nowej wersji rozwiązania.
  • Brak możliwości instalacji budowanego rozwiązania w środowisku CRM OnLine

Korzystanie z mechanizmów łączenia („merge’owania”) bibliotek

Za pomocą rozwiązań takich jak Microsoft ILMerge lub Fody/Costura jesteśmy w stanie połączyć kilka plików w pojedynczą, zawierającą wszystkie wymagane klasy bibliotekę .NET. Stworzenie finalnego pliku polega w tym przypadku na uruchomieniu stosownego narzędzia z linii poleceń (ilmerge.exe) lub zainstalowania pakietu Nuget i stworzenie stosownego pliku konfiguracyjnego, który będzie wykorzystywany w procesie buildu aplikacji. W tym przypadku musimy pamiętać o tym, że wszystkie łączone biblioteki muszą być podpisane kluczem i posiadać tzw. „silną nazwę” (ang. strong name). W innym przypadku nie będziemy w stanie zarejestrować wynikowego pliku w bazie CRM.

Przykładowe połączenie i podpisanie kluczem bibliotek Foo.Crm.Plugins.ILMerged.dll i Foo.Crm.External.dll za pomocą ILMerge:

ILMerge.exe Foo.Crm.Plugins.ILMerged.dll Foo.Crm.External.dll /out:MyMergedLibrary.dll /target:dll /keyfile:Foo.Key.snk

Przykładowa konfiguracja pliku FodyWeavers.xml (plik konfiguracyjny Fody/Costura):

Plusy:

  • Łatwość budowy rozwiązania.
  • Łatwość instalacji i wdrożenia (możliwość dodania wszystkich wymaganych komponentów do solucji CRM).
  • Możliwość instalacji bibliotek rozszerzeń w bazie danych.
  • Możliwość wykorzystania zarejestrowanych bibliotek w kliencie Outlook w trybie off-line.

Minusy:

  • Brak podziału aplikacji na logiczne komponenty. Brak jasnego rozdzielenia odpowiedzialności między poszczególnymi komponentami tworzącymi rozwiązanie.
  • Ewentualna aktualizacja zewnętrznej biblioteki powoduje konieczność utworzenia nowego buildu aplikacji i wdrożenia go na środowisko produkcyjne.
  • W przypadku rozwiązania zbudowanego w oparciu o Fody/Costura merge’owana biblioteka nie działa w trybie Sandbox. W związku z tym, nie mamy możliwości przeniesienia naszej aplikacji do chmury. W przypadku ILMerge’a powyższy problem nie występuje.
  • Brak możliwości wykorzystania Plugin Profilera do debuggowania produkcyjnej instancji aplikacji

Udostępnienie funkcjonalności z biblioteki zewnętrznej za pomocą usługi sieciowej

Jest to scenariusz, który preferuje i polecam wszystkim w czasie projektów. Polega on na stworzeniu usługi sieciowej, która wykorzystuje zewnętrzną bibliotekę i umożliwia nam skorzystanie z jej funkcjonalności. Rozszerzenia CRM komunikują się w tym przypadku z usługą sieciową i w praktyce nie korzystają w bezpośredni sposób z zewnętrznego komponentu.

CRMWe bServices

Plusy:

  • Podział aplikacji na logiczne i fizyczne komponenty funkcjonalne.
  • W przypadku aktualizacji wersji – konieczność aktualizacji jedynie pojedynczego komponentu tworzącego rozwiązanie.
  • Możliwość pracy w środowiskach on-premise i CRM OnLine. Możliwość uruchomienia tworzonego kodu w trybie Sandbox.
  • Dowolny sposób instalacji tworzonych rozszerzeń CRM (dysk, GAC, baza danych).
  • Możliwość skorzystania z niepodpisanych bibliotek oraz komponentów z poza ekosystemu Microsoft .NET (Java, PHP i inne).

Minusy:

  • Potencjalnie większa pracochłonność wynikająca z konieczności stworzenia, wdrożenia oraz zabezpieczenia komponentów zewnętrznych wobec CRM.
  • Konieczność stworzenia oraz uruchomienie dodatkowej usługi sieciowej obok systemu CRM. W przypadku trybu off-line dodatkowo konieczność hostowania jej na stacji roboczej użytkownika systemu (np. za pomocą zainstalowanego lokalnie serwera WWW).
  • W przypadku CRM OnLine – potencjalnie dodatkowe koszty wynikające z konieczności wykupienia miejsca do hostingu naszego web service’u.

Tak jak wspomniałem powyżej – pomimo potencjalnie największej pracochłonności zdecydowanie polecam wszystkim korzystanie z metody numer 3. Z punktu widzenia architektury rozwiązania jest ona najbardziej elastyczna.  Zapewnia proste możliwości rozbudowy i aktualizacji w porównaniu z innymi podejściami. Ponadto pozwala ominąć wiele „ograniczeń”, które nakłada na nas jako developerów platforma CRM. Natomiast nieco dłuższy czas developmentu oraz wdrożenia rozwiązania zostanie w tym przypadku szybko zrekompensowany przez zdecydowanie niższy koszt rozbudowy funkcjonalnej, implementacji zmian oraz aktualizacji naszego systemu.

Total Views: 631 ,

2 comments

  • Dla mnie jedynym rozwiązaniem jest opcja numer 3.
    Wtyczki, czy przepływy pracy są stworzone w konkretnym celu i mają konkretne ograniczenia.
    Nakład pracy włożony w „zmuszenie” wtyczki do zrobienia czegoś, do czego nie jest stworzona, będzie porównywalny do napisania prostego serwisu, a korzyści brak. Trudno bowiem zrozumieć jak ktokolwiek może stawiać szybkość dostarczenia rozwiązania ponad jakością i możliwością rozwoju. Cała platforma Dynamics CRM skonstruowana wokół sprawnego i łatwego mechanizmu rozszerzania i dostosowywania. Tworzenie rozwiązań „szybkich w implementacji” w większości przypadków okazuje się nieprzemyślane w dłuższym horyzoncie czasowym i wymagającym większego, często niezrozumiałego dla klienta nakładu pracy przy rozszerzaniu.

  • Ad. punktu 2 – jest jeszcze https://github.com/gluck/il-repack z którego osobiście korzystam. ILMerge powodował u mnie dziwne błędy w zmergowanej dllce, plus ilrepack działa znacznie szybciej.

    Obecnie w moim projekcie korzystam z podejścia 2 łączonego z podejściem nr. 3 – system jest wewnętrzny i onpremise, więc wady rozwiązań nr. 2 aż tak bardzo mnie nie dotykają. Niemniej dzięki za temat do przemyśleń i poprawy na przyszłość 🙂

    ps. Wasza prezentacja w Warszawie mocno mi się przydała przy wdrażaniu wersji mobilnej! Dzięki!

Comments are closed.