IBM FileNet P8, バージョン 5.2.1            

入門

Content Engine API は、FileNet® Content Platform Engine サーバーに格納されたオブジェクトにアクセスして処理するアプリケーションを構築するための、プラットフォームに依存しない API です。 Content Engine API でサポートするアプリケーションの主なタイプは、ランタイム、管理、およびメタデータ・オーサリングの 3 種類です。 ランタイム・アプリケーションはオブジェクト・ストアおよびドキュメントを処理し、管理アプリケーションは構成タスクを実行し、メタデータ・オーサリング・アプリケーションはクラスの定義とプロパティーを作成します。API により、Content Engine サーバーでサポートするすべての操作が開示されます。Content Engine API では、これらすべての種類に対応したアプリケーションを作成できます。

重要: アプリケーションを開発するときには、Content Engine Java™ および .NET API リファレンス・ヘルプに記載されている開示クラスおよび開示インターフェースのみを使用してください。ただし、リファレンス・ヘルプ内で内部使用専用と明記されているものを除きます。 Java API の開示クラスおよび開示インターフェースは、com.filenet.api のサブパッケージに入っているものです。 .NET API の開示クラスおよび開示インターフェースは、FileNet.Api のサブ名前空間に入っています。 開示されていない内部クラスおよび内部インターフェース (リファレンス・ヘルプで内部使用専用と明記されているものと、API リファレンス・ヘルプに記載されていないクラスおよびインターフェース) は使用しないでください。 特に、com.filenet.apiimpl の Java サブパッケージと FileNet.Apiimpl の .NET サブ名前空間の中のクラスまたはインターフェースはいずれも使用しないでください。開示されていないクラスおよびインターフェースは、随時、通知なしに変更される可能性があります。それらの使用はサポートされていません。

開発者の要件

開発を開始する前に、ご使用の開発環境と開発言語に対応した特定のバージョンのフレームワーク・ソフトウェアが必要です。さまざまな開発環境のセットアップ手順については、以下のトピックを参照してください。

サンプル IDE のセットアップのトピックには、クライアント FileNet P8 アプリケーション開発のための統合開発環境 (IDE) プロジェクトをセットアップする方法を示すサンプルが含まれています。 Eclipse IDE および Microsoft Visual Studio IDE 用のサンプルが用意されています。サンプルは、すべてのサポートされるアプリケーション・サーバー上の開発環境に対応しています。

Content Engine API のサーバー・バージョンとの互換性

Content Engine API のバージョン N を使用するクライアント・アプリケーションは、Content Platform Engine サーバー・バージョン N およびバージョン N+1 でサポートされます。 この API サポート・ポリシーは、サーバー・バージョン N+2 以上には拡張されません。新しい API バージョンを使用するアプリケーションは、古いサーバー・バージョンではサポートされません。

新しい Content Platform Engine サーバー・バージョンとの互換性を保証するために、クライアント・アプリケーションで Content Engine Client ダウンロード・サービスを使用することをお勧めします。 Content Engine Client ダウンロード・サービスを使用すると、クライアント・アプリケーション内にバージョン互換性チェックおよび自動更新を組み込むことができます。 詳細については、 『Content Engine Clientダウンロード・サービス (Content Engine Client Download Service)』を参照してください。

Content Platform Engine サーバーの 5.2.1 バージョン以降、Content Engine Java API には、リリース間クラス・ロード (CRCL) 機能が組み込まれています。この機能を使用すると、Java アプリケーションの単一のインスタンスを複数の Content Platform Engine サーバー・リリースに同時に接続できます。そのアプリケーションの Content Engine API よりも古いサーバー・バージョンにも接続できます。 詳細については、『リリース間アプリケーションの開発』を参照してください。

必要なファイルの検索

Content Platform Engine に付属の Content Platform Engine Client Installer を実行することによって、開発サポート・ファイルを取得することができます。 アプリケーション開発に必要な Content Engine Client ファイルをインストールするには、インストーラーのFileNet P8 アプリケーションの選択 (Select FileNet P8 Applications)」ウィンドウの「他のアプリケーション (Other Applications)」オプションを選択します。

Java および .NET の必須バージョン

Content Engine API では、特定の最小レベルの Java 2 Standard Edition (J2SE) 環境と Microsoft .NET Framework 環境が必要です。これらの要件については、『IBM® FileNet P8 Hardware and Software Requirements』を参照してください。

必要な Java Archive (JAR) ファイル

