ヘッダーをスキップ
Oracle® Fusion Middleware Oracle Enterprise Repository統合ガイド
11g リリース1(11.1.1.7)
B72433-01
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

5 コード・コンプライアンス・インスペクタとの統合

この章では、概要について説明し、Oracle Enterprise Repository (OER)用にコード・コンプライアンス・インスペクタ(CCI)を使用する方法について解説します。

この章では、次の項目について説明します。

5.1 概要

オープンな標準を遵守し、正しいコーディングを実行することは、SOAガバナンスの重要な原則です。コード・コンプライアンス・インスペクタは、SOAスイート・プロジェクトとOracle Application Integration Architecture (AIA)統合プロジェクトの両方で正しいコーディングが行われているかどうかをチェックするツールです。

OER用のCCIには、2つのコマンドライン・ユーティリティがあります。1つは、HTMLコンプライアンス・レポート・ファイルを作成し、もう1つは結果をリポジトリに対して同期します。これにより、ユーザーはOERコンソールからレポートにアクセスできるようになります。

コンプライアンス・データをOERに統合すると、コンポジットがリポジトリ・レポートおよび個々のアセット・メタデータに準拠しているかどうかについての情報がユーザーに提供されます。これにより、次のようなことが可能になります。

AIAユーザーは、コマンドラインからCCIを起動でき、JDeveloperで使用できます。JDeveloperの拡張機能を使用すると、開発者はリポジトリにチェックインする前に、継続的に作業内容のコンプライアンスを確認できます。

コンポジットを開発し、コンプライアンスを確認するためのJDeveloper拡張機能の使用の詳細は、Oracle Fusion Middlewareインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドfor Oracle Application Integration Architecture Foundation Packのコード・コンプライアンス・インスペクタの使用に関する項を参照してください。

CCIは、Web Services Interoperability Organization Basic Profile (WS-I BP)、および設計の一貫性、正しいコーディングとドキュメントをチェックするためのAIA統合開発者のガイドラインに基づいた事前定義済のアサーションのセットとともに提供されます。CCIでは、コードを、オープンな標準とベスト・プラクティスに対して、準拠性、一貫性、または完全な一貫性があると評価します。

結果はコード・コンプライアンス・レポートに表示されます。これには、コンプライアンスのレベルや合格と不合格の割合が示され、優先度とポリシーで結果をグループ分けするグラフィカルな棒グラフが表示されます。結果には、上位10の違反コンポジットも記載されます。SOAスイート・プロジェクトの全体のコンプライアンス・スコアは、レポートのヘッダー部分に表示されます。

図5-1に、全体のコード・コンプライアンス・レポートの例を示します。このレポートは、OERの「レポート」ページを介してリンクされています。コンポジットをクリックすると、コンポジットの詳細を表示できます。OERの「アセット詳細」ページを使用すると、各コンポジットを個別に表示することもできます。さらに、レポート・ファイルをサーバーにポストし、同僚とコンプライアンスの結果を共有できます。

図5-1 全体のコード・コンプライアンス・レポート

この図については本文で説明しています。

5.1.1 提供されたカタログについて

コード・コンプライアンス・インスペクタはCCIの2つのポリシー・セットを提供します。次のカタログには、WS-I Basic Profileに対するコンプライアンスをチェックするために使用するポリシーとアサーションが含まれています。

  • AssertionsCatalog-WS-I-<version>.xml

  • Policies-WS-I-<version>.xml

次のカタログには、AIAの設計とコーディングのベスト・プラクティスに対するコンプライアンスをチェックするために使用するポリシーとアサーションが含まれています。

  • AssertionsCatalog-AIA-<version>.xml

  • Policies-AIA-<version>.xml

WS-Iカタログとポリシーは、すべての種類のSOAコンポジットで汎用的に使用するためのものです。AIAカタログとポリシーは、ライセンスを取得したOracle AIAも所有しているOERユーザー用です。アサーションとポリシーはこれらのXMLファイルに格納されています。

<version>プレースホルダは、アサーションとポリシーが存在するディレクトリを示します。提供されたカタログの名前に10.xまたは11.xが付いており、これが<version>に置き換わります。

表5-1に、提供されているWS-I BPアサーションを示します。これらの事前定義済のアサーションは、ComplianceInspector/configディレクトリに存在する、パッケージ化済アサーション・カタログのXMLファイルに表示できます。

