Rozwiązania (Solutions) i Poprawki (Patches) – wszystko, co musisz wiedzieć o wersjonowaniu w Dynamics 365

Przy okazji rozdzielenia platformy od aplikacji (opisanej w poprzednim poście) wypada się pochylić bardziej nad tym, jak przygotowywać nowe Rozwiązania (Solutions) w trakcie wdrożenia Dynamics 365 (i po nim). Skoro od teraz każdy moduł funkcjonalny będzie w osobnym Rozwiązaniu, to i my, partnerzy wdrażający, powinniśmy trochę bardziej serio zacząć traktować solucje i poprawki. Wiadomo, że w realnym życiu nikt poza ISV nie używa Rozwiązań Zarządzanych ;), ale wypada zacząć używać Rozwiązań i Poprawek w celu lepszego panowania nad cyklem życia naszych dostosowań w CRM’ie (Dynamics 365 for Customer Engagement, taaaa).

* standardowo, będę używał słów „rozwiązania” i „solucje” zamiennie, mimo że „solucja” to wg Słownika Języka Polskiego i CD Action coś zupełnie innego 🙂

 

Wersjonowanie Rozwiązań vs wersjonowanie Poprawek

Jak wiadomo, każde rozwiązanie przygotowywane przez nas podczas wdrażania Dynamics 365 ma numer wersji. Pierwszy numer podczas tworzenia Rozwiązania nadajemy my sami, więc wydaje się, że możemy wybrać dowolną nazwę. A jednak nie! Odkąd Microsoft wprowadził do CRM 2016 i Dynamics 365 „Aktywa” (Assets), czyli poszczególne, bardzo małe komponenty konkretnych encji, to numerowanie Rozwiązań jest wymuszane przez platformę do określonego formatu X.Y.Z.W, gdzie:

  • X – numer głównej wersji Rozwiązania (major)
  • Y – numer aktualizacji Rozwiązania (minor)
  • Z – numer Poprawki (build)
  • W – numer rewizji Poprawki (revision)

Dlatego też próba wpisania takiego numerku wersji:

dynamics365-solution-number

…spowoduje z automatu poprawienie przez system numeru wersji na taki:

dynamics365-solution-number02

 

Każda Poprawka (Patch) do naszego Rozwiązania będzie miała później automatycznie nadawany numer będący inkrementacją trzeciego numerka (Z w numerze X.Y.Z.W).

 

Poprawki (Patches) w Dynamics 365 – co to takiego?

Poprawki (albo „patche”), jak sama nazwa wskazuje, służą do wgrywania poprawek do istniejących rozwiązań. Poprawki to nic innego jak zestaw konkretnych Aktywów dodanych do istniejącego Rozwiązania. Na przykład:

chcemy szybko zmienić konkretny widok, albo dodać nowy wykres, albo zmienić pola na formatce w docelowym środowisku – wtedy nie tworzymy nowego rozwiązania zawierającego tylko widok, wykres i formularz, ale tworzymy patch do istniejącego rozwiązania, który zawiera tylko te elementy, które chcemy zmienić.

Patche mogą być aplikowane zarówno do Rozwiązań Zarządzanych, jak i Niezarządzanych (ufff!), a więc szybko powinny się stać obowiązkowym i ulubionym elementem każdego dobrego wdrożenia Dynamics 365. Patch zawsze powstaje poprzez utworzenie go (sklonowanie) z istniejącego rozwiązania – nie można stworzyć patch’a ot tak bez istniejącego Rozwiązania. Każdy patch jest stworzony dla konkretnego Rozwiązania i nie może być używany poza kontekstem tego Rozwiązania. Oczywiście, co za tym idzie, nie można wgrać Poprawki na środowisko, w którym nie ma oryginalnego Rozwiązania, którego ta Poprawka dotyczy!

Dodatkowo, podczas próby importu Poprawki, CRM (tfu, Dynamics 365) zawsze sprawdzi, czy numer głównej wersji Rozwiązania (X) i numer aktualizacji Rozwiązania (Y) w Poprawce są takie same, jak numery Rozwiązania istniejącego już na środowisku docelowym. Nie da się więc patch’em zaktualizować numeru wersji, czy aktualizacji. Patch to patch. Zawsze trzeci numerek w numerze wersji.

 

Poprawka, a aktualizacje Rozwiązania (minor version)