Content Engine Java API の実行中には、他の JAR ファイル (サード・パーティーの JAR ファイルを含む) が必要です。必要な JAR ファイルは、Application Engine ソフトウェアとともにインストールされます。各 JAR ファイルについては提供されるバージョンが必須のため、同名の異なる JAR ファイルで置き換えないでください。 (ご使用の環境用のインストール手順については、『IBM FileNet P8 のインストールまたはアップグレード (Installing or upgrading IBM FileNet P8)』を参照してください。 Content Engine Java API を使用するスタンドアロンの Java アプリケーションを作成する場合は、必要な JAR ファイルをクラスパスに含める必要があります。 欠落した JAR ファイルがあると、エラーと ClassNotFound 例外が発生します。使用するトランスポート・オプション、Content Engine Web Service (CEWS)、および Enterprise JavaBeans (EJB) 別の必要な JAR ファイルを次の表に示します。

.jar ファイル 説明
Content Engine Java API CEWS トランスポート・クライアントに必要なファイル
Jace.jar Content Engine Java API 用のコア FileNet JAR ファイル。
log4j.jar Content Engine Java API ロギングのための LOG4J フレームワーク。同一の log4j-<version>.jar ファイルを使用することもできます。ここで、<version> は FileNet P8 Platform ソフトウェアとともにインストールされたサポートされるバージョンです。例: log4j-1.2.14.jar
stax-api.jar CEWS トランスポート・サポートを提供します。
xlxpScanner.jar CEWS トランスポート・サポートを提供します。
xlxpScannerUtils.jar CEWS トランスポート・サポートを提供します。
p8cel10n.jar Content Engine サーバーおよび Content Engine Java API のローカライズされた例外メッセージを提供します。 p8cel10n.jar ファイルは、Jace.jar と同じバージョンの Content Engine のものでなければなりません。

クライアント・アプリケーションの場合、この JAR ファイルは、クライアントのロケールの言語で例外メッセージを受け取るために必要です。この JAR ファイルがクライアントのランタイム環境から削除されている場合、例外メッセージは英語で表示されます。

Content Engine Java API EJB トランスポート・クライアントに必要なファイル
Jace.jar Content Engine Java API 用のコア FileNet JAR ファイル。
log4j.jar Content Engine Java API ロギングのための LOG4J フレームワーク。同一の log4j-<version>.jar ファイルを使用することもできます。ここで、<version> は FileNet P8 Platform ソフトウェアとともにインストールされたサポートされるバージョンです。例: log4j-1.2.14.jar
p8cel10n.jar Content Engine サーバーおよび Content Engine Java API のローカライズされた例外メッセージを提供します。 p8cel10n.jar ファイルは、Jace.jar と同じバージョンの Content Engine のものでなければなりません。

クライアント・アプリケーションの場合、この JAR ファイルは、クライアントのロケールの言語で例外メッセージを受け取るために必要です。この JAR ファイルがクライアントのランタイム環境から削除されている場合、例外メッセージは英語で表示されます。

1 つ以上のアプリケーション・サーバー固有 .jar ファイル これらの JAR ファイルがアプリケーション・サーバー内に既に存在する場合には不要です。スタンドアロン JVM を使用している場合にのみ必要です。
Content Java API 互換性レイヤー・クライアントに必要なファイル
javaapi.jar Content Java API 互換性レイヤーのクラス実装ファイル。
p8cjares.jar Content Engine Java API 互換性レイヤー・クラスのローカライズ可能リソース文字列。
listener.jar FileNet P8 System Manager リスナー API。 System Manager ロギング・クライアントを開発する場合、または互換性レイヤー API で System Manager パフォーマンスのモニターを実行する場合にのみ必要です。互換性レイヤーは、このファイルが存在する場合はこのファイルを使用しますが、存在しない場合は無視します。 (System Manager ロギングの詳細については、「FileNet System Manager Help for Developers」を参照してください。)
該当するトランスポートの Content Engine Java API クライアントのすべての .jar ファイル。 ご使用のトランスポートに関する前述のセクションを参照してください。

必要な .NET コンポーネント

Content Engine の .NET API は、Microsoft Windows Communication Foundation (WCF) をサポートし、Microsoft Web Services Extensions (WSE) 3.0 の旧バージョンとの互換性を維持します。 ただし、WSE サポートは非推奨であり、今後のリリースではサポートは継続されません。この理由から、WSE の使用を継続することは推奨されません。

WCF 搭載の .NET Framework 向けに開発されたアプリケーションで、WCF 搭載の .NET Framework 3.0 で実行したいものがある場合、それらのアプリケーションの認証メカニズムを更新する必要があります。詳しくは、カスタム・アプリケーションのアップグレード (Upgrading Custom Applications) を参照してください。

Content Engine .NET API による開発を開始するには、Microsoft .NET Framework 3.0 以降 (WCF はこのフレームワークに組み込まれています) をインストールします。この環境では独自のカスタム・アプリケーションを作成できます

Microsoft Visual Studio .NET API を使用するアプリケーションを開発する場合は、最初に .NET API への参照をプロジェクトに追加する必要があります。 Visual Studio の 「参照の追加」ダイアログで、「参照」タブを選択して <ドライブ名 >:¥Program Files¥FileNet¥Content Engine¥ に移動します。 このフォルダーから FileNet.Api.dll という項目を選択し、「OK」をクリックします。 これで、プロジェクト内から Content Engine .NET API を使用できるようになりました。

Java パッケージと .NET 名前空間

通常、パブリック Java パッケージと .NET 名前空間は、機能の点で相互に対応しています。 ただし、Java パッケージの機能に相当するものが .NET 環境にない場合 (またはその逆の場合)、列には N/A (適用外) と記載されます。Java パッケージおよび .NET 名前空間と簡単な説明を次の表に示します。

Java パッケージ .NET 名前空間
com.filenet.api.action FileNet.Api.Action オブジェクトの変更操作に関連するクラス。
com.filenet.api.admin FileNet.Api.Admin Content Engine サーバーの管理に使用されるクラスとインターフェース。
なし FileNet.Api.Authentication Microsoft Web Services Extensions (WSE) 3.0 を組み込んだ .NET Framework 2.0 環境、または Microsoft Windows Communication Foundation (WCF) を組み込んだ .NET Framework 3.0 環境のどちらでもアプリケーションを実行できるようにするクラスとインターフェース。
com.filenet.api.collection FileNet.Api.Collection オブジェクトのコレクションに関連するタイプ・セーフなインターフェース
com.filenet.api.constants FileNet.Api.Constants 関連するタイプ・セーフな定数値のコレクションを定義するクラス
com.filenet.api.core FileNet.Api.Core API のコア・ビジネス・オブジェクトに関連するクラスとインターフェース
com.filenet.api.engine なし Content Engine サーバー内で実行するコード (イベント・アクションなど) の作成時に使用されるクラスとインターフェース。
com.filenet.api.events FileNet.Api.Events Content Engine のイベント処理フレームワーク
com.filenet.api.exception FileNet.Api.Exception Content Engine の例外レポート・フレームワーク
com.filenet.api.jdbc なし Content Engine データベースの Java Database Connectivity (JDBC) プロバイダーの使用に関連するクラス。
com.filenet.api.meta FileNet.Api.Meta Content Engine オブジェクト・プロパティー・メタデータに関連するクラスとインターフェース。
com.filenet.api.property FileNet.Api.Property Content Engine オブジェクト・プロパティーに関連するクラスとインターフェース。
com.filenet.api.publishing FileNet.Api.Publishing パブリッシングに関連するインターフェース
com.filenet.api.query FileNet.Api.Query Content Engine 検索条件の作成と検索実行に関連するクラス。
com.filenet.api.security FileNet.Api.Security 認証、認可、およびユーザー固有/グループ固有のデータに関連するインターフェース
com.filenet.api.util FileNet.Api.Utility ユーティリティーのクラスとインターフェース

トランスポート・プロトコル

Content Platform Engine では、Enterprise Java Beans (EJB)、Web Service for Content Engine and for Process Engine、および HTTP for Process Engine の 3 つの基本的なトランスポート・プロトコルがサポートされます。 Content Platform Engine とこれらのプロトコルの間の相互作用を次の図に示します。

Content Platform Engine がサポートするトランスポート・プロトコルのイメージ。

以下のセクションでは、Content Engine によって使用されるトランスポート・プロトコルを中心に説明します。 Process Engine については、Process Java Developer's GuideProcess Engine Web Service、および Process Engine REST Service を参照してください。

EJB

Content Platform Engine は、Java Platform, Enterprise Edition アプリケーション・サーバーの EJB コンテナー・レイヤーを介して機能を実装します。 EJB プロトコル (多くの場合、RMI-IIOP ベース) は、ネットワーク上で Content Platform Engine サーバーとの間での要求/応答として、シリアライズされた Java オブジェクトを受け渡します。EJB トランスポートを介して実行するよう構成された Content Engine Java API は、FileNet P8 で利用可能なインターフェースのうち、最も速いインターフェースですが、相対的なパフォーマンスは使用状況に依存します。

EJB リスナーは、Content Engine に対してプライベート EJB インターフェース (API 呼び出し側に対しては使用可能ではないインターフェース) を提供し、ローカル・インターフェースとリモート・インターフェースの両方を提供します。ローカル・インターフェースは、アプリケーション・サーバーにデプロイされた Content Engine EAR ファイルにバンドルされている Java Platform, Enterprise Edition コンポーネントにより使用されます。 リモート・インターフェースはリモート Java API により使用されます。EJB インターフェースは、Content Engine Java API により使用されます。サーバー・ノード間の通信と、セキュリティーおよびトランザクション・コンテキストの自動伝達に、アプリケーション・サーバー提供のプロトコルを使用します。

Content Engine Web Service

Content Engine Web Service (CEWS) トランスポートは、SOAP プロトコルをベースにしています。CEWS トランスポートは、.NET API が Content Engine にアクセスできる唯一の手段です。Java API は、EJB トランスポートと CEWS トランスポートのどちらかを使用して Content Engine にアクセスできます。Content Engine オブジェクトは XML で表現されます。これらのオブジェクトはシリアライズされ、HTTP を使用してクライアント・アプリケーションからネットワーク経由で Content Engine へ受け渡されます。

CEWS リスナーは、Java Platform, Enterprise Edition アプリケーション・サーバーの Web コンテナー・レイヤーで実行されるサーブレットとして実装されます。 CEWS レイヤーは、ピュア Web サービス・ベースのインターフェースを Content Engine サーバーに提供することにより、EJB レイヤーが Java クライアントに対して開示するのと同じ Content Engine 機能を Web サービス・クライアントに対して開示します (ただし、トランザクション伝達および使用可能な認証方式は異なります)。 CEWS リスナーは、Content Engine にアクセスするため Web サービス 呼び出しを EJB レイヤーに転送します。

トランスポートの選択

Content Engine サーバーへの接続確立時に、EJB トランスポートまたは CEWS トランスポートのいずれかを指定できます。 Connection オブジェクトは、FileNet P8 ドメインへの論理接続を表し、接続の Universal Resource Identity (URI) を保持します。URI は、Content Engine サーバーへの接続確立時に必要な情報 (サーバー通信に使用するトランスポート・プロトコル、ホスト、およびポートなど) を保持します。

Content Engine Java API ベースのクライアントは、サーバーとの通信に使用するトランスポートを判別します。Connection オブジェクトの作成時に URI パラメーターに基づいてトランスポートを選択します。

例については、「接続の取得」を参照してください。

トランスポートの相違点

各トランスポート・プロトコル間の相違点に注意してください。

  • Java クライアントの場合、EJB プロトコルには SOAP プロトコルとは異なる JAR ファイルが必要です。詳細については、必要な Java Archive (JAR) ファイルで、必要な JAR ファイルのリストを参照してください。
  • 異なる構成が必要になることがあります。デフォルトの認証動作では十分でない場合には、JAAS 構成ファイルの別のスタンザを使用する必要があります。Content Engine Java API ベースのクライアントは、Connection オブジェクトで指定された URI に基づいて、サーバーとの通信に使用するトランスポートと、通信するエンドポイントを判別します。 これらの例は、トランスポートの選択に応じて影響を及ぼし得る構成の相違点の 2 つの例に過ぎません。 構成ファイルの詳細については、クライアント構成を参照してください。
  • EJB トランスポートでは JAAS セキュリティー伝達がサポートされていますが、CEWS トランスポートではサポートされていません。
  • EJB トランスポートでは Java API からの呼び出しによるクライアント開始トランザクションのみがサポートされていますが、CEWS トランスポートではクライアント開始トランザクションがサポートされていません。Web サービス要求のトランザクション・コンテキストの伝達に関しては、十分に確立された業界標準がありません。このため、CEWS トランスポートを使用しているときに ConfigurationParameter.CONNECTION_PARTICIPATES_IN_TRANSACTION の値を、接続がトランザクションに関与することを示す true に設定すると、ランタイム例外が発生します (Java クライアント・アプリケーションのトランザクション・サポートを構成するには、Java API リファレンス・ヘルプの CONNECTION_PARTICIPATES_IN_TRANSACTION パラメーターを参照してください)。

クライアント構成

Content Engine のインストール時に、さまざまなクライアント・サイド構成関連ファイルがインストールされます。これらのファイルにはデフォルト値が記述されていますが、テキスト・エディターでご使用の環境に合わせてこれらのデフォルト値を変更できます。特定のファイルの一部の値はプログラムで変更でき、変更した値は、構成ファイルに指定された値を上書きします。詳細については、Configuration クラスと ConfigurationParameterクラスを参照してください。

Java アプリケーションの場合、Java ランタイム環境 (JRE) に合わせて構成された JAAS ログイン・コンテキストがあることを前提としています。 Content Engine Java API は、認証に JAAS を使用します。

構成ファイル

クライアント環境が Java と .NET のどちらであるかに応じて、クライアント環境を構成するためのそれぞれ固有のファイルにアクセスできます。

.NET 構成ファイル

app.config ファイル (ASP.NET アプリケーションの場合は web.config) は、アプリケーション固有の構成ファイルであり、アプリケーションに使用されるパラメーターを指定する XML ステートメントが記述されています。(.NET アプリケーションでのこのファイルの使用はオプションである点に注意してください。このファイルが存在しない場合は、推奨されるデフォルト値が使用されます。) 適用する .NET アプリケーションに合わせてこのファイルの名前を変更する必要があります。app.config ファイルについては、Microsoft MSDN ライブラリーの記事「Application Configuration Files Explained」を参照してください。

「filenet.api」という名前のセクションで、FileNet P8 アプリケーションの構成パラメーターを設定できます。以下のセクションの内容は、並行アップロード・スレッド数、コンテンツのアップロードに使用するコンテンツ・チャンクのブロック・サイズ、トレース・ロギング・オプション、メタデータ・キャッシュ・パラメーターなどの設定を表します。 値を設定するために使用するキーは、ConfigurationParameter 列挙に対応しています。 例えば、キー cmc enabled は、ConfigurationParameter.CMC_ENABLED 定数に対応しています。

以下の app.config ファイルの例は、"filenet.api" セクションを示しています。

 
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
     <section name="filenet.api" type="FileNet.Api.Util.FileNetConfigHandler, FileNet.Api, 
         Version=5.0.0.0, Culture=neutral, PublicKeyToken=63fc2fb3fdeef4f1" />
  </configSections>
  <filenet.api>
     <cmc enabled="true" timetolive="3000" />
     <connection fullwsspecheaders="true" />
     <content maxuploadthreads="4" putblocksizekb="1024" getblocksizekb="32" />
  </filenet.api>
</configuration>

また、グローバルに構成を適用するには、システムの machine.config ファイル (ASP .NET アプリケーションの場合は web.config ファイル) に、構成を組み込みます。これを選択する場合、まず 2 つのセクション (<section name="filenet.api"><filenet.api>) を切り出し、次にこれらを machine.config ファイルのそれぞれ異なる場所にマージする必要があります。 app.config ファイルには 1 つの項目が指定された <configSections> セクションがあり、その直後に <filenet.api> セクションがあります。 machine.config ファイルには、既に多数の項目が指定された既存の <configSections> セクションが記述されています。 この情報を machine.config ファイルに追加するには、<section name="filenet.api"> セクションを既存の <configSections> 領域に挿入し、<configSections> とは別の適切な位置に <filenet.api> セクションを追加する必要があります。 これは通常、ファイルの末尾に追加します (ただし、末尾に置くことは必須ではありません)。 machine.config ファイルの詳細については、.NET 開発者向け資料を参照してください。 以下の例では、<section name="filenet.api"> セクションと <filenet.api> セクションが別の位置に挿入されています)。