表5-1 WS-I BP標準

アサーション 説明

SchemaImportUsedforXSDOnlyCheck

他の種類のXMLスキーマをインポートするために、WSDLインポート要素を使用しないでください。WSDLインポートはWSDLのみをインポートする必要があります。このチェックは、WS interoperability basic profile 1.0との互換性を確認するためのものです。

SchemaImportsOnlyInsideSchemaCheck

XMLスキーマのimport文は、types要素のxsd:schema要素内に存在する必要があります。

SchemaNodeOnlyInsideWsdlTypesCheck

XMLスキーマの要素は、types要素のxsd:types要素内に存在する必要があります。

SchemaTargetNamespaceExistCheck

xsd:schema要素が子要素としてxsd:importまたはxsd:annotation(あるいはその両方)を持たない場合、wsdl:types要素に含まれているすべてのxsd:schema要素には、有効でnull以外の値を持つtargetNamespace属性が必要です。

SchemaTargetNamespaceMatchingCheck

WSDLでは、定義内に異なるtargetNamespaceを持つWSDLをインポートできません。このアサーションは、inputDirにAIAMetaDataディレクトリが含まれていることを想定しています。

SchemaXSDFileRootSchemaCheck

XSDファイルは、xsd:importの場所にスキーマをルート・ノードとして持つXSDファイルをインポートする必要があります。このアサーションは、inputDirにAIAMetaDataディレクトリが含まれていることを想定しています。

UTFEncodingUsedinSchemaCheck

スキーマ定義では、UTF-8またはUTF-16エンコーディングを使用する必要があります。UTFエンコーディングはXMLの処理手順で指定できます。アサーションでは、処理手順にUTFが存在するかどうかを検索します。このチェックは、WS interoperability basic profile 1.0との互換性を確認するためのものです。

UTFEncodingUsedinWSDLCheck

WSDLの記述では、UTF-8またはUTF-16エンコーディングを使用する必要があります。UTFエンコーディングはXMLの処理手順で指定できます。アサーションでは、処理手順にUTFが存在するかどうかを検索します。このチェックは、WS interoperability basic profile 1.0との互換性を確認するためのものです。

WSDLDocumentationIsFirstChildCheck

wsdl:documentation要素は、wsdl:import、wsdl:part、wsdl:definitions、およびWSDL1.1仕様で参照されている要素の最初の子要素として存在することがあります。

WSDLFileRootDefinitionsCheck

WSDLは、wsdl:importの場所に定義をルート・ノードとして持つWSDLファイルをインポートする必要があります。このアサーションは、inputDirにAIAMetaDataディレクトリが含まれていることを想定しています。

WSDLImportLocationNotEmptyCheck

すべてのwsdl:import要素の場所属性は空にすることはできません。

WSDLImportNoRelativeURIInNSCheck

wsdl:importのネームスペース属性は相対URIにすることはできません。URIは、URI標準のとおり、絶対URIにする必要があります。このチェックは、WS interoperability basic profile 1.0との互換性を確認するためのものです。

WSDLImportOnlyPrecededByDocCheck

WSDLファイルで、すべてのWSDLインポート要素の前に、WSDLドキュメント要素を置く必要があります。このチェックは、WS interoperability basic profile 1.0との互換性を確認するためのものです。

WSDLImportUsedforWSDLOnlyCheck

他の種類のXMLスキーマをインポートするために、WSDLインポート要素を使用しないでください。WSDLインポートはWSDLのみをインポートする必要があります。このチェックは、WS interoperability basic profile 1.0との互換性を確認するためのものです。

WSDLImportsOnlyInsideDefinitionCheck

すべてのWSDLのimport文は、wsdl:definition要素内に存在する必要があります。

WSDLOperationMustHaveInputCheck

送信、レスポンスおよび通知タイプ操作はwsdl:portタイプ定義で使用できません。たとえば、出力メッセージは常に入力メッセージの後にある必要があります。

WSDLOperationNameMustBeUniqueCheck

すべてのwsdl:portType要素には、名前属性(overloading)用に個別の値を持つ操作が含まれている必要があります。

WSDLPartMustNotUseElementAndTypeCheck

