ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebCenter Contentサービス・リファレンス
11gリリース1 (11.1.1)
B72418-02
  ドキュメント・ライブラリへ移動
ライブラリ
目次へ移動
目次
索引へ移動
索引

前
 
次
 

3 サービスのカスタマイズ

この章では、サービスのカスタマイズに役立つOracle WebCenter Contentのサービスの基本構成について説明します。

この章の内容は、次のとおりです。

3.1 サービス構造の概要

この項では、Oracle WebCenter Content Serverに標準サービスがどのように実装されるかを説明します。他のプログラムからのサービスのコールの詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentでの開発』の、統合方法に関する章を参照してください。

サービス・リソースは、次の3つの列があるResultSet表を使用したHTMファイルで定義されます。

コンテンツ・サーバーの標準的なサービスは、IdcHomeDir/resources/core/tables/std_services.htmファイルのStandardServices表に定義されています。同じディレクトリのworkflow.htmファイルには、特殊な目的のサービスもあります。

サービスが機能を実行する際には、他のリソース定義に左右されます。

サービス・リソースにマージ・ルールは不要です。ただし、サービス・リソースは、ResourceDefinition ResultSetに表として一覧表示されている必要があります。

図3-1に表示されている表の行は、サービス定義の例です。

図3-1 サービス定義の例

図3-1については周囲のテキストで説明しています。

3.1.1 名前

StandardServices表の「名前」列では、各サービスの名前が定義されています。クライアント側のサービス・リクエストでは、これは、第2.1.5項「永続URLを使用したサービスのコール」でコールされている名前です。標準的なWebリクエストでは、これはほぼ必ず、コンテンツ・サーバーのWebページに対するURLです。

図3-2 DELETE_DOCサービス定義の「名前」列

図3-2については周囲のテキストで説明しています。

3.1.2 属性

StandardServices表の「属性」列では、各サービスの側面が定義されており、それらについては次の各項で説明されています。

図3-3 DELETE_DOCサービス定義の「属性」列

図3-3については周囲のテキストで説明しています。

3.1.2.1 サービス・クラス

「サービス・クラス」属性は、サービスからアクセスできるJavaクラス・オブジェクトを指定します。完全パスが指定されていないかぎり、クラスパス接頭辞intradoc.serviceが想定されます。サービス・クラスによって、サービスで実行できるアクションが一部決定されます。考えられるサービス・クラスは次のとおりです。

サービス・クラス 説明

ArchiveService

アーカイブに関連する機能を実行します。

BatchService

バッチのロードに関連する機能を実行します。

ChunkedService

アプレットのアップロードおよびダウンロードのためのHTTPファイルのチャンク化に関連する機能を実行します。

DocService

ドキュメントに対するアクションを実行します。チェックイン、チェックアウト、ドキュメント情報、サブスクリプションなどのサービスがその例です。

DocProfileService

ドキュメントのプロファイルに対して、プロファイルの追加、編集、削除などのアクションを実行します。

FileService

コンテンツ・サーバーからファイルを取得します。

IndexerService

検索エンジンのメンテナンスのための索引付けに関連する機能を実行します。

ListBoxService

コンテンツ・サーバーからリストをダウンロードします。たとえば、ユーザーのリストや依存選択リストなどです。

LocaleService

ユーザーの場所または環境に固有の(たとえば、ユーザーの場所を識別し、適切な言語による文字列ファイルを提供するための国際化で使用される)機能を実行します。

MetaService

メタデータ・フィールドを管理します。

PageHandlerService

(Webレイアウト・エディタで作成される)ライブラリWebページを管理します。

PageRequestService

HTMLページを取得します。

ProjectService

Publisherプロジェクトを管理します。

ProviderManagerService

プロバイダ(外部のエンティティへの接続を確立するアプリケーション・プログラミング・インタフェース(API))を管理します。

SchemaService

オプション・リストなど、データベース表のJavaScriptファイルのサーバー側のパブリッシュを管理します。

SearchService

検索に関連する機能を実行します。

Service

一般的なサービスを実行します。

UserService

ユーザーを管理します。

WorkflowService

ワークフローを管理します。

WorkflowTemplateService

ワークフロー・テンプレートを管理します。

intradoc.admin.AdminService

管理サーバー全体にわたる機能を実行します。一般的に、コンテンツ・サーバー自体から内部的にコールされます。これらのサービスは非常に複雑なため、適切にコールできないと、コンテンツ・サーバーのデータが失われたり破損したりする可能性があります。したがって、これらのサービスは、使用も変更もしないことを強くお薦めします。


DELETE_DOCサービスの例では、このサービス・クラスは、次に示すようにDocServiceとなります。

DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)

3.1.2.2 アクセス・レベル

サービスのセキュリティ・モデルは、コンテンツ・サーバー全体で使用されるドキュメントのセキュリティ・モデルに似ています。「アクセス・レベル」属性は、サービスに権限レベルを割り当てます。このサービスを実行しようとするユーザーは誰でも、最低限、この権限が付与されている必要があります。

セキュリティ・アクセスは、ビット・フラグとして格納されています。一般的に、1つのサービスには、読取り、書込み、削除、管理のいずれかの権限が割り当てられます。アクセス・レベル番号は、使用可能な次のビット・フラグの合計です。

ビット・フラグ 権限 説明

1

READ_PRIVILEGE

読取り権限は、サービス内で参照されるセキュリティ・グループに必要です、

2

WRITE_PRIVILEGE

書込み権限は、サービス内で参照されるセキュリティ・グループに必要です、

4

DELETE_PRIVILEGE

削除権限は、サービス内で参照されるセキュリティ・グループに必要です、

8

ADMIN_PRIVILEGE

管理権限は、サービス内で参照されるセキュリティ・グループに必要です、

16

GLOBAL_PRIVILEGE