<configuration>
   <configSections>
      <section name=... />
      <section name=... />
      ...
      <sectionGroup name=...>
         <section name=... /> 
         <section name=... />
      </sectionGroup>
      <section name=... /> 
       <section name="filenet.api" type=FileNet.Api.Util.FileNetConfigHandler, FileNet.Api, Version=5.0.0.0, 
         Culture=neutral, PublicKeyToken=63fc2fb3fdeef4f1" />
   </configSections>
   <configProtectedData ... >
      <providers>
      ...
      </providers>
   </configProtectedData>
   <runtime />
   <connectionStrings>
      ...
   </connectionStrings>
   <system.data>
      ...
   </system.data>
   <system.web>
      ...
   </system.web>
   <filenet.api>
   </filenet.api> 
</configuration> 

FileNet.properties ファイル

これはオプションのファイルです。このファイルには、構成値を設定する項目が記述されています (ConfigurationParameter クラスの構成アイテムのタイプを参照)。FileNet.properties ファイルの 2 つのキャッシュ管理項目の出力例を次に示します。

 
 FileNet.CMC.Enabled=true 
 FileNet.CMC.TimeToLive=300000
 

API は FileNet.properties 構成ファイルの検索時に、次に示すディレクトリーをこの順序で検索します。

  • 現行ディレクトリー (Java システム・プロパティー user.dir)
  • ユーザーのホーム・ディレクトリー (Java システム・プロパティー user.home)
  • Java JVM ホーム・ディレクトリー (Java システム・プロパティー java.home)

上のいずれのディレクトリーでもファイルが見つからない場合、API はクラスパス上でファイルを検索します。

JAAS 構成ファイル

Content Engine Java API では、要求発行前に JAAS コンテキストが確立されたことを前提としています。 UserContext クラスを使用したユーザー名/パスワード・モデルに対する既存のサポートはあります。 そのモデルを使用する場合でも、クライアント環境には適切な JAAS 構成を組み込む必要があります (API は内部 JAAS ログインを実行します)。

Content Engine のインストール処理時には、サポートされる各アプリケーション・サーバー環境用の JAAS 構成ファイルのサンプル (jaas.conf.WebLogic、jaas.conf.WebSpherejaas.conf.JBossおよび jaas.conf.WSI) が含まれたサンプル・ディレクトリーが作成されます。 これらのサンプル・ファイルはそのまま使用されることを想定していません。各自で JAAS 構成を作成する際のガイドとして使用してください。(JAAS 構成の作成の詳細については、JDK または アプリケーション・サーバーの資料を参照してください。)

EJB トランスポートを使用する場合、アプリケーション・サーバーの通常の JAAS 構成 (またはサイトに合わせてカスタマイズした構成) で十分です。 CEWS トランスポートを使用するときには、API 外部で JAAS ログイン・コンテキストを確立する場合でも、UserContext のレガシー・サポートを使用する場合でも、FileNet 固有のログイン・モジュールを JAAS 構成に組み込む必要があります。 CEWS トランスポートを使用する場合のこのログイン・モジュールの形式は次のようになります。

tag {com.filenet.api.util.WSILoginModule REQUIRED;}; 

UserContext のレガシー・サポートを使用する場合、ログインに使用する JAAS スタンザを示すタグを指定できます。 null を指定すると、API ではデフォルトの「FileNetP8」が使用されます。「FileNetP8」が存在しない場合は、「other」の通常の全体的な JAAS フォールバックが使用されます。 また、ログイン・モジュールを既存の JAAS 構成スタンザに統合できます。

JAAS を正しく構成した後、JAAS ログインを実行できます。 サンプル・コードについては「LoginContext の取得」を参照してください。

JNDI 構成ファイル

jndi.properties ファイルには、アプリケーション・サーバー固有の JNDI InitialContextFactory クラスとプロバイダー URL が指定されています。このファイルは、CEWS トランスポートでは使用されませんが、EJB トランスポートではオプションです。 このファイルは標準 JNDI 構成メカニズムであり、FileNet 固有ではありません。このファイルがない場合は、パラメーターにはデフォルト値が使用されます。パラメーターの値を指定するもう 1 つの方法として、システム・パラメーター java.naming.factory.initial および java.naming.provider.url を使用する方法があります。

ロギング構成ファイル

クライアント API ロギングを制御するオプションの log4j 構成ファイルは、Java プロパティー・ファイル形式 (log4j.properties) または XML 形式 (log4j.xml) のいずれかです。インストーラーにより、サンプルの log4j.properties.client ファイルがインストールされます (このファイルは、使用する前に名前を必ず変更してください)。このファイルの項目を、作成したサイト構成ファイルにマージして、log4j を作成できます。

FileNet P8Domain

FileNet P8 ドメインは、物理リソース (オブジェクト・ストアなど) の論理グループと、これらのリソースへのアクセスを提供する Content Engine サーバーを表します。 また、ドメインにはユーザー許可のための 1 つ以上のセキュリティー・レルムが関連付けられています。ドメインのリソースは共通属性 (マーキング・セットやアドオンなど) を共有します。論理グループでは、共通属性を共有するだけでなく、複数オブジェクト・ストアの検索と更新を実行するコンテキストも提供されます。各リソースおよび各 Content Engine サーバーは、1 つのドメインにのみ属します。 Content Engine サーバーはドメイン内のすべてのリソースにアクセスできますが、関連付けられているドメインの外部にあるリソースにはアクセスできません。FileNet P8 ドメインの詳細については、「Content Engine Administration」ヘルプの 『FileNet P8 ドメイン (FileNet P8 Domains)』を参照してください。

