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?

• 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 jest do ściągnięcia stąd: http://www.microsoft.com/downloadS/details.aspx?FamilyID=82e632a7-faf9-41e0-8ec1-a2662aae9dfb&displaylang=en

<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!

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

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

Podczas importu organizacji Import Organization Wizard’em (uruchamia się go z “Deployment Manager’a”) przenoszone zostają wszystkie dane zgromadzone w naszym systemie CRM. Jednym z kroków importu jest mapowanie użytkowników. Po co mapować użytowników nie muszę mówić – wyobraźcie sobie sytuację, że właścicielem 1000 zadań w poprzednim środowisku był użytkownik, którego nie ma w nowej domenie – już wiadomo po co mapować . Mapować można na kilka sposobów – kreator oferuje też możliwość auto-mapowania. I ten post jest właśnie omówieniem tych sposobów , które jak się okazuje wprowadziły w błąd niejednego administratora. Poniżej lista możliwych wyborów i ich wyjaśnienie:

Opcja 1 – Active Directory account name
Kreator zmapuje użytkowników na podstawie nazw kont w AD. Lepiej więc, żeby nazwy się zgadzały

Opcja 2 – Microsoft Dynamics CRM full name to Active Directory full name
Nazwy kont w ogóle nie muszą się zgadzać pomiędzy domenami. Wystarczy, że kreator będzie w stanie zmapować pełne nazwy użytowników w CRM to pełnych nazw w AD.

Opcja 3 – Prefix
Najdziwniejsza opcja – kreator zmapuje PO KOLEI użytkowników do JUŻ ISTNIEJĄCYCH w nowym środowisku kont o odpowiednio wybranej nazwie (np. “uzytkownik_”) i automatycznie inkrementowanym sufiksie. Jeśli więc chcemy, żeby właściciele rekordów np. Ala i Jaś zmienili się w “uzytkownik_01″ i “uzytkownik_02″, to wybierzmy tę opję. Wybranie tej opcji nie spowoduje, że kreator stworzy konta użytkowników w AD!

Opcja 4 – Use existing mapping file
ta opcja pozwoli nam użyć wcześniej stworzonego pliku XML z odpowiednimi mapowaniami użytkowników

Ważne:
1. Import Organization Wizard nigdy nie tworzy kont w Active Directory. Narzędzie pozwala jedynie mapować stare konta do nowych

2. Jeśli któreś konto nie da się automatycznie zmapować, nie ma strachu – kreator w następnym kroku pokaże błąd i da nam możliwość zmapowania pozostałych użytkowników.

Miłego przenoszenia!

1. Aby móc zmenić interfejs, musimy najpierw wyeksportować plik SiteMap. W tym celu z menu “Ustawienia“, wybieramy “Dostosowywanie” i “Eksportowanie dostosowań“:

2. Z listy wybieramy “Mapa witryny” i klikamy “Eksportowanie wybranych dostosowań”:

Microsoft Dynamics CRM - SiteMap

3. Wyeksportowany plik rozpakowujemy i otwieramy XML w edytorze. Teraz w miejscu, w którym chcemy dodać link (musi być w elemencie “Group“), wstawiamy odpowiedni element typu SubArea z URL do zewnętrznej strony. W pokazywanym przypadku, wstawiam link w module “Marketing”, tuż pod linkiem “Potencjalni klienci”:

<Group Id=”MA”>
          …
          <SubArea Id=”nav_leads” Entity=”lead” DescriptionResourceId=”Lead_SubArea_Description” />
          <SubArea Id=”Custom_SubArea” Url=”http://www.crmblog.pl“>
            <Titles>
              <Title LCID=”1045″ Title=”Polski tytuł”/>
              <Title LCID=”1033″ Title=”English title”/>
            </Titles>
          </SubArea>
…

4. Zapisujemy plik XML i importujemy go z powrotem do systemu, za pomocą “Importowania dostosowań”, analogicznie do mechanizmu eksportu.

5. Kiedy odświeżymy aplikację, możemy zobaczyć link do strony w wybranym przez nas miejscu:

Microsoft Dynamics CRM - SiteMap link

