Dynamics 365 Business Edition, czyli z Maderą się nie udało; czas na Teneryfę…

2017-09-212017-09-21 Jakub (Kuba) Skałbania aktualizacja, Dynamics 365, nowy, Tenerife, xRM

W światku Dynamics’owym zawrzało… Od wczoraj Twitter i blogi, a także część polskiego internetu poświęconego Microsoft Dynamics się gotuje. Polacy piszą: Dynamics 365 „Business Edition już nie ma”, „Dynamics 365 Business Edition zaprzestana”, a Amerykanie „Business Edition is no more” (cytat wyrwany z kontekstu z wypowiedzi przedstawiciela Microsoft). W takich sytuacjach warto zatrzymać się na chwilę i zamiast cytować plotki – doczytać i dopiero dzielić się informacjami.

Co stało się wczoraj na Directions 2017?

Marko Perisic, podczas otwierającej sesji na konferencji Directions w Orlando powiedział, że Microsoft Dynamics 365 Business Edition to od teraz Project Tenerife. Dla przypomnienia roboczą nazwą dla Business Edition była Project Madeira.

Panika rozlała się po wszystkich. Panika wynikająca z niezrozumienia co się stało. Rozwój Microsoft Dynamics 365 Business Edition nie został zawieszony! To, co się wydarzyło, to „niespodziewana” zmiana planów i roadmapy „mniejszego” Dynamics’a 365. Zmiana, która w kręgu dobrych partnerów NAV’owych i grup zainteresowanych konsultantów Dynamics 365, była spodziewana. Nawet dla rynku ogólnego powinna być spodziewana, bo jak można się nie spodziewać zmiany planów, jeśli Microsoft w sierpniu (na miesiąc przed premierą) mówił, że moduł marketingowy i funkcjonalność przeniesiona z NAV nie jest jeszcze gotowa. A dodatkowo w zasadzie nie było planu co dalej z Microsoft NAV. Ktokolwiek wierzył, że w jeden miesiąc ogromne funkcjonalności nagle się pojawią? Chyba nie.

Co w takim razie dzieje się z Microsoft Dynamics 365 Business Edition i czym jest Project ‚Tenerife’?

Dynamics 365 Business Edition rzeczywiście znika, ale tylko z licencjonowania Microsoft. Znika, bo tak, jak pisałem wcześniej, a mówiłem wszystkim Klientom na spotkaniach, totalnie bez sensu była wersja Business Edition, która miała być tańsza i być przeznaczona dla x liczby użytkowników. I zawsze pojawiało się to samo pytanie:

„Załóżmy, że Klient kupi Business Edition i urośnie o kilku użytkowników. Co ma się stać? Ma się zmigrować z Business Edition opartego o Dynamics NAV i przenieść do Enterprise Edition opartego o Dynamics AX?”

No przecież – proste, że nie! Mimo oszalałej wizji pań i panów z marketingu w Redmond, już w listopadzie 2016 roku na spotkaniach dla insider’ów były poruszane tematy potencjalnej konieczności migracji i zawsze kończyło się tak samo. Przy tej okazji pozdrawiam Klientów, którym jeszcze w zeszłym tygodniu mówiliśmy, żeby uważali na Business Edition 😉 – mam nadzieję, że znów pomogliśmy w strategii.

W Project Tenerife i w nowym licencjonowaniu licencje kupuje się dla użytkowników „na moduł” (per app), a nie w zależności od liczby użytkowników. I to ucina spekulacje, że Business Edition się skończył. Licencjonowanie tak, produkt nie. Ba, produkt żyje i będzie większy niż Microsoft mówił.

Project Tenerife to w zasadzie połączenie Microsoft Dynamics 365 Business Edition i Microsoft Dynamics NAV, ale ze znaczącym naciskiem na platformę stojącą pod spodem i opartą o Common Data Service. Sam NAV ma być rzeczywiście zaprzestany, a wiodącym systemem ma być jego następca, Tenerife, który będzie oferował pełną funkcjonalność Dynamics NAV i w chmurze i on-premise.