Global Configuration Database (GCD) には、このデータベースが表す FileNet P8 ドメインのリソースおよびサービスのコレクションの機能特性を制御する共通属性セットの定義が格納されています。一般的な階層型のオブジェクト格納構造を備え、FileNet P8 ドメインのブートストラッピング・データやグローバル構成情報が格納されます。GCD により定義されるドメイン・リソースには、サイト (およびサイトに関連する仮想サーバーとサーバー・インスタンス)、オブジェクト・ストア・データベース、フルテキスト索引領域、固定コンテンツ・ストレージ域、コンテンツ・キャッシュ域、アドオン、マーキング・セットなどがあります。

GCD を主に使用するのは、アプリケーション・サーバー内部で実行される Content Engine です。例えば Content Engine は、オブジェクト・ストアのリストや、特定のオブジェクト・ストアの接続情報などを取得するときに GCD を使用します。アプリケーション・サーバー外部で実行されるインストール・プログラムも GCD を使用して新規 FileNet P8 ドメインの作成や既存の FileNet P8 ドメインへの接続を行います。機密情報を含むことがある GCD はセキュリティー的に保護され、特定のプリンシパル (通常は管理者)、またはプリンシパルのグループのみが GCD に含まれる、データの読み書きアクセスを持ちます。クライアント・サイド・アプリケーションの開発者は、GCD のオブジェクトを表すオブジェクト (ObjectStoreMarkingMarkingSetAddOn オブジェクトなど) にアクセスできます。

注: 分散トランザクションを使用する場合は、ユーザー開始トランザクションで GCD ベースのオブジェクトを更新しないでください。このように更新すると、トランザクションが完了するまで、すべてのサーバーのすべてのスレッドが待機状態になる可能性があります。

FileNet P8 のドメイン構造

FileNet P8 ドメインからこのドメインの構造にアクセスするには、Domain オブジェクトに対するメソッドを呼び出します。ドメインの構造は、次のエンティティーで構成されています。

  • Site - ドメインには 1 つ以上の構成済みサイトを組み込むことができます。各サイトは固有の名前で識別され、各サイトにはサーバーとリソース (オブジェクト・ストア、索引エリア、ストレージ域、コンテンツ・キャッシュなど) が関連付けられています。同一地域内にある関連リソース・オブジェクトには、同じ Site プロパティーが設定されます。

    地理的に分散した環境の Content Engine サーバーは、ユーザー要求の処理時に、要求の処理に必要なリソースを判別し、これらのリソースのサイト情報を利用して要求の最適な処理方法を判別します。サイト情報により、コンテンツの取得とアップロードの処理にコンテンツ・キャッシュを使用するかどうか、および要求の処理に必要なリソースに地理的に近い位置にある別のサイトのサーバーに要求を転送するかどうかが判別されます。 Site の CanForwardRequests プロパティーを設定して明示的に有効にしない限り、デフォルトでは、Site では要求転送が無効に設定された点に注意してください。(要求転送の詳細については、「Content Engine Administration」資料の『要求転送の概念 (Request Forwarding Concepts)』を参照してください。) 要求転送が必要な場合、サーバー側で自動的に処理され、クライアント・アプリケーションでは特別の操作が不要な点に注意してください。この機能に対してクライアントは、Connection を初期化する URI のみを変更できます。

    Content Engine サーバーが初期化され、GCD が作成されると (通常は FileNet P8 のインストール時)、Site クラスのデフォルト・インスタンス「Initial Site」が作成され、Domain.DefaultSite プロパティーにより参照されます。 別のサイトが明示的に指定された場合を除き、ドメインに追加される仮想サーバー、サーバー・インスタンス、およびリソース (オブジェクト・ストア、ストレージ域など) は、DefaultSite に割り当てられます。 システム管理者特権を持つユーザーは、必要に応じて Domain.DefaultSite を別のデフォルト・サイトに変更できます。

  • VirtualServer は、サーバー・インスタンス・グループを管理する論理エンティティーを表します。複数のサーバー・インスタンスを 1 台の物理マシン上で実行するか、または個別のマシンにデプロイすることができます。仮想サーバーは、1 つまたは複数のサービスを提供するために論理的に連携する複数のサーバー・インスタンスで構成されています。Content Engine のクライアントは、特定の ServerInstance ではなく VirtualServer と対話します。VirtualServer が 1 つの ServerInstance で構成された場合、この 2 つは機能的に同等です。VirtualServer が複数のサーバー・インスタンスで構成された場合、クライアント要求は個々の ServerInstance に分散されます。これにより、スケーラビリティーと高可用性が実現します。クライアントは、要求を処理する ServerInstance を認識しません。

    複数のサーバー・インスタンスが 1 つの VirtualServer として実行するように構成された場合、着信要求をサーバー・インスタンスに分散するサード・パーティー (FilNet 以外) の負荷分散メカニズムが必要です。これは、Java Platform, Enterprise Edition アプリケーション・サーバーのクラスター化実装でも、または外部のハードウェアまたはソフトウェアの負荷分散製品でもかまいません。 いずれの場合でも、サード・パーティーの負荷分散構成ツールを使用する管理者が、VirtualServer の負荷分散を構成します。

    システムの初期化および起動中に、アプリケーション・サーバーの構成トポロジーまたは特定のシステム・プロパティーに基づいて、VirtualServer オブジェクトが動的に作成されます。保管された VirtualServer オブジェクトの取得については、Content Engine リファレンス・ヘルプを参照してください。

  • ServerInstance は、アプリケーション・サーバーで実行される Java Virtual Machine (JVM) の 1 つのインスタンスを表します。連携して動作する 1 つ以上の論理接続サーバー・インスタンスが仮想サーバーを構成します。 1 つ以上の仮想サーバーが、FileNet P8 ドメインのサイトを構成します。システムの初期化および起動中に、アプリケーション・サーバーの構成トポロジーまたは特定のシステム・プロパティーに基づいて、ServerInstance オブジェクトが動的に作成されます。

    ServerInstance.HostNames プロパティーの値を取得して、サーバー・インスタンスに関連付けられた DNS ホスト名をリストできます。多くの場合、このプロパティーには単一のホスト名が取り込まれますが、マルチホーム・マシンの場合には IP アドレスごとに異なる DNS 名が取り込まれることがあります。ご使用のアプリケーション内のホスト名のリストを表示すると、管理者はこのリストを利用して、特定のサーバー・インスタンスをホストしているマシンを識別できます。

  • SubsystemConfiguration - サーバー階層内の独立したレベル (DomainSiteVirtualServer、および ServerInstance) ごとに、関連する構成オブジェクトが多数あります。独立レベルで使用可能な構成オブジェクトはすべて、「host」独立オブジェクトの依存オブジェクトの SubsystemConfigurationList コレクションとして表現されます。コレクションの各 SubsystemConfiguration エレメントは、サーバー階層を基準にして構成可能な特定の機能領域またはサブシステムに関連する構成オブジェクトを表します。 各構成オブジェクトには、特定のサブシステム領域のさまざまな構成オプション (コンテンツ・キャッシュ、サーバー・キャッシュ、トレース・ロギングなど) を定義する属性が 1 つ以上含まれています。 Domain 作成時に、すべての構成オブジェクトの適切なデフォルト値が Domain レベルでサーバーにより作成されます。これらのデフォルト値を変更しない場合、または下位レベルでオーバーライドする場合は、デフォルト値は引き続き有効です。
  • System add-on は、コア Content Engine コンポーネントの製品拡張です。これらの機能拡張は、特定の機能をサポートするプロパティーおよびクラスで構成されています。アドオンは、FileNet P8 と互換性がある FileNet 以外の製品であるか、または機能追加の目的で FileNet から提供されます。アドオンのインスタンスを作成すると、このインスタンスが FileNet P8 GCD データベースに自動的に登録されます。
  • Marking は、マーキング制御プロパティーに割り当てられる値の定義を表します。Marking により、元々はレコード管理市場向けに設計された、オプションのセキュリティー層が、追加で提供されます。ただし非レコード管理アプリケーションにもこのセキュリティーを適用することができます。Marking では、特定のプロパティー値に基づいてオブジェクトへのアクセスを制御できます。すべての Marking オブジェクトの定義は、MarkingSet に含まれています。Marking と MarkingSet は GCD に格納されるため、FileNet P8 ドメインのすべてのオブジェクト・ストアにおいて使用可能であり、整合性があります。
  • PEConnectionPoint は、Process Engine 要求をアイソレート・リージョン (IsolatedRegion インスタンス) にルーティングします。この情報は GCD で永続化されます。複数の PEConnectionPoint インスタンスが同一アイソレート・リージョンを参照することがあります。定義された接続ポイントのセットは、Domain.PEConnectionPoints プロパティーに反映されます。

