| Oracle® Fusion Middleware Oracle WebCenter PortalおよびOracle JDeveloperでのポータルの開発 11gリリース1 (11.1.1.8.3) E49666-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter PortalおよびOracle JDeveloperでのポータルの開発 11gリリース1 (11.1.1.8.3) E49666-03 |
|
前 |
次 |
この章では、データ・プロバイダについて紹介します。また、パーソナライズ・アーキテクチャにおけるその重要な役割について説明し、JDeveloperで作成および実行できる基本的な例を示します。この章を読了すると、カスタム・データ・プロバイダの実装方法の基礎が理解できます。
この章の内容は、次のとおりです。
データ・プロバイダは、経営管理システムや在庫管理システムなどの、外部システムから提供されるサービスとコンダクタ間の接続ポイントです。コンダクタは、シナリオと呼ばれる、スクリプト化されたコンポーネントの実行および管理のためのコンテナです。シナリオは、1つまたは複数のデータ・プロバイダが取得したデータを使用および処理します。そのため、ポータル・アプリケーションやモバイル・アプリケーションなどのクライアント・アプリケーションでそのデータを使用できるようになります。詳細は、図67-1を参照してください。
|
注意: パーソナライズで使用されるもう1つのタイプのプロバイダが、ファンクション・プロバイダです。データ・プロバイダでは、外部ソースからデータがフェッチされ、シナリオに返されますが、ファンクション・プロバイダではシナリオ内でデータがフィルタされ、変換されます。第68章「カスタム・ファンクション・プロバイダの実装」を参照してください。 |
データ・プロバイダは、パーソナライズ・アーキテクチャの中で重要なコンポーネントです。データ・プロバイダでは、ほぼすべての種類のサービスへの接続とそこからのデータの取得が柔軟に行えます。WebCenter Portalには、複数のデフォルトのプロバイダが用意されています。これらのデフォルトのプロバイダをすぐに使用開始することも、特定のユースケースに対応する独自のカスタム・データ・プロバイダを作成することもできます。
たとえば、在庫プロバイダを作成しての部品情報および在庫情報の取得、購買プロバイダを作成しての経営管理システムからの購買情報の取得、売上プロバイダを作成してのCRMシステムからの売上情報の取得などが可能です。
まずはじめに、使用するパーソナライズのユースケースで、デフォルトのプロバイダのいずれかで要件が満たされるのかどうかを確認する必要があります。デフォルトのデータ・プロバイダには、次のものがあります。
プロパティ・サービス・プロバイダ: プロパティ・サービスのデータをシナリオに統合できます。第70.5項「プロパティ・サービス・データ・プロバイダの使用」を参照してください。
CMISデータ・プロバイダ: 特にOracle WebCenter Content Serverにより提供される標準ベースのCMIS (Content Management Interoperability Services)コンテンツ・サーバーからコンテンツを取得および検索するサービスを提供します。
アクティビティ・グラフ・データ・プロバイダ: WebCenter内での分析に基づいて、ユーザーの接続に関するニーズに対して推奨事項を提供するアクティビティ・グラフ・エンジン(アクティビティ・グラフの基盤)との統合を実現します。
これらのデータ・プロバイダは、すべてのユースケースに適合するわけではありません。たとえば、レガシー・アプリケーションから一連の非標準のAPIを使用して、データを取得する必要がある場合です。その場合、カスタム・データ・プロバイダの実装が必要です。第67.4項「単純なカスタム・データ・プロバイダの実装」を参照してください。
データ・プロバイダ(デフォルト・プロバイダとカスタム・プロバイダの両方)は、図67-2に示す「起動するプロバイダのプロパティ」ダイアログにリスト表示されます。
このダイアログにアクセスするには、シナリオを作成し、そこにプロバイダの起動ノードを追加します。ノードを右クリックして、起動するプロバイダのプロパティを選択します。シナリオの作成およびこのダイアログへのアクセスの詳細は、第66.2.2項「JDeveloperでのパーソナライズされたシナリオの作成」を参照してください。
データ・プロバイダの起動方法を示す例は、第67.6項「シナリオ内のデータ・プロバイダのJDeveloperからの起動」を参照してください。
この項では、単純なカスタム・データ・プロバイダの実装方法、構成方法およびシナリオ内での起動方法について説明します。これは非常に基本的な例ではありますが、カスタム・プロバイダの開発および構成の多くの重要な側面について説明しています。
この例では、シナリオ内でコールされた場合に1つのパラメータを受け取り、サーバー・コンソールにメッセージを返す、データ・プロバイダの実装方法を示しています。次からの項では、必要なプロバイダのコードについて考察し、プロバイダのコンダクタへの統合方法、プロバイダのシナリオでの使用方法およびシナリオの実行方法について説明します。
データ・プロバイダを含む、カスタム・パーソナライズ・コンポーネントの開発の前提条件については、第2.5項「パーソナライズのためのJDeveloperの設定」で説明されています。前提条件には、プロジェクトで使用可能な、特定の必要なコンポーネントの作成も含まれます。
|
注意: この例は、JDeveloperのPortal Frameworkアプリケーションとの関連で示されています。 カスタム・データ・プロバイダの開発には、JDeveloperは必要ありません。任意のJava IDEを使用できますが、使用するプロジェクトに、必要なWebCenterパーソナライズのJARファイルおよびJavaコンポーネントをインクルードする必要があります。詳細は、第2.5項「パーソナライズのためのJDeveloperの設定」を参照してください。 |
カスタム・データ・プロバイダを作成するには、一連のJavaベースのクラスを拡張して、適切な機能が提供されるようにする必要があります。表67-1に、この例で使用されているデータ・プロバイダのクラスの早見表を示します。カスタム・プロバイダを作成する場合は、これらのクラスに精通する必要があります。デフォルトのプロバイダを使用する場合は、この基本的なアーキテクチャを理解すると役に立ちます。
表67-1 データ・プロバイダの必須のベース・クラス
| インタフェース | 主目的 |
|---|---|
|
DefaultDataProvider |
プロバイダが使用する接続構成オブジェクトをインスタンス化します。各データ・プロバイダが1つの接続を持ちます(1対1リレーションシップ)。 |
|
BaseConnectionConfig |
接続の名前を指定します。この章で後述するとおり、接続名は必須であり、 |
|
DefaultProviderConnection |
1つまたは複数のExecutableResourceオブジェクトをインスタンス化します。1つのデータ・プロバイダは、複数の実行可能なリソース・オブジェクトを参照できます(1対多リレーションシップ)。 |
|
DefaultExecutableResource |
ExecutableResourceメソッドは、データ・プロバイダに対して実行が要求された、あらゆる作業を実行します。通常、この作業には外部サービスとのやり取りが含まれます。たとえば、使用するプロバイダがメールとやり取りするよう作成されている場合、特定のメール接続情報を取得してから、getMail()メソッドおよびsendMail()メソッドを実装します。これらのメソッドは、その後でシナリオのコンテキスト内で呼出しできます。これらの概念は、この章で示されている単純なデータ・プロバイダの例を見直すと、より明確になります。 |
カスタム・データ・プロバイダの例を作成する最初の手順は、DefaultDataProviderを拡張することです。この方法は、データベースやアプリケーションなどの外部リソースに依存しないカスタム・プロバイダを、すばやく実装するために使用すると最適です。外部リソースが必要な場合は、かわりにExternalDataProviderクラスを拡張してください。
例67-1に、拡張されたDefaultDataProviderクラスのコードをリストします。Javaクラスの作成およびコンパイルの詳細は、JDeveloperでオンライン・ヘルプを参照してください。
|
ヒント: 一般的なクラスの作成手順では、「ファイル」メニューから「新規」を選択して、新規Javaクラスの作成を選択します。コードの例をファイルにコピーして保存します。「Javaクラスの作成」ダイアログで、パッケージ |
例67-1 DefaultDataProviderの拡張
package providers.data;
import oracle.wcps.conductor.annotation.ContextualProvider;
import oracle.wcps.dataprovider.base.DefaultDataProvider;
import oracle.wcps.conductor.provider.IConnection;
import oracle.wcps.dataprovider.base.IConnectionConfig;
@ContextualProvider
(
contextName="SayHelloProvider",
resourceBundle="resources.SayHelloProperties",
descriptionBundleKey="hello.provider.description",
nameBundleKey="hello.provider.name"
)
public class SayHelloProvider extends DefaultDataProvider {
public Class<?> getConnectionConfigClass()
{
return SayHelloConnectionConfig.class;
}
@Override
protected IConnection createConnection(IConnectionConfig config)
{
return new SayHelloConnection((SayHelloConnectionConfig)config);
}
}
SayHelloProviderで最初に注目すべき点は、これが注釈付きであるということです。各データ・プロバイダ・クラスには、クラス定義の直前に、次のような@ContextualProvider注釈スタンザが必要です。
@ContextualProvider
(
contextName="SayHelloProvider",
resourceBundle="resources.SayHelloProperties",
descriptionBundleKey="hello.provider.description",
nameBundleKey="hello.provider.name"
)
contextName要素には、シナリオ・エディタ・ダイアログに表示される名前を指定します。このダイアログでは、データ・プロバイダを選択できます。resourceBundle要素は、データ・プロバイダのクラス・パスに存在する、リソース・ファイルを参照します。1つのプロジェクトに複数のリソース・ファイルを指定できます。resourceBundleの値は、これらのファイルのいずれかと対応している必要があるので、注意してください。その他の注釈は、リソース・ファイル内の文字列を識別するため使用される、リソース・バンドル・キーです。リソース・ファイルは、主としてローカライゼーションをサポートします。次項、第67.4.4項「リソース・プロパティ・ファイルの作成」では、リソース・ファイルの作成について考察します。
これらのクラス・レベルの注釈を使用するには、次のクラスをインポートする必要があることに注意します。
import oracle.wcps.conductor.annotation.ContextualProvider;
図67-3に、JDeveloperのアプリケーション・ナビゲータでの新規SayHelloProvider.javaソース・ファイルを示します。ソース・ファイルがproviders.dataというパッケージ内にあることに注目してください。独自の表記規則に従って、自分が作成したパッケージです。
データ・プロバイダのソース・ファイルに配置された、クラス・レベルのJava注釈には、リソース・プロパティ・ファイルを指定します。このファイルは、存在する必要があり、かつクラス注釈で使用されるキーを格納し、その値を提供する必要があります。
|
注意: リソース・プロパティ・ファイルのパッケージは、ソース・コードまたはソース・コード・パッケージと同一の親ディレクトリ内に配置する必要があります。プロバイダ・クラスで適切に参照されているかぎり、複数のリソース・ファイルを作成できます。 |
たとえば、SayHelloProviderクラス注釈(例67-1のリスティングを参照)では、次のリソース・キーが示されていました。最初の注釈、hello.provider.nameには、シナリオ・エディタのプロバイダの起動ダイアログに表示されるように、プロバイダの名前を指定します。2番目の注釈は、要約を提供します。これもプロバイダの起動ダイアログで、プロバイダの名前の上にマウスを置くと表示されます。
hello.provider.name=SayHelloProvider hello.provider.description=Simple data provider that greets a user by name.
図67-4は、アプリケーション・ナビゲータにあるSayHelloProperties.propertiesというプロパティ・ファイルを示しています。このファイルは、resourcesというパッケージ内にあります。例67-1では、クラス注釈でリソース・ファイルがresources.DataProviderResourcesになるように指定されていました。それが図67-4に反映されています。
SayHelloProviderクラスを前述のとおり作成すると、2つのクラスが未解決であることに気づきます。次に、これらのクラスを作成します。最初のクラス、SayHelloConnectionConfigは、ベース・クラスのBaseConnectionConfigを拡張します。2番目のSayHelloConnectionは、DefaultProviderConnectionを拡張します。
|
注意: 各DataProviderクラスには、単一のConnectionクラスがあり、その属性はConnectionConfigクラス内で指定されています。 |
例67-2では、SayHelloConnectionConfigをリストします。この例では、構成する接続が存在しないため、空になっています。この例の場合、BaseConnectionConfigを拡張せずに、直接使用しても構いません。外部リソースに接続する必要のあるプロバイダを作成する場合は、このクラスはさらに重要になります。
例67-2 BaseConnectionConfigの拡張
package providers.data;
import oracle.wcps.dataprovider.base.BaseConnectionConfig;
import oracle.wcps.connection.annotation.ConnectionConfiguration;
@ConnectionConfiguration
(
connectionType="client.simple.connection"
)
public class SayHelloConnectionConfig extends BaseConnectionConfig {
public SayHelloConnectionConfig() {
super();
}
}
クラス・レベルの注釈、@ConnectionConfigurationが重要です。ここで、プロバイダの接続タイプを指定します。この注釈で指定された接続タイプは、wcps-connections.xml構成ファイルの<connection-type>要素と一致する必要があります。この構成ファイルについては、まもなく第67.5.6項「WCPS接続構成ファイルの更新」で考察します。
次のクラスのSayHelloConnectionは、DefaultProviderConnectionを拡張します。このクラスは主に、ExecutableResourceオブジェクトのインスタンス化の役割を担います。このオブジェクトは、外部APIをコールしてデータを取得するなどの、データ・プロバイダの働きをします。1つのプロバイダに複数のExecutableResourceオブジェクトを指定できますが、この例で必要なのは、1つのみです。
例67-3 DefaultProviderConnectionの拡張
package providers.data;
import oracle.wcps.conductor.provider.IExecutableResource;
import oracle.wcps.dataprovider.base.DefaultProviderConnection;
public class SayHelloConnection extends DefaultProviderConnection {
public SayHelloConnection(SayHelloConnectionConfig config) {
super(config);
}
@Override
protected void createExecutableResources()
{
IExecutableResource resource = new SayHelloExecutableResource();
executableResources.put("SimpleDataProvider", resource);
}
}
マップ・キー"SimpleDataProvider"は、任意の名前であることに注意してください。これはクラス名と一致する必要はありません。
拡張する必要のある最後のクラスは、DefaultExecutableResourceです。ExecutableResourceオブジェクトは、データ・プロバイダの主力です。これらのクラスにより、シナリオで実行されるカスタム・コードの実装が可能になります。外部ソースからデータをフェッチするプロバイダを作成する場合、その作業を実行するコードは、ExecutableResourceクラスに配置します。
|
注意: 1つの接続には、複数のExecutableResourceの実装が含まれることがあります。たとえば、ActivityGraphProviderのActivityGraphConnectionには、共通アイテム、共通ユーザー、推奨に関連する3つの異なるExecutableResourceが含まれます。 |
この単純な例のExecutableResourceクラスでは、それほどの作業は行っていません。メッセージを返すのみです。例67-4のコードを確認し、例の直後で詳細について考察します。
例67-4 DefaultExecutableResourceの拡張
package providers.data;
import oracle.wcps.conductor.annotation.PublicFunction;
import oracle.wcps.conductor.annotation.PublicParameter;
import oracle.wcps.dataprovider.base.DefaultExecutableResource;
public class SayHelloExecutableResource extends DefaultExecutableResource {
@PublicFunction
(
functionName = "sayHello",
descriptionBundleKey = "provider.method.sayHello.description"
)
public String sayHello(@PublicParameter(parameterName = "user",
descriptionBundleKey = "provider.parameter.sayHello.user.description")
String user)
{
String msg = "Hello, " + user +
". How are you today!";
System.err.println(msg);
return msg;
}
}
このコードで注目するべき最も重要な点は、sayHello()メソッドとそのパラメータが注釈付きであることです。注釈は必須であり、このメソッドに関するメタデータの取得および表示がシナリオ・エディタで可能になります。他の注釈同様、これらの注釈は名前/値ペアを表します。ここで値の部分は、リソース・バンドル・キーです。このキーはさらに、SayHelloProviderクラスで指定されたものと同じリソース・プロパティ・ファイルで参照されます。
|
ヒント: 文字列値を分離するためリソース・バンドルを使用することは、最善の方法であり、ローカライゼーションの支援になります。必ず最終のデプロイ済JARファイルに、プロパティ・ファイルをインクルードするようにしてください。JARファイルの作成については、第67.5項「カスタム・データ・プロバイダのデプロイ」で考察します。また、第67.4.4項「リソース・プロパティ・ファイルの作成」も参照してください。 |
単純なSayHelloExecutableResourceクラスのコーディングはここまでです。ご覧のとおり、このクラスを使用すると、シナリオで実行可能なカスタム・メソッドを実装できます。メソッドとパラメータの両方で注釈が必要であることを忘れないようにしてください。
次に、データ・プロバイダをシナリオで使用する場合は、サーバーにデプロイする必要があります。第67.5項「カスタム・データ・プロバイダのデプロイ」を参照してください。
新しいデータ・プロバイダ・クラスを作成した後は、コンパイルして、適切にデプロイする必要があります。これらの作業を正常に完了すると、第67.6項「シナリオ内のデータ・プロバイダのJDeveloperからの起動」で説明されているように、データ・プロバイダ・プロパティの起動ダイアログのシナリオ・エディタに、プロバイダが表示されます。
|
注意: データ・プロバイダのデプロイは、大部分が手作業による手順のため、注意を要します。これらの手順には、慎重に従う必要があります。いかなる時点の単純な入力ミスでも、プロバイダを正常にデプロイできなくなります。 |
手順を要約すると、次のものを格納したJARファイルをデプロイする必要があります。
コンパイル済のデータ・プロバイダ・クラス
リソース・プロパティ・ファイル(クラスと同一の親ディレクトリ内に存在する必要があります)
データ・プロバイダのクラス名が記述されている構成ファイル
データ・プロバイダはJavaで作成されており、デプロイする前にコンパイルする必要があります。
図67-5に示すように、アプリケーション・ナビゲータで、ソース・コードが含まれるプロジェクトを右クリックし、「メイク」または「再ビルド」のいずれかのオプションを選択します。
データ・プロバイダのデプロイを準備する次の手順は、プロバイダの完全なクラス名が記述された、単純な構成ファイルを作成することです。
アプリケーション・ナビゲータで、「アプリケーション・ソース」フォルダ内に、META-INFという新しいフォルダを作成します。
META-INFフォルダ内に、servicesというフォルダを作成します。
servicesフォルダ内に、oracle.wcps.conductor.provider.IDataProviderというテキスト・ファイルを作成します。厳密にこの名前を使用する必要があります。
oracle.wcps.conductor.provider.IDataProviderファイルを開き、デプロイ対象の各データ・プロバイダの完全なクラス名を入力します。複数のプロバイダが存在する場合は、ファイル内で各プロバイダを別々の行に記述します。
例:
providers.data.SayHelloProvider
この項は、ユーザーがJDeveloperでのJARファイルの作成に不慣れな場合、JARファイル構造(デプロイメント・プロファイル)の設定方法を説明し、必要な要素がすべて含まれるようにするものです。
アプリケーション・ナビゲータで、データ・プロバイダのソース・コードが格納されているプロジェクトを右クリックし、「プロジェクト・プロパティ」を選択します。
「プロジェクト・プロパティ」ダイアログで「デプロイ」を選択します。
「新規」をクリックします。
「アーカイブ・タイプ」として「JARファイル」を選択し、JARの名前を入力します。
「OK」をクリックします。
「JARオプション」ダイアログで、「コントリビュータ」を選択します。
図67-6に示すように、「プロジェクトの出力ディレクトリ」、「プロジェクトのソースパス」および「プロジェクトの依存性」が選択されていることを確認します。
「フィルタ」を選択します。
「パターン」タブを選択します。
「パターン」タブで、次のファイル・パターンを追加し、特定のタイプのファイルのJARへの組込みおよび除外を行います。
組込み: **.class
組込み: **resources**
組込み: META-INF**
除外: **.java
除外: **.txt
除外: **.html
図67-7に、リストに追加後のこれらのパターンを示します。
「OK」をクリックしてから、「プロジェクト・プロパティ」ダイアログの「OK」をクリックします。
プロジェクトを保存します。
JARデプロイメント・プロファイルを設定したら、プロジェクトからのJARファイルの生成は準備完了です。
アプリケーション・ナビゲータで、プロジェクト(この場合、Portalプロジェクト)を右クリックし、「デプロイ」を選択します。
デプロイするJARファイルを選択します。これは、第67.5.3項「JARファイル構造の設定」でファイルに指定した名前です。
「デプロイメント・アクション」ダイアログで、「JARファイルにデプロイ」を選択して「終了」をクリックします。
JARファイルがプロジェクト・ディレクトリに配置されます。このファイルは、ファイル・システムの<Workspace_Directory>/Portal/deployで確認できます。たとえば、MyProvidersというワークスペースの場合、JARはC:\JDeveloper\mywork\MyProviders\Portal\deployにあります。
JARファイルは、サーバーにコピーする必要があります。
前の手順で作成したJARファイルをコピーします。前述したとおり、ファイルは<Workspace_Directory\Portal\deployに配置されています。
JARファイルを、サーバーの次の場所に貼り付けます。
DOMAIN_HOME/conductor-extensions-library/WEB-INF/lib
たとえば、統合WebLogic Server環境では次の場所になります。
C:\JDeveloper\system11.1.7.40.63.82\DefaultDomain\conductor-extensions-library\WEB-INF\lib
また、管理対象サーバー環境では次の場所になります。
ORACLE_HOME/oracle/user_projects/applications/wc_domain/conductor-extensions-library/WEB-INF/lib
サーバーを再起動します。
最後に、wcps-connections.xmlを更新する必要があります。このファイルはサーバーの、デフォルト・ドメイン・ディレクトリの構成ディレクトリに存在します。独自の開発環境での最も簡単な更新方法は、このファイルを手動で編集することです。このファイルは、デフォルト・ドメインの次の場所に配置されています。
DOMIAIN_HOME/config/fmwconfig/wcps-connections.xml
|
注意: このファイルを編集および保存後、WebLogic Serverコンソールを使用して、wcps-servicesアプリケーションを再デプロイします。それには、コンソールの「デプロイメント」セクションに移動して、「デプロイメント」表でwcps-servicesを探します。「wcps-services」を選択して「更新」をクリックすると、再デプロイされます。 |
例67-5に示す<connection>要素を、wcps-connections.xmlファイルに追加します。
例67-5 wcps-connection.xmlエントリのサンプル
<connection>
<connection-name>SayHelloConnection</connection-name>
<connection-type>client.simple.connection</connection-type>
<namespace>*</namespace>
<properties>
<property>
<name>isDefault</name>
<value>true</value>
</property>
</properties>
</connection>
namespace属性には、シナリオが存在するネームスペースを指定します。デフォルトでは、ネームスペースはポータル・アプリケーションの名前です。また、namespaceをアスタリスク(*)にして、すべてのネームスペースを指定することもできます。
|
ヒント: ネームスペースは、RESTコマンドを使用して確認できます。resourceIndexから、ネームスペースのリンクをたどります。例: http://localhost:7101/wcps/api/conductor/resourceIndex resourceIndexの詳細は、第66.4項「チュートリアル: 単純なアプリケーションの作成、テストおよびデプロイ」を参照してください。 |
接続名は任意の名前で、シナリオ・エディタのユーザー・インタフェースに表示されます。接続タイプは、作成したBaseConnectionConfigの拡張のconnectionType注釈と一致する必要があります(例67-2を参照)。デフォルトのデータ・プロバイダ用の接続タイプは次のとおりです。
properties.provider.connection: プロパティ・サービス・データ・プロバイダ
activity.provider.connection: アクティビティ・グラフ・データ・プロバイダ
cmis.provider.connection: CMISデータ・プロバイダ
|
ヒント: プロバイダをデプロイしてもユーザー・インタフェースに表示されない場合は、 |
サーバーのファイル・システムに直接アクセスできない場合は、Fusion Middleware Controlを使用して接続情報を更新できます。Fusion Middleware Controlの使用の詳細は、Oracle Fusion Middleware Oracle WebCenter Portalの管理のFusion Middleware Controlを使用した接続の構成に関する項を参照してください。
デプロイのテストは、シナリオ・エディタのユーザー・インタフェースにカスタム・データ・プロバイダが表示されることを確認するだけです。詳細は、第67.3項「データ・プロバイダの検出」を参照してください。
デプロイしたプロバイダが見つからない場合は、行った手順を見直して、構成ファイルやリソース・ファイルに誤字があるような、明らかな誤りがないことを注意深く確認します。第67.5.3項「JARファイル構造の設定」の説明に従って、JARファイルが適切に作成されていることを確認します。また、JARファイルが適切なドメインにコピーされていることを確認します。
再確認の必要がある一般的なミスには、次のものがあります。
META-INF/servicesの内容は、JARファイルのトップ・レベルでインクルードする必要があります。たとえば、このフォルダはJARファイル内にMETA-INF/services/oracle.wcps.conductor.provider.IDataProviderとしてパッケージ化されており、これ以外の場所ではありません。
注釈が指定されたプロパティ・ファイルは、JARファイルのトップ・レベルでインクルードする必要があります。第67.4.4項「リソース・プロパティ・ファイルの作成」も参照してください。
JARファイルは、次のフォルダにコピーする必要があります。
DOMAIN_HOME/conductor-extensions/WEB-INF/lib
ファイルのコピー後は、サーバーを再起動する必要があります。
wcps-connections.xmlに、データ・プロバイダの接続エントリを追加する必要があります。第67.5.6項「WCPS接続構成ファイルの更新」を参照してください。
作成したカスタム・データ・プロバイダが正常にデプロイされたら、シナリオで使用できるようになります。これがどのように動作するかを、作成したプロバイダの例で確認します。
アプリケーション・ナビゲータでプロジェクトを右クリックし、「新規」を選択します。
「新規ギャラリ」ダイアログで、「一般」カテゴリを選択後、「パーソナライズ」をクリックします。
アイテム・リストで、コンダクタ・シナリオを選択して「OK」をクリックします。
「新規コンダクタ・シナリオ」ダイアログで、シナリオの名前を入力して「OK」をクリックします。
シナリオ・エディタで、「開始」ノードを右クリックし、次の文を追加を選択後、プロバイダの起動を選択します。
プロバイダ・ノードを右クリックし、起動するプロバイダのプロパティを選択します。
図67-8に示すように、「SayHelloProvider」ノードをたどってsayHello(user)メソッドを選択します。
「変数名」フィールドに変数名を入力します。この変数は、次の手順でreturn文を作成する際に参照します。たとえば、単純にresultと入力します。
|
注意: 変数名の入力は、忘れやすいものです。変数はシナリオのコンテキスト内で使用できるようになります。そのため、他のシナリオのコンポーネントや操作で再利用できることがわかります。 |
ダイアログの「パラメータ」セクションで、「user」パラメータの値を入力します。この値は、シナリオの実行時に出力される、静的な変数になります。
|
ヒント: これ以外の方法は、EL式を追加してログインしたユーザーの名前を取得し、それをシナリオで使用するというものです。例: |
「OK」をクリックします。
プロバイダの起動ノードを右クリックし、次の文を追加を選択してから、「戻る」を選択します。
「戻る」ノードを右クリックし、「式の設定」を選択します。
「シナリオ式ビルダー」ダイアログで、式プロバイダの起動ダイアログで作成した変数名をそのまま入力します。適切な式言語の構文を使用する必要があります。たとえば、変数resultをコールする場合、${result}と入力します。
「OK」をクリックします。
「開始」ノードを右クリックし、「実行」を選択します。
シナリオ入力ダイアログで、「OK」をクリックします。
サーバーが起動してシナリオがデプロイされたら、図67-10に示すように、JDeveloperのログ・ウィンドウで結果を確認します。
シナリオ・エディタおよび式ビルダーの使用の詳細は、第66章の「JDeveloperでのパーソナライズされたシナリオの作成」を参照してください。
この項では、カスタム・データ・プロバイダの設計の際に考慮する必要がある、ベスト・プラクティスについて考察します。
ユース・ケースに固有の、または問題のあるドメインに固有のデータ・プロバイダを個別に作成します。たとえば、PeopleSoftやSiebelなどのビジネス・サービスのデータにアクセスする場合のベスト・プラクティスは、別々のデータ・プロバイダを作成して、この2つを明確に線引きすることです。
1つのデータ・プロバイダは、各々が特定のサービスを表す、複数の実行可能なリソースを持つ可能性があることも念頭においてください。たとえば、1つのPeopleSoftProviderは、ベースのExternalDataProviderを拡張して、複数の実行可能なリソースを持つことが可能です。つまり、1つのリソースは個人の基本情報を取得するため、もう1つは仕事の詳細の取得のためなどです。
独自のデータ・プロバイダ・クラスを一から実装するよりも、既存のものを拡張することが最善の方法です。
コンダクタでは、データ・プロバイダ用のベースのインフラストラクチャが提供されます。そのため、プロバイダを一から作成し始めるのではなく、そのいずれかを拡張することを強くお薦めします。例として、AbstractSOAPProviderは、ExternalDataProviderを拡張して作成できます。より具体的なプロバイダでは、PeopleSoftProviderなどは、SoapProviderを拡張して作成できます。
外部システムに対しては、コンダクタの接続構成ファイルを活用します。ホスト、ポート、WSDLなどの、かなり静的な情報は、データ・プロバイダの接続との関連付けに適した属性です。コンダクタの接続は、Fusion Middleware Controlを使用して管理できます。これは、接続属性の値を実行時に追加または変更できることを意味します。Oracle Fusion Middleware Oracle WebCenter Portalの管理のFusion Middleware Controlを使用した接続の構成に関する項
コンダクタによるデータ・プロバイダの使用方法はRESTfulであるため、データ・プロバイダはシナリオが起動されるたびにインスタンス化されます。外部リソースへの接続を作成すると、コストがかかる場合があります。データ・プロバイダのベース・インフラストラクチャでは、これらの接続のキャッシュが可能です。
パーソナライズの最も強力な側面の1つは、データ・プロバイダとシナリオの両方の再利用が、複数のコンテキストで複数のクライアントを使用して可能なことです。たとえば、1つのシナリオを再利用して、モバイル・アプリケーション、トランザクションWebサイト、ポータル、タブレットにデータを配信できます。
シナリオでは、複数のデータ(およびファンクション)プロバイダを起動して、特定のビジネス・プロセスをカプセル化します。シナリオは、連鎖することもできます。つまり、あるシナリオの出力を、別のシナリオの入力として使用できます。
