COM+ CRM 作業程式
在一般作業中，在伺服器應用程式進程中執行的應用程式元件會藉由建立CRM背景工作角色來使用 COM+ CRM。 CRM 背景工作角色會實作專為其設計來執行之工作的 COM 介面。 應用程式元件必須在交易下執行，讓CRM背景工作角色繼承應用程式元件的交易。 CRM 背景工作角色一律需要交易。
若要存取 COM+ CRM，CRM 背景工作角色會先取得 ICrmLogControl 介面，這可讓 CRM 背景工作角色將記錄寫入長期記錄。 CRM 背景工作角色會藉由建立CRM Clerk元件來取得此介面。
接下來，CRM 背景工作角色必須告訴CRM職員其要使用的CRM補償器名稱。 其做法是呼叫 ICrmLogControl：：RegisterCompensator 方法。 呼叫此方法之後，CRM Compensator 會在交易完成時由CRM基礎結構建立。
在CRM背景工作角色註冊其CRM Compensator之後，可以使用ICrmLogControl將記錄寫入CRM記錄。 CRM 背景工作角色必須 事先寫入;也就是說，它必須將記錄寫入記錄，描述動作才能實際執行動作，以防在完成動作之後立即發生當機。 如果沒有這些預先寫入的記錄檔記錄，就無法更正動作。
此外，提前寫入表示 CRM Compensator 是接收復原記錄檔記錄的元件，必須處理寫入記錄檔記錄但實際上並未發生動作的情況。 CRM 補償器的動作必須是 等冪的;也就是說，它們應該能夠執行多次，但應該會導致相同的結果。 例如，將帳戶餘額設定為 $100 的值是等冪動作;將 $100 新增至帳戶餘額不是。
ICrmLogControl 介面提供下列兩種方法來寫入記錄檔記錄：
- WriteLogRecordVariants 可用來寫入建置為 Variants 集合的結構化記錄檔記錄。 它主要是在 Microsoft Visual Basic 中開發 CRM 時使用。
- WriteLogRecord 用於將非結構化記錄檔記錄寫入為位元組的 BLOB。 它主要是在 Microsoft Visual C++ 中開發 CRM 時使用。 由於 C 中的記錄結構通常是由一組可能散佈在記憶體中的標頭和欄位所組成， 因此 WriteLogRecord 方法會實作可減少數據複製的收集功能。
注意
您不應該在記錄檔記錄中的數據結構內用戶指標類型。 指標在復原階段不再有效，因為CRM補償器會在與寫入記錄記錄的CRM背景工作角色不同的進程中執行。 在記錄檔記錄中包含指標類型可能會導致應用程式在復原期間損毀或損毀。
這兩種寫入方法都會將記錄檔記錄寫入磁碟，但不保證記錄的持久性。 雖然允許延遲寫入在強制磁碟之前累積，但您可以改用 ICrmLogControl：：ForceLog 方法，以確保 CRM 完成的所有寫入在磁碟上都是永久性的，這對失敗復原很重要。
當CRM背景工作角色執行其動作並完成寫入並強制記錄到記錄檔時，它必須釋放ICrmLogControl。 當交易完成時（通常是因為呼叫 SetComplete 或 SetAbort 的應用程式元件），CRM 基礎結構會建立 CRM Compensator 元件，該元件會實作 ICrmCompensator 介面或 ICrmCompensatorVariants 介面。 這些介面可用來將非結構化 （Visual C++） 或結構化 （Visual Basic） 記錄傳遞至 CRM 補償器，以及交易結果通知。
CRM Compensator 會先收到交易完成準備階段的通知，而且可以投票給準備要求。 如果CRM補償器投票不，則不會收到任何進一步中止通知。 如果對準備要求投票贊成，則會收到認可或中止通知。 在用戶端中止的情況下，不會收到任何準備通知，只會中止通知。 CRM 補償器必須準備好處理所有這些案例，而且也必須處理CRM背景工作角色未成功寫入記錄的案例。 CRM Compensator 不得假設相同的 CRM 補償器實例會收到階段 1 （prepare） 和階段 2 （認可或中止） 通知，因為這些通知可能會因復原而中斷。
一般而言，CRM Compensator 會使用中止通知來反轉 CRM 背景工作角色所執行的動作。 如果CRM背景工作角色需要反轉其動作，可能會讓某些狀態可供使用。 該狀態可能會完全包含在記錄檔記錄中，如果不是，CRM 補償器必須在交易認可時清除該狀態。 這是CRM補償器收到認可通知的原因。 CRM Compensator 不會在 DTC 交易下執行。
CRM Compensator 可以使用 ICrmLogControl 來記錄新記錄，其會在建立時收到該記錄。 CRM 背景工作角色和CRM補償器也可以忘記他們撰寫的最後一筆記錄檔記錄，這可能需要避免不必要的復原。
相關主題