W skrócie, Customer to typ referencyjny wskazujący obiekt typu account albo contact. Dzięki zastosowaniu takiej klasy, możliwe jest np. tworzenie szans sprzedaży i wstawienie do pola “Potencjalny Klient” obiektu typu account (konto) lub contact (kontakt). Nie trzeba mieć więc dwóch różnych pól – jednego wykorzystywanego jeśli klient byłby kontaktem, a drugiego jeśli klient byłby kontem. Jeden z najbardziej popularnych przykładów wykorzystania typu Customer to właśnie pole customerid w szansie sprzedaży (opportunity). Pole to zawiera GUID konta lub kontaktu, ale nie tylko. Jak więc dowiedzieć się z jakim obiektem mamy do czynienia? Bardzo prosto – ponieważ typ Customer dziedzidzy po CrmReference, pozwala przechowywać nie tylko GUID, ale i nazwę oraz typ rekordu. Dlatego, żeby dowiedzieć się z jakim obiektem mamy do czynienia w przypadku customerid (lub wszędzie tam, gdzie jest relacja typu Customer), musimy sprawdzić wartość właściwości type:

Customer c = naszaSzansaSprzedazy.customerid;
string typObiektu = c.type;    // tutaj jest informacje o typie (account lub contact)
string guidObiektu = c.Value;    // tutaj jest GUID wskazywanego obiektu

Aby pobrać teraz dane o obiekcie wskazywanym przez customerid wystarczy, że użyjemy np. metody Retrieve, wykorzystując znaleziony typ i GUID obiektu:

_naszCRMService.Retrieve(typObiektu, guidObiektu, new AllColumns());

Należy pamiętać, że NIE ma możliwości konwertowania obiektów typu Customer  do np. konta (tak naprawdę można to osiągnąć wykorzystując wewnętrzną klasę SDK – Moniker, ale to nie tego typu konwersja). Tzn, że nie można zrobić czegoś takiego:

account acc = (account)naszaSzansaSprzedazy.customerid;    // to nie zadziala!

Ograniczenia typu Customer:

Podstawowe ograniczenie tego typu to brak możliwości tworzenia nowych relacji wiążących Customer z innymi encjami. Tylko obecne w systemie relacje (m.in. szansa sprzedaży -> Customer, sprawa -> Customer) mogą korzystać z tego typu. Dodatkowe ograniczenie to fakt, że nie można zobaczyć tego typu np. w widokach, bo nie jest to typ encji, jak account czy contact.

Egzamin “MB2-634 – Extending Microsoft Dynamics CRM 4.0″ został opublikowany dość niedawno, bo 16 października 2008. Według Microsoft’u ciągle jeszcze jest “in development”. Spodziewacie się pewnie kolejnej recenzji podobnej do opisu egzaminu “MB2-632 – Microsoft Dynamics CRM 4.0 Applications” znajdującej się tutaj. Na szczęście o MB2-634 można napisać trochę dobrego…

Przede wszystkim egzamin rzeczywiście porusza “życiowe” kwestie związane z wszelkiego rodzaju rozszerzaniem Dynamics CRM 4.0 – jest kilka pytań o web services, są pytania o plug-in’y, custom workflow activities, są pytania o JScript i client side development. Ogólnie egzamin zdaje się sprawdzać bardziej doświadczenie niż pamięć. I to jest ok. Zastanawia mnie jednak facscynacja autorów pytań “wielo-organizacyjnością” (multi-tenancy) CRM’a. Sporo pytań odnosi się wprost do kwestii programowania w środowisku wielu organizacji – od tego jak propagują się dostosowania po to jak korzystać z usług sieciowych w takim środowisku. Nie wiem czy to jest wiedza niezbędna, ale niech będzie.

Oczywiście, jak w każdym egzaminie, nie obyło się bez 3-5 pytań “z kosmosu”. I tych z rodzaju “wybierz 2 odpowiedzi” a odpowiedzi było 3 albo 4. I takich gdzie komuś zabrakło umiejętności pisania po angielsku. Ale 3-5 pytań to nie 35, jak w “CRM 4.0 Applications” . No i egzamin jest ciągle “in development”, więc można to wybaczyć.

Ogólnie egzamin do łatwych nie należy i nie polecam podchodzenia do niego bez doświadczenia w oprogramowywaniu Dynamics CRM 4.0.