wsdl:message要素は、同じwsdl:part要素でtypeおよびelement属性の両方を指定できません。

WSDLTargetNamespaceMatchingCheck

WSDLでは、定義内に異なるtargetNamespaceを持つ他のWSDLをインポートできません。このアサーションは、inputDirにAIAMetaDataディレクトリが含まれていることを想定しています。

WSDLTypesOnlyPrecededByDocAndImportCheck

WSDLファイルで、すべてのWSDLタイプ要素の前に、WSDLドキュメント要素またはWSDLインポート要素を置く必要があります。このチェックは、WS interoperability basic profile 1.0との互換性を確認するためのものです。

XMLversionUsageInSchemaCheck

XSDファイルはXMLバージョン1.0を使用する必要があります。XMLバージョンはXMLの処理手順で指定できます。アサーションでは、処理手順にバージョンが存在するかどうかを検索します。このチェックは、WS interoperability basic profile 1.0との互換性を確認するためのものです。

XMLversionUsageInWSDLCheck

WSDLファイルはXMLバージョン1.0を使用する必要があります。XMLバージョンはXMLの処理手順で指定できます。アサーションでは、処理手順にバージョンが存在するかどうかを検索します。このチェックは、WS interoperability basic profile 1.0との互換性を確認するためのものです。

OERおよびAIAの事前定義済のアサーション、ポリシーおよび優先度の詳細は、Oracle Fusion Middlewareインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドfor Oracle Application Integration Architecture Foundation Packの付録B「コード・コンプライアンス・インスペクタ: 新しい用語と使用可能なアサーション・エグゼキュータ」を参照してください。

より安全な方法でカスタム・ポリシーおよびアサーションを作成できます。詳細は、Oracle Fusion Middlewareインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドfor Oracle Application Integration Architecture Foundation Packのコード・コンプライアンス・インスペクタ用のカスタム・アサーションの記述に関する項を参照してください。

5.1.2 OERのためのCCIの実行 - 推奨手順

次の手順を順に実行することをお薦めします。手順1から3はオプションですが、よいコンプライアンス結果を得るためには、リポジトリに取り込む前に実行することをお薦めします。手順5および6は、事前に一度、実行できます。

  1. AIAユーザーの場合、JDeveloperでコンポジットを開発します。

    詳細は、Oracle Fusion Middlewareインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドfor Oracle Application Integration Architecture Foundation Packのコード・コンプライアンス・インスペクタの使用に関する項を参照してください。

  2. JDeveloperのCCI拡張機能を実行してコンプライアンスを確認します。

  3. JDeveloper内のコンプライアンスの問題を発見して修正し、CCIを再実行してコンプライアンスを確認します。

    コンプライアンスの問題の発見と修正の詳細は、Oracle Fusion Middlewareインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドfor Oracle Application Integration Architecture Foundation PackのJDeveloperのコード・コンプライアンス・インスペクタの実行に関する項を参照してください。

  4. コンプライアンス結果に満足したら、コンポジットを収集してOERアセットを作成します。

  5. cci-oerSynch.propertiesファイルを構成します。

    詳細は、5.2項「コンプライアンスのチェックおよびOERのレポート・データの同期」を参照してください。

  6. アーティファクト・ストアを構成します。

    詳細は、5.2.1項「CCIレポート・ファイルにアクセスするためのアーティファクト・ストアの使用」を参照してください。

  7. コマンドラインからコンプライアンス・チェックを実行して、HTMLレポート・ファイルを作成します。

    この時点で、レポートをレビューしたり、他の人がレビューできるようにレポートをポストしたりできます。

  8. OERコンプライアンス・メタデータおよびCCIレポート出力でコンプライアンスの問題(問題がある場合)を特定します。

  9. 準拠性のないアセットまたはアーティファクトで問題を発見し、修正します。

    1. 必要に応じて、JDeveloper拡張機能で修正します。

    2. JDeveloperでコンプライアンス・チェックを実行します。

    3. レポートの結果に満足した場合、10に進みます。レポートの結果に満足しない場合、9を実行します。

  10. CCIとOERの同期を再実行する前に、修正したアセットを再収集します。これを実行しないと、CCIデータが間違ったアセットと照合されることがあります。

  11. CCIとOERの同期を実行して、OERアセットをレポート・ファイルにリンクします。CCIレポートを収集およびポストした後に、これを実行する必要があることに注意してください。これを実行しないと、レポート・データはOERアセットと同期できなくなります。

    詳細は、5.2.3項「CCIとOERの同期の実行」を参照してください。

  12. レポート・サーバーにレポート・ファイルを配置します。CCIとOERの同期コマンドを実行する前に、レポートの場所プロパティ(compliance.report.web.root)がcci-oerSynch.propertiesファイル内で正しく指定されていることを確認します。

    詳細は、5.3.2項「サーバーへのレポート・ファイルのポスト」を参照してください。

