原文はこちら。
https://blogs.oracle.com/integration/entry/patching_soa_composite_instances_in

---

Introduction

Composite Instance Patching12.2.1で導入された新機能で、これを使うと互換性のある変更をSOAコンポジット定義に対して実施し、長時間実行中のアクティブなインスタンスに適用することができます。特徴は、コンポジットを実行中のインスタンスに対してパッチを適用し、ランタイムにパッチを適用した後、失敗したインスタンスを回復できる、という点で、これを使うことで、コンポジットに対する緊急の修正を提供し、長時間実行中のインスタンスを停止せずに互換性/許可された変更をコンポジットに対して適用できます。パッチが適用された実行中のインスタンスがパッチによって修正されたビジネスプロセス、例えばBPELのTransformationに遭遇すると、ビジネスプロセスに適用された修正を受け取ります。
12.2.1以前では、コンポジットに小さな変更を加えたり、実行中のインスタンス、具体的には長時間実行中のインスタンスや、エラーホスピタルのインスタンスがそうした変更を確認する方法がありませんでした。代替策としては、既存のコンポジットのリビジョンをデプロイするか、新たなコンポジットのリビジョンを作成することですが、前者の場合、実行中のインスタンスが処理を停止してしまうこと、後者の場合、既存の実行インスタンスはそのまま実行できるものの、新しいリビジョンで導入された変更はわからない、という問題があります。そこで、12.2.1での新しいComposite Instance Patching機能を使用すると、重要な修正をタイムリーに適用し即時有効化できる、という点が、Oracle SOA Suiteのユニークな差別化要素です。
このエントリでは、(1) コンポジットに加えることのできる互換性のある変更について紹介するとともに、(2) コンポジットパッチで無効な変更を加える心配なく、迅速かつ簡単にパッチを設計できる、JDeveloperへの機能強化を説明し、(3) SOA Suiteへコンポジットインスタンスへのパッチをビルド、検証、デプロイで使う手順を紹介します。

Compatible Composite Changes

前述の通り、コンポジットに対して加えることができ、実行中のインスタンスとの互換性があると見なされる変更は限られています。Composite Instance Patchingで扱える互換性のある変更をいくつかご紹介しましょう。

• スキーマに関係しないXSLTの変更
• フォルトポリシー、センサーデータ、アナリティクスデータへの変更
• BPELへの互換性のある変更。例えば同期/非同期呼び出し、Transformationアクティビティ、Assignなど
• JCA Adapterの構成プロパティ
• コンポジット参照（Reference）のトークン値の変更

対して、Composite Instance Patchingで扱えない、互換性のない変更は以下のようなものがあります。

• コンポジットあーティファクトの削除や名前変更
• バインディングプロパティの更新
• WSDLやスキーマ定義への変更
• XQueryマッピングへの変更
• BPELのReceive、構造化アクティビティ、Assignにおけるマッパー（ソース、ターゲット、スキップ条件）

どれが互換性のある変更で、どれが非互換なのかを正確に知っておく必要はありません。こうしたルールはJDeveloperのSOA Patch Developerモードで把握しており、自動的にパッチを作成できない変更を無効化します。

Composite Instance Patch Development in JDeveloper

コンポジットインスタンスへのパッチ作成を簡単にするため、数多くの機能強化がJDeveloperになされました。第1の変更点は、新たなSOA Patch Developerロールの導入です。JDeveloperを立ち上げたときに、最初に自身の要求に適うロールを選択する必要があります。


選択されたロールでは、メニュー、プリファレンス、新規ギャラリ、およびダイアログ上の個々のフィールドまでを含む、不要な項目をJDeveloperから除去するようにJDeveloper環境を仕立てます。選択したロールによって、利用可能な機能とオプションが決まります。SOA Patching Developerロールの場合、利用可能なアクション、エディタ、ウィザードによってユーザーが制限され、コンポジットインスタンスへのパッチ作成のため、互換性のある変更に関連するアクションのみ許可されます。
すでにJDeveloperでプロジェクトを開いている場合は、Oracle JDeveloperのメニューバーから、［ツール］> ［ロールの切替え］>［SOA Patch Developer］とたどって、SOA Patch Developerモードに切り替える必要があります。 新たなロールを選択すると、変更を有効にするためにJDeveloperを再起動するように求められます。





