Oracle Siebel CRMイベントモデル（パート1）

この記事は、Oracle Siebel CRMに精通しており、3層アーキテクチャを十分に理解している人を対象としています。

システムを設計するときは、ビジネスコンポーネントレコードの作成または削除、アプレットのボタンのクリック、フィールドの編集、データの保存など、さまざまなユーザーアクションにどのように応答するかをよく理解することが重要です。 一方では顧客の要件を実装し、他方ではさらなるサポートとスケーリングのコストを増加させないアーキテクチャを正確に作成するには、Oracle Siebel CRMがユーザーまたはプロシージャが開始するすべてのイベントを処理する方法を知る必要があります。

一般に、各オブジェクト内のイベントの処理はいくつかの段階を経ます。

1. 分岐前
2. 標準ハンドラー
3. 分岐後

実際、分岐前と分岐後はスタブであり、その内部に開発者は独自のハンドラーを記述する、つまりイベント処理アルゴリズムを作成する機会があります。 このアルゴリズムが記述されているブランチの選択は、標準ハンドラが何をするかによって異なります。 この記事では、ビジネスコンポーネントレベルで最もよく使用される2つのイベント、 SetFieldValue （フィールド値の更新）とWriteRecord （データベースへの変更の保存）について詳しく説明します。

SetFieldValue-スクリプト

連絡先ビジネスコンポーネントとその[勤務先電話番号]フィールドについて考えます。 これは、ユーザーが編集できる共通の基本フィールドです。 現在、このフィールドの即時変更後プロパティは「Y」に設定されています。



このプロパティが正確に行うことは、後で説明します。

次に、 Contactビジネスコンポーネントレベルでこのようなスクリプトを検討します。

function BusComp_PreSetFieldValue (FieldName, FieldValue) { if (FieldName == "Work Phone #") { TheApplication().RaiseErrorText(": " + this.GetFieldValue("Work Phone #")); } return (ContinueOperation); } 

実際、ハンドラーは、標準のハンドラーの前に呼び出されるSetFieldValueイベントのPre-Branchブランチに書き込まれます。 ユーザーが[勤務先電話番号]フィールドを更新したい場合はどうなりますか？ この場合、システムはエラーを表示する必要があり、実際、標準ハンドラーを呼び出すことはできません。

新しい値を入力する前でした。



新しい値の入力：



別のフィールドに切り替えた後：



次のことが判明しました。

	初期段階では、3つのレベルすべてで、値は同じでした（フォーマット用に調整され、DTYPE_PHONEフィールドのタイプによって決定されます）。
	その後、ユーザーはアプレットレベルのテキストボックス「Work＃」に新しい値を入力しました。 この時点で、ビジネスコンポーネントレベルおよびテーブルレベルでは、値は変更されていません。
	ユーザーが「Work＃」テキストボックスからフォーカスを切り替えた後、アプレットはビジネスコンポーネントレベルでSetFieldValueイベントをトリガーしました。 この時点で、システムはBusComp_PreSetFieldValue関数内にスクリプトがあることを確認し、それを実行し始めました。 このスクリプトのフレームワーク内で、[Work Phone＃]フィールドの現在の値が読み取られ、TheApplication（）。RaiseErrorText（）関数を介してこの値が表示されました。 この関数は、標準ハンドラへのイベントの処理をそれぞれ終了し、システムは分岐後ブランチに到達しませんでした。 その結果、古い電話の値がエラーテキストに表示され、アプレットレベルでは新しい値も保存されません。

次に、同じ状況を考えて、このスクリプトをSetFieldValueイベントのポストブランチに転送します。

 function BusComp_SetFieldValue (FieldName) { if (FieldName == "Work Phone #") { TheApplication().RaiseErrorText(": " + this.GetFieldValue("Work Phone #")); } } 

すべて同じアクションを繰り返し、わずかに異なる結果が表示されます。



まず、エラーテキストに新しい値が表示されます。 第二に、ユーザーに表示されるエラーにもかかわらず、入力された値はそのまま残ります。

システムがPost Branchの実行に到達した場合、標準ハンドラーはエラーなしで実行を完了したと主張できます。 したがって、上記の例から、標準のSetFieldValueハンドラーはビジネスコンポーネントレベルでフィールド値を更新すると結論付けることができます。 テーブルレベルでは、この時点で何も変わっていないことに注意することが重要です。 これを確認するには、データベースに対して簡単なクエリを実行します。

上記の例から、SetFieldValueイベントのPre-Branchでビジネスコンポーネントフィールドにアクセスすると、システムは新しい値が入力される前に存在していたフィールドの現在の値を返します。 一方、SetFieldValueイベントの分岐後のビジネスコンポーネントフィールドにアクセスすると、システムはユーザーが入力した値を返します。

SetFieldValue-実行時イベント

上記のすべての原則は、分岐後および分岐前のハンドラーがスクリプトではなくランタイムイベントメカニズムによって起動された場合に機能します。

これを実証するために、この単純な検証ルール（管理-データ検証）を検討してください。



1が0に等しくなることはないため、システムがこのルールにアクセスするたびに、ユーザーはエラーメッセージを受け取り、その時点でトリガーされたイベントの処理を停止します。 Data Validation Managerは、別の記事に値する別の大きなトピックです。 ここでは、その設定の機能については説明しません。

このルールを実行するには、1つのアクションでアクションセット（管理-ランタイムイベント）を作成する必要があります。 このアクションのパラメーターを表に示します。