Jak łatwo się domyślić, w prawdziwych wdrożeniach będziemy mieli wiele patch’y do istniejących rozwiązań. Dlatego Microsoft przemyślał sprawę i pozwala na tworzenie Aktualizacji Rozwiązania (numerek Y w X.Y.Z.W), które automatycznie uwzględniają wszystkie dotychczasowe Poprawki! Nie ma więc potrzeby pamiętania o wszystkich Poprawkach dodawanych do rozwiązania, bo każda nowa wersja Rozwiązania będzie zawierać wszystkie zmiany, które dodaliśmy wcześniej patch’ami.

 

Jak to zadziała w realnym życiu, przy wielu zainstalowanych rozwiązaniach?

Załóżmy trochę trudniejszy scenariusz niż kolejne patch’e na jednym rozwiązaniu (co oczywiście jest proste i skutkuje konkretnymi, spodziewanymi zmianami wprowadzanymi w patch’ach). Mianowicie, wprowadzamy Poprawkę do dostosowania (np. encji), które jest też komponentem innego Rozwiązania. Mamy więc taką sytuację na środowisku docelowym:

  • PodstawoweRozwiazanie, 2017.0.0.0., zawiera encję „Encja” i pole „Pole Testowe” o długości 50 znaków
  • InneRozwiazanie, 1983.0.0.0., zainstalowane później, też zawiera encję „Encja„, ale długość pola „Pole Testowe” jest zmieniona na 100 znaków

solutions-managed

Przygotowujemy poprawkę PodstawoweRozwiazanie, 2017.0.1.0. (pierwszy patch) z długością pola „Pole Testowe” zmienioną na 70 znakówCo stanie się, kiedy zainstalujemy naszą Poprawkę? 

Otóż odpowiedź różni się w zależności od tego, czy pracujemy na Rozwiązaniach Zarządzanych i Niezarządzanych:

W przypadku Rozwiązań Zarządzanych… nic się nie stanie dopóki w systemie mamy zainstalowane InneRozwiazanie. Długość pola „Pole Testowe” nadal będzie mieć 100 znaków! A to dlatego, że nasza Poprawka chce zmienić i może zmienić tylko nasze PodstawoweRozwiazanie, ale nie może zmienić drugiego rozwiązania (bo nie została dla niego stworzona)! Dlatego, w powyższym scenariuszu nasz patch zostanie „uwzględniony” dopiero, kiedy odinstalujemy InneRozwiazanie (1983.0.0.0.). Wtedy z automatu PodstawoweRozwiazanie będzie mieć numerek 2017.0.1.0. (pierwszy patch), a więc będzie zawierać wszystkie zmiany wprowadzone przez nasz patch.

W przypadku Rozwiązań Niezarządzanych oczywiście nasz patch nadpisze „Pole Testowe” tak, jak się tego spodziewamy. UWAGA! Wbrew temu, co pisze Microsoft na MSDN’ie tutaj w akapicie „Another patching example”: https://msdn.microsoft.com/en-us/library/mt593040.aspx

 

Tworzenie poprawek i aktualizacji krok po kroku

Poniżej opisuję kilka kroków, które przeprowadzą Was dokładnie przez proces utworzenia pierwszego patch’a (Z) i pierwszej aktualizacji (Y) w Dynamics 365:

  1. Tworzymy Rozwiązanie i dodajemy do niego wszystkie aktywa, które ma zawierać:

solution01

2. Tworzymy pierwszą Poprawkę do Rozwiązania poprzez „Klonuj do poprawki”. Dynamics 365 automatycznie zmieni numer wersji, inkrementując trzecią cyfrę:

solution02

3. Dodajemy zmiany w Poprawce. Po dodaniu wszystkich aktywów, w systemie mamy jedno Rozwiązanie (2017.0.0.0) i jedną Poprawkę (2017.0.1.0):

solution03

4. Kiedy mamy już dużo poprawek, możemy zdecydować się na utworzenie aktualizacji Rozwiązania. Taka aktualizacja automatycznie będzie zawierać wszystkie wcześniej utworzone Poprawki, a same Poprawki znikną z systemu!

solution04

solution05

 

Aktualizacja zmieni też numer build’u, inkrementując drugą cyfrę (Y, minor) w numerze wersji Rozwiązania.

5. Podczas importu aktualizacji Rozwiązania system wykryje, że ma do czynienia z aktualizacją i pokaże nam dodatkową opcję zastosowania aktualizacji do istniejącego Rozwiązania.

 

Usuwanie poprawek

Podobnie jak w powyżej opisanym przypadku pracy z kilkoma Rozwiązaniami, usuwanie patch’y różni się w zależności od tego, czy pracujemy na Rozwiązaniach Zarządzanych, czy nie.