新しいコンポジット・インスタンス・パッチを作成する場合、出発点は既存のデプロイ済みSOAコンポジットのリビジョンです。SOA Patch Developerロールである間、コンポジットへの後の変更は新たなpatch.xmlファイルでトラッキングされています。このファイルは変更されたアーティファクトファイルが最初に保存される際にプロジェクトディレクトリ内のSOA/SCA-INFディレクトリに自動的に生成されます。patch.xmlファイルは、SOA Patch Developerモードでコンポジットを変更、保存するたびに更新されます。patch.xmlファイルはメニューバーの［アプリケーション］＞［概要の表示］を開き、XMLファイルの配下にあるpatch.xmlを選択すると表示できます。
プロジェクトにpatch.xmlがあるかないかで、コンポジット・パッチを作成しているのか、新規リビジョンを作成しているのかをJDeveloperに伝えます。SOA Patch Developerロールでない場合にpatch.xmlファイルを含むプロジェクトを開くと、以下の3個の方法のうち一つをとるよう求められます。

1. SOA Patch Developerロールに切り替え、パッチ作成を継続する
2. 現在のロールでプロジェクトを閉じる（つまり何もしない）
3. project.xmlファイルを削除し、新しいコンポジット・リビジョンを作成する

なお、project.xmlファイルの削除を選択した場合、SOA Patch Developerロールで実施したコンポジットへの変更は消失しませんが、パッチ用にアーティファクトを修正したその記録はなくなることにご注意ください。

［訳注］
本来ならば、［Patch File Found］を意味する「パッチ・ファイルが見つかりました」となるべきところが、翻訳ミスで逆の意味になってしまっています。現在修正を依頼しています。


なお、英語の場合はこんな感じです。


patch.xmlファイルで参照されているアーティファクトのみコンポジットインスタンスパッチのデプロイメントアーカイブに取り込まれます。パッチアーカイブには通常のデプロイメント・アーカイブ（.sarファイル）にあるファイルの完全なセットは含まれていませんので、「少ない(sparse)」パッチ・アーカイブとも呼ばれます。パッチ・アーカイブを作成するためには、実行環境に変更をデプロイするためのデプロイメント・プロファイルを作成することから始めます。以下の手順を踏んでJDeveloperを使ってパッチのデプロイメント・プロファイルを作成します。

1. ［アプリケーション］内のプロジェクト名を右クリックし、［デプロイ］＞［プロジェクト名］を選択します。新規デプロイメント・プロファイルを選択してもよいですし、以前に作成したパッチのデプロイメント・プロファイルを選択してもかまいません。［プロジェクト名］のデプロイウィザードが現れます。
2. プロジェクトをデプロイするために、ウィザードの全手順を完了します。デプロイの構成（Deploy Configuration、なぜか日本語表示では構成のデプロイになっていますが...）画面では新たなバージョンの作成や既存バージョンの上書きはできないことに注意してください。これは別のバージョンを作成せず、実行中のインスタンスに影響を与えずに、パッチを実行環境にデプロイするためです。
3. ［終了］をクリックして、パッチのjarファイルを作成します。プロジェクト名/deployディレクトリにパッチのjarファイルがプロジェクトオリジナルのjarファイルに加えて格納されているはずです。デフォルトでは、パッチのjarファイルの名前はsca_{プロジェクト名}_patch.jarという表記ルールに則っています。

その他にも、AntやWLSTコマンドラインツールを使ってパッチ・アーカイブを作成することができます。パッチ・アーカイブをAntで作成する場合、以下のようにスクリプトを呼び出します。

ant -f  jdev_home/soa/bin/ant-sca-package.xml  -DcompositeDir=path_to_project_soa_folder -DcompositeName=composite_name  -Drevision=composite_revision

WLSTコマンドラインツールを使ってパッチ・アーカイブを作成する場合、sca_packagePatchコマンドを使います。sca_packagePatchコマンドの構文や引数に関する詳細情報は、ヘルプコマンド help(‘sca_packagePatch’) を使って確認できます。
例として、 sca_packagePatch('/home/HelloWorld/SOA','HelloWorld','1.0') とすると、/home/HelloWorld/SOA というディレクトリにコンポジット・アーティファクトのためのパッチ・アーカイブが作成されます。

