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! 🙂
Polski blog o Microsoft Dynamics 365 
Zastanawiam się jaki jest tak naprawdę sens wrzucania swoich stron do do katalogu CRM’a.
Tak czy owak wymagany jest dostęp do serwera, czyli instalacja „on premise”. Czemu nie utworzyć zwyczajnie osobnej aplikacji? Odpadają problemy z konfiguracją, możemy bez obaw dodawać wpisy do Web.config (np. żeby używać ASP.NET Ajax), nie ingerujemy w proces CRM’a.
Jakie są w takim razie korzyści? Wiadomo, że można tak robić, tylko pytanie po co?
Piszesz „mamy dostęp do kilku ciekawych informacji przekazywanych naszym stronom przez CRM”. O co konkretnie chodzi? Pewnie o czymś zwyczajnie nie wiem. Sporo danych uzyskujemy jednak zaznaczając „pass parameters” we właściwościach iFrame’u, miejsce „hostowania” strony nie mu tu żadnego znaczenia.
Pozdrawiam,
Łukasz
Hej,
Sens jest taki, że mamy np. dostęp do informacji o organizacji (GUID) i języku, jakiego używa aktualny użytkownik. Oczywiście wszystkie te informacje można pobrać w stronach „na zewnątrz”, ale po co?
Dodatkowo oczywiście stawianie strony „obok” często wiąże się z otwieraniem nowego portu, żeby nie dodawać nagłówka hosta (host header). A nie wszędzie jest to możliwe…
Przeciw umieszczaniu stron jest oczywiście to, że pojawiają się z nimi określone problemy, np. ViewState wspomniany w poście :).
Pozdrawiam,
Kuba
Sam sobie odpowiem 🙂
Widzę sens wtedy kiedy mamy dostęp do katalogu CRM, a nie mamy możliwości tworzenia nowych aplikacji. Czyli być może w niektórych przypadkach CRM’a hostowanego.
Ciekawi mnie jednak o co chodzi z tymi „ciekawymi informacjami”.