5.2 コンプライアンスのチェックおよびOERのレポート・データの同期

CCIコマンドライン・ツールは、OERの<OER Oracle Home>/tools/solutions/<version>のComplianceInspector.zip内に配布されています。

設定手順は、次のとおりです。

  1. コンプライアンス・インスペクタのzipファイルを一時フォルダにコピーします。

  2. コンプライアンス・インスペクタのzipファイルを解凍します。

  3. ComplianceInspector/config/cci-oerSynch.propertiesにあるコンプライアンス・インスペクタのcci-oerSynch.propertiesファイルを構成します。

    プロパティ・ファイルによって、環境の静的な情報を設定できます。


注意:

このファイルを解凍すると、常に、プロパティ・ファイルはComplianceInspectorディレクトリに対して相対的な位置にあり、configの下に置かれています。このディレクトリの名前を変更できます。この場所をComplianceInspector_Homeと呼びます。

5.2.1 CCIレポート・ファイルにアクセスするためのアーティファクト・ストアの使用

OERでは、アセットに完全修飾されたURLが格納されている場合、サーバーやポート名の変更、またはパスに影響があるその他の変更が行われると、そのリンクやURLに問題が生じることがあります。OERのアーティファクト・ストアを使用して、1回の単純な変更で、アーティファクト・ストアを参照するすべてのURLを簡単に管理および変更します。

cci-oerSynch.propertiesファイルには、CCIレポート・ファイルに対する接頭辞として使用するURIパターンを指定するために使用するプロパティがあります。実際のhost/port/pathパターンではなく、OERのアーティファクト・ストアのURIパターンを使用する場合、OERのJSPページは、自動的にアーティファクト・ストア・パターンを実際のURLパターンに変換します。

アーティファクト・ストアを使用すると、サーバー間でレポートを移動できます。レポートが格納されている場所のパスを変更するためにアセット自体を変更する必要がありません。アーティファクト・ストア情報を更新するだけで、変更処理は完了です。アーティファクト・ストアを1回変更すると、そのストア情報を使用するすべてのアセットが修正されます。

これにより、次のことが可能になります。

  1. CCIレポートのアセット内での相対URLの使用

  2. アーティファクト・ストアの構成を使用するレポートへのプロキシ・アクセス

  3. ソース・コード管理(SCM)システム内で格納されるレポートのサポート

  4. SCMメカニズムを介してアクセスされるバージョニング済レポート

CCIとOERの同期時にアーティファクト・ストアを作成する手順:

  1. OER内で適切なタイプ(HTTPなど)のアーティファクト・ストアを作成します。

  2. アーティファクト・ストアに目的に合った名前を付けます(CCI-Reports-Production)。

  3. cci-oerSynch.propertiesファイル内のcompliance.report.web.rootプロパティの一部として、rep://<ARTIFACTSTORE-NAME>を使用します。

    1. 例: compliance.report.web.root=rep://CCI-Reports-Production/reports

    2. レポートには次のURLパターンが含まれます。

      rep://CCI-Reports-Production/reports/cci/AIADemo/reports/composites/AIADemoBatchJMSAdapter.html#hide_link

  4. CCIとOERの同期を実行して、コンプライアンス・レポート・リンクを作成または更新します。

アーティファクト・ストアの使用の詳細は、第1章「アーティファクト・ストアの構成」を参照してください。

5.2.2 checkComplianceコマンドの実行

checkComplianceコマンドはcci-oerSynch.propertiesファイルを使用してOERインスタンスのURLを取得し、コンポジットのアセット・タイプIDと接続する際に使用するユーザー名の両方を検索します。