アクションタイプ	バスサービス
ビジネスサービス名	データ検証マネージャー
ビジネスサービス方法	検証する
ビジネスサービスのコンテキスト	「ルールセット名」、「SBL連絡先ダミー検証」

その結果、ハンドラーの準備が整い、対応するイベントにアタッチする必要があります。 これを行うには、イベントを作成します。



この場合、[電子メールアドレス]フィールドが更新されると、ContactビジネスコンポーネントのSetFieldValueイベントのPre-Branchブランチでハンドラーが起動されます。 条件式に注意を払うことが重要です。 そのフレームワーク内で、システムは[電子メールアドレス]フィールドから値を読み取り、この値の長さが3文字未満であることを確認する必要があります。 条件が満たされた場合のみ、ハンドラーが起動されます。

これで、個人の住所の変更にシステムがどのように対応するかを確認できます。

電子メールには、最初にsiebel@oracle.comが入力されます。



長さが3文字未満の新しい値を入力します。



別のフィールドに切り替えた後：



システムはエラーを表示しませんでした。 値は同じままです。 したがって、条件Len（[Email Address]）<3は合格しませんでした。 つまり、その時点でシステムは、[Email Address]フィールドの古い値（siebel@oracle.comと等しい）を考慮し、この値の長さが3を超えていることを認識し、ハンドラーを開始しませんでした。 エラーは発生せず、ビジネスコンポーネントフィールドは正常に更新されました。

このフィールドに古い値を入力した場合：



別のフィールドに移動します。



次に、最初にユーザーにエラーが表示され、次にフィールドの値が変更されません。 実際、一度に2つのエラーを受け取りました。1つ目はシステムエラー、2つ目はデータ検証のエラーです。 この場合、最初のものを取り除く方法を誰かが知っているなら、コメントに書いてください。 SetFieldValueイベントの標準ハンドラーの原理を理解している場合、結果は非常に論理的です。

これで、対象となるイベントに小さな変更を加えることができます。



この場合、ハンドラーはSetFieldValueイベントのポストブランチにバインドされます。 それ以外はすべてそのままですが、システムの動作は大幅に異なります。

これらの変更後、システムは「電子メール」テキストボックスに値siebel@oracle.comを入力しても「誓う」ことはありません。



ただし、3文字未満の値を入力しようとすると、次のことが起こります。



ユーザーにはエラーメッセージが表示されますが、値はビジネスコンポーネントフィールドに残ります。 条件式が新しく入力された値の長さを確認したため、エラーメッセージが表示されました。 ただし、エラーは分岐後、つまり標準ハンドラーの作業後に発生したため、入力した値はそのまま残りました。

書き込み記録

標準のSetFieldValueイベントハンドラが実際にアプレットレベルからビジネスコンポーネントレベルに値をドロップする場合、標準のWriteRecordハンドラはビジネスコンポーネントレベルからテーブルレベルにデータをドロップします。 つまり、対応するテーブルのデータが更新され、システムの他のユーザーが表示できるようになります。



SetFieldValueとWriteRecordの違いは、最初のケースではフィールドが個別に更新され、2番目のケースでは変更がすべてのフィールドのデータベースにすぐに送信されるという事実にあります。

開発者が独自のハンドラを記述して、それをWrite-RecordイベントのPre-Branchにアタッチすると、システムはデータベースにデータを書き込む前にすべてのアクションを実行します。 したがって、分岐前ブランチでエラーが発生した場合、データベース内のデータは変更されず、逆も同様です。分岐後ブランチでエラーが発生した場合、これは標準プロセッサに影響せず、データベース内のデータが更新されます。

この事実を知っていれば、ビジネスロジックをより有能に実装できます。 たとえば、プレブランチでは、さまざまなデータ検証手順をハングアップして、「曲線」情報がデータベースに入らないようにする必要があります。 通知手順をポストブランチに添付できます。 たとえば、アプリケーションが何らかの段階に進んだときに電子メールメッセージを送信するように構成します。

即時変更

「即時変更後」フィールドのプロパティは、「Y」に等しい場合、ユーザーが変更を行ってカーソルを別の場所に移動しようとしたときに、対応するフィールドのSetFieldValueイベントをトリガーする必要があることをシステムに伝えます。 設定されておらず、ほとんどのフィールドで設定されている場合、WriteRecordイベント処理の一部としてSetFieldValueイベントが発生します。 つまり、システムは、アプレットレベルからビジネスコンポーネントのレベルに転送されていないデータを調べ、各フィールドでSetFieldValueを起動し、その後でWriteRecordが起動します。

結論

Oracle Siebel CRMがイベントを処理する方法を考えると、Pre-Branch WriteRecordイベントでデータ検証を実行することをお勧めします。 この場合、ユーザーが作成したレコードを保存しようとすると、システムはどのフィールドでデータが特定のビジネスロジックに対応していないかを示します。 ユーザーは適切な調整を行い、再度すべてを保存しようとします。

ランタイムイベントはSetFieldValueイベントのPre-Branchにあるときに新しい値にアクセスできないため、各フィールドの値を確認するにはスクリプトが必要です。

上記のすべての原則は、ユーザーがインターフェイスを介して変更を行うときだけでなく、EAI統合が機能しているとき、またはスクリプトがSetFieldValueメソッドを直接起動するときにも適用されます。 例：bcContact.SetFieldValue（「電子メールアドレス」、「rrr@kk.ru」）。