この章では、Oracle WebCenter Content Serverとの通信のためのシン通信APIを提供するRemote Intradoc Client (RIDC)の初期化および使用方法について説明します。
Remote Intradoc Client (RIDC)は、Oracle Technology Network (OTN) (http://www.oracle.com/technetwork/index.html
)からダウンロードできます。
注意:
Remote Intradoc Client (RIDC) 12c (12.2.1.0.0以降)では、Java Runtime Environment (JRE) 1.8以上が必要です。最新のJava JRE/JDKは、Oracle Technology Network (OTN) (http://www.oracle.com/technetwork/index.html
)からダウンロードできます。
Remote Intradoc Client (RIDC)の詳細は、『Oracle Fusion Middleware Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンス』を参照してください。
この章の内容は次のとおりです。
Remote Intradoc Client (RIDC)は、コンテンツ・サーバーとの通信を行うためのシン通信APIです。その主な機能は、コンテンツ・サーバー・サービスをリモートで実行できるようにすることです。さらに、RIDCは、接続プーリング、セキュリティ、プロトコルの固有情報などを処理します。
主要機能
Remote Intradoc Client (RIDC)には次のような機能があります。
Remote Intradoc Client (RIDC) 12c (12.2.1.3.0)は、idc
、idcs
、http
、https
およびjax-ws
のプロトコルをサポートしています。
Intradoc: Intradocプロトコルは、Intradocソケット・ポート(通常は4444
)経由でコンテンツ・サーバーと通信します。このプロトコルは、クライアントとコンテンツ・サーバー間の信頼できる接続を必要とし、パスワード検証は行いません。このプロトコルを使用するクライアントには、RIDCコールを行う前に、必要な認証を自身で実行することが求められます。Intradoc通信は、SSL経由で実行するように構成することもできます。
HTTP: RIDCは、サポートされている次の3つのHTTPクライアント・パッケージのいずれかを使用して、コンテンツ・サーバーへのHTTP接続を作成できます。
Oracle HTTPClient
JDK HttpURLConnection
Intradocとは異なり、このプロトコルでは、各リクエストについて有効なユーザー名とパスワード認証資格証明が必要です。
詳細は、「HttpClientライブラリ」を参照してください。
JAX-WS: JAX-WSプロトコルは、適切に構成されたコンテンツ・サーバー・インスタンスとRIDCクライアントがインストールされているOracle WebCenter Content 12cでのみサポートされます。JAX-WSは、この環境の外部ではサポートされません。
JAX-WSの詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』のJAX-WS Webサービスの概要に関する項および『Oracle Fusion Middleware Oracle WebLogic Server JAX-WS Webサービスの高度な機能のプログラミング』のJAX-WS参照実装の使用に関する項を参照してください。また、Java Community Process Webサイト(http://www.jcp.org/)で、
Java API for XML Web Services (JAX-WS)のドキュメントも参照してください。
次の表に、サポートされているURLフォーマットを示します。
URL | 説明 |
---|---|
|
Intradocポートを使用します。ホスト名とポート番号のみが必要です。 |
|
Intradocポート経由でSSLを使用します。SSL証明書をロードするための追加の構成が必要です。 |
|
コンテンツ・サーバーCGIパスへのURLを指定します。 |
|
SSL over HTTPを使用します。SSL証明書をロードするための追加の構成が必要です。 |
|
JAX-WSプロトコルを使用してコンテンツ・サーバーに接続します。 |
次の表は、RIDCが各接続タイプをサポートするために必要な環境についてまとめたものです。
URL | 説明 |
---|---|
|
|
|
|
|
|
|
|
|
|
RIDCでは、HTTP接続を使用してコンテンツ・サーバー・インスタンスに添付されているWebサービスと通信するために、HTTPクライアント・ライブラリをサポートする必要があります。現在は、次の2つのライブラリがサポートされています。
Oracle HTTPClient
JDK HttpURLConnection
注意:
デフォルトでは、RIDCはHTTP/HTTPSプロトコル接続に、JVMの内部HTTPクライアント・ライブラリであるjava.net.HttpURLConnection
を使用します。JVMのHTTPクライアントを、 RIDCではhttpurlconnection
クライアントと呼んでいます。アプリケーションでRIDCのhttpurlconnection
クライアント実装を使用する場合、静的なjava.net
構成を変更またはオーバーライドする補助アプリケーション・コードまたはクラスパスのライブラリがあると、RIDCの動作に影響することがあります。たとえば、補助コードがjava.net.CookieHandler setDefault()
メソッドを使用して処理される静的なカスタムCookieを設定する場合、そのカスタムCookieハンドラは誤ってRIDC HTTP/HTTPS URL接続リクエストにCookieを送信することがあり、これはRIDC Cookie管理フレームワークで認識されないことがあります。言い換えれば、グローバルCookieストアからのCookieは誤ってUCMバックエンドに送信される場合があるということです。Oracle HttpClientをJavaコードでリクエストするには:
IdcClient idcClient = manager.createClient("http://localhost/cs/idcplg"); idcClient.getConfig ().setProperty ("http.library", "oracle");
JDeveloper拡張機能を使用して新規のRIDCアプリケーションを作成している場合は、「構成パラメータ」セクションで、適切な値( oracle
など)を指定したパラメータhttp.library
を接続に追加することができます。
JDeveloperでSite Studio for External Applications (SSXA)アプリケーションを使用している場合、ユーザー・インタフェースがないため、まず接続を作成し、その接続をテストせずに保存する必要があります。その後で、「接続」→「ディスクリプタ」→「ADF META-INF」ノードのconnections.xml
ファイルを開きます。connections.xml
ファイルにStringRefAddr
セクションを追加し、ファイルを保存します。
Connection Example in connections.xml <Reference name="sample" className="oracle.stellent.ridc.convenience.adf.mbeans.IdcConnection" xmlns=""> <Factory className= "oracle.stellent.ridc.convenience.adf.mbeans.IdcConnectionFactory"/> <RefAddresses> <StringRefAddr addrType="oracle.stellent.idc.connectionUrl"> <Contents>idc://<IPv6 Hostname>:4444</Contents> </StringRefAddr> <StringRefAddr addrType="oracle.stellent.idc.idcServerURL"> <Contents>http://localhost/cs/idcplg</Contents> </StringRefAddr> <StringRefAddr addrType="oracle.stellent.idc.http.library"> <Contents>oracle</Contents> </StringRefAddr> </RefAddresses> </Reference>
SSXAとRIDCの接続タイプは類似していることに注意してください。
JDeveloperでSSXA接続を使用する場合、connections.xml
ファイルのaddrType
値はoracle.stellent.idc.http.library
です。
JDeveloperでRIDC接続を使用する場合、connections.xml
ファイルのaddrType
値はoracle.stellent.ridc.http.library
です。
多数のアプリケーションがRIDCを使用して実行するアクションのパターンがいくつかあります。コンビニエンス・パッケージで、それらのパターンの一部が再利用のために提供されています。コンビニエンス・パッケージ領域内のクラスは、RIDCコードのコンシューマであり、そのため、新しい機能を追加することはありません。それらは、RIDCの上の新たなレイヤーと考えることができます。
コンビニエンス・クラスの使用の詳細は、「ユーザー・セキュリティの設定」を参照してください。
この項では、Intradoc接続とHTTP接続を初期化するサンプル・コード、およびJAX-WSクライアントを初期化するコードを示します。
次のコードは、Intradoc接続を初期化します。
Intradoc Connection Initialization // create the manager IdcClientManager manager = new IdcClientManager(); // build a client that will communicate using the intradoc protocol IdcClient idcClient = manager.createClient("idc://localhost:4444");
次のコードは、HTTP接続を初期化します。Intradoc接続との唯一の違いはURLです。
HTTP Connection Initialization // create the manager IdcClientManager manager = new IdcClientManager(); // build a client that will communicate using the HTTP protocol IdcClient idcClient = manager.createClient("http://localhost:16200/cs/idcplg");
次のコードは、JAX-WSクライアントを初期化します。URLにはidcnativews
Webコンテキスト・ルートが含まれています。このWebコンテキスト・ルートは(デフォルトでは)、コンテンツ・サーバーにより公開される2つのWebサービス、login
サービスおよびrequest
サービスにより使用されます。
JAX-WS Client Initialization // create the manager IdcClientManager manager = new IdcClientManager(); // build a client that will communicate using the JAXWS protocol IdcClient idcClient = manager.createClient ("http://wlsserver:16200/idcnativews");
クライアントの構成は、クライアントの作成後に実行できます。構成パラメータには、ソケット・タイムアウトの設定、接続プール・サイズなどがあります。構成はプロトコルに固有です。IdcClientオブジェクトを特定のタイプにキャストすると、そのタイプのプロトコル構成オブジェクトを取得できます。
次のコードは、Intradoc接続のためのソケット・タイムアウトおよび待機時間を設定します。
Client Configuration for Intradoc Connections // build a client as cast to specific type IntradocClient idcClient = (IntradocClient)manager.createClient("http://localhost/cs/idcplg"); // get the config object and set properties idcClient.getConfig().setSocketTimeout(30000); // 30 seconds idcClient.getConfig().setConnectionSize(20); // 20 connections
Remote Intradoc Client (RIDC)では、Intradoc通信プロトコルを使用してコンテンツ・サーバーとSecure Socket Layer (SSL)通信を行うことが可能です。使用される通常のポートは4444です。SSLの構成とポートの有効化の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』のSSLを使用するためのOracle WebCenter Contentの構成に関する項を参照してください。
SSL通信の場合、アクセス先のコンテンツ・サーバー・インスタンスにSecurityProvidersコンポーネントをインストールして有効化する必要があります。新しい受信プロバイダとのSSL通信のためにコンテンツ・サーバーを構成し、トラストストアまたはキーストアに関する情報を指定する必要があります。クライアントとコンテンツ・サーバーの両方で、署名付きの信頼できる証明書のある有効なキーストアまたはトラスト・マネージャが必要です。
Oracleでは、署名付き証明書を提供していません。ほとんどの実装では、広く認められている認証局による署名付きの証明書を求めることになります。
コンテンツ・サーバーとのSSL通信を構成するには、次のタスクを実行する必要があります。
例29-1 SSL経由のIDCプロトコル
// build a secure IDC client as cast to specific type IntradocClient idcClient = (IntradocClient) manager.createClient("idcs://localhost:4443"); // set the SSL socket options config.setKeystoreFile("keystore/client_keystore"); //location of keystore file config.setKeystorePassword ("password"); // keystore password config.setKeystoreAlias("SecureClient"); //keystore alias config.setKeystoreAliasPassword("password"); //password for keystore alias
次のコードは、セキュア・ソケット(SSL)経由のIDCプロトコルを使用します。
JAX-WS接続を設定するには、RIDCクライアントとコンテンツ・サーバーがそれぞれ、互換性のあるクライアントおよびサービスのWebサービス・ポリシーによって構成されている必要があります。
RIDCクライアントの場合、jaxwsConfig.setClientSecurityPolicy(...)
を使用して明示的なクライアント・ポリシー(LPAモード)を設定するか、または、RIDCを使用するアプリケーションが、ws-client
のGPAポリシーが正しく構成され、ターゲットになっている状態でOracle WebLogic Serverドメインにデプロイされている場合に、GPAクライアント・ポリシーを継承することができます。
サービス・ポリシーは、Oracle WebCenter ContentのWebサービス(IdcWebLoginPort
)エンドポイント(LPAモード)に直接添付するか、GPA ws-serviceポリシーをドメイン用に構成して、サービスにより継承することができます。
サービスのLPAモードは、Oracle Enterprise Manager Fusion Middleware Controlを使用して設定できます。
Fusion Middleware Controlを使用してサービスのLPAモードを設定するには:
oracle/wss_saml_or_username_token_service_policy
)を選択します。WebLogic Scripting Tool (WLST)のコマンドを使用して、GPAポリシーの継承を構成できます。
WLSTを使用してドメインのGPA ws-serviceポリシーを設定するには:
WebLogic Server Administration Scripting Shellを使用して、WebLogic Scripting Tool (WLST)を初期化します。
(/u01/app/oracle/product/Middleware/oracle_common/common/bin)% ./wlst.sh ... Initializing WebLogic Scripting Tool (WLST) ... Welcome to WebLogic Server Administration Scripting Shell Type help() for help on available commands
次のbase_domain
というドメインに対する一連のコマンドと類似したコマンドを起動します。
$MW_HOME/Oracle_ECM1/common/bin/wlst.sh
connect(username='weblogic',password='password',url='t3://localhost:7001')
beginRepositorySession()
createPolicySet('base_domain-ws-service','ws-service','Domain("base_domain")')
attachPolicySetPolicy('oracle/wss_saml_or_username_token_service_policy')
validatePolicySet()
commitRepositorySession()
listPolicySets()
exit()
GPAサービス・ポリシーが設定されていることを検証します。
GPAサービス・ポリシーがIdcWebLoginPort
によってピックアップされるまでしばらく待ちます。
WSDLを検査してwsp:PolicyReference
を探し、変更が適用されたかどうかを確認します。
http://server:16200/idcnativews/IdcWebLoginPort?WSDL
GPA Webサービス・クライアント・ポリシーの設定の詳細は、「ドメインのGPAサービス・ポリシーの設定」および「Webサービス・クライアントに対するGPAの追加」を参照してください。
LPAが明示的に設定されていない場合にJAX-WS経由でRIDCによって活用されるWSクライアントに対するGPAポリシーを特定するには、WebLogic Scripting Tool (WLST)を初期化し、WebLogic Server Administration Scripting Shellを使用します。
次にコードの例を示します。
例29-2 WebLogic Scripting Toolを使用したGPAポリシーの特定
(/u01/app/oracle/product/Middleware/oracle_common/common/bin)% ./wlst.sh
...
Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands
wls:/offline> connect('weblogic','password','t3://localhost:7001')
Connecting to t3://localhost:7001 with userid weblogic ...
Successfully connected to Admin Server 'AdminServer' that belongs to domain 'base_domain'.
wls:/base_domain/serverConfig> help('wsmManage')
Operations that provide support to manage the global policy attachments and
Oracle MDS repository.
help('abortRepositorySession')
Abort the current repository session,
discarding the changes made to repository.
help('attachPolicySet')
Attach a policy set to the specified resource scope.
help('attachPolicySetPolicy')
Attach a policy to a policy set using the policy's URI.
help('beginRepositorySession')
Begin a session to modify the repository.
help('clonePolicySet')
Clone a new policy set from an existing policy set.
help('commitRepositorySession')
Write the contents of the current session to the repository.
help('createPolicySet')
Create a new, empty policy set.
help('deletePolicySet')
Delete a specified policy set.
help('describeRepositorySession')
Describe the contents of the current repository session.
help('detachPolicySetPolicy')
Detach a policy from a policy set using the policy's URI.
help('displayPolicySet')
Display the configuration of a specified policy set.
help('enablePolicySet')
Enable or disable a policy set.
help('enablePolicySetPolicy')
Enable or disable a policy attachment
for a policy set using the policy's URI.
help('exportRepository')
Export a set of documents from the repository into a supported ZIP archive.
help('importRepository')
Import a set of documents from a supported ZIP archive into the repository.
help('listPolicySets')
Lists the policy sets in the repository.
help('migrateAttachments')
Migrates direct policy attachments to global policy attachments
if they are identical.
help('modifyPolicySet')
Specify an existing policy set for modification in the current session.
help('resetWSMPolicyRepository')
Clean the Oracle MDS repository and re-seed with the current set
of WSM policies.
help('setPolicySetDescription')
Specify a description for the policy set selected within a session.
help('upgradeWSMPolicyRepository')
Add newly introduced WSM policies to the Oracle MDS repository.
help('validatePolicySet')
Validate an existing policy set in the repository or in a session.
wls:/base_domain/serverConfig> listPolicySets()
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)
Global Policy Sets in Repository:
base-domain-ws-client
wls:/base_domain/serverConfig> displayPolicySet('base-domain-ws-client')
Policy Set Details:
-------------------
Name: base-domain-ws-client
Type of Resources: Web Service Client
Scope of Resources: Domain("base_domain")
Description: Global policy attachments for Web Service Client resources.
Enabled: true
Policy Reference: security : oracle/wss10_saml_token_client_policy, enabled=true
次のコードは、WSクライアントのGPAポリシーを設定します。
例29-3 Webサービス・クライアントに対するGPAの追加
# add GPA for the web service client assuming domain name is base_domain beginRepositorySession() createPolicySet('base_domain-ws-client','ws-client','Domain("base_domain")') # assuming service policy is hardcoded to # oracle/wss11_saml_token_with_message_protection_service_policy # and that we want the RIDC client to leverage client policy: # oracle/wss11_saml_token_with_message_protection_client_policy attachPolicySetPolicy ('oracle/wss11_saml_token_with_message_protection_client_policy') validatePolicySet() commitRepositorySession() # confirm policy set created listPolicySets()
# add GPA for the web service client assuming domain name is base_domain beginRepositorySession() createPolicySet('base_domain-ws-client','ws-client','Domain("base_domain")') # assuming service policy is hardcoded to # oracle/wss11_saml_token_with_message_protection_service_policy # and that we want the RIDC client to leverage client policy: # oracle/wss11_saml_token_with_message_protection_client_policy attachPolicySetPolicy ('oracle/wss11_saml_token_with_message_protection_client_policy') validatePolicySet() commitRepositorySession() # confirm policy set created listPolicySets()
クライアントの作成後に実行可能な、JAX-WS固有の構成がいくつかあります。ただし、ほとんどの場合、デフォルト設定を使用する必要があります。
このコードは、クライアントをJAX-WSタイプのキャストとしてビルドします。
JaxWSClient jaxwsClient = (JaxWSClient) manager.createClient ("http://wlsserver:7044/idcnativews"); JaxWSClientConfig jaxwsConfig = jaxwsClient.getConfig();
接続先のコンテンツ・サーバーのインスタンス名を設定できます。これはデフォルトで、コンテンツ・サーバーのインストール用のデフォルトWebコンテキストの/cs/
に設定されます。サーバーのWebコンテキストがデフォルトと異なる場合、次のように設定できます。
// set the property jaxwsConfig.setServerInstanceName("/mywebcontext/");
JPS構成ファイルの場所を設定します。JPS構成ファイルは、SAMLやメッセージ・トークンなど、ほとんどのポリシーで必要です。
jaxwsConfig.setJpsConfigFile("/my/path/to/the/jps-config.xml");
次のように、セキュリティ・ポリシーを設定します。
jaxwsConfig.setClientSecurityPolicy("policy:oracle/wss11_username_token_with_message_protection_client_policy");
ログイン・ポートのWSDL URLの変更
RIDCでは、インストールされたWebサービスに対してデフォルト値が使用されます。なんらかの理由でWebサービスが変更されており、デフォルトのURIまたはURLと一致しない場合は、デフォルト値の変更が必要になる可能性があります。
次のように、ログイン・ポートのWSDL URLを変更します。
jaxwsConfig.setLoginServiceWSDLUrl (new URL("http://server:7044/webservices/loginPort?WSDL"));
次のように、リクエスト・サービスURLを変更します。
jaxwsConfig.setRequestServiceWSDLUrl (new URL("http://server:7044/anotherservice/myrequestport?WSDL"));
デフォルトのストリーム・チャンク・サイズは8192です。次の例では、チャンク・サイズを変更します。
jaxwsConfig.setStreamingChunkSize(8190);
Remote Intradoc Client (RIDC)へのすべてのコールで、認証のためのなんらかのユーザーIDが必要です。オプションで、このID資格証明に、プロトコルで必要なパスワードなど、他のパラメータを添付することができます。ユーザーIDは、IdcContext
オブジェクトに保持されます。いったん作成されると、以降のすべてのコールでそれを再利用できます。コンテキストを作成するには、ユーザー名と、オプションでなんらかの資格証明を渡します。
次のように、(idc://
URLに対して)パスワードなしの単純なコンテキストを作成します。
IdcContext userContext = new IdcContext("weblogic");
次のように、パスワード付きのコンテキストを作成します。
IdcContext userPasswordContext = new IdcContext("weblogic", "password");
Intradoc URLの場合、リクエストがコンテンツ・サーバーとクライアントの間で信頼されているため、資格証明でパスワードは必要ありません。
JAX-WS URLの場合、資格証明の要件は、サーバーによってWebサービスが使用するように構成されているサービス・ポリシーによって異なります。
サービスを起動するには、IdcClient
クラス・メソッドを使用します。
public ServiceResponse sendRequest (IdcContext userContext, DataBinder dataBinder) throws IdcClientException
次のコードは、サービス・リクエストを実行し、結果のデータ・バインダを戻します。
Executing a Service Request // get the binder DataBinder binder = idcClient.createBinder(); // populate the binder with the parameters binder.putLocal ("IdcService", "GET_SEARCH_RESULTS"); binder.putLocal ("QueryText", ""); binder.putLocal ("ResultCount", "20"); // execute the request ServiceResponse response = idcClient.sendRequest (userContext, binder);
ServiceResponse
オブジェクトには、コンテンツ・サーバーからのレスポンスが含まれます。このレスポンスから、コンテンツ・サーバーのストリームに直接アクセスできます。または、それをDataBinder
に解析し、結果を問い合せることができます。
次のコードは、ServiceResponse
オブジェクトを取得し、検索結果を取得して、タイトルと作成者の値を出力します。
Get the Binder and Loop Over the Results // get the binder DataBinder binder = response.getResponseAsBinder (); DataResultSet resultSet = binder.getResultSet ("SearchResults"); // loop over the results for (DataObject dataObject : resultSet.getRows ()) { System.out.println ("Title is: " + dataObject.get ("dDocTitle")); System.out.println ("Author is: " + dataObject.get ("dDocAuthor")); }
ストリームを使用する場合、ストリームのクローズはコードで行います。次のコードは、ストリームを閉じます。
Closing a Stream
IdcContext user = new IdcContext ("weblogic", "password");
IdcClientManager manager = new IdcClientManager ();
IdcClient idcClient = manager.getClient ("some url");
DataBinder binder = idcClient.createBinder ();
binder.putLocal ("IdcService", "GET_FILE");
binder.putLocal ("dID", "12345");
ServiceResponse response = idcClient.sendRequest (user, binder);
InputStream stream = null;
try {
stream = response.getResponseStream ();
int read = 0;
int total = 0;
byte[] buf = new byte[256];
while ((read = stream.read (buf)) != -1) {
total += read;
}
} finally {
if (stream != null) {
stream.close ();
}
}
接続プーリングとストリームを介して閉じる方法の詳細は、「接続プーリングの処理」を参照してください。
IdcClientConfig#getConnectionPool
プロパティは、RIDCが接続のプーリングをどのように処理するかを決定します。simple
とpool
の2つのオプションがあります。
simple
オプションがデフォルトです。simple
オプションでは、接続の最大数の制限は適用されず、すべての接続がブロックされることなく処理されます。ほとんどの場合、このオプションを使用する必要があります。
pool
オプションでは、一度にアクティブにする接続数を構成可能な内部プールを使用することが指定されます(IdcClientConfig#getConnectionSize
プロパティを通じて構成可能で、デフォルトのアクティブ・サイズは20
に設定されます)。
通常、RIDCライブラリが、それ自体がアプリケーション・コンテナ内に存在するアプリケーション(Webアプリケーションなど)からの通信に使用される場合、インバウンド・リクエストはすでに調整されています。そのため、simple
オプションを使用することが適切です。pool
オプションを使用する唯一のシナリオは、スタンドアロン・サーバーを作成しており、かつコンテンツ・サーバーの過負荷を生じさせる可能性がある大量の同時コールをコンテンツ・サーバーに対して行う場合です。
IdcClientManager#getConnectionPoolManager()#registerPool()
メソッドによって別のプール実装を登録できます。このメソッドは、名前をConnectionPool
インタフェースの実装にマップします。マップされた名前は、IdcClientConfig
オブジェクトで使用されて、特定のクライアントに対してそのプールが選択されます。
ストリームは、TransferFile
クラスを通じてコンテンツ・サーバーに送信されます。このクラスは、実際のストリームを、ストリームに関するメタデータ(長さや名前など)とともにラップします。ファイルとストリームのチェックインを可能にするメソッドの詳細は、Oracle Fusion Middleware Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンスを参照してください。
次のコードは、コンテンツ・サーバーへのチェックインを実行します。
Content Server Check-In // create request DataBinder binder = idcClient.createBinder(); binder.putLocal ("IdcService", "CHECKIN_UNIVERSAL"); // get the binder binder.putLocal ("dDocTitle", "Test File"); binder.putLocal ("dDocName", "test-checkin-6"); binder.putLocal ("dDocType", "ADACCT"); binder.putLocal ("dSecurityGroup", "Public"); // add a file binder.addFile ("primaryFile", new TransferFile ("test.doc")); // check in the file idcClient.sendRequest (userContext, binder);
コンテンツ・サーバーからのレスポンス
コンテンツ・サーバーからのストリームは、ServiceResponse
オブジェクトを通じて受信されます。使用可能なメソッドのサマリーは、『Oracle Fusion Middleware Oracle WebCenter Content Remote Intradoc Client (RIDC) Java APIリファレンス』を参照してください。
特に要求されないかぎり、レスポンスは、DataBinderに変換されません。単に未加工のHDAデータが必要な場合は、それを直接取得し、レスポンスをStringまたはDataBinderに変換できます。
次のコードは、サービスを実行し、レスポンスを文字列として取得して、それをデータ・バインダに解析します。
Parsing a String into a DataBinder // create request DataBinder binder = idcClient.createBinder (); // execute the service ServiceResponse response = idcClient.sendRequest (userContext, binder); // get the response stream InputStream stream = response.getResponseStream (); // get the response as a string String responseString = response.getResponseAsString (); // parse into data binder DataBinder dataBinder = response.getResponseAsBinder ();
コンテンツ・サーバーのほとんどのサービス・リクエストは、クライアント上でDataBinderを使用してモデル化される構造化HDAペイロードを返します。HDAペイロードは基本的にマップのような構造であり、オプションとして、表に似たResultSetが含まれています。
ダウンロード・スタイルのサービス・リクエスト(GET_FILE
など)は通常、リクエストされたドキュメントのコンテンツをRAWバイト・ストリームとして返すと予想されています。ただし、GET_FILE
リクエストに指定されたパラメータが無効な場合、またはエンド・ユーザーの権限が十分でない場合などには、コンテンツ・サーバーは、エラー情報を含めたHDAペイロードで応答することがあります。したがって、GET_FILE
のようなリクエストを実行するときには、次に示すように、ServiceResponse
オブジェクトに質問して、返されるレスポンス・タイプを決定する必要があります。
Response Type Returned DataBinder binder = idcClient.createBinder (); binder.putLocal ("IdcService", "GET_FILE"); binder.putLocal ("dID", "12345"); ServiceResponse response = idcClient.sendRequest (user, binder); if (response.getResponseType().equals(ServiceResponse.ResponseType.BINDER)) { DataBinder responseBinder = response.getResponseAsBinder(false); // do not check for errors int statusCode = m_binder.getLocalData ("StatusCode").getInteger("StatusCode"); String statusMessage = m_binder.getLocal ("StatusMessage"); throw new IllegalStateException("Download response was not a stream - Error: " + statusCode + " - " + statusMessage); }
バインダは、複数のリクエスト間で再利用できます。あるリクエストからのバインダを別のリクエストに送信できます。あるコールからのバインダを次のコールで再利用する場合、次のコールに影響する可能性のあるものがバインダに残っていないように、細心の注意を払う必要があります。RIDCは、各コールの後にバインダをクリーンアップしません。
次のコードは、コンテンツ・サーバーへの複数のコールで同じバインダを再利用することで、検索結果をページングする例を示しています。
Reusing Binders // create the user context IdcContext idcContext = new IdcContext ("sysadmin", "idc"); // build the search request binder DataBinder binder = idcClient.createBinder(); binder.putLocal("IdcService", "GET_SEARCH_RESULTS"); binder.putLocal("QueryText", ""); binder.putLocal("ResultCount", "20"); // send the initial request ServiceResponse response = idcClient.sendRequest (idcContext, binder); DataBinder responseBinder = response.getResponseAsBinder(); // get the next page binder.putLocal("StartRow", "21"); response = idcClient.sendRequest (idcContext, binder); responseBinder = response.getResponseAsBinder(); // get the next page binder.putLocal("StartRow", "41"); response = idcClient.sendRequest (idcContext, binder); responseBinder = response.getResponseAsBinder();
コンテンツ・サーバーには、コンテンツ・サーバー上の設定によって制御されるいくつかのセキュリティ・モデルがあります。特定のユーザーがあるドキュメントへのアクセス権を持っているかどうかを判断するには、ユーザーの権限コントロール、ドキュメントの権限コントロール、コンテンツ・サーバーのセキュリティ環境設定という3つのものが必要です。
UserSecurityモジュールをコールするアプリケーション・プログラムは、スーパーユーザーとして(ドキュメントのバインダ、通常は検索結果で)ドキュメントおよびDOC_INFOメタデータをフェッチし、その情報をキャッシュすると想定されます。アプリケーション・プログラムで、特定のユーザーがドキュメントへのアクセス権を持っているかどうかを把握する必要がある場合、そのユーザーの権限をフェッチするために、そのユーザーとしてコンテンツ・サーバーへのコールが行われます。いったんユーザーの権限コントロールが把握されると、それらをドキュメントのメタデータ内の情報と照合してそのユーザーのアクセス・レベルを判断することができます。(アクセス・レベルは、READ、READ/WRITEまたはREAD/WRITE/DELETEです)。したがって、必要なのは、(キャッシュによって)コンテンツ・サーバーへのコール数を減らし、ユーザーの権限情報とドキュメントの権限情報を照合するデフォルトの実装を用意することです。さらに複雑化させる1つの要因は、コンテンツ・サーバーが一部のサーバー環境プロパティ(UseAccounts=true
およびUseCollaboration=true
またはUseEntitySecurity=1
)でどのセキュリティのタイプが使用されるかを制御することです。さらに、メソッドによって、そのドキュメントのセキュリティ・タイプに管理者権限が割り当てられているかどうかをテストすることができます。
ユーザー・セキュリティ・コンビニエンスには、IUserSecurityCache
インタフェースを通じてアクセスできます。それらのクラスは、オプションのコンテンツ・サーバー・セキュリティを実装します。
UserSGAcctAclCache
クラスは、常にコールする必要があります。このクラスは、セキュリティ構成についてコンテンツ・サーバーをチェックし、それに合せて自身を内部的に調整します。
UserSecurityGroupsCache
クラスは、ユーザー権限のキャッシュを保持し、セキュリティ・グループ情報のみを考慮してドキュメントを照合します。このクラスを直接コールしないでください。UserSGAcctAclCache
クラスは、セキュリティ構成についてコンテンツ・サーバーをチェックし、それに合せて自身を内部的に調整します。
コンテンツ・サーバーにUseAccounts=true設定がある場合、UserSGAccountsCache
クラスは、アカウント情報も考慮するためのリゾルバを追加します。このクラスを直接コールしないでください。UserSGAcctAclCache
クラスは、セキュリティ構成についてコンテンツ・サーバーをチェックし、それに合せて自身を内部的に調整します。
次のコードは、ユーザー・セキュリティの設定の例を示しています。
Setting User Security IdcClientManager m_clientManager = new IdcClientManager (); IdcClient m_client = m_clientManager.createClient ("http://localhost/scs/idcplg"); //RIDC superuser context IdcContext m_superuser = new IdcContext("sysadmin", "idc"); //This class will self-adjust (downwards) to match the security model // on Content Server. IUserSecurityCache m_userSecurityCache = new UserSGAcctAclCache (m_client, 20, 1000, 20000, m_superuser); ITrace trace = null; //Example test testDocPermission () { //If you don't want to do any logging, you can leave trace as null if (m_log.isLogEnabled(ILog.Level.TRACE)) { trace = new Trace (); } DataBinder m_doc1 = getDataBinder ("TEST"); //Get the document information (typically in the first row of DOC_INFO) DataObject docInfo = m_doc1.getResultSet ("DOC_INFO").getRows ().get (0); //Get the cache id for this user //This makes a live call to content server to get the user ID for "Acme1" //CacheId acme1 = m_userSecurityCache.getCacheIdForUser // (new IdcContext("Acme1", "idc"), trace); IdcContext context = new IdcContext("Acme1", "idc"); CacheId acme1 = new CacheId (context.getUser (), context); //Get the access level for this document by this user int access = m_userSecurityCache.getAccessLevelForDocument (acme1, docInfo, trace); //Check if user has ACL admin permissions boolean aclAdmin = m_userSecurityCache.isAdmin (acme1, docInfo, IUserSecurityCache.AdminType.ACL, trace); if (m_log.isLogEnabled(ILog.Level.TRACE)) { m_log.log (trace.formatTrace (), ILog.Level.TRACE); } } //Example code to get a Document's DOC_INFO databinder DataBinder getDataBinder (String dDocName) throws IdcClientException { DataBinder dataBinder = m_client.createBinder (); dataBinder.putLocal ("IdcService", "DOC_INFO_BY_NAME"); dataBinder.putLocal ("dDocName", dDocName); ServiceResponse response = m_client.sendRequest (m_superuser, dataBinder); return response.getResponseAsBinder (); } //Example code to create a DataObject DataObject dataObject = m_client.getDataFactory ().createDataObject (); dataObject.put ("dSecurityGroup", "public"); dataObject.put ("dDocAccount", "Eng/Acme");
内部的に、ドキュメントからのこれらのフィールドは、getAccessLevelForDocument()
の間に調査されます。
AccessResolverSecurityGroups
クラスの場合: dSecurityGroup
AccessResolverAccounts
クラスの場合: dDocAccount
AccessResolverSecurityGroups
クラスの場合: xClbraUserList
、xClbraAliasList
およびxClbraRoleList
IAccessResolver
クラスは、コンテンツ・サーバーからキャッシュされた情報に基づいて参加するかどうかを決定します。参加する場合、複数のアクセス・レベルは論理積(AND)になります。hasAdmin()
メソッドを使用して、管理アクセス権があるかどうかを判断できます。
Remote Intradoc Client (RIDC) 12cでは、DataBinderが処理されてコンテンツ・サーバーに送信される前に、アプリケーション・コードでフィルタを追加することが可能です。IdcFilterAdapter
クラスのいずれかを拡張してフィルタを作成し、そのフィルタを登録してIdcFilterManager
クラスで実行できます。フィルタは、登録時に指定された順番で実行されます。すでに登録済のフィルタを取得したり、削除したりすることもできます。
次のコードは、アダプタを拡張し、アクションを実行するメソッドをオーバーライドします。
Calling RIDC Filter Before Service Request public class IdcFilterAddComment extends BeforeServiceRequestFilter { @Override public void beforeServiceRequest (IdcClient client, IdcContext context, DataBinder binder) throws IdcClientException { String existingComments = binder.getLocal("xComments"); if (existingComments != null) { binder.putLocal("xComments", String.format ("%s %s", existingComments, "--DGT WAS HERE--")); } else { binder.putLocal("xComments", "--DGT WAS HERE--"); } } }
Remote Intradoc Client (RIDC) 12cでは、JAX-WS処理領域にさらに2つのフィルタの場所が提供されます。それらのフィルタを使用するには、BeforeJaxwsServiceFilter
クラスを拡張します。
次のコードは、BeforeJaxwsServiceFilter
クラスを拡張します。
Calling RIDC Filter Before JAX-WS Call /** * RIDC filter called just before jaxws call is made to * loginPort.contentServerLogin () in authenticateUser () **/ public void beforeJaxwsAuthenticateUser (IdcContext context, DataBinder binder, Map<String, Object> requestContext) throws IdcClientException { requestContext.put(oracle.wsm.security.util.SecurityConstants. ClientConstants.WSM_SUBJECT_PRECEDENCE, “false"); } /** * RIDC filter called just before jaxws call is made to * loginPort.contentServerRequest () in performServiceRequest () **/ public void beforeJaxwsServiceRequest (IdcContext context, DataBinder binder, Map<String, Object> requestContext) throws IdcClientException { //Override this class and implement your filter here }
次のコードは、フィルタ・クラス(複数可)を登録します。
Register Filer Classes // If you are at the start of a pure RIDC application, you typically // will create a ClientManager, for example: IdcClientManager m_clientManager = new IdcClientManager(); // New method added to IdcClient to get the ClientManager // if you do not have the ClientManager instance: IdcClient client = myClient; client.getClientManager(); // From the ClientManager, you can get the FilterManager: IdcFilterManager fmanager = m_clientManager.getFilterManager(); // Then register your filter: IIdcFilter addCommentFilter = new IdcFilterAddComment(); int slot = fmanager.registerFilter(100, addCommentFilter); // Optionally, you can deregister. However, it might not be in the slot you // assigned because there might have already been a filter in that slot. // When registering, the next available higher slot will be used. You also need // to pass in the instance currently in the slot you want to remove: fmanager.deRegisterFilter(slot, addCommentFilter); // Here is an example to remove all the filters, // including the ones you did not register for (Integer slot:fmanager.getUsedSlots()) { fmanager.deRegisterFilter(slot, fmanager.getFilter (slot)); }