Udostępnij przez

Proces operacyjny COM+ CRM

W normalnej pracy składnik aplikacji uruchomiony w procesie aplikacji serwera używa modelu COM+ CRM poprzez utworzenie procesu roboczego CRM. Pracownik CRM implementuje interfejs COM specyficzny dla zadania, do którego jest przeznaczony. Składnik aplikacji musi być uruchomiony w ramach transakcji, aby pracownik CRM dziedziczył transakcję składnika aplikacji. Pracownicy CRM zawsze wymagają transakcji.

Aby uzyskać dostęp do modelu COM+ CRM, pracownik CRM najpierw uzyskuje interfejs ICrmLogControl, który umożliwia pracownikowi CRM zapisywanie rekordów w dzienniku trwałym. Pracownik CRM uzyskuje ten interfejs, tworząc komponent CRM.

Następnie pracownik CRM musi poinformować urzędnika CRM o nazwie kompensatora CRM, którego chce użyć. Robi to, wywołując metodę ICrmLogControl::RegisterCompensator. Po wywołaniu tej metody kompensator CRM jest tworzony przez infrastrukturę CRM po zakończeniu transakcji.

Po zarejestrowaniu kompensatora CRM, pracownik CRM może zapisywać rekordy w dzienniku CRM przy użyciu ICrmLogControl. Pracownik CRM musi napisać z wyprzedzeniem; oznacza to, że musi zapisać zapis w dzienniku opisującym czynność, zanim faktycznie ją wykona, w przypadku wystąpienia awarii natychmiast po zakończeniu czynności. Bez tych rekordów dziennika zapisu z wyprzedzeniem nie ma możliwości poprawienia czynności.

Ponadto zapisywanie z wyprzedzeniem oznacza, że kompensator CRM, który jest komponentem odbierającym rekordy dziennika w procesie odzyskiwania, musi zajmować się przypadkiem, w którym rekordy dziennika zostały zapisane, ale w rzeczywistości nie wystąpiła operacja. Akcje kompensatora CRM muszą być idempotentne; oznacza to, że powinny móc być wykonane więcej niż raz, ale powinny prowadzić do tego samego wyniku. Na przykład ustawienie salda konta na wartość 100 USD jest akcją idempotentną, natomiast dodanie 100 USD do salda konta już nie.

InterfejsICrmLogControludostępnia następujące dwie metody pisania rekordów dziennika:

  • WriteLogRecordVariants służy do zapisu ustrukturyzowanego rekordu dziennika, który jest tworzony jako kolekcja wariantów. Jest ona używana głównie podczas opracowywania crMs w programie Microsoft Visual Basic.
  • WriteLogRecord służy do zapisywania rekordu dziennika bez struktury jako BLOB bajtów. Jest ona używana przede wszystkim podczas tworzenia crMs w programie Microsoft Visual C++. Ponieważ struktury rekordów w języku C często składają się z zestawu nagłówków i pól, które mogą być rozproszone w pamięci, metoda WriteLogRecord implementuje możliwość zbierania, która zmniejsza kopiowanie danych.

Notatka

Nie należy stosować typów wskaźników w strukturach danych w rekordzie dziennika. Wskaźniki nie są już ważne w fazie odzyskiwania, ponieważ kompensator CRM działa w innym procesie niż CRM worker, który zapisał rekord dziennika. Dołączenie typów wskaźników w rekordzie dziennika może spowodować awarię lub uszkodzenie aplikacji podczas odzyskiwania.

 

Obie te metody zapisu zapisują rekord dziennika na dysku, ale nie gwarantują trwałości rekordu. Pozwalając na kumulację odłożonych zapisań przed ich wymuszeniem na dysku, można zwiększyć wydajność. Można jednak użyć metody ICrmLogControl::ForceLog, aby zagwarantować, że wszystkie zapisy wykonywane przez system CRM są trwałe na dysku, co jest ważne w przypadku odzyskiwania danych po awarii.

Gdy pracownik CRM ukończy swoje działania i zakończy zapisywanie oraz wymuszanie rekordów w dzienniku, musi zwolnić ICrmLogControl. Po zakończeniu transakcji (zazwyczaj ze względu na składnik aplikacji wywołujący SetComplete lub SetAbort), infrastruktura CRM tworzy składnik kompensatora CRM, który implementuje interfejs ICrmCompensator lub interfejs ICrmCompensatorVariants. Te interfejsy są używane do przekazywania rekordów bez struktury (Visual C++) lub ustrukturyzowanych (Visual Basic) do programu CRM Kompensator wraz z powiadomieniami o wyniku transakcji.

Kompensator CRM jest najpierw powiadamiany o przygotowawczej fazie zakończenia transakcji i może głosować albo tak, lub nie, w odpowiedzi na wniosek przygotowawczy. Jeśli kompensator CRM nie głosuje, nie otrzyma żadnych dalszych powiadomień przerwania. Jeśli zagłosuje na 'tak' w ramach żądania przygotowania, otrzymuje powiadomienie o zatwierdzeniu lub przerwaniu. W przypadku, gdy klient zostanie przerwany, nie są odbierane żadne powiadomienia dotyczące przygotowywania, tylko powiadomienia o przerwaniu. Kompensator CRM musi być przygotowany do obsługi wszystkich tych przypadków, a także musi obsługiwać przypadek, w którym żadne rekordy dziennika nie zostały pomyślnie zapisane przez pracownika CRM. Kompensator CRM nie może zakładać, że to samo wystąpienie kompensatora CRM otrzyma zarówno powiadomienie o fazie 1 (przygotowanie), jak i powiadomienie z fazy 2 (zatwierdzenie lub przerwanie), ponieważ mogą one zostać przerwane przez proces odzyskiwania.

Zazwyczaj kompensator CRM używa powiadomienia przerwania w celu cofnięcia działań wykonanych przez pracownika CRM. Pracownik CRM może pozostawić jakąś dostępną sytuację na wypadek, gdy będzie musiał cofnąć działanie. Ten stan może być w pełni zawarty w rekordach dziennika, a jeśli nie, kompensator CRM musi ten stan wyczyścić, jeśli transakcja zostanie zatwierdzona. Jest to powód, dla którego moduł kompensacyjny CRM otrzymuje powiadomienie o zatwierdzeniu. Kompensator CRM nie jest uruchamiany w ramach transakcji DTC.

Moduł kompensacyjny CRM może rejestrować nowe rekordy, jeśli jest to wymagane, używając ICrmLogControl, które otrzymuje podczas tworzenia. Zarówno pracownik CRM, jak i kompensator CRM mogą również zresetować ostatni zapis dziennika, co może być konieczne, aby uniknąć niepotrzebnego odzyskiwania.

Pojęcia dotyczące Kompensującego Menedżera Zasobów COM+

Uruchamianie i odzyskiwanie COM+ CRM

 

 

  • Last updated on