I tak, w przypadku Rozwiązania Zarządzanego wystarczy ze środowiska docelowego odinstalować to Rozwiązanie, a wszystkie poprawki (patch’e) zostaną usunięte automatycznie.

Natomiast, w przypadku Rozwiązania Niezarządzanego usuwanie Poprawek odbywa się „pojedynczo”, a samo Rozwiązanie nie da się usunąć, jeśli najpierw nie usuniemy jego Poprawek. System poinformuje nas o tym, jeśli zapomnimy o tej kolejności miłym błędem:

solution-unmanaged-deletion

 

Podsumowanie

Mechanizm Poprawek i Aktualizacji stanowczo wspiera pracę podczas wdrażania Microsoft Dynamics 365 for Customer Engagement poprzez dobry i przemyślany, a przede wszystkim działający, mechanizm wersjonowania. Dzięki mechanizmom klonowania Poprawek i aktualizacji system sam dba o zależności między naszymi poprawkami a istniejącymi Rozwiązaniami, a dzięki temu, że wszystkie Poprawki automatycznie stają się częścią nowych aktualizacji, nie musimy się już martwić, że zapomnimy podczas importu nowej wersji Rozwiązań o jakimś komponencie.

To jedna z tych funkcji, które powinniście zacząć używać jak najszybciej!

 

Reklamy

Cele w CRM, a własność encji w Dynamics 365

Ten post jest trochę nietypowy, bo jest wskazówką i pewną odpowiedzią na notoryczny problem z tym, na jakich encjach można tworzyć cele w Microsoft Dynamics 365.

Trochę o celach w Microsoft Dynamics 365

Zarządzanie celami to jedna z funkcjonalności Dynamics 365 obecna w Dynamics CRM od wersji 2011. Niektórzy ją kochają ze względu na elastyczność i łatwość tworzenia celów dla użytkowników CRM, a także za łatwość prezentacji danych o postępie i celach. Inni nienawidzą za to, że każdy cel musi mieć właściciela i jest tylko na dany okres fiskalny, a w kolejnych trzeba tworzyć cele od nowa i za każdym razem osobno dla każdego użytkownika / zespołu.

Jeśli ktoś chce używać celów, to ma do dyspozycji całkiem dobry mechanizm (o ile akceptuje trudność w ergonomii dla tworzenia celów od nowa co okres fiskalny) składający się z następujących komponentów:

  • Metryka Celu (Goal Metric):
    Obiekt pozwalający na wybór typu celu oraz danych, które chcemy śledzić (np. czy to będzie cel liczbowy, czy kwotowy i jaki typ danych będzie liczony do postępu i realizacji celów)
  • Cel (Goal):
    Cel to jak sama nazwa wskazuje właściwy cel, który obowiązkowo składa się z Nazwy, Metryki Celu, Właściciela Celu (i jego managera) oraz przede wszystkim z Okresu Obrachunkowego, dla którego ma być liczony. Cel zawiera dane o oczekiwanej (docelowej) liczbie lub kwocie, a także może zawierać Cele Podrzędne, jeśli chcemy liczyć cele dla zespołów.
  • Zapytanie Zestawienia (Rollup Query):
    Zapytanie Zestawienia umożliwia szczegółowy wybór rekordów, które mają być zaliczane do Celu. Przykładem może być sytuacja, w której Celem jest uzyskanie 100 000 PLN przychodu w wystawionych fakturach (Metryka Celu), ale dodatkowo chcemy, żeby były to faktury na konkretny rodzaj usługi (Zapytanie Zestawienia).

Mojej encji nie mam na liście Celów, czyli haczyk z własnością encji…

Wiadomo, że cele w Dynamics 365 mogą obejmować nie tylko dane sprzedażowe, ale dowolne inne dane z różnych encji, które dają się sumować lub liczyć (pod warunkiem, że Metryka Celu jest jednym z dwóch typów – Liczba, albo Kwota). Łącznie z tym, że możemy tworzyć Cele (Goals), Metryki Celów (Goal Metrics) i Zapytania Zestawienia (Rollup Queries) dla encji stworzonych przez nas (encji dostosowanych / Custom Entities).

Jednak jest jeden bardzo ważny punkt – teoretycznie wszystkie (w tym custom) encje mogą być przedmiotem dla Celu. Czy naprawdę? Wystarczy chwilę się zastanowić (i nie zapomnieć podczas wdrożenia), że Cele mają Właścicieli i obejmują rekordy, które mają właścicieli. Dlatego też Cele mogą być w praktyce tworzone tylko dla encji, które mają Własność ustawioną na „Użytkownik lub zespół”, a nie na „Organizacja”!!!