Razem z nową platformą Microsoft ogłosił też, że możliwe będzie budowanie własnych aplikacji dla konkretnych branż i sprzedawanie ich jako „white label”, tj. np. „Mały ERPik z super CRMem powered by Microsoft Dynamics”. Mamy więc odpowiednik Force.com w Microsofcie (ciekawe dlaczego? Ktoś zgadnie? 🙂 Może dlatego, że szef AppExchange’a Salesforce’owego rządzi teraz w Microsofcie?)

Najważniejsze fakty o Dynamics 365 Project Tenerife

Najważniejsze fakty o następcy Business Edition można podsumować tak:

pełny Dynamics NAV połączony z Dynamics 365 Business Edition
brak ograniczeń wynikających z liczby licencji
licencjonowanie oparte o moduły i aplikacje
platforma do budowy własnych aplikacji oparta o Common Data Service
pełna integracja z Outlook, Office365 i Power BI
szereg gotowych modułów, np. Accountant Hub dla księgowych
możliwość instalacji w chmurze i on-premise

Reklamy

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

2017-08-292017-08-27 Jakub (Kuba) Skałbania aktualizacja, dostosowanie, Dynamics 365, xRM

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:

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

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

Przygotowujemy poprawkę PodstawoweRozwiazanie, 2017.0.1.0. (pierwszy patch) z długością pola „Pole Testowe” zmienioną na 70 znaków. Co 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:

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

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

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):

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!

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:

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!

Rozdzielenie platformy od aplikacji w Dynamics 365 (9.x.x.x) – o co chodzi Microsoftowi?

2017-08-23 Jakub (Kuba) Skałbania co nowego?, Dynamics 365, nowy, xRM

Prawdziwy Dynamics 365 nadchodzi!

Pamiętam kilka naprawdę gorących rozmów z Klientami (i przy okazji Microsoft’em) o tym, dlaczego nie warto migrować się do Microsoft Dynamics 365, który pojawił się na rynku w 2016 roku. Ci klienci, którzy nam uwierzyli w lutym i marcu tego roku i posłuchali, że „tamten” Dynamics 365 z grudnia to jedynie update, a nie nowa wersja (8.2.x.x, a nie 9.x.x.x) dobrze na tym wyszli. Ci, którzy uwierzyli mimo naszych warsztatów Microsoftowi przeżyli koszmar z migracją do nowych licencji i do platformy, która była przejściowa. Teraz muszą zmierzyć się z migracją do tego prawdziwego Dynamics 365 :). Dlatego warto wierzyć ekspertom, a nie sprzedawcom, ale to tak przy okazji.

Tak, czy inaczej, prawdziwy Dynamics 365 (a więc wersja z nowym numerem) nadchodzi wielkimi krokami. Należy więc zacząć przygotowywać się do niej z odpowiednią uwagą.

Rozdzielenie platformy i aplikacji, czyli co?

Jedną ze zmian, o których rzadko mówią sprzedawcy Microsoftu (z mojego doświadczenia nawet o niej nie wiedzą, bo to nie jest coś, co się „łatwo sprzedaje”) jest tzw. application-platform separation, czyli rozdzielenie platformy Microsoft Dynamics CRM (tak, CRM, nie żaden Dynamics 365) od logiki i modułów funkcjonalnych. Z wysokiego poziomu można to rozdzielenie opisać w taki sposób:

Do tej pory mieliśmy moduł Sprzedaży, Marketingu i Obsługi Klienta wbudowany w platformę. Te moduły, niejako, były częścią Microsoft Dynamics CRM. Były tam zawsze; no dobra, Obsługi Klienta nie było w 1.2 😉 ). Generalnie chodzi o to, że kupując Microsoft Dynamics CRM kupowaliśmy te trzy moduły i platformę do budowania aplikacji xRM:

Od wersji 9.0 wszystkie te moduły, które znamy od lat i które dla wielu osób są tożsame z „CRM’em”, zostaną „wyrzucone” z „platformy”, która staje się z powrotem platformą, czyli czymś, na czym można budować dowolne inne aplikacji.

