Oracle® Oracle Fusion Middleware Oracle WebCenter Contentのマネージング 11g リリース1(11.1.1) B72426-01 |
|
![]() 前 |
![]() 次 |
Inbound Refineryは、コンテンツ・サーバーおよびInbound Refinery上にインストールおよび有効化されているコンポーネントに応じて、様々な変換オプションを提供します。この章では、様々な変換オプションの概要を説明します。
基本的な変換を行うには、最低でも次のコンポーネントをインストールして有効化する必要があります。
コンポーネント名 | コンポーネントの説明 | 有効にするサーバー |
---|---|---|
InboundRefinery |
Inbound Refineryを有効にします。 |
Inbound Refineryサーバー |
InboundRefinerySupport |
コンテンツ・サーバーとInbound Refineryの併用を有効にします。 |
コンテンツ・サーバー |
この章では、次の項目について説明します。
注意: コンテンツ・サーバーがInbound Refineryインスタンスを処理するように構成されている場合を除き、ファイルはすべてネイティブ・フォーマットでWebサイトに渡されます。 |
コンテンツ・サーバーがInbound Refineryインスタンスのプロバイダとして構成されている場合は、変換用にリファイナリに渡されるファイル・フォーマットを、次のいずれかの方法で指定する必要があります。
「管理」メニューの「リファイナリ管理」を選択することによってアクセスできる、ファイル・フォーマット・ウィザードを使用します。
構成マネージャ・アプレットの「ファイル・フォーマット」オプションを使用して、ファイル拡張子(.doc、.txtなど)をファイル・フォーマットにマップした後、リファイナリでファイル・フォーマットを変換オプションにマップします。このオプションには、様々なファイル拡張子を様々な変換オプションにマップする柔軟性があります。
ファイル・フォーマットやカスタム・フィールドなどのコンテンツ・アイテムに対して指定された、メタデータ・フィールドの値の変換に基づくカスタム・コンポーネントを作成します。
ジョブがコンテンツ・サーバーからInbound Refineryに渡された後は、リファイナリの構成によって、ネイティブ・ファイルを変換および返す方法が決定されます。ファイル・フォーマットはインストール時に自動的に構成されるか、または、必要に応じて追加または変更できます。
この項の項目は次のとおりです。
新しいファイル・フォーマットを定義する場合は、ファイル拡張子に対応するMIME (Multipurpose Internet Mail Extensions)タイプを指定することをお薦めします(たとえば、docファイル拡張子にマップされるフォーマットはapplication/mswordになります)。
コンテンツ・アイテムがリポジトリにチェックインされると、そのコンテンツ・アイテムのフォーマットは、ネイティブ・ファイルのファイル拡張子にマップされているフォーマットに従って割り当てられます。ネイティブ・ファイルが変換されない場合、コンテンツ・サーバーでは、コンテンツ・アイテムをクライアントに配信する際にこのフォーマットを含めます。フォーマットにMIMEタイプを使用すると、クライアントでは、ファイルのデータのタイプや関連付けられたヘルパー・アプリケーションなどの判断に役立ちます。
MIMEタイプおよび登録済のMIMEタイプのリストは、http://www.iana.org/assignments/media-types/index.html
で確認します。
コンテンツの変換に使用されるネイティブ・アプリケーションは、次の要件を満たす必要があります。
ネイティブ・アプリケーション | 要件 |
---|---|
MS Word MS Project Lotus Freelance MS Excel Lotus 123 Corel WordPerfect MS PowerPoint Lotus WordPro MS Visio iGrafx Designer |
Inbound Refineryで変換用に必要な場合は、ネイティブ・アプリケーションがインストールされていることを確認します。 「ファイル・フォーマット」タブで、ファイル・タイプを変換プロセスに関連付けます。 WordおよびPowerPointアプリケーションの場合は、「ローカルInbound Refineryの構成」ページの「ネイティブ・オプション」タブを使用して、リンクを処理するかどうかを指定します。 |
MS Publisher FrameMaker PhotoShop PageMaker |
ネイティブ・アプリケーションがインストールされていることを確認します。 Inbound Refineryでファイル・パスを構成します。FrameMakerブックをチェックインするには、「複数ファイルのアップロード」オプション(「システム・プロパティ」で有効にしておく必要があります)を使用します。 「ファイル・フォーマット」タブで、ファイル・タイプを変換プロセスに関連付けます。 |
その他 |
ネイティブ・アプリケーションがインストールされていることを確認します(必要な場合)。 Inbound Refineryにカスタム変換プログラムをインストールします。 Inbound Refineryでファイル・パスを構成します。 「ファイル・フォーマット」タブで、ファイル・タイプを変換プロセスに関連付けます。 |
ファイル・タイプと変換プログラムの関連付けは、2段階のプロセスとなります。
ファイル・フォーマットを追加し、フォーマットにファイル拡張子を関連付けます。
「メイン」メニューから「管理」→「管理アプレット」を選択します。
「構成マネージャ」をクリックします。
構成マネージャ・ページで、ページ・メニューの「オプション」→「ファイル・フォーマット」を選択します。
ファイル・フォーマット・ページで、ファイル・フォーマットを追加するために、「ファイル・フォーマット」ペインの「追加」をクリックします。
ファイル・フォーマットの追加/ファイル・フォーマットの編集ページで、必要な情報を入力します。
フォーマット: 通常はMIMEタイプです。
変換タイプ: フォーマット名を変換プログラムに関連付けます。次のいずれかを選択します。
通過: PASSTHRUにマップされた拡張子のドキュメントは、変換されませんが、Webサイト上にはそのネイティブ・ファイル・フォーマットで表示されます。クライアント・コンピュータに、そのネイティブ・アプリケーションがある必要があります。
レガシー・カスタム: CUSTOMにマップされた拡張子のドキュメントは、標準の変換のセットに含まれていない変換プログラムを実行します。このオプションは、このリリースではサポートされていません。
説明: ファイル・フォーマットの簡単な説明。
「OK」をクリックします。
ファイル・フォーマットに関連付けるファイル拡張子を入力します。
「ファイル拡張子」ペインで、「追加」をクリックします。
ファイル拡張子の追加/ファイル拡張子の編集ページで、必要な情報を入力します。
拡張子: ファイル・フォーマットに対する3文字の指定。この拡張子のファイルは、「マップ先フォーマット」フィールドで指定した変換プログラムを使用して変換されます。
マップ先フォーマット: 指定された変換で使用可能なフォーマット(「ファイル・フォーマット」ペインで定義)のリスト。フォーマットを選択すると、該当する拡張子のすべてのファイルが、特定の変換プログラムに直接関連付けられます。
「OK」をクリックします。
サムネイルは、コンテンツの小さなプレビュー・イメージです。検索結果のページで使用され、通常は、それらが表すWeb表示可能ファイルにリンクしています。サムネイルによって、実際にファイル自体を開くことなく確認できる、視覚的なサンプルがコンシューマに示されます。これにより、より大きい元のファイルのダウンロードを行う前に、ファイルを確認できます。デフォルトで、基本的な一連のサムネイル作成オプションが用意されています。
Inbound Refineryは、コンテンツ・サーバーによって管理されているコンテンツを調整するために使用できます。Inbound Refineryは、コンテンツ・サーバーと同じコンピュータまたは1台以上の別のコンピュータにインストールできます。インストール後に、同じまたは別のコンピュータ上のコンテンツ・サーバー・インスタンスに、プロバイダとしてリファイナリを追加する必要があります。詳細は、23.3.1項を参照してください。
注意: Oracle Inbound Refineryでは、クラスタ環境での実行はサポートされていません。Inbound Refineryはコンテンツ・サーバー・クラスタに対する変換作業は実行できますが、それ自体をクラスタ環境で実行することはできません。Inbound Refineryは正しく機能するように、 |
様々な構成が可能なため、リファイナリ環境の設定時には、次の一般ルールに留意してください。
1日に大量のコンテンツ・アイテムを処理する場合は、コンテンツ・サーバーと同じコンピュータ上でInbound Refineryを実行しないでください。
インストールされる専用のリファイナリ・システムの数が多いほど、コンテンツの処理速度は速くなります。コンテンツ・サーバー・インスタンスの数よりもリファイナリ・システムの数を多くすることにより、最適な速度を実現できます。コンテンツ・サーバーの数よりリファイナリ・システムの数が少ないと、多数のファイルを変換する場合にパフォーマンスが低下します。
通常、リファイナリはシステムのリソースを共有するため、同じコンピュータ上で複数のリファイナリを実行すべき理由はありません。1つのリファイナリが複数のコンテンツ・サーバーに対してプロバイダとして機能できます。これには、変換時に使用されるサード・パーティ・アプリケーションも含まれます。パフォーマンスを向上させるには、各リファイナリに対して別々のコンピュータを使用します。
一部のファイル・タイプや大きなファイルの場合は、平均よりも処理時間がかかります。他のファイル・タイプに加え、これらのタイプを多数処理する必要がある場合は、これらのファイル・タイプのみを処理するリファイナリを別のシステム上に設定することを検討してください。これには複数のリファイナリ・システムが必要になりますが、最適な調整速度およびパフォーマンスを得られます。
次に一般的なシナリオを示します。この項で説明するリファイナリ構成に加え、その他の構成も可能です。特定のコンテンツ管理アプリケーションでは独自のリファイナリ設定が必要なことがあり、この項で紹介するいずれのシナリオとも合致しない場合があります。
シナリオA: 同じコンピュータ上に1つのコンテンツ・サーバーと1つのリファイナリ。
シナリオB: 同じコンピュータ上に複数のコンテンツ・サーバーと1つのリファイナリ。
シナリオC: 別々のコンピュータ上に複数のコンテンツ・サーバーと1つのリファイナリ。
シナリオD: 別々のコンピュータ上に1つのコンテンツ・サーバーに付き1つのリファイナリ。
シナリオE: 別々のコンピュータ上に1つのコンテンツ・サーバーに付き複数のリファイナリ。
これらの各シナリオについて、次の各項で、それぞれのシナリオのメリットおよび考慮すべき注意事項も含めて詳しく説明します。シナリオの図では、コンピュータ、コンテンツ・サーバーおよびInbound Refineryを表すために、次の記号を使用します。
大きい丸: コンピュータ
小さい丸: Inbound Refinery
小さい四角: コンテンツ・サーバー
これは最も基本的なシナリオです。同じコンピュータ上にインストールされた1つのコンテンツ・サーバーと1つのリファイナリから構成されます。
長所:
最も安価で、構成が最も容易です。
購入する必要がある、リファイナリ変換に必要なサード・パーティ・アプリケーションは1つだけです。
考慮事項:
変換の数および速度が制限されています。
リファイナリがコンテンツ・サーバー・コンピュータにデプロイされていないシナリオほど処理能力は高くありません。これは、コンテンツ・サーバー・コンピュータ上でのリファイナリ処理は検索やWebサイトへのアクセス速度を低下させることがあり、その逆もまた同様のためです。ファイル・タイプとサイズに応じて、各変換には数秒から数分かかります。
このシナリオは、同じコンピュータ上にインストールされた複数のコンテンツ・サーバーと1つのリファイナリから構成されます。
長所: 購入する必要がある、リファイナリ変換に必要なサード・パーティ・アプリケーションは1つだけです。
考慮事項:
変換の数および速度が制限されています。
リファイナリがコンテンツ・サーバー・コンピュータにデプロイされていないシナリオほど処理能力は高くありません。これは、コンテンツ・サーバー・コンピュータ上でのリファイナリ処理は検索やWebサイトへのアクセス速度を低下させることがあり、その逆もまた同様のためです。ファイル・タイプとサイズに応じて、各変換には数秒から数分かかります。
この構成では、リファイナリのデプロイ時には通常、次の選択を行います。
リファイナリをいずれかのコンテンツ・サーバーのプロバイダとして設定します。デプロイメント後に、このリファイナリを他のコンテンツ・サーバーに対してプロバイダとして追加する必要があります。詳細は、23.3.1項を参照してください。
このシナリオは、別々のコンピュータ上にインストールされた複数のコンテンツ・サーバーと1つのリファイナリから構成されます。
長所:
購入する必要がある、リファイナリ変換に必要なサード・パーティ・アプリケーションは1つだけです。
リファイナリがコンテンツ・サーバーと同じコンピュータ上にデプロイされている場合よりも、処理が高速です。
リファイナリの処理はコンテンツ・サーバーの検索およびWebサイトへのアクセスに影響しません。その逆もまた同様です。
考慮事項:
1つのコンテンツ・サーバーに付き1つのリファイナリが存在するシナリオほど処理能力は高くありません。
この構成では、リファイナリのデプロイ時には通常、次の選択を行います。
リファイナリは、各コンテンツ・サーバーに対してプロバイダとして追加する必要があります。詳細は、23.3.1項を参照してください。
このシナリオは、別々のコンピュータ上にインストールされた1つのコンテンツ・サーバーに付き1つのリファイナリから構成されます。
長所:
大量のコンテンツおよび大きなファイル・サイズに対して高速処理を行えます。
リファイナリの処理はコンテンツ・サーバーの検索およびWebサイトへのアクセスに影響しません。その逆もまた同様です。
考慮事項:
各リファイナリ・コンピュータに、変換に必要なすべてのサード・パーティ・アプリケーションのコピーが必要です。
各リファイナリを、各コンテンツ・サーバーに対してプロバイダとして追加する必要があります。詳細は、23.3.1項を参照してください。
このシナリオは、別々のコンピュータ上にインストールされた1つのコンテンツ・サーバーに付き複数のリファイナリから構成されます。
長所:
大量のコンテンツおよび大きなファイル・サイズに対して最高速で処理を行えます。
リファイナリの処理はコンテンツ・サーバーの検索およびWebサイトへのアクセスに影響しません。その逆もまた同様です。
考慮事項:
各リファイナリ・コンピュータに、変換に必要なすべてのサード・パーティ・アプリケーションのコピーが必要です。
この構成では、リファイナリのデプロイ時には通常、次の選択を行います。
各リファイナリを、各コンテンツ・サーバーに対してプロバイダとして追加する必要があります。詳細は、23.3.1項を参照してください。
このセクションのトピックは次のとおりです:
コンテンツ・サーバーは、プロバイダを通してリファイナリと通信します。1つのリファイナリは、1つまたは複数のコンテンツ・サーバーに対してプロバイダとして機能できます。一般的な構成の詳細は、第23.2項を参照してください。
リファイナリは、同じコンピュータ上のコンテンツ・サーバーにプロバイダとして追加するか、デプロイメント後に別のコンピュータ上のコンテンツ・サーバーに追加できます。
このセクションのトピックは次のとおりです:
リファイナリをプロバイダとしてコンテンツ・サーバーに追加する手順は次のとおりです。
管理者としてコンテンツ・サーバーにログインします。
「メイン」メニューで、「管理」→「プロバイダ」を選択します。
プロバイダ・ページの「新規プロバイダの作成」セクションで、「送信」プロバイダ・タイプの「アクション」列にある「追加」をクリックします。
送信ソケット・プロバイダの追加/送信ソケット・プロバイダの編集ページで、次のフィールドに入力します。
プロバイダ名(必須): リファイナリ・プロバイダの名前。
プロバイダの説明(必須): わかりやすいプロバイダの説明。
プロバイダ・クラス(必須): プロバイダのJavaクラスの名前。デフォルトは、intradoc.provider.SocketOutgoingProviderクラスです。
接続クラス: 必須ではありません。
構成クラス: 必須ではありません。
サーバー・ホスト名(必須): リファイナリがインストールされているサーバーのホスト名。
HTTPサーバー・アドレス: リファイナリのHTTPサーバー・アドレス。リファイナリがコンテンツ・サーバーと同じコンピュータ上に存在している場合は、必須ではありません。
サーバー・ポート(必須): リファイナリ・プロバイダが通信するポート。このエントリは、Inbound Refineryのデプロイメント時にインストール後の構成ページで構成したサーバー・ソケット・ポートと一致する必要があります。インストール後の構成の詳細は、『Oracle WebCenter Contentインストレーション・ガイド』を参照してください。デフォルトのリファイナリ・ポートは5555です。
インスタンス名(必須): リファイナリのインスタンス名。たとえば、ref2です。
相対Webルート(必須): リファイナリの相対Webルートは/ibr/です。
接続先のリファイナリでコンテンツ・サーバーに対する認証が要求される場合は、「接続パスワードの使用」チェック・ボックスを選択します(コンテンツ・サーバーはリファイナリのユーザー・ベースを共有するようになります)。選択した場合は、使用するユーザー名とパスワードを指定し、リファイナリ上にProxyConnectionsコンポーネントをインストールして構成する必要があります。
「Inbound Refinery変換ジョブの処理」チェック・ボックスを選択します。これは必須です。
「Inbound Refineryの読取り専用モード」チェック・ボックスの選択を解除します。コンテンツ・サーバーで新規の変換ジョブをリファイナリに送信しない場合にのみ、このチェック・ボックスを選択します。
必要な場合は、コンテンツ・サーバーの事前変換されたキューで許可されるジョブの最大数を変更します。デフォルトは1000ジョブです。
「追加」をクリックします。「プロバイダ」表に新しいリファイナリ・プロバイダが追加されたプロバイダ・ページが表示されます。
コンテンツ・サーバーを再起動します。
既存のリファイナリ・プロバイダの情報を編集するには、プロバイダ・ページにアクセスし、編集するプロバイダの「アクション」メニューの「情報」をクリックします。送信ソケット・プロバイダの追加/送信ソケット・プロバイダの編集ページで、必要な変更を加えます。完了したらコンテンツ・サーバーを再起動します。
既存のリファイナリ・プロバイダを有効または無効にする手順は次のとおりです。
管理者としてコンテンツ・サーバーにログインします。
「メイン」メニューで、「管理」→「プロバイダ」を選択します。
プロバイダ・ページの「プロバイダ」表で、有効または無効にするリファイナリ・プロバイダの「アクション」列の「情報」をクリックします。
プロバイダ情報ページで、「無効化」または「有効化」をクリックします。
コンテンツ・サーバーを再起動します。
既存のリファイナリ・プロバイダを削除する手順は次のとおりです。
管理者としてコンテンツ・サーバーにログインします。
「メイン」メニューで、「管理」→「プロバイダ」を選択します。
プロバイダ・ページの「プロバイダ」表で、削除するリファイナリ・プロバイダの「アクション」列の「情報」をクリックします。
プロバイダ情報ページで、「削除」をクリックします。確認メッセージが表示されます。
「OK」をクリックします。
リファイナリへのアクセスを制限するためにIPセキュリティ・フィルタを使用します。指定された条件に一致するIPまたはIPv6アドレスのホストのみにアクセスが許可されます。デフォルトでは、IPセキュリティ・フィルタは127.0.0.1|0:0:0:0:0:0:0:1です。これは、Inbound Refineryはlocalhostからの通信のみをリスニングすることを意味します。コンテンツ・サーバーがそのすべてのリファイナリと通信できるようにするには、リファイナリのIPセキュリティ・フィルタに、各コンテンツ・サーバー・コンピュータのIPまたはIPv6アドレスを追加する必要があります。これは、リファイナリがコンテンツ・サーバーと同じコンピュータ上で実行されている場合も同様です。リファイナリのIPセキュリティ・フィルタを編集する手順は次のとおりです。
リファイナリ・コンピュータにアクセスします。
システム・プロパティ・アプリケーションを起動します。
Windows: 「スタート」→「プログラム」を選択します。Oracle Content Server/Inbound Refinery→instance_name→「ユーティリティ」→「システム・プロパティ」を選択します。
UNIX: リファイナリのインストール・ディレクトリの/bin
サブディレクトリにあるSystemProperties
スクリプトを実行します。
「サーバー」タブを選択します。
「IPアドレス・フィルタ」フィールドには、各コンテンツ・サーバー・コンピュータのIPまたはIPv6アドレスが含まれている必要があります(これが、リファイナリ・サーバーも実行されているのと同じ物理コンピュータである場合も)。このフィールドのデフォルト値は127.0.0.1|0:0:0:0:0:0:0:1(localhost)ですが、有効なIPまたはIPv6アドレスをいくつでも追加できます。パイプ記号(|)で区切ることにより複数のIPアドレスを指定できます。また、ワイルドカード(0個以上の文字を表す*、および1文字を表す?)も使用できます。次に例を示します。
127.0.0.1|0:0:0:0:0:0:0:1|10.10.1.10|62.43.163.*|62.43.161.12?
重要: localhostのIPアドレス(127.0.0.1)は必ず含めてください。 |
完了したら「OK」をクリックし、リファイナリ・サーバーを再起動します。
ヒント: または、 |
コンテンツ・サーバーおよびInbound Refineryでは、Outside In Technologyを使用します。Ouside In Technologyは、すべてのLinuxプラットフォームに加えて、SolarisプラットフォームとHPUX ia64の両方で、GCCライブラリ(libgcc_sとlibstdc++)に動的にリンクされます。コンテンツ・サーバーはこれらのライブラリにアクセスできる必要がありますが、SolarisとHPUXではこれらのライブラリはデフォルトでは利用できません。コンテンツ・サーバーまたはInbound RefineryをSolarisまたはHPUXのいずれかで実行している場合は、GCCライブラリを入手してインストールし、それらを検出するようにコンテンツ・サーバーを構成する必要があります。ライブラリ・パスの構成の詳細は、『Oracle WebCenter Contentインストレーション・ガイド』を参照してください。
コンテンツ・サーバーでは、ファイル拡張子、ファイル・フォーマットおよび変換を使用して、コンテンツ・アイテムがInbound Refineryおよびその変換アドオンによってどのように処理されるべきかを定義します。また、アプリケーション開発者はカスタム変換を作成することもできます。
このセクションのトピックは次のとおりです:
通常、ファイル・フォーマットはそのMultipurpose Internet Mail Extension(MIME)タイプにより識別され、各ファイル・フォーマットは特定の変換にリンクされます。各ファイル拡張子は、特定のファイル・フォーマットにマップされます。したがって、チェックインされたファイルの拡張子に基づいて、コンテンツ・サーバーは、ファイルがリファイナリによって処理されるかどうか、およびどのように処理されるかを制御できます。リファイナリの変換設定は、リファイナリが承認する変換を指定し、変換の出力を制御します。
次の例を考えてみます。docファイル拡張子がファイル・フォーマットapplication/mswordにマップされており、これは変換Wordにリンクされています。これは、コンテンツ・サーバーが、コンテンツ・サーバーにチェックインされたすべてのMicrosoft Wordファイル(拡張子がdocのファイル)を、変換用にリファイナリに送信しようとすることを意味します。
別の例として、xlsファイル拡張子がファイル・フォーマットapplication/vnd.ms-excelにマップされており、これは変換PassThruにリンクされているとします。この場合、Microsoft Excelファイルはリファイナリには送信されません。かわりに、ネイティブ・ファイルのコピーまたはネイティブ・ボールト・ファイルを指すHCSTファイルを/weblayoutディレクトリに配置するように、コンテンツ・サーバーを構成できます。つまり、ユーザーがこのファイルを表示するには、ネイティブ・ファイルを開くことができるアプリケーションがユーザーのコンピュータにインストールされている必要があります。
ファイルがコンテンツ・サーバーにチェックインされ、そのファイル・フォーマットが変換にマップされていると、コンテンツ・サーバーは、その変換を承認して変換ジョブを実行できるリファイナリ・プロバイダがあるかどうかを確認します。これは、次のことを意味します。
コンテンツ・サーバーに対してリファイナリ・プロバイダが設定されている必要があります。詳細は、23.3.1項を参照してください。
リファイナリが変換を承認するように構成されている必要があります。詳細は、23.6.2項を参照してください。
変換では、実行すべき変換ステップや使用すべき変換エンジンも含め、特定のファイル・フォーマットをどのように処理すべきかを指定します。詳細は、第23.4.2項を参照してください。
コンテンツ・サーバーで使用可能な変換は、リファイナリで使用可能な変換と一致する必要があります。あるファイル・フォーマットがコンテンツ・サーバーで変換にマップされると、そのフォーマットのファイルは、チェックイン時に変換用に送信されます。その変換を承認するように、1つ以上のリファイナリが設定されている必要があります。詳細は、23.6.2項を参照してください。
次のデフォルト変換を使用できます。変換アドオンをインストールすると、追加の変換が使用可能になります。詳細は、特定の変換アドオンのドキュメントを参照してください。
変換 | 説明 |
---|---|
PassThru |
ファイルが変換されないようにするために使用します。この変換がファイル・フォーマットにリンクされていると、そのファイル・フォーマットにマップされているすべてのファイル拡張子は変換用に送信されません。ネイティブ・ファイルのコピーまたはネイティブ・ボールト・ファイルを指すHCSTファイルを |
Word |
Microsoft Word、Microsoft Writeおよびリッチ・テキスト形式(RTF)ファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。 |
Excel |
Microsoft Excelファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。 |
PowerPoint |
Microsoft PowerPointファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。 |
MSProject |
Microsoft Projectファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。 |
Distiller |
PostScriptファイルを変換用に送信するために使用します。ファイルは指定されたPostScript Distillerエンジンを使用してPDFに変換されます。 |
MSPub |
Microsoft Publisherファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。 |
FrameMaker |
Adobe FrameMakerファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。 |
Visio |
Microsoft Visioファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。 |
WordPerfect |
Corel WordPerfectファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。 |
PhotoShop |
Adobe Photoshopファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。 |
InDesign |
Adobe InDesign、Adobe PageMakerおよびQuarkXPressファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。 |
MSSnapshot |
Microsoft Snapshotファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。 |
PDF Refinement |
チェックインされたPDFファイルを調整用に送信するために使用します。リファイナリの変換設定に応じて、これには指定されたPostScript Distillerエンジンを使用した、高速Web表示用のPDFファイルの最適化が含まれます。 |
Ichitaro |
このバージョンのInbound Refineryでは、一太郎の変換はサポートされていません。 |
OpenOffice |
OpenOfficeおよびStarOfficeファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。 |
ImageThumbnail |
選択したグラフィック・フォーマットを単純なサムネイルのみの作成用に送信するために使用します。これは、Inbound Refineryはインストールされていないが、グラフィック・フォーマットのサムネイル・イメージが必要な場合に有用です。返されるWeb表示可能ファイルは、ネイティブ・ファイルのコピーであり、オプションでサムネイル・イメージになります。 Inbound Refineryがインストールされている場合は、ImageThumbnail変換のかわりに、イメージ・レンディションおよびサムネイルの作成も含め、変換用にグラフィック・フォーマットを送信するために使用できます。 |
NativeThumbnail |
中間のPDF変換からではなく、ネイティブ・フォーマットからのサムネイルの作成用に、選択したファイル・フォーマットを送信するために使用します。通常、この変換は、テキスト・ファイル(TXT)、Microsoft Outlook電子メール・ファイル(EMLとMSG)およびOfficeドキュメントのサムネイルを、先にPDFに変換せずに作成するために使用します。返されるWeb表示可能ファイルは、ネイティブ・ファイルのコピーであり、オプションでサムネイル・レンディションやXMLレンディションになります。XMLレンディションを作成するには、XMLConverterがインストールされており、XMLステップが構成および有効化されている必要があります。 |
MultipageTiff |
Outside In Image Exportを使用した複数ページのTIFFファイルへの直接変換用にファイルを送信するために使用します。ファイル・フォーマットがこの変換にマップされている場合、リファイナリの変換設定は無視され、ファイルはTIFFファイルへの変換用にImage Exportに直接送信されます。 |
OutsideIn Technology |
リファイナリ・サーバー上でのWinNativeConverterを使用した変換用に、サポートされているフォーマットをPostScriptに印刷するためにOutside In Xを使用します。 |
Direct PDFExport |
Outside In PDF Exportを使用したPDFへの直接変換用にファイルを送信するために使用します。 |
FlexionXML |
XML Converterを使用した変換用にファイルを送信するために使用します。 |
SearchML |
XML Converterを使用した変換用にファイルを送信するために使用します。 |
XML-XSLT Transformation |
XML Converterを使用したXSLT変換用にファイルを送信するために使用します。XSLT変換は、XMLデータを別のフォーマットに出力するために使用します。 |
LegacyCustom |
このバージョンのInbound Refineryでは、LegacyCustom変換はサポートされていません。 |
Digital Media Graphics |
Digital Asset Managerがインストールされている場合、Image Managerを使用した複数のイメージ・レンディションへの変換用にデジタル・イメージを送信するために使用します。 |
Digital Media Video |
Digital Asset Managerがインストールされている場合、Video Managerを使用した複数のビデオまたはオーディオ・レンディションへの変換用にデジタル・ビデオを送信するために使用します。 |
TIFFConversion |
ドキュメント内でのテキストの索引付けが可能なPDFフォーマットへの変換用にTIFFファイルを送信するために使用します。 |
Word HTML |
ネイティブMicrosoft Wordアプリケーションを使用したHTMLへの変換用にMicrosoft Wordファイルを送信するために使用します。 |
PowerPoint HTML |
ネイティブMicrosoft PowerPointアプリケーションを使用したHTMLへの変換用にMicrosoft PowerPointファイルを送信するために使用します。 |
Excel HTML |
ネイティブMicrosoft Excelアプリケーションを使用したHTMLへの変換用にMicrosoft Excelファイルを送信するために使用します。 |
Visio HTML |
ネイティブMicrosoft Visioアプリケーションを使用したHTMLへの変換用にMicrosoft Visioファイルを送信するために使用します。 |
ファイル・フォーマットが変換PassThruにリンクされていると、そのファイル・フォーマットにマップされているすべてのファイル拡張子は変換されません。ファイル拡張子がPassThruにマップされているコンテンツ・アイテムがコンテンツ・サーバーにチェックインされると、そのファイルはリファイナリには送信されず、Web表示可能ファイルは作成されません。ネイティブ・ファイルのコピー、またはネイティブ・ファイルを指すHCSTファイルをWebレイアウト・ディレクトリに配置するように、コンテンツ・サーバーを構成できます。これは、ユーザーがファイルを表示するには、ファイルの作成に使用されたアプリケーション、またはファイルを開くことができるアプリケーションが、各クライアント上にインストールされている必要があることを意味します。詳細は、23.4.3項を参照してください。
ファイルがリファイナリに送信され、変換が失敗したことがリファイナリによってコンテンツ・サーバーに通知される場合、ネイティブ・ファイルのコピーをWebレイアウト・ディレクトリに配置するようにコンテンツ・サーバーを構成できます。この場合、ユーザーがこのファイルを表示するには、ネイティブ・ファイルを開くことができるアプリケーションがユーザーのコンピュータにインストールされている必要があります。詳細は、23.4.4項を参照してください。
新しいファイル・フォーマットには、ファイル拡張子に対応するMIME(Multipurpose Internet Mail Extensions)タイプによって名前を付けることをお薦めします(たとえば、docファイル拡張子にマップされるフォーマットはapplication/mswordとするなど)。
コンテンツ・アイテムがコンテンツ・サーバーにチェックインされると、そのコンテンツ・アイテムのフォーマットは、ネイティブ・ファイルのファイル拡張子にマップされているフォーマットに従って割り当てられます。ネイティブ・ファイルが変換されない場合、コンテンツ・サーバーでは、コンテンツ・アイテムをクライアントに配信する際にこのフォーマットを含めます。フォーマットにMIMEタイプを使用すると、クライアントでは、ファイルのデータのタイプや使用する必要があるヘルパー・アプリケーションなどの判断に役立ちます。
ネイティブ・ファイルが変換されると、Inbound RefineryはWeb表示可能ファイルに適切なフォーマットを割り当て(たとえば、リファイナリがPDFファイルを生成した場合、このファイルをapplication/pdfと識別します)、コンテンツ・サーバーはクライアントへのWeb表示可能ファイルの配信時に(ネイティブ・ファイルに対して指定されているフォーマットではなく)このフォーマットを含めます。
Inbound Refineryには、インストール時に自動的に構成されるファイル・フォーマットの広範なリストが含まれます。コンテンツ・サーバー・プロバイダの構成マネージャ・アプレットでリストを確認してください。新しいフォーマットは、珍しいフォーマットまたは独自のフォーマットで作業する場合にのみ追加する必要があります。
ファイル・フォーマットに対する正しいMIMEタイプを判別するために有用なリソースがインターネットで提供されています。次に例を示します。
ファイル・タイプとファイル・フォーマットの構成の詳細を管理するには、ファイル・フォーマット・ウィザード・ページまたは構成マネージャを使用します。ファイル・フォーマット・ウィザード・ページは、一般的なほとんどのファイル・タイプの変換を構成するために使用できますが、構成マネージャ・アプレットのすべての機能が複製されるわけではありません。
重要: ファイル・フォーマット・ウィザード・ページを有効にするには、コンテンツ・サーバーにInboundRefinerySupportコンポーネントをインストールして有効にし、少なくとも1つのInbound Refineryプロバイダを有効にする必要があります。また、変換オプション・コンポーネントによって、ファイル・タイプがファイル・フォーマット・ウィザード・ページに追加される場合があります。 |
ファイル・フォーマット・ウィザード・ページを使用する手順は次のとおりです。
管理者としてログインします。
「メイン」メニューで「管理」→「リファイナリ管理」→「ファイル・フォーマット・ウィザード」を選択します。
ファイル・フォーマット・ウィザード・ページで、変換用にリファイナリに送信される各ファイル・タイプに対するチェック・ボックスを選択します。すべてのチェック・ボックスを選択または選択解除するには、ヘッダー行でチェック・ボックスを選択または選択解除します。
重要: このバージョンのInbound Refineryでは、一太郎の変換はサポートされていません。 |
最後に保存した設定に戻すには、「リセット」をクリックします。
「更新」をクリックします。選択したファイル・タイプに対して、対応するデフォルトのファイル拡張子、ファイル・フォーマットおよび変換が、自動的にマップされます。
構成マネージャを使用する手順は次のとおりです。
管理者としてログインします。
「メイン」メニューから「管理」→「管理アプレット」を選択します。「構成マネージャ」を選択します。
「オプション」→「ファイル・フォーマット」を選択します。
ファイル・フォーマットを追加して変換にリンクする手順は次のとおりです。
ファイル・フォーマット・ページで、「ファイル・フォーマット」セクションの「追加」をクリックします。
新しいファイル・フォーマットの追加/ファイル・フォーマットの編集ページで、「フォーマット」フィールドにファイル・フォーマットの名前を入力します。任意の名前を使用できますが、対応するファイル拡張子(複数の場合あり)に関連付けられているMIMEタイプを使用することをお薦めします。
「変換」ドロップダウン・リストから適切な変換を選択します。
重要: このバージョンのInbound Refineryでは、一太郎の変換はサポートされていません。 |
「説明」フィールドにファイル・フォーマットの説明を入力します。
「OK」をクリックして設定を保存します。
ファイル・フォーマットを編集するには、ファイル・フォーマットを選択して「編集」をクリックします。新しいファイル・フォーマットの追加/ファイル・フォーマットの編集ページで、適切な変更を加えます。
ファイル拡張子を追加し、ファイル・フォーマットにマップする(およびそれによりファイル拡張子を変換に関連付ける)手順は次のとおりです。
ファイル・フォーマット・ページで、「ファイル拡張子」セクションの「追加」をクリックします。
ファイル拡張子の追加/ファイル拡張子の編集ページで、ファイル拡張子を入力します。
「マップ先フォーマット」ドロップダウン・リストで、定義済ファイル・フォーマットのリストから適切なファイル・フォーマットを選択します。ファイル・フォーマットを選択すると、指定した拡張子を持つすべてのファイルが、そのファイル・フォーマットにリンクされている特定の変換に直接割り当てられます。
「OK」をクリックして設定を保存します。
ファイル拡張子を編集するには、「ファイル・フォーマット」ページでファイル拡張子を選択し、「編集」をクリックします。適切な変更を行います。
ファイル・フォーマットが変換PassThruにリンクされていると、そのファイル・フォーマットにマップされているすべてのファイル拡張子は変換用に送信されません。デフォルトでは、コンテンツ・サーバーはネイティブ・ファイルのコピーをWebレイアウト・ディレクトリに配置します。ただし、かわりにネイティブ・ボールト・ファイルを指すHCSTファイルをWebレイアウト・ディレクトリに配置するように、コンテンツ・サーバーを構成することもできます。これは、変換しない大きなファイルがあり、Webレイアウト・ディレクトリに大きなファイルをコピーしたくない場合に有用です。
次の重要な注意事項に留意してください。
HCSTファイルの内容は、redirectionfile_template.htmファイルの内容によって制御されます。
ファイルの配信にはGET_FILE
サービスが使用されるため、PDFハイライトやバイト・サービングは利用できません。これは、テンプレートを上書きし、Webサーバーを再構成することにより解決できます。
単純なテンプレートを使用します。ブラウザの「戻る」ボタンが機能せず、レイアウトの相違が発生することがあります。これは、テンプレートを上書きし、Webサーバーを再構成することにより解決できます。
Webレイアウト・ディレクトリにHCSTファイルがあるため、ファイル数は減りません。ただし、ネイティブ・ボールト・ファイルが大きい場合は、ディスク領域を節約できます。
この設定は、変換用にリファイナリに送信されるファイルには影響しません。つまり、ファイルが変換用にリファイナリに送信される場合、別のコンテンツ・サーバー設定によって、Web表示可能ファイルとネイティブ・ファイルのコピーのいずれがWebレイアウト・ディレクトリに配置されるかが制御され、HCSTファイルは使用できません。詳細は、第23.4.4項を参照してください。
ネイティブ・ファイルのコピーではなくHCSTファイルをWebレイアウト・ディレクトリに配置するようにコンテンツ・サーバーを構成する手順は次のとおりです。
テキスト・エディタを使用して、IntradocDir
/config/
ディレクトリにある、コンテンツ・サーバーのconfig.cfg
ファイルを開きます。
IndexVaultFile
変数を追加し、値をtrue
に設定します。
IndexVaultFile=true
config.cfg
ファイルへの変更内容を保存します。
コンテンツ・サーバーを再起動します。
変換前および変換後ジョブをコンテンツ・サーバーでどのように処理するかなど、コンテンツ・サーバーとそのリファイナリ・プロバイダとの対話方法を構成できます。
重要: Inbound Refinery変換オプション・ページを使用するには、コンテンツ・サーバーにInboundRefinerySupportコンポーネントをインストールして有効にし、少なくとも1つのInbound Refineryプロバイダを有効にする必要があります。 |
コンテンツ・サーバーが変換前および変換後ジョブをどのように処理するかを構成する手順は次のとおりです。
管理者としてコンテンツ・サーバーにログインします。
「メイン」メニューで「管理」→「リファイナリ管理」→「変換オプション」を選択します。
リファイナリ変換オプション・ページで、次の情報を入力します。
次に転送を試みるまでに変換前ジョブを待機する秒数を入力します。デフォルトは10(秒)です。
単一のジョブの転送を開始してからアクションを実行するまでの転送許容時間を分単位で入力します。デフォルトは30(分)です。
ネイティブ・ファイル圧縮しきい値サイズを入力します(MB単位)。デフォルトのしきい値サイズは1024MB (1GB)です。ネイティブ・ファイルは、しきい値サイズを超えないかぎり、圧縮されてから、コンテンツ・サーバーによってリファイナリに転送されます。この設定を使用すると、非常に大きなファイル(たとえば、大規模なビデオ・ファイル)の圧縮に伴うオーバーヘッドを回避できます。転送前にネイティブ・ファイルを圧縮しないようにする場合は、ネイティブ・ファイル圧縮しきい値サイズを0に設定します。
ジョブ転送の有効期限が切れた場合に変換が失敗するようにするには、該当するチェック・ボックスを選択します。
コンテンツ・サーバーが失敗した変換をどのように処理するかを指定します。ファイルがリファイナリに送信され、変換が失敗した場合に、ネイティブ・ファイルのコピーを/weblayout
ディレクトリに配置するようにコンテンツ・サーバーを構成できます(「Refinery通過」)。通過を有効にするには、このチェック・ボックスを選択します。通過を無効にするには、チェック・ボックスの選択を解除します。
次の重要な注意事項に留意してください。
ファイルが変換用にリファイナリに送信される場合、ネイティブ・ファイルのコピーのかわりにHCSTファイルを使用することはできません。コンテンツ・サーバーがリファイナリに送信されないファイルをどのように処理するかを構成する方法の詳細は、第23.4.3項を参照してください。
この設定は、IntradocDir
\config\
ディレクトリにあるconfig.cgf
ファイル内のAllowPassthru
変数を使用して手動で上書きすることもできます。
最後に保存した設定に戻す場合は「リセット」をクリックし、変更を保存するには「更新」をクリックします。
コンテンツ・サーバーを再起動します。
環境によっては、特定のファイル拡張子が複数の方法で使用されている場合があります。よい例がZIPファイル拡張子です。たとえば、次のようなファイルをチェックインすることが考えられます。
TIFF Converterを含むリファイナリに、OCRを使用して単一のPDFファイルに変換させる、単一のZIPファイルに圧縮された複数のTIFFファイル。
変換用にリファイナリに送信しない、単一のZIPファイルに圧縮された複数のファイル・タイプ(ZIPファイルはそのネイティブ・フォーマットのまま通過させる必要があります)。
複数の方法でファイル拡張子を使用する場合は、ユーザーがファイルをコンテンツ・サーバーにチェックインするときにそのファイルをどのように変換するかを選択できるように、コンテンツ・サーバーを構成できます。これを、「チェックイン時にフォーマットの上書きを許可」と呼びます。このコンテンツ・サーバーの機能を有効にする手順は次のとおりです。
管理者としてログインします。
「メイン」メニューから「管理」→「管理サーバー」を選択します。
「管理サーバー」ページで、構成するコンテンツ・サーバー・インスタンスに対するボタンをクリックします。
「管理」ページで、ナビゲーション・メニューの「一般構成」をクリックします。
「チェックイン時にフォーマットの上書きを許可」チェック・ボックスを選択します。
「保存」をクリックします。
構成マネージャを使用して、ファイル拡張子を最も一般的に使用される変換にマップし、それをデフォルト変換にします。たとえば、ZIPファイル拡張子では、次のようなデフォルト変換を設定できます。
ZIPファイル拡張子をapplication/x-zip-compressedファイル・フォーマットにマップし、application/x-zip-compressedファイル・フォーマットをTIFFConversion変換にマップします。したがって、デフォルトでは、ZIPファイルには複数のTIFFファイルが含まれ、OCRを使用したPDFへの変換用にTIFF Converterを含むリファイナリに送信すべきであることが想定されます。
構成マネージャを使用して、ユーザーがチェックイン時に選択できるようにする代替ファイル・フォーマットおよび変換を設定します。前述のZIPファイル拡張子の例では、次のような代替変換を設定できます。
application/zip-passthruファイル・フォーマットをPassThru変換にマップします。これで、変換用にリファイナリに送信すべきではない様々なファイルを含むZIPファイルに対して、チェックイン時にこのオプションを選択できるようになります。ZIPファイルはそのネイティブ・フォーマットで渡されることになります。
コンテンツ・サーバーを再起動します。ユーザーはファイルのチェックイン時に、設定されているいずれかの変換を選択することにより、デフォルト変換を上書きできます。
複数の専用のリファイナリやカスタム変換を使用している場合に、このようにユーザーがチェックイン時に変換を上書きできるようにすることがあります。前述のZIPファイル拡張子の例を使用すると、TIFF Converterを持つ1つのリファイナリを、複数のTIFFファイルを含むZIPファイルをOCRを使用してPDFに変換するために使用し、2つ目のリファイナリを、Microsoft Officeファイルを含むZIPファイルをPDFに変換するために設定できます。
デフォルトでは、サムネイルは80x80ピクセルで表示されます。異なるサイズで表示する手順は次のとおりです。
IntradocDir
/config/
ディレクトリにあるconfig.cfg
ファイルをテキスト・エディタで開きます。
次の変数を必要に応じて変更し、サムネイルの高さと幅を変更します。
ThumbnailHeight=xxx
(xxx
はピクセル値)
ThumbnailWidth=xxx
(xxx
はピクセル値)
小さい方の設定に基づいて(設定が等しい場合は高さ設定を使用)、縦横比を維持するようにスケーリングが実行されます。
変更内容を保存します。
コンテンツ・サーバーを再起動します。
注意: これにより、すべてのサムネイルのサイズが更新されます。 |
ThumbnailHeight
およびThumbnailWidth
変数の詳細は、Oracle Fusion Middleware Oracle WebCenter Content構成リファレンスを参照してください。
この項では、変換ジョブのステータスを表示する方法を説明します。次の内容について説明します。
リファイナリの変換ステータスを表示するには、「メイン」メニューで「管理」→「リファイナリ管理」→「変換オプション」を選択します。IBRプロバイダのステータス・ページの「変換ジョブのステータス」タブをクリックすることもできます。
重要: このページを使用するには、InboundRefinerySupportコンポーネントをインストールして有効にし、少なくとも1つのInbound Refineryプロバイダを有効にする必要があります。 |
リファイナリの変換ステータス・ページに、次の情報が表示されます。
要素 | 説明 |
---|---|
リフレッシュ |
表示されたジョブのステータスを更新します。 |
ジョブ・キューのチェックの強制 |
コンテンツ・サーバーにジョブをリファイナリ・プロバイダに配信させます。これは、リファイナリが停止し、保留中のジョブが失敗した場合に特に有用です。この状況では、保留中のジョブは定期的に変換用にプロバイダに再送信されます。このボタンは、送信を強制的に行います。 |
変換ジョブID |
Inbound Refineryによって送信された各ジョブに割り当てられる一意の識別子。 |
コンテンツID |
変換用に送信されたコンテンツ・アイテムの一意のコンテンツ・サーバー識別子。 |
変換ジョブの状態 |
ジョブが変換処理内のどこにあるかを示します。 |
プロバイダに送信されたジョブ |
ジョブの送信先のプロバイダを示します。 |
最終アクション |
ジョブの状態の最後の変更日時をリストします。 |
アクション |
変換用に送信されたコンテンツ・アイテムに対するコンテンツ・サーバーのコンテンツ情報ページにリンクします。 |
IBRプロバイダのステータスを表示するには、「メイン」メニューで「管理」→「リファイナリ管理」→「IBRプロバイダのステータス」を選択します。リファイナリ変換ジョブのステータス・ページの「IBRプロバイダのステータス」タブをクリックすることもできます。
重要: このページを使用するには、コンテンツ・サーバーにInboundRefinerySupportコンポーネントをインストールして有効にし、少なくとも1つのInbound Refineryプロバイダを有効にする必要があります。 |
IBRプロバイダのステータス・ページに、次の情報が表示されます。
要素 | 説明 |
---|---|
ステータスの更新の強制 |
表示されたプロバイダのステータスを更新します。 |
プロバイダ |
各プロバイダの名前。 |
使用可能 |
プロバイダがコンテンツを変換用に承認しているかどうかを示します。 |
読取り専用 |
プロバイダが読取り専用であること、つまりジョブを変換用にこれ以上承認できないことを示します。コンテンツ・サーバーに変換を返すことしかできません。 |
キューに格納されたジョブ |
各プロバイダで変換を待機しているジョブの数を示します。 |
最終メッセージ |
プロバイダによって最後に配信されたステータス・メッセージを表示します。 |
接続状態 |
プロバイダがコンテンツ・サーバーに接続されているかどうかを示します。 |
最終アクティビティの日付 |
最後のプロバイダ・アクティビティの日時をリストします。 |
アクション |
特定のプロバイダに関する情報を示すプロバイダ情報ページを表示します。 |
リファイナリの変換設定を構成する前に、次の作業を実行する必要があります。
リファイナリを起動します。
リファイナリが1つ以上のコンテンツ・サーバーに対するプロバイダとして設定されていることを確認します。詳細は、23.3.1項を参照してください。
各コンテンツ・サーバー上にInboundRefinerySupportコンポーネントがインストールされ、有効化されていることを確認します。
各コンテンツ・サーバーが変換用にリファイナリにファイルを送信するように構成されていることを確認します。詳細は、23.4項を参照してください。
リファイナリ変換設定は、リファイナリがどの変換を承認し、各変換をどのように処理するかを制御します。Inbound RefineryにはOutside In Image Exportが含まれ、これは次の目的で使用できます。
ファイルのサムネイルを作成する。サムネイルは、コンテンツの小さなプレビュー・イメージです。詳細は、23.6.4項を参照してください。
ファイルを複数ページのTIFFファイルに変換することにより、ユーザーがTIFFビューア・プラグインを使用する標準のWebブラウザでファイルを表示できるようにする。詳細は、23.6.3項を参照してください。
また、Inbound Refineryではいくつかの変換オプションを使用できます。変換オプションを有効にすると、その変換設定がリファイナリに追加されます。
このセクションのトピックは次のとおりです:
リファイナリでの処理時に、コンテンツには、ファイルのサイズとタイムアウトの設定ページの設定に基づいて、一定の処理時間が割り当てられます。タイムアウト値(分単位)は、次のように計算されます。
タイムアウト値[分単位] = ([バイト単位のファイル・サイズ] x タイムアウト・ファクタ) / 60,000
まずInbound Refineryは、使用するファイルを特定するために、前のステップでファイルが生成されたかどうかを確認します。該当する場合、そのファイルがタイムアウトの計算に使用されます。生成されていない場合は、ネイティブ・ファイルを使用します。前のステップで複数のファイルが出力された場合は(たとえばExcelからPostScriptへの変換)、ファイル・サイズの合計を使用します。処理対象のコンテンツ・アイテムは、「最低 (Minimum)」列以上、「最高 (Maximum)」列未満の分数に割り当てられます。計算されたタイムアウト値が最低値を下回ると、最低値が適用されます。計算されたタイムアウト値が最高値を超えると、最高値が適用されます。
次の各例は、タイムアウトの計算方法を示しています。
例1
この場合、Inbound Refineryは最高値の10分間のみ待機します。
例2
この場合、Inbound Refineryは最高値の30分間ではなく、計算された6.83分間のみ待機します。
例3
リファイナリが承認し、キューに入れる変換の最大数を設定する手順は次のとおりです。
リファイナリにログインします。
「変換設定」→「変換リスト」を選択します。
変換リスト・ページで、リファイナリでキューに入れることのできる変換ジョブの合計数を設定します。デフォルトは0 (無制限)です。
コンテンツ・サーバーによるピックアップを待機可能な変換の最大数を入力します。この数を超えると、Inbound Refineryはそのコンテンツ・サーバーからの変換ジョブを承認しなくなります。デフォルトは1000です。
変換が最大数に達しているとき、リファイナリをビジー状態とみなす秒数を入力します。デフォルトは120 (秒)です。リファイナリの変換ジョブが最大数に達した場合、コンテンツ・サーバーはこの時間待機してから、リファイナリとの通信を再度試行します。
リファイナリが同時に処理する変換の最大数を入力します。デフォルトは5です。
リファイナリが承認するように設定する各変換に対するチェック・ボックスを選択します。
デフォルトでは、すべての変換が選択され、承認されます。
すべての変換を選択するには、列ヘッダーの「承認」チェック・ボックスを選択します。
すべての変換の選択を解除するには、列ヘッダーの「承認」チェック・ボックスの選択を解除します。
重要: このバージョンのInbound Refineryでは、一太郎およびLegacyCustomの変換はサポートされていません。 |
変換タイプごとに(すべてのリファイナリ・キューにわたる)ジョブの最大数を設定します。デフォルトは0 (無制限)です。
「更新」をクリックして変更を保存します。
リファイナリに対するエージェントである各コンテンツ・サーバーを再起動して、コンテンツ・サーバーのキューに対する変更を即時に有効にします。そうしない場合、リファイナリの承認済の変換に対する変更は、次回にコンテンツ・サーバーがリファイナリをポーリングするときまでコンテンツ・サーバーに認識されません。
Inbound Refineryには、ファイルをプライマリWeb表示可能レンディションとして複数ページのTIFFファイルに変換するために使用される、Outside In Image Exportが含まれています。これにより、ユーザーはTIFFビューア・プラグインを備えた標準的なWebブラウザでファイルを表示できます。
PDF Exportなどのその他の変換オプションを使用すると、プライマリWeb表示可能レンディションとしてその他のタイプのレンディションを作成できます。Web表示可能レンディションを生成できる変換オプションが有効になっていると、追加のオプションが指定可能になります。
複数ページのTIFFファイルをリファイナリが生成するプライマリWeb表示可能レンディションとして設定する手順は次のとおりです。
リファイナリにログインします。
「変換設定」→「プライマリWebレンディション」を選択します。
プライマリWeb表示可能レンディションとしてファイルを複数ページのTIFFファイルに変換するには、プライマリWeb表示可能レンディション・ページで「Outside Inを使用して複数ページのTIFFに変換」を選択します。
「更新」をクリックして変更を適用します。
サムネイルは、コンテンツの小さなプレビュー・イメージとして検索結果のページで使用され、通常は、それらが表すWeb表示可能ファイルにリンクしています。サムネイルによって、実際にファイル自体を開くことなく確認できる、視覚的なサンプルがコンシューマに示されます。これにより、より大きい元のファイルのダウンロードを行う前に、ファイルを確認できます。
Inbound RefineryにはOutside In Image Exportが含まれ、これを使用してファイルのサムネイルを作成できます。次の重要な注意事項に留意してください。
サムネイル作成用にリファイナリにファイルを送信するには、各コンテンツ・サーバーでファイル・フォーマットおよび変換を構成する必要があります。詳細は、23.4項を参照してください。リファイナリが変換を承認するように構成されている必要があります。詳細は、23.6.2項を参照してください。
Outside In Image Exportサムネイル・エンジンは、Type 3フォントを含むPDFファイルのサムネイルを正常に作成することはできません。チェックインされたPDFファイルにType 3フォントが含まれると、Outside In Image Exportサムネイル・エンジンは空白ページのサムネイルを作成します。
サムネイル・ファイルは、JPEG、GIFまたはPNGファイルとして、コンテンツ・サーバーの/weblayout
ディレクトリに格納され、そのファイル名には文字@tが含まれます。たとえば、Report2001@t~2.jpgファイルはReport2001~2.pdf(Report2001.xxxというファイルのリビジョン2)に属するサムネイルです。
暗号化またはパスワード保護されているファイルに対してサムネイルを作成することはできません。
EMLファイルに対するサムネイルを作成できます。Internet Explorerを使用していて、Outlook Express用の累積的な修正プログラム(2003年4月)をインストールしている場合、サムネイルをクリックしてEMLファイルを表示しようとするとエラーが発生します。これは、プライマリWeb表示可能ファイルがEMLファイルである場合(リファイナリによってプライマリWeb表示可能ファイルとして複数ページのTIFFまたはEMLファイルのPDFバージョンが作成されておらず、ネイティブEMLファイルがプライマリWeb表示可能ファイルとしてWebレイアウト・ディレクトリにコピーされている場合)にのみ当てはまります。
EMLファイルのサムネイルは、Outlook ExpressでそのEMLファイルを開いたときのルック・アンド・フィールと正確に一致しません。これは、サムネイルはプレーン・テキスト・レンディションに基づいて作成されるのに対し、Outlook Expressではファイルは独自の形式で開かれるためです。
コンテンツ・サーバーに表示されるサムネイル・サイズの変更方法の詳細は、第23.4.5.1項を参照してください。
Inbound Refineryでサムネイルをオフにしても、作成済のサムネイルは検索結果ページに表示され続けます。これを防ぐには、IntradocDir
\config\
ディレクトリにあるconfig.cfgファイル内のAllowableAdditionalRenditions
エントリからTHUMBNAIL
を削除します。
サムネイルは、Inbound Refineryでデフォルトで使用可能な唯一の追加のレンディションです。その他の変換オプションやカスタム変換を使用すると、追加のレンディションを作成できます。
サムネイルを有効にし、サムネイルの設定を構成する手順は次のとおりです。
リファイナリにログインします。
「変換設定」→「追加レンディション」を選択します。
追加レンディション・ページで、「Outside Inを使用するサムネイル・イメージの作成」を選択します。
「更新」をクリックして変更を保存します。
「オプション」をクリックします。
サムネイル・オプション・ページで、必要なサムネイル・オプションを選択します。終了後、「更新」をクリックします。
注意: Solarisを実行するSPARCシステム、またはLinuxを実行するいずれかのシステム上でのInbound Refineryの使用時には、Outside In Image Exportはフォントおよびグラフィックのレンダリングにデフォルトでその内部グラフィック・コードを使用します。かわりに、オペレーティング・システムのネイティブ・グラフィック・サブシステムを使用することも選択できます。詳細は、23.6.5項を参照してください。 |
次のリストに、使用可能なオプションを示します。
要素 | 説明 |
---|---|
「ネイティブ・ボールト・ファイルからサムネイル・イメージを作成」チェック・ボックス |
サムネイル・イメージをネイティブ・ファイルから作成するか、Web表示可能プライマリ・ファイルから作成するかを指定します。 |
「サムネイル・イメージ作成に使用するネイティブ・ボールト・ファイルのページ番号」フィールド |
サムネイル・イメージの作成に使用するネイティブ・ファイルのページを指定します。デフォルト設定は1です。ネイティブ・ファイルの最初のページが、サムネイル・イメージの作成に使用されます。 |
「クイック・サイジングを使用」ラジオ・ボタン |
最も高速のカラー・グラフィック変換を指定しますが、変換されたグラフィックの品質は若干低下します。 |
「スムーズ・サイジングを使用」ラジオ・ボタン |
元のグラフィックのより正確な表現を指定しますが、複雑な処理が必要になるため、変換速度が若干低下します。これがデフォルトの設定です。 |
「グレイスケール・グラフィック用のスムーズ・サイジング」ラジオ・ボタン |
グレイスケール・グラフィックにスムーズ・サイジング・オプションを使用し、すべてのカラー・グラフィックにクイック・サイジング・オプションを使用します。 |
「jpgのサムネイルの生成」ラジオ・ボタン |
すべてのサムネイルがJPGファイルとして作成されるように指定します。これは、サムネイルのファイル・タイプのデフォルト設定です。 |
「gifのサムネイルの生成」ラジオ・ボタン |
すべてのサムネイルがGIFファイルとして作成されるように指定します。 |
「pngのサムネイルの生成」ラジオ・ボタン |
すべてのサムネイルがPNGファイルとして作成されるように指定します。 |
「更新」ボタン |
設定に加えた変更内容を保存します。 |
「リセット」ボタン |
前回保存した設定に戻します。 |
LinuxまたはSolaris SPARCでInbound Refineryを実行している場合に複数ページのTIFFファイルまたはサムネイルを作成するとき、Outside Inはフォントおよびグラフィックのレンダリングにデフォルトでその内部グラフィック・コードを使用します。したがって、実行中のX Window Systemディスプレイ・サーバー(Xサーバー)へのアクセスおよびMotif(Solaris)またはLessTif(Linux)は必要ありません。システムで実行する必要があるのは、使用可能なフォントを検出することだけです。フォントはOutside Inには付属していません。使用可能なフォントへのパスの設定方法の詳細は、第23.6.6項を参照してください。
Image Exportがフォントとグラフィックのレンダリングに、その内部グラフィック・コードではなくオペレーティング・システムのネイティブのグラフィック・サブシステムを使用するようにInbound Refineryを構成する手順は次のとおりです。
Inbound RefineryコンピュータにInbound Refineryユーザーとしてログインします。
Inbound Refineryコンピュータが実行中のX Window Systemディスプレイ・サーバー(Xサーバー)にアクセスでき、Motif(Solaris)またはLessTif(Linux)が存在する必要があります。
Inbound Refineryの起動スクリプト(.profile、.login、.bashrcなど)内のDISPLAY
変数が実行中のXサーバーを指していることを確認します。次に例を示します。
DISPLAY=:0.0 export DISPLAY
新しい.profileをソースします。たとえば/usr/bin/sh
を使用して次のコマンドを実行します。
..profile
次のコマンドを実行して、実行中のXサーバーを使用するパーミッションをOutside In Image Exportに付与します。
xhost +localhost
Inbound Refineryユーザーはログインした状態のまま、コンソールをロックします。
リファイナリにログインします。
「変換設定」→「サードパーティ・アプリケーションの設定」を選択します。
サードパーティ・アプリケーションの設定ページで、「標準のOutsideInフィルタ・オプション」セクションの「オプション」をクリックします。
「ネイティブ・オペレーティング・システムのネイティブ・グラフィック・サブシステムを使用」を選択します。
「更新」をクリックします。
Inbound Refineryが正常に機能するには、フォント・イメージを生成するために使用されるフォントへのパスを指定する必要があります。デフォルトでは、フォント・パスはInbound Refineryで使用されるJVM内のフォント・ディレクトリ(java.home
/lib/fonts
)に設定されます。ただし、デフォルト・ディレクトリに含まれるフォントは限定されているため、レンディションが低下する可能性があります。また、非標準のJVMを使用した場合、デフォルトで指定されているJVMのフォント・パスと異なることがあります。この場合、エラー・メッセージがInbound Refineryとコンテンツ・サーバーの両方から表示されます。これが発生した場合は、変換を正しくレンダリングするために必要なフォントを含むディレクトリにフォント・パスが設定されていることを確認してください。
使用可能なフォントを検出するようにInbound Refineryを構成する手順は次のとおりです。
Inbound RefineryコンピュータにInbound Refineryユーザーとしてログインします。
「変換設定」の下の「サードパーティ・アプリケーションの設定」をクリックします。
サードパーティ・アプリケーションの設定ページで、「標準のOutsideInフィルタ・オプション」セクションの「オプション」をクリックします。
テキスト・フィールドに、Outside Inで使用するフォント・ディレクトリへのパスを入力します。たとえばLinuxでは、次のように指定します。
/usr/lib/X11/fonts/TTF
Windowsでは次のように指定します。
C:\WINDOWS\Fonts
フォントがコールされた場合に見つからないと、Outside Inはエラーを表示して終了します。TrueTypeフォント(*.ttfまたは*.ttcファイル)のみがサポートされています。
「更新」をクリックします。
グラフィック変換に対するタイムアウト設定を構成する手順は次のとおりです。
リファイナリにログインします。
「変換設定」→「タイムアウトの設定」を選択します。
タイムアウトの設定ページで、「グラフィック」変換に対する「最低(Minimum)」(分単位)、「最高(Maximum)」(分単位)および「ファクタ」を入力します。詳細は、23.6.1項を参照してください。
「更新」をクリックして変更を適用します。