このサービスはグローバル・セキュリティ・チェックをコールし、このサービスを実行する権限が現在のユーザーに付与されているかどうかを判別します。このチェックは、adminロールが必要かどうか、または、少なくとも1つのセキュリティ・グループに対して、指定された権限(読取り、書込み、または削除)のみがユーザーに必要かどうかを検証します。

32

SCRIPTABLE_SERVICE

スクリプト可能なサービスはパラメータ入力が不要であるため、動的サーバー・ページでexecuteService関数を実行することでコールできます。


サービスの実行対象がドキュメントの場合は、サービスを実行するために、そのドキュメントのセキュリティ・グループに対して、読取り、書込み、削除、管理のいずれかの権限が(この順序で)、そのユーザーに付与されている必要があります。たとえば、ドキュメントをサブスクライブする場合、ユーザーには、そのドキュメントのセキュリティ・グループに対する読取り権限のみが必要です。ただし、新規のドキュメントにチェックインする場合は、ユーザーには、そのドキュメントのセキュリティ・グループに対する書込み権限も必要です。

(GET_USER_INFOやCHECKIN_NEW_FORMなどのように)サービスの実行対象が特定のドキュメントでない場合は、GLOBAL_PRIVILEGEビット・フラグを、少なくとももう1つの権限ビット・フラグとともに設定する必要があります。ユーザーはそのサービスを実行するために、少なくとも1つのセキュリティ・グループで、そのレベルの権限が付与されている必要があります。


注意:

サービスは、GLOBAL_PRIVILEGEビット・フラグのみを指定するものではありません。少なくとも、権限ビット・フラグをもう1つ指定する必要があります。


SCRIPTABLE_SERVICE権限とは、このサービスが、IdocスクリプトのexecuteService関数で実行できるという意味です。これは、GET_SEARCH_RESULTSやGET_USER_INFOなどのように、読取り専用サービスに制限する必要があります。

次に示すのは、すべてのアクセス・レベルおよびそれぞれの意味の詳細なリストです。

  • 0: アクセスは許可されない

  • 1: 読取り権限が必要

  • 2: 書込み権限が必要

  • 3: 読取り/書込み権限が必要

  • 4: 削除権限が必要

  • 8: 管理権限が必要

  • 16: グローバルな権限が必要

  • 17: グローバルな読取り権限が必要

  • 18: グローバルな書込み権限が必要

  • 19: グローバルな読取り/書込み権限が必要

  • 23: グローバルな読取り/書込み/削除権限が必要

  • 24: グローバルな管理権限が必要

  • 32: スクリプト可能な権限が必要

  • 33: スクリプト可能な読取り権限が必要

  • 34: スクリプト可能な書込み権限が必要

  • 40: スクリプト可能な管理権限が必要

  • 49: スクリプト可能でグローバルな読取り権限が必要

  • 50: スクリプト可能でグローバルな書込み権限が必要

  • 51: スクリプト可能でグローバルな読取り/書込み権限が必要

  • 56: スクリプト可能でグローバルな管理権限が必要

DELETE_DOCサービスの例では、アクセス・レベルは4です。これは、このサービスを実行するには、ユーザーにDELETE_PRIVILEGEが付与されている必要があるという意味です。

DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)

別の例では、ADD_ALIASサービスのアクセス・レベルは24です。これは、このサービスを実行するには、ユーザーにADMIN_PRIVILEGEとGLOBAL_PRIVILEGEが付与されている必要があるという意味です。

ADD_ALIAS UserService 24 null null aliases !csUnableToAddAlias

ユーザー・アカウントとロール権限の詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentの管理』を参照してください。

3.1.2.3 「テンプレート」ページ

「「テンプレート」ページ」属性は、サービスの結果を表示するテンプレートを指定します。(PageHandlerServiceタイプのように)サービスの結果にページ表示が必要ない場合は、この属性はnullにします。

テンプレートとは、HTMLとIdocスクリプトの組合せです。Idocスクリプトは、HTMLを書式設定し、レスポンスにデータを表示するために使用します。次に示すように、テンプレート・ページ名は、IdcHomeDir/components/Folders/resources/templates/templates.hdaファイル内のHTMファイルにマップされます。

  • ほとんどのテンプレート・ページは、IntradocTemplates ResultSet内にマップされます。

  • 検索テンプレート・ページは、SearchResultTemplates ResultSet内にマップされます。

DELETE_DOCサービスの例では、サービスの結果を表示するテンプレート・ページはMSG_PAGEとなり、次に示すように、msg_page.htmファイルにマップされます。

DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)

3.1.2.4 サービス・タイプ

「サービス・タイプ」属性は、サービスを別のサービス内でサブサービスとして実行するかどうかを指定します。2番目のサービスがサブサービスでないかぎり、メインのサービスから2番目のサービスをコールすることはできません。

サービス・タイプ 説明

SubService

このサービスは、別のサービス内でのみ実行されるサブサービスです。

null

このサービスはサブサービスではありません。


たとえば、UPDATE_DOCINFOサービスが、SubServiceをサービス・タイプとするUPDATE_DOCINFO_SUBを実行するとします。

DELETE_DOCサービスの例では、このサービスはサブサービスでないため、サービス・タイプは、次に示すようにnullとなります。

DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)

3.1.2.5 通知された件名

「通知された件名」属性は、サービスによって通知されるサブジェクト(サブシステム)を指定します。サービスが1つ以上のサブジェクトを変更する場合は、キャッシュされた情報が更新されたことをサービスがリモート・ソース(データベース表など)に通知する必要があります。

たとえば、いずれかのサービスに対してIsJava=1コールを行った場合、レスポンスにはchangedSubjectsrefreshSubjectsが常に表示されます。これらのサブジェクトは、コンテンツ・サーバー・インスタンスの状態が変化したときにクライアントに通知するために使用されます。たとえば、システムに新しいユーザーが追加されたとき、新しいドキュメントにチェックインされたとき、カスタム・メタデータが変更されたときなどに、クライアントに通知されます。これによって、コンテンツ・サーバーの状態が変化したときに、外部アプリケーションがそのデータをリフレッシュできます。これは、コンテンツ・サーバーの管理アプレットを最新のものにして、ユーザーの数、ドキュメント・タイプ、およびシステム内のドキュメントを反映させる際に基礎となるメカニズムでもあります。たとえば、リポジトリ・マネージャを起動して新しいドキュメントにチェックインした場合、(ほんの数秒で)そのアイテムがアプレットに表示されます。