Deploying the Composite Instance Patch

WLSTコマンドラインツールを使ってパッチのjarファイルを検証、デプロイすることができます。sca_validatePatchとsca_patchCompositeという2個のコマンドを使い、パッチを検証、デプロイします。以下の手順を踏んで、パッケージ済みjar（コンポジットのSARファイル）を検証し、実行環境にデプロイします。

• sca_validatePatchコマンドを使用して、パッチのjarファイルを検証します。sca_validatePatchコマンドの構文および引数の詳細情報は、help('sca_validatePatch')で確認できます。例として、sca_validatePatch('http://my_soa_server:8001', 'weblogic',  'welcome', '/home/sca_HelloWorld_patch.jar') を実行した場合、sca_HelloWorld_patch.jar というパッチファイルが正常にmy_soa_serverのSOAサーバ実行環境にデプロイできるかどうかを確認します。コンポジット・パッチの検証で問題がないことが確認されると、「コンポジット・パッチは正常に検証されました（"Composite patch has been validated successfully"）」というメッセージが表示されるはずです。
• sca_patchCompositeコマンドを使用して、パッチのjarファイルを実行環境にデプロイします。help(‘sca_patchComposite’)でsca_patchCompositeコマンドの構文および引数の詳細情報を取得することができます。例えば、sca_patchComposite('http://my_soa_server:8001', 'weblogic', 'welcome', '/home/sca_HelloWorld_patch.jar') とすると、sca_HelloWorld_patch.jarというパッチのjarファイルを使ってmy_soa_serverの実行環境上のHelloWorldコンポジットにパッチを適用します。パッチが正常に適用されると、「コンポジットは正常にパッチが適用されました（Composite has been patched successfully）」のメッセージが表示されるはずです。デプロイ前にパッチのjarファイルを検証するのを忘れたとしても、心配する必要はありません。デプロイメント・アクション中に、コンポジットのリビジョンをアップデートする前にサーバ側で検証チェックを実施するので、非互換の変更によって実行環境へ誤ってアップロードされることはありません。

Enterprise Manager Fusion Middleware Controlで以前に失敗したフローインスタンスを確認していて、このパッチを適用後リカバリが可能な場合、リカバリしてみてください。

JDeveloper-Based Patching Process

Composite Instance Patchingを、正式なビルドプロセスに組み込む方法には様々考えられますが、その一つをご紹介しましょう。

1. 開発者は「SOAパッチ開発（SOA Patch Developer）」モードでJDeveloperを起動し、、ソースコントロールで見つかった既存のコンポジット用の互換性のある変更/修正のセットを作成します
2. ソース管理の"patching"ブランチに変更を保存し戻します。
3. 「互換性のある」コンポジットの修正のデプロイメント・アーカイブをソース管理からantスクリプトを使って作成し、後続のテスト作業のため、テスト/ステージング環境にWLSTコマンドを使ってデプロイします¹。
4. もしくは、デプロイメント・アーカイブをJDeveloperで作成し、その後のテストのために、WLSTコマンドを使用して開発環境にデプロイします¹。
5. このアーカイブを本番環境にデプロイし、実行インスタンスが新しいメタデータを使って処理を継続します¹。

¹ランタイム検証・互換性のチェックは、変更されたアーティファクトに対してパッチデプロイ中に実行されます。

Conclusions

新機能であるComposite Instance PatchingがSOA Suite 12.2.1で導入されました。これを使うとコンポジットに対する緊急の修正を展開し、長時間実行中のインスタンスが取り込むことができるようになります。この機能はOracle Integration Continuous Availabilityに含まれています。その他の情報は、以下のドキュメントをご覧ください。

Oracle® Fusion Middleware Developing SOA Applications with Oracle SOA Suite 12c (12.2.1)
Patching Running Instances of a SOA Composite
http://docs.oracle.com/middleware/1221/soasuite/develop/GUID-F2B6386E-0F68-4797-96D2-196800394FEF.htm#SOASE-GUID-4010E817-DF41-4CCC-B9CC-196EE6AB8905