![]() |
|
ワークフローアクションの作成:統合イベントの作成ワークフロールールに対する[統合イベントの作成]アクションでは、ワークフロールールの条件を満たし、[統合イベントの作成]アクションで追跡されているフィールドの少なくとも1つで変更が検出された場合、自動的に1つ以上の統合キューに統合イベントを送信します。 [統合イベントの作成]アクションおよび[待機]アクションについて[統合イベントの作成]アクションを使用して、ワークフロールールをトリガーするイベントによってレコードに加えられた変更を取得する統合イベントを作成する場合は、ワークフロールールのアクションの順序として、[待機]アクションの前に[統合イベントの作成]アクションを設定する必要があります。ワークフロールールで[統合イベントの作成]アクションの前に[待機]アクションを実行すると、[統合イベントの作成]アクションでレコードに対する変更が検出されなくなります。[待機]アクションの待機期間が終了すると、ルールの残りのアクションが実行される前にレコードが再び読み取られ、ワークフロールールをトリガーしたイベントの前にレコードに記録されたフィールド値は保持されません。したがって、フィールドの以前の値と現在の値は同一と見なされ、[統合イベントの作成]アクションによって統合イベントは作成されません。これは、追跡対象のフィールドの変更が検出されないためです。 統合イベントのピックリスト値形式について統合イベントキューの設定状態に応じ、統合イベントの作成の原因になったアクションの実行ユーザーの言語、または言語独立コード(LIC)値で、統合イベントのピックリストフィールドの値が記録されます。統合イベントキューのピックリスト値形式の指定の詳細は、「統合イベントキューの作成」および「統合イベント設定の管理」を参照してください。 取引先レコードおよび担当者の住所レコードにおける[請求]、[出荷]および[プライマリ]フラグについて[取引先住所]レコードタイプの統合イベントでは、住所が取引先に指定された請求先住所または出荷先住所のいずれであるかを示す[請求]および[出荷]フラグを含めることができます。同様に、[担当者の住所]レコードタイプの統合イベントでは、住所が担当者のプライマリ住所かどうかを示す[プライマリ]フラグを含めることができます。ただし、[請求]、[出荷]および[プライマリ]フラグに対する変更は追跡できません。これは、フラグについて[常に含む]チェックボックスを選択した場合でも、これらのフラグに対する変更を使用して統合イベントの作成をトリガーすることはできないことを意味します。これらのフラグのいずれかを統合イベントに含め、そのフラグが変更の追跡対象であるフィールドと同時に変更された場合、追跡対象のフィールドに対する変更の結果として作成された統合イベントには、フラグの新しい値は表示されません。かわりに、統合イベントには更新実行前のフラグの値が表示されます。ただし、追跡対象のフィールドに対する変更の結果として次回統合イベントが作成されたとき、統合イベントには前回更新実行後のフラグフィールドの値が含められます。 たとえば、住所Aおよび住所Bという2つの住所が、Jane Smithという担当者にリンクしていると想定します。住所AはJane Smithのプライマリ住所です。次のように設定された[担当者の住所]レコードタイプに対するワークフローの[統合イベントの作成]アクションがあります。
ユーザーがJane Smithの担当者の住所レコードから住所Aの[アドレスタイプ]フィールドを更新し、住所Aの[プライマリ]チェックボックスを選択解除した場合、[アドレスタイプ]フィールドに対する変更の結果としてワークフローアクションにより作成された統合イベントには新規住所タイプが表示されますが、統合イベントの[プライマリ]フラグの値は、住所AがJane Smithのプライマリ住所であることを引き続き示します。ただし、次回担当者の住所レコードから住所Aの[アドレスタイプ]フィールドが変更され、変更の結果として統合イベントが作成されたとき、統合イベントの[プライマリ]フラグは、住所AがJane Smithのプライマリ住所でないことを示します。 注:1つのワークフロールールに対して、最大25個のアクションを作成できます。 次の手順では、[統合イベントの作成]アクションの作成方法について説明します。 作業前の準備。ここで説明する手順を実行するには、[データルールの管理 - ワークフロールールの管理]権限を含むユーザー役割が割り当てられている必要があります。役割への権限の追加については、「役割の追加」を参照してください。 [統合イベントの作成]アクションを作成するには
次の表では、統合イベント追跡の設定ページのフィールドについて説明します。
[変更を追跡]チェックボックスについてワークフロールールに対するトリガーイベントが[レコードが削除される前]、[親との関連付けの後]または[親との関連付け解除の後]である場合、[変更を追跡]チェックボックスは使用できません。また、ワークフロールールに対するトリガーイベントが[親との関連付けの後]または[親との関連付け解除の後]の場合、ページに表示されるフィールドのセットは、子レコードレベルのフィールドのセットとなります。統合イベントに含まれているフィールドセットは親レコードレベルでも設定できません。 [変更を追跡]チェックボックスが使用可能なワークフローアクションの場合、ワークフローアクションにより統合イベントが作成されるのは、[変更を追跡]チェックボックスが少なくとも1つのフィールドで選択されており、[変更を追跡]チェックボックスが選択されているフィールドのうち少なくとも1つにおいて変更が検出された場合のみです。統合イベントが作成されると、ワークフローアクションで[常に含む]チェックボックスが選択されているすべてのフィールドが統合イベントに含められます。 システムフィールドの例外ワークフロールールに対するトリガーイベントが[新規レコードが保存されたとき]以外である場合、次の1つ以上のシステムフィールドについて[変更を追跡]チェックボックスを選択し、他のフィールドについては[変更を追跡]チェックボックスを選択していないと、Oracle CRM On Demandでは統合イベントが生成されません。
統合イベントの詳細は、「統合イベントについて」を参照してください。 他のタイプのワークフローアクションの作成手順については、次のトピックを参照してください。
関連トピックワークフローの関連情報については、次のトピックを参照してください。 |
公開日 2017 年 9 月 | Copyright © 2005, 2017, Oracle. All rights reserved. Legal Notices. |