通知された件名の文字列は、変更された件名のカンマ区切りリストです(件名が通知されない場合は、この属性はnullにします)。たとえば、EDIT_METADEFサービスの通知された件名属性の値がmetadata,dynamicqueriesとします。このサービスによってメタデータ・フィールドが変更され、続いて、metadataサブジェクトおよびdynamicqueriesサブジェクトが変化したことがシステムに知らされます。

考えられるサブジェクトは次のとおりです。

サブジェクト 変更したら通知が必要になるもの

accounts

定義済アカウント

aliases

ユーザー・エイリアス

collections

アーカイバ・コレクション

config

グローバルな構成情報

docformats

ファイル形式

doctypes

コンテンツ・タイプ

documents

新規のコンテンツ・アイテム、改訂されたコンテンツ・アイテム、または更新されたコンテンツ・アイテム・メタデータ

dynamicqueries

データベースからメタデータ・フィールドのリストを取得する動的な問合せ

indexerstatus

インデクサのステータス

indexerwork

コンテンツ・アイテムであり、更新サイクルの索引付けが必要であることを指定します

metadata

メタデータ・フィールド

metaoptlists

メタデータ・フィールドのオプション・リスト

pagelist

ライブラリ(Webレイアウト・エディタ)ページ

renditions

(XML Converter、サムネイルなどからの)追加のレンディション

reports

レポートのデータソース

schema

スキーマ定義

searchapi

索引付け検索エンジンへの接続

subscriptiontypes

サブスクリプション・タイプ

templates

(Webレイアウト・エディタから構成されている)検索結果テンプレート

usermetaoptlists

ユーザー情報フィールドのオプション・リスト

users

ユーザー情報

wfscripts

ワークフロー・イベント・スクリプト

wftemplates

ワークフロー・テンプレート

workflows

ワークフロー


DELETE_DOCサービスの例では、次に示すdocumentsサブジェクトが、通知される唯一のサブジェクトです。

DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)

3.1.2.6 エラー・メッセージ

「エラー・メッセージ」属性は、アクション・エラー・メッセージによってオーバーライドされない場合、サービスによって返されるエラー・メッセージを定義します。これは、実際のテキスト文字列にも、ロケールに依存する文字列への参照にすることもできます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentでの開発』を参照してください。

DELETE_DOCサービスの例では、エラー・メッセージは、次に示すようにローカライズされた文字列となります。

DocService 4 MSG_PAGE null documents !csUnableToDeleteItem(dDocName)

3.1.3 アクション

「アクション」列は、サービスを処理するために実施される1つ以上の手順を定義します。アクションとは、サービス・スクリプトの一部として実行される操作です。アクションでは、SQL文の実行、問合せの実行、コードの実行、問合せ結果のキャッシュまたはオプション・リストのロードを行えます。あるアクションによって返されたデータが、それ以降のアクションの動作を変える場合があります。

アクションは、次の形式を使用した、コロン区切りのセグメントのリストとして定義されます。

type:name:parameters:control mask:error message

詳細は、次の各項を参照してください。

図3-4 DELETE_DOCサービス定義の「アクション」列

図3-4については周囲のテキストで説明しています。

3.1.3.1 アクション・タイプ

アクション文の最初のセグメントでは、アクションのタイプを定義します。

  • アクション・タイプ番号: サービス・リソース・ファイルでアクション・タイプを特定するために使用します。

  • コンポーネント・ウィザードID: コンポーネント・ウィザードでアクション・タイプを特定するために使用します。サービス・リソース・ファイルでは、アクション・タイプは番号で表されています。

  • Java定数: Javaコードでアクション・タイプを特定するために使用します。

考えられるアクション・タイプは次のとおりです。

アクション・タイプ番号 コンポーネント・ウィザードID Java定数 説明

1

問合せの選択

QUERY_TYPE

情報を取得するために、事前定義されたSQLデータベース問合せを実行し(読取り専用のアクション)、その直後に結果を破棄します。たとえば、「問合せの選択」は、データベースに特定のdDocName(コンテンツID)がすでに存在しているかどうかを確かめるような場合に使用できます。この問合せは、アクションの「アクション名」で指定できます。

2

問合せの実行

EXECUTE_TYPE

データベース内の情報を削除、追加または更新するために、事前定義されたSQLデータベース問合せを実行します。

3

Javaメソッド

CODE_TYPE

サービスを実装するJavaクラスの一部であるコード・モジュールを指定します。

4

オプション・リストのロード

OPTION_TYPE

システムに格納されているオプション・リストをロードします。これは、非推奨のアクション・タイプです。

5

キャッシュ問合せの選択

CACHE_RESULT_TYPE

情報を取得するために、SQLデータベース問合せを実行し(読取り専用のアクション)、後で使用できるように結果を格納します。たとえば、「キャッシュ問合せの選択」は、コンテンツ・アイテムをサブスクライブしているユーザーをすべて見つけ、リストを保存してコンシューマの画面に表示するような場合に使用できます。この問合せは、アクションの「アクション名」で指定できます。


DELETE_DOCサービスの最初のアクションの例では、このアクションは次のような「キャッシュ問合せの選択」タイプ(5)になります。

5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExists

3.1.3.2 アクション名

