SDK 4.0.12 – kolejna rewolucja!

Zazwyczaj informowałem o nowych wersjach SDK za pomocą krótkiego opisu. W przypadku CRM SDK 4.0.12 opis nie może być krótki. Takie SDK u innych producentów systemów CRM nazywałoby się „major platform upgrade” i kosztowałoby tyle, co kolejna wersja systemu. SDK 4.0.12 to zmiana spojrzenia na platformę Microsoft Dynamics CRM! To również totalne przełączenie na koncepcję xRM! Ja osobiście jestem w szoku :) . Nowe SDK przygotowuje nas po prostu do gładkiego przejścia do CRM 5 i daje już teraz dostęp do funkcjonalności SDK CRM 5.
David Jennaway już sporo opisał na swoim blogu, ale myślę, że można by napisać ciągle więcej o tej rewolucji po polsku. Tak więc… ;P:

SDK 4.0.12 wprowadza pojęcia „Advanced Developer Extensions” czyli „Zaawansowanych rozszerzeń programistycznych”, które technicznie nazwane są po prostu xRM’em. W skrócie polegają na tym, że możemy korzystać z platformy Dynamics CRM w zupełnie nowy sposób. I tak:

  • nowe SDK pozwala na korzystanie z danych w Dynamics CRM za pomocą LINQ!!! Niech ten piękny kod powie sam za siebie:
    var marketingListsWithCalculations =
    from marketingList in crm.lists
    select new { marketingList.listname, Cost = marketingList.cost + 100 };
  • nowe SDK pozwala na używanie natywnych typów .NET!!! W tym typów nullowalnych (o których nota bene pisałem ostatni projekt w szkole ;) ), czyli np. short? a nie short, dzięki czemu unikamy konieczności ustawiania IsNullSpecified
  • możemy budować źródła danych za pomocą klasy DataContext
  • nowe SDK dostarcza narzędzie CrmSvcUtil, które pozwala budować lokalne i silnie typowane odzwierciedlenia bazy CRM, czyli klasy reprezentujące obiekty i DTO (Data Transfer Object). Dzięki temu można pisać kod oparty o LINQ
  • nowe SDK daje wsparcie dla WCF! poprzez generowanie klas kontekstowych za pomocą CrmSvcUtil
  • z nowym SDK możemy robić tzw. batch updates!!! To z kolei znaczy, że nie musimy już robić tysiąca wywołań Update(). Zamiast tego możemy modyfikować dane „lokalnie”, cache’ować je i dopiero za jednym wywołaniem aktualizować wszystkie na raz! Tutaj przykład:

    contact.Email emailaddress1 = "janko@x.com";
    contact.contact_customer_accountsParentCustomerAccount = account;
    contact1.Firstname firstname = "Jakub";

    crm.UpdateObject(contact);
    crm.UpdateObject(contact1);

    // zapisywanie do bazy
    crm.SaveChanges();

  • nowe SDK pozwala pobierać obiekty powiązane za pomocą gotowych metod. Dzięki temu zamiast budować QueryExpression i podawać GUID’y możemy po prostu wywołać metodę GetRelatedEntities()
  • nowe SDK daje zupełnie nowe możliwości budowania relacji między obiektami z poziomu kodu (poprzez metodę SetLink() albo aktuzalizację klucza obcego). Wystarczy zerknąć na przykłady poniżej, żeby zobaczyć dlaczego mówię o rewolucji :) :
    crm.SetLink(contact, "contact_customer_accounts", account);
    crm.SaveChanges();

    albo:

    contact.contact_customer_accounts = account;
    crm.UpdateObject(contact);
    crm.SaveChanges();
  • nowe SDK zawiera informacje o budowaniu tzw. Visual Charts, czyli dynamicznych wykresów z danych w CRM. W CRM 5 wykresy te będą mogły być wyświetlane na listach rekordów, aktualnie udostępnia je w ograniczonej postaci tylko CRM Online R4.
  • nowe SDK zawiera zupełnie nowe rozdziały o uwierzytelnianiu w modelach serwer-serwer i impersonacji
  • nowe SDK zawiera mnóstwo nowych rozdziałów, w tym rozdziały opisujące dokładnie dlaczego należy korzystać z DynamicEntity, z klasy IsvReadiness i kilkunastu innych
  • nowe SDK zawiera rozdziały o dobrych praktykach w pisaniu zewnętrznych aplikacji korzystających z CRM i o sugestiach związanych z wydajnością takich aplikacji

