Javaアプリケーションの更新および検証

次に、Oracle Java Cloud Service - SaaS Extensionで現在実行されているJava EEアプリケーションをOracle WebLogic Server for OCIで実行するための準備の概要を示します。

次のアプリケーション環境の変更に注意してください。2つの環境間で異なる互換性のあるバージョンを考慮して、アプリケーション・コードを更新する必要があります。各製品バージョンの相違点の詳細は、製品ドキュメントを参照してください。

Area	Oracle Java Cloud Service - SaaS Extension	Oracle WebLogic Server for OCI
Oracle Java Standard Edition	JDK 7	JDK 8
Oracle Java Enterprise Edition	Java EE 5	Java EE 7
Oracle WebLogic Server	WebLogic Server 11 g (10.3.6)	WebLogic Server 12 c
Oracle Fusion Middleware	Oracle Fusion Middleware 11 gリリース1 (11.1.1.7.1または11.1.1.9.1)	Oracle Fusion Middleware 12 cリリース2 (12.2.1.x)
Oracle JDeveloper	Oracle JDeveloper 11 g	Oracle JDeveloper 12 c

Oracle WebLogic Serverのアップグレードには、WebLogic (Java EE) Webサービス(JAX - RSおよびJAX - WS)のアップグレードが含まれることに注意してください。

必要な更新および検証ステップの実行

新しい環境のJavaアプリケーションを再度ファクタリングしてテストします。

次の各ステップでは、アプリケーションを更新および検証するために実行する必要があるプロセスを大まかに説明します。

既存のアプリケーションの保護されたページおよび匿名ページを識別します。通常、アプリケーション・ページは、web.xmlのCLIENT-CERT構成を使用して保護されます。
現在のアプリケーションで使用されているロールを識別します。ADFアプリケーションはjazn-data.xmlファイルを使用してロールを定義しますが、Java EEアプリケーションはアプリケーション・デプロイメント・ディスクリプタ内のアプリケーション・ロールおよびセキュリティ制約をweb.xmlファイルまたはアプリケーション・コードで指定できます。
既存のアプリケーションのWebサービス・セキュリティに使用されるポリシーを識別します。
SOAPクライアント・アプリケーションのクライアント・セキュリティ・ポリシーはアプリケーション・コードにあり、通常は次のものが含まれます。
- oracle/wss11_saml_token_with_message_protection_client_policy
- oracle/wss_saml_token_bearer_over_ssl_client_policy
RESTクライアント・アプリケーションのデフォルト・ポリシーは、oracle/http_saml20_token_bearer_over_ssl_client_policyです。
アプリケーションがFusionベースのOracleアプリケーションと統合されているかどうか、またはその方法を識別します。
一般的なパターンは次のとおりです。
- アプリケーション・コンポーザ、ページ統合またはページ・コンポーザ・ツールを使用したページまたはリンクの埋込み
- 構造ツールを使用したスプリングボード
- ナビゲータ構成を使用したナビゲーション
アプリケーションの依存性を識別します。
たとえば、次のいずれかの依存関係を識別します。
- ライブラリ
- SSL証明書
- Webサービス・セキュリティ証明書
- システム・プロパティ
- アプリケーションが予期するファイルシステム構造
- OPSS資格証明ストア内の資格証明エントリ
- 電子メール通知の使用方法
データベース・スキーマからデータをエクスポートし、Oracle Cloud Infrastructureの新しいデータベース・サービスにインポートします。Oracle Cloud Infrastructure Databaseシステムの場合、Oracle Application Express (APEX)をインストールし、アプリケーションを移行する必要があります。
詳細は、Oracle Database Cloud - Database Schema Serviceのドキュメントを参照してください。
Oracle WebLogic Server for OCIのドキュメントの説明に従って、Oracle Identity Cloud Serviceを使用してWeb層セキュリティを構成し、保護されたアプリケーション・リソースを更新します。
ロール認可を構成します。Oracle WebLogic Server for OCIのドキュメントの説明に従って、OPSSユーザーおよびグループAPIをOracle Identity Cloud Serviceと統合します。
Oracle JDeveloper 12 cをダウンロードおよびインストールします。このバージョンは、前に選択したOracle WebLogic Serverバージョンと連携しています。
Oracle JDeveloper 12 cで既存のJava EEアプリケーションを開きます。JDeveloperは、ADF依存性を含め、プロジェクトを12 cに自動的に移行します。詳細は、Oracle JDeveloperのドキュメントを確認してください。
Oracle WebLogic Server for OCIにアプリケーションをデプロイして検証します。
1. Oracle JDeveloperからWARまたはEARファイルを生成します。
2. Oracle WebLogic Server管理コンソールにログインします。
3. WARまたはEARファイルをWebLogicドメインのクラスタまたは管理対象サーバーにデプロイします。
ページ統合の場合は、特定のアプリケーションに応じて、アプリケーション・コンポーザまたはページ・コンポーザを使用して、Oracle FusionベースのアプリケーションのアプリケーションURLを更新します。
テスト環境または開発環境でテストを実行して、アプリケーションを検証します。
次の記事で説明するように、アプリケーションの検証を完了する前に、Web層のセキュリティおよびロール認可を構成する必要がある場合があります。