アクション文の2番目のセグメントでは、アクションの名前を定義します。

  • アクション・タイプが「Javaメソッド」の場合は、アクション名はJavaメソッドとなります。

  • アクション・タイプが「オプション・リストのロード」の場合は、アクション名はオプション・リストとなります。

  • アクション・タイプが「問合せの選択」「問合せの実行」および「キャッシュ問合せの選択」の場合は、アクション名は問合せ名となります。コンテンツ・サーバーの標準サービスでは、通常の場合、接頭辞を使用して、データベースに対して実行されるアクションを特定します。問合せに考えられる接頭辞は次のとおりです。

    問合せの接頭辞 説明

    Q

    データベースに情報を問い合せます(取得します)(読取り専用のアクション)。

    D

    データベースから情報を削除します。

    I

    データベースに情報を挿入(追加)します。

    U

    データベース内の情報を更新します。


DELETE_DOCサービスの最初のアクションの例では、このアクションの名前はQdocInfoです。これは次のように、データベースに対して読取り専用の問合せ(Q)が実行されることを指定します。

5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExists

3.1.3.3 アクションのパラメータ

アクション文の3番目のセグメントでは、アクションに必要なパラメータを指定します。必須のパラメータがない場合は、このセグメントを空白にしておきます(パラメータのかわりに2つのコロンが表示されます)。

  • アクションでパラメータが必要になる場合は、そのパラメータをカンマ区切りリストとして入力します。

  • アクション・タイプが「キャッシュ問合せの選択」である場合、第1パラメータは問合せから返されたResultSetにアクションが割り当てる名前となります。このResultSetは、テンプレート・ページで参照できます。

  • アクション・タイプが「オプション・リストのロード」の場合、パラメータはオプションです。ただし、パラメータを指定する場合、第1パラメータはオプション・リストがロードされるキー、第2パラメータはHTMLページに表示するために選択した値となります。

DELETE_DOCサービスの最初のアクションの例では、サービス問合せから返されるResultSetには、次に示すように、DOC_INFOという名前が付けられます。

5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExists

3.1.3.4 アクションの制御マスク

アクション文の4番目のセグメントは省略可能なビット・フラグで、コンテンツ・サーバー・データベースに対する問合せの結果を制御します。

  • 制御マスクのビット・フラグ: サービス・リソース・ファイルで制御マスクを特定するために使用します。サービス・リソース・ファイルで使用される制御マスク番号は、適用されている制御すべてのビット・フラグの合計を表しています。コンテンツ・サーバーの標準サービスでは、通常の場合、制御マスクの文字列値でなく制御マスクのビット・フラグが使用されます。

  • 制御マスクの文字列値: サービス・リソース・ファイルで制御マスクを特定するために使用します。制御マスクが複数ある場合、文字列値はカンマ区切りリストに置かれます。カスタム・サービスでは、制御マスクのビット・フラグでなく文字列値が使用されます。

  • コンポーネント・ウィザードID: コンポーネント・ウィザードで制御マスクを特定するために使用します。サービス・リソース・ファイルでは、制御マスクは、そのビット・フラグの合計(コンテンツ・サーバーの標準サービス)とビット・フラグの文字列値のカンマ区切りリスト(カスタム・サービス)のいずれかで表されます。

  • Java定数: Javaコードで制御マスクを特定するために使用します。

考えられる制御マスクは次のとおりです。

制御マスクのビット・フラグ 制御マスクの文字列値 コンポーネント・ウィザードID Java定数 説明

0

-

-

-

適用される制御はありません。

1

ignoreError

エラーを無視

CONTROL_IGNORE_ERROR

エラー発生時にサービスを終了しません。

2

mustExist

結果が空でないことのチェック

CONTROL_MUST_EXIST

問合せによって、少なくとも1つのレコードが戻される必要があり、戻されないとアクションは失敗します。アクション・タイプが「問合せの選択」の場合と「キャッシュ問合せの選択」の場合にのみ使用されます。

4

beginTran

トランザクションの開始

CONTROL_BEGIN_TRAN

データベース・トランザクションを開始します。

8

commitTran

トランザクションのコミット

CONTROL_COMMIT_TRAN

データベース・トランザクションを終了します。

16

mustNotExist

結果が空であることのチェック

CONTROL_MUST_NOT_EXIST

問合せによって行が戻されてはならず、戻されるとアクションは失敗します。アクション・タイプが「問合せの選択」の場合と「キャッシュ問合せの選択」の場合にのみ使用されます。

32

retryQuery

問合せのリトライ

CONTROL_RETRY QUERY

アクション・タイプが「問合せの実行」に設定されていて問合せが失敗すると、エラーがログに記録されます。この問合せは3秒後に再実行されます。問合せが3回失敗すると、サービスは失敗します。その用途は、コンテンツのチェックインがほとんどです。もう使用されなくなりました。

64

doNotLog

ログに記録しない

CONTROL_DO_NOT_LOG

アクション・タイプが「問合せの選択」に設定されていて問合せが失敗すると、サービスは失敗します。ただし、エラーはシステム・ログに記録されません。テスト用のデバッグ・フラグとしてコンポーネントを開発するときに、内部的に使用されます。



注意:

制御マスク「結果が空でないことのチェック」および「結果が空であることのチェック」は、アクション・タイプが「問合せの選択」の場合と「キャッシュ問合せの選択」の場合にのみ使用されます。第3.1.3.1項「アクション・タイプ」を参照してください。


DELETE_DOCサービスの最初のアクションの例では、制御マスクの値が6になっています。これは、この問合せによって少なくとも1つのレコードが戻される必要がある(2)という意味です。また、このアクションによってデータベース・トランザクションが開始されます(4)。

5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExists

これがコンポーネント・ウィザードを使用して作成されたカスタム・サービスであれば、次に示すように、制御マスクのビット・フラグの合計は、ビット・フラグの文字列値のカンマ区切りリストに置換されます。

5:QdocInfo:DOC_INFO:mustExist, beginTran:!csUnableToDeleteItem(dDocName)
!csRevisionNoLongerExists

3.1.3.5 アクションのエラー・メッセージ