Na razie nikt nie wie, czy ukaże się CRM SDK 4.0.13. A to dlatego, że 4.0.12 zbliża nas wielkimi krokami do CRM 5. Już teraz Microsoft przyzwyczaja programistów do rozwiązań, które w gotowej platformie zobaczymy za kilka miesięcy. SDK 4.0.12 to jest coś pięknego. To dla takich chwil warto kochać Dynamics CRM’a! I w takich chwilach wiem, czemu kocham MS a nie Google’a, który za major update uważa nowy kształt guzika „szukaj” :D .

PS. SDK 4.0.12 jest do ściągnięcia tutaj: http://www.microsoft.com/downloads/details.aspx?FamilyID=82E632A7-FAF9-41E0-8EC1-A2662AAE9DFB&displaylang=en

CRM SDK 4.0.10 dla Dynamics CRM

Długo trzeba było czekać na aktualizację SDK. 2 listopada Microsoft opublikował nowe SDK w wersji 4.0.10. SDK oczywiście bazuje na systemie z Rollup’em 7. Pośród zmian są m.in. nowe rozdziały o optymalizacji kodu poprzez np. użycie predefioniwanych serializerów, poprawiony Plugin Registration Tool, rozdziały o filtrach w raportach i nowe opisy stylów CSS używanych w CRM. Niestety najwięcej zmian w SDK 4.0.10 dotyczy CRM Online. To pokazuje, że Microsoft rzeczywiście zaangażował się w rozwój platformy.
SDK 4.0.10 można ściągnąć tutaj: http://www.microsoft.com/downloads/details.aspx?FamilyID=82E632A7-FAF9-41E0-8EC1-A2662AAE9DFB&displaylang=en.

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!

Dokument „The Microsoft Dynamics CRM Security Model”

Sustaining Engineering Team (E2) opublikował kolejny bardzo techniczny dokument o Microsoft Dynamics CRM. Tym razem trafiło na opis bezpieczeństwa, metod autentykacji i zabezpieczeń systemu i całej platformy. Dość obszerny dokument opisuje w szczegółach jakie są dostępne metody autentykacji, której należy użyć i jak Dynamics CRM radzi sobie z zapytaniami przez web services, z zewnętrznych aplikacji i po prostu z dowolnymi odwołaniami do platformy.
Dokument dostępny jestdo ściągnięcia tutaj: https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=fb4bb16b-586f-4aae-aa4b-790023e95b61. Polecam go każdemu, kto chce wiedzieć, dlaczego czasem RetrieveMultiple zwraca mu różne liczby rekordów ;) .

Zamykanie szans sprzedaży programistycznie

Szanse sprzedaży, podobnie jak inne obiekty, mają tzw. stan i status (statecode i statuscode). Kiedy zamykamy szanse sprzedaży z poziomu interfejsu Microsoft Dynamics CRM, nie zastanawiamy się często, co tak naprawdę robi CRM „pod spodem”. Otóż, system zmienia wtedy stan i status konkretnej szansy sprzedaży.
Jeśli chcemy zamknąć szansę sprzedaży programistycznie (z poziomu kodu), nie zmieniamy jednak jej stanu, jak robilibyśmy to w przypadku innych obiektów. Aby zamknąć szansę sprzedaży, należy użyć jednej z dwóch klas: WinOpportunityRequest albo LoseOpportunityRequest. Obiekty te mają dwie właściwości, które powinniśmy ustawić: opportunityclose i status. Ten pierwszy obiekt reprezentuje działanie odzwierciedlające zamknięcie szansy sprzedaży. Działanie to ma szereg właściwości, które możemy chcieć ustawić, np. actualend czy actualrevenue.
Przykładowy kod może wyglądać tak (należy dodać właściwe wartości):