Witajcie w historii MBS CRM i w 2003 roku!!! 🙂 Już wtedy Philip Richardson (teraz w Salesforce) był adwokatem osobnej platformy xRM i budowania na niej „appek” w oparciu o SDK. Nomen omen, teraz ta platforma ma roboczą nazwę… xRM Server.

xRM Server jest więc platformą do budowania aplikacji i obejmuje (nazwy Rozwiązań celowo po angielsku, bo takie będą nazwy Solucji w v9!):

Oczywiście istniejące moduły zostają „w CRM’ie”, ale technicznie będą realizowane już przez osobne Rozwiązania i nie będą „częścią systemu”. To, w wersji 9.0, dotyczy również modułu Sprzedaży, Marketingu i Obsługi Klienta – od nowej wersji nie są one już częścią platformy, a stają się Rozwiązaniami (Solutions)!!!

Czemu tak?

Od niedawna widać, że Microsoft zaczął dodawać kupowane przez siebie produkty (portale ADX, FieldOne) jako solucje (rozwiązania) do Dynamics CRM. Oczywiście to wynika z faktu, że partnerzy robiący wcześniej te rozwiązania oferowali je swoim Klientom jako solucje, więc naturalnym krokiem było pozostawienie ich w tej formie, zamiast podejmowania próby „wbudowywania” ich w platformę. Dodatkowo takie podejście ma mnóstwo innych zalet…

Zalety rozdzielenia platformy od logiki aplikacji

Trzymanie konkretnych funkcjonalności / modułów jako osobne rozwiązania, w separacji od platformy ma szereg zalet w kontekście Microsoft Dynamics 365, m.in.:

Możliwość aktualizacji konkretnego modułu (np. Sprzedaży) bez konieczności podnoszenia wersji całej platformy
Brak zależności od konkretnego partnera / zespołu wewnątrz Microsoft podczas aktualizacji ważnych dla nas funkcjonalności
Rozdzielenie kodu platformy od kodu realizującego konkretne funkcjonalności, przez co developerzy mają znacznie mniej zależności przy rozwoju konkretnego modułu
Możliwość szybszego nadążania za rynkiem w kontekście konkretnego modułu bez oglądania się na całą platformę
Ogromna zmiana w podejściu do implementacji rozwiązań przez partnerów, bo nie będziemy zależni od „wszystkich” komponentów encji systemowych, ale w zamian będziemy zależni tylko od poszczególnych modułów

Na czym technicznie polega to rozdzielenie?

Platforma Microsoft Dynamics 365 składa się z wielu komponentów/warstw (od bazy danych, przez serwery web’owe aż po aplikacje natywne i kod po stronie klienta). Dlatego rozdzielenie, o którym mowa w tym poście, musiało dotyczyć wszystkich tych warstw.

W warstwie serwerowej oznacza to, że:

cały kod charakterystyczny dla poszczególnych modułów został przeniesiony do plug-in’ów
metadane encji (a także jej elementów, takich jak widoki i formularze) zostały przeniesione do konkretnych rozwiązań

W warstwie klienckiej rozdzielenie platformy od aplikacji polegało na:

przepisaniu wszystkich stron ASPX na własne kontrolki w oparciu o CCF (Custom Control Framework)
kod JScript został skonwertowany na TypeScript

Jak możecie się domyślać, rozdzielenie oznacza, że przybędzie nam Rozwiązań (Solutions). I tak, w wersji 9.0, mamy następujące Rozwiązania:

LeadManagement
ProductManagement
ClientUtilities
Sales
Scheduling
ServiceManagement
Marketing

Ktoś może zapytać „No dobra, a co stanie się, jak nie zainstaluję tych rozwiązań?” A, to odpowiedź jest prosta – sama platforma (xRM Server) bez doinstalowanych rozwiązań z funkcjonalnością np. Sprzedaży sprowadzi się po stronie UI jedynie do modułu Ustawień J. A to dlatego, że cała funkcjonalność będzie teraz realizowana przez dedykowane solucje.