アクション文の5番目のセグメントでは、このアクションが失敗した場合に表示されるエラー・メッセージを定義します。これは、実際のテキスト文字列にも、ロケールに依存する文字列への参照にすることもできます。詳細は、『Oracle Fusion Middleware Oracle WebCenter Contentでの開発』を参照してください。

  • アクションのエラー・メッセージは、サービスの属性として用意されているエラー・メッセージをオーバーライドします。

  • アクションのエラー・メッセージがnullでない場合は、サービス内のアクションのリマインダに対するエラー・メッセージとなります。

  • アクションのエラー・メッセージがnullの場合は、エラー・メッセージは前のアクションからそのまま変わりません。

  • 文字列参照の前には感嘆符が置かれます。

DELETE_DOCサービスの最初のアクションの例では、このエラー・メッセージは次に示すように、ローカライズされた2つの文字列を組み合せたものです。

5:QdocInfo:DOC_INFO:6:!csUnableToDeleteItem(dDocName)!csRevisionNoLongerExists

3.2 サービスの例

DOC_INFOサービスでは、サービス、問合せおよびテンプレートがまとまってどのように機能しているかの好例が提供されています。この項の内容は次のとおりです。

3.2.1 DOC_INFOサービス定義

この項では、IdcHomeDir/resources/core/tables/std_services.htmファイルにあるDOC_INFOサービス定義の詳細を示します。

テキスト・エディタに表示されるDOC_INFOサービス定義の例は、次のとおりです。

<@table StandardServices@>
<table border=1><caption><strong>Scripts For Standard Services</strong></caption>
<tr>
    <td>Name</td><td>Attributes</td><td>Actions</td>
</tr>
<tr>
    <td>DOC_INFO</td>
    <td>DocService
        33
        DOC_INFO
        null
        null<br>
        !csUnableToGetRevInfo</td>
    <td>5:QdocInfo:DOC_INFO:2:!csItemNoLongerExists2
         3:mapNamedResultSetValues:DOCINFO,dStatus,dStatus,dDocTitle,dDocTitle:0:null
        3:checkSecurity:DOC_INFO:0:!csUnableToGetRevInfo2(dDocName)
        3:getDocFormats:QdocFormats:0:null
        3:getURLAbsolute::0:null
        3:getUserMailAddress:dDocAuthor,AuthorAddress:0:null
        3:getUserMailAddress:dCheckoutUser,CheckoutUserAddress:0:null
        3:getWorkflowInfo:WF_INFO:0:null
        3:getDocSubscriptionInfo:QisSubscribed:0:null
        5:QrevHistory:REVISION_HISTORY:0:!csUnableToGetRevHistory(dDocName)</td>
</tr>
</table>
<@end@>

図3-5 DOC_INFOサービス定義の例

図3-5については周囲のテキストで説明しています。

3.2.2 DOC_INFOの属性

次の表では、DOC_INFOサービスの属性について説明します。

属性 説明

サービス・クラス

DocService

このサービスは、コンテンツ・アイテムに関する情報を提供しています。

アクセス・レベル

33

1 = サービスをリクエストするユーザーには、コンテンツ・アイテムに対する読取り権限が必要です。

32 =このサービスは、IdocスクリプトのexecuteService関数で実行できます。

「テンプレート」ページ

DOC_INFO

このサービスでは、DOC_INFOテンプレート(doc_info.htmファイル)を使用しています。アクションの結果がこのテンプレートにマージされて、ユーザーの画面に表示されます。

サービス・タイプ

null

このサービスはサブサービスではありません。

通知された件名

null

このサービスの影響を受ける件名はありません。

エラー・メッセージ

!csUnableToGetRevInfo

このサービスが英語コンテンツ・サーバー・システムで失敗した場合は、次のエラー・メッセージ文字列が返されます。

リビジョンに関する情報を取得できません。


3.2.3 DOC_INFOのアクション

DOC_INFOサービスでは、次の10個のアクションを実行します。

3.2.3.1 アクション1の定義と説明

アクション1は、次のように実行されます。

  • Action 1 - 5:QdocInfo:DOC_INFO:2:!csItemNoLongerExists2

  • 5: 問合せを使用してデータベースから情報を取得する、キャッシュ問合せの選択アクション。

  • QDocInfo: このアクションでは、query.htmファイル内のQDocInfo問合せを使用して、コンテンツ・アイテム情報を取得します。

  • DOC_INFO: この問合せの結果がDOC_INFOというResultSetに割り当てられ、後で使用できるように格納されます。

  • 2: 「結果が空でないことのチェック」制御マスクによって、問合せがレコードを返す必要があり、返さないとアクションが失敗すると指定されます。

  • !csItemNoLongerExists2: このアクションが英語コンテンツ・サーバー・システムで失敗した場合は、次のエラー・メッセージ文字列が返されます。

    該当コンテンツ・アイテムはもはや存在しません。

3.2.3.2 アクション2の定義と説明

アクション2は、次のように実行されます。

  • Action 2 : 3:mapNamedResultSetValues:DOCINFO,dStatus,dStatus,dDocTitle,dDocTitle:0:null

  • 3: サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

  • mapNamedResultSetValues: このアクションでは、DOC_INFO ResultSetの最初の行からdStatusおよびdDocTitleの値を取得して、ローカル・データに格納します。(これによってスピードが上がり、正しい値が使用されるようになります。)

  • DOC_INFO,dStatus,dStatus,dDocTitle,dDocTitle: mapNamedResultSetValuesアクションに必須のパラメータ。

  • 0: 制御マスクが指定されていません。

  • null: エラー・メッセージが指定されていません。

3.2.3.3 アクション3の定義と説明

アクション3は、次のように実行されます。

  • Action 3 : 3:checkSecurity:DOC_INFO:0:!csUnableToGetRevInfo2(dDocName)

  • 3: サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

  • checkSecurity: このアクションでは、DOC_INFO ResultSetに割り当てられているデータを取得し、割り当てられているセキュリティ・レベルを評価して、ユーザーがこのアクションを実行する権限があることを確認します。

  • DOC_INFO: checkSecurityアクションによって評価されるセキュリティ情報を含むResultSet。

  • 0: 制御マスクが指定されていません。

  • !csUnableToGetRevInfo2(dDocName): このアクションが英語コンテンツ・サーバー・システムで失敗した場合は、次のエラー・メッセージ文字列が返されます。

    '{dDocName}'に対する情報を取得できません。

