機械翻訳について

アプリケーション・コンポーザの変更の診断レポートを表示する方法

構成分析レポートには、アプリケーション・コンポーザで行われたすべてのカスタム・アプリケーション変更の診断分析が表示されます。 レポートには、アプリケーションの実行時のスケーラビリティに影響を与える可能性がある、推奨されていないGroovy関連パターンがリストされます。 また、同じ修正アクションの上位レベルもリストされます。

最大5つのオブジェクトのレポートをHTML形式でダウンロードできます。

レポートを生成するには:

1. アクティブなサンドボックス・セッションにいることを確認します。

2. アプリケーション・コンポーザで、「共通設定」ペインで「Metadataマネージャ」を選択します。

3. 「構成アナライザ」セクションで、「構成分析レポートの生成」をクリックします。

4. 「構成分析レポートの生成」ダイアログで、診断レポートを生成するオブジェクトを選択します。

5. 「レポートの生成」をクリックします。

レポートの例を次に示します:

次の表に、アプリケーションのスケーラビリティに影響を与える可能性のあるGroovy関連のパターンを示します。

パターン	詳細
オブジェクト当たり10を超えるオブジェクト・トリガー	パフォーマンスを向上させるために、オブジェクトごとにトリガー数を10に最小化します。 レポートには、オブジェクト・トリガーが10個を超えるオブジェクトが、カウントおよび対応するオブジェクト・トリガー名とともにリストされます。
名前に特殊文字を含むオブジェクト関数	名前に特殊文字("、'、(、)、*、 / 、\\、#、@、+、!など)を含むオブジェクト関数は避けてください。 一部の文字はすでにアプリケーションによってブロックされていますが、オブジェクト関数の作成中または既存のオブジェクト関数名の変更中に許可されない文字もあります。 レポートには、このようなオブジェクト関数が特殊文字でリストされます。
アプリケーション・コンポーザに登録され、トリガーおよびオブジェクト関数から起動されるWebサービス	アプリケーション・コンポーザのwebサービスUIは、統合の目的で外部Webサービスをサポートするために使用されます。 内部で利用可能なwebサービスを登録して使用しないでください。 このレポートには、同じホストに内部的にデプロイされているすべてのwebサービスがリストされます。
検証ルールを直接使用するのではなく、トリガーからスローされた検証例外	トリガーは、通常、レコードの作成、更新、削除などの標準処理ロジック、またはフィールドへのプログラム的なデフォルト値の割当に使用されます。 検証の実行にトリガーを使用しないでください。 かわりに、フィールド・レベルまたはオブジェクト・レベルの検証ルールを使用します。 レポートには、検証例外をスローする全てのフィールドレベルおよびオブジェクトレベルのトリガーがリストされます。
複雑な算式フィールド	算式フィールドは、参照されるたびに評価されるため、単純な計算ロジックにのみ使用します。 複雑なロジックを使用する場合、追加の評価オーバーヘッドが原因でパフォーマンスに影響する可能性があります。 たとえば、式フィールドにexecuteQuery()を使用するとパフォーマンスに影響し、setAttribute()などの特定のAPIを使用すると、レコード・ロックの問題が発生する可能性があります。 レポートには、executeQuery()またはsetAttribute()を使用したすべての式フィールドがリストされます。
オブジェクト当たりのフィールド・タイプ数	パフォーマンス・ガイドラインでは、パフォーマンスを最適化するために、オブジェクトの長いテキスト属性の数を4に制限することをお薦めします。 また、動的選択リスト・フィールドの数を15に制限することをお薦めします。 レポートには、長いテキスト・フィールドと動的選択リスト・フィールドの数がそれぞれ推奨制限である4および15を超えるオブジェクトがリストされます。
ループ内のnewView() API	ビジネス・ロジックを実装する際は、問合せの数を最小限に抑えてください。 余分な問合せが発生する可能性があるため、ループ内でnewView()関数を起動しないでください。 このレポートには、任意のループ内でnewView() APIを使用したすべてのオカレンスがリストされます。
ランディング・ページの長いテキスト・フィールド	必要に応じて、長いテキスト・フィールドを作成および詳細ページに制限します。 長いテキスト・フィールドを使用すると、パフォーマンスに影響する可能性があります。 そのため、ランディング・ページに長いテキスト・フィールドを追加することは避けてください。 要約ページで複数のレコードの長いテキスト・フィールドを問い合せると、パフォーマンスに影響する可能性があります。
詳細ページ・レイアウト当たりのカスタム・サブタブ数	パフォーマンスを最適化するために、詳細ページ・レイアウト当たりのカスタム・サブタブの数を制限します。 レイアウト当たり10個を超えるカスタム・サブタブはありません。 カスタム・サブタブおよびカスタム・レイアウトは、ページを動的にする重要な機能です。 カスタム・レイアウトは、ロール、レコード・タイプ・フィールドまたは条件(Groovy式として実装)に基づいて異なるフィールド/タブのセットを表示する場合に作成します。 ただし、カスタム・サブタブおよびカスタム・レイアウトは、ビジネス・ユース・ケースをサポートするために使用する場合にのみ使用する必要があります。 カスタム・レイアウトでは多くの情報がメタデータに格納されるため、MDSのロード時間が長いため、多くのレイアウトではランタイム・フローのパフォーマンスが低下する可能性があります。
setAttribute()がページに表示されるアクションおよびボタン	アクション、ボタンおよびリンクに使用されるGroovy関数内でsetAttribute() APIを使用しないでください。 アクション、ボタンおよびリンク用に記述されたGroovy式は、ページ・ライフ・サイクル中に複数回実行できます。 そのため、Groovyロジックを複数回実行しても安全であることを確認してください。 オブジェクト・レコードを更新するカスタム・ビジネス・ロジックを記述しないでください。このようなスクリプトを繰り返し実行するとエラーが発生する可能性があります。
オブジェクト当たりのオブジェクト・ワークフロー数	オブジェクト当たりのアクティブなワークフローの数を10未満に制限し、Groovy評価に軽量式を使用します。 オブジェクト・ワークフローの実行は非同期ですが、トリガー・アクション(挿入/更新)中に条件が評価され、イベントが公開されます。 その結果、複雑なGroovyロジックまたは多数のオブジェクト・ワークフローがアプリケーションのランタイム・パフォーマンスに影響する可能性があります。 したがって、オブジェクトごとにアクティブなオブジェクト・ワークフローの数を制限することが重要です。
フィールド更新アクションを持つオブジェクト・ワークフロー	パフォーマンスを最適化するためにフィールド更新アクションを回避します。 かわりに、トリガー内にアクションを組み込み、同期アクションとして処理できます。 フィールド更新オブジェクト・ワークフローは、実行スケジュールが必要な場合、またはビジネス・ユース・ケースでフィールド更新の非同期実行が必要な場合にのみ使用します。
setAttribute() APIを使用した検証ルール	パフォーマンスを最適化するために、オブジェクト内またはフィールド検証ルールGroovyスクリプト内の検証以外のビジネス・ロジックを実装しないでください。 検証スクリプトは検証にのみ使用してください。 たとえば、検証スクリプトでsetAttribute()値を使用しないでください。
オブジェクト当たりのレイアウト数	最適なパフォーマンスを得るには、カスタム・レイアウトの操作時に次のガイドラインに従ってください: カスタム・レイアウトの数を20以下に最小化します。 レイアウトを頻繁に作成し、後で非アクティブにすることは避けてください。 レイアウトを「非アクティブ」としてマークすると、UIからのみ非表示になります。 レイアウトを区別するためにGroovy式を使用しないでください。 常に、ロールや「レコード型」フィールドなどの他のオプションも考慮してください。
挿入前および更新前トリガーからのWebサービス起動	可能な場合は、webサービスに依存せずにビジネス・ロジックを実装してください。 同じロジックを非同期で実行できるかどうかを考えてみます。 Groovyロジックを非同期で実行できる場合、親トランザクション(オブジェクト・レコード作成)は、このGroovyの完了を待機しません。 かわりに、Groovyロジックは、UIパフォーマンスに影響を与えずにバックグラウンドで実行されます。 ただし、ビジネス要件に絶対に必要な場合は、次の点に注意してください: webサービス・コールが、コミット・ライフ・サイクルで可能なかぎり遅れている適切なタイミングで実行され、現在のトランザクションの検証が確実に渡されるようにします。 そうしないと、webサービス・コールが自動的にコミットされるため、データの不整合が発生する可能性があります。 また、Webサービスに関連するロジックについて、コミット後、削除後および変更後のDBトリガーを考慮してください。 webサービスを使用して、Groovyから直接アクセスできるビジネス・オブジェクトを操作することは避けてください。 データを同期するために外部webサービスを呼び出す更新前トリガーは、時間のかかるプロセスです。 コミット全体がwebサービス・レスポンスを待機する必要があり、合計ランタイム・パフォーマンスに影響します。 これをトリガーで実行するかわりに、レコードの更新時にGroovy式をコールして外部システムに同期するオブジェクト・ワークフローを記述できます。 この非同期のメソッドで外部システムとデータを同期できるため、UIのオーバーヘッドが軽減されます。
ループ内のWebサービス呼出し	ループ内でwebサービス・コールを使用しないでください。 絶対に必要なものか、ESSジョブとして非同期に実行できるか、または単純なGroovy更新として実行できるかを検討してください。
sendNotification()をコールするオブジェクト・ワークフロー	オブジェクト・ワークフローのコンテキストからadf.util.sendNotification() APIを使用しないでください。
ループ内のExecuteQuery API	可能なかぎりループ内でexecuteQuery()を使用することは避け、絶対に必要なかどうかを考慮してください。 はいの場合は、Groovyスクリプト作成のガイドラインに従って、バインド変数を使用してパフォーマンスを向上させる必要があります。
getEstimatedRowCountの前にExecuteQuery	getEstimatedRowCount() APIを使用している場合は、executeQuery()を使用しないでください。 行数を取得する必要がある場合は、getEstimatedRowCount() APIを使用します。 データベースから行数が返されます。 個別のexecuteQuery()実行は必要ありません。
動的レイアウト拡張式からコールされるExecuteQuery	動的レイアウトの拡張式でexecuteQuery()を使用した複雑なGroovy式の使用は避けてください。 ロールや「レコード型」フィールドなど、他のオプションは常に考慮してください。
選択した属性なしでExecuteQueryがコールされました	ビジネス・オブジェクト問合せを実行する場合は、結果からコードがアクセスするフィールドを指定することが重要です。 これには、ロジックで更新する予定のフィールドも含まれます。 これをプロアクティブに実行することで、アプリケーションには次の2つの利点があります: 必要なデータのみをデータベースから取り出します。 最初の参照で欠落しているデータを「フォルト・イン」する追加のシステム起動問合せを回避します。 これは、selectAttributesBeforeQuery APIを使用して実現できます。 これにより、Groovyスクリプトのパフォーマンスが向上します。 詳細は、『Groovy Scripting』ガイドの「必要な属性のみを明示的に選択」を参照してください。
オブジェクトごとの検索可能フィールドの数	検索可能なフィールドの数は100以下に制限してください。 検索可能なフィールドの数を減らすことで、リスト・ページのパフォーマンスへの影響を減らすことができます。 推奨される方法は、オブジェクトの検索を実行するためにユーザーが最も頻繁に必要になるフィールドを決定することです。 次に、新しいカスタム・フィールドを作成するときに、必要な検索フィールドでないかぎり、「検索可能」オプションをクリアします。 これにより、拡張検索を使用するたびに、検索可能な属性リストに移入する必要があることによるパフォーマンスへの影響が軽減されます。
SetAttribute APIをコールするフィールド更新可能な式	フィールド更新可能な式を使用する場合は、次のガイドラインに従ってください: 更新可能なGroovy式内でオブジェクト属性値を設定しないでください。 更新可能なGroovy式でオブジェクト関数を使用しないでください。 ユースケース要件が、実行時に属性の必須または更新可能なプロパティが変更されるという場合、条件で単純な式を使用することを検討してください。 ユースケース要件が単一のページで属性を読み取り専用にする場合、レイアウト・レベルのUIプロパティを使用できます。 属性の更新可能なプロパティが異なる機能フローで単一値を持つことができ、この値がTrueまたはFalseの場合は、式を使用しないでください。 代わりに、RequiredまたはUpdatableプロパティの絶対値を使用します。
更新可能および必須フィールド・レベル式のグローバル関数	更新可能または必須のフィールド式を使用する場合は、次のガイドラインに従ってください: 必要なGroovy式または更新可能なGroovy式で、可能なかぎりグローバル関数の呼出しを使用しないでください ユースケース要件が、実行時に属性の必須または更新可能なプロパティが変更されるという場合、条件で単純な式を使用することを検討してください。