次のスイッチを使用して、LinuxではcheckCompliance.shコマンドで、WindowsではcheckCompliance.batコマンドでCCIを起動します。

  • -inputDir {コンポジットが含まれるフォルダの絶対パス}

    これは、入力ディレクトリが存在する場所を指定する必須のスイッチです。-inputMetaFileスイッチを指定しない場合、これは必ずしもSOAスイート・プロジェクトを表しません。-inputMetaFileスイッチを指定すると、プロジェクトのルート・ディレクトリ(ComplianceInspector_Homeのプロジェクト・フォルダが含まれるソース・フォルダ)が指定されます。

  • -outputDir {コンプライアンス・レポートが生成される出力フォルダ}

    これは、出力レポートが格納される場所を指定するための必須のスイッチです。次に例を示します。

    コンポジットが/tmp/cci/composites/AIADemoにある場合

    出力ディレクトリは、/tmpです。

    CCIでは、生成したファイルは/tmp/AIADemoに置かれます。

  • -policiesFile {ポリシー・ファイル名}

    このオプションのスイッチを使用して、CCIが実行されるポリシー・ファイルを指定します。たとえば、Policies-WS-I_11.x.xmlなどです。ファイルは、ComplianceInspector/libまたはComplianceInspector/config (ツール・クラス・パス)の下にあるか、compliance.policy.engine.jarに組み込まれています。

  • -policy {ポリシー名}

    これは、実行するポリシーを指定するためのオプションのスイッチです。指定しない場合、Policies.xmlのデフォルト・ポリシーが実行されます。

  • -assertion {アサーション名}

    このオプションのスイッチを使用して、CCIが実行されるアサーションを指定します。これは、定義済の特定のアサーション用のツールを実行します。たとえば、ABCSTargetNameSpacesCheckなどです。

  • -inputMetaFile {SOAスイート・プロジェクトのメタファイルの絶対パス}

    特定のSOAスイート・プロジェクトに対してレポートを実行する場合に、このオプションのスイッチを使用します。入力メタファイルには、出力結果がSOAスイート・プロジェクト固有になるように、コード・コンプライアンス・インスペクタがスキャンする必要がある、特定のディレクトリを指すパスが含まれています。このファイルには、指定されたSOAスイート・プロジェクトで使用されるすべてのサービスの名前が含まれています。このオプションを指定すると、入力メタファイルにこのルートに対する相対ディレクトリ・パスが含まれるので、-inputDirスイッチはプロジェクトのルート・ディレクトリを指します。次に、いくつかの例を示します。

    -inputMetaFile <ファイルのディレクトリ・パス>/GenerateScriptInput.xml

    -inputMetaFile <ファイルのディレクトリ・パス>/MyPIPDP.xml

  • -inputMetaFile ALL

    すべてのSOAスイート・プロジェクトに対してレポートを実行する場合に、このオプションのスイッチを使用します。このオプションを指定すると、入力メタファイルにこのルートに対する相対ディレクトリ・パスが含まれるので、-inputDirスイッチはプロジェクトのルート・ディレクトリを指します。

  • -version

    -versionフラグでは、使用しているCCI(CCIビルドの日時)のバージョン。これは、バージョン情報を示すオプションの引数です。

例

次に、コマンドラインからコード・コンプライアンス・インスペクタを起動する例を示します。

  • Windows: checkCompliance.bat -inputDir D:\composites\demo -outputDir D:\ComplianceOut

  • Linux: checkCompliance.sh -inputDir /composites/demo -outputDir /ComplianceOut

5.2.3 CCIとOERの同期の実行

CCIとOERの同期では、cci-oerSynch.propertiesファイルを使用し、コマンドライン・パラメータを補完して渡されます。これは、cci-oerSynch.propertiesファイルからすべてのプロパティを取得し、これをプロパティ・ファイルで指定されたOERインスタンスと相互に動作する様々な操作で使用します。

コマンドラインでコンプライアンスのチェックを実行すると、HTMLレポートが作成され、他の人がレビューできるようにサーバー上に配置されます。CCIとOERの同期では、これらのHTMLページとOERが統合されるので、OERの「アセット詳細」ページから表示できます。CCIとOERの同期は、次の内容を実行するスクリプトです。

  • CCIで生成されたHTMLページを指すURLが含まれる、OERのすべてのコンポジットを更新します。

  • OERと同じホストでスクリプトが実行されている場合、コマンドラインの引数-reportLocationで指定されたディレクトリ全体をOERのレポート・フォルダにコピーします。異なるホストで実行されている場合、レポートがある場所のディレクトリをOERのレポート・フォルダにコピーできます。