3.2.3.4 アクション4の定義と説明

アクション4は、次のように実行されます。

  • Action 4 : 3:getDocFormats:QdocFormats:0:null

  • 3: サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

  • getDocFormats: このアクションでは、query.htmファイル内のQdocFormats問合せを使用して、コンテンツ・アイテムのファイル形式を取得します。ファイル形式のカンマ区切りのリストが、dDocFormatsとしてローカル・データに格納されます。

  • QdocFormats: ファイル形式の取得に使用される問合せを指定します。

  • 0: 制御マスクが指定されていません。

  • null: エラー・メッセージが指定されていません。

3.2.3.5 アクション5の定義と説明

アクション5は、次のように実行されます。

  • Action 5 : 3:getURLAbsolute::0:null

  • 3: サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

  • getURLAbsolute: このアクションでは、コンテンツ・アイテムのURLを解決し、DocUrlとしてローカル・データに格納します。

  • 空白: このアクションではパラメータを利用しません。

  • 0: 制御マスクが指定されていません。

  • null: エラー・メッセージが指定されていません。

3.2.3.6 アクション6の定義と説明

アクション6は、次のように実行されます。

  • Action 6 : 3:getUserMailAddress:dDocAuthor,AuthorAddress:0:null

  • 3: サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

  • getUserMailAddress: このアクションでは、コンテンツ・アイテムの作者の電子メール・アドレスを解決します。

  • dDocAuthor,AuthorAddress: このアクションでは、パラメータとしてdDocAuthorとAuthorAddressを渡します。

  • 0: 制御マスクが指定されていません。

  • null: エラー・メッセージが指定されていません。

3.2.3.7 アクション7の定義と説明

アクション7は、次のように実行されます。

  • Action 7 : 3:getUserMailAddress:dCheckoutUser,CheckoutUserAddress:0:null

  • 3: サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

  • getUserMailAddress: このアクションでは、コンテンツ・アイテムがチェックアウトされているユーザーの電子メール・アドレスを解決します。

  • dCheckoutUser,CheckoutUserAddress: このアクションでは、パラメータとしてdCheckoutUserとCheckoutUserAddressを渡します。

  • 0: 制御マスクが指定されていません。

  • null: エラー・メッセージが指定されていません。

3.2.3.8 アクション8の定義と説明

アクション8は、次のように実行されます。

  • Action 8 : 3:getWorkflowInfo:WF_INFO:0:null

  • 3: サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

  • getWorkflowInfo: このアクションでは、コンテンツ・アイテムがワークフローの一部かどうかを評価します。WF_INFO ResultSetが存在している場合は、ワークフロー情報がDOC_INFOテンプレートにマージされます。

  • WF_INFO: このアクションでは、パラメータとしてWF_INFOを渡します。

  • 0: 制御マスクが指定されていません。

  • null: エラー・メッセージが指定されていません。

3.2.3.9 アクション9の定義と説明

アクション9は、次のように実行されます。

  • Action 9 : 3:getDocSubscriptionInfo:QisSubscribed:0:null

  • 3: サービスを実装するJavaクラスの一部であるモジュールを指定するJavaメソッドのアクション。

  • getDocSubscriptionInfo: このアクションでは、現在のユーザーがコンテンツ・アイテムをサブスクライブしているかどうかを評価します。

    • ユーザーがサブスクライブしている場合は、「サブスクライブ解除」ボタンが表示されます。

    • ユーザーがサブスクライブしていない場合は、「サブスクライブ」ボタンが表示されます。

  • QisSubscribed: サブスクリプション情報の取得に使用される問合せを指定します。

  • 0: 制御マスクが指定されていません。

  • null: エラー・メッセージが指定されていません。

3.2.3.10 アクション10の定義と説明

アクション10は、次のように実行されます。

  • Action 10 :

    5:QrevHistory:REVISION_HISTORY:0:!csUnableToGetRevHistory(dDocName)

  • 5: 問合せを使用してデータベースから情報を取得する、キャッシュ問合せの選択アクション。

  • QrevHistory: このアクションでは、query.htmファイル内のQrevHistory問合せを使用して、リビジョン履歴情報を取得します。

  • REVISION_HISTORY: この問合せの結果が、REVISION_HISTORYというResultSetに割り当てられます。DOC_INFOテンプレートはResultSet上をループし、各リビジョンに関する情報を表示します。

  • 0: 制御マスクが指定されていません。

  • !csUnableToGetRevHistory(dDocName): このアクションが英語コンテンツ・サーバー・システムで失敗した場合は、次のエラー・メッセージ文字列が返されます。

    ''{dDocName}''に対するリビジョン履歴を取得できません。

3.2.4 DOC_INFOテンプレート

DOC_INFOサービスのテンプレート・ページはDOC_INFOテンプレートです。ファイル間で何が行われているかを知って、テンプレート・ページとサービス内で実行されるアクションの相互作用を理解できるようにしておくことが重要です。

doc_info.htmテンプレートに含まれるコンテンツの定義は、IdcHomeDir/components/Folders/resources/std_page.htmファイル内にあります。両方のファイルのコードが、次のマークアップ・セクションに表示されます。

IdcHomeDir/resources/core/templates/doc_info.htmファイルからのマークアップ:

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>

<$include std_info_html_head_declarations$>

</head>
<$include info_body_def$>
<$include info_page_content$>
</body>
</html>

doc_info.htmテンプレートに何が表示されるかを定義する、IdcHomeDir/components/Folders/resources/std_page.htmファイルからのマークアップ:

<@dynamichtml info_page_content@>
<$include std_page_begin$>
<$include std_header$>
…
<!-- Do a loop on DOC_INFO so that all substitution tags will use DOC_INFO as 
their first place to find their values.  Otherwise their is confusion between 
this result set and the REVISION_HISTORY table that comes later.  For example 
'dStatus' is a value in both tables-->
<$loop DOC_INFO$>
<$if AllowPrimaryMetaFile and isTrue(AllowPrimaryMetaFile) and
isTrue(dFormat like "*idcmeta*")$>
<$showPrimaryMetaFileFields = "1"$>
<$endif$>
<$include doc_info_notify_data$>

<table border=0 cellpadding=2 cellspacing=0 width=<$docInfoWidth-30$>>
<caption align=top><h4 class=pageTitle><$pageTitle$></caption>
<$include special_checkin_fields1$>
<$include std_revision_label_field$>
<$include std_document_type_field$>
<$include std_document_title_field$>
<$include author_checkin_field$>
<$include std_meta_fields$>
<$include security_checkin_fields$>
<$include checkout_author_info_field$>
<$if IsStagingDoc$>
<$include doc_date_fields$>
<$endif$>
<$fieldName = "dStatus", fieldCaption = "Status"$><$include std_displayonly_field$>
<$if HasOriginal$>
<$fieldName = "dDocFormats", fieldCaption = "Formats"$><$include std_display_field$>
<$endif$>
<$include workflow_list_for_doc$>
<$if HasUrl$>
<$include doc_url_field$>
<$endif$>
<$if HasOriginal and not ClientControlled and not showPrimaryMetaFileFields$>
<$fieldName = "dOriginalName", fieldCaption = "Get Native File"$>
<$if DownloadApplet$>
<$valueStyle="xxsmall", fieldValue = strTrimWs(inc("download_file_by_applet_form_content"))$>
<$else$>
<$fieldValue = strTrimWs(inc("doc_file_get_copy"))$>
<$endif$>
<$if DownloadApplet$><form name=downloadForm><$endif$>
<$include std_displayonly_field$>
<$if DownloadApplet$></form><$endif$>
<$endif$>
<$if IsFailedConversion or IsFailedIndex or IsDocRefinePassthru$>
<$if IsFailedConversion$><$include std_namevalue_separator$><$endif$>
<tr>
<td align=right><span class=errorHighlight>
<$if IsFailedIndex$>Index Error:
<$else$>Conversion Error:
<$endif$></span></td>
<td>
<table>
<tr>
<td><span class=tableEntry>
<$dMessage$>
<$if IsFailedIndex$>
<br>Content has been indexed with Info only.
Resubmit should only be performed if the problem has been resolved.
<$elseif IsDocRefinePassthru$>
<br>Content Refinery failed to convert the content item but released it to the
web by copying the native file.
<$endif$></span></td>
<td><form action="<$HttpCgiPath$>" method="POST">
<input type=hidden name=dID value="<$dID$>">
<input type=hidden name=dDocName value="<$dDocName$>">
<input type=hidden name=IdcService value="RESUBMIT_FOR_CONVERSION">
<input type=submit value= "Resubmit ">
<$if ClientControlled$>
<input type=hidden name=ClientControlled value="DocMan">
<$endif$>
</form></td>
</tr>
</table>
</td>
</tr>
<$if IsFailedConversion$><$include std_namevalue_separator$><$endif$>
<$endif$>
</table>
<$if IsNotSyncRev$>
<table width="100%">
<tr>
<td align=center><span class=errorHighlight>The local copy of this content item has
not been updated to the latest revision.  Use <i>Get Native File</i> or <i>Check out</i>
to update your local copy of <i><$dDocName$></i>.</span></td>
</tr>
</table>
<$endif$>

<$if IsStagingDoc$>
<br>
<table width="90%">
<tr>
<td width="20%" align=center><$include doc_problem_reports$></td>
<td width="20%" align=center><$include project_problem_reports$></td>
</tr>
</table>
<$include doc_provider_info$>
<$else$>
<table width="90%">
<tr>
<$if ClientControlled$>
<td width="20%" align=center><$include doc_select_actions$></td>
<$else$>
<td width="20%" align=center><$include doc_file_undo_checkout$></td>
<td width="20%" align=center><$include doc_file_checkout$></td>
<td width="20%" align=center><$if showPrimaryMetaFileFields$><$include meta_file_update$>
<$else$><$include doc_file_update$><$endif$></td>
<$endif$>
<td width="20%" align=left><$include doc_subscription_unsubscription$></td>
<$if ClientControlled$>
<td width="20%"></td>
<td width="20%"></td>
<$endif$>
</tr>
</table>
<$endif$>
<$if HasOriginal and DownloadApplet$>
<$include download_native_applet$>
<$endif$>

<!-- end loop on DOC_INFO-->
<$endloop$>
<$if IsStagingDoc$>
<!-- present a problem report form -->
<$include doc_add_problem_report$>
<$else$>
<!-- Table holding information about all revisions of this document-->
<$include doc_rev_table$>
<$endif$>
</td>
</tr>
</table>
<$include std_page_end$>
<@end@>

3.3 サービス・リソースの作成

カスタム・コンポーネントとともに使用するためにサービス・リソースを作成するには、次の2つの方法があります。

3.3.1 カスタム・サービスの手動作成

カスタム・サービス・リソースを手動で作成するには:

3.3.2 HTMファイルでのサービスの定義

HTMファイルには、StandardServices表と構造が同一な表が格納されている必要があります。第3.1項「サービス構造の概要」を参照してください。

std_services.htmファイルのコピーを作成し、それをカスタム・コンポーネントの/resourcesディレクトリ内に置いて、混乱が生じないようにこのファイルの名前を変更します。例:

/custom/my_component/resources/my_services.htm
  1. StandardServices表の名前を新しい名前に変更します。例:

    <@table MyServices@>
    
  2. 作成するサービスに類似したサービスを除き、表の中の行をすべて削除します。

  3. 「名前」、「属性」、「アクション」の各列のエントリを編集します。

  4. ファイルを保存して閉じます。

