| Oracle® Fusion Middleware Oracle Java CAPS Migration Toolユーザーズ・ガイド 11g リリース1 (11.1.1.6.0) B66433-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Java CAPS Migration Toolユーザーズ・ガイド 11g リリース1 (11.1.1.6.0) B66433-01 |
|
前 |
次 |
この章では、Oracle Java CAPSからOracle SOA Suiteに移行したプロジェクトに行う必要がある更新の手順について説明します。移行ツールでプロジェクトを変換した後は、Oracle JDeveloperでプロジェクトを開いて、生成されたコンポーネントの一部を変更し、場合によっては新しいコンポーネントを追加する必要があります。その後に、それらのプロジェクトをWebLogic Serverにデプロイできます。
この章には次のトピックが含まれます:
Oracle Java CAPS Migration Toolでプロジェクトの移行を完了した後は、生成されたOracle SOA SuiteファイルをOracle JDeveloperで開いて、プロジェクトを確認し、場合によってはプロジェクト・コンポーネントを変更または追加する必要があります。
移行後のプロジェクトをOracle JDeveloperで開く手順は、次のとおりです。
Oracle JDeveloperを起動します。
Oracle JDeveloperを起動するには、jdeveloper_home/jdev/binにナビゲートして、jdev実行可能ファイルを実行します。
Oracle JDeveloperのメイン・メニューで、「ファイル」をクリックし、「開く」を選択します。
表示されたダイアログで、移行後のプロジェクト・ファイルが存在するフォルダを参照して、プロジェクト・ファイルを選択します。
|
ヒント: これは、JPRの拡張子を持つファイルです。 |
ダイアログの「開く」をクリックします。
「プロジェクトを収容するアプリケーションの作成」ダイアログが表示されます。
ダイアログで、アプリケーションの名前を入力し、「OK」をクリックします。
左側のアプリケーション・ナビゲーション・パネルに、プロジェクト・ファイルが表示されます。
ナビゲーション・ツリーで、「SOAコンテンツ」を開いて、composite.xmlファイルを開きます。
図4-1に、Oracle JDeveloperでの変換後のプロジェクトの例を示します。サービス、ビジネス・プロセス、Springコンポーネントおよび複数の参照が含まれています。
図4-1 Oracle JDeveloperでの変換後のOracle Java CAPSプロジェクト
移行ツールを使用してOracle Java CAPS JBIプロジェクトを処理した後は、移行を完了して移行後のプロジェクトの正常なデプロイメントを実行するために、手動での手順が必要な場合があります。次に、移行後のJBIプロジェクトに対して必要になる可能性がある更新をいくつか示します。
すべてのOracle Java CAPSバインディング・コンポーネント・プロパティに、Oracle SOA Suiteアダプタ・プロパティとの1対1の対応関係が存在するとはかぎらないため、移行ツールでは、必須のプロパティ・セットのみが移行されます。移行後のプロジェクトをデプロイする前に、コンポジット内の各サービスおよび参照に対して構成ウィザードを実行し、構成を確認または更新する必要があります。
サービスまたは参照を構成する手順は、次のとおりです。
4.1項「移行後のプロジェクトをOracle JDeveloperで開く」の説明に従って、Oracle JDeveloperでプロジェクトとそのコンポジットを開きます。
構成するサービスまたは参照をダブルクリックするか、コンポーネントを右クリックして「編集」を選択します。
そのコンポーネントの構成ウィザードが表示されます。
ウィザードの手順に従って、構成を完了します。
JMSアダプタ構成ウィザードの「JMSプロバイダ」ページで、移行後のプロジェクトに対してデフォルトで選択されるオプションは「サード・パーティ」です。JMSプロバイダがOracle WebLogic JMSまたはOracle Advanced Queueingである場合は、選択をOracle Enterprise Messaging Serviceに変更して、使用するプロバイダを選択する必要があります。
JMSアダプタの場合は、Oracle WebLogic Server管理コンソールで、新しい接続ファクトリと宛先を作成する必要があり、JMSアダプタ構成で指定されている名前と一致するようにします。別の方法として、既存の接続ファクトリと宛先を使用するようにアダプタを再構成することもできます。WebLogic ServerでJMSリソースを作成する手順については、4.7項「JMSリソースの作成」を参照してください。
WSDLは、特定のポート・タイプに対する複数の操作をサポートします。Oracle Java CAPSでは、ポート・タイプに対して1つのサービス定義であってもかまいませんが、Oracle SOA Suiteでは、各操作に対して複数のサービス要素を定義する必要があります。コンポジット内での参照の場合は、複数の操作を持つポート・タイプに対して複数の参照要素は必要ありません。SOAP以外のバインディング・タイプを持つOracle SOA Suiteプロジェクトでは、JCAファイル内のバインディング構成で、複数のエンドポイント・アクティブ化およびエンドポイント相互作用の要素(各操作につき1つずつ)を定義します。
複数の操作を持つポート・タイプが使用されているOracle Java CAPS WSDLドキュメントの場合は、移行ツールによって、移行後のWSDLおよびJCAファイルに複数のエンドポイント・アクティブ化およびエンドポイント相互作用の要素が移入されますが、生成されたcomposite.xmlファイルでは(各操作につき1つずつの)複数のサービス要素は定義されません。
そのようなプロジェクトの場合は、生成されたcomposite.xmlファイルを手動で編集して、複数のサービス要素(各操作につき1つずつ)を作成する必要があります。また、service要素のbinding.jca属性をoperation属性で修飾する必要があります。
例4-1 複数の操作を持つポート・タイプの手動変更
この例の場合、元のJava CAPSバインディング・コンポーネントでは、インバウンド・ファイル・エンドポイントに対して2つの操作を定義していました。次に、移行ツールによって生成されたcomposite.xmlファイル内のservice要素を示します。
<service name="FileInboundService_FileInWSDL_InboundPort"
ui:wsdlLocation="FileInWSDL.wsdl">
<interface.wsdl interface="http://j2ee.netbeans.org/wsdl/FileInOut/
FileInWSDL#wsdl.interface(FileInboundPortType)"/>
<binding.jca
config="FileInboundService_FileInWSDL_InboundPort_file.jca"/>
</service>
必要な変更を行った後のcomposite.xml内のservice要素は次のようになります。
<service name="FileInboundService_FileInWSDL_InboundPort"
ui:wsdlLocation="FileInWSDL.wsdl">
<interface.wsdl interface="http://j2ee.netbeans.org/wsdl/FileInOut/
FileInWSDL#wsdl.interface(FileInboundPortType)"/>
<binding.jca
config="FileInboundService_FileInWSDL_InboundPort_file.jca"
operation="pollMain"/>
</service>
<service name="FileInboundService_FileInWSDL_InboundPort"
ui:wsdlLocation="FileInWSDL.wsdl">
<interface.wsdl interface="http://j2ee.netbeans.org/wsdl/FileInOut/
FileInWSDL#wsdl.interface(FileInboundPortType)"/>
<binding.jca
config="FileInboundService_FileInWSDL_InboundPort_file.jca"
operation="pollBackupDir"/>
</service>
Oracle Java CAPS JBIプロジェクトの場合は、いくつかのサービス品質プロパティを構成できます。これらのプロパティのすべてがそのままOracle SOA Suiteの機能に引き継がれるわけではありません。制限および再配信のプロパティは、Oracle Java CAPS Migration Toolによって移行されません。制限を使用すると、一貫したパフォーマンスが維持されるように、特定のエンドポイントで処理される同時メッセージの最大数を設定できます。再配信の設定では、初回の配信が失敗した場合のメッセージ配信を処理します。
制限では、BPELプロセス・サービス・エンジン用のメモリー内のリクエスト数を制限できます。これは、入力専用のインバウンド・リクエストに影響を及ぼします。この制限を設定するには、BPELプロセス・サービス・エンジンのMaximumNumberOfInvokeMessagesInCacheプロパティを構成します。詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』の「BPELプロセスのサービス・コンポーネントとエンジンの構成」を参照してください。
BPELプロセス・サービス・エンジンのフォルト・ポリシーを使用して、様々な再配信を構成できます。詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』のフォルト管理フレームワークの使用に関する項を参照してください。
Oracle Java CAPS JBIでサポートされているBPEL 2.0の一部はOracle SOA Suiteでは使用できないため、次のコンストラクトを使用しているプロジェクトの場合は、変換後のBPELコードを確認する必要があります。これらはOracle SOA Suiteではサポートされませんが、変換後のBPELコードには含まれます。
補正ハンドラおよび終了ハンドラ: 元のJava CAPSビジネス・プロセスにこれらが存在する場合、パートナ・リンクは、移行後のBPELではプレースホルダとして含まれます。移行後に、パートナ・リンクを再作成して構成する必要があります。
標準フォルト: これには、forcedTermination、repeatedCompensationおよびinvalidReplyがあります。
パートナ: パートナは複数のpartnerLink要素をグループ化しますが、パートナの概念には実行可能なプロパティがなかったため、BPEL 2.0からパートナは削除されました。
移行ツールでは、ファイル、JMSおよびWebサービスのアダプタと、メッセージ可能OTDがサポートされていますが、これらのコンポーネントの移行を完了するには、手動による手順が必要です。
JMSアダプタの場合は、Oracle WebLogic Server管理コンソールで、新しい宛先を作成する必要があり、JMSアダプタ構成で指定されている名前と一致するようにします。アダプタ構成ウィザードを使用して、JMSアダプタの構成を確認してください。JMS宛先の作成の詳細は、4.7項「JMSリソースの作成」を参照してください。
次に、移行後のJBIプロジェクトに対して必要になる可能性がある更新をいくつか示します。
また、4.2.1項「移行後のバインディング・コンポーネントの構成」および4.2.1.1項「JMSアダプタの変更」の説明に従って、移行後のアダプタ構成を確認する必要があります。また、4.2.2項「サービス要素の追加」の情報は、Oracle Java CAPSリポジトリ・プロジェクトにも適用されます。
Oracle Java CAPS Migration Toolでは、すべてのファイルおよびJMSのインバウンドおよびアウトバウンド・アダプタは、Oracle SOA Suiteのファイル・アダプタおよびJMSアダプタを使用するように変換されます。変換後のJMSおよびファイルのアダプタは、それらが対応するWSDLドキュメント内のewaytype:FileTextMessageおよびewaytype:MessageのXMLスキーマ・タイプを使用するように構成されます。WSDLドキュメントはコンポジット内の移行後のアダプタ接続によってインポートされるため、これらのファイルへの変更は、そのアダプタのすべての接続に影響を及ぼします。
定義されるewaytypeは要素タイプであるため、入力メッセージは、例4-2に示すようにXMLタグで囲む必要があります。Oracle SOA Suiteでは、常に、opaqueとして定義されていないファイルおよびJMSのエンドポイントに対する入力メッセージとして、XML要素が必要です。変換後のWSDLドキュメントでは、デフォルトで、メッセージ・パートが文字列の要素として定義されます。
例4-2
<?xml version="1.0" encoding="UTF-8" ?>
<FileTextMessage xmlns=" http://xml.netbeans.org/schema/eWayTypes " >
<<Actual messagse input>>
</FileTextMessage>
WSDLドキュメントを変更して、Oracle SOA Suiteの入力のメッセージ・パートをewaytypeの要素タイプからopaqueの要素タイプに変換できます。メッセージ・パートがopaqueに変換されると、Oracle SOA Suiteアダプタでは、メッセージはBase64エンコード形式の文字列として処理されます。opaqueのメッセージ・タイプを使用すると、Oracle Java CAPSアダプタと同様に、入力および出力メッセージを単純な文字列にすることができます。
メッセージ・タイプをopaqueとして有効にする手順は、次のとおりです。
変換後のプロジェクトをOracle JDeveloperで開き、変更するWSDLドキュメントを開きます。
WSDLドキュメント内のmessage要素までスクロールします。
次に、typesおよびmessage要素の抜粋を示します。コメントのセクションで、要素をopaqueとして定義する方法を説明しています。
<types>
<schema targetNamespace="http://xml.netbeans.org/schema/eWayTypes"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="Message" type="string"/>
</schema>
<schema targetNamespace="http://xmlns.oracle.com/pcbpel/adapter/opaque/"
xmlns="http://www.w3.org/2001/XMLSchema">
<element name="Message" type="base64Binary"/>
</schema>
</types>
<message name="Message">
<part name="Message" element="ewaytype:Message"/>
<!-- This is an opaque message type, comment out Message part defined above
and uncomment following Message part to use opaque message type
<part name="Message" element="opaque:Message"/>
-->
</message>
メッセージ・タイプをopaqueに変更するために、説明コメントの直前の行をコメント・アウトし、<part name="Message" element="opaque:Message"/>のコメント・アウトを外します。
入力の文字列メッセージの使用や、出力メッセージの書込みまたは送信を行う前に、opaqueのメッセージ・タイプの場合は、次の手順を実行します。
oracle.soa.common.util.Base64Decoder.decode()メソッドを使用してBase64エンコード形式の入力をデコードして、文字列メッセージを取得します。
oracle.soa.common.util.Base64Encoder.encode()メソッドを使用して、出力メッセージをBase64文字列に変換します。
opaqueのメッセージ・タイプに対して、次のいずれかを行います。
OTDUtil.otdOperationメソッドを使用してopaqueのメッセージをマーシャルまたはアンマーシャルする場合は、次に示すように、最後のパラメータをtrueに設定します。
OTDUtil.otdOperation(otdClass,"marshalToString",inputelem,"text",true);
OTDUtil.otdOperationメソッドを使用しない場合は、ビジネス・プロセスまたはSpring出力でメッセージを使用する前に、エンコード・メソッドまたはデコード・メソッドをコールしてメッセージを変換するロジックを追加する必要があります。
|
注意: OTDUtil.otdOperationの最後のパラメータをtrueに設定すると、使用されるOTD操作に応じて、次の処理が実行されます。
メッセージがBase64にエンコードされずにアウトバウンド・アダプタが呼び出された場合、Oracle SOA Suiteアダプタは予想どおりに動作しない可能性があります。 |
インバウンドおよびアウトバウンドに同じXSDおよびFCX OTDを持つJCDが含まれるプロジェクトを移行する場合は、次に示すように、JAX-WSホルダーから値を取得する必要があります。このタイプの実装の場合に生成されるJAX-WSプロキシでは、JAXBオブジェクトをカプセル化するJAX-WSホルダーが作成されます。
public void test(Holder<org.netbeans.xml.schema.synchronous.TypeA> input,
Holder<org.netbeans.xml.schema.synchronous.TypeA> output) throws Throwable {
//output.setTypeA(input.getTypeA()); ? Replace this line
output.value = input.value; ? Retrieve the value from the input Holder to output.
移行ツールは、ビジネス・プロセスまたはJCD内にFCX OTDを持つリポジトリ・プロジェクトの移行を自動化します。サポートされるモデルは次のとおりです。
マーシャルおよびアンマーシャル・アクティビティを実行するFCX OTDを持つビジネス・プロセス。
インバウンドとアウトバウンドの両方としてFCX OTDを持つJCDを呼び出すビジネス・プロセス。
リクエスト・タイプおよびリプライ・タイプとしてFCX OTDを持ち、Webサービスとして公開されているスタンドアロンのJCD。
前述の場合、移行ツールは、XMLBeanに基づくFCX OTDをJAXBオブジェクトに置換することによって変換します。Oracle Java CAPSプロジェクトのFCX OTD内のマッピングは、JAXBオブジェクト内に保持されます。
Oracle Java CAPSプロジェクトに含まれるJCDのFCX OTDが他のOTDとして使用されている場合は、移行ツールでは、OTDをJAXBオブジェクトに変換しません。他のOTDとして使用されているFCX OTDをJAXBに変換するには、-xsd2jaxbオプションを使用します。
|
注意: これらの手順を実行しない場合、変換後のOracle SOA Suiteプロジェクトのビルドおよびデプロイでエラーは発生しませんが、XMLBeanの競合により、実行時にエラーが発生します。 |
他のOTDとして使用されているFCX OTDを更新する手順は、次のとおりです。
3.2項「Oracle Java CAPSプロジェクトの移行」の説明に従って、プロジェクトのEARファイルに対して移行ツールを実行します。
変換後のJavaコードにナビゲートすると、他のOTDとして使用されているFCX OTDはOTDのまま残され、JAXBに変換されていないことを確認できます。
-xsd2jaxbオプションを使用して移行ツールを実行し、FCX OTDをJAXBオブジェクトに変換します。
これは、3.4項「XSDからJAXB形式への変換」で説明しています。
変換後のJCDコード内のFCX OTDを、変換後のJavaコード内の生成されたJAXBオブジェクトに置換します。
移行ツールによって、JMS、ファイルおよびWebサービスのOTDのコードは自動的に生成されますが、一部のアダプタは移行ツールで処理されないため、手動でプロジェクトに追加する必要があります。移行ツールにより、ビジネス・プロセス・プロジェクト内にこれらのエンドポイントのプレースホルダが生成され、プレースホルダを対応するOracle SOA Suiteアダプタに置換する必要があります。
|
注意: これらの手順は、Oracle JDeveloperで移行後のプロジェクトに未変換のアダプタを追加する際に変更が必要なSpring BeanのJavaクラス・ファイルにもパブリッシュされます。 |
未変換のアダプタをSpringに追加する手順は、次のとおりです。
Oracle JDeveloperで、移行後のOracle SOA Suiteプロジェクトを開き、関連するcomposite.xmlファイルを開きます。
コンポーネント・パレットで、移行されなかったアダプタに相当するOracle SOA Suiteアダプタを探し、それをサービスまたは参照のスイムレーンまでドラッグします。
構成ウィザードの手順に従って、アダプタを構成します。
該当するJCD (つまり、元のOracle Java CAPSプロジェクト内の移行されなかったアダプタに接続されていたJCD)に対応して生成されたSpringコンポーネントに、新しいアダプタを接続します。
アプリケーション・ナビゲータで、「アプリケーション・ソース」を開き、先ほど接続したSpringコンポーネントのJavaクラスを探します。
Spring BeanのJavaクラスのパッケージおよびクラス名は、Spring XMLファイルのbean要素で確認できます。次に例を示します。
<bean name="Consume_Message_ptt" class="CAPSJCDProj_JMSInFileJMSOut.Collaboration_JMSIn">
Javaクラス・ファイルを開いて、前述の新しいアダプタを接続したときに生成されたアダプタ・インタフェース・クラスの型のグローバル・フィールドを追加します。そのフィールドのアクセッサ・メソッドを作成します。
確認を行い、Javaファイルを保存して閉じます。
composite.xmlで、Springコンポーネントを右クリックして「編集」を選択します。
Oracle JDeveloperエディタで、Spring XMLファイルが開かれます。
Spring XMLファイルで、アダプタとSpringコンポーネントを接続したときに生成されたアダプタ参照を探します。Springクラスのbean要素に、前の手順で作成したグローバル・フィールドを追加し、そのプロパティからアダプタ参照を参照します。
|
注意: 前の手順で作成したグローバル・アダプタ・フィールドは、実行時に自動的にインスタンス化されます。それは、すでにインスタンス化されているかのように使用できます。 |
例4-3 移行されなかったアダプタの追加
前述の例として、次の条件でデータベース・アダプタを移行後のプロジェクトに追加します。
前述の手順6で、Javaクラスに追加されたグローバル・フィールドは、次の文で特定されます。
private xe.projectname.db.adapter.pcbpel.com.oracle.xmlns.XE_ptt database;
アダプタをSpringコンポーネントに接続すると、Spring XMLファイルに次の参照が生成されます。
<reference type="xe.projectname.db.adapter.pcbpel.com.oracle.xmlns.XE_ptt"
name="XE" xmlns="http://xmlns.oracle.com/weblogic/weblogic-sca" />
次のプロパティをSpring XMLファイルに追加する必要があります。
<property name="database" ref="XE" />
移行ツールによって元のJCDコードから生成されたSpring BeanのJavaクラスでは、アウトバウンドのファイル・アダプタまたはJMSアダプタの変更と、JCDがサブコラボレーションを呼び出している場合はプロジェクトの変更が必要です。次の手順を実行して、Javaクラスを構成します。
JMSヘッダー・プロパティにアクセスする必要がある場合は、4.4.4項「JMSヘッダー・プロパティへのアクセス」の手順に従います。
元のJava CAPSプロジェクトのJCDでサブコラボレーションを呼び出している場合は、4.4.5項「Javaコラボレーション定義から呼び出されるサブコラボレーションの構成」の手順に従います。
この項に記載されている特別なケースにプロジェクトが該当するかどうかにかかわらず、元のJCDロジックが含まれる移行後のJavaクラスを確認することは重要です。このクラスに含まれるコメントおよびノートでは、ユーザー固有のJCDを実装する場合に必要になる可能性がある変更についての詳細な情報が提供されます。
Spring BeanのJavaクラスを変更する手順は、次のとおりです。
Oracle JDeveloperで、SpringコンポーネントXMLファイルを開きます。
Beanクラスの名前が含まれるbean要素を探して、パッケージ名およびクラス名をメモします。要素は次のようなものです。
<bean name="Consume_Message_ptt" class="CAPSJCDProj_JMSInFileJMSOut.Collaboration_JMSIn"
Oracle JDeveloperの左側のナビゲーション・パネルで、「アプリケーション・ソース」を開き、bean要素で指定されているパッケージを開きます。
bean要素で指定されている名前のJavaクラス・ファイルを開きます。
コードを確認し、移行ツールによって生成されたコメントを探します。これらの前には、***Migration Tool***のテキストが付いているため、ファイル内で簡単に見つかります。
変更が完了したら、ファイルを保存して閉じます。
デフォルトでは、Oracle SOA Suiteは、インバウンドのJMSアダプタおよびファイル・アダプタの入力メッセージをByte型のメッセージとして受信します。Oracle Java CAPSプロジェクトでは、入力がString型のメッセージである可能性があります。この場合は、生成されたコード内でバイト配列を文字列に変換する必要があります。
バイト入力配列を文字列に変換する手順は、次のとおりです。
4.4.1項「Spring BeanのJavaクラスの変更」の説明に従って、Spring Beanクラスを探して開きます。
Spring BeanのJavaクラス・ファイルで、入力がテキストであるかどうかを確認します。次に例を示します。
public void receive(com.stc.connectors.jms.Message input,
com.stc.connector.appconn.file.FileApplication FileClient_1,
com.stc.connectors.jms.JMS JMS_1) throws Throwable {
String in = input.getTextMessage();
...
元のJCDがTextMessageをファイル・アダプタの入力として受信している場合は、次に示すように、byte[]をStringに変換します。
String in = new String(input.getBytesMessage());
元のJCDがTextMessageをJMSアダプタの入力として受信している場合は、次に示すように、consumeMessageメソッドのコードにTextMessageを設定します。
public void consumeMessage(byte opaque[]) {
com.stc.connectors.jms.Message input = new
com.stc.connectors.jms.impl.MessageImpl();
//input.setBytesMessage(opaque);
input.setTextMessage(new String(input.getBytesMessage()));
このファイルを保存して閉じます。
変換後のアウトバウンドのファイル・アダプタおよびJMSアダプタについて、生成されたSpring BeanクラスでOracle Java CAPSのファイルまたはJMSのアウトバウンド参照を使用しているすべてのコードを探し、それをSpring Bean参照を使用したOracle SOA Suiteの呼出しに置換します。
ファイルまたはJMSのアウトバウンド・アダプタのSpring Beanクラスを構成する手順は、次のとおりです。
4.4.1項「Spring BeanのJavaクラスの変更」の説明に従って、Spring Beanクラスを探して開きます。
Spring XMLファイルを開いて、Beanプロパティを探します。次に例を示します。
<bean name="Consume_Message_ptt" class="CAPSJCDProj_JMSInFileJMSOut.Collaboration_JMSIn">
<property name="JMSOUT_Collaboration_JMSIn_JMS_1"
ref="JMSOUT_Collaboration_JMSIn_JMS_1"/>
<property name="FILEOUT_Collaboration_JMSIn_FileClient_1"
ref="FILEOUT_Collaboration_JMSIn_FileClient_1"/>
<property name="collabContext" ref="collabCtxBean"/>
....
|
注意: 前述のコードは、見やすくするために行を折り返しています。 |
アウトバウンド・アダプタのプロパティ名をメモします。
Spring BeanのJavaクラス・ファイルで、メソッドのパラメータとして使用されているJava CAPSアウトバウンドのファイル・アダプタおよびJMSアダプタを表すすべての変数を探します。次に例を示します。
public void receive(com.stc.connectors.jms.Message input,
com.stc.connector.appconn.file.FileApplication FileClient_1,
com.stc.connectors.jms.JMS JMS_1) throws Throwable {
String in = new String(input.getBytesMessage());
System.out.println("@@ Input message " + in);
System.out.println("@@ Sending text message to File " + in);
FileClient_1.setText(in);
FileClient_1.write();
System.out.println("@@ Sending text message to JMS " + in);
JMS_1.sendText(in);
}
Java CAPSアダプタ参照を、Spring XMLファイルからのOracle SOA SuiteアダプタのSpring Beanプロパティに置換します。次に例を示します。
String in = new String(input.getBytesMessage());
System.out.println("@@ Input message " + in);
System.out.println("@@ Sending text message to File " + in);
this.FILEOUT_Collaboration_JMSIn_FileClient_1.write(in.getBytes());
System.out.println("@@ Sending text message to JMS " + in);
this.JMSOUT_Collaboration_JMSIn_JMS_1.produceMessage(in.getBytes());
このファイルを保存して閉じます。
Oracle Java CAPSではJMSメッセージがサポートされており、JMSメッセージはペイロードと一緒にJMSヘッダーをカプセル化します。Oracle SOA Suiteでは、JMSヘッダーとペイロードは1つのオブジェクト内で関連付けられていませんが、コードを定義してヘッダー・プロパティにアクセスできます。
|
注意: これは、Oracle SOA Suite 11.1.1.6.0以降でのみサポートされています。 |
SpringコンポーネントからJMSヘッダー・プロパティにアクセスする手順は、次のとおりです。
Oracle JDeveloperで、変更する必要があるSpringコンテキストを開きます。
適切なbean要素のSpringコンテキストに次のプロパティを追加します。
<property name="headerHelper" ref="headerHelperBean"/>
エディタで、プロパティを追加したSpring Beanのクラス・ファイルを開き、次の手順を実行します。
IHeaderHelperBeanヘルパー・クラスのimport文を追加します。
import oracle.soa.platform.component.spring.beans.IHeaderHelperBean;
headerHelperという名前(Springコンテキスト・ファイルで使用されている名前)の変数を宣言します。
private IHeaderHelperBean headerHelper;
BeanクラスでheaderHelper変数のgetterおよびsetterメソッドを定義します。
ヘッダー・ヘルパーBeanからgetおよびsetプロパティを使用します。すべてのカスタム・プロパティで、jca.jms.JMSProperty.<PROPERTY_NAME>の接頭辞を使用します。
headerHelper.setHeaderProperty("jca.jms.JMSDestinationName", "queue_TMHException");
Oracle Java CAPSプロジェクトに含まれるメインのJavaコラボレーション定義(JCD)で別のJCD (サブコラボレーションと呼びます)を呼び出している場合、そのモデルは完全には移行されません。JCDのコードは両方とも、生成されるOracle SOA Suiteプロジェクトに変換されるため、手動でプロジェクトを更新して移行を完了できます。
メインJCDのみ、Spring Beanクラスに変換されます。サブコラボレーションには、手動による変換とメインJCDへのワイヤリングが必要です。
サブコラボレーションを移行する手順は、次のとおりです。
Javaインタフェースを作成し、サブコラボレーションのメソッド定義(つまり、メインの操作)を追加します。
新しいインタフェースを実装するようにサブコラボレーションを更新します。
サブコラボレーションのSpringコンポーネントXMLファイルで、サービス・ノードおよびBeanノードを追加する変更を行います。サービス・ノード・タイプのインタフェースを参照し、Beanノード・クラスのサブコラボレーションのBeanクラスを参照します。
メインJCDのSpringコンポーネントXMLファイルで、そのタイプの参照ノードを前の手順で作成したJavaインタフェースとして追加する変更を行います。
Beanプロパティを追加し、ref属性にサブコラボレーションの参照ノードを設定します。
メインJCDのSpringコンポーネントXMLファイルに追加したBeanプロパティ名と同じ名前のクラス変数を作成します。
メインJCDのBeanクラスで、前の手順で定義したBeanプロパティのgetterおよびsetterメソッドを定義します。
前述の変更を行うと、Oracle SOA Suiteプロジェクトのcomposite.xmlファイルで、メインJCDとサブコラボレーションの両方のSpringコンポーネントで新しいエンドポイントが公開されます。
2つのエンドポイントを接続することで、メインJCDのSpringコンポーネントをサブコラボレーションのSpringコンポーネントにワイヤリングします。
メインJCDのSpringコンポーネントXMLファイルで、サブコラボレーションを呼び出すJCDへの参照をサブコラボレーションのSpring Bean参照に置換する変更を行います。
プロジェクトを保存します。
次に、ビジネス・プロセスを持つリポジトリ・プロジェクトを移行する場合に必要になる可能性がある更新をいくつか示します。
移行ツールでは、ユーザー・アクティビティ(Worklist Manager)を持つビジネス・プロセスは移行できません。元のビジネス・プロセスには、Oracle Java CAPS固有のBPELコンストラクトが含まれるため、それらを手動でOracle SOA Suiteのヒューマン・ワークフロー・サービスに置換する必要があります。Oracle SOA Suiteヒューマン・ワークフロー・サービスの使用の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』の「ヒューマン・ワークフローの開始」を参照してください。
ビジネス・プロセスのマーシャルおよびアンマーシャル(Invoke)アクティビティで相関を初期化している場合、マーシャルおよびアンマーシャル・アクティビティは埋込みJavaアクティビティに置換されるため、移行後のビジネス・プロセスではこの初期化は無視されます。
これを解決するには、この状態のプロジェクトを移行する前に、相関の初期化ロジックをマーシャルおよびアンマーシャル・アクティビティの外に移動します。次の手順を実行して、WSDLドキュメント内の相関プロパティの別名定義を、messagetype属性ではなく、要素の属性に置換します。
messageType属性をそれに対応する要素の属性に変更します
propertyAlias定義のpart属性を削除します
次に、必要な変更を行う前と後のコードの例を示します。
<message name="ReserveVehicleIn"> <part name="itinerary" element="ota:TravelItinerary"/> </message> <bpws:propertyAlias propertyName="tres:ItineraryRefId" messageType="vres:ReserveVehicleIn" part="itinerary"> <bpws:query>/ota:TravelItinerary/ota:ItineraryRef/ota:UniqueID</bpws:query> </bpws:propertyAlias>
propertyAlias定義を次のように変更します。
<bpws:propertyAlias propertyName="tres:ItineraryRefId" element="ota:TravelItinerary"> <bpws:query>/ota:TravelItinerary/ota:ItineraryRef/ota:UniqueID</bpws:query> </bpws:propertyAlias>
JCDが含まれるリポジトリ・プロジェクトでは、Oracle Java CAPS固有の追加JARファイルが使用されている場合があります。これらのファイルは、移行後のOracle SOA Suiteプロジェクトでも必要で、生成されたプロジェクトの/SCA-INF/libディレクトリに追加されます(それらは、ソースのEARファイルにパッケージされているためです)。JARファイルのほとんどは、移行ツールによって自動的にJDeveloperプロジェクト・ファイルに追加されます。プロジェクトに追加する必要がある追加のJARファイルが存在する場合は、Oracle JDeveloperにロードできます。
移行後のプロジェクトにJARファイルを追加する手順は、次のとおりです。
移行後のプロジェクトをOracle JDeveloperで開きます。
アプリケーション・ナビゲータで、プロジェクト名を右クリックして、「プロジェクト・プロパティ」を選択します。
プロジェクト・プロパティ・エディタが表示されます。
左側のナビゲーション・ペインで、「ライブラリとクラスパス」を選択します。
「ライブラリとクラスパス」ページが表示されます。
「JAR/ディレクトリの追加」をクリックします。
追加するJARファイルを参照して選択し、「選択」をクリックします。
JARファイルが「クラスパス・エントリ」リストに追加されます。
別のJARファイルをさらに追加する場合は、前の2つの手順を繰り返します。
JMSリソースを作成するために必要な手順は、メッセージ・プロバイダとしてOracle WebLogic JMSを使用しているか、サードパーティのメッセージ・プロバイダを使用しているかによって異なります。既存のJMSモジュールおよびサービスを使用したり、必要な場合は新しいものを追加できます。WebLogic以外のJMSサーバーを使用している場合は、外部サーバーを作成して構成し、新しいサーバーに接続ファクトリを追加する必要がある場合があります。
次に、JMSモジュールに宛先を追加する一般的な手順を示します。Oracle WebLogic Server管理コンソールを使用してJMSリソースを作成する方法の詳細と手順については、『Oracle Fusion Middleware Oracle WebLogic Server JMSの構成と管理』を参照してください。
JMSモジュールに宛先を追加する手順は、次のとおりです。
Webブラウザで、Oracle WebLogic Server管理コンソールを起動します。
http://hostname:port_number/console
「サービス」の下の「JMSモジュール」を選択します。
「JMSモジュール」ページが表示されます。
「JMSモジュール」表で、宛先を追加するモジュールを選択します。
選択したモジュールの「設定」ページが表示されます。
「リソースのサマリー」表で、「新規」をクリックします。
「新しいJMSシステム・モジュール・リソースの作成」ページが表示されます。
「キュー」または「トピック」を選択し、「次へ」をクリックします。
「名前」フィールドに、このトピックまたはキューの名前を入力します。これは、Oracle WebLogic Serverで参照される論理名です。
「JNDI名」フィールドに、この宛先を参照するためにアプリケーションで使用するローカルJNDI名を入力します
「次へ」をクリックします。
サブデプロイメントを宛先で使用するには、次の手順を実行します。
「サブデプロイメント」フィールドから既存のサブデプロイメントを選択するか、「新しいサブデプロイメントの作成」をクリックして新しいものを作成します。
サブデプロイメントのターゲット・サーバーを選択します。
「終了」をクリックします。
新しい宛先が「リソースのサマリー」表に追加されます。
これらの変更を有効にするには、管理コンソールの「チェンジ・センター」で「変更のアクティブ化」をクリックします。
サーバーを再起動します。