CCIとOERの同期の実行

  1. OERをインストールしたマシンの詳細情報で、ComplianceInspector/configディレクトリに存在するcci-oerSynch.propertiesファイルを更新します。

  2. ComplianceInspector/binディレクトリに存在する、cci-oerSynch.batまたはcci-oerSynch.shを実行します。表5-2に、渡すことができるコマンドラインの引数のリストを示します。

表5-2 OER同期のコマンドライン引数

引数 タイプ 説明

-url <OERのWebサービスのURL>

オプション

OERのWebサービスのURL。

次に例を示します。

http://example.com:port/oer/services

-user <OERのユーザー名>

オプション

有効なOERのユーザー・ログイン。このユーザーは、アセットのインスタンスを更新する権限を持っている必要があります。

-pwd <指定したユーザー名のパスワード>

オプション

OERのユーザー・ログインのパスワード。

-reportLocation <CCIで生成された出力ディレクトリのパス>

必須

CCI HTMLコンプライアンス・レポートの場所。OERに統合するコンプライアンス・インスペクタ・ツールによって作成されます。


注意:

コマンドラインのオプションの引数を指定しない場合、値はcci-oerSynch.propertiesファイルから取得されます。コマンドラインの引数は、cci-oerSynch.propertiesファイルで指定したプロパティよりも優先されます。また、コマンドラインの引数でパスワードを指定しない場合、入力するように要求されます。

5.3 レポートの構成

コンプライアンス・レポートの構成後、認証済ユーザーはOERの「レポート」ページのリンクを使用して、これらのレポートを表示できます。さらに、表示アクセス権を持つユーザーは、個々のコンポジットをOERの「アセット詳細」ページで表示できます。

コンプライアンス・レポートを追加および構成する手順

  1. アプリケーション・サーバーを停止します。

  2. $OER_APP_HOME/oer-app/WEB-INF/config/reports/ComplianceReport.xmlファイルを編集します。

    次に、すぐに使用できるComplianceReport.xmlの例を示します。

    <?xml version="1.0" ?>
<reports>
    <report name="complianceReportDoc">
        <displayName>Compliance Report Documentation</displayName>
        <description>Documentation for setting up Compliance Reports.
        </description>
<externalLink>http://www.example.com/pls/topic/lookup?ctx=as111170&
id=OERIN851</externalLink>
    </report>
    <report name="complianceReport">
        <displayName>Compliance Report</displayName>
        <description>This is the index page for all technical compliance
reports.</description>
        <!-- update the host and port, according the your http enabled server
where you have hosted the compliance reports. Use the OER download servlet to
map the OER artifact store URL for browser consumption. Example:
<externalLink>http://server.example.com:7101/oer/com.flashline.cmee.
servlet.enterprisetab.Download?path=rep://INSTANCE/reports/cci/FPDemo/
index.html</externalLink> -->
  <externalLink>http://host.example.com/CCI/reports/index.html</externalLink>
    </report>
</reports>

  3. 要約されているSOAスイート・プロジェクトが1つしかない場合、complianceReportという名前の既存のレポートを変更して、手順9に進みます。

    • OERアーティファクト・ストアを使用してレポートの場所を参照している場合(これをお薦めします)、次のURLパターンをCustomReport.xmlファイルのexternalLink要素の一部として使用する必要があります。

      http://host.example.com:port/oer/com.flashline.cmee.servlet.enterprisetab.Download?path=rep://<ARTIFACTSTORENAME>/relative_path/index.html

      アーティファクト・ストアが示す正しいURLをユーザーに提供するために、URLをデコードして再フォーマットするダウンロード・サーブレットが必要です。OERアーティファクト・ストアを使用すると、OER管理者は、複数のアセットの再同期または変更によってこれらの詳細情報を更新しないで、レポート・サーバーのホスト名/ポートおよびパスを変更できます。

  4. 2つ以上のSOAスイート・プロジェクトが要約される場合、チェック・コンプライアンス・ツールで報告されるプロジェクト数分、レポート・セクションを複製します。

  5. 各レポート要素の名前属性を意味のある名前(一意にする必要があります)に更新します。

  6. SOAスイート・プロジェクトの要約ページに適切なdisplayName、説明および外部リンク要素を更新し、編集内容を保存します。

  7. $OER_APP_HOME/oer-app/WEB-INF/config/reports/custom.tocファイルを編集します。

    例:

    <?xml version="1.0" ?>
