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…

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!

Impersonacja plug-in’ów w Dynamics CRM

Konieczność impersonacji (użycia poświadczeń innego uprawnionego użytkownika) w kodzie plug-in’ów jest dość powszechna. Często bowiem zdarza się, że kod uruchamiany wewnątrz plug-in’u powinien być uruchamiany za pomocą konkretnego konta (np. dlatego, że konto to ma dostęp do zewnętrznego systemu).

Sytuacja domyślna:

Należałoby zacząć od kontekstu w jakim uruchamiane są plug-in’y. Otóż, plug-in’y zawsze domyślnie uruchamiają się w kontekście konta, na którym działa pula aplikacji serwera CRM. To znaczy, że w większości wypadków kod będzie działał wykorzystując konto “NETWORK SERVICE”, które w Dynamics CRM reprezentowane jest jako użytkownik “SYSTEM”.

Impersonacja innego użytkownika:

Aby użyć poświadczeń innego użytkownika, możemy zmienić konto, na którym zadziałają plug-in’y. Możemy to zrobić podczas rejestracji plug-in’u. Operacja polega na wybraniu w narzędziu do rejestracji plug-in’ów konta, które ma być użyte do wykonania kodu albo ustawienie tego konta jako wartości pola impersonatinguserid:

Aby użyć wybranego podczas rejestracji konta w plug-in’ie musimy utworzyć proxy usługi sieciowej, wykorzystując metodę obiektu context:

 ICrmService naszWebService = (ICrmService)context.CreateCrmService(true);

Jeśli zostawimy puste pole impersonatinguserid i wywołamy powyższą metodę, użyjemy poświadczeń aktualnie zalogowanego użytkownika, a więc tego, którego działanie wywołało plug-in. Jeśli w czasie działania (runtime plug-in impersonation) chcielibyśmy zmienić poświadczenia z wybranego podczas rejestracji konta na użytkownika, który uruchomił plug-in, możemy utworzyć web service z następującym parametrem:

ICrmService naszWebService = (ICrmService)context.CreateCrmService(context.InitiatingUserId);

Nowe SDK 4.0.6 już dostępne

29 sierpnia pojawiła się nowa wersja SDK dla Dynamics CRM. Najnowsza wersja oznaczona jest numerkiem 4.0.6 i zawiera wiele zmian. Poprawione są m.in. błędy związane z użyciem DynamicEntity i referencji, o których pisałem tu: http://www.crmblog.pl/2008/08/bdy-w-sdk-405.html, a o których informowałem osoby z zespołu redagującego SDK dużo wcześniej .

Dodatkowe zmiany to pojawienie się ciekawej sekcji o pisaniu własnych rozszerzeń E-mail Router’a, lepszy opis funkcji globalnych dostępnych w JScript i opis jak dodawać Web References w Visual Studio 2008 .

SDK jest dostępne tutaj: http://www.microsoft.com/downloads/details.aspx?FamilyID=82E632A7-FAF9-41E0-8EC1-A2662AAE9DFB&displaylang=en

Błędy w SDK 4.0.5

Aktualna wersja SDK dla Dynamics CRM to 4.0.5 z 30 maja 2008. Jest to wersja poprawiona, ale jak się okazuje – zawiera jeszcze sporo błędów . Mam na myśli błędy, które denerwują szczególnie, czyli fragmenty kodu, które rzekomo mają działać i dostarczają jakąś funkcjonalność, a najzwyczajniej w świecie nie działają…

Najwięcej błędów znajduje się we fragmentach kodu związanych jest z częścią systemu, która uległa zmianiom w wersji 4.0. W szczególności chodzi o obsługę DynamicEntity i różnych sposobów budowania kwerend do wywołania poszczególnych metod web service’u CrmService.asmx (np. ColumnSet, FilterExpression).

Jednym z przykładów błędnego kodu w SDK jest próba odwoływania się do właściwości obiektu klasy DynamicEntity poprzez Properties. W SDK mamy:

DynamicEntity entity = (DynamicEntity)retrieved.BusinessEntity;
string fullname;

for (int i = 0; i < entity.Properties.Length; i++)
{
if (entity.Properties[i].Name.ToLower() == “fullname”)
}

Ten kod w CRM 4.0 po prostu nie zadziała! Wynika to z faktu, że właściwość Properties jest teraz obiektem typu PropertyBag, więc np. nie ma właściwości Length, a Count. Dodatkowo nie można oczywiście odwoływać się do poszczególnych wartości w tej kolekcji poprzez indeksy liczbowe w pętli. Aby pobrać konkretne pole z encji, powinniśmy napisać:

if (entity.Properties.Contains(“fullname”))
{
fullName = entity.Properties["fullname"]; // a nie Properties[int i] !!!
}

Kolejne błędy znajdują się we fragmentach kodu opisujących np. dodawanie kolumn do zapytania, które chcemy wysłać web service’owi. SDK pokazuje w jednym z przykładów:

// Create a column set that holds the names of the columns to be retrieved
ColumnSet colsOrganization = new ColumnSet();
colsOrganization.Attributes = new string [] {“fullname”};

i znowu! Ten kod działał w CRM 3.0, ale nie zadziała w 4.0, jeśli użyjemy tak jak powinniśmy referencji do Microsoft.Crm.Sdk.dll Chyba, że “namieszamy” sobie w kodzie i dodamy “web reference” do web service’u oprócz referencji do wspomnianej DLL (czyniąc kod zupełnie nie-generycznym). Nie zadziała z tej prostej przyczyny, że w CRM 4.0 właściwość Attributes jest tylko do odczytu i zwraca listę ArrayList.
Prawidłowy kod dla CRM 4.0 to:

ColumnSet colsOrganization = new ColumnSet();
colsOrganization.AddColumn(“fullname”);


Niestety takich “nieścisłości” w SDK jest całkiem sporo… Jedyny sposób sprawdzenia, czy fragmenty kodu działają to ich uruchomienie. Nawet doświadczenie z wcześniejszymi wersjami CRM tu nie pomagają, a nawet chyba trochę szkodzą .