FileNet P8 ドメインへの接続

FileNet P8 ドメイン内のオブジェクト・ストアへの参照を取得するには、ドメインに接続する必要があります。Connection オブジェクトは、FileNet P8 ドメインへの論理接続を表し、FileNet P8 ドメインで実行される Content Engine サーバー上で操作を実行するために必要な構成オプションなどの情報が含まれています。

Connection オブジェクトには、Content Engine サーバーとの通信を確立する十分な情報が含まれています。この情報は URI により保持され、サーバー通信に使用するトランスポート・プロトコル (接続タイプ)、ホスト名、およびポート番号が含まれています。接続失敗に関連する例外の原因として最も多いのが、誤った構成 (環境と Connection オブジェクト内の情報が矛盾したなど) です。例えば、Connection オブジェクトにより保持される URI に EJB トランスポート・プロトコルが指定されたが、EJB JAR ファイルがクラスパスに含まれていないと、API から例外がスローされます。

Connection オブジェクトを作成するには、Factory.Connection クラスに対して静的メソッドの 1 つを呼び出します。ドメインへの接続を示すサンプル・コードについては、「接続の取得」を参照してください。

複数ドメイン

組織では、ドメインが依存する物理的インフラストラクチャーおよび物理的ストレージのリソースを保守しています。しかしながら、FileNet P8 のインストールは単一ドメインに限定されません。物理的インフラストラクチャーおよび物理的リソースを共有する、論理的に異なる複数ドメインをセットアップできます。ドメインが標準のスタンドアロン・ドメインではなくマスター・ドメインである場合、マスター・ドメインによって管理される、テナント・ドメインと呼ばれる複数ドメインをセットアップできます。

ドメインのタイプは、その読み取り専用の DomainType プロパティーによって示され、スタンドアロン、マスター、テナントの 3 つのタイプのいずれかになります。

  • スタンドアロン: スタンドアロン・ドメインは標準ドメインであり、テナント・ドメインの作成を許可しません。FileNet P8 のインストールがスタンドアロン・ドメインを使用してインストールされた場合、追加のドメインは作成できません。
  • マスター: マスター・ドメインは、オプションとして 1 つ以上のテナント・ドメインを作成することを許可します。テナント・ドメインは、その物理的インフラストラクチャーおよび物理的リソースを共有します。マスター・ドメインには、マスター・ドメインとそのテナント・ドメインの構造を表すエンティティーのマスター・インスタンス (例えば、Site、VirtualServer、ServerInstance、SubsystemConfiguration) が含まれます。サービス・プロバイダーはこのマスター・インスタンスを使用して、複数のテナント・ドメインを構成および管理します。
  • テナント: テナント・ドメインは、マスター・ドメインの物理的インフラストラクチャーおよび物理的リソースを共有しますが、API にはスタンドアロン・ドメインとして表示されます。各テナント・ドメインには固有のレルムおよびディレクトリー構成があり、他のすべてのテナント・ドメインから独立し、分離されています。マスター・ドメインとそのテナント・ドメインの構造を表すエンティティーは、読み取り専用としてコピーしたものが各テナント・ドメインで使用可能です。

サポートされるシナリオに関する重要な情報を含め、複数ドメインのサポートについての詳細は、複数ドメインのシナリオを参照してください。

基本クラスとインターフェース

Content Engine API で使用可能なメソッドの多くは、継承により開示されます。一連の基本クラスとインターフェースには、継承される基本機能が備わっています。

EngineObject クラス

EngineObject オブジェクトは、Content Engine が認識する任意のオブジェクトです。これには、リポジトリー外部のオブジェクトも含まれます。 リポジトリーの外部に存在するオブジェクトの例としては、DomainMarkingSetObjectStore、および User オブジェクトなどがあります。

EngineObject インターフェースは、ほとんどの Content Engine API インターフェースの派生元である最上位インターフェースを表します。一般に EngineObject を直接操作することはありません。このインターフェースのサブクラスのインスタンスを操作します。これらのサブクラスは、独立オブジェクトと依存オブジェクトに分類されます。 このインターフェースは、いくつかの基本的な機能、例えば Content Engine サーバーとの通信に使用され、オブジェクトのクラス情報やプロパティー情報を取得する Connection オブジェクトの取得、などの機能を提供します。

以降のトピックでは、EngineObject のいくつかの主要なサブクラスについて簡単に説明します。

IndependentObject

IndependentObject は、固有の独立した識別情報を持つ EngineObject を表します。このオブジェクトを、DependentObject オブジェクト (別のオブジェクトのスコープ内にのみ存在可能な EngineObject) と比較してみてください。 IndependentObject には常に、オブジェクトの識別情報を提供する ObjectReference があります。

IndependentObject をサーバーからフェッチするには、InstantiatingScope.fetchObject 呼び出しまたは Factory.<classname>.fetchInstance 呼び出しを使用しますが、依存オブジェクトは、別のオブジェクトのプロパティーを使用してのみフェッチされます。

DependentObject

DependentObject は、別のオブジェクトのスコープ内にのみ存在可能な EngineObject を表します。 固有の独立した識別情報を持つ IndependentObject とは異なり、依存オブジェクトの識別情報とセキュリティーは親オブジェクトから派生します。依存オブジェクトはサーバーから IndependentObject のプロパティーとしてのみフェッチ可能であり、サーバーに保存できるのは IndependentObject の子として追加される場合に限ります。 このような依存関係の例として、ContentElement オブジェクトがあります。コンテンツ・エレメントは、永続化前に特定の Document または Annotation オブジェクトに追加しておく必要があります。 その他の例としては、PermissionsPropertyDefinitions、および Choices などがあります。すべての DependentObject のリストについては、API リファレンス・ヘルプを参照してください。

DependentObject タイプには、対応するリスト・タイプのコレクション・インスタンスがあります (ContentElementListPermissionList、および ChoiceList など)。DependentObjectDependentObjectList に割り当てられ、DependentObjectListIndependentObject に割り当てられます (例えば Document にはタイプ ContentElementList の ContentElements プロパティーがあり、ClassDescription にはタイプ PropertyDescriptionList の PropertyDescriptions プロパティーがあります)。

DependentObject オブジェクトと DependentObjectList オブジェクトは再利用できません。すなわち、フェッチしたオブジェクトの DependentObject オブジェクトまたは DependentObjectList オブジェクトを別のオブジェクトに再割り当てしてはなりません。 1 つの親オブジェクトに割り当てた後で、別の親オブジェクトに割り当てることはできません。例えば、あるオブジェクトの Permission オブジェクトをフェッチした場合、別のオブジェクトに対して直接この同じ Permission オブジェクトを使用しないでください。 このように再利用しようとすると、結果が予測不能になります。場合によっては、悪影響が出ないこともあります。操作は正常に完了したように見えても、呼び出し元が予期しない結果が生じることがあります (オブジェクトの保存中にエラーが発生するなど)。あるいは、試行した操作が失敗し、その症状の診断が困難になることがあります。

既に割り当て済みの DependentObject オブジェクトを別の親オブジェクトに割り当てようとすると、警告メッセージがクライアント・トレース・ログに書き込まれます。

IndependentlyPersistableObject

IndependentlyPersistableObject は、直接作成、更新、削除できる永続化可能な IndependentObject を表します。このインターフェースは、サブインターフェースに対していくつかの基本機能 (オブジェクトの保留アクション・リストの変更、オブジェクトのシーケンス番号の更新、アクセス権限設定の取得など) を提供します。

RepositoryObject

RepositoryObject は、オブジェクト・ストア・リポジトリーに格納されており、Content Engine が認識する任意のオブジェクトを表します。 RepositoryObject の例として Document オブジェクトがあります。対照的に EngineObject は、リポジトリー外部のオブジェクトも含め、Content Engine が認識する任意のオブジェクトです (DomainObjectStore など)。

一般に RepositoryObject を直接操作することはなく、そのサブクラスのインスタンスを操作します。

Subscribable オブジェクト

Subscribable オブジェクトは、Subscription クラスに基づくオブジェクトにより表されるイベント・サブスクリプションのターゲットとして機能します。 Subscribable は、サブスクリプション・ターゲットとして使用できる各種派生インターフェースの基本インターフェースです。Subscribable オブジェクトをサブスクリプション・ターゲットとして設定するには、Subscription オブジェクトの SubscriptionTarget プロパティーを使用します。

Containable オブジェクト