<reportSections>
        <reportSection name="Custom">
                <summary></summary>
                <description>Custom reports provide you with the flexibility
to customize reports for your organization or build new reports that align
your organizational metrics with your program goals.</description>
        </reportSection>
        <reportSection name="Compliance Reports">
                <summary></summary>
                <description>Code Compliance Inspector report for design-time
compliance information</description>
                <report name="complianceReportDoc"/>
                <report name="complianceReport"/>
    </reportSection>
</reportSections>

  8. CustomReport.xmlファイルに追加または変更したものと一致するように、レポート名要素を変更します。

  9. 図5-2に示すとおり、変更内容が反映されるようにOERアプリケーション・サーバーを再起動します。

図5-2 OERコンプライアンス・レポートのリンク

OERコンプライアンス・レポート

次に、ComplianceReport.xmlファイルの例を示します。ここでは、OERアーティファクト・ストアを使用して、コンプライアンス・レポートの要約ページに移動します。

<?xml version="1.0" ?>
<reports>
    <report name="complianceReport_project1">
        <displayName>Compliance Report (Project 1)</displayName>
        <description>This is the compliance report summary page for Composite
Project 1.</description>
        <!-- update the host and port, according the your http enabled server
where you have hosted the compliance reports -->
        <externalLink>http://host.example.com/CCI/reports/project1/index.html
</externalLink>
    </report>
    <report name="complianceReport_project2">
        <displayName>Compliance Report (Project 2)</displayName>
        <description>This is the compliance report summary page for Composite
Project 2.</description>
        <!-- update the host and port, according the your http enabled server
where you have hosted the compliance reports -->
        <externalLink>http://usclqaap04.us.example.com:8080/tr130107/com.flashline.cmee
.servlet.enterprisetab.Download?path=rep://INSTANCE/reports/cci/FPDemo/
index.html</externalLink>
    </report>
</reports>

この場所の実際のURLパスは、次のとおりです。

http://usclqaap04.example.com:8080/tr130107/reports/cci/FPDemo/index.html

前述のURLの斜体部分はレポート・ファイルの相対パスです。リポジトリ名の後ろが相対パスです。図5-3を参照してください。

図5-3 アーティファクト・ストアの編集ダイアログ・ボックス

アーティファクト・ストアの編集

5.3.1 レポートのレビューおよびコンプライアンスの問題の修正

OERでは、図5-4に示すように、コンプライアンス・レポートのリンクをクリックして、図5-5に示す、すべてのコンポジットの全体のレポートを表示します。

図5-4 コンプライアンス・レポートのリンク

この図については本文で説明しています。

図5-5 全体のコード・コンプライアンス・レポート

この図については本文で説明しています。

図5-5に示すように、違反しているコンポジットをクリックして、違反の詳細を表示し、コンプライアンスの問題を修正します。

図5-6に示すように、OERで個々のコンポジットのコンプライアンス情報を表示することもできます。

図5-6 技術的なコンプライアンス・レポートのレビュー

図5-6については周囲のテキストで説明しています。

「コンプライアンス・レポート」ボックスの「開く」リンクをクリックして、図5-7に示すような詳細な結果を表示します。

図5-7 コンポジットのコンプライアンス・レポート

この図については本文で説明しています。

コンプライアンスの問題の修正の詳細は、Oracle Fusion Middlewareインフラストラクチャ・コンポーネントとユーティリティ・ユーザーズ・ガイドfor Oracle Application Integration Architecture Foundation Packのコード・コンプライアンス・インスペクタの使用に関する項を参照してください。

5.3.2 サーバーへのレポート・ファイルのポスト

レポート・ファイルをサーバーにポストし、同僚とコンプライアンスの結果を共有できます。レポート・ファイルをHTTPサーバーにコピーし、他の人に場所を通知します。

  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引