構成シナリオ
アプリケーション・インタフェースを調整して特定の要件を達成できるいくつかのシナリオを見てみましょう。
シナリオ1
ビジネス上、すべての変更オーダーの摘要フィールドは、ユーザーが入力した部門および事業所で自動的に更新される必要があります。
- 「設定および保守」作業領域で、次の場所に移動します。
- オファリング: 製品管理
- 機能領域: 変更オーダー
- タスク: 変更オーダーおよび新規品目要求ヘッダーの付加フレックスフィールドの管理
- 「部門」および「ロケーション」というタイトルのグローバル付加フレックスフィールドを作成します。
- アプリケーション・コンポーザで、「部門」および「ロケーション」フィールドの値を「説明」フィールドにコピーするスクリプトを作成します。
シナリオ2
ユーザーが品質処理を作成するときに、トリージ日が作成日の3日後に自動的に設定されるようにします。
解決策: アプリケーション・コンポーザ内で、Triage Dateという新しい日付フィールドを作成します。 作成日を取得して3日を追加するGroovyスクリプト式を使用して、Triage Dateのデフォルト値を定義します。 フィールドの更新を許可しない方法で式を定義します。
シナリオ 3
ビジネス・プロセスでは、ステータスが承認済であるアイデアごとに要件仕様を作成する必要があります。 また、要件仕様には、元のアイデアと同じ名前と摘要が必要です。
解答A: アプリケーション・コンポーザ内で、webサービスをコールするアイデアにボタンを追加できます。 webサービスは、要件仕様を作成し、アイデアの名前と説明を新しい要件仕様にコピーします。
解答B: アプリケーション・コンポーザ内で、アイデアが承認済ステータスに設定されるたびにwebサービスをコールするトリガーを作成できます。これにより、要件仕様が作成され、そのアイデアの名前と摘要が新しい要件仕様にコピーされます。
シナリオ 4
品質の問題では、ユーザーはサービス・タイプを選択し、次にサービス・センターを選択する必要があります。 サービス・センターの選択は、サービス・タイプの選択によって異なります。
解答A: アプリケーション・コンポーザ内で、サービス・タイプとサービス・センターに適切な値を持つ2つの固定選択リスト・フィールドを作成します。 サービス・タイプ・フィールドをサービス・センター・フィールドの親として指定し、必要に応じて値をマップして、ユーザーがサービス・タイプを選択すると、該当するサービス・センターのみが選択可能になるようにします。