Screen Shot 2017-05-08 at 17.10.36

Implikacje w prawdziwym życiu

Czemu to jest takie ważne? Ano dlatego, że ta przypadłość celów wymaga odpowiedniego planowania nowych obiektów w kontekście ich właśności w systemie. Nie da się przecież zmienić typu Własności już po utworzeniu encji. A co dopiero, kiedy encja jest w pełni dostosowana, a my zaimportujemy już dane z zewnętrznego systemu… Wtedy możemy się nieźle zdziwić, kiedy obiecamy Klientowi np. zarządzanie celami na wystawione faktury, albo na liczbę zamówień i stworzymy encję, której Własność ustawiona będzie na „Organizacja”. A przecież w przypadku takich obiektów jak Faktura takie ustawienie właśnie ma największy sens. Chcemy przecież zapewnić w systemie w prosty sposób – albo ktoś widzi faktury z ERP, albo nie. Nie zastanawiamy się i na pewno nie chcemy dodatkowo ustawiać właścicieli dla każdej zaimportowanej faktury i konfigurować ról zabezpieczeń w taki sposób, żeby użytkownicy mogli widzieć tylko konkretne faktury.

Podobnie ma się sytuacja z wieloma innymi encjami utworzonymi na wdrożeniach – chcemy albo widzieć stan magazynowy (kiedy tworzymy sobie encję na te potrzeby), albo nie. Chcemy albo pozwolić użytkownikom widzieć wejścia na stronę (kiedy tworzymy encję na te potrzeby), albo nie. Nie ma przecież sensu, żeby takie obiekty miały właścicieli – po prostu użytkownicy albo je widzą, albo nie.

Podsumowując – cele w Microsoft Dynamics 365 można ustawiać na wielu encjach, w tym encjach własnych. Jednak nie da się używać mechanizmu Celów na encjach, które właściwość Własność mają ustawioną jako „Organizacja”. Dodajcie sobie powyższy punkt do listy podczas planowania nowych encji :).

Zmiana maksymalnej liczby zakładek na formularzu

Czy próbowaliście kiedyś dodać wiele zakładek do dowolnej formatki w Microsoft Dynamics CRM 4.0? Zdawaliście egzamin „Applications”? Jeśli padło choć raz TAK, to wiecie, że Dynamics CRM nakłada na nas ograniczenia na liczbę zakładek na formatkach. Maksymalna liczba zakładek to 8. Co zrobić jeśli potrzebujesz więcej zakładek? Oficjalnie nic. Ale od czego są nieoficjalne zmiany? 🙂
Pomijając user experience takiej formatki, możesz zwiększyć maksymalną liczbę zakładek na formatce powyżej 8. W tym celu trzeba dokonać zmiany w pliku odpowiedzialnym za ustawienia edyora formatek:

  1. Na serwerze, gdzie zainstalowany jest Dynamics CRM, wchodzimy do katalogu zawierającego pliki stron (C:\inetpub\wwwroot, C:\Microsoft Dynamics CRM\CRMWeb albo inny katalog, do którego zainstalowaliście strony)
  2. Wchodzimy do katalogu Tools
  3. Wchodzimy do katalogu FormEditor
  4. Edytujemy plik FormEditor.aspx i znajdujemy w nim linijkę:
    var _iMaxTabs = 8;
  5. Zmieniamy na większą liczbę i zapisujemy plik
  6. Restartujemy IIS’a i mamy nową funkcjonalność CRM’a 🙂

Uważajcie tylko z tymi zakładkami, bo… w CRM 5 nie będzie ich w ogóle! Lepiej więc nie przyzwyczajać klientów…
PS. Nie muszę chyba dodawać, że zmiana jest niewspierana i jako taka może być usunięta przez Microsoft w którymś Rollup’ie?

3 spotkanie grupy DxPUG i CRM Developer Toolkit

