Oracle Application Server アップグレードおよび互換性ガイド 10g(10.1.4.0.1)for Microsoft Windows B31481-01 |
|
この章では、アップグレード後の手順(コンポーネント別)について説明します。この手順により、Infrastructureの10g(10.1.4.0.1)へのアップグレードが完了します。 この章の内容は、次のとおりです。
SSLを使用するように構成された分散OracleAS Identity Managementコンポーネントをアップグレードしている場合は、アップグレード後にOracleAS Single Sign-OnおよびOracle Delegated Administration ServicesでSSLを再度有効にする必要があります。詳細は、次の項を参照してください。
Oracle Internet DirectoryでSSLを有効にする必要はありません。これは、ソースOracleホームのOracle Internet DirectoryでSSLを使用していた場合、アップグレード処理によって、アップグレード先OracleホームのOracle Internet DirectoryでSSLが自動的に再度有効にされるためです。
OracleAS Single Sign-OnでSSLを有効にするには、『Oracle Application Server Single Sign-On管理者ガイド』の「SSLの有効化」に示す手順を使用します。
特に、『Oracle Application Server Single Sign-On管理者ガイド』のこの項で説明されている次の手順を実行する必要があります。
opmn.xml
構成ファイルの編集が含まれます。
ssocfg
ユーティリティを実行し、シングル・サインオンURLを変更します。
targets.xml
を更新し、SSL証明書を認識するように、Oracle Enterprise Manager Application Server Control を構成します。SSL構成処理におけるこの手順の詳細は、9.1.2.1項「Application Server ControlにおけるOracleAS Single Sign-OnおよびOracle Delegated Administration Servicesの監視の有効化」を参照してください。
mod_osso
を登録します。
この項では、Application Server Controlが、SSLを介してOracleAS Single Sign-OnおよびOracle Delegated Administration Servicesコンポーネントを監視できるようにする手順について説明します。
Application Server Control構成ファイル(targets.xml
)を変更し、Application Server Controlが、必要なOracleAS Single Sign-OnおよびOracle Delegated Administration ServicesのURLに接続できるようにします。
targets.xml
ファイルを検索し、テキスト・エディタで開きます。このファイルは、アップグレード先Oracleホームにあります。
DESTINATION_ORACLE_HOME¥sysman¥emd¥
targets.xml
ファイルで、次に示すOracle Delegated Administration Services要素を検索します。
<Target TYPE="oracle_das_server" ... > .... </Target>
oracle_das_server
要素内で、表9-1に示すプロパティをそれぞれの推奨値で更新します。
表9-1 targets.xml構成ファイルで変更するOracleAS Single Sign-OnおよびOracle Delegated Administration Servicesのプロパティ
<Target TYPE="oracle_sso_server" ... > .... </Target>
oracle_sso_server
要素内で、HTTPPort
およびHTTPProtocol
プロパティの値を編集します。OracleAS Single Sign-Onの物理ホストのポートおよびプロトコルを必ず入力してください。ロード・バランサの接続に使用するポートおよびプロトコルは使用しないでください。
targets.xml
ファイルを閉じます。
Application Server Controlが、SSL接続を介してOracleAS Single Sign-OnおよびOracle Delegated Administration Servicesを監視できるようにするために、Application Server Controlに適切なセキュリティ証明書へのアクセス権があることを確認します。
この手順を実行しないと、OracleAS Single Sign-OnおよびOracle Delegated Administration Servicesが起動され、実行中であっても、Application Server Controlには停止または使用不可と示されます。
この問題を解決するには、HTTPSをサポートするために使用した認証局を、Application Server Controlが認識できるようにする必要があります。 Application Server Controlによって認識される認証局のリストに、その認証局の証明書を追加する必要があります。
Application Server Controlを構成して認証局を認識させるには、次の手順を実行します。
ブラウザに「証明書」ダイアログ・ボックスが表示されます。ここには、このWebサイトで使用されている証明書についての説明が示されます。 他のブラウザでも、Webサイトの証明書の詳細を表示するための類似したメカニズムが提供されています。
sso_certificate.cer
など)で、その証明書をテキスト・ファイルに保存します。
証明書ファイルの内容は、例9-1に示す内容と同様です。
sso_certificate.cer
という名前を付けたファイル)を、OracleAS Portal中間層にコピーします。
orapki
ユーティリティで、Oracle Walletのmonwallet
を更新します。
DESTINATION_ORACLE_HOME¥bin¥orapki wallet add -wallet ORACLE_HOME¥sysman¥config¥monwallet -trusted_cert -cert certificate_location
パスワードを要求されたら、monwallet
Walletのパスワードを入力します。 デフォルトのパスワードはwelcomeです。
この例では、certificate_locationに、この手順の前半で保存してOracleAS Portal中間層にコピーした証明書が含まれるテキスト・ファイルへのフルパスを指定します。次に例を示します。
D:¥oracle¥sso_certificate.cer
Application Server Controlを再起動した後、Enterprise Managerによって認証局のリストへの追加が検出され、セキュアなApplication Server Control Consoleを使用して、OracleAS Portalメトリックを正常に監視できます。
-----BEGIN CERTIFICATE----- MIIDBzCCAnCgAwIBAgIQTs4NcImNY3JAs5edi/5RkTANBgk ... base64 certificate content ... ------END CERTIFICATE------
アップグレードされたOracleホームにOracle Delegated Administration Servicesも構成されている場合は、Oracle Delegated Administration ServicesのURLを再構成する必要があります。
Oracle Delegated Administration ServicesのURLを再構成するには、次の手順を実行します。
oidadmin
)を起動し、Oracle Internet Directoryに接続します。oidadmin
ツールは、アップグレード先Oracleホームの次のディレクトリにあります。
DESTINATION_ORACLE_HOME\bin\
SSLを介してディレクトリに接続する場合は、ディレクトリ・サーバーに接続するときに「SSL有効」チェック・ボックスを選択します。
cn=OperationURLs
エントリまで移動します。
Entry Management -> cn=OracleContext -> cn=Products -> cn=DAS -> cn=OperationURLs
cn=OperationURLs
エントリを選択してから、Oracle Directory Managerウィンドウの右側のペインにある「プロパティ」タブで、orcldasurl属性の場所を確認します。
orcldasurlbase
属性を変更します。
https://virtual_server_name:load_balancer_ssl_listen_port
Oracle Internet Directoryのアップグレードを完了するには、次のタスクを実行する必要があります。
リリース2(10.1.2)からは、証明書のハッシュ値を使用してOracle Internet Directoryにバインドできるようになりました。このハッシュ値を導入するには、リリース2(10.1.2)より前に発行されたユーザー証明書をディレクトリで更新する必要があります。
結果的に、10gリリース2(10.1.2)より前のリリースからアップグレードする場合、およびユーザー証明書をディレクトリでプロビジョニングする場合は、このアップグレード後の追加手順を実行する必要があります。
Oracle Internet Directory 10gリリース2(10.1.2)からアップグレードする場合、この手順は必要でないことに注意してください。
証明書のアップグレード・ツール(upgradecert.pl
)の実行方法の詳細は、『Oracle Internet Directory管理者ガイド』のLDIFおよびコマンドライン・ツールの構文に関する項を参照してください。
Oracle Internet Directoryのアップグレード時、ディレクトリ内のLDAPオブジェクトは、変更されるか、またはOracle Internet Directoryに追加されます。これらの更新には、アクセス制御情報が含まれる場合があります。
本番環境では、カスタマイズされたアクセス制御ポリシーがディレクトリ内での適用されます。 そのため、アップグレード処理では、ディレクトリで実装したカスタマイズ済の動作を維持するために、意図的にディレクトリ内の特定のエントリがそのまま残されます。
また、Oracleコンポーネントが正常に動作するためには、デフォルトでそのまま使用できるアクセス制御設定が必要な場合があります。そのため、Oracle Internet Directoryのアップグレード後、デフォルトでそのまま使用できるアクセス制御ポリシーと、実装済のカスタム・ポリシーの差異を分析する必要があります。このタスクを実行した結果、Oracleコンポーネントの要件を満たす、カスタマイズ済のアクセス制御ポリシーと、組織のアクセス制御ポリシーが実装されます。
カスタマイズ済のアクセス制御ポリシーを実装していない場合でも、アップグレード後は、ACLを新しいデフォルト値に手動で更新することをお薦めします。
次の例では、デフォルトのレルムDNとして「dc=acme, dc=com」を使用します。この例では、ディレクトリのACLポリシーを分析する場合に次の事項を考慮します。
そのまま使用できるアクセス制御ポリシーは、次のファイルで使用可能です。
$ORACLE_HOME¥ldap¥schema¥oid¥oidDefaultSubscriberConfig.sbs
$ORACLE_HOME¥ldap¥schema¥oid¥oidSubscriberCreateAuxDIT.sbs
デフォルトのACLポリシーは、『Oracle Internet Directory管理者ガイド』の第17章にある共通グループ属性を読み取るためのデフォルトの権限の項で説明されています。
9.0.xのノードを10g(10.1.4.0.1)にアップグレードし、このノードのレプリケーションを設定しようとすると、レプリケーション・サーバーが起動に失敗し、レプリケーションの設定自体が失敗する場合があります。 レプリケーションWalletパスワードの変更およびリセットについては、A.4.1項「各レプリカでのOracle Internet Directory WalletのレプリケーションDNのパスワードの変更」を参照してください。
別のコンピュータ上の別のOracleホームで、より古いリリース(9.0.2または9.0.4)のDirectory Integration Platformが動作しており、アップグレード対象のOracle Internet Directoryを使用している場合、そのOracle Directory Integration Platformを使い続けるには、Oracle Directory Integration Platformサーバーを再登録する必要があります。
Oracle Internet Directoryを10g(9.0.4)から10g(10.1.4.0.1)にアップグレードした後、一部のLDAP問合せのパフォーマンスが低下する場合があります。
この問題を解決するには、次の手順を実行します。これによって、Oracle Internet DirectoryサーバーをホスティングするOracle Database 10gデータベース内の一部のデータベース統計が更新されます。
sqlplus ods/<passwd> @%ORACLE_HOME%/ldap/admin/oidstats.sql
同様に、Oracle Internet Directoryのアップグレード前にOracle Internet Directoryをホスティングするデータベースがアップグレードされる環境で実行している場合は、データベースのアップグレード直後にデータベースに対して次のSQLコマンドを実行してデータベース統計を収集する必要があります。
exec dbms_stats.gather_schema_stats('ODS');
Oracle Internet Directoryを10g(9.0.4)から10g(10.1.4.0.1)にアップグレードすると、DSA構成エントリ内のすべての属性がデフォルト値にリセットされます。たとえば、次に示すとおりです。
cn=dsaconfig,cn=configsets,cn=oracle internet directory
このため、アップグレード前にこのエントリ内の属性を変更した場合は、アップグレード前にそれらの属性を対応する値に再構成する必要があります。
Oracle Internet Directoryを10g(9.0.4)から10g(10.1.4.0.1)にアップグレードすると、このアップグレード処理によって一部の索引が自動的に再作成されます。たとえば、EI_attrstore
索引はアップグレード時に自動的に再作成されます。
このため、アップグレード前にEI_attrstore
索引を再作成した場合は、アップグレード後に再度その索引を再作成する必要があります。 EI_attrstore
索引の再作成は、大きいグループ・エントリを検索する場合のパフォーマンスに関する推奨事項(『Oracle Internet Directory管理者ガイド』の大きいグループ・エントリの検索の最適化に関する項を参照)の一部です。10g(10.1.4.0.1)にアップグレードする前にこの手順を実行した場合は、アップグレード後に再度この手順を実行する必要があります。
Oracle Internet Directoryデータベース・アカウントODSSMを使用して、データベースにあるサーバーの管理性についての情報にアクセスします。 このアカウントは、10g(10.1.4.0.1)へのアップグレード中に作成され、ランダムに生成されたパスワードが指定されます。
このアカウントの資格証明(ランダムなパスワードを含む)は、Enterprise Managerファイルtargets.xml
のOracle Internet Directoryの部分に格納されます。
このアカウントのパスワードを変更できる唯一の方法は、SQLPLUSを使用することです。 oidpasswd
ツールを使用して、このパスワードを変更することはできません。 また、このパスワードはWalletに格納されません。 このパスワードをデータベースで変更した後に、targets.xml
ファイルでも変更する必要があります。 これを行うには、ユーザー・フィールドおよびパスワード・フィールドに新しい値を設定するか、またはoidemdpasswd
ツールを実行します。
OracleAS Single Sign-Onのアップグレードを完了するには、アップグレードされた構成に応じて、次の項で説明するタスクの実行が必要です。
Single Sign-Onサーバーの10g(9.0.4)または10gリリース2(10.1.2)中間層がカスタム構成であった場合(Oracle HTTP ServerがSSL用に構成されていたり、Oracle Application Server Single Sign-Onサーバーのデータベース・アクセス記述子がカスタム構成されていた場合など)、アップグレードされた10g(10.1.4.0.1)中間層も同様に再構成する必要があります。
OracleAS Portalを使用している場合に、SSL用に10gリリース2(10.1.2)中間層を再構成すると、Oracle Delegated Administration Servicesに使用するURLが最新でなくなる可能性があります。この問題を解決するには、ポータル・キャッシュのリフレッシュを実行します。これによって、関連するOracle Internet Directory情報は保持されます。
ページの「DASホスト名」フィールドが適切な値にリフレッシュされます。
10g(9.0.4)または10gリリース2(10.1.2)中間層がユーザー証明書または第三者機関の認証メカニズムを使用して認証するように構成されていた場合、10g(10.1.4.0.1)のOracleAS Single Sign-Onサーバーも同様に再構成する必要があります。
10g(9.0.4)または10gリリース2(10.1.2)のSingle Sign-Onサーバーでログイン、パスワードおよびサインオフのページをカスタマイズしていた場合、そのページを10g(10.1.4.0.1)の仕様に従って更新する必要があります。これは、アプリケーション・サービス・プロバイダのサポートを有効にし、デプロイのログイン・ページを更新して企業フィールドを有効にしていた場合も同様です。
Oracle Internet Directoryレプリケーションを使用してOracleAS Single Sign-Onレプリケーションも使用する場合、アップグレードされた10g(10.1.4.0.1)表を10g(9.0.4)Oracle Internet Directoryとともにレプリケーション・グループに追加します。レプリケーションにOracleAS Single Sign-On表を追加するには、次の手順を実行します。
%ORACLE_HOME%¥ldap¥admin
で、次のコマンドを実行します。
sqlplus repadmin/password@<mds connect id> @oidrssou.sql
10g(9.0.4)または10gリリース2(10.1.2)のOracleAS Single Sign-Onサーバーがデフォルトの中間層インストール以外の中間層を使用していた場合、中間層がアップグレードされたOracleAS Single Sign-Onサーバーを指し示すように構成する必要があります。
たとえば、10g(9.0.4)または 10gリリース2(10.1.2) OracleAS Single Sign-Onサーバー中間層でリバース・プロキシを構成していた場合、10g(10.1.4.0.1)のOracleAS Single Sign-Onサーバー中間層でも構成する必要があります。
Wireless Voice認証を10g(10.1.4.0.1)のOracleAS Single Sign-Onサーバーで使用する場合に機能しないときは、OracleAS Single Sign-Onサーバー・エントリがOracle Internet Directoryでベリファイア・サービス・グループのメンバーであること(cn=verifierServices,cn=Groups,cn=OracleContext
)を確認します。このメンバーであることが、Wireless Voice認証の要件です。メンバーであることを確認するには、次の手順を実行します。
ldapsearch -h host -p port -D "cn=orcladmin" -w password -b "cn=verifierServices, cn=Groups, cn=OracleContext" "objectclass=*"
例9-2に示すように、エントリでuniquemember
として表示されていれば、OracleAS Single Sign-Onサーバーはベリファイア・サービス・グループのメンバーです。
cn=verifierServices, cn=Groups,cn=OracleContext . . . uniquemember=orclApplication CommonName=ORASSO_SSOSERVER,cn=SSO,cn=Products,cn=OracleContext . . .
OracleAS Single Sign-Onのアップグレード時に言語を選択しなかった場合、またはアップグレード後に追加の言語をインストールする場合、次の手順に従って必要な言語をインストールできます。
copy repCA_CD¥portal¥admin¥plsql¥nlsres¥ctl¥lang¥*.* DESTINATION_ORACLE_ HOME¥sso¥nlsres¥ctl¥lang
この例では、lang
が言語コードです。たとえば、日本語の言語コードはja
です。
アップグレード後、OracleAS Single Sign-Onパートナ・アプリケーションの管理ページには、余分な、または使用されていないパートナ・アプリケーションが表示されます。
たとえば、2つのOracle Application Server Certificate Authority(OCA)パートナ・アプリケーションおよび2つのOracleAS Wirelessパートナ・アプリケーションが表示されます。
ポート4400を使用する10g(9.0.4) OCAは、削除してもかまいません。
関連項目:
パートナ・アプリケーションのリストからソース・コンポーネントを削除する手順については、10.2項「タスク2: OracleAS Identity ManagementのソースOracleホームの破棄」を参照してください。 |
OracleAS Wirelessパートナ・アプリケーションの場合は、アップグレード後、10g(9.0.4) HTTP Serverポートが使用されるように10gリリース2(10.1.2) Oracle HTTP Server構成が変更されます。このパートナ・アプリケーションは、有効ではないため削除できます。有効なOracleAS Wirelessパートナ・アプリケーションは、10g(9.0.4)環境に存在していた、アップグレード後のパートナ・アプリケーションです。
パートナ・アプリケーションのリストで、不要になったり、アップグレード済であるコンポーネントまたはアプリケーションを確認します。
関連項目:
アップグレード済のOracleAS Identity Managementインストールと表示されるパートナ・アプリケーションの削除については、10.2項「タスク2: OracleAS Identity ManagementのソースOracleホームの破棄」を参照してください。 |
次の項で、OracleAS Portalスキーマのアップグレードを完了する方法について説明します。
スクリプトが正常に実行された後、次の手順を実行して、アップグレードされたPortalインスタンスを使用する各中間層を起動します。
デフォルトでは、ポートレット・リポジトリはOracleAS Portalスキーマにインプレース・アップグレードされます。ポートレット・リポジトリ内の既存のページ、テンプレート、アイテムなどがアップグレードされ、新しいポートレットがリポジトリに追加されます。以前の設定が維持されるため、ページはアップグレード実行前と非常によく似ています。
リポジトリの外観を新しくインストールされたインスタンスの外観にするには、スクリプトを使用して、アップグレードされたポートレット・リポジトリを再作成します。スクリプトは、既存のポートレット・リポジトリを削除して、再作成します。スクリプトは、ポートレット・リポジトリ内のカスタマイズ、設定、スタイル、バナーなどを保持しない場合にのみ使用してください。
ポートレット・リポジトリを再作成するには、9.4.1項「アップグレードされたPortalインスタンスを使用するすべての中間層の起動」の説明に従って中間層を起動した後で、次の手順を実行します。
prrplc.sql
スクリプトが含まれています。
MRUA_CDROM_ROOT¥portal¥admin¥plsql¥upg¥common
prrplc.sql
スクリプトを実行します。
OracleAS Portal Repositoryのアップグレードでエラーが発生しなかった場合、アップグレードされたPortalにアクセスできます。ブラウザを開き、次のURLに移動します。
http://host.domain:port/pls/portal_DAD
次に例を示します。
http://portalhost42.acme.com:7777/pls/portal
欠落したOracle Text索引がOracleAS Portalのアップグレード処理中に作成されますが、移入は行われません。移入には非常に長い時間がかかる場合があるためです。新しい索引は、アップグレードの完了後、次の同期ジョブのスケジューリング時に移入されます。
アップグレード(バックアップ用)およびOracle Text索引の同期ジョブの起動後、データベースを停止する必要がある場合は、同期プロセスに対する次の停止コマンドの影響を考慮してください。
索引付けジョブはすぐに停止され、ロールバックされます。
索引付けジョブ全体が終了してから、データベースが停止します。
データベースが停止する前に、現在の索引の同期を終了できます。同期が必要な索引がある場合でも、次の索引の同期は開始されません。
10gリリース2(10.1.2)より前のOracleAS Portalでは、InfrastructureおよびApplication Server中間層が別々のホストまたはプロトコルに分割されていた場合、ユーザーおよびグループLOVは、JavaScriptのオリジナル・サーバー・セキュリティ・ポリシーに対応するように構成する必要がありました。JavaScriptエラーが発生する原因は、OracleAS PortalとDelegated Administration Services(DAS)が別々のドメインにあることでした。
この問題には次の2つの解決方法がありました。
OracleAS Portal 10gリリース2(10.1.2)では、LOVの実装はコールバック方式をサポートするように変更され、ドメイン間の問題が解消され、前述の構成手順は不要になりました。ただし、このコールバック方式では、ドメイン間でのLOVの使用をサポートするために、DAS環境に対応するパッチが必要になります。
コールバック方式は、DAS 10g(9.0.4)以上でサポートされています。DASリリース2(9.0.2.3)を使用している場合は、パッチ3278638を適用するとコールバックをサポートできます。
ご使用の環境に適切なDASリリースがインストールされ、前述の構成オプションを実装していない場合は、個別のホストでLOVをサポートするためにOracleAS Portalで追加の構成手順を実行する必要はありません。ただし、前述の構成オプションを使用した場合は、その手順を削除する必要があります。手順は次のとおりです。
ログイン・ポートレットがカスタマイズされている場合は、このリリースで動作するように更新する必要があります。以前のリリースでは、ユーザー証明書はOracleAS Portalのwwptl_login.login_url
プロシージャに渡されていました。今回のリリースでは、ユーザー証明書はOracleAS Single Sign-Onのwwsso_app_admin.ls_login
プロシージャに渡される必要があります。OracleMetaLinkのNote 290445.1
に記載されている手順に従って、カスタマイズされたログイン・ポートレットがwwsso_app_admin.ls_login
を使用するように更新します。
OracleAS Portalのパフォーマンス・レポートを生成するには、一連のSQLスクリプトを使用する必要があります。それらのスクリプトは、OracleAS Portalのログ・ファイルをデータベース表にロードし、その情報に基づいてレポートを作成するために使用されます。それらのスクリプトは、次のディレクトリにあります。
ORACLE_HOME¥portal¥admin¥plsql¥perf
すでにパフォーマンス・レポート・スクリプトを使用している場合は、OracleAS Portalリリース2(10.1.2.0.2)にアップグレードした後、次のファイルの新しいコピーを実行する必要があります。
ORACLE_HOME¥portal¥admin¥plsql¥perf¥install¥update.sql
これは、Repositoryのリクエストに新しいURL形式を対応させ、新しいデータの収集を可能にするためです。これを行わないと、スクリプトが機能しません。
それらのスクリプトを使用してOracleAS Portalのパフォーマンスを監視する方法については、スクリプトのサブディレクトリにある次のファイルを参照してください。
ORACLE_HOME¥portal¥admin¥plsql¥perf¥scripts¥README.html
次の項で、Oracle Application Server Wirelessのアップグレードを完了するために実行する必要があるタスクについて説明します。
10g(10.1.4.0.1)では、Oracle Internet Directoryは、ユーザー属性に対する一意性制約を自動的に設定しません。orclUserV2
オブジェクト・クラスのorclWirelessAccountNumber
属性に対して一意性制約が設定されていない場合、Wireless Voice認証は正しく機能しません。
中間層およびInfrastructureのアップグレードの完了後、次の手順を実行して一意性制約を設定します。
addAccountNumberUniqueConstraint.bat
を実行します。このスクリプトは、次のディレクトリにあります。
DESTINATION_ORACLE_HOME¥wireless¥bin
このスクリプトには、1つの引数(Oracleホームのフルパス)を指定します。たとえば、次に示すとおりです。
addAccountNumberUniqueConstraint.bat DESTINATION_ORACLE_HOME
Oracle Application Server 10g(10.1.4.0.1)では、OracleAS Wirelessアプリケーション・エンティティは、デフォルトではユーザー・パスワードを変更できる権限を持っていません。そのため、ユーザーはインストール直後にOracleAS Wirelessサーバーに対するパスワードを変更できません。ただし、UserSecurityAdmins
権限をOracleAS Wirelessアプリケーション・エンティティに割り当てることによって、パスワードを変更する機能を有効にできます。
これを行うには、次のスクリプトを実行します。
DESTINATION_ORACLE_HOME¥wireless¥bin¥assignUserSecurityAdminsPrivilege.bat
構文は次のとおりです。
assignUserSecurityAdminsPrivilege.bat oid_super_user_dn user_password
この例の内容は、次のとおりです。
次に例を示します。
assignUserSecurityAdminsPrivilege.bat "cn=orcladmin" welcome1
HTTPアダプタを使用してWirelessサービスを構築する場合、指定する必要があるサービス・パラメータの1つにバックエンド・アプリケーションに対するURLがあります。場合によって、問合せパラメータをバックエンド・アプリケーションに送信することがあります。OracleAS Wirelessからこれを行うには、例9-3および例9-4に示すように2つの方法があります。 例9-3のパラメータ名はfn
、値はJoe
です。
http://localhost:7777/myapp/home.jsp?fn=Joe
問合せパラメータは、サービスの最初のページに対するリクエストにおいてのみ送信されます。最初のページから他のページへのリンクがある場合でも、そのページに対するリクエストにはパラメータが追加されません。
http://localhost:7777/myapp/home.jsp
URLを変更するかわりに、パラメータ名がfn
および値Joe
である追加サービス・パラメータを追加します。パラメータは最初のページだけでなくすべてのページに送信されます。さらに、そのパラメータはすべてのHTTPリダイレクト・リクエストでも送信されます。ただし、この方法では追加URLパラメータがOracleAS Single Sign-Onサーバーにも送信されるので、その場合にはサーバーからエラーが返されます。
エラーが発生するのは、バックエンド・アプリケーションがmod_ossoによって保護されている場合です。この場合、アプリケーションに対するリクエストは捕捉され、ユーザー認証のためにOracle SSOサーバーにリダイレクトされます。OracleAS Single Sign-Onサーバーには、送信されてくる問合せパラメータを制限するルールがあります。そのため、mod_ossoによって保護されているバックエンド・アプリケーションの場合、Wirelessサービスを変更し、例9-3のように問合せパラメータをURLに追加する必要があります。
|
Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|