この章では、以下のトピックについて説明します。
基本的な変換機能のためには、最低でも次のコンポーネントをインストールして有効化する必要があります。
コンポーネント名 | コンポーネントの説明 | 有効にするサーバー |
---|---|---|
InboundRefinery |
Inbound Refineryを有効にします |
Inbound Refineryサーバー |
InboundRefinerySupport |
コンテンツ・サーバーとInbound Refineryの併用を有効にします。 |
コンテンツ・サーバー |
Oracle WebCenter Content: Inbound Refineryは、コンテンツ・サーバーによって管理されているコンテンツを調整するために使用できます。Inbound Refineryアプリケーションは、コンテンツ・サーバーと同じコンピュータまたは1台以上の別のコンピュータにインストールできます。インストール後に、同じまたは別のコンピュータ上のコンテンツ・サーバーに、プロバイダとしてリファイナリを追加する必要があります。詳細は、「リファイナリ・プロバイダの構成」を参照してください。
注意:
Inbound Refineryでは、クラスタ環境での実行はサポートされていません。Inbound Refineryはコンテンツ・サーバー・クラスタに対する変換作業は実行できますが、それ自体をクラスタ環境で実行することはできません。Inbound Refineryは正しく機能するように、/queue/conversion
ディレクトリに対して長期ロックを作成し、維持します。Inbound Refineryが誤ってクラスタの一部として構成され、2つ目のInbound Refineryが起動して同じディレクトリのロックを試みると、2つ目の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サイトへのアクセス速度を低下させることがあり、その逆もまた同様のためです。ファイル・タイプとサイズに応じて、各変換には数秒から数分かかります。
この構成では、通常、リファイナリはいずれかのコンテンツ・サーバーにプロバイダとして設定されます。デプロイメント後に、このリファイナリを他のコンテンツ・サーバーに対してプロバイダとして追加する必要があります。詳細は、「リファイナリ・プロバイダの構成」を参照してください。
このシナリオは、別々のコンピュータ上にインストールされた複数のコンテンツ・サーバーと1つのリファイナリから構成されます。
利点:
購入する必要がある、リファイナリ変換に必要なサード・パーティ・アプリケーションは1つだけです。
リファイナリがコンテンツ・サーバーと同じコンピュータ上にデプロイされている場合よりも、処理が高速です。
リファイナリの処理はコンテンツ・サーバーの検索およびWebサイトへのアクセスに影響しません。その逆もまた同様です。
注意事項:
1つのコンテンツ・サーバーに付き1つのリファイナリが存在するシナリオほど処理能力は高くありません。
この構成では、通常、リファイナリは各コンテンツ・サーバーにプロバイダとして追加される必要があります。詳細は、「リファイナリ・プロバイダの構成」を参照してください。
このシナリオは、別々のコンピュータ上にインストールされた1つのコンテンツ・サーバーに付き1つのリファイナリから構成されます。
利点:
大量のコンテンツおよび大きなファイル・サイズに対して高速処理を行えます。
リファイナリの処理はコンテンツ・サーバーの検索およびWebサイトへのアクセスに影響しません。その逆もまた同様です。
注意事項:
各リファイナリ・コンピュータに、変換に必要なすべてのサード・パーティ・アプリケーションのコピーが必要です。
各リファイナリを、各コンテンツ・サーバーに対してプロバイダとして追加する必要があります。詳細は、「リファイナリ・プロバイダの構成」を参照してください。
このシナリオは、別々のコンピュータ上にインストールされた1つのコンテンツ・サーバーに付き複数のリファイナリから構成されます。
利点:
大量のコンテンツおよび大きなファイル・サイズに対して最高速で処理を行えます。
リファイナリの処理はコンテンツ・サーバーの検索およびWebサイトへのアクセスに影響しません。その逆もまた同様です。
注意事項:
各リファイナリ・コンピュータに、変換に必要なすべてのサード・パーティ・アプリケーションのコピーが必要です。
この構成では、通常、各リファイナリは各コンテンツ・サーバー・インスタンスにプロバイダとして追加される必要があります。詳細は、「リファイナリ・プロバイダの構成」を参照してください。
この項では、次の項目について説明します。
コンテンツ・サーバーは、プロバイダを通してリファイナリと通信します。1つのリファイナリは、1つまたは複数のコンテンツ・サーバー・インスタンスに対してプロバイダとして機能できます。一般的な構成の詳細は、「コンテンツ・サーバーとリファイナリの構成シナリオ」を参照してください。
リファイナリは、同じコンピュータ上のコンテンツ・サーバー・インスタンスにプロバイダとして追加するか、デプロイメント後に別のコンピュータ上のコンテンツ・サーバー・インスタンスに追加できます。
この項では、次の項目について説明します。
リファイナリをプロバイダとしてコンテンツ・サーバー・インスタンスに追加する手順は次のとおりです。
既存のリファイナリ・プロバイダの情報を編集するには、「プロバイダ」ページにアクセスし、編集するプロバイダの「アクション」列の「情報」をクリックします。送信ソケット・プロバイダの追加/「送信ソケット・プロバイダの編集」ページで、必要な変更を加えます。実行時に、コンテンツ・サーバー・インスタンスを再起動します。
既存のリファイナリ・プロバイダを有効または無効にする手順は次のとおりです。
リファイナリへのアクセスを制限するためにIPセキュリティ・フィルタを使用します。指定された条件に一致するIPまたはIPv6アドレスのホストのみにアクセスが許可されます。デフォルトでは、IPセキュリティ・フィルタは127.0.0.1|0:0:0:0:0:0:0:1です。これは、Inbound Refineryはlocalhostからの通信のみをリスニングすることを意味します。コンテンツ・サーバーがそのすべてのリファイナリと通信できるようにするには、リファイナリのIPセキュリティ・フィルタに、各コンテンツ・サーバー・コンピュータのIPまたはIPv6アドレスを追加する必要があります。これは、リファイナリがコンテンツ・サーバー・インスタンスと同じコンピュータ上で実行されている場合も同様です。リファイナリのIPセキュリティ・フィルタを編集する手順は次のとおりです。
コンテンツ・サーバーおよびInbound Refineryでは、Outside In Technologyを使用します。Ouside In Technologyは、すべてのLinuxプラットフォームに加えて、SolarisプラットフォームとHPUX ia64の両方で、GCCライブラリ(libgcc_sとlibstdc++)に動的にリンクされます。コンテンツ・サーバーはこれらのライブラリにアクセスできる必要がありますが、SolarisとHPUXではこれらのライブラリはデフォルトでは利用できません。コンテンツ・サーバーまたはInbound RefineryをSolarisまたはHPUXのいずれかで実行している場合は、GCCライブラリを入手してインストールし、それらを検出するようにコンテンツ・サーバーを構成する必要があります。ライブラリ・パスの構成については、『Oracle Fusion Middleware Oracle WebCenter Contentのインストールと構成 11g リリース1 (11.1.1.9)』のUNIXプラットフォーム上の環境変数へのライブラリ・パスの設定に関する項を参照してください。
コンテンツ・サーバーでは、ファイル拡張子、ファイル形式および変換を使用して、コンテンツ・アイテムがInbound Refineryおよびその変換アドオンによってどのように処理されるべきかを定義します。また、アプリケーション開発者はカスタム変換を作成することもできます。
この項では、次の項目について説明します。
通常、ファイル形式はそのMultipurpose Internet Mail Extension (MIME)タイプにより識別され、各ファイル形式は特定の変換にリンクされます。各ファイル拡張子は、特定のファイル形式にマップされます。したがって、チェックインされたファイルの拡張子に基づいて、コンテンツ・サーバーは、ファイルがリファイナリによって処理されるかどうか、およびどのように処理されるかを制御できます。リファイナリの変換設定は、リファイナリが承認する変換を指定し、変換の出力を制御します。
次の例を考えてみます。doc
ファイル拡張子がファイル形式application/msword
にマップされており、これは変換Word
にリンクされています。これは、コンテンツ・サーバーが、コンテンツ・サーバーにチェックインされたすべてのMicrosoft Wordファイル(拡張子がdoc
のファイル)を、変換用にリファイナリに送信しようとすることを意味します。
別の例として、xls
ファイル拡張子がファイル形式application/vnd.ms-excel
にマップされており、これは変換PassThru
にリンクされているとします。この場合、Microsoft Excelファイルはリファイナリには送信されません。かわりに、ネイティブ・ファイルのコピーまたはネイティブ・ボールト・ファイルを指すHCSTファイルを/weblayout
ディレクトリに配置するように、コンテンツ・サーバーを構成できます。つまり、ユーザーがこのファイルを表示するには、ネイティブ・ファイルを開くことができるアプリケーションがユーザーのコンピュータにインストールされている必要があります。
図21-1 変換へのファイル形式のマッピング
ファイルがコンテンツ・サーバーにチェックインされ、そのファイル形式が変換にマップされていると、コンテンツ・サーバーは、その変換を承認して変換ジョブを実行できるリファイナリ・プロバイダがあるかどうかを確認します。これは次のことを意味します。
コンテンツ・サーバーに対してリファイナリ・プロバイダが設定されている必要があります。詳細は、「リファイナリ・プロバイダの構成」を参照してください。
1つ以上のリファイナリが変換を承認するように構成されている必要があります。詳細は、「承認される変換の設定」を参照してください。
変換では、実行すべき変換ステップや使用すべき変換エンジンも含め、特定のファイル形式をどのように処理すべきかを指定します。詳細は、「ファイル・タイプの管理」を参照してください。
コンテンツ・サーバーで使用可能な変換は、リファイナリで使用可能な変換と一致する必要があります。あるファイル形式がコンテンツ・サーバーで変換にマップされると、そのフォーマットのファイルは、チェックイン時に変換用に送信されます。その変換を承認するように、1つ以上のリファイナリが設定されている必要があります。詳細は、「承認される変換の設定」を参照してください。
次のデフォルト変換を使用できます。変換アドオンをインストールすると、追加の変換が使用可能になります。詳細は、特定の変換アドオンのドキュメントを参照してください。
変換 | 説明 |
---|---|
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 |
Ichitaroファイルを変換用に送信するために使用します。ファイルはリファイナリの変換設定に従って変換されます。 |
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を使用した変換用にファイルを送信するために使用します。 |
XSLT変換 |
XML Converterを使用したXSLT変換用にファイルを送信するために使用します。XSLT変換は、XMLデータを別のフォーマットに出力するために使用します。 |
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ファイルをweblayout
ディレクトリに配置するように、コンテンツ・サーバーを構成できます。これは、ユーザーがファイルを表示するには、ファイルの作成に使用されたアプリケーション、またはファイルを開くことができるアプリケーションが、各クライアント上にインストールされている必要があることを意味します。詳細は、「PassThruファイル用のコンテンツ・サーバーの構成」を参照してください。
ファイルがリファイナリに送信され、変換が失敗したことがリファイナリによってコンテンツ・サーバーに通知される場合、ネイティブ・ファイルのコピーをweblayout
ディレクトリに配置するようにコンテンツ・サーバーを構成できます。この場合、ユーザーがこのファイルを表示するには、ネイティブ・ファイルを開くことができるアプリケーションがユーザーのコンピュータにインストールされている必要があります。詳細は、「コンテンツ・サーバーのリファイナリ変換オプションの構成」を参照してください。
新しいファイル形式には、ファイル拡張子に対応するMIME (Multipurpose Internet Mail Extensions)タイプによって名前を付けることをお薦めします(たとえば、doc
ファイル拡張子にマップされるフォーマットはapplication/msword
にするなど)。
コンテンツ・アイテムがコンテンツ・サーバーにチェックインされると、そのコンテンツ・アイテムのフォーマットは、ネイティブ・ファイルのファイル拡張子にマップされているフォーマットに従って割り当てられます。ネイティブ・ファイルが変換されない場合、コンテンツ・サーバーでは、コンテンツ・アイテムをクライアントに配信する際にこのフォーマットを含めます。フォーマットにMIMEタイプを使用すると、クライアントでは、ファイルのデータのタイプや使用する必要があるヘルパー・アプリケーションなどの判断に役立ちます。
ネイティブ・ファイルが変換されると、Inbound RefineryはWeb表示可能ファイルに適切なフォーマットを割り当て(たとえば、リファイナリがPDFファイルを生成した場合、このファイルをapplication/pdf
と識別します)、コンテンツ・サーバーはクライアントへのWeb表示可能ファイルの配信時に(ネイティブ・ファイルに対して指定されているフォーマットではなく)このフォーマットを含めます。
Inbound Refineryには、インストール時に自動的に構成されるファイル形式の広範なリストが含まれます。コンテンツ・サーバー・プロバイダの構成マネージャ・アプレットでリストを確認してください。新しいフォーマットは、珍しいフォーマットまたは独自のフォーマットで作業する場合にのみ追加する必要があります。
ファイル形式に対する正しいMIMEタイプを判別するために有用なリソースがインターネットで提供されています。例:
ファイル・タイプとファイル形式の構成の詳細を管理するには、「ファイル形式ウィザード」ページまたは構成マネージャを使用します。ファイル・フォーマット・ウィザード・ページは、一般的なほとんどのファイル・タイプの変換を構成するために使用できますが、構成マネージャ・アプレットのすべての機能が複製されるわけではありません。
注意:
「ファイル形式ウィザード」ページを有効にするには、コンテンツ・サーバーにInboundRefinerySupportコンポーネントをインストールして有効にし、少なくとも1つのInbound Refineryプロバイダを有効にする必要があります。また、変換オプション・コンポーネントによって、ファイル・タイプが「ファイル形式ウィザード」ページに追加される場合があります。
「ファイル形式ウィザード」ページを使用する手順は次のとおりです。
管理者としてログインします。
メイン・メニューから、「管理」→「リファイナリ管理」→「ファイル形式ウィザード」を選択します。
「ファイル形式ウィザード」ページで、変換用にリファイナリに送信される各ファイル・タイプに対するチェック・ボックスを選択します。すべてのチェック・ボックスを選択または選択解除するには、見出し行でチェック・ボックスを選択または選択解除します。
最後に保存した設定に戻すには、「リセット」をクリックします。
「更新」をクリックします。
選択したファイル・タイプに対して、対応するデフォルトのファイル拡張子、ファイル形式および変換が、自動的にマップされます。
構成マネージャを使用する手順は次のとおりです。
ファイル形式を追加して変換にリンクする手順は次のとおりです。
ファイル形式を編集するには、ファイル形式を選択して「編集」をクリックします。新しいファイル形式の追加/「ファイル形式の編集」ページで、適切な変更を加えます。
ファイル拡張子を追加し、ファイル形式にマップする(およびそれによりファイル拡張子を変換に関連付ける)手順は次のとおりです。
ファイル拡張子を編集するには、「ファイル形式」ページでファイル拡張子を選択し、「編集」をクリックします。適切な変更を行います。
ファイル形式が変換PassThru
にリンクされていると、そのファイル形式にマップされているすべてのファイル拡張子は変換用に送信されません。デフォルトでは、コンテンツ・サーバーはネイティブ・ファイルのコピーをweblayout
ディレクトリに配置します。ただし、かわりにネイティブ・ボールト・ファイルを指すHCSTファイルをweblayout
ディレクトリに配置するように、コンテンツ・サーバーを構成することもできます。これは、変換しない大きなファイルがあり、weblayout
ディレクトリに大きなファイルをコピーしたくない場合に有用です。
次の重要な注意事項に留意してください。
HCSTファイルの内容は、redirectionfile_template.htm
ファイルの内容によって制御されます。
ファイルの配信にはGET_FILE
サービスが使用されるため、PDFハイライトやバイト・サービングは利用できません。これは、テンプレートをオーバーライドし、Webサーバーを再構成することにより解決できます。
単純なテンプレートを使用します。ブラウザの「戻る」ボタンが機能せず、レイアウトの相違が発生することがあります。これは、テンプレートをオーバーライドし、Webサーバーを再構成することにより解決できます。
weblayout
ディレクトリにHCSTファイルがあるため、ファイル数は減りません。ただし、ネイティブ・ボールト・ファイルが大きい場合は、ディスク領域を節約できます。
この設定は、変換用にリファイナリに送信されるファイルには影響しません。つまり、ファイルが変換用にリファイナリに送信される場合、別のコンテンツ・サーバー設定によって、Web表示可能ファイルとネイティブ・ファイルのコピーのいずれがweblayout
ディレクトリに配置されるかが制御され、HCSTファイルは使用できません。詳細は、「コンテンツ・サーバーのリファイナリ変換オプションの構成」を参照してください。
ネイティブ・ファイルのコピーではなくHCSTファイルをweblayout
ディレクトリに配置するようにコンテンツ・サーバーを構成する手順は次のとおりです。
テキスト・エディタを使用して、IntradocDir
/config/
ディレクトリにある、コンテンツ・サーバーのconfig.cfg
ファイルを開きます。
IndexVaultFile
変数を追加し、値をtrue
に設定します。
IndexVaultFile=true
config.cfg
ファイルへの変更内容を保存します。
Content Serverを再起動します。
変換前および変換後ジョブをコンテンツ・サーバーでどのように処理するかなど、コンテンツ・サーバーとそのリファイナリ・プロバイダとの対話方法を構成できます。
注意:
「Inbound Refinery変換オプション」ページを使用するには、コンテンツ・サーバーにInboundRefinerySupportコンポーネントをインストールして有効にし、少なくとも1つのInbound Refineryプロバイダを有効にする必要があります。
コンテンツ・サーバーが変換前および変換後ジョブをどのように処理するかを構成する手順は次のとおりです。
一般的な形式のイメージ・ファイルについて、ネイティブ・ユーザー・インタフェースでは、通常、ほとんどのWebブラウザで表示できるネイティブ・ドキュメントのプレビューが表示されます。対照的に、Oracle WebCenter Contentユーザー・インタフェースでは、通常、ドキュメントの表示ページでドキュメントのプレビューを表示する前に、Outside In Technologyを使用してネイティブ・ドキュメントがページ・イメージに変換されます。
複数レイヤーのイメージ・ファイル(動画の.gif
ファイルなど)では、Outside Inによって、複数レイヤー・ファイルの各レイヤーについて、それぞれ1つのイメージが作成されます。この結果、元のイメージの各レイヤーについて、別々のページが存在することになります。ほとんどのWebブラウザで動画の.gif
ファイルおよび複数レイヤーの他の形式を適切に表示できるため、コンテンツ・サーバーでOutside Inをバイパスして、アニメーションを適切に表示することもできます。
Outside Inをバイパスしてネイティブ・ファイルを表示するには、管理者は、コンテンツ・サーバーのintradoc.cfg
ファイルのSimplePreviewFormatList
変数に形式をリストします。これは、コンテンツ・サーバーにアクセスするブラウザでサポートされる形式(標準的なイメージ形式など)について行う必要があります。これによって、ブラウザでネイティブ・ファイルが表示され、複数レイヤーの動画ファイル形式が適切に解釈されます。
単純なプレビューを使用するために任意のイメージ形式を指定する手順は次のとおりです。
環境によっては、特定のファイル拡張子が複数の方法で使用されている場合があります。よい例がZIPファイル拡張子です。たとえば、次のようなファイルをチェックインすることが考えられます。
TIFF Converterを含むリファイナリに、OCRを使用して単一のPDFファイルに変換させる、単一のZIPファイルに圧縮された複数のTIFFファイル。
変換用にリファイナリに送信しない、単一のZIPファイルに圧縮された複数のファイル・タイプ(ZIPファイルはそのネイティブ・フォーマットのまま通過させる必要があります)。
複数の方法でファイル拡張子を使用する場合は、ユーザーがファイルをコンテンツ・サーバーにチェックインするときにそのファイルをどのように変換するかを選択できるように、コンテンツ・サーバーを構成できます。これを、「チェックイン時にフォーマットのオーバーライドを許可」と呼びます。このコンテンツ・サーバーの機能を有効にする手順は次のとおりです。
複数の専用のリファイナリおよびカスタム変換を使用している場合に、このようにユーザーがチェックイン時に変換を上書きできるようにすることがあります。前述のZIPファイル拡張子の例を使用すると、TIFF Converterを持つ1つのリファイナリを、複数のTIFFファイルを含むZIPファイルをOCRを使用してPDFに変換するために使用し、2つ目のリファイナリを、Microsoft Officeファイルを含むZIPファイルをPDFに変換するために設定できます。
コンテンツ・アイテムがチェックインされた後でリファイナリに送信される前に、Dynamic Converterはpre_submit_to_conversion
インクルード・リソースを実行します。このインクルード・リソースは作成するカスタム・コンポーネントのプレースホルダとして機能します。カスタム・コンポーネントは、リファイナリにより実行されるアクションを指定するコンテンツ・アイテムに対するdConversion
変数の値をオーバーライドします。
デフォルトの変換条件を変更するには、カスタム・コンポーネントを作成し、pre_submit_to_conversion
リソースを変更します。たとえば、MIMEタイプに基づき、またはカスタム・メタデータ・フィールドを含むメタデータ・フィールドの値に基づき、コンテンツ・アイテムのフルテキストの索引付けを選択的に含めるまたは除外することができます。
作成するカスタム・コンポーネントがデフォルト・インクルードの後にロードされ、そのコンテンツが指定したコンテンツに効果的に置き換えられます。カスタム・コンポーネントの作成の詳細は、『Oracle WebCenter Contentでの開発』を参照してください。
pre_submit_to_conversion
インクルードのデフォルトのスクリプトには、コメントとして囲まれたサンプル・コードが含まれています。サンプル・コードは実行されませんが、dConversion
変数の変更方法の例として提供されます。
[[% The pre_submit_to_conversion include can be used to reset a document conversion type based on specified metadata field values. Create a custom component to override the sample content in this include. The sample include below is enclosed as a comment and does not execute. %]] <@dynamichtml pre_submit_to_conversion@> [[% <$if strEquals(dDocTitle, "skip Conversion")$> <$dConversion="PassThru"$> <$elseif strEquals(dDocType, "Image")$> <$dConversion="MultipageTiff"$> <$endif$> %]] <@end@>
サンプル・コードで、コンテンツ・アイテムのタイトル(dDocTitle
メタデータ・フィールドの値)が"Skip Conversion"
の場合、コンテンツ・アイテムは変換されません(dConversion
に"PASSTHRU"
の値が指定されます)。また、デフォルトで、ドキュメント・タイプ(dDocType
メタデータ・フィールドの値)が"Image"
の場合、コンテンツ・アイテムは複数ページTIFFイメージ・ファイルに変換されます。
チェックインしたコンテンツ・アイテムの変換方法を決定するdConversion
変数の値。dConversion
変数の形式は次のとおりです。
dConversion="<conversion_type>"
シナリオ:
ユーザーがWordドキュメントにチェックインすると、Wordドキュメントとしてドキュメントを変換するか、またはドキュメントを変換せずにパススルーさせるかを選択できます。
解決策:
Wordドキュメントを変換するかどうかをユーザーが決定できるようにするには、2つの値(Yes
およびNo
、No
がデフォルト)を含むリストを使用して、カスタム・メタデータ・フィールド(xPerformConversion
など)を作成します。ユーザーが変換されるWordドキュメントにチェックインすると、チェックイン中に、xPerformConversion
フィールドの値はYes
に設定されます。
このソリューションを実装するには、次のコンテンツを含むカスタム・コンポーネントを作成します。
<@dynamichtml pre_submit_to_conversion@> <$if strEquals(xPerformConversion, "No")$> <$dConversion="PASSTHRU"$> <$elseif strEquals(xPerformConversion, "Yes")$> <$dConversion="Word"$> <$endif$> <@end@>
この項では、変換ジョブのステータスを表示する方法を説明します。次の内容について説明します。
リファイナリの変換ステータスを表示するには、メイン・メニューを使用して、「管理」→「リファイナリ管理」→「変換オプション」を選択します。「IBRプロバイダのステータス」ページの「変換ジョブのステータス」タブをクリックすることもできます。
注意:
このページを使用するには、InboundRefinerySupportコンポーネントをインストールして有効にし、少なくとも1つのInbound Refineryプロバイダを有効にする必要があります。
次の変換ステータス情報が使用できます。
要素 | 説明 |
---|---|
リフレッシュ |
表示されたジョブのステータスを更新します。 |
ジョブ・キューのチェックの強制 |
コンテンツ・サーバーにジョブをリファイナリ・プロバイダに配信させます。これは、リファイナリが停止し、保留中のジョブが失敗した場合に特に有用です。この状況では、保留中のジョブは定期的に変換用にプロバイダに再送信されます。このボタンは、送信を強制的に行います。 |
変換ジョブID |
Inbound Refineryによって送信された各ジョブに割り当てられる一意の識別子。 |
コンテンツID |
変換用に送信されたコンテンツ・アイテムの一意のコンテンツ・サーバー識別子。 |
変換ジョブの状態 |
ジョブが変換処理内のどこにあるかを示します。 |
プロバイダに送信されたジョブ |
ジョブの送信先のプロバイダを示します。 |
最終アクション |
ジョブの状態の最後の変更日時をリストします。 |
アクション |
変換用に送信されたコンテンツ・アイテムに対するコンテンツ・サーバーの「コンテンツ情報」ページにリンクします。 |
IBRプロバイダのステータスを表示するには、メイン・メニューを使用して、「管理」→「リファイナリ管理」→「IBRプロバイダのステータス」を選択します。リファイナリ変換ジョブのステータス・ページの「IBRプロバイダのステータス」タブをクリックすることもできます。
注意:
このページを使用するには、コンテンツ・サーバーにInboundRefinerySupportコンポーネントをインストールして有効にし、少なくとも1つのInbound Refineryプロバイダを有効にする必要があります。
次の変換情報が「IBRプロバイダのステータス」ページに表示されます。
要素 | 説明 |
---|---|
ステータスの更新の強制 |
表示されたプロバイダのステータスを更新します。 |
プロバイダ |
各プロバイダの名前。 |
使用可能 |
プロバイダがコンテンツを変換用に承認しているかどうかを示します。 |
読取り専用 |
プロバイダが読取り専用であること、つまりジョブを変換用にこれ以上承認できないことを示します。コンテンツ・サーバーに変換を返すことしかできません。 |
キューに格納されたジョブ |
各プロバイダで変換を待機しているジョブの数を示します。 |
最終メッセージ |
プロバイダによって最後に配信されたステータス・メッセージを表示します。 |
接続状態 |
プロバイダがコンテンツ・サーバーに接続されているかどうかを示します。 |
最終アクティビティの日付 |
最後のプロバイダ・アクティビティの日時をリストします。 |
アクション |
特定のプロバイダに関する情報を示す「プロバイダ情報」ページを表示します。 |
リファイナリの変換設定を構成する前に、次の作業を実行する必要があります。
リファイナリを起動します。
リファイナリが1つ以上のコンテンツ・サーバーに対するプロバイダとして設定されていることを確認します。詳細は、「リファイナリ・プロバイダの構成」を参照してください。
各コンテンツ・サーバー上にInboundRefinerySupportコンポーネントがインストールされ、有効化されていることを確認します。
各コンテンツ・サーバーが変換用にリファイナリにファイルを送信するように構成されていることを確認します。詳細は、「コンテンツ・サーバーでのリファイナリへのジョブ送信の構成」を参照してください。
リファイナリ変換設定は、リファイナリがどの変換を承認し、各変換をどのように処理するかを制御します。Inbound RefineryにはOutside In Image Exportが含まれ、これは次の目的で使用できます。
ファイルのサムネイルを作成します。サムネイルは、コンテンツの小さなプレビュー・イメージです。詳細は、「サムネイルの設定」を参照してください。
ファイルを複数ページのTIFFファイルに変換することにより、ユーザーがTIFFビューア・プラグインを使用する標準のWebブラウザでファイルを表示できるようになります。詳細は、参照してください。
また、Inbound Refineryではいくつかの変換オプションを使用できます。変換オプションを有効にすると、その変換設定がリファイナリに追加されます。
この項では、次の項目について説明します。
リファイナリでの処理時に、コンテンツには、ファイルのサイズと「タイムアウトの設定」ページの設定に基づいて、一定の処理時間が割り当てられます。タイムアウト値(分単位)は、次のように計算されます。
タイムアウト値[分単位] = ([バイト単位のファイル・サイズ] × タイムアウト・ファクタ) / 60,000
まずInbound Refineryは、使用するファイルを特定するために、前のステップでファイルが生成されたかどうかを確認します。該当する場合、そのファイルがタイムアウトの計算に使用されます。そうでない場合は、ネイティブ・ファイルを使用します。前のステップで複数のファイルが出力される場合は(たとえばExcelからPostScriptへの変換)、ファイル・サイズの合計を使用します。処理対象のコンテンツ・アイテムは、「最低 (Minimum)」列以上、「最高 (Maximum)」列未満の分数に割り当てられます。計算されたタイムアウト値が最低値を下回ると、最低値が適用されます。計算されたタイムアウト値が最高値を超えると、最高値が適用されます。
次の各例は、タイムアウトの計算方法を示しています。
例1
この場合、Inbound Refineryは最高値の10分間のみ待機します。
例2
この場合、Inbound Refineryは最高値の30分間ではなく、計算された6.83分間のみ待機します。
例3
Inbound Refineryには、ファイルをプライマリWeb表示可能レンディションとして複数ページのTIFFファイルに変換するために使用される、Outside In Image Exportが含まれています。これにより、ユーザーはTIFFビューア・プラグインを備えた標準的なWebブラウザでファイルを表示できます。
PDF Exportなどのその他の変換オプションを使用すると、プライマリWeb表示可能レンディションとしてその他のタイプのレンディションを作成できます。Web表示可能レンディションを生成できる変換オプションが有効になっていると、追加のオプションが指定可能になります。
複数ページのTIFFファイルをリファイナリが生成するプライマリWeb表示可能レンディションとして設定する手順は次のとおりです。
サムネイルは、コンテンツの小さなプレビュー・イメージとして検索結果のページで使用され、通常は、それらが表すWeb表示可能ファイルにリンクしています。サムネイルによって、実際にファイル自体を開くことなく確認できる、視覚的なサンプルがコンシューマに示されます。これにより、より大きい元のファイルのダウンロードを行う前に、ファイルを確認できます。
Inbound RefineryにはOutside In Image Exportが含まれ、これを使用してファイルのサムネイルを作成できます。次の重要な注意事項に留意してください。
サムネイル作成用にリファイナリにファイルを送信するには、各コンテンツ・サーバーでファイル形式および変換を構成する必要があります。詳細は、「コンテンツ・サーバーでのリファイナリへのジョブ送信の構成」を参照してください。リファイナリが変換を承認するように構成されている必要があります。詳細は、「承認される変換の設定」を参照してください。
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表示可能ファイルとしてweblayout
ディレクトリにコピーされている場合)にのみ当てはまります。
EMLファイルのサムネイルは、Outlook ExpressでそのEMLファイルを開いたときのルック・アンド・フィールと正確に一致しません。これは、サムネイルはプレーン・テキスト・レンディションに基づいて作成されるのに対し、Outlook Expressではファイルは独自の形式で開かれるためです。
コンテンツ・サーバーに表示されるサムネイル・サイズの変更方法の詳細は、「サムネイルのサイズの変更」を参照してください。
Inbound Refineryでサムネイルをオフにしても、作成済のサムネイルは検索結果ページに表示され続けることに注意してください。
サムネイルは、Inbound Refineryでデフォルトで使用可能な唯一の追加のレンディションです。その他の変換オプションやカスタム変換を使用すると、追加のレンディションを作成できます。
サムネイルを有効にし、サムネイルの設定を構成する手順は次のとおりです。
次の表に、使用可能なオプションを示します。
要素 | 説明 |
---|---|
「ネイティブ・ボールト・ファイルからサムネイル・イメージを作成」チェック・ボックス |
サムネイル・イメージをネイティブ・ファイルから作成するか、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には付属していません。使用可能なフォントへのパスの設定方法の詳細は、「フォント・パスの指定」を参照してください。
Image Exportがフォントとグラフィックのレンダリングに、その内部グラフィック・コードではなくオペレーティング・システムのネイティブのグラフィック・サブシステムを使用するようにInbound Refineryを構成する手順は次のとおりです。
Inbound Refineryが正常に機能するには、フォント・イメージを生成するために使用されるフォントへのパスを指定する必要があります。デフォルトでは、フォント・パスはInbound Refineryで使用されるJVM内のフォント・ディレクトリ(java.home
/lib/fonts
)に設定されます。ただし、デフォルト・ディレクトリに含まれるフォントは限定されているため、レンディションが低下する可能性があります。また、非標準のJVMを使用した場合、デフォルトで指定されているJVMのフォント・パスと異なることがあります。この場合、エラー・メッセージがInbound Refineryとコンテンツ・サーバーの両方から表示されます。このエラーが発生した場合は、変換を正しくレンダリングするために必要なフォントを含むディレクトリにフォント・パスが設定されていることを確認してください。
使用可能なフォントを検出するようにInbound Refineryを構成する手順は次のとおりです。
グラフィック変換に対するタイムアウト設定を構成する手順は次のとおりです。