Containable オブジェクトは、包含可能なすべてのオブジェクトの基本クラスを表します。Folder オブジェクトを除き、すべての Containable サブクラスは参照によって包含されます。 Folder オブジェクトとそのサブクラスは、Folder オブジェクトに直接包含するか、または参照により包含することができます (ReferentialContainmentRelationship クラスまたは DynamicReferentialContainmentRelationship クラスを参照)。

注: 参照により包含されたフォルダーの使用は推奨されません。これは、多くのアプリケーションでこのようなフォルダーの使用が予期されていないためです。

Versionable オブジェクト

Versionable オブジェクトは、インスタンスがバージョン管理可能なクラスの基本クラスを表します。Versionable オブジェクトのバージョン管理が有効な場合 (オブジェクトの IsVersioningEnabled プロパティーが true に設定された場合)、オブジェクト・ストア内でこのオブジェクトに複数のバージョンを関連付けることができます。バージョン管理可能なオブジェクトは、チェックアウトして編集した後 (編集操作は任意)、メジャー・バージョンまたはマイナー・バージョンとしてチェックインできます。メジャー・バージョンは、現行リリース・バージョン (現行バージョンが最新のメジャー・バージョンである場合)、または以前にリリースされたが置換済みのバージョンのいずれかです。マイナー・バージョンは、処理中バージョン (最新のマイナー・バージョンの場合)、または置換済みの古い処理中バージョンのいずれかです。バージョン管理可能オブジェクトをチェックアウトすると、予約オブジェクトが作成されます。この予約オブジェクトはユーザーが変更できます。チェックイン処理中に、予約オブジェクトが最新バージョンのバージョン管理可能オブジェクトになります。すべてのバージョンの Versionable オブジェクトは、関連付けられている VersionSeries オブジェクト、またはその Versions プロパティーによって戻されるコレクションからアクセスできます。

コア・オブジェクト

コア・オブジェクトとは、DocumentFolder など、API のコア・ビジネス・オブジェクトに関連するオブジェクトです。 コア・オブジェクトに関連付けられているインターフェースとクラスは、Java API コア・パッケージと .NET コア名前空間に含まれています。コア機能には、オブジェクトをインスタンス化するファクトリー・クラスも含まれています。いくつかの最も重要なコア・クラスおよびインターフェースについて以降のセクションで説明します。

Connection

Connection オブジェクトには、アプリケーションが FileNet P8 ドメインとそのリソースに接続するために必要な情報が含まれています。接続を確立するには、Factory.Connection.getConnection (Java) または Factory.Connection.GetConnection (.NET) を呼び出します。(「基本手順」を参照。)

ObjectStore

オブジェクト・ストアは、独立したドメイン・スコープ・オブジェクト (GCD 内で定義されたオブジェクト) です。リソースへのアクセスを提供します。リソースには、ドキュメント、フォルダー、カスタム・オブジェクト、クラス記述、プロパティー説明、セキュリティー・ポリシー、およびその関連メタデータなどの Content Engine オブジェクトがあります。 Content Engine サーバー上で、フォルダー、ドキュメント、およびカスタム・オブジェクトが格納されており、アクセスおよび管理されるロケーションを表します。

ObjectStore インターフェースのメソッドを使用して、オブジェクト・ストア内での新規オブジェクトの作成と格納、オブジェクトに関する情報の取得、オブジェクト・ストアにインストールされた機能アドオンの取得を実行できます。

Folder

フォルダーはファイルされたオブジェクトに対して、使い慣れたファイル・システム・セマンティクスと同様のアクセスを提供します。Folder オブジェクトは、包含可能な他のオブジェクトを格納できるコンテナーですが、それ自体のコンテンツ・データを持つことはできません。Folder オブジェクトとそのサブクラスは参照により包含可能ですが、(Folder に) 直接包含することができる唯一の Containable サブクラスです。その他の Containable サブクラスはすべて、ReferentialContainmentRelationship クラスまたは DynamicReferentialContainmentRelationship クラスを使用して参照により包含することができます。

その他の重要なフォルダーの特性を以下に示します。

  • フォルダーはバージョン管理できません。
  • 参照により包含されたフォルダーは、階層型索引検索の対象にはできません。

コンテナー階層の最上位は、自動的に作成されたルート・フォルダーです。収容 (親) フォルダーには、複数の子フォルダーを含めることができますが、子フォルダーに対して親フォルダーは 1 つだけです。直接包含されるフォルダーを作成するには、親フォルダーに対してサブフォルダーを作成するメソッドを呼び出します。

カスタムのオブジェクトおよびドキュメントは、常に参照として包含されます。参照により包含されるオブジェクトの場合、コンテナー・モデルは N:M 関係 (多対多関係) です。1 つのフォルダーに任意の数の包含対象を含めることができます。また、1 つの包含可能オブジェクトが任意の数のフォルダー内に含まれることがあります。すなわち、1 つのオブジェクトが 1 つのフォルダー内に複数含まれることがあります。

ドキュメント

Document オブジェクトは、Content Engine オブジェクト・ストアに格納されているドキュメントの 1 つのバージョンを表します。基本的にドキュメントとは次の 2 つのものを指します。

  • ユーザーが作成したドキュメント。 このドキュメント (ワードプロセッサー・ファイル、グラフィック、スプレッドシート、html ファイルなど) は、オブジェクト・ストアのコンテンツ・ストアまたは外部 (URL アドレスの参照先 Web ページなど) に格納されます。 いずれの場合でも、これは Document オブジェクトのコンテンツ・エレメントと呼ばれます。
  • ユーザー・ドキュメントを記述するオブジェクト。 このオブジェクトは、Content Engine がユーザー・ドキュメントの特定のバージョンを識別および検出するときに使用するものであり、Document オブジェクトと呼ばれます。

ドキュメントにはコンテンツ・エレメントがまったく関連付けられていないか、または 1 つ以上のコンテンツ・エレメントが関連付けられています。ドキュメントにコンテンツが含まれている場合、このコンテンツは Content Engine コンテンツ・ストアに格納されるか (コンテンツ転送エレメントと呼ばれます)、または外部に格納されます (コンテンツ参照エレメントと呼ばれます)。これらのエレメントはそれぞれ、ContentTransfer オブジェクトと ContentReference オブジェクトにより表されます。コンテンツが含まれているドキュメントの場合、Content Engine API では、1 つ以上のコンテンツ転送エレメントが含まれているドキュメント、1 つ以上のコンテンツ参照エレメントが含まれているドキュメント、またはコンテンツ転送エレメントとコンテンツ参照エレメントが混在するドキュメントを作成できます。

ドキュメントはバージョン管理可能です。Content Engine では、バージョン管理無効、単一レベルのバージョン管理、2 レベルのバージョン管理の 3 つのバージョン管理レベルをサポートします。ドキュメントを Content Engine オブジェクト・ストアにチェックインしてバージョンを設定すると、VersionSeries オブジェクトがドキュメントに関連付けられます。このオブジェクトには、ドキュメントのすべてのバージョンが含まれます。

アノテーション

Annotation オブジェクトは、オブジェクト (親) に対し、アノテーションまたは脚注のために添付可能な付随情報を表します。Annotation オブジェクトにより、被包含可能オブジェクト (カスタム・オブジェクト、ドキュメント、フォルダー) に追加情報をリンクできます。アノテーションの変更や削除は、その親オブジェクトとは関係なく実行できます。ただし、親オブジェクトから切り離してアノテーションのバージョンを作成することはできません。設計上、親オブジェクトが削除されるとアノテーションも削除されます。

ドキュメントのアノテーションは、単一のドキュメント・バージョンのみに割り当てられます。割当先のドキュメントが更新され、新しいバージョンが作成されても、アノテーションのバージョンの作成や移行は行われません。

CustomObject

CustomObject オブジェクトは汎用的なオブジェクトで、継承のセマンティクスを持ちませんが個別に保護可能で、オブジェクト・ストアに永続化可能です。カスタム・オブジェクトの特徴としてコンテンツを持たず、バージョン管理できず、ライフ・サイクル機能をサポートしません。フォルダーへの格納や注釈の付加は可能です。

WorkflowDefinition

ワークフロー定義は Process Designer アプリケーションを使用して作成された XML ドキュメントであり、ビジネス・プロセス完了までに必要なステップの流れを電子的に表します。 ワークフローを実行するたびに Process Engine が使用するプロセス・テンプレートとしても機能します。 ステップは、ビジネス・プロセス内のそれぞれの特定のアクティビティーまたはタスクを表します。ステップの仕様には、ステップの作業を行う担当者、参加者が使用するステップ・プロセッサー・アプリケーションの起動元、必要な添付ファイル (ドキュメント)、必要なデータ、参加者が選択可能な対応などのオプションが含まれています。 ルーティング・ロジックにより、あるステップから次のステップに作業を進めるときのルートが指定されます。