Na ostatnim (3-cim) spotkaniu Dynamics xRM Polish User Group (http://ms-groups.pl/dxpug/3_spotkanie/) miałem okazję powiedzieć kilka słów o CRM Developer Toolkit – narzędziu (lub framework’u, jak kto woli) wspomagającym pracę z Microsoft Dynamics CRM 4.0. Dla tych których nie byo na spotkaniu, krókie podsumowanie CRM Developer Toolkit tutaj:

  • Zestaw narzędzi do rozszerzania Dynamics CRM zintegrowanych z Visual Studio
  • Zestaw szablonów projektów Visual Studio bazujących na wdrożeniach klasy Enterprise (od plugin’ów przez własne strony ASP.NET aż po usługi Windows korzystające z CRM w tle)
  • Składa się z: CRM Solution Framework i CRM Explorer
  • pozwala edytować encje i generować kod
  • dostarcza jednolitego środowiska do rozwijania wszystich komponentów (od plugin’ów po zewnętrzne strony
  • może być budowany za pomocą predefiniowanych konfigurcji MSBuild
  • można go ściągnąć stąd: http://code.msdn.microsoft.com/E2DevTkt

Więcej o CRM Developer Toolkit (w tym prezentacja) na stronie grupy. BTW, zapraszam więcej osób na kolejne spotkania!

SDK 4.0.9. dla Dynamics CRM 4.0

W piątek rano pojawiło się nowe SDK, tym razem opatrzone numerkiem 4.0.9. W nowym SDK pojawił się m.in. cały opis wszystkich encji i atrybutów, który do tej pory dostępny był w metadata browser’ze, na serwerze CRM. Dodatkowo pojawiły się trzy nowe szablony projektów Visual Studio dla Microsoft Dynamics CRM, np. strona korzystająca z danych.

SDK 4.0.9 jest do ściągnięcia stąd: http://www.microsoft.com/downloadS/details.aspx?FamilyID=82e632a7-faf9-41e0-8ec1-a2662aae9dfb&displaylang=en

Strony ASP.NET rozszerzające CRM i ViewState

To, że Microsoft Dynamics CRM 4.0 jest platformą „super-rozszerzalną” wie każdy :). Do popularnych sposobów rozszerzania należą nasze własne strony ASP.NET wyświetlane np. w pływających ramkach (iframes). Dobre praktyki nakazują umieszczanie naszych stron w folderze ISV w katalogu, do którego zainstalowane zostały pliki ze stronami używane przez Dynamics CRM (katalog CRMWeb lub dowolny wybrany przez nas podczas instalacji). Dzięki umieszczeniu stron w folderze ISV mamy dostęp do kilku ciekawych informacji przekazywanych naszym stronom przez CRM. Niestety, jest też jedna rzecz, o której warto pamiętać: fakt, że nasze strony są w podfolderze używanym przez CRM powoduje m.in., że domyślnie na nasze strony narzucane są ustawienia z web.config CRM’a. Pośród wielu ustawień jest m.in. taka linijka:

<pages buffer=”true” enableSessionState=”false” enableViewState=”false” validateRequest=”false”/>

 

Łatwo zauważyć, że przez tą linijkę nasze strony domyślnie mają wyłączony ViewState (!). Nie jest to sytuacja, której się spodziewamy… Szczególnie może zdziwić Was sytuacja, kiedy tworzycie strony i zaawansowany kod na innym środowisku. Wszystko działa, a po umieszczeniu na serwerze CRM nagle kontrolki gubią „pamięć”, co chwila dostajecie „null reference” itd. Warto wtedy sprawdzić, czy pozwalacie Waszej stronie na zarządzanie stanem (ViewState). Jeśli nie, koniecznie ustawcie to explicite. W tym celu, w kodzie strony .aspx, do pierwszej linijki, należy dodać dyrektywę EnableViewState=”true”, jak w poniższym przykładzie:

<%@ Page Language=”C#” (…) EnableViewState=”true” %>

Jeśli chcecie szyfrować zawartość ViewState, możecie dodać też EnableViewStateMac=”true”.

Miłego kodowania i mniej nerwów, jak po postback’u macie puste listy! 🙂

II spotkanie grupy Dynamics xRM Polish User Group

19 maja 2009, we wtorek, o godz. 18:00 w Microsoft przy Al. Jerozolimskich 195A w Warszawie odbędzie się drugie spotkanie grupy Dynamics xRM Polish User Group (DxPUG). W czasie spotkania będzie „bardzo technicznie”, bo planujemy dwie sesje o rozszerzaniu platformy Dynamics CRM 4.0. Tomek Filipowicz opowie o plug-in’ach, ich roli, cechach i sposobie pisania. Ja za to powiem trochę o UWAGA, UWAGA CRM 5.0! Na razie tylko informacje, które można przekazać, ale będziemy na pewno pierwsi :).

Zapraszam wszystkich do rejestracji na II spotkanie grupy tutaj: Rejestracja na II spotkanie DxPUG.