Wykorzystanie WCF w kodzie po stronie klienta w CRM

Ten, kto wywołuje web service’y Microsoft Dynamics CRM z kodu na formatkach (kodu JScript, po stronie klienta) wie, jak ciężko to osiągnąć. I nie chodzi tu oczywiście o składnię czy technologię (AJAX i tyle), ale o specyfikę tego działania w CRM. Po pierwsze trzeba powtarzać mnóstwo kodu; po drugie – prawie nie da się tego kodu debugować; po trzecie – łatwo o pomyłkę; po czwarte – czasem można nieźle natrudzić się z uwierzytelnieniem.

Wael Hamze na swoim blogu opublikował wczoraj bardzo fajny postna temat wykorzystywania usług Windows Communiation Foundation (WCF) z poziomu JScript’u w interfejsie Microsoft Dynamics CRM. Post jest tutaj: http://waelhamze.com/blog/crm/crm-wcf-integration/. Warto rzucić okiem, bo zdefiniowanie sobie kilku często używanych usług w WCF i np. możliwość zwracania JScript’owych obiektów zamiast parsowania zwróconego XML’a za każdym razem powodują, że wykorzystanie WCF wydaje się bardzo ciekawą opcją.

Nowy Sure Step! Spring 2009 Release

Wczoraj (tak naprawdę dziś w nocy) Microsoft opublikował najnowszą wersję metodyki Microsoft Dynamics Sure Step. Tym razem mamy do czynienia z „release’m”, a nie aktualizacjami. Nowa wersja nazywa się wiosennie – Spring 2009 Release. Co nowego pojawiło się w najnowszej wersji Sure Step?

  • nowe kwestionariusze z pytaniami do Klientów przydatne na etapie sprzedaży produktów – podczas fazy Diagnostyki
  • wiele nowych szablonów dla konkretnych produktów
  • nowe mechanizmy wyszukiwania treści – wreszcie będzie można znaleźć konkretny dokument, wpisując słowa kluczowe
  • nowy widok kluczowych produktów w naszych własnych projektach
  • więcej wskazówek i szablonów w pojektach typu „Aktualizacja” (Upgrade)

 

Oczywiście nowa wersja Sure Step dostępna jest dla partnerów z Service Plan’em. Można ją ściągnąć stąd: https://mbs.microsoft.com/partnersource/communities/consulting/resources/Consulting_SureStep_Methodology.htm.

Microsoft kolejny raz potwierdza, że Dynamics Sure Step staje się oczkiem w głowie korporacji. W każdym razie zauważalne są marketingowe ruchy, które pewnie niedługo sprawią, że Sure Step będzie w każdej firmie :-D

Parametry przekazywane do kontekstu plug-in’ów

Plug-in’y w Microsoft Dynamics CRM 4.0 działają zawsze w określonym kontekście. Ten kontekst prawie zawsze obsługuje parametry wejściowe i wyjściowe (lub opcjonalne). I ten post jest właśnie o tych parametrach :) .
Bardzo często zdarza się, że z przyzwyczajenia lub po skopiowaniu kodu z SDK ;) rozpoczynamy pracę z naszym plug-in’em od napisania (wklejenia) następującej linijki:

if(context.InputParameters.Properties.Contains("Target") &&
   context.InputParameters.Properties["Target"] is DynamicEntity)

Później np. przy plug-in’ie obsługującym usuwanie dziwimy się czemu nasz kod nie działa. A nie działa dlatego, że ta spopularyzowana w SDK i na stronach linijka nie sprawdza się zawsze. Bo nie może się sprawdzać. Bardzo często kolekcja parametrów przekazywanych do plug-in’ów w kontekście wcale nie zawiera klucza „Target”, a czasem żeby było trudniej ten „Target” wcale nie jest typu DynamicEntity. A jeszcze innym razem najważniejszy dla nas parametr jest w kolekcji OutputParameters, a nie InputParamaters :) . Od czego to zależy?

Oczywiście zależy od typu żądania (Request) przekazywanego do warstwy platformy. I tak np. CreateRequest przekazuje Target, ale AssignRequest przekazuje Target i Assignee. A dziesiątki innych requestów przekazuje jeszcze inne parametry. Żeby trochę ułatwić życie piszącym plug-in’y zebrałem najbardziej popularne wiadomości (messages) i wypisałem jakie parametry przekazują one plug-in’om. Poniższa tabela nie zawiera wszystkich żądań (Requests), ale te najbardziej popularne, których zapamiętanie nie raz ułatwi Wam życie…

Wiadomość (message) Nazwa parametru Typ parametru Kolekcja
Create id Guid OutputParameters
Update Target DynamicEntity InputParameters
Delete Target Moniker InputParameters
Retrieve ColumnSet ColumnSetBase InputParameters
Retrieve Target Moniker InputParameters
Retrieve BusinessEntity DynamicEntity OutputParameters
RetrieveMultiple Query QueryExpression InputParameters
RetrieveMultiple ReturnDynamicEntities Boolean InputParameters
RetrieveMultiple BusinessEntityCollection BusinessEntityCollection OutputParameters
Assign Assignee SecurityPrincipal InputParameters
Assign Target Moniker InputParameters

 

Wobec powyższego, wcześniej wspomniana popularna linijka dla operacji Delete wygląda tak:

if(context.InputParameters.Properties.Contains("Target") &&
   context.InputParameters.Properties["Target"] is Moniker)    // Moniker, a nie DynamicEntity!

Miłego programowania!