今回の内容はDB操作前後の処理について、SalesforceとDynamicsで違いを見つつ、移行のための設定を確立していきます。
（本当は動作確認ができればよかったのですが、Dynamicsの試用期間切れのため確認ができず・・・）
SFDCのトリガ
Salesforceのトリガ機能は、オブジェクトに対して、InsertやUpdate操作が行われた際に、その操作の前後のタイミングでカスタムアクションを実行することができます。
このカスタムアクションはApexによって定義するため、コーンディングによってユーザ独自で柔軟に処理を記述することができます。
Salesforceのトリガには以下のような特徴があります。
- DB操作の前後(before,after)のタイミングで処理を実行できる
- 更新のトリガであれば、変更前レコードと変更後レコードを保持しているため、変更値を比較することができる
- beforeトリガ内では項目値の編集が可能だが、追加時のSalesforceIDは未採番の状態
- afterトリガ内ではSalesforceIDが採番済みのため、他レコードから自身のレコードを参照する操作が行える
- 複数レコードを一括でDB操作した場合は、1つのトリガ内で複数レコードが処理される（トリガが複数回起動する訳では無い）
- トリガ内でエラーが発生した場合、before,after関わらずDBへはコミットされない
思いついた範囲ではざっとこんなところです。
D365のプラグイン
一方のDynamicsでは、トリガに代わるものとして、プラグインという機能が作成されます。
トリガでできることはプラグインでも実施することができます。
ソースコードはC#で組まないといけないことや、プラグインの登録にDynamics 365 SDKのPluginRegistrationToolを使用するなど、システム構造こそ大分異なりますが、トリガで実現したことは、プラグインへと基本移行可能となります。
プラグイン登録手順については、手元にツールがなかったため割愛しますが、dllの作成であったり、ステップの登録であったりと何個か手順を踏むので慣れないうちは苦労するかと思います。
トリガからプラグインへの移行
では、SalesforceのトリガをDynamicsのプラグインへと移行するための設定について、考慮すべきは以下の2つのポイントとなります。
ステップのメッセージ
プラグイン登録時にステップを作成し、メッセージを設定します。
ここでいうメッセージとは、DB操作アクションに当たるもので、「Create」「Update」「Delete」といった対象のDB操作に対しての起動条件を指定するものです。
トリガでは、Insert、Update、Deleteで定義しているものをメッセージ内にそのまま置き換えて（InsertならCreateといった具合に）
もらえばOKです。
パイプラインステージの登録
Dynamicsではプラグイン登録の際にパイプラインステージを指定する必要があります。
パイプラインステージには以下の3つがあります。
■PreValidation
DB操作前の入力チェックを行うためのステージです。
ここで実施されるチェック処理がエラーの場合はポップアップメッセージを表示します。
■PreOperation
DB操作前の前処理を行うためのステージです。
PreValidationと違うところは、PreValidationは入力チェックを行い、PreOperationでは、項目編集などの操作を行います。
■PostOperation
DB操作後の後処理を行うステージです。
つまり、トリガのbeforeで実施されたものがPreValidationまたはPreOperationに、afterで実施されたものがPostOperationへと置き換えることができます。
同期/非同期の登録
また、プラグインは同期/非同期を指定して登録することができます。
処理に時間がかかるものは非同期として、それ以外は同期へ設定するのが一般的です。
Salesforceのトリガは同期として起動するため、移行する際は同期で設定することが基本線です。
ただし、トリガの処理の中で非同期処理(@futureアノテーションの使用)が実施されていた場合は、プラグインは非同期として動作させるようにしてください。
このように、設定方法こそ異なりますが、定義する内容自体は、トリガとプラグインでは大差はありませんので、置き換え方法がわかってしまえば移行は問題ないでしょう。
コメント