opportunityclose zamkniecie = new opportunityclose();
zamkniecie.opportunityid = new Lookup();
zamkniecie.opportunityid.Value = GUID_SZANSY_SPRZEDAZY;
zamkniecie.actualrevenue = WARTOSC_SZANSY_SPRZEDAZY;
zamkniecie.actualend = AKTUALNA_DATA;

WinOpportunityRequest winReq = new WinOpportunityRequest();
winReq.OpportunityClose = zamkniecie;
winReq.Status = -1; // -1 pozwoli systemowi ustawić domyślny status

crmService.Execute(winReq);

Analogicznie, można zamknąć szansę sprzedaży jako przegraną, używając LoseOpportunityRequest. Miłego programowania!

Jak usunąć więcej niż 250 rekordów na raz?

Każdy, kto pracuje z Microsoft Dynamics CRM prędzej czy później zderzy się z problemem „jak usunąć tysiąc rekordów na raz”? Zdarza się, że zapełniamy system danymi testowymi, które musimy później usunąć lub najzwyczajniej w świecie potrzebujemy usunąć kilka tysięcy rekordów dowolnego typu z jakiejś przyczyny. Ostatnio coraz więcej osób mnie o to pytało, więc postanowiłem opisać kilka sposobów. Dla tych, co potrzebują odpowiedzi po angielsku, proponuję przetłumaczyć tę stronę w LiveTranslator’ze ;)

W interfejsie Dynamics CRM, w opcjach, możemy wybrać wyświetlanie w widoku maksymalnie 250 rekordów. Usunięcie 10000 testowo utworzonych klientów nadal będzie żmudne :) = będzie wymagało od nas 40 razy zaznaczenia wszystkich rekordów i kliknięcia „Usuń”. Można zrobić to sprytniej!

Sposób 1 – usuwanie z pomocą kodu:

Jeśli lubisz kod i nie boisz się skompilować już gotowego kodu, Microsoft Dynamics CRM 4.0 udostępnia w SDK jeden przydatny request – BulkDeleteRequest. Jeszcze w Dynamics CRM 3.0 nie było możliwości usuwania wielu rekordów na raz przez wywołania web service’ów. W 4.0 to jest możliwe! Wystarczy zbudować kwerendę (QueryExpression), podać ją jako atrybut to obiektu typu BulkDeleteRequest, uzupełnić resztę właściwości i wywołać metodę Execute() w CrmService. Więcej informacji na ten temat znajduje się tutaj: http://msdn.microsoft.com/en-us/library/cc155955.aspx

 

Sposób 2 – unikaj cudownych płatnych narzędzi:

Jest pewna (niepolska) firma, która potrafiła zbić kapitał na niewiedzy użytkowników i… oferuje narzędzie, które wywołuje powyższy kod za opłatą! Ja sam zwalczam takie praktyki, dlatego nie polecam korzystania z takich narzędzi. Raczej lepiej poczytać SDK i samemu skopiować kod.

 

Sposób 3 – magiczny trick z dostosowaniami:

To jest niestety obejście, którego minusów trzebe być świadomym. Na szczęście nie ma ich wiele. Otóż, można usunąć dowolną liczbę rekordów dowolnego typu poza obiektami typów systemowych w bardzo prosty sposób – usuwając obiekt danego typu z systemu :) . Przy tym rozwiązaniu robimy backup naszych dostosowań, usuwamy obiekt, którego rekordy chcemy usunąć i… importujemy ten obiekt z powrotem :) . Do plusów tego rozwiązania należy niewątpliwie fakt, że usuniemy dowolną liczbę rekordów w super-krótkim czasie. Do minusów należy zaliczyć fakt, że obiekty custom mają tzw. ObjectTypeCode nadawany każdemu nowotworzonem obiektowi sekwencyjnie od 10000. Nasz nowy import nada naszemu obiektowi nowy numer i lepiej, żebyśmy byli świadomi w których skryptach używamy starego ObjectTypeCode =)

Mam nadzieję, że te wskazówki pomogą Wam usuwać mnóstwo danych z Waszego CRM’a! Jest jeszcze jeden sposób, który pozwala na wyświetlanie 5000 rekordów w widokach. Ale o nim nie napiszę – zbyt to „niesupportowalne” ;)

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.

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ą.