一般に、ワークフロー定義が完了したら、作成者はワークフロー定義を Process Engine サーバーに転送し、WorkflowDefinition オブジェクトとして Content Engine オブジェクト・ストアに保存します。 その後、ワークフロー定義をターゲット・オブジェクトにリンクできます。これにより、ワークフローを手動で開始するか、またはイベントから開始することができます。

WorkflowDefinition オブジェクトは、Document オブジェクトと同様の方法で処理できます。ドキュメントに対して実行できるアクションは、ワークフロー定義に対しても実行できます。ワークフロー定義のチェックアウト、チェックイン、コンテンツの設定、フォルダーへのファイリング、および削除が可能です。 また、ワークフロー定義に関連付けられている WorkflowSubscription オブジェクトを取得することもできます。

コレクション

Content Engine コレクションとは、関連するエレメントのグループで、List 型と Set 型の 2 つがあります。コレクションの名前により、型が識別できます。例えば DocumentSetDocument オブジェクトのコレクションで、IdListId オブジェクトのコレクションです。詳細については、『コレクション』を参照してください。

定数

Content Engine API は、関連するタイプ・セーフな定数値のグループを定義するクラスを提供します。クラス名により列挙の目的が示され、個々の値の名前によりその用途が示されます。例えば CheckinType クラスの定数 MAJOR_VERSIONMINOR_VERSION は、チェックイン・タイプがメジャー・バージョンであるか、またはマイナー・バージョンであるかをそれぞれ識別します。

認証

認証とは、ユーザーが提示した認証情報に基づいてユーザー識別情報を検証することです。各ユーザーの識別の確立は、クライアント/サーバー・ベース・システムにおける重要な最初のステップです。FileNet P8 では、ユーザー名/パスワードの組み合わせの受け渡しによる認証を超えたオプションが提供されます。このオプションでは、Java 認証・許可サービス (JAAS) 標準と Web Services Security (WS-Security) 標準を使用します。JAAS 標準により、Java Platform, Enterprise Edition 環境でのセキュリティー上の相互運用フレームワークが確立し、WS-Security 標準により、異機種のクライアントとサーバーが Web サービス・インターフェースを介して通信する環境でのセキュリティー上の相互運用フレームワークが確立します。2 つの標準を使用することで、幅広い認証オプションを FileNet P8 に統合できます。

今後 Content Engine を使用する可能性がある各ユーザーは、既存のエンタープライズ・ディレクトリー・サービス内で定義したセキュリティー・プリンシパルであることが前提となります。ユーザーは JAAS により認証 されます。JAAS の「Subject」内で認証識別情報が定義されます。Content Engine API のクライアントが、アプリケーション・サーバーで既に実行中のコードである場合、クライアントは既に認証されており、Subject が関連付けられています。アプリケーション・サーバー外部のクライアントの場合、アプリケーション、Content Engine API、または CEWS リスナーが、クライアントの認証情報を使用して JAAS 認証を実行し、Subject を生成します。

ユーザーがシステム内で認証された後、そのユーザーが発行する各要求には、必ずそのユーザーの識別情報 (JAAS Subject) が付加されます。(呼び出し元の代わりに API がこれを透過的に処理します。)認証済みユーザーが Content Engine サーバーを対話型で操作するときに、認可メカニズムにより、ユーザーがシステム内でオブジェクトを作成、表示、または操作するアクセス・レベル (設定した場合) が判別されます。

JAAS Subject の取得

ターゲット・アプリケーション・サーバーでサポートおよび信頼する JAAS Subject の取得方法については、接続の取得を参照してください。.NET API で JAAS Subject と類似したクラスは Microsoft.Web.Services3.Security.Tokens.SecurityToken であることに注意してください。JAAS Subject は認証されたユーザーを表しますが、Microsoft SecurityToken は、Content Engine サーバーでの CEWS 要求の処理時に (JAAS ログインの実行による) ユーザー認証に使用できる認証情報を維持します。

Kerberos サポート

Content Engine は、JAAS が使用できない環境でのシングル・サインオン (SSO) に Kerberos 認証を使用できます。SSO を使用すると、例えば初期 Windows ログオンでユーザーの識別が安全に確立されると、後続のログオンではユーザーが認証情報を再入力する必要がありません。シングル・サインオンと Kerberos サポートの詳細については、入手可能な Kerberos 資料と、Enterprise Administration ヘルプの『Security Guide』を参照してください。Content Engine 環境での Kerberos の設定方法については、「セキュリティーの操作」を参照してください。

カスタム・ログイン・モジュール

Content Engine サーバーは、EJB トランスポートおよび CEWS トランスポートの 2 つのトランスポート・プロトコルを介して着信要求を受け入れます。EJB トランスポートを介した認証は JAAS により拡張可能です。呼び出し元が EJB レイヤーにアクセスする前に、Java Platform, Enterprise Edition アプリケーション・サーバーにより呼び出し元が認証されます。

Content Engine Web サービスでは、Web Service Security (WS-Security) Username Token プロファイルと Kerberos プロファイルが直接サポートされています。その他の WS-Security 準拠手法のサポートも、Content Engine Web Service Extensible Authentication Framework (WS-EAF) を介して追加できます。WS-EAF は、プラグ可能な CEWS トランスポート認証メカニズムです。WS-Security OASIS 標準に基づいており、JAAS 標準により実装された認証情報を受け入れます。開発者は、WS-Security 標準の定義に従ってバイナリー・セキュリティー・トークンを処理するカスタム・ログイン・モジュールを作成できます。

カスタム・ログイン・モジュールの作成については、「IBM FileNet Content Engine Web Service Extensible Authentication Framework Developer's Guide」を参照してください。

許可

認証の完了後に、永続化されたオブジェクトへのアクセスの許可が検査されます。 一部の例外を除き、個別に永続化されたオブジェクトには固有のセキュリティー設定があります。例えば、ドキュメントのバージョンが複数ある場合、各ドキュメント・バージョンにはそれぞれ固有のセキュリティー設定があります。これらのセキュリティー設定により、そのオブジェクトへのユーザー (またはグループ) のアクセスが制御されます。Content Engine で管理される資産は保護されており、ユーザーのアクセス権限に基づいて表示または変更が可能になります。認可の詳細については、「認可」を参照してください。

オブジェクトのインスタンス化

Content Engine の Java API および .NET API はインターフェースの形で定義されるため、一般に標準の「new」を使用して新規オブジェクトをインスタンス化できません。Content Engine API の Factory クラスで定義されたファクトリー・クラス・メソッドを使用して、タイプに対応したオブジェクトをインスタンス化する必要があります。以下のセクションでは、ファクトリー・メソッドの使用法を説明します。また、オブジェクトのスコープを他のオブジェクトに設定する方法についても説明します。

ファクトリー・メソッド

Content Engine API は、静的内部クラスを持つ Factory クラスを提供します。この静的内部クラスの名前は、Content Engine API の標準的なタイプに対応しています (Factory.Document など)。 Factory のメソッドは、タイプ・セーフであり便利です。オブジェクト・タイプを指定する必要がなく (エラーが発生する可能性を回避でき)、Factory メソッドの結果を必要なタイプにキャストする必要がないため、実行時ではなくコンパイル時に、戻されたタイプでプログラミング・エラーを捕捉できます。

既知のオブジェクト・タイプのインスタンスを作成または取得するには、Factory クラスの特定のオブジェクト・タイプに対応する静的メソッドを使用します。(オブジェクト・タイプが事前に判明していない場合は、「スコープ限定」を参照してください。)オブジェクトのインスタンス化に使用できる Factory メソッドは、createInstancefetchInstance、 および getInstance (『フェッチなしインスタンス化』で使用されるメソッド) です。

createInstance メソッドは、新規サーバー・オブジェクトを参照するオブジェクトのインスタンス化に使用できます。オブジェクトのインスタンス化の時点で、サーバーへのラウンド・トリップは行われず、オブジェクトはリポジトリーには格納されません。代わりに、インスタンスに「Create」保留アクションが関連付けられます。サーバーへのラウンド・トリップは、後のコミット (保存) ステップで実行されます。

fetchInstance メソッドでは、オブジェクトをインスタンス化するために、最初に Content Engine サーバーへのラウンド・トリップを行い、プロパティー値を取得 (「フェッチ」) します。インスタンス化オブジェクトには、フェッチ時点での現行の UpdateSequenceNumber (USN) の値が含まれています。USN により、オブジェクトが同時更新から保護されます。オブジェクトが更新されるたびにその値が増加します。オブジェクトが更新されると、取得されたオブジェクトの USN が、現在永続化した USN 値と比較されます。値が一致しないと、操作は失敗します。オブジェクトの UpdateSequenceNumber プロパティーを調べ、以前のオブジェクトのフェッチ以降このオブジェクトが変更されたかどうかを確認できます。USN 値に関わらずクライアントで更新を強制的に永続化するには、setUpdateSequenceNumber(null) を呼び出します。USN が null の場合、更新時のサーバー・サイド・チェックが省略されます。この手法はオブジェクトに対して delete() または checkout() を呼び出す際に使用できます。

