この章では、Oracle Managed File Transfer専用のOracle WebLogic Server管理対象サーバーを管理する方法を説明します。
この章の内容は次のとおりです。
キーストアに関する情報は、「キーストアの管理」を参照してください。
ドメインに関する情報は、「ドメインの管理」を参照してください。
Oracle Managed File Transferの埋込みFTPおよびsFTPサーバーの管理の詳細は、「Oracle Managed File Transfer埋込みサーバーの管理」を参照してください。
「管理」ページの「サーバー・プロパティ」タブは、次のセクションで構成されています。
これらのプロパティに対する変更を保存するには、「保存」をクリックします。前回保存以降の変更をすべて取り消すには、「元に戻す」をクリックします。
「サーバー・プロパティ」タブには、次の構成可能フィールドが表示されます。
「ペイロード・ストレージ・ディレクトリ」のデフォルト値はWLS_Home/user_projects/domains/base_domain/mft/storage
です。クラスタ内で複数のOracle WebLogic Serverインスタンスが稼働している場合は、共有の場所に設定する必要があります。
WLS_Home/user_projects/domains/base_domain/mft/callouts
です。インライン・ペイロードのストア: 「インライン・ペイロードのストア」設定では、インライン・ペイロードを転送後にファイル・システムとデータベースのどちらに格納するかを指定します。いずれかのオプションを選択する必要があります。
参照ペイロードのストア: 「参照ペイロードのストア」チェック・ボックスでは、参照ペイロードをペイロード・ストレージ・ディレクトリに格納するかどうかを指定します。このチェック・ボックスを選択した場合は、「ペイロード・ストレージ・ディレクトリ」でファイル・システムの場所を指定します。チェック・ボックスを選択しなかった場合は、参照ペイロードは保持されません。
「ペイロード・ストレージ・ディレクトリ」を変更する手順は次のとおりです。
Oracle Managed File Transfer専用のOracle WebLogic Server管理対象サーバーを停止します。
「ペイロード・ストレージ・ディレクトリ」の設定を変更します。
ディレクトリとファイルをペイロード・ストレージ・ディレクトリの下に移動します。
管理対象サーバーを再起動します。
管理対象サーバーの停止と開始方法については、「ポートの再構成」を参照してください。
チェックサムの生成: 「チェックサムの生成」設定は、1つのファイル内のすべてのビットが正常に転送されたことの確認に役立ちます。このチェック・ボックスが選択されている場合は、ターゲットに配信する前にOracle Managed File Transferによって各ペイロードに対するチェックサムが生成されて、データベースに格納されます。このチェックサムを比較すると、ファイルが転送中に破損していないことを確認できます。
注意:
チェックサムは、後の段階でペイロードを検証するのに必要です。これはオプションのフィールドで、チェックサムの生成にMFTが必要ない場合は、このフィールドを選択しないでください。これにより追加のチェックサムの計算が回避されるため、パフォーマンスが向上します。各プロセッサの設定では、ファイル配信の各段階専用の処理スレッド数を指定します。3つの設定のデフォルト値はいずれも2です。
ソース・プロセッサ: ソース・レベルで必要なメッセージ・プロセッサの数を決定します。これは転送識別とソース・レベルの処理関数実行を扱います。
インスタンス・プロセッサ: 転送レベルで必要なメッセージ・プロセッサの数を決定します。これはターゲット・レベルの前処理関数実行を扱います。
ターゲット・プロセッサ: ターゲット・レベルで必要なメッセージ・プロセッサの数を決定します。これは配信およびターゲット・レベルの後処理関数実行を扱います。
ターゲット・メッセージ処理または配信のようなロードの多くがこのレイヤーで発生するので、ほとんどの場合、この数はより大きくする必要があります。そのため通常これは他の2つのタイプのプロセッサよりも大きくすることができます。
転送の構成、定義済の処理関数および予期されるペイロード・パターンに基づいて、各プロセッサ設定に割り当てるスレッド数の増減が必要になる可能性があります。たとえば、ターゲット前処理に要する時間が配信に比べて短い場合は、最適なパフォーマンスとなるように「インスタンス・プロセッサ」の数を減らして「ターゲット・プロセッサ」の数を増やします。
Oracle Managed File Transferでは、スレッド同時実行性の問題を防止するために内部JCAアダプタの衝突検出機能が使用されます。
これらの設定は、高可用性のためのJCAアダプタのプロパティです。
コントロール・ディレクトリはMFTファイル/FTPアダプタがHAユース・ケースを処理するのに必要なディレクトリ・パスです。MFTがHA環境で実行している場合、このフィールドは必須です。クラスタ内で複数のOracle WebLogic Serverインスタンスが稼働している場合は、共有の場所に設定する必要があります。たとえば、$DOMAIN_HOME/mft/control_di
とします。
「インバウンド・データソース」は、高可用性に対応するスキーマが事前作成される場所である、MFTのインバウンドのデータ・ソースです。コントロール・ディレクトリが指定されない場合、このフィールドは必須です。デフォルト値(Oracle Managed File Transferの外部で決定されます)はjdbc/MFTDataSource
です。
「アウトバウンド・データソース」は、高可用性に対応するスキーマが事前作成される場所である、MFTのアウトバウンドのデータ・ソースです。コントロール・ディレクトリが指定されない場合、このフィールドは必須です。デフォルト値(Oracle Managed File Transferの外部で決定されます)はjdbc/MFTDataSource
です。
詳細は、テクノロジ・アダプタの理解の高可用性のためのOracleファイルおよびFTPアダプタの構成に関する項を参照してください。
拡張配信の設定が必要になるのは、Oracle WebLogic Serverインスタンスがロード・バランサとともに実行されるときです。これらの設定では、ロード・バランサで使用される「内部アドレス」と「外部アドレス」(IPアドレス)および「FTP」、「FTPs」および「sFTP」のポートを設定します。この設定を使用するのは、Oracle Managed File TransferからペイロードがFTPまたはsFTP参照として送信されるときです。値が設定されている場合は、その値を使用してFTP参照(FTP/sFTPホスト・アドレスとポート)が構築されます。
内部アドレス: 配信の参照ケースに必要な内部プロキシ・アドレスおよびポート。
外部アドレス: 配信の参照ケースに必要な外部プロキシ・アドレスおよびポート。
Oracle MFTが内部および外部プロキシの背後で実行している場合、内部および外部IPアドレスは必須です。
詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタでのロード・バランシングに関する項を参照してください。
Oracle Managed File Transfer構成(つまりリポジトリ)のバックアップには、「管理」ページのすべての設定と、デザイナのすべてのアーティファクト(パスワード設定を除く)が含まれています。構成はZIPファイルに保存され、このファイルから後で復元できるようになっています。
このプロセスの手順は次のとおりです。
「管理」ページの「インポート/エクスポート」タブを開きます。
「エクスポート」をクリックします。
ファイルexport.zip
に対してどのような処理を実行するかを尋ねる、オペレーティング・システムのダイアログ・ボックスが開きます。
「ファイルを保存」を選択して、「OK」をクリックします。
オペレーティング・システムのファイル保存ダイアログ・ボックスが開きます。
ファイルを保存するディレクトリを選択します。
ファイル名を編集します。これはオプションです。
「保存」をクリックします。
Oracle Managed File Transfer構成をバックアップから復元できます。これを行うと、既存の構成が上書きされます(パスワード設定を除く)。
転送アーティファクトを1つだけインポートまたはエクスポートするには、「転送のインポートとエクスポート」を参照してください。
WLSTのexportMftMetadata
コマンドとimportMFTMetadata
コマンドを使用してOracle Managed File Transfer構成のバックアップと復元を行うことができます。詳細は、SOA Suite用WLSTコマンド・リファレンスを参照してください。
キーストアはOracle Managed File Transfer構成の一部ではありません。詳細は、「キーストアの管理」を参照してください。
大きなファイルの転送に時間がかかる場合や、メモリー不足例外が発生する場合は、メモリー(-Xms
)またはヒープ・サイズを(-Xmx
)を1GBまたは2GBまで増やします。たとえば、次のコマンドを実行するとメモリーが1GBに増え、ヒープ・サイズが2GBに増えます。
setenv USER_MEM_ARGS "-Xms1024m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=768m"
Oracle Managed File Transfer専用のOracle WebLogic Server管理対象サーバーの起動、再起動または停止を、Oracle Managed File Transferコンソールから行うことができます。
埋込みサーバーは、Oracle WebLogic Server管理対象サーバーとは別のものです。MFTの埋込みFTPサーバーおよびsFTPサーバーは、Oracle Managed File Transfer専用のOracle WebLogic Server管理対象サーバー上で実行されるサービスです。MFTコンソールの埋込みサーバー・ポート管理のページに、この管理対象サーバーが一覧表示され、停止や起動ができます。
このプロセスの手順は次のとおりです。
「管理」ページの左ペインで、「埋込みサーバー」の左にある矢印をクリックします。
「ポート」と「ユーザー・アクセス」という項目が表示されます。
「ポート」をクリックします。
「埋込みサーバーのポート」タブが開きます。
「サーバー・インスタンス」の表で、起動、再起動または停止するサーバー・インスタンスのチェック・ボックスを選択します。操作をすべてのサーバーに対して実行するには、「すべて選択」チェック・ボックスを選択します。
「サーバー・ステータス」に注目します。サーバーを停止または再起動できるのは、RUNNINGの場合です。サーバーを起動できるのは、STOPPEDの場合です。
「起動」、「停止」または「再起動」をクリックします。
「リフレッシュ」アイコンをクリックして表を更新し、新しい「サーバー・ステータス」を確認します。
「ポート」タブの主な目的は、埋込みサーバーのポートを更新することです。詳細は、「ポートの再構成」を参照してください。
埋込みFTPおよびsFTPサーバーのみを起動および停止するには、「埋込みサーバーの起動と停止」を参照してください。
Oracle WebLogic Serverの起動、停止および障害回復を管理する方法の詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』を参照してください。
Oracle Managed File Transferには、MFT FTPプロキシ・サーバーが組み込まれており、このサーバーには次のような特性があります。
サポートするプロトコルはFTP、sFTPおよびFTPSです。
ファイアウォールの外側に独立して存在しているため、MFTをファイアウォールの外側にデプロイする必要がなくなります。
外部FTP要求を受け入れて、ファイアウォールの内側にあるMFTサーバーに転送します。
一般的には、単一のハードウェア・ロード・バランサに接続されます。
標準的なゲートウェイとリバース・プロキシのユース・ケースをサポートします。
ポートとインバウンド・サーバーIPアドレスの構成が可能です。
標準的なFTPクライアントであればどれでもサポートします。
次に示すのは単純なトポロジの1つです。
FTPクライアント→MFT FTPプロキシ・サーバー→ハードウェア・ロード・バランサ→MFTサーバー・クラスタ
MFT FTPプロキシ・サーバーを構成するファイルの場所は、WLS_HOME
/mft/applications/proxy/config
です。Readme.txt
ファイルに、MFT FTPプロキシ・サーバーの構成とデプロイの方法が記載されています。
ファイアウォールの設定方法の詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタ・アーキテクチャのセキュリティ・オプションに関する項を参照してください。
Oracle Managed File Transferは、Oracle WebLogic Serverの上で実行されます。したがって、Oracle Managed File Transferの高可用性の設定は、Oracle WebLogic Serverの高可用性の設定に依存します。
この項の内容は次のとおりです。
このプロセスの手順の概要は次のとおりです。
JCAアダプタのプロパティのうち高可用性に関するものを、Oracle WebLogic Serverの構成時に設定します。これらは、高可用性プロパティを設定するのに必要です。詳細は、テクノロジ・アダプタの理解の高可用性のためのOracleファイルおよびFTPアダプタの構成に関する項を参照してください。
Oracle Managed File Transferをインストールするときのドメイン構成のステップで、管理対象サーバーのクラスタを作成します。詳細は、Managed File Transferのインストールと構成を参照してください。
ソフトウェアまたはハードウェアのロード・バランサをインストールします。ロード・バランサで使用される「内部アドレス」と「外部アドレス」(IPアドレス)および「FTP」、「FTPs」および「sFTP」のポートを書き留めます。これらは、拡張配信プロパティを設定するのに必要です。詳細は、ロード・バランサのドキュメントを参照してください。
各管理対象サーバーを再起動します。「Oracle WebLogic Serverの起動と停止」を参照してください。
クラスタのトポロジ、仮想IPアドレス、ロード・バランシングのオプション、フェイルオーバーなどのトピックの詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください。
Oracle WebLogic Serverクラスタでユニキャスト・メッセージングを使用する場合に、クラスタ内のサーバーがすぐに同期しないときは、クラスタが再起動するときに次のようなメッセージが表示される可能性があります。
<Error> <oracle.soa.adapter.jms.inbound> <BEA-000000> <JMSMessageConsumer_init:[destination = MFTJMSServer_auto_2@jms/mft/MFTSourceQueue (payload = 1)]:ERRJMS_ERR_CR_QUEUE_CONS. Unable to create Queue receiver due to JMSException.
次のようなメッセージがスタック・トレースの中で見つかる可能性があります。
weblogic.jms.common.JMSException: could not find Server mft_server1 javax.naming.NameNotFoundException: Unable to resolve 'weblogic.messaging.dispatcher.S:mft_server1'. Resolved 'weblogic.messaging.dispatcher'; remaining name 'S:mft_server1'
通常はこれらのメッセージを無視してかまいません。サーバー同期は再試行され、通常は成功するからです。このメッセージが発生しないようにするには、次のいずれかを行います。
MBean属性「メンバーのウォームアップ・タイムアウト」を30に設定します。このようにして同期を遅延させると、先にクラスタ内のサーバーを起動するための時間を確保できます。
マルチキャスト・メッセージングを使用します。これを使用するときは、「メンバーのウォームアップ・タイムアウト」のデフォルト値が30に設定されます。
詳細は、『Oracle WebLogic Serverクラスタの管理』のクラスタ内の通信に関する項を参照してください。
Oracle Managed File Transferのイベント、たとえばエラーや新しいアーティファクトのデプロイメントのことを、特定のユーザーに通知できます。新規ユーザーを作成することも、既存のWebLogicユーザーおよびユーザー・グループも使うことができます。
新規ユーザーを作成するには、WLSTコマンドcreateContact
を使用します。これらのユーザーは外部です。
既存のWebLogicユーザーまたはユーザー・グループを使用するには、WLSTコマンドcreateUserContact
or create UserGroupContact
を使用します。これらは内部ユーザーであり、電子メール・アドレスと電話番号は、LDAPユーザー設定から取得されています。
イベントについて特定のユーザーに通知するには、Oracle Managed File TransferのためのWLSTのコマンドを使用して通知を構成し、次に電子メールまたはSMSのドライバを構成します。通知には、次の種類があります。
RUNTIME_ERROR_EVENT
: メッセージ処理やサーバー起動などのイベントの中で発生したエラー。
DELETE_ARTIFACT_EVENT
: 転送、ソースまたはターゲットの削除。
DEPLOY_ARTIFACT_EVENT
: 転送、ソースまたはターゲットのデプロイメント。
EXPORT_IMPORT_EVENT
: MFT構成のインポートまたはエクスポート。
PURGE_EVENT
: 実行時転送インスタンスまたは転送ペイロードのパージ。
ARCHIVE_RESTORE_EVENT
: 実行時転送インスタンスまたは転送ペイロードのアーカイブまたは復元。
JMS MFTExceptionQueueが有効かどうか、または、通知対象の連絡先が存在するかどうかに関係なく、通知メッセージはすべてそこに送信されます。MFTExceptionQueueの詳細は、「MFTExceptionQueue」を参照してください。
イベント通知を有効にする手順は次のとおりです。
「WLSTコマンドの実行」の説明に従ってWLSTを起動します。
ユーザーへの通知の対象となるイベントを有効化します。次に例を示します。
updateEvent('DEPLOY_ARTIFACT_EVENT', 'true')
通知先となるユーザー、つまり連絡先を作成します。次に例を示します。
createContact('Email', 'jane.doe@example.com')
createUserContact('john.doe', 'Email')
createUserGroupContact('MFT_User_Group', 'Email')
連絡先をイベントに関連付けます。次に例を示します。
addContactToNotification('DEPLOY_ARTIFACT_EVENT', 'Email', 'jane.doe@example.com')
種類がEMAIL
またはSMS
の通知が送られるようにするには、電子メールまたはSMSのドライバを構成する必要があります。詳細は、「通知のための電子メール・ドライバの構成」または「通知のためのSMSドライバの構成」を参照してください。
WebLogicユーザーまたはユーザー・グループへの配信チャネルを指定しない場合は、MFTがWebLogicユーザー・ストアで構成されているユーザー優先配信チャネルが使用されます。
Oracle Managed File TransferのためのWLSTの通知コマンドの詳細は、SOA Suite用WLSTコマンド・リファレンスを参照してください。
Oracle Enterprise Manager Fusion Middleware Controlを使用して、イベント通知のための電子メール・ドライバを構成します。
このプロセスの手順は次のとおりです。
Fusion Middleware Controlでの電子メール・ドライバの構成方法の詳細は、Oracle User Messaging Serviceの管理の電子メール・ドライバの構成に関する項を参照してください。
MFTをインストールする場合、MFTインストーラはMFTExceptionQueueと呼ばれるJMSキューを作成します。このキューを使用して、構成されていない通知用のイベントをトレースします。イベントをトレースするために、サーバーは通知がイベントに対して有効かどうかをチェックします。通知が有効ではない場合、同じメッセージがMFTExceptionQueueに発行されます。
JMS MFTExceptionQueueを使用することで、次のイベントを追跡できます。
表6-1 イベント
イベント | 説明 |
---|---|
RUNTIME_ERROR_EVENT |
このイベントは、実行時に発生したエラーを追跡します。次に例を示します。
|
EXPORT_IMPORT_EVENT |
このイベントは、エクスポートおよびインポート・エラーの両方を追跡します。通知が構成されていない場合、MFTは例外キュー内のメッセージを送信します。 たとえば、サンプル・メッセージにはリポジトリのエクスポート全体が含まれます。このメッセージは、イベントが正常に行われたときにのみ送信されます。 |
DEPLOY_ARTIFACT_EVENT |
このイベントは、アーティファクトのデプロイメント・イベントを追跡します。通知が構成されていない場合、MFTは例外キュー内のメッセージを送信します。 たとえば、サンプル・メッセージは、ソースのデプロイメント・イベントを示しています(「osbsrc1」など)。このメッセージは、デプロイメントが正常に行われたときにのみ送信されます。 |
DELETE_ARTIFACT_EVENT |
このイベントは、ヒント・メタデータの削除を追跡します。 たとえば、ソース、転送およびターゲットの削除です。 |
PURGE_EVENT |
このイベントは、実行時/ペイロード・パージを追跡します。実行時/ペイロード・パージが実行されるときに、MFTは例外キューのメッセージを送信します。このメッセージは、通知が構成されていない場合にかぎり、パージが正常に完了すると送信されます。 たとえば、サンプル・メッセージは実行時パージを示します。 |
ARCHIVE_RESTORE_EVENT |
このイベントは、実行時/ペイロード・アーカイブおよびリストアを追跡します。実行時/ペイロード・データに対してアーカイブ/リストアが実行されるときに、MFTは例外キューのメッセージを送信します。このメッセージは、通知が構成されていない場合にかぎり、イベントが正常に完了すると送信されます。 たとえば、サンプル・メッセージは実行時アーカイブ・イベントを示します。 |
MFTの実行時エラー・イベントを受け取るようにJMSキューを構成するには、Oracle WebLogic Server管理コンソールを使用します。
既存のMFT実行時プロセッサ・キューには次のものがあります。
MFTSourceQueue
MFTInstanceQueue
MFTTargetQueue
この項では、これらの実行時プロセッサ・キューのそれぞれに対応するエラー・キューを作成する方法を説明します。
MFTでは、メッセージは非同期的に処理されます。1つのMFTメッセージが3つの異なるプロセッサにより処理され、各プロセッサに対し、次に示すように対応するキューがあります。
表6-2 プロセッサおよびキュー
プロセッサ | キュー |
---|---|
ソース・プロセッサ |
MFTSourceQueue |
インスタンス・プロセッサ |
MFTInstanceQueue |
ターゲット・プロセッサ |
MFTTargetQueue |
また、各MFTメッセージは、各プロセッサ用のJMSメッセージに対応します。エラー・プロセッサ・キューへの例外が発生する場合があります。
予期されるまたは予期されないシステム・レベルのエラーは、次の方法で処理されます。
予期されるシステム・レベルのエラー: ファイルが見つからないといった予期されるシステム・レベルのエラーに対し、「Error」とマークされた対応するMFTメッセージが存在します。
リモート・サーバーの停止といった配信関係の予期されるエラーに対し、対応するメッセージがターゲットの再試行設定に基づいて再試行されます。その他の予期されるエラーに対しては、再試行は行われません。
予期されないシステム・レベルのエラー: RAC障害またはJMS障害といった予期されないシステム・レベルのエラーがある場合、MFTはJMSメッセージを3回再試行します。再試行回数の上限に達したら、MFTメッセージはアクティブ・ステータスのままになります。対応するJMSメッセージはパージされるかどうかは、JMSプロセッサ・エラー・キューがMFT処理キューに関連付けられているかどうかによって異なります。
デフォルトでは、エラー処理キューは構成されません。この場合、JMSメッセージはパージされ、それ以外の場合は、JMSメッセージは構成されたエラー・キューにリダイレクトされます。
転送インスタンスがアクティブ・ステータスのまま長時間変化しない場合は、これらのエラー・キューを調べてください。エラー・キューの中のJMSメッセージには、転送インスタンスの詳細情報が記録されています。このメッセージIDをMFTログ・ファイルの中で検索すると、根本原因(エラー・スタック)を検索できます。問題が解決したら、再処理のためにJMSメッセージを対応する実行キューに再送信します。
エラー・キューを作成する手順は次のとおりです。
MFTコンポーネントのログ・メッセージは、この場所にあるログ・ファイルに書き込まれます。
WLS_HOME/user_projects/domains/base_domain/servers/mft_server1/mft_server1-mft-diagnostic.log
MFT埋込みサーバーのログ・メッセージは、この場所にあるログ・ファイルに書き込まれます。
WLS_HOME/user_projects/domains/base_domain/servers/mft_server1/mft-es/mft_server1-mft-es-diagnostic.log
Oracle Enterprise Manager Fusion Middleware Controlを使用して、これらのログ・ファイルのサイズを変更することや、メッセージをこれらのログ・ファイルに書き込む様々なログ出力のログ・レベルを設定できます。
このプロセスの手順は次のとおりです。
Fusion Middleware Controlコンソールにログインします。
ターゲット・ナビゲーション・ペインで、WebLogicドメイン・ノードを開きます。
Oracle Managed File Transfer専用のOracle WebLogic Server管理対象サーバーがインストールされているドメインのノードを開きます。
たとえば、ドメインはsoainfra
またはbase_domain
です。
MFTサーバーを右クリックします。
たとえば、MFTサーバーはmft_server1
です。
「ログ」→「ログ構成」の順に選択します。
「ログ・ファイル」タブを選択します。
「odl-handler」
を選択して「構成の編集」をクリックします。
「最大ログ・ファイル・サイズ(MB)」と「すべてのログ・ファイルの最大サイズ(MB)」の値を編集して「OK」をクリックします。
「ログ・レベル」タブを選択します。
「ルート・ログ出力」ノードを開き、必要に応じてその他のノードも開いて、ログ・レベルの設定の対象となるログ出力を表示します。
表6-3 は、MFTのコンポーネントに関係するログ出力の一覧です。表6-4 は、MFTの埋込みサーバーに関係するログ出力の一覧です。
各ログ出力について、「Oracle Diagnostic Loggingレベル(Javaレベル)」をSEVERE+100、SEVERE、WARNING、INFO、CONFIG、FINE、FINERまたはFINESTに設定します。デフォルトはINFOです。
必要に応じて、「コンポーネントの再起動後もログ・レベル状態を維持」チェック・ボックスを選択します。
「適用」をクリックします。
表6-3 MFTコンポーネントのログ出力
ログ出力名 | ログに記録されるイベント | デフォルト・レベル | 本番のレベル |
---|---|---|---|
|
メッセージ処理、処理関数とコールアウト、デプロイメント操作 |
INFO |
SEVERE |
|
トランスポート層相互作用操作、システム・イベント |
INFO |
SEVERE |
|
監査、通知、パージ、アーカイブ、復元、サーバー起動、共通ユーティリティAPI |
INFO |
SEVERE |
|
Java永続性操作 |
INFO |
SEVERE |
|
WLSTおよびEJBによって呼び出されたAPI処理 |
INFO |
SEVERE |
|
スケジュール操作 |
INFO |
SEVERE |
|
埋込みサーバーとMFTサーバーとの通信 |
INFO |
SEVERE |
|
セキュリティ操作、OWSMローカル・ポリシー |
INFO |
SEVERE |
|
コンソール操作 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
|
テクノロジ・アダプタの理解を参照してください。 |
INFO |
SEVERE |
表6-4 MFT埋込みサーバーのログ出力
ログ出力名 | ログに記録されるイベント | デフォルト・レベル | 本番のレベル |
---|---|---|---|
|
FTP操作 |
INFO |
SEVERE |
|
sFTP操作 |
INFO |
SEVERE |
Oracle Enterprise Manager Fusion Middleware Controlを使用して、Oracle Managed File Transferのログ・ファイル内のメッセージを表示できます。
このプロセスの手順は次のとおりです。
MFTメタデータを開発環境またはテスト環境から本番環境に移動するとき、主要なプロトコル属性を置き換えることができます。
環境間で(たとえば、テスト環境から本番環境へ)メタデータを移動する際には、環境固有の値を変更しなければならない場合があります。構成プランと呼ばれる単一のテキスト(XML)ファイルを使用して、これらの値を変更できます。構成計画は、エクスポートwlstコマンドを使用するか、UIからエクスポートして作成できます。構成計画XMLで生成されるデフォルトには、現在の値が含まれます。本番環境にファイルを移動する準備できたら、構成計画xmlを変更して、本番環境で必要な値の置換文字列を指定できます。本番環境でインポート・コマンドを呼び出すとき、変更した構成xmlファイルを指定すると、文字列の置換を指定することができます。変更した構成計画を確認するには、previewModeオプションを使用できます。このオプションはwlstコマンドでのみ使用でき、UIでは使用できません。
新しいパラメータ、configFileが既存のインポートのwlstコマンドに追加されたので、キー属性のconfigPlan xmlを介して、文字列置換をオプションで指定することができます。
新しいパラメータ、configFileが既存のエクスポートのwlstコマンドに追加されたので、configPlan xmlをどこに生成するか、オプションで指定することができます。この表には、configPlanで置換に対応するキー属性をまとめています。
プロトコル |
属性 |
ファイル |
folder |
FTP |
host、controlPort、user、password、folder |
SSH-FTP |
host、port、user、password、folder、authenticationType、privateKeyFile、publicKeyFile |
Embedded-FTP |
folder |
Embedded-SSH-FTP |
folder |
WS(SOA,SOAP,ODI,OSB) |
url、service、port、action |
B2B |
tpChannelName |
Healthcare |
endpointName |
構成計画とT2P移行をいつ使用するかの理解
MFTでデータの移行が必要な場合は、T2P移行とMFT構成計画の2つの方法があります。
T2Pでは、T2Pフレームワークに対するMFTプラグインを使用してデプロイメント全体を一度に移行します。移行のスクリプトは、新しいターゲット環境への移行を対象としています。既存の環境にアーティファクトを移動することには対応しておらず、アーティファクトの段階的な移動もできません。
T2P移行スクリプトの詳細は、『Oracle Fusion Middlewareの管理』のテスト環境から本番環境への移行に関する項を参照してください。
MFT構成計画では、アーティファクト・レベルのプロパティ(ソース、ターゲット、転送)も含めて段階的に移行します。構成計画は、次のような場合に使用します。
テスト環境から本番環境にtransfer1を移行し、ホスト名をtestHost1.comからpartner1.comに変更する必要がある場合。
パスワードは環境ごとに異なるため、MFT構成計画にはインポート中にパスワードを変更するオプションもあります
PGP鍵の別名は環境ごとに異なるため、MFT構成計画にはインポート中に鍵の別名を変更するオプションもあります。
属性のグローバル置換
名前や内部フィールドとは別に、任意の属性値をグローバルに置換できます。次に示すのは、グローバル文字列置換の2つの例です。
<searchReplace> <search>http://my-dev-server</search> <replace>http://my-test-server</replace> <searchReplace>
<Source name= "*"> <searchReplace> <search>http://my-dev-server1</search> <replace>http://my-test-server1</replace> <searchReplace> <Source>
任意のソースまたはターゲットのキー属性の変更
ConfigPlan xmlには、ソースおよびターゲットすべてのキー属性がリストされ、特定のアーティファクトの値を変更するオプションがあります。次に例を示します。
<Source name="PO Source"> <binding type="ftp"> <attribute name="port"> <replace>8888</replace> </attribute> <attribute name="host"> <replace>example.com</replace> </attribute> </binding> </Source>
競合する場合は、優先順位は次のようになります。
アーティファクト固有の変更
アーティファクト固有のグローバル・ルール
グローバル置換
基本的な検証は、すべての置換フィールドに対して実行されます。完全な検証は、デプロイ中にのみ実行されます。基本的な検証には、次のものがあります。
タイプ検証: たとえば、プール値のフィールドではtrue/falseのみを使用可能
制限チェック: フィールドが指定された特定の値でバインドされている場合は、それらの値のみ使用可能
インポートに含めるアーティファクトの指定
構成計画xmlでは、インポートに含めるアップデートを指定できます。次に例を示します。
<transfers> <include> <transfer name="PO transfer"/> </include> <transfers>
パスワードの変更
新しいwlstコマンドcreateMftCredential
は、生成されたキーに対するCSF参照を返すか、出力します(またはその両方)。ターゲット環境でキーが生成されると、構成計画で同じ参照を使用してパスワード・フィールドを置き換えることができます。
注意:
パスワードのクリアはサポートされません。
インポートのレビュー
インポート・コマンドのプレビュー・モード・オプションでは、メタデータをインポートしません。エクスポートされるアーティファクトと、構成計画のためにエクスポートのzipで上書きされるすべての属性がリストされるだけです。デフォルト値はfalseです。
変更されたWLSTコマンド
次の表は、変更されたwlstコマンドの詳細を示しています。
コマンド |
詳細 |
構文およびパラメータ |
例 |
exportMetadata |
MFTのメタデータをすべて、指定されたファイルにエクスポートします(TIPバージョンのみ) |
exportMetadata('<ArchiveFile>', generateConfigPlan, longFormat) ArchiveFile: メタデータをエクスポートするファイルの場所 generateConfigPlan (オプション。デフォルトはfalse): mftConfig XMLを生成するかどうかを指定します。構成計画は、アーカイブ・ファイルが生成されるのと同じフォルダに生成されます longFormat (オプション。デフォルトはfalse): trueの場合は、config plan xmlに属性のほとんどが含まれます。それ以外の場合、構成プランXMLには主要な属性のみがリストされます |
wls:/mydomain/serverConfig> exportMetadata("/tmp/mft/mds.zip") wls:/mydomain/serverConfig> exportMetadata("/tmp/mft/mds.zip", true) wls:/mydomain/serverConfig> exportMetadata("/tmp/mft/mds.zip", true, true) |
exportTransferMetadata |
指定した転送と関連メタデータを、指定されたファイルにエクスポートします(TIPバージョンのみ)。 |
exportTransferMetadata('<ArchiveFile>', '<TransferName>', generateConfigPlan, longFormat ) ArchiveFile: メタデータをエクスポートするファイルの場所 TransferName: エクスポートする転送の名前 generateConfigPlan (オプション。デフォルトはfalse): mftConfig XMLを生成するかどうかを指定します。構成計画は、アーカイブ・ファイルが生成されるのと同じフォルダに生成されます longFormat (オプション。デフォルトはfalse): trueの場合は、config plan xmlに属性のほとんどが含まれます。それ以外の場合、構成プランXMLには主要な属性のみがリストされます |
wls:/mydomain/serverConfig> exportTransferMetadata('/tmp/mft/mds-xfer.zip', 'cotsmart-xfer') wls:/mydomain/serverConfig> exportTransferMetadata('/tmp/mft/mds-xfer.zip', 'cotsmart-xfer', true) wls:/mydomain/serverConfig> exportTransferMetadata('/tmp/mft/mds-xfer.zip', 'cotsmart-xfer', true, true) |
exportDeployedArtifact |
デプロイされたアーティファクトを、指定されたmdsラベルからエクスポートします。 |
exportDeployedArtifact('<ArtifactType>','<ArtifactName>',<Label>,'<ArchiveFilePath>',generateConfigPlan, longFormat) ArtifactType - SOURCE/TRANSFER/TARGET ArtifactName: エクスポートされるアーティファクトの名前 Label: エクスポートMDSラベル ArchiveFilePath: アーティファクトをエクスポートするファイル。存在しないzipファイルである必要があります。 generateConfigPlan (オプション。デフォルトはfalse): mftConfig XMLを生成するかどうかを指定します。構成計画は、アーカイブ・ファイルが生成されるのと同じフォルダに生成されます longFormat (オプション。デフォルトはfalse): trueの場合は、config plan xmlに属性のほとんどが含まれます。それ以外の場合、構成プランXMLには主要な属性のみがリストされます |
wls:/mydomain/serverConfig> exportDeployedArtifact('TARGET','cotsmart-file-tgt','soa_mft-2012-12-07 22:24:09.383','/tmp/export/cotsmart-file.zip') wls:/mydomain/serverConfig> exportDeployedArtifact('TARGET','cotsmart-file-tgt','soa_mft-2012-12-07 22:24:09.383','/tmp/export/cotsmart-file.zip', true) wls:/mydomain/serverConfig> exportDeployedArtifact('TARGET','cotsmart-file-tgt','soa_mft-2012-12-07 22:24:09.383','/tmp/export/cotsmart-file.zip', true,true)n |
importMetadata |
指定されたファイルの場所からメタデータをインポートします。オプションでmft構成計画を指定すると、インポート中にパラメータを変更できます。コマンドは、プレビュー・モードでも実行できます。 |
importMetadata('<ArchiveFile>',<MftConfigPlanXML>, previewMode) ArchiveFile: メタデータをインポートするファイルの場所 configFileLocation(optional): mftConfig XMLのファイルの場所 previewMode (オプション。デフォルトはfalse): trueの場合、メタデータはインポートされません。構成計画のためにどの属性を変更するかを決定する目的で使用できます。 |
wls:/mydomain/serverConfig> importMetadata("/tmp/mft/mds.zip") wls:/mydomain/serverConfig> importMetadata("/tmp/mft/mds.zip","/tmp/mft/mftconfigplan.xml") これはメタデータをインポートし、構成計画XMLを使用して値をオーバーライドします。 wls:/mydomain/serverConfig> importMetadata("/tmp/mft/mds.zip","/tmp/mft/mftconfigplan.xml", false) メタデータはインポートしません。構成計画を使用してどの属性が変更されるかについて、情報が提供されます。 |
createMftCredential |
mftappの資格証明を作成します。 |
createMftCredential(password, key) password: mftappに対して資格証明を作成する必要があるパスワード。 key (オプション): 資格証明の鍵 |
wls:/mydomain/serverConfig> createMftCredential('mypass') wls:/mydomain/serverConfig> createMftCredential('mypass','mykey') |