W systemie pływa, akcja się nazywa…

Dynamics 365, Dynamics CRM, Web API

Niestandardowe przepływy pracy typu „Akcja” są bardzo przydatnym elementem, który umożliwia „opakowywanie” zbioru operacji wykonywanych na danych w systemie Dynamics 365. Utworzoną akcję możemy później w łatwy sposób wykonać z poziomu kodu C# oraz (przede wszystkim) JavaScript. Uwalnia nas to z obowiązku implementowania tego typu mechanizmów samodzielnie (kto pamięta wzorzec CRM Command stosowany w czasach wersji 2011?) lub pracochłonnego rzeźbienia poszczególnych funkcjonalności po stronie klienta (wszyscy kochamy język JavaScript, hell yeah!). Samą akcję możemy po prostu „wyklikać” z poziomu interfejsu użytkownika (tzw. wersja „business-friendly”) lub zaimplementować za pomocą kodu na platformie .NET.

Wszystko to wygląda w teorii pięknie. W praktyce należy jednak uważać na kilka kwestii. Według dokumentacji uruchomienie własnej akcji z poziomu języka JavaScript za pomocą Dynamics 365 WebAPI (REST-owy endpoint umożliwiający operacje na danych w systemie Dynamics 365) powinno być dość proste i sprowadzić się do wysłania komunikatu HTTP na określony adres. Przykładowo:

http://AdresSerweraDynamics365/AdresOrganizacji/api/data/v8.2/Accounts(‚c212b3c4-b2b7-49c3-a014-df70be3c8e11’)/Microsoft.Dynamics.CRM.foo_myaction

Wysłanie komunikatu POST pod powyższy adres uruchomi akcję o nazwie „foo_myaction” powiązaną z obiektem typu Account o identyfikatorze: c212b3c4-b2b7-49c3-a014-df70be3c8e11.

Pytanie tylko jakiej nazwy akcji powinniśmy użyć?

Po pierwsze, należy pamiętać o dodaniu do nazwy akcji przedrostka: Microsoft.Dynamics.CRM.*. Po drugie – musimy zidentyfikować pod jaką nazwą utworzona przez nas akcja została zapisana w metadanych Dynamics 365 WEB API. Prosty, programistyczny umysł podpowiada, że sensownym rozwiązaniem byłoby użycie unikalnej nazwy foo_myaction. Niestety programiści z Redmont zdecydowali, że do generowania metadanych dla Web API wykorzystają modyfikowalną nazwę procesu, która w praktyce zawiera przyjazny biznesowo opis wykonywanych operacji, np. „Create acceptance task for new sales process”. „Techniczna” nazwa, którą powinniśmy wykorzystywać w kodzie JS wyglądać będzie w tym przypadku następująco: foo_Createacceptancetaskfornewsalesprocess) . Jest to według mnie bezsensowna decyzja, która dodatkowo wprowadza niespójności w budowanym rozwiązaniu, zwłasza, że generowany automatycznie kod klas w C# używa unikalnych nazw.

Żeby było weselej, WebAPI nie poinformuje nas o tym, że nazwa uruchamianej przeze nas akcji jest nieprawidłowa. Zamiast stosownej informacji w odpowiedzi otrzymamy (z zależności od humoru serwera?) informacje o nieprawidłowych parametrach wywołania akcji (WTF?), niepoprawnym adresie URL (to już bardziej przydatna informacja) lub wewnętrznym błędzie  serwera.

Kolejnym problemem w tym obszarze jest fakt, że nazwa zapisywana jest w metadanych jednorazowo, w momencie tworzenia danej akcji. Jeżeli przy jej wpisywaniu zrobimy literówkę w rodzaju „Do Somehting” nasz niestandardowy request już zawsze będzie nazywać się foo_dosomehting. Jedynym sposobem na „wyprostowanie” tej sytuacji jest usuniecie akcji i dodanie jej ponownie z prawidłową nazwą. Hasztag: #DziekiMicrosofcieZaUłatwianieŻycia

Na koniec krótkie przypomnienie o tym, gdzie możemy znaleźć informacje o metadanych, które są wykorzystywane przez Web API. Wystarczy w tym celu wpisać w oknie przeglądarki następujący adres:

http://AdresSerweraDynamics365/NazwaOrganizacji/api/data/v8.2/$metadata

Chcąc odnaleźć rzeczywistą nazwę utworzonego przez nas przepływu przeszukujemy zwrócony plik XML pod kątem ciągów znaków podobnych do poniższego:

<Action Name=”foo_myaction” IsBound=”true”>
<Parameter Name=”entity” Type=”mscrm.account” Nullable=”false”/>
</Action>

Total Views: 280 ,

One thought on “W systemie pływa, akcja się nazywa…

  • Cieszę się, że natrafiłam na ten tekst. Poszerzył on moją wiedzę i wydaje mi się, że zainteresuję się tym tematem jeszcze bardziej.

Comments are closed.