フェッチなしインスタンス化

getInstance メソッドは、既に存在すると想定されたサーバー・オブジェクトを参照するオブジェクトをインスタンス化するために使用されます。Content Engine サーバーでオブジェクトが存在するかどうかが検証されず、サーバーへのラウンド・トリップを行う関数 (プロパティー値のフェッチなど) がオブジェクトに対して実行されるまでは、サーバーへのラウンド・トリップは行われません。これは「フェッチなしインスタンス化」と呼ばれ、パフォーマンス上の理由から、オブジェクトが受動的に機能する場合 (オブジェクト値を持つプロパティーのターゲット値として使用される場合など) に便利です。

getInstance でインスタンス化されるオブジェクトは、このオブジェクトの永続 UpdateSequenceNumber を認識しません。フェッチなしインスタンス化オブジェクトを保存すると、UpdateSequenceNumber プロパティーの値は null に設定され、サーバー・サイドでの更新チェックが省略されます。これにより、クライアントがオブジェクトのコピーをインスタンス化した後で、サーバーでオブジェクトに対して行われた中間更新に関係なく、オブジェクトを保存できます。

スコープ限定

オブジェクトのスコープとは、オブジェクトの「エンクロージング・コンテキスト」です。すなわち、あるオブジェクトの派生元となるオブジェクトです。例えば DomainSite または ObjectStore の親スコープであり、ObjectStoreDocument の親スコープです。

クラスは、インスタンス・オブジェクトの位置によって特徴付けられます。あるオブジェクトは ObjectStore 内に位置し、他のオブジェクトは ObjectStore の「上」、すなわちオブジェクト・モデル内の上位レベルに位置します。ClassDescription のスコープがその特定のロケーションに限定され、そのロケーションに関連付けられたオブジェクトはスコープ・オブジェクトになります。 ClassDescription.getScope() を呼び出すと、ClassDescription が記述するクラスのタイプに基づいて、次のいずれかが返されます。

  • Domain
  • ObjectStore
  • null (Realm および EntireNetwork の場合)

スコープ・オブジェクトと、これらのスコープ・オブジェクトにスコープが限定されるオブジェクトを次の表に示します。

スコープ・オブジェクト スコープ限定オブジェクトのタイプ
EntireNetwork EntireNetwork、Domain、Realm
Realm User、Group
Domain ObjectStore、MarkingSet、Site、VirtualServer、ServerInstance
ObjectStore 個別の RepositoryObject タイプ、ClassDescription

EntireNetwork は階層のルートで自分自身をスコープ限定する、DomainRealm のスコープ・オブジェクトです。ClassDescription オブジェクトのスコープ・オブジェクトは、この ClassDescription オブジェクトで記述されるインスタンスのスコープ・オブジェクトと同一です。 例えば CustomObject オブジェクトが ObjectStore インスタンス「OS1」にスコープ限定される場合、このカスタム・オブジェクトの ClassDescription も「OS1」にスコープ限定されます。

ほとんどの場合、そのタイプについて理解するオブジェクトのインスタンスを作成または取得します。ただし、オブジェクトのタイプについての知識がない場合は、ObjectStoreDomain の両方により拡張される InstantiatingScope を使用してオブジェクトをインスタンス化できます。

InstantiatingScope インターフェースは、スコープ内の独立オブジェクトをインスタンス化する汎用手法を提供します。InstantiatingScope では、スコープ内のオブジェクトのみをインスタンス化できます。例えば Document オブジェクトは ObjectStore のスコープ内にありますが、Domain のスコープ内にはありません。このインターフェースは、インスタンス化するオブジェクトのタイプについての知識がユーザーにない場合に、オブジェクトを作成または取得するメソッドを提供します。オブジェクトを作成または取得するときには、クラス名と (取得の場合) オブジェクト識別子またはパスを指定します。戻されたオブジェクトを適切なタイプにキャストする必要があります。

オブジェクトの保存

API では、オブジェクトに対するアクションが組み合わせられ、1 つのサーバー呼び出しが作成されます。オブジェクトの保存時 (バッチ処理の場合はコミット時) に、組み合わせられた呼び出しが実行されます。 保存操作の実行前までにオブジェクトに対して累積されたアクションは、保留アクションと呼ばれます。

API での保留アクションの処理方法が原因で、オブジェクト保存操作が予期しない状況で失敗することがあります。 保留アクションは、サーバー上のオブジェクトに対して保存 (コミット) されていない意図的な変更を表します。基礎オブジェクトを変更するメソッドを呼び出すと、アクションに対応する PendingAction のサブクラスが作成されます。例えば Document.checkout を呼び出すと、PendingActionCheckout サブクラスが作成されます。保留アクションは、基礎オブジェクトの保留アクションの順序付きリスト (自動生成される PendingActions コレクション) に追加されます。その後オブジェクトに対して実行されるアクション (ロックとアンロック、クラスの変更、フリーズ、削除など) ごとに、保留アクション・リストに対応する項目が追加されます。例えば save メソッドの呼び出しやバッチのコミット (バッチ操作の場合) によってオブジェクトをコミットすると、基礎オブジェクト (およびその保留アクションのコレクション) がサーバーに送信され、オブジェクトの保留アクション・リストでの順序に従って変更がリポジトリーに書き込まれます。呼び出しで行われる一連のアクションのいずれかが失敗すると、一連のアクション全体が失敗します。save メソッドでは常に、(アトミック・トランザクションと同様に) 要求に含まれているすべての作業が完了するか、または作業が一切完了しないかのいずれかです。

保存中に失敗が発生することを防ぐには、アプリケーション・プログラムで次のいずれかの手法を採用します。

  • refresh を呼び出してから delete を呼び出す。その後 save を呼び出す。
  • 全探索を行い、「ダーティー」プロパティーを削除してから、save 呼び出しを使用して delete をサーバーに送信する。
  • オブジェクトのフェッチなしインスタンス化を実行し、delete を呼び出してから save を呼び出す。

オブジェクトの削除

オブジェクトに対して delete を呼び出すと、オブジェクトの保留アクション・リストに削除アクションが追加されます。オブジェクトに対して save() を呼び出すと、そのオブジェクトの保留アクション・リストが処理され、処理するリストでエラーが発生しなかった場合はオブジェクトが削除されます。トランザクションでのエラーが原因で delete が失敗する可能性がある状況についての詳細は、オブジェクトの保存の例を参照してください。

オブジェクトのシリアライズ

フォーマッターによりシリアライズできるように、すべての Content Engine Java API オブジェクトは java.io.Serializable インターフェースを実装しており、すべての Content Engine .NET API オブジェクトには SerializableAttribute が注釈として付加されています。特定のオブジェクトのシリアライズに関する補足情報を次に示します。

  • Connection オブジェクトには、Content Engine サーバー接続用 URI が含まれています。ネットワーク・トポロジーの問題が原因で、オブジェクトがデシリアライズされる時点まで、特定の URI が使用できなくなることがあります。アプリケーションとシステムの設計者には、この可能性を考慮するようお勧めします。
  • Content Engine Java API RPC には常にアクティブな JAAS Subject が必要です。このためには、周囲の JAAS 構成を使用するか、または Content Engine API の UserContext オブジェクトを使用します。いずれもシリアライズ状態の Content Engine オブジェクトには含まれないため、アプリケーションとシステムの設計者は、後続の Content Engine サーバーへのラウンド・トリップが、オブジェクトがデシリアライズされるポイントから行われるよりも前に、適切な JAAS Subject が使用可能であるようにしてください。

クライアント開始トランザクション

トランザクションは、Java API 呼び出しで EJB トランスポートによりサポートされています。(CEWS トランスポートと .NET API ではクライアント開始トランザクションはサポートされていません。) トランザクション処理は、Java Transaction API (JTA) の標準 Java Platform, Enterprise Edition トランザクション・メカニズムを使用して実装されます。アプリケーションは、1 つのトランザクション内で複数の操作を実行できます。トランザクションが失敗した場合 (1 つの操作が失敗した場合など)、JTA によりトランザクション全体のロールバックが処理されます。 Java クライアント・アプリケーションでのトランザクションのサポートをセットアップするには、標準 Java Platform, Enterprise Edition UserTransaction 呼び出し (javax.transaction.UserTransaction インターフェース) を使用します。また、使用する Connection オブジェクトでトランザクションを有効にするため、CONNECTION_PARTICIPATES_IN_TRANSACTION パラメーターを true に設定する必要があります。詳細については、Connection.setParameter メソッドと ConfigurationParameter.CONNECTION_PARTICIPATES_IN_TRANSACTION を参照してください。



最終更新日: 2015 年 10 月
gs_concepts.htm

© Copyright IBM Corp. 2015.