アプリケーションを本番環境にデプロイする前に、次の記事の説明に従って、Oracle Identity Cloud ServiceでWeb層のセキュリティおよびロール認可を構成します。

権限の問題の診断および解決

新しい環境では、一部のJavaアプリケーション・コードがAccessControlExceptionエラーをスローする場合があります。これらの権限の問題を診断および解決するには、ログで詳細を確認し、Oracle Enterprise Manager Fusion Middleware Controlを使用して権限付与を構成します。

権限を付与するようにcodeBaseを定義する場合(次の手順のステップ2 )、次の環境変数が役立ちます。

oracle.deployed.app.dir=/u01/data/domains/wls_domain/servers/wls_adminserver/tmp/_WL_user
oracle.deployed.app.ext=/-
common.components.home=/u01/app/oracle/middleware/oracle_common
domain.home=/u01/data/domains/wls_domain

権限の問題を診断して解決するには:

JPSロギングを有効にします。通常、デフォルトのロギング・レベルでは、 AccessControlExceptionエラーの原因を検出できません。ログでより細かい詳細を使用すると、認可されていない操作を実行している正確なコード・ベースを確認できます。
1. Oracle WebLogic Server管理コンソールを開き、「ドメイン構造」ツリーで「環境」を開きます。「サーバー」を選択して、管理対象サーバー名をクリックします。
2. 「サーバーの起動」タブを選択し、「ロックして編集」をクリックして、引数リストの末尾に次の引数を追加します。
```
-Djps.auth.debug=true
Djps.auth.debug.verbose=true
```
3. 「保存」をクリックし、「変更のアクティブ化」をクリックします。次に、管理対象サーバーを再起動します。
4. AccessControlExceptionの原因となっているユースケースをレプリケートしてから、管理対象サーバーの.outログ・ファイルでログに記録されているエントリを検索します。文字列FAILEDを検索します。次に例を示します。
```
[OpsAuth] Check Permission
	  PolicyContext:        [oauth-client]
	  Resource/Target:      [context=SYSTEM,mapName=user.public.map,keyName=SaaSSystemAccount]
	  Action:	        [read]
	  Permission Class:     [oracle.security.jps.service.credstore.CredentialAccessPermission]
	  Result:	        [FAILED]
	  Evaluater:	     [ACC]
	  Failed ProtectionDomain:ClassLoader-weblogic.utils.classloaders.GenericClassLoader@5Da796tt...
```
  PolicyContext、Resource/Target、ActionおよびPermission Classが、例外に示されているものと一致していることを確認します。
5. 前のステップでログ・スニペットのすぐ下に表示されたCodeSourceブロックを確認します。リストされているファイルは、欠落している権限でコードを実行するjarです。次に例を示します。
```
CodeSource-file:/u01/data/domains/wls_domain/servers/wls_server_1/tmp/_WL_user/oauth-client/kk4bjg/lib/PublicReportServiceWSClient-1.0.11.jar
```
このコード・ベースにパーミッションを付与します。これは、WLSTコマンド行ツールまたはOracle Enterprise Manager Fusion Middleware Controlを使用して実行できます。次のステップは、Oracle Enterprise Managerを使用して権限を付与する方法を示しています。
WLSTの使用方法の詳細は、My Oracle Supportにログインし、記事Doc ID 1327577.1を検索してください。
1. Oracle Enterprise Manager Fusion Middleware Controlにログインし、「WebLogicドメイン」ドロップダウン・メニューから「セキュリティ」、「システム・ポリシー」の順に選択します。「新規セキュリティ権限の作成」をクリックします。
2. 「システム権限の作成」ページの「CodeBase」の下で、ログ・ファイルにあるcodeSourceファイルを追加します。
  実際のファイル・パスを使用しないように、環境変数を置き換えます。たとえば、変数 oracle.deployed.app.dirは、前のステップのログ・エラーJARファイルの例で指定されたサンプル・ファイル・パスの_WL_userフォルダを指します。環境変数oracle.deployed.app.extを使用して、現在のパスの下のすべてに権限を適用することもできます。
  次に例を示します。
```
file:${oracle.deployed.app.dir}/MassItem28B${oracle.deployed.app.ext}
```
3. 「追加」をクリックします。「新しい権限の詳細を入力するにはここを選択します」オプションを選択し、詳細を入力します。
  - 権限クラス: oracle.security.jps.service.credstore.CredentialAccessPermission
  - リソース名: context = SYSTEM, mapName = user.public.map, keyName = SaaSSystemAccount
  - 権限アクション: read
4. 「OK」をクリックします。情報を確認し、「OK」をクリックして変更を保存します。

権限を付与した後、通常、再起動は必要ありませんが、問題が引き続き発生する場合は、サーバーを再起動すると解決する可能性があります。あるアクセス拒否エラーを解決した後、別のcodeSourceで新しいエラーが表示されるようになりました。これは、より多くのJavaコードを実行できるためです。そのため、ログを確認し、新しい権限を別のjarファイルに付与し、すべての権限の問題を解決するまで複数回再テストするこのプロセスを繰り返す必要がある場合があります。