たとえば、次のHTMファイルは、ADD_REPORTとREPORTS_LISTという2つのカスタム・サービスを示しています。

テキスト・エディタに表示されるカスタム・サービスのHTMファイルの例は、次のとおりです。

<HTML>
<HEAD>
<META HTTP-EQUIV='Content-Type' content='text/html; charset=iso-8859-1'>
<TITLE>Custom Scripted Services</TITLE>
</HEAD>
<BODY>
<@table MyServices@>
<table border=1><caption><strong>Scripts For Custom Services
</strong></caption>
<tr>
<td>Name</td><td>Attributes</td><td>Actions</td>
</tr>
<tr>
<td>ADD_REPORT</td>
<td>Service
18
ADD_REPORT_FORM
null
null<br>
Unable to add report.</td>
<td>2:Ireport::0:null</td>
</tr>
<tr>
<td>REPORTS_LIST</td>
<td>Service
17
REPORT_LIST_FORM
null
null<br>
Unable to retrieve reports.</td>
<td>5:Qreports:REPORT_LIST:0:null</td>
</tr>
</table>
<@end@>
<br><br>
</BODY>
</HTML>

図3-6 Webブラウザに表示されるカスタム・サービスのHTMファイルの例

図3-6については周囲のテキストで説明しています。

3.3.2.1 カスタム・コンポーネントのHDAファイル内にあるサービスのロード

  1. テキスト・エディタでカスタム・コンポーネントのコンポーネント定義(glue)ファイルを開きます。たとえば、DomainHome/ucm/cs/custom/my_component/my_component.hdaのようになります。

  2. 新しいHTMファイルをResourceDefinition ResultSetに追加します。例:

    @ResultSet ResourceDefinition
    4
    type
    filename
    tables
    loadOrder
    service
    resources/my_services.htm
    MyServices
    1
    @end
    
  3. ファイルを保存します。

3.3.3 コンポーネント・ウィザードを使用したカスタム・サービスの作成

コンポーネント・ウィザードを使用してサービス・リソースを作成するには、次の手順を実行します。

  1. コンポーネント・ウィザードで、リソースを作成するコンポーネントを開きます。

  2. 「リソースの定義」タブで、「追加」をクリックします。

図3-7 新しいカスタム・サービスの定義

図3-7については周囲のテキストで説明しています。
  1. 「リソースを追加します。」ウィンドウで「サービス」オプションを選択します。

  2. リソース・ファイルのファイル名を入力します。デフォルトのファイル名は、resources/componentname_service.htmです。

    サービスにリソース・ファイルが作成されている場合、ファイル名を選択して、新規のサービス表を既存のファイルに追加できます。ロード順に変更を加えた場合は、リソース・ファイル全体に適用されます。

    別のファイル名で新規リソース・ファイルを作成するには、ファイル名を入力します。例: my_services.htm

  3. 新規リソース・ファイルを特定の順序でロードする場合は、「ロード順」フィールドに数値を入力します。


    注意:

    リソース・ファイルを他のリソースの後にロードする特別な理由がある場合を除き、ロード順は1に設定されたままにしてください。


  4. 「次へ」をクリックします。

図3-8 新しいサービス表の定義

図3-8については周囲のテキストで説明しています。
  1. 「サービス表情報の追加」で、サービス表の名前を追加します。

    コンポーネント名を接頭辞として残すことをお薦めします。例: My_Component_Services

    サービス表が別のリソース・ファイルにある場合であっても、コンポーネントの各サービス表には、一意の名前を付ける必要があります。

  2. 「次へ」をクリックします。

図3-9 サービスの属性の定義

図3-9については周囲のテキストで説明しています。
  1. 「サービスの追加」ウィンドウで、サービスの属性を直接入力するか、または次のようにして既存のサービス定義から始めます。

    1. 「選択」をクリックします。よく使用されるサービスのリストが表示されます。

    2. 「すべて表示」チェック・ボックスを選択して、事前定義サービスのリスト全体を表示します。

    3. リストからサービスを選択します。サービスの詳細を表示するには、そのサービス名をハイライトして、「プレビュー」をクリックします。


      ヒント:

      選択したサービスのオンライン・ヘルプを表示するには、「サービスservice_nameの情報をプレビュー」ダイアログで「ヘルプ」ボタンをクリックします。


    4. 「OK」をクリックします。サービスの属性とアクションが入力されます。


      注意:

      サービスの名前を変更しない場合、このコンポーネントを最後にロードすると、カスタム・サービスにより標準サービスおよび同じ名前の他のカスタム・サービスがオーバーライドされます。


    5. 必要に応じて、サービスの属性を編集します。

  2. 必要に応じて、アクションを入力します。

    • アクションは、実行順に「アクション」リストに表示される必要があります。「上へ」および「下へ」ボタンを使用して、選択したアクションを移動します。

    • アクションを追加する場合は、「追加」をクリックします。アクション定義を入力して、「OK」をクリックします。

    • アクションを編集する場合は、アクションを選択して「編集」をクリックします。アクション定義を変更して、「OK」をクリックします。

    • アクションを削除する場合は、アクションを選択して「削除」をクリックします。

図3-10 アクションの定義

図3-10については周囲のテキストで説明しています。
  1. 「終了」をクリックします。

  2. ダイアログ・ボックスが表示され、テキスト・エディタを起動して編集を続行するように求められます。リソース・ファイルをテキスト・エディタで開く場合は、「はい」をクリックします。コンポーネント・ウィザードに戻る場合は、「いいえ」をクリックします。

    サービス・リソース・ファイルが「カスタム・リソース定義」リストに表示され、サービス表が右ペインの「表名」リストに表示されます。

図3-11 コンポーネント・ウィザードで定義されたカスタム・サービス・リソース

図3-11については周囲のテキストで説明しています。