| Oracle Application Serverリリース・ノートおよび新機能 10gリリース3（10.1.3.5.1） B57229-01 |
|
 戻る |
 次へ |
この章では、Oracle BPEL Process Managerに関連する問題について説明します。内容は次のとおりです。
この項では、次の問題と回避方法について説明します。
電子メールの添付ファイルを使用した10.1.3.4のサンプルを10.1.3.5に移行する場合、.bpelファイルに次のコピー・ルールが記載されています。このサンプルをOracle BPEL Serverにそのままデプロイすると、電子メールの本文は添付ファイルとしてのみ表示され、インライン・メッセージとしては表示されません。そのため、このコピー・ルールを手動で削除する必要があります。
<copy>
<from expression="string('NotificationAttachment1.html')"/>
<to variable="varNotificationReq" part="EmailPayload"
query="/EmailPayload/ns1:Content/ns1:ContentBody/ns1:MultiPart/
ns1:BodyPart[2]
/ns1:BodyPartName"/>
</copy>
10.1.3.5パッチを既存のOracle SOA Suite 10.1.3.1/10.1.3.3/10.1.3.4インストールに適用すると、log4j-config.xmlファイルの通知用エントリがなくなる場合があります。
回避方法として、通知ロガーのエントリを手動で追加する必要があります。次に例を示します。
<logger name="default.collaxa.bpel.services.notification" additivity="false"> <level value="INFO" /> <appender-ref ref="A1" /> <appender-ref ref="A2" /> </logger>
defaultはドメイン名です。
この項では、次の問題と回避方法について説明します。
5.2.1項「WSDLファイルのサービス・エンドポイント名の変更がOracle JDeveloperでサポートされない」
5.2.4項「Xpath関数getFaultNameおよびgetFaultAsStringをcatchブランチで使用可能」
BPELプロジェクトのWSDLファイル内に定義されているサービス・エンドポイントの名前の変更は、現在のところOracle JDeveloperではサポートされていません。ただし、Oracle JDeveloperの「名前の変更」ダイアログを使用することにより、BPELプロジェクトとすべてのアーティファクト（BPEL、XSD、XMLおよびWSDLファイル）の名前を変更できます。さらに、これらのアーティファクトへの参照はすべて自動的に更新されます。このダイアログを表示させるには、「アプリケーション・ナビゲータ」でBPELプロジェクトを選択し、次に「ファイル」メイン・メニューから「名前の変更」を選択します。
BPELプロセスのアーカイブとそのコンポーネントをコンパイルしてBPELスーツケースJARファイルにパッケージ化する場合は、すべてのXSDおよびWSDLファイルをbpelフォルダに置く必要があります。
bpelフォルダ以外の場所でインポートされたXSDおよびWSDLファイルを使用する場合は、その共有ファイルが次のどちらかに該当することを確認する必要があります。
JARファイルのbpelフォルダに置かれています。
デプロイ済のBPELプロセスのbpelフォルダにあるデプロイ済のサーバーで使用可能です。
どちらにも該当しない場合は、Oracle BPEL Controlからプロセスを開始すると、次のようなエラー・メッセージが表示されます。
"java.io.IOException: WSDLException: ...../public_html/CommonCustomer.xsd:WSDL not found"
Securityヘッダーに値を渡すには、次の手順を実行します。
スキーマ・ファイルをインポートします。
http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0
インポートされたスキーマに基づいて、次の3つの変数を作成します。
<variable name="securityContext" element="ns2:Security"/> <variable name="userNameToken" element="ns2:UsernameToken"/> <variable name="pswd" element="ns2:Password"/>
これらの新規作成された変数に値をコピーします。
ユーザー名の後にパスワードを挿入します（assignアクティビティで実行）。
セキュリティ・コンテキストのヘッダー変数にユーザー名を付加します（assignアクティビティで実行）。
これで、assignアクティビティは次のようになります。
<assign>
<copy>
<from variable="inputVariable" part="payload"
query="/client:SampleRequest/client:pswd"/>
<to variable="pswd" query="/wsse:Password"/>
</copy>
<copy>
<from variable="inputVariable" part="payload"
query="/client:SampleRequest/client:user"/>
<to variable="userNameToken"
query="/wsse:UsernameToken/wsse:Username"/>
</copy>
<bpelx:insertAfter>
<bpelx:from variable="pswd" query="/wsse:Password"/>
<bpelx:to variable="userNameToken"
query="/wsse:UsernameToken/wsse:Username"/>
</bpelx:insertAfter>
<bpelx:append>
<bpelx:from variable="userNameToken" query="/wsse:UsernameToken"/>
<bpelx:to variable="securityContext" query="/wsse:Security"/>
</bpelx:append>
</assign>
パートナ・リンク・アクティビティを開きます。
「プロパティ」タブをクリックします。
「追加」ボタンをクリックします。
「wsseheaders」を選択し、それを「propagate」の値に割り当てます。
BPELプロセスの設計を完了します。
BPELプロセスをデプロイしてテストします。
XPath関数のgetFaultNameおよびgetFaultAsStringをcatchブランチで使用できるようになりました。以前のリリースでは、これらはcatchAllブランチでのみ動作していました。
この項では、次の問題と回避方法について説明します。
WSIF antツールでは、EJB 3.0ベースのJAR用のWSDL生成はサポートされていません。
Bean定義のantタスクは空白を含むディレクトリ・パス（たとえば、c:\Document and Settings\jsmith）では動作しません。
たとえば、build.xmlファイルに次のエントリが含まれるとします。
<property name="beanDefinitionLocation" value="C:\Documents and Settings\jsmith\Desktop\EJB_test\DataBindingTestEJB\deploy" />
このファイルを使用するantタスクは、次のようなメッセージを出力して失敗します。
cannot find file "C:\Documents"
java.util.concurrent.ConcurrentMapコレクション・クラスは、10.1.3 JAX RPCでサポートされていないタイプです。回避方法として、メソッド・シグネチャでjava.util.Mapを使用します。
JDK 1.5の列挙は、10.1.3 JAX RPCではサポートされていません。
BeanプロパティとしてのThrowableクラスは、JAX RPCではサポートされていません。たとえば、次のコードは無効です。
/**
* Returns the cause.
* @return Throwable
*/
public Throwable getCause()
{
return cause;
}
/**
* Sets the cause.
* @param cause The cause to set
*/
public void setCause(Throwable cause)
{
this.cause = cause;
}
この項では、次の問題と回避方法について説明します。
.task ファイルを右クリックして「単純タスク・フォームの自動生成」を選択しないでください。この操作を行うと、空のpayload-body.jspファイルが作成されます。プロジェクト・フォルダを右クリックして「単純タスク・フォームの自動生成」を選択しても、同じエラーになります。
そのかわりに、『Oracle BPEL Process Manager開発者ガイド』に記載しているように、プロジェクト・フォルダを右クリックして「単純タスク・フォームの自動生成」を選択してフォームを生成します。
空のpayload-body.jspファイルを受け取ったら、次の手順を実行してファイルを削除します。
ヒューマン・タスク・フォルダを右クリックします。
「タスク・フォーム・ファイルの削除」を選択します。
新しいタスク・フォームを生成します。
アクション可能な電子メールから操作を行っても、添付ファイルを追加できません。たとえば、アクション可能な電子メールの返信メッセージに添付ファイルを追加すると、そのタスクは承認されません。
回避方法として、添付ファイルをOracle BPELワークリスト・アプリケーションから追加します。
タスクが1人の無効なユーザーに割り当てられ、そのタスクに対してエラー割当て先が定義されていない場合、タスクは直接ERRORED状態になります。さらに、タスク設定でエラー状態の受信者を設定している場合でも、エラー通知は送信されません。
この問題は次のどちらかの状況では発生しません。
エラー割当て先が定義されています。
無効なユーザーが最初の割当て先ではありません。
ヒューマン・タスクのスコープに対して行ったカスタマイズは、ヒューマン・タスクのスコープが再生成されないかぎり保持されます。ヒューマン・タスク・アクティビティの「詳細」タブで次の2つのチェック・ボックスの選択を変更すると、スコープが再生成されます。
BPELコールバックのタスクとルーティング・カスタマイズを許可
タスク履歴の追加元
Active Directory構成を使用するには、$SOA_HOME/bpel/system/services/config/ldap/is_config.ActiveDirectory.xmlファイルの<userControls>セクションに<property name=”nicknameAttribute” value=”sAMAccountName”/>を追加する必要があります。
<?xml version = '1.0' encoding = 'UTF-8'?>
<ISConfiguration
xmlns="http://www.oracle.com/pcbpel/identityservice/isconfig" >
<configurations>
<!-- Active Directory EXAMPLE -->
<configuration>
<provider providerType="LDAP" name="Active Directory" >
<connection url="ldap://host:port"
binddn="cn=administrator,cn=Users,DC=us,DC=oracle,DC=com"
password="CHANGE_ME" encrypted="false">
<pool initsize="2" maxsize="25" prefsize="10" timeout="60"/>
</connection>
<userControls>
<property name="nameattribute" value="cn"/>
<property name="objectclass" value="user"/>
<property name="nicknameAttribute" value="sAMAccountName"/>
<search searchbase="cn=Users,DC=us,DC=oracle,DC=com"
maxSizeLimit="1000" maxTimeLimit="120" scope="subtree" />
</userControls>
<roleControls>
<property name="nameattribute" value="cn"/>
<property name="objectclass" value="group"/>
<property name="membershipsearchscope" value="onelevel"/>
<property name="memberattribute" value="member"/>
<search searchbase="cn=Users,DC=us,DC=oracle,DC=com"
maxSizeLimit="1000" maxTimeLimit="120" scope="onelevel" />
</roleControls>
</provider>
</configuration>
</configurations>
</ISConfiguration>
この項では、次の問題と回避方法について説明します。
再帰的ノードを含むスキーマを自動マップする場合、再帰的ノードが存在し、それが特定のレベルを超えたところまで展開されていないことを示す警告メッセージは表示されません。これらの展開されていないノードはマップされません。
このような状況では、スキーマを目的の深さに手動でマップする必要があります。
マップ生成タイプをREQ（<mapGenType type="REQ"/>）に設定すると、必要なノードすべてを生成するよう指定したことになります。マッパーは存在しないノードに対しても空の必要なノードを作成しようとします。XSDに必要な再帰的要素がある場合、XSDに従ってドキュメントが生成されるとドキュメントは膨大な量になります。
再帰的スキーマを解決するときには、XMLスキーマ拡張の深さは適用されません。たとえば、次の手順を実行します。
「ツール」メイン・メニューから、「プリファレンス」→「XSLマップ」を選択します。
「拡張の深さ」フィールドで、大きい値（たとえば20）を入力します。
「繰返し要素の数」フィールドに20を入力します。
「最大の深さ」フィールドに20を入力します。
再帰的スキーマをソースからターゲットにマップします。
ソースのルート・ノードを右クリックし、「すべて開く」を選択します。スキーマをデフォルトのレベル（6ノード）のみになるまで拡張します。
「設計」ビューでXSLマップを閉じてから開きなおします。デフォルトのレベルのみが表示されます。
Oracle JDeveloperを再起動します。デフォルトのレベルのみが表示されます。
スキーマを10レベルまで手動で拡張し、ソースからターゲットのルート・ノードに自動マップします。
マップを右クリックして、スキーマをテストします。手順3で繰返し要素の数を20に設定したにもかかわらず、ソースXMLは20レベルまでは生成されていません。
XSLファイル内のソースおよびターゲット・ファイルがリモートのXSDファイル（たとえば、ネットワーク上で使用可能なXSD）である場合、XSLはソースおよびターゲットを認識しません。
回避方法として、リモートのXSDをインポートする場合は、「プロジェクトにコピー」チェック・ボックスを選択して、プロジェクト内にXSDファイルのローカル・コピーを作成します。
XSLTマッパーの「XSLマップのテスト」ダイアログでターゲットXMLファイルを生成する場合、ターゲットXMLファイルは正しく生成されます。ただし、ターゲットXMLファイルにより、選択要素のセットからなくなった要素でマップされていないものがあることを示す間違ったエラー・メッセージが表示されます。このメッセージは無視してかまいません。
XSLサンプル拡張関数を設計時に使用できるようにするには、SampleExtensionFunction.jarファイルを、READMEファイルに記載されているディレクトリ（jdev/extensions）ではなくjdev/lib/patchesディレクトリにコピーする必要があります。
この項では、次の問題と回避方法について説明します。
orabpelアプリケーションを次のようにして停止してから起動すると、プロセスはロードされません。
opmnctl stopproc application=orabpel opmnctl startproc application=orabpel
回避方法として、opmnctl startallおよびopmnctl stopallを使用します。つまり、orabpelアプリケーションを停止してから起動するには、すべてのJ2EEアプリケーションとOracle Enterprise Service Busを停止して起動しなおす必要があるということになります。
同じBPELプロセス・リビジョンをOracle JDeveloperから本番モードで実行しているOracle BPEL Serverに再デプロイすると（たとえば、HelloWorldリビジョン1.0をリビジョン1.0に再デプロイ）、Oracle Process Manager and Notification Server（OPMN）ログにエラーとして表示されます。これは予想どおりの動作です。
ただし、同じデプロイがOracle JDeveloperでは成功として表示されます。このメッセージは無視してかまいません。
BPELプロジェクトを右クリックし、「デプロイ」→「BPELプロセス・デプロイヤ」を選択すると、BPELプロセスを常に新しいリビジョンでデプロイできます。表示される「BPELプロセス・デプロイヤ」ダイアログには、異なるリビジョン値を入力するオプションがあります。このオプションはOracle BPEL Serverが本番モードでも開発モードでも使用可能です。
ただし、BPELプロジェクトを右クリックし、「デプロイ」→「server_connection_name」→「domain_name」を選択して迅速なデプロイを実行するよう選択した場合、サーバーを開発モードで実行している場合はプロセス・リビジョンが上書きされて再デプロイされます。
この項では、自動リカバリ・パラメータを使用環境に適した値にする推奨設定を提供します。どのようなシナリオでも、dspInvokeThreadsは40に設定できます。したがって、ディスパッチャ・レイヤーで呼出しメッセージを処理するために、最大40のスレッドが割り当てられます。これは十分な数であり、変更する必要はありません。たとえば、外部Webサービスのコールに対する応答に最大120秒かかり、インスタンスの作成に約5秒かかるとします。この場合、最大コール時間（Webサービス呼出しを含む）は少なくとも125秒になります。
最悪の場合のシナリオを考慮すると、subsequentTriggerDelayを約150〜200秒に変更する必要があります。これはインスタンスが起動とリカバリを複数回繰り返すのを避ける、より安全な方法です。subsequentTriggerDelayプロパティは連続する2つのカバリ試行間の遅延です。このプロパティの設定値を小さくしても、リカバリが速くなるわけではありません。リカバリするメッセージを遅延なく保留するには、maxMessageRaiseSizeパラメータをより大きい値（たとえば、40（dspInvokeThreads）以下の値）に変更します。この場合、リカバリ試行では少なくとも40個の起動インスタンス・メッセージをリカバリできます。この値を-1に設定して、最初のリカバリ試行ですべての保留メッセージを処理することもできます。
リカバリ処理中の新しいメッセージの到着を速くするには、startupRecoveryDurationを400秒にします。これにより、最低2回のリカバリ試行が確実に行われます。そのため、サーバー起動中にメッセージがリカバリを待つことはなくなります。1回のリカバリ試行の方が適切な場合は、startupRecoveryDurationの値を小さくします。これにより、一定時間待っているメッセージはリカバリされなくなります。これは、期待するサーバー起動中にリカバリされるメッセージ数によっても異なります。
Oracle SOA Suite 10.1.3.1をインストールします。インストール時に、oc4jadminにwelcome1以外の任意のパスワードを指定します。
パッチ・セット10.1.3.5を適用します。
antを使用して事前に構築されたサンプルのデプロイを試行します。デプロイは認証エラーで失敗します。
回避方法として、ant-orabpel.propertiesファイルにあるこのパスワードを手動で置き換えます。
デプロイ時に次のようなPermGenのメモリー不足エラーを受け取ることがあります。
. . . . . . <2009-06-17 08:39:55,845> <ERROR> <default.collaxa.cube.engine.deployment> java.lang.OutOfMemoryError: PermGen space <2009-06-17 08:40:41,030> <ERROR> <default.collaxa.cube.engine.deployment> <DeploymentManager::deploySuitcase> java.lang.OutOfMemoryError: PermGen space <2009-06-17 08:44:20,187> <ERROR> <default.collaxa.cube.engine.agents> <SimpleTrigger::executionComplete> Error while rescheduling agent java.lang.OutOfMemoryError: PermGen space . . . . . .
この問題は次のような状況で発生します。
多数のコンポーネントがインストールされています（たとえば、10.1.3 Oracle Application Server、10.1.3.1 Oracle BPEL Process Manager、10.1.3.1 Oracle Enterprise Service Bus、10.1.3.1 Oracle Web Services Manager、10.1.3.5パッチ・セットなど）。このインストールに多数のクラス定義が含まれており、そのすべてがPermGen領域に格納されています。
BPELプロセスが巨大です。
次の手順を実行して、PermGen領域を大きくします。
$ORACLE_HOME/opmn/conf/opmn.xmlファイル（UNIXの場合）またはORACLE_HOME\opmn\conf\opmn.xmlファイル（Windowsの場合）を開きます。
OC4JのPermGen値を変更します。
-Doc4j.formauth.redirect=true -XX:MaxPermSize=128M -Xms2048M -Xmx2048M
-Xmn1228M
多数のプロセスをデプロイする場合は、PermGen値を256Mに増やすこともあります。
Oracle BPEL Controlで失効したインスタンスにアクセスする場合、「監査」タブのみが有効になります。「フロー」タブは無効です。これはこのタブに必要なプロセス定義が、失効したインスタンスでは使用できないためです。
BPELプロセスのインスタンスを作成して呼び出しても、フォルトは取得されません。Oracle BPEL Controlで失敗したインスタンスをクリックすると、監査証跡により正しいペイロード情報とアクティビティが表示されますが、フローのトレースは空です。
これは予想どおりの動作です。フローのトレースにはインスタンス・データが必要です。フォルトが処理されていないため、インスタンスはロールバックされ、監査データのみが非同期で保存されます。
以前のリリースでOracle BPEL Controlの「管理」 タブの下に表示されていた「リカバリ」（アクティビティ）タブは使用できなくなりました。ただし、アクティビティ・リカバリの主要なケースはすべて、他のアクションを通して実行できます。
ReceiveおよびonMessageアクティビティは、コールバック・リカバリを通してリカバリできます。
WaitおよびonAlarmアクティビティは、アラーム表のリフレッシュを通してリカバリできます。
リカバリできないただ1つのケースは、bpelx:checkpointまたはdspMaxRequestDepthを使用している場合ですが、このシナリオは一般的には使用されません。
Oracle BPEL Controlのインスタンス追跡での最適化された割当てノードの縮小機能は、このリリースで削除されました。
この項では、次の問題と回避方法について説明します。
『Oracle BPEL Process Manager開発者ガイド』の第15章「Oracle BPEL Process Managerワークフロー・サービス」のヒューマン・タスク・アクティビティのカスタム結果の表示に関する項に、ヒューマン・タスク・アクティビティの切替えアクティビティでカスタム結果を表示する方法に関する記述があります。
タスク結果がカスタムか事前定義されたものか（APPROVEおよびREJECTなど）に関係なく、次の手順を実行してOracle JDeveloperでタスク切替えをリフレッシュする必要があります。
「ソース」をクリックしてBPELプロセスのソース・ビューを表示します。
「設計」をクリックしてBPELプロセスの設計ビューを表示します。
リフレッシュしなければ、機能が損われることはありません。正しいBPELプロセスが（新しい結果で）正しくデプロイされます。Oracle JDeveloperの設計ビューだけは、切替えアクティビティに正しいタスク結果が反映されていません。
『Oracle BPEL Process Manager開発者ガイド』の第16章「ワークリスト・アプリケーション」の表16-2「ワークリスト・アプリケーションの「ユーザー・タスク」ページのコンテンツ」で、検索キーワード・フィールドについての次の定義が表示されます。
タスクのタイトル、コメント、識別キー、および指定のフィルタ条件を満たすタスクのフレックス文字列フィールドを検索するためのキーワードを入力します。
ただし、検索できるのはテキスト属性フィールドのみです（textAttribute1〜textAttribute10）。formAttribute(1-5)やurlAttribute(1-5)などのその他の文字列フレックス・フィールドは、「ユーザー・タスク」ページの基本的な検索キーワードでは検索できません。このようなフィールドを検索するには、高度な検索機能を使用します。
10.1.3.5より前のリリースでは、サンプルはSOA_HOME/bpel/samplesディレクトリにインストールされていました。
これらのサンプルを使用していない場合は、削除することをお薦めします。たとえば、Linuxシステムでコマンド・プロンプトでディレクトリをSOA_HOME/bpel/samplesに変更し、rm -rfと入力します。
BPELには次の4つのLightweight Directory Access Protocol（LDAP）XPath関数があります。
authenticate
listUsers
lookupUser
search
これらのXPath関数は、LDAPサーバーからの情報、一般的にはLDAPユーザー情報を取得するための参照および検索機能を提供します。
これらのXPath関数は、directories.xmlという名前の構成ファイルを使用して、JNDIのサーバー・アクセス情報を取得します（たとえば、コンテキスト・ファクトリ、LDAPサーバーのプロバイダURL、認証タイプなど）。directories.xmlファイルを作成し、これを.bpelファイルと同じディレクトリに置く必要があります。
10.1.3.xリリースでは、これらのXPath関数はxpath-functions.xmlファイルで定義されています。
XPath関数のネームスペースURLは、http://schemas.oracle.com/xpath/extension/ldapです。
directories.xmlファイルを次のように書式設定します。
<?xml version="1.0" ?>
<directories>
<directory name='people'>
<property name="java.naming.provider.url">ldap://servername:port</property>
<property name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory
</property>
<property name="java.naming.security.principal">username</property>
<property name="java.naming.security.authentication">simple</property>
<property name="java.naming.security.credentials">passord</property>
<property name="entryDN">[entry dn]</property>
</directory>
</directories>
次に例を示します。
<?xml version="1.0" ?>
<directories>
<directory name='people'>
<property name="java.naming.provider.url">ldap://sta0018.us.mycompany.com:7001
</property>
<property name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory
</property>
<property name="java.naming.security.principal">cn=admin</property>
<property name="java.naming.security.credentials">weblogic</property>
<property name="java.naming.security.authentication">simple</property>
<property name="entryDN">ou=people,ou=myrealm,dc=soainfra</property>
</directory>
</directories>
LDAP関数をコールするには、directories.xmlを使用する必要があります。
この関数はLDAPユーザーを認証し、trueまたはfalseを返します。
シグネチャ:
ldap:authenticate('directoryName','userId','password')
パラメータ:
directoryName: directories.xmlに指定されたディレクトリ名です。
userId: LDAPサーバー・ログインのユーザーIDです。
password: LDAPサーバー・ログインのパスワードです。
戻り値:
trueまたはfalse
例:
ldap:authenticate('people','weblogic','weblogic')
このXPath関数の場合は、directories.xmlファイルに次の2つのプロパティを指定するだけです。
java.naming.provider.url
java.naming.factory.initial
この関数はLDAPユーザーのリストを返します。
シグネチャ:
ldap:listUsers('directoryName','filter')
パラメータ:
directoryName: directories.xmlに指定されたディレクトリ名です。
filter: 検索に使用するフィルタ式で、この値をnullにすることはできません。
戻り値:
ユーザーのリストを含むXML要素です。
このXPath関数の場合は、すべてのプロパティをdirectories.xmlファイルで指定する必要があります。
例:
ldap:listUser('people','cn=weblogic');
出力例:
<users xmlns="http://schemas.oracle.com/bpel/ldap">
<user dn="uid=weblogic">
<uid>weblogic</uid>
<userpassword>{ssha}bHDVJRfWVt/Uwlzb4TKU+QTOLB4FLySO</userpassword>
<objectclass>inetOrgPerson</objectclass>
<objectclass>organizationalPerson</objectclass>
<objectclass>person</objectclass>
<objectclass>top</objectclass>
<objectclass>wlsUser</objectclass>
<description>This user is the default administrator.</description>
<wlsMemberOf>cn=Administrators,ou=groups,ou=myrealm,dc=soainfra</wlsMemberOf>
<orclguid>8AC1B6206FDD11DEBF9A7F3D47003274</orclguid>
<sn>weblogic</sn>
<cn>weblogic</cn>
</user>
</users>
この関数はLDAPユーザー情報を返します。
シグネチャ:
ldap:lookupUser('directoryName','userId','password')
パラメータ:
directoryName: directories.xmlに指定されたディレクトリ名です。
userid: 検索するユーザーIDです。
戻り値:
ユーザー情報を含むXML要素です。
このXPath関数の場合は、すべてのプロパティをdirectories.xmlファイルで指定する必要があります。
例:
ldap:lookupUser('people','cn=weblogic');
出力例:
<user dn="" xmlns="http://schemas.oracle.com/bpel/ldap"> <ou>people</ou> <objectclass>organizationalUnit</objectclass> <objectclass>top</objectclass> <orclguid>8ABB9BA06FDD11DEBF9A7F3D47003274</orclguid> </user>
この関数はLDAPエントリのリストを返します。
シグネチャ:
ldap:search('directoryName','filter','scope')
パラメータ:
directoryName: directories.xmlに指定されたディレクトリ名です。
filter: 検索に使用するフィルタ式で、この値をnullにすることはできません。
scope: 検索の範囲です。次のいずれかの値にする必要があります。
0: 名前付きオブジェクト
1: 1レベル
2: サブツリー
このパラメータはオプションです。デフォルトでは、値は2です。
戻り値:
エントリのリストを含むXML要素です。
このXPath関数の場合は、すべてのプロパティをdirectories.xmlファイルで指定する必要があります。
例:
ldap:search('people','cn=weblogic');
出力例:
<searchResult xmlns="http://schemas.oracle.com/bpel/ldap">
<searchResultEntry dn="uid=weblogic" xmlns="urn:oasis:names:tc:DSML:2:0:core">
<attr name="uid">
<value>weblogic</value>
</attr>
<attr name="userpassword">
<value>{ssha}bHDVJRfWVt/Uwlzb4TKU+QTOLB4FLySO</value>
</attr>
<attr name="objectclass">
<value>inetOrgPerson</value>
<value>organizationalPerson</value>
<value>person</value>
<value>top</value>
<value>wlsUser</value>
</attr>
<attr name="description">
<value>This user is the default administrator.</value>
</attr>
<attr name="wlsMemberOf">
<value>cn=Administrators,ou=groups,ou=myrealm,dc=soainfra</value>
</attr>
<attr name="orclguid">
<value>8AC1B6206FDD11DEBF9A7F3D47003274</value>
</attr>
<attr name="sn">
<value>weblogic</value>
</attr>
<attr name="cn">
<value>weblogic</value>
</attr>
</searchResultEntry>
<searchResultEntry xmlns="urn:oasis:names:tc:DSML:2:0:core"/>
</searchResult>
parseXML XPath関数は、Oracle BPEL Process Managerとの使用で有効です。この関数は文字列をDOM要素に解析します。
シグネチャ:
ora:parseXML(contentString)
引数:
contentString: この関数がDOM要素に解析する文字列です。
プロパティID:
namespace-uri: http://schemas.oracle.com/xpath/extension
namespace-prefix: ora
『Oracle BPEL Process Manager開発者ガイド』の第15章「Oracle BPEL Process Managerワークフロー・サービス」の単純タスク表示フォームの自動生成に関する項に、単純タスク・フォームの生成時にタスク・パラメータに基づいてそのフォームの本体を作成する方法が記載されています。XSD定義に従って、本体フォームに含まれるフィールドを値のリストとして表示できます。
受け取る本体フォームの値のリストは、次のようになります。
XSDがカーディナリティにバインドなしの要素を含む場合は、ui構成のリストが生成されます。たとえば、XSDが次のような場合、ユーザー・インタフェースには複数のparam行が含まれます。
<element name="payload">
<complexType>
<sequence>
<element name="param" type="string" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
この項では、次の新機能と不具合の修正について説明します。
これまでのリリースでは、ヘッダー・ハンドラは呼出しリクエスト間のパートナ・リンクに関する情報のみを保存していました。このリリースでは、faultableResponseHeaderHandlerという名前のパートナ・リンク・プロパティが導入され、これによりヘッダー・ハンドラがフォルトをスローできるようになりました。このプロパティはフォルト・ハンドラを拡張して次の機能を提供します。
呼出しから返されるレスポンス・ペイロードにアクセスする機能
BPELフォルトをコール元に返せるようにする機能
これにより、レスポンス・ペイロードに基づいてルーティング・フィルタを実装して、フォルト処理の標準的な方法（たとえば、キャッチ・ブロックやフォルト・ポリシーなど）により、プロセスで取得されたBPELフォルトを返すかスローすることができます。faultableResponseHeaderHandlerプロパティは、インタフェースcom.collaxa.cube.ws.FaultableHeaderHandlerを実装するJavaクラスを指す必要があります。このクラスは、レスポンス・ヘッダーの内容に基づいてBPELフォルトをスローできるようになりました。たとえば、このプロパティをbpel.xmlで次のように設定します。
<partnerLinkBinding name="CallMyTestFunc"> <property name="wsdlLocation">CallMyTestFunc.wsdl</property> .... <propertyname="faultableResponseHeaderHandler"> com.collaxa.cube.ws.FaultHeaderHandlerImpl </property> </partnerLinkBinding>
UDDIを使用するパートナ・リンクのエンドポイントURLをキャッシュできるようになりました。この機能を使用するには、次の手順を実行します。
partnerLinkBindingプロパティuseRegistryCacheをbpel.xmlファイルに追加し、UDDIレジストリを使用するパートナ・リンクに対してtrueに設定します。次に例を示します。
<partnerLinkBinding name="UDDIBPEL">
<property name="wsdlLocation">http://host:port/
orabpel/default/UDDIBPEL/1.0/UDDIBPEL?wsdl</property>
<property name="registryServiceKey">
uddi:c6e19e10-6289-11de-9560-e4d914b0955f</property>
<property name="useRegistryCache">true</property>
</partnerLinkBinding>
UDDIレジストリを通してWSDLロケーションを取得するパートナ・リンクでは、WSDLロケーションは最初の呼出し後にキャッシュされます。
Oracle BPEL Controlで、「構成」→「ドメイン」を選択します。
uddiRefreshIntervalプロパティに、UDDIキャッシュをリフレッシュする定期的な時間間隔（秒単位）を設定します。デフォルト値は86400（1日）です。
キャッシュをリフレッシュすると、この中にある現在のエントリはすべて削除されます。
10.1.3.5より前のリリースでは、フォルト・ポリシーをパートナ・リンクまたはportTypeにバインドしていました。このリリースからは、フォルト・ポリシーをプロセス名にバインドすることもできます。これにより、すべてのフォルト・ポリシー機能をプロセス・レベルで適用できます。
次の例では、fault-bindings.xmlファイルでポリシーを定義しています。
<process faultPolicy="TerminatePolicy">
<name>LoanFlow</name>
</process>
<process faultPolicy="RetryPolicy">
<name>AutoLoanFlow</name>
</process>
<!--this is default policy for all processess -->
<process faultPolicy="RethrowPolicy"/>
<!--partnerlink policy -->
<partnerLink faultPolicy="RetryPolicy">
<name>creditRatingService</name>
</partnerLink>
プロセス（たとえば、LoanFlowやAutoLoanFlowなど）ごとにフォルト・ポリシーを定義し、その他すべてのプロセスにはデフォルト・ポリシーを定義できます。パートナ・リンクは常に優先順位が最上位で、その後にプロセス名のポリシーが続きます。前述のサンプル・コードでは、優先順位は次のようになります。
creditRatingServiceパートナ・リンクのポリシーは最上位を与えられます。
その特定のパートナ・リンクにポリシーが定義されていない場合は、プロセス名のポリシーが最上位になります（前述のサンプルではLoanFlowおよびAutoLoanFlow）。
特定のプロセスにポリシーが定義されていない場合は、デフォルトのプロセス名のポリシー（前述のサンプルではRethrowPolicy）が最上位になります。
fault-bindings.xmlファイルには、次の順序でポリシーを定義する必要があります。
プロセス名のポリシー
デフォルト・プロセスのポリシー
パートナ・リンクのポリシー
フォルト・ポリシーの詳細は、Oracle Technology Networkで入手可能なOracle BPEL Process Manager 10.1.3.4のリリース・ノートを参照してください。
http://www.oracle.com/technology/documentation/appserver10131.html
BPELデバッガを使用してOracle BPEL ControlからBPELプロセスおよびインスタンスをデバッグできます。BPELデバッガにより、次のタスクを実行できます。
BPELプロセス・レベルでブレークポイントを設定およびクリアします。
新規作成されたプロセス・インスタンスをプロセス・レベルでトラップする個数を指定します。
BPELプロセスの特定のインスタンスにブレークポイントを設定またはクリアします。ブレークポイントをインスタンス・レベルで定義することにより、インスタンスを完了するまでデバッグを行うことができます。次のようなインスタンスのデバッグ操作を追加で実行できます。
変数を表示および編集します。
監査証跡を表示します。
一度に1つのアクティビティのインスタンス実行を再開することにより、ステップ操作を実行します。
一度に1つの構造化アクティビティのインスタンス実行を再開することにより、再開操作を実行します。
すべてのブレークポイントをクリアし、インスタンスを完了するまで実行します。
BPELデバッガは、以前のモードではリリース10.1.3.5でのみ使用可能でした。BPELデバッガを有効にする方法については、Oracleサポート・サービスにお問い合せください。
BPELデバッガを有効にした後で、次の手順を実行します。
Oracle BPEL Controlにログインします。
「構成」タブを選択します。
「デバッグ」サブタブが、Oracle BPEL Controlの「インスタンス」タブと「プロセス」タブの両方に表示されるようになります。
次のデバッグ・タスクをプロセス・レベルで実行できます。
BPELプロセスのプロセス・マップを表示します。
選択したBPELアクティビティにプロセス・ブレークポイントを設定またはクリアします。
ブレークポイントに到達すると、実行を一時停止し、デバッグ・アクションが実行されるのを待ちます。
プロセスにトラップを定義します。
プロセス・トラップにより、デバッグのためにトラップされたBPELプロセス・インスタンスを制御できます。プロセス・トラップでは、無条件トラップとカウントを含む条件付きトラップの両方がサポートされています。デバッグのためにトラップするプロセス・インスタンスの数を指定します。デフォルトでは、プロセスに対するプロセス・トラップは無効です。
すべてのプロセスのデバッグ状態（プロセス・トラップとブレークポイントを含む）は、デハイドレーション・ストアに保持されます。また、Oracle BPEL Server起動中にドメインが初期化される際には、BPELデバッガはデハイドレーション・ストアからそのドメイン内にあるすべてのプロセスのデバッグ状態をロードします。
|
注意: リリース10.1.3.5にアップグレードした場合、続けてBPELプロセスを再コンパイルおよび再デプロイしなくてもBPELデバッガを使用できます。 |
Oracle BPEL Controlにログインします。
「プロセス」タブをクリックします。
「BPELプロセス」列で、デプロイされた特定のプロセスをクリックします。ライフ・サイクル設定が「アクティブ」で状態設定が「オン」のプロセスのみデバッグできます。
「デバッグ」サブタブをクリックします。
ブレークポイントを設定するBPELアクティビティを選択します。[Ctrl]キーを押しながら追加選択すると、複数のアクティビティを選択できます。
右側の「デバッガ」コントロール・パネルで、「ブレークポイントの設定」アイコン（2番目のアイコン）をクリックし、アクティビティにブレークポイントを設定します。
「デバッガ」コントロール・パネルの「ブレークポイント」セクションに、選択したブレークポイントが表示されます。インスタンス作成時には、プロセス・レベルで定義したすべてのブレークポイントが、プロセスの各インスタンスにデバッグ用にコピーされます。その特定のインスタンスのみに影響を与えるデバッグ・アクション（ステップ、再開、変数値の更新など）を、インスタンス・レベルで実行できます。
「ブレークポイント」セクションでブレークポイントを選択し、ブレークポイントのクリア・アイコン（3番目のアイコン）をクリックして、これを削除します。
「デバッガ」コントロール・パネルで、トラップ・カウントの設定アイコン（最初のアイコン）をクリックして、トラップ・カウント値を設定します。
プロセス・トラップ値を入力するためのダイアログが表示されます。すべてのプロセス・インスタンスをトラップするには、-1を入力します。トラップ・カウントにALLと表示されます。トラップ・カウント値0は、トラップが無効であることを意味します。
新規作成されたプロセス・インスタンスをトラップする数に値を入力し、「OK」をクリックします。
プロセス・インスタンスのトラップ値が「デバッガ」コントロール・パネルのトラップ・カウント・セクションと「ブレークポイント」セクションに表示されます。
「ブレークポイント」セクションでブレークポイントを選択し、ブレークポイントのクリア・アイコン（3番目のアイコン）をクリックして、これを削除します。
デバッグ状態をリフレッシュするには、プロセスのデバッグ状態をリフレッシュ・アイコン（4番目のアイコン）をクリックします。このアイコンの詳細は、表内のインスタンスのデバッグ状態をリフレッシュ・アイコンの説明を参照してください。
このページで実行できるタスクのオンライン・ヘルプを表示するには、「?」アイコン（5番目のアイコン）をクリックします。
次のデバッグ・タスクをインスタンス・レベルで実行できます。
最初のブレークポイント（プロセス・レベルで定義）で一時停止しているオープンBPELインスタンスをデバッグします。
デハイドレートされたインスタンスを対象にデバッグします（デハイドレーション・ポイントより先のアクティビティにブレークポイントを設定し、インスタンスがブレークポイントをヒットするのを待ちます）。
一度に1つずつインスタンスをデバッグします。
プロセス・インスタンスがブレークポイントをヒットするときには、「デバッグ」タブにインスタンスのプロセス・マップが表示されます。これにより、どのアクティビティでインスタンスの実行が一時停止したかを確認できます。デバッグ状態で一時停止しているインスタンスが複数ある場合は、特定のインスタンスを選択してロードしてからデバッグできます。
BPELインスタンスは、作成時に、対応するプロセス・レベルで定義されているブレークポイントを継承します。作成後は、インスタンスのブレークポイントはプロセスのブレークポイントに依存しなくなります。インスタンス上のブレークポイントの設定やクリアなどのデバッグ操作は、プロセス・レベルで定義されているブレークポイントには影響しません。またその逆も同様です。
インスタンスがデハイドレートされる際には、インスタンスのデバッグ状態はデハイドレーション・ストアで保持されます。同様に、インスタンスがリハイドレートされる際には、インスタンスのデバッグ状態もリストアされ、インスタンスのデバッグ操作を継続できます。
Oracle BPEL Controlにログインします。
「インスタンス」タブをクリックします。
「インスタンス」列で、1つ以上の特定のインスタンスをクリックします。デバッグが有効な場合、デバッグ可能なインスタンスには赤い停止アイコンが表示されます。1つ以上のデバッグ可能なインスタンスを選択して「再開」ボタンをクリックすると、一括再開操作を実行できます。インスタンス・レベルのデバッグは、open.running状態のBPELインスタンスに対してのみ有効です。
「デバッグ」サブタブをクリックします。
BPELインスタンスのプロセス・マップが表示されます。
プロセス・マップにより、ブレークポイントまたは現在位置を持つBPELアクティビティを視覚的に識別できます。現在位置は、アクティビティが実行を一時停止した場所に定義されます（そのアクティビティの直前）。そのため、最初の現在位置は、インスタンスが開始後に最初のブレークポイントをヒットしたときに定義されます。現在位置に関連付けられるブレークポイントは、明示的（ユーザー定義のブレークポイント）でも暗黙的（内部的なブレークポイントで、たとえば、単一ステップの操作を実行し、それに続くアクティビティにユーザー・ブレークポイントがない場合など）でもかまいません。
ユーザー・ブレークポイントを持つアクティビティは実行されないことがあり、そのため現在位置にならない可能性があります。これは、実行されるインスタンスがそのアクティビティに遭遇しない別の実行パスを通る場合に発生します。そのため、ブレークポイントに遭遇しない可能性があります。
アクティビティを右クリックし、そのアクティビティで許可されているデバッグ操作のリストを表示します。これらの操作の多くは状況に応じて行われるため、関連する場合にのみ表示されることに注意してください。
ソースの表示
BPELソース・コードを表示します。
ブレークポイントの設定
このアクティビティにブレークポイントを設定します。任意のアクティビティを右クリックすると、「ブレークポイントの設定」または「ブレークポイントのクリア」のどちらか1つのオプションが表示されます。
ブレークポイントのクリア
このアクティビティのブレークポイントをクリアします。
強制完了
デバッグするインスタンスに1つ以上の非同期アクティビティが実行中として表示される場合、実行中のアクティビティを強制完了するかスキップすることができます。そして続けて次のアクティビティが実行されます。
実行中として認識されたアクティビティは、現在位置のアクティビティとは異なります。receive、pickのOnAlarmブランチおよびwaitなどのBPELアクティビティは非同期で完了します。たとえば、中間プロセスのreceiveアクティビティは、関連付けられたパートナ・リンクからメッセージを受け取ると完了します。同様に、waitアクティビティは、アクティビティに関連付けられたタイマーが切れたときに完了します。
開始されているが、あるイベントの完了を待っているような非同期アクティビティのみが、実行中としてマークされます。アクティビティが正常に完了するまで待たない場合は、そのアクティビティをスキップするか強制完了させることができます。
現在位置の選択
複数の現在位置がある場合は、選択した現在位置を1つずつ切り替えることができます。この操作は、BPELインスタンスが複数の現在位置を持つデバッグ・モードの場合にのみ有効です。このオプションは、インスタンスに複数の現在位置があり、選択したアクティビティがその中の1つであるが、選択した現在位置ではない場合にのみ、選択対象として表示されます。
単一ステップ
次の操作を実行します。このオプションは、現在位置アクティビティを右クリックしたときに表示されます。
ステップ・ブロック
次の構造化アクティビティを実行します。このオプションは、構造化BPELアクティビティである現在位置アクティビティを右クリックしたときに表示されます。
再開
次のブレークポイントまで実行を再開します。このオプションは、現在位置アクティビティを右クリックしたときに表示されます。
すべてクリアして実行
すべてのブレークポイントを削除してから実行を再開します。このオプションは、現在位置アクティビティを右クリックしたときに表示されます。
右側の「デバッガ」コントロール・パネルの「ブレークポイント」セクションに、ブレークポイントのリストが表示されます。BPELインスタンスの実行は、アクティブなブレークポイントを持つBPELアクティビティの前で一時停止します。
上部のアイコンからデバッグ・タスクにアクセスできます。
左から右に表示されるアイコンについては、次の表で説明します。
使用環境に適したオプションを選択します。
「デバッガ」コントロール・パネルに、インスタンスのBPEL変数のリストが表示されます。ブレークポイントで実行が一時停止されたときに、インスタンスに関連するBPELプロセス変数を表示して編集できます。
リストの変数名をクリックすると、そのコンテンツが表示されます。
選択した変数の内容を編集します。
変数内容の上部にある最初のアイコンをクリックし、変数のXMLスケルトンを作成するか、エディタでその内容を作成します。これにより、XMLスキーマ・タイプに基づいた空のスケルトンを使用して変数を初期化できます。
変数内容の上部にある2番目のアイコンをクリックし、その変数をプロセス・インスタンスに保存します。
変数内容を編集した後で「保存」をクリックしないと、変更は取り消されます。BPELデバッガは、更新された変数内容に対してXMLスキーマ検証を実行します。
次のイベントが発生したときに、構成されたユーザーに電子メール通知を送信できます。
Oracle BPEL Serverが起動または停止されました。
プロセスの状態がオンからオフに変わり、ライフ・サイクルがアクティブからリタイアに変わりました。
インスタンスの状態が次のいずれかに変わりました。
起動済（open.running）
完了（closed.completed）
失敗（closed.faulted）
取消（closed.cancelled）
自動リカバリ・エージェントがインスタンスのリカバリに失敗しました。
呼出しメッセージ、コールバック・メッセージまたはアクティビティがリカバリ・フェーズに移動しました。
|
注意: イベント通知の送信用としてサポートされるチャネルは、電子メールのみです。 |
表5-1は、Oracle BPEL Controlで事前定義されたテンプレートを使用して構成できる通知イベント・タイプを示しています。
表5-1 通知のイベント・タイプ
| イベント・タイプ | イベント名 | イベントの説明 |
|---|---|---|
|
Oracle BPEL Server |
|
|
|
プロセス |
|
|
|
インスタンス |
|
|
|
リカバリ |
|
|
テンプレートで通知メッセージの内容を作成する場合、件名と本文に事前定義された特定の変数を使用できます。これらの変数は、実行時に実際の値に置き換えられます。表5-2に詳細を示します。
表5-2 事前定義された通知変数テンプレート
| タイプ | 変数名 | 速度表現 |
|---|---|---|
|
環境変数（環境） |
|
|
|
エンジン通知変数（エンジン） |
|
|
|
プロセス通知変数（プロセス） |
|
|
|
インスタンス通知変数（インスタンス） |
|
|
|
自動リカバリ・エージェント変数（リカバリ） |
|
|
XSDファイル（bpel_notification.xsd）はSOA_Home/bpel/system/xmllibにあります。
通知用に生成される電子メールは、テンプレートに従って構成されます。これらのテンプレートには事前定義された変数が含まれており、実行時に実際の値に置き換えられます。標準に従ってこれらの変数をより簡単な形式にするために、BPEL通知機能にはvelocityテンプレートが使用されています。そのため、通知機能を動作させるにはvelocity-dep-1.5.jarファイルが必要になります。
velocity-dep-1.5.jarファイルは、Oracle SOA Suiteに同梱されていません。そのため、BPEL通知機能はデフォルトでは無効になっています。BPEL通知機能を有効にするには、Apacheライセンス契約に承諾後、このJARファイルを明示的にダウンロードする必要があります。
velocity-dep-1.5.jarファイルをダウンロードするには、次の手順を実行します。
次のURLにアクセスします。
http://archive.apache.org/dist/velocity/engine/1.5/
velocity-dep-1.5.jarをダウンロードします。
BPEL通知機能を使用するために、Apacheライセンス契約に承諾します。
JARファイルを$Oracle_Home/bpel/lib（UNIXの場合）またはOracle_Home\bpel\lib（Windowsの場合）に置きます。
Oracle BPEL Serverを再起動します。
これでBPEL通知機能をOracle BPEL Controlに表示できるようになりました。
Oracle BPEL Controlにログインします。
「構成」タブをクリックします。
「通知」タブをクリックします。
ページの上部では次のタスクを実行できます。
イベント・タイプとテンプレートを選択し、有効または無効にします。1つのイベント・タイプが2つ以上のテンプレートを持つように構成できます。ただし、1つのイベント・タイプが同じテンプレートを2回持つことはできません。
通知受信者を指定します。複数の受信者を指定する場合は、各受信者をカンマで区切ります。
「適用」をクリックして変更を適用します。
ページの下部にスクロールします。
ページの下部では次のタスクを実行できます。
「現在のテンプレート」セクションで、使用するテンプレートを選択します。この操作により、「テンプレートの詳細」セクションにテンプレートが表示されるようになります。velocityテンプレートのすべての変数値は、通知サービスによりBPELランタイムの実際の値と自動的に置き換えられます。これらの値は電子メールの内容として送信されます。このテンプレートにユーザーが値を入力する必要はありません。
テンプレートを追加または削除するには、「追加」または「削除」アイコンをクリックします。
変数の説明と値の例については、オンライン・ヘルプの事前定義されたテンプレート変数リンクをクリックしてください。
完了したら「適用」をクリックします。
「構成」タブをクリックします。
下にスクロールし、SMTPサーバーを使用環境に適した値で構成します。
完了したら「適用」をクリックします。
通知機能は、メモリー内の記憶域を使用して2つの処理サイクル（デフォルトで5分）の間のメッセージを収集し、それらを定期的に処理します。処理する通知メッセージの最大数は、このページのnotificationStoreMaxMessagesSizeプロパティで設定します。デフォルト値は150です。大規模な環境では、多数の通知メッセージの収集や処理が必要になります。このシナリオでは、このプロパティの値を増やし、メッセージが収集および処理されないことのないようにする必要があります。デフォルト値150を超えると、ログに次のnullポインタ例外が記録され、その結果BPEL通知サービスが無効になります。
<NotificationAgent::execute> Domain :default NotificationJob: Number of
notification messages to be processed : 150
<NotificationAgent::processNotification> Domain :default, Processing
@ instance.complete notification for channel: email
Unable to handle email notifications for the domain default
java.lang.NullPointerException
at
com.collaxa.bpel.services.notification.channel.ChannelHandler.constructMessage
. . .
. . .
このような事態が発生した場合は、次の回避方法のいずれかを実行します。
Oracle BPEL Controlで「構成」→「通知」に移動します。
通知を無効にして、「適用」をクリックします。
通知を有効にして、「適用」をクリックします。
または
Oracle BPEL Serverを再起動します。
通知イベントは、BPELインスタンス、ディスパッチャ・メッセージ、BPELプロセスなどに重大な変化が発生した場合にトリガーされます。これらの累積イベントは定期的に処理され（デフォルトでは5分ごと）、通知イベント・タイプ1つにつき1つの電子メールがディスパッチされます。この実行中に、2つの通知周期サイクル間で収集された同じ通知メッセージのセットが処理され、1つの電子メールとして送信されます。たとえば、ドメインでは、失敗したBPELインスタンスのセットが統合されて1つの電子メールとして送信されます。
通知メッセージの処理は定期的に実行されます。デフォルトの間隔は5分です。この値は使用環境の要件に合せて変更できます。このプロパティを変更するには、次の手順を実行します。
このプロパティを変更するドメインのSOA_HOME\bpel\domains\domain_name\config\domain.xmlファイルを開きます。
notificationScheduleDurationプロパティを手動で追加し、これに適切な整数値を設定します。
<property id="notificationScheduleDuration"> <name>Notification schedule duration property</name> <value>5</value> <comment/> </property>
ファイルを保存して閉じます。
Oracle BPEL Serverを再起動します。
これでプロパティはOracle BPEL Controlの「構成」→「ドメイン」の下に表示されるようになりました。この値を変更してもOracle BPEL Serverを再起動する必要はありません。
この項では、イベント通知メッセージのサンプルを示します。
例5-1は、エンジン（Oracle BPEL Server）通知時に送信されるメッセージ内容の例です。
例5-1 エンジン（Oracle BPEL Server）通知メッセージの内容
E-mail Subject Engine Notification: Started
Email Content Server host : myhost.us.oracle.com:9999
Server instance : oc4j_soa
Domain name : tests
Server status : Stopped
Timestamp : Wed April 08 00:42:23 PDT 2009
例5-2は、プロセス通知時に送信されるメッセージ内容の例です。この例では、同じ内容の通知が1つの通知に結合されています。
例5-2 プロセス通知メッセージの内容
E-mail Subject Process Notification: Retired
Email Content Server host : myhost.us.oracle.com:9999
Server instance : oc4j_soa
Domain name : tests
Process name : SyncEmbedProcess
Revision tag : 1.0
Process Status : Retired
Timestamp : Wed April 08 10:42:23 PDT 2009
Process name : SyncXPathProcess
Revision tag : 1.0
Process Status : Retired
Timestamp : Wed April 08 05:12:24 PDT 2009
例5-3は、インスタンス通知時に送信されるメッセージ内容の例です。
例5-3 インスタンス通知メッセージの内容
E-mail Subject Instance Notification: Faulted
Email Content Server host : myhost.us.oracle.com:9999
Server instance : oc4j_soa
Domain name : tests
Process name : SyncEmbedProcess
Revision tag : 1.0
Instance ID : Retired
Conversation ID : bpel://localhost/tests/Tests-1.0/6567403-BpSeq1.3
Instance status : Faulted
Timestamp : Wed April 08 04:22:29 PDT 2009
例5-4は、リカバリ通知時に送信されるメッセージ内容の例です。この例では、同じ内容の通知が1つの通知に結合されています。
例5-4 リカバリ通知メッセージの内容
E-mail Subject Attempted Invoke messages recovery and faulted
Email Content Server host : myhost.us.oracle.com:9999
Server instance : oc4j_soa
Domain name : tests
Process name : SyncEmbedProcess
Revision tag : N/A
Instance ID : N/A
Activity name :
Conversation ID : bpel://localhost/tests/Tests-1.0/6567402-BpSeq1.3
Receive date : 03/11/09 06:37:51 AM
Recovery status : Pending recovery
Timestamp : Wed April 08 01:26:34 PDT 2009
Error code : ORABPEL-92181
Exception : Fauled due to unhandled BPEL fault
Process name : SyncJavaEmbed
Revision tag : N/A
Instance ID : N/A
Activity name :
Conversation ID : bpel://localhost/tests/Tests-1.0/6567434-BpSeq1.3
Receive date : 03/11/09 06:37:51 AM
Recovery status : Pending recovery
Timestamp : Wed April 08 07:21:03 PDT 2009
Error code : ORABPEL-92181
Exception : Fauled due to unhandled BPEL fault
例5-5は、インスタンス・リカバリ通知時に送信されるメッセージ内容の例です。この通知は、メッセージまたはアクティビティがリカバリに移動したときにトリガーされます。
例5-5 インスタンス・リカバリ通知メッセージの内容
E-mail Subject Invoke message fail and move to recovery
Email Content Server host : myhost.us.oracle.com:9999
Server instance : oc4j_soa
Domain name : tests
Process name : SyncJavaEmbed
Revision tag : 1.0
Instance ID : N/A
Activity name : N/A
Conversation ID : bpel://localhost/tests/Tests-1.0/6567433-BpSeq1.3
Receive date : 03/11/09 06:37:51 AM
Timestamp : Wed April 08 12:00:23 PDT 2009
例5-6は、インスタンス・リカバリ通知時に送信されるメッセージ内容の例です。この通知は、メッセージまたはアクティビティがリカバリに移動したときにトリガーされます。
例5-6 インスタンス・リカバリ通知メッセージの内容
E-mail Subject Callback messages fail and move to recovery
Email Content Server host : myhost.us.oracle.com:9999
Server instance : oc4j_soa
Domain name : tests
Process name : SyncJavaEmbed
Revision tag : 1.0
Instance ID : N/A
Activity name : N/A
Conversation ID : bpel://localhost/tests/Tests-1.0/6567913-BpSeq1.3
Receive date : 03/11/09 04:33:51 AM
Timestamp : Wed April 08 09:42:03 PDT 2009
10.1.3.5より前のリリースでは、「変換」ダイアログの「OK」および「適用」ボタンは、Oracle JDeveloperがリモートXSDファイル（たとえば、BPELプロセスの変数が使用するタイプ宣言を含むファイル）をロードしている間も有効なままでした。Oracle JDeveloperがまだファイルをロード中であることに気付かないで「OK」または「適用」ボタンをクリックすると、メッセージ変数の一部が正しく設定されず、変換アクティビティが壊れる場合があります。
このリリースから、XSDファイルをロードするときには、Oracle JDeveloperがファイルのロードを完了するまで、「OK」および「適用」ボタンが無効になります。
10.1.3.5より前のリリースでは、BPELプロセスをデプロイしてそれをデフォルトのリビジョンにする（つまり、Oracle BPEL Controlでアスタリスクとみなす）には、手動で設定する必要がありました。
このリリースでは、bpelcにdefaultRevisionパラメータが含まれています。このパラメータをtrueに設定すると、デプロイされるプロセス・リビジョンがデフォルト・リビジョンに設定されます。
たとえば、次の手順を実行します。
domain.xmlファイルで、構成プロパティprocessDeployAsDefault=falseを追加します。
Oracle BPEL Serverを再起動します。
次のコマンドを入力して、SOA_HOME/bpel/samples/tutorials/101.HelloWorldのプロセスをデプロイします。
ant -Drev 1.0
このプロセスがデフォルトのリビジョンになります。
次のコマンドを入力します。
ant -Drev 2.0
リビジョン1.0がデフォルトのリビジョンのままです。
次のコマンドを入力します。
ant -Drev 3.0 -DdefaultRevision true
リビジョン3.0がデフォルトのリビジョンになります。
次の相互運用シナリオがサポートされています。
Oracle SOA Suite 11gサービスがOracle SOA Suite 10.1.3.5サービスを非同期にコール。
Oracle SOA Suite 10.1.3.5サービスがOracle SOA Suite 11gサービスを非同期にコール。
10.1.3.5より前のリリースでは、XSDスキーマが再帰的である場合（たとえば、orderとcustomerの両方のノードが必要なXSDでorder→customer→orderが繰り返される）、変換の問題が発生していました。これは、この再帰タイプが無限であり、有効なドキュメントが1つも作成されないことが原因でした。XSLTマッパーのテスト・ツール用のXMLコード・ジェネレータは、これらの再帰的ノードを通して無限に実行され、しだいにメモリー不足になっていました。
このリリースでは、XML生成は、必要な再帰を検出して最初の繰返しで停止させます。有効なXMLドキュメントがXSDに対して定義どおりに作成できないため、問題を示すエラーがXMLエディタに表示されます。エラーを無視して継続するよう選択するか、あるいはXSDを修正することもできます。
10.1.3.5より前のリリースでは、変換マッピングを含むBPELプロセスのインスタンスを設計、デプロイ、作成し、それからBPELプロセスに戻り、追加の変換マッピングを実行し、プロセスを再デプロイし、そしてインスタンスを再作成した場合、追加のマッピングは実行時にインスタンスに反映されませんでした。
このリリースでは、追加のマッピングが実行時にインスタンスに正しく反映されるようになりました。
新しいantベースのツールが追加され、WSIF-EJBバインディングおよびXML/Javaオブジェクトのマッピング・メタデータを含むWSDLファイルを生成できるようになりました。また、新しいデータ・バインディング・ランタイムも追加され、設計ツールで現在生成されているマッピング・メタデータに基づいて、JavaとXML間の変換を行えるようになりました。現在のWSIF-EJBプロバイダは、新しいデータ・バインディング・ランタイムに、Webサービス・アセンブラ（WSA）で生成されたアーティファクトの操作に必要となる変更を組み込むように強化されています。
この項では、BPELからEJBを起動するために必要なWSIF-EJBバインディングと関連するアーティファクトを含むWSDLを生成する方法について説明します。特に、この項では次の手順の実行方法について説明します。
antで使用する2つのXMLファイル（wsif-ejb-tool.xmlおよびbuild.xml）を作成します。
GenerateBeanDefinition antターゲットを実行して、中間タイプ定義ファイルを生成します。
次のコード・サンプルに示すXXXXX値を、タイプ定義ファイル内の有効な値と置き換えます。
GenerateWSDL antターゲットを実行して、WSDLファイルを生成します。
|
注意: Bean定義およびWSDLファイル生成のantスクリプトを作成する際には、必ず正しいパス・セパレータを使用してください（Linuxの場合は:と/、Windowsの場合は;と\）。 |
SOA_HOME\bpel\systemディレクトリにwsif-ejb-tool.xmlという名前の新規ファイルを作成します。
次のXMLコンテンツをコピーしてファイル内に貼り付けます。このXMLファイルはクラス・パス変数を設定します。
<?xml version="1.0"?>
<project name="wsif-ejb-binding" default="" basedir=".">
<property name="classpath"
value=".\..\lib\xmlparserv2.jar;.\..\..\webservices\lib\saaj-api.jar;.\..\..\
webservices\lib\wsa.jar;.\..\..\webservices\lib\wsclient.jar;.\..\..\webservice
s\lib\wsserver.jar;.\..\..\webservices\lib\jaxrpc-api.jar;.\..\..\webservices\
lib\orasaaj.jar;.\..\..\webservices\lib\orawsdl.jar;.\..\..\webservices\lib\
orawsmetadata.jar;.\..\..\j2ee\home\lib\ejb30.jar;.\..\..\j2ee\home\lib\
ejb.jar;.\..\..\j2ee\home\lib\mail.jar;.\..\..\j2ee\home\lib\http_client.jar;.
\..\lib\wsif-ejb-design.jar"/>
<taskdef name="BeanDefinitionGenerator"
classname="oracle.tip.wsif.ejb.wsdlgen.tool.AntBDFGenerator"
classpath="${classpath}"/>
<taskdef name="WSDLGenerator"
classname="oracle.tip.wsif.ejb.wsdlgen.tool.AntGenerateArtifacts"
classpath="${classpath}"/>
</project>
SOA_HOME\bpel\binの下にWSDLファイルを生成するantファイルを作成します。次のbuild.xmlファイルは、WSDLファイル生成のコンテンツを示しています。
<project name="wsif-ejb-binding-design-time" default="" basedir=".">
<import file="..\system\wsif-ejb-tool.xml"/>
<property name="jarLocation"
value="C:\Temp\wsif\DataBindingTestEJB\deploy\ejb1.jar"/>
<property name="beanDefinitionLocation" value="C:\Temp\wsif\beanDefinition\"/>
<target name="GenerateBeanDefinition" depends="">
<BeanDefinitionGenerator
jarLocation="${jarLocation}"
beanDefinitionLocation="${beanDefinitionLocation}"
pkg="test.*,databindingtestejb.*"
logLevel="info"
jvmArgs="-Dhttp.proxyHost=PROXY_HOST -Dhttp.proxyPort=PROXY_PORT
-DproxySet=true"
failonerror="true">
</BeanDefinitionGenerator>
</target>
<target name="GenerateWSDL" depends="">
<WSDLGenerator
jarLocation="${jarLocation}"
beanDefinitionLocation="${beanDefinitionLocation}"
artifactsLocation="C:\Temp\wsif\artifacts\"
schemaLocation=""
customTypeMappingLocation=""
jndiName="CustomerEJB"
initialContextFactory="oracle.j2ee.rmi.RMIInitialContextFactory"
jndiProviderURL="ormi://myhost-pc.idc.oracle.com:12402/ejb1"
logLevel="info"
jvmArgs="-Dhttp.proxyHost=PROXY_HOST -Dhttp.proxyPort=PROXY_PORT
-DproxySet=true"
strictJaxrpcValidation="true"
failonerror="true">
</WSDLGenerator>
</target>
</project>
|
注意: Oracle WebLogic ServerでBean定義を生成する場合は、GenerateBeanDefinitionタスクおよびGenerateWSDLタスクのXDKパーサーを指定するシステム・プロパティを追加する必要があります。手順は、5.9.9項「EJBがコレクション・クラスを含む場合にant Bean定義生成エラーが発生する」を参照してください。 |
BeanDefinitionGeneratorタスクを使用して、中間タイプ定義ファイルを生成するantターゲットを作成し、実行します。このターゲットは、BeanDefinitionGeneratorタスクに必要なすべての属性を提供する必要があります。
次の属性の定義を示します。
jarLocation: EJBクライアントJARファイルの場所です。この属性値は、最上位レベルのプロパティjarLocationですでに定義されています。
beanDefinitionLocation: 中間タイプ定義ファイルを置くディレクトリの場所です。この属性値は、最上位レベルのプロパティbeanDefinitionLocationですでに定義されています。
pkg: タイプ定義ファイルを生成する必要のあるパッケージのカンマ区切りのリストです。たとえば、test.*,databindingtestejb.*のようになります。現在のところ、タスクは*.*をサポートしていません。
antタスクGenerateBeanDefinitionを使用してBean定義を生成する場合、Bean定義ファイルは指定したクラス、およびこのクラス・ファイルに依存するすべてのクラスに対して生成され、何もフィルタされません。パッケージ・フィルタのメカニズムは、主にパッケージ構造が異なる他の依存クラスを含めることを目的としています。
logLevel: 必要なロギング・レベルです。許可される値はDEBUG、INFO、WARNINGおよびERRORです。
jvmArgs: この属性はEJB 2.1 JARファイルには必要ありません。ただし、EJB 2.0 JARファイルを使用していてプロキシ・サーバーを使用する場合には、この属性を追加して、使用しているPROXY_HOST（たとえば、www-proxy.us.mycompany.com）とPROXY_PORT（たとえば、80）の値を指定する必要があります。プロキシ・サーバーを使用していない場合は、jvmArgs属性とPROXY_HOSTおよびPROXY_PORTプロパティは必要ありません。ツールは自動的にhttp://java.sun.com/dtd/ejb-jar_2_0.dtdを使用します。
failonerror: これはtrueに設定する必要があります。
次に例を示します。
<target name="GenerateBeanDefinition" depends="">
<BeanDefinitionGenerator
jarLocation="${jarLocation}"
beanDefinitionLocation="${beanDefinitionLocation}"
pkg="test.*,databindingtestejb.*"
logLevel="info"
jvmArgs="-Dhttp.proxyHost=PROXY_HOST -Dhttp.proxyPort=PROXY_PORT
-DproxySet=true"
failonerror="true">
</BeanDefinitionGenerator>
</target>
このターゲットにより、beanDefinitionLocationディレクトリにタイプ定義ファイルが出力されます。タイプ定義ファイルは、選択したパッケージのクラスに対応します。タイプ定義ファイルは次の事項を持つクラスに対して生成されることに注意してください。
メンバー変数としてのコレクション・クラス
コレクション・クラスをパラメータまたは戻り型として使用する、ejb-jar.xmlファイルのサービス・エンドポイント、リモートまたはローカルのインタフェース
タイプ定義ファイル名は、完全修飾クラス名のドット（.）をアンダースコア（_）に置き換えたものです。たとえば、名前がdatabindingtestejb.CustomerEJBWebServiceのクラスの場合、対応するタイプ定義ファイル名はdatabindingtestejb_CustomerEJBWebService.xmlです。
beanDefinitionLocationディレクトリのすべてのタイプ定義ファイルの不足している情報を提供する必要があります。必要な情報はコレクション・クラスに含まれるタイプです。たとえば、次に示すタイプ定義ファイル・スニペットが、設計時に生成されるとします。
<?xml version = '1.0' ?>
<Bean-definition xmlns="http://java.wsif.ejb.binding">
<Class name="test.databinding.dto.customer.profile.FiledCreditCards"
serialVersionUID="-8027792423900150501">
<Fields>
<Field name="customerCreditCards" type="java.util.Collection">
<Value>XXXXX</Value>
</Field>
<Field name="merchants" type="java.util.TreeSet">
<Value>XXXXX</Value>
</Field>
<Field name="creditCardByMerchant" type="java.util.Hashtable">
<Key>XXXXX</Key>
<Value>XXXXX</Value>
</Field>
</Fields>
</Class>
</Bean-definition>
この例のXXXXX値をコレクションのコンテンツ・クラスと置き換えます。
次の例は、前述のタイプ定義ファイルの変更されたバージョンを示しています。
<?xml version = '1.0' ?>
<Bean-definition xmlns="http://java.wsif.ejb.binding">
<Class name="test.databinding.dto.customer.profile.FiledCreditCards"
serialVersionUID="-8027792423900150501">
<Fields>
<Field name="customerCreditCards" type="java.util.Collection">
<Value>test.databinding.dto.customer.profile.CustomerCreditCard
</Value>
</Field>
<Field name="merchants" type="java.util.TreeSet">
<Value>test.databinding.dto.customer.profile.Merchant</Value>
</Field>
<Field name="creditCardByMerchant" type="java.util.Hashtable">
<Key>test.databinding.dto.customer.profile.Merchant</Key>
<Value>test.databinding.dto.customer.profile.CustomerCreditCard
</Value>
</Field>
</Fields>
</Class>
</Bean-definition>
WSDLGeneratorタスクを使用してWSDLファイルを生成するantターゲットを作成し、実行します。このターゲットは、WSDLGeneratorタスクに必要なすべての属性を提供する必要があります。WSDLGenerator構文については、手順3を参照してください。
次の属性の定義を示します。
jarLocation: EJBクライアントJARファイルの場所です。この属性の値は、最上位レベルのプロパティjarLocationですでに定義されています。
beanDefinitionLocation: 中間タイプ定義ファイルのディレクトリの場所です。この属性値は、最上位レベルのプロパティbeanDefinitionLocationですでに定義されています。
artifactsLocation: WSDLおよびJAX-RPCマッピング・ファイルのディレクトリの場所です。
schemaLocation: WSDLファイルにインポートするすべてのスキーマ・ファイルのカンマ区切りのリスト（空白なし）です。この属性はオプションです。
customTypeMappingLocation: カスタム・タイプのマッピング・ファイルの場所です。この属性はオプションです。
jndiName: EJBのJNDI名です。
initialContextFactory: EJBの初期コンテキスト・ファクトリです。
jndiProviderURL: EJBのJNDIプロバイダURLです。
logLevel: 必要なロギング・レベルです。許可される値はDEBUG、INFO、WARNINGおよびERRORです。
jvmArgs: 説明は5.8.11.2項「Bean定義の生成」を参照してください。
strictJaxrpcValidation: サービス・エンドポイント・インタフェース、例外および値タイプをすべてのJAX-RPC検証ルールに従って検証するかどうかを決定します。許可された値がtrue（デフォルト）かfalseかに関係なく、この属性はtrueに設定する必要があります。falseに設定した場合、WSDLファイル生成は動作しますが、実行中に問題が発生します。
failonerror: trueに設定する必要があります。
次に例を示します。
<target name="GenerateWSDL" depends="">
<WSDLGenerator
jarLocation="${jarLocation}"
beanDefinitionLocation="${beanDefinitionLocation}"
artifactsLocation="C:\Temp\wsif\artifacts\"
schemaLocation=""
customTypeMappingLocation=""
jndiName="CustomerEJB"
initialContextFactory="oracle.j2ee.rmi.RMIInitialContextFactory"
jndiProviderURL="ormi://myhost-pc.idc.oracle.com:12402/ejb1"
logLevel="info"
jvmArgs="-Dhttp.proxyHost=PROXY_HOST -Dhttp.proxyPort=PROXY_PORT
-DproxySet=true"
strictJaxrpcValidation="true"
failonerror="true">
</WSDLGenerator>
</target>
T3プロトコル（最適化されたバインディング）を使用したOracle BPEL Process ManagerとOracle Service Bus 3.1の通信がサポートされています。パッチ10.1.3.5をインストール後、次の追加情報に注意してください。
Oracle Bug#5507491に対してOracleのXDK個別パッチを適用する必要があります。詳細はOracleサポート・サービスにお問い合せください。
Oracle WebLogic Serverリリース9.2のJMSキューに接続するJMSアダプタを使用しており、MetaLinkノート549016.1を使用してweblogic.jarファイルを使用環境に追加した場合は、server.xmlファイルを変更する必要はありません。そうでない場合は、次の手順を実行する必要があります。
テキスト・エディタを使用して$ORACLE_HOME/j2ee/container_name/config/server.xmlファイルを開きます。
ここでcontainer_nameは、Oracle BPEL Process Managerのデプロイ先のコンテナ名です（たとえば、oc4j_soa）。
<shared-library name="oracle.bpel.common" version="10.1.3">を検索します。
次に示すように、oracle.bpel.common共有ライブラリ内にもう1つ<code-source path/>を追加します。
<code-source path="$ORACLE_HOME/bpel/lib/wlclient_oc4jinterop.jar"/>
$ORACLE_HOMEがその実際のパスに展開されていることを確認します（たとえば、同じファイル内のorabpel.jarのエントリを確認）。
最適化されたバインディングの次の機能に注目してください。
| ユースケース | プロトコル・オプション | トランザクション伝播 |
|---|---|---|
| OC4J上のOracle BPEL Process ManagerからOracle WebLogic Server上のOracle Service Bus: | T3 | なし |
| Oracle WebLogic Server上のOracle Service BusからOC4J上のOracle BPEL Process Manager | ORMI/OPMN | なし |
| Oracle WebLogic Server上のOracle BPEL Process ManagerからOracle WebLogic Server上のOracle Service Bus | T3 | あり |
| Oracle WebLogic Server上のOracle Service BusからOracle WebLogic Server上のOracle BPEL Process Manager | T3、IIOP、RMI over HTTP（つまり、HTTPトンネリング） | あり |
変更されたBPELプロセスの進行中のインスタンスを移行できます。これは、通常はより古いプロセス定義から作成された実行インスタンスをより新しいプロセス定義に移行します。そしてインスタンスは、新しい方の定義で完了まで実行されます。移行の完了後、古い方のプロセス・インスタンスはクローズとしてマークされ、取り消されます。たとえば、HelloWorldリビジョン1.0のインスタンス番号1234をプロセスHelloWorldリビジョン2.0へ移行すると、このプロセスで完了まで実行されます。
移行を実行する前に、次のガイドラインを確認して、インスタンスの移行がどのように行われるか理解しておく必要があります。
移行は、同じプロセス名（たとえば、HelloWorld 1.0からHelloWorld 2.0またはOrderBooking 3.0からOrderBooking 7.0）のリビジョン間でのみ許可されます。
任意の2つのリビジョンが互換性のあるインタフェースを持つようにする必要があります。ただし、現時点ではこの要件を強制するツールはありません。そのため、この互換性が維持されていることを確認してください。たとえば、次の点を確認します。
変更が増分的で以前のリビジョンの定義と矛盾していません。
パートナ・リンク、メッセージ、タイプ、バインディングなどの外部サービスとの通信に使用するインタフェースが互換性のない方法で変更されていません。
変数のタイプと名前に互換性があります。
パートナ・リンクのパートナ・リンク名や操作などの定義に互換性があります。
たとえば、より古いソース・リビジョンとより新しい宛先リビジョンのパートナ・リンク名が異なると、ソース・リビジョンのインスタンスの状態は宛先リビジョンのインスタンスにコピーされません。そのため、receiveアクティビティは受け取ったコールバック・メッセージの処理方法がわかりません。
非同期プロセスのみを移行できます。非同期プロセスは、一般的には実行時間が長く、デハイドレーション・ポイントで一時停止します。同期プロセスは、デハイドレーション・ポイントがないため移行できません。
移行マッピングは、デハイドレーション・ポイントを持つ特定のアクティビティから許可されます。移行に関係するアクティビティには2つのタイプがあります。
コンテナ・アクティビティ
コンテナの例として、scope、flow、sequence、flowNなどがあります。
sssign、throw、receiveなど、その他すべてのアクティビティ。
移行マッピングは、複数のアクティビティを管理するスレッド制約を受けます。Oracle BPEL Serverでは、許可されるスレッド数は1アクティビティにつき1個のみで、1コンテナにつき最大N個です。scopeやsequenceなどのコンテナでは、実行を許可されるスレッドは常に1つのみです。表5-3は、サポートされるアクティビティの移行についての詳細を示しています。
表5-3 サポートされるアクティビティの移行
| 移行元のソース定義 | 移行先のターゲット定義 | 説明 |
|---|---|---|
|
receiveアクティビティ |
flowNに属するアクティビティを除く任意のアクティビティ 注意: flowNへ移行できますが、その中には移行できません。 |
移行されたアイテムがフローの中にある場合は、フローのそのブランチのみが宛先で実行されます。この場合、ソース・スレッドは1つのみであり、そのため宛先プロセスには最大1つのスレッド/作業アイテムが作成されます。作業アイテムは、Oracle BPEL Serverが実行するタスクです。スレッドは、作業アイテムで表され、コンテナ・アクティビティによって管理されます。 |
|
waitアクティビティ |
flowNに属するアクティビティを除く任意のアクティビティ |
receiveアクティビティで説明したのと同じ動作が発生します。 |
|
pickアクティビティ |
flowNに属するアクティビティを除く任意のアクティビティ |
pickはonMessage構成とonAlarm構成のリストに分割されます。親プロセスで作成された作業アイテムがN個であると、宛先には潜在的にN個の異なる実行ポイントがあります。ほとんどの場合は、1つの作業アイテムのみが移行されます（最初のonMessageか最初のonAlarm）。 |
|
任意のデハイドレーション・ポイント（receive、wait、pick、onAlarm、onMessage） |
flowNに属するアクティビティを除く任意のアクティビティ |
ソース・プロセスのN個のアクティブな作業アイテムを移行し、宛先プロセスにM個のアクティブな作業アイテムを作成できます。要件は次の1つのみです。
|
|
任意のデハイドレーション・ポイント（receive、wait、pick、onAlarm、onMessage） |
pickアクティビティへ |
pickへの移行は、pickが実行ポイントとなることを意味します。Oracle BPEL Serverは、単にpickを実行するだけです。 |
|
任意のデハイドレーション・ポイント（receive、wait、pick、onAlarm、onMessage） |
pickアクティビティ内へ |
pickアクティビティ内への移行は、pickを構成するonMessageまたはonAlarmのいずれかの基本アクティビティ内に移行することを意味します。これらのいずれか1つに移行できます。 |
|
任意のデハイドレーション・ポイント（receive、wait、pick、onAlarm、onMessage） |
flowアクティビティへ |
flowへの移行は、flowが実行ポイントとなることを意味します。Oracle BPEL Serverは、単にflowを実行するだけです。 |
|
任意のデハイドレーション・ポイント（receive、wait、pick、onAlarm、onMessage） |
flowアクティビティ内へ |
flowアクティビティ内への移行は、たとえば2つのブランチを3つのブランチを持つflowアクティビティに移行する場合、2つのみが実行されることを意味します。 |
|
flowアクティビティ内のアクティビティ |
別のflowアクティビティ内へ |
この移行タイプはサポートされていて、複数のブランチを移行できます。 |
インスタンスはソースのwhileループ内から移行し、宛先のwhileループ内へ移行できます。ループ・カウンタ変数がコピーされ、状態は維持されます。
例外ハンドラ内のアクティビティを移行のソースおよび宛先にすることができます。ハンドラが完了すると、例外ハンドラが定義されているブロックの後から実行を開始します。
scopeコンテナ・アクティビティへの移行時には、Oracle BPEL Serverはscopeを開き、scope内のコンテナでない最初のアクティビティを実行します。
インスタンスの移行時には、新しい実行ポイントを宛先プロセスの任意のアクティビティにすることができます。ただし、flowNアクティビティに属するアクティビティは除きます。
flowアクティビティに移行すると、Oracle BPEL Serverはflowを開き、その中のパラレル・スレッドを実行します。
変数は新しいプロセス・インスタンスに自動的にコピーされます。変数マッピングは、変数名とその場所によって語彙スコープ・チェーンで行われます。プロセス・スコープだけは例外です。その場所では、スコープ（あれば）によって語彙的にどのように隠されているかに関係なく、変数はプロセス間でコピーされます。
変数移行に関する次の詳細情報に注意してください。
変数はプロセス・スコープからプロセス・スコープへコピーされます。
変数は、可視性と語彙ルールに従って、各ソースのスタック・フレームからコピーされます。
変数が宛先プロセスに存在しない場合は、コピーされず、警告メッセージが発行されます。
宛先プロセスに新しい変数が含まれる場合は、ログ・ファイルに次のようなメッセージが表示されます。
<2009-07-15 03:06:25,381> <WARN> <default.collaxa.cube.engine.migrate> <CubeEngine::migrateVariables> Scope "rootScope@6" has a variable "newPickService_InputVariable" which is NOT defined in the source scope(s).
このような新規変数は初期化されていないことに注意してください。
宛先プロセスに変数が存在する場合は、コピーが成功するように変数に互換性を持たせる必要があります。
宛先プロセスに存在する変数は、インスタンス化して初期化されているだけです。
エンドポイントは移行できます。プロセス・インスタンスを移行すると、そのインスタンスへの保留中のコールバックはすべて、新しい移行後のインスタンスへルーティングされます。
この項では、Oracle BPEL Controlからインスタンスの移行を実行する方法について説明します。
|
注意: 移行するためには、通常はすでにデプロイされた複数のリビジョンのプロセスが必要です。そうでない場合は、移行を実行すると、同じリビジョンに移行されます。同じリビジョンへの移行は、開発やテストのフェーズでは役立つ場合があります。 |
Oracle BPEL Controlにログインします。
次のいずれかの移行方法を選択します。必要に応じて、移行元のインスタンスを初期化します。
「プロセス」タブから:
このオプションにより、プロセス・リビジョンのすべてのインスタンスを移行できます。
「プロセス」タブをクリックします。
移行元のプロセス・リビジョンを選択します（たとえば、MigrationTestReceive2Assign (v. 1.0)を選択）。移行ページで宛先の定義を選択します。
|
注意: ユーザー・インタフェースでは、名前の異なる複数のプロセス（たとえば、OrderBooking（v. 1.0）とLoanFlow（v. 1.0））を選択することは禁止されません。ただし、このような選択はサポートされていません。 |
ページの下部にある「プロセス・インスタンスの移行」をクリックします。
手順3に進みます。
「インスタンス」タブから:
このオプションにより、プロセス・リビジョンの単一のインスタンス、またはすべてのインスタンスが同じBPELプロセスに属する場合は複数のインスタンスを移行できます。
「インスタンス」タブをクリックします。
移行元のインスタンスを選択します。移行ページで宛先の定義を選択します。
|
注意: ユーザー・インタフェースでは、名前の異なる複数のインスタンス（たとえば、OrderBooking（v. 1.0）のインスタンス1001とLoanFlow（v. 1.0）のインスタンス275）を選択することは禁止されません。ただし、このような選択はサポートされていません。 |
ページの下部にある「移行」をクリックします。
手順3に進みます。
特定のBPELインスタンスの「監査」または「フロー」タブから:
「移行」をクリックします。
手順3に進みます。
移行ページを表示します。
ソースのプロセス定義がページの左側に表示されます。これは古い方のリビジョンです。宛先のプロセス定義がページの右側に表示されます。中央の列は、ソース・プロセスから宛先プロセスへのマッピングを表します。
マッピングは、作業アイテムを新しいプロセス定義で実行するように移行する方法を表します。プロセスは特定のタイプのアクティビティでのみデハイドレートするため、これらのアクティビティのみをルール・マッピングの左列に表示します。
指定したプロセス・インスタンスを移行するためのマッピングを実行します。移行が成功すると、ソースのプロセス・インスタンスは終了し、新しいプロセス・インスタンスが指定した移行ポイントから続行します。すべての変数、パートナ・リンク状態などが新しいプロセス・インスタンスにコピーされます（互換性がある場合）。
|
注意: pick、switch、flowなどの分岐アクティビティをInternet Explorer 7を使用して開く場合、クローズされたブランチが追加で横に外れて表示されます。この追加のブランチは無視してかまいません。 |
宛先ツリーのドロップダウン・リストから、移行先のバージョンを選択します。この例では、リビジョン2.0が選択されています。
ソースのプロセス定義から、移行元のアクティビティを選択します。たとえば、receiveアクティビティを選択します。
宛先のプロセス定義から、移行先のアクティビティを選択します。たとえば、assignアクティビティを選択します。これにより、中央列にassignアクティビティが表示されます。
移行のアクティビティを無効にするには、中央列でそのアクティビティのプラス・アイコンを選択します。
|
注意: 移行するアクティビティを手動で選択する必要があります（たとえば、receiveアクティビティまたはwaitアクティビティを選択してassignアクティビティに移行します）。これにより、アクティビティを新しいリビジョンに移動するために、デハイドレーション・ポイントにマッピング・ルールが作成されます。デハイドレーション・ポイントにマッピング・ルールを作成しないと、「インスタンスの移行」をクリックしても移行は実行されません。 |
マッピングを移行マップに保存して後で再使用できるようにするには、「保存」をクリックします。保存しない場合は、手順9に進みます。
移行マップは、古いプロセスから新しい宛先プロセスにどのようにスレッドを作成するかを定義します。各ルールには、ソースのアクティビティIDと宛先のアクティビティIDが含まれます。移行マップには、移行するソースのプロセス名、宛先のプロセス名、インスタンスIDの埋込みリストも含まれます。
マッピングを保存するファイルの名前を入力し、「OK」をクリックします。
テンプレートの名前と場所を確認するプロンプトが表示されたら、「OK」をクリックします。
「移行マップ」をクリックします。
保存されたマップのリストが表示されます。
使用するマップを選択します。
「インスタンスの移行」をクリックして宛先インスタンスを作成します。
表示されるメッセージを確認し、「移行」をクリックします。移行マッピングが後で使用できるように保存されます。
次のメッセージが表示されます。
「OK」をクリックします。
移行に関する特定の詳細情報を表示するには、「ログの表示」をクリックします。
「インスタンス」タブをクリックします。
移行先の宛先インスタンスをクリックします。
「フロー」をクリックします。
宛先リビジョンに古いリビジョンのフロー・トレースへのリンクが含まれていることに注目してください。
リンクをクリックします。
古いバージョンのフロー・トレースが表示されます。新しいリビジョンへのリンクはフローの下部に表示されます。古い方のプロセス・インスタンスはクローズとしてマークされ、取り消されます。
移行ログを表示するには、次の2通りの方法があります。
「確認」ダイアログで「ログの表示と移行」をクリックします。
移行ページの右上のセクションで「ログの表示」リンクをクリックします。
単一のBPELプロセス・インスタンスまたは中間層Oracle SOA Suiteインストールにデプロイされた大量のインスタンスを移行しようとしていて、移行ログを表示しようとすると、空のログ・ウィンドウが表示される場合があります。次の手順を実行してOc4jSetパラメータを設定します。これにより、正しいログ・ファイル出力が得られます。必ずOc4jSetパラメータを設定することをお薦めします。
$ORACLE_HOME/Apache/Apache/conf/mod_oc4j.confファイルを開きます。
タグIfModule mod_oc4j.cの内側にOc4jSet flush trueを追加します。
<IfModule mod_oc4j.c>
Oc4jSet flush true
</IfModule>
Oracle HTTP Serverを再起動して、構成の変更を有効にします。
10.1.3.5より前のリリースでは、Oracle BPEL ControlでBPELプロセスの自動リカバリを永続的に有効にすると、インスタンスの重複リカバリが発生する可能性がありました。
たとえば、Oracle BPEL Serverが作業中のプロセス・インスタンスをリカバリ・キューに一時的に入れたとします。このインスタンスがリカバリ・キューにあるときに自動リカバリが実行されると、そのインスタンスが選択されてリカバリされます。そのすぐ後で、BPELが元のインスタンスのリカバリを開始すると、結果として2つの同じインスタンスに対して、重複して出力されます。
このリリースでは、Oracle BPEL ControlにthreshHoldTimeInMinutesという名前の新しいプロパティが追加されました。これにより、時間のしきい値を設定し、新たに受信したメッセージをそのしきい値を超えるまで自動リカバリに再送信しないようにすることができます。
デフォルト値は10分です。このプロパティにアクセスするには、Oracle BPEL Controlで「構成」→「自動リカバリ」を選択します。
このリリースで、Oracle BPEL管理コンソールにserverModeという名前の新しいプロパティが追加されました。このプロパティには次の値を設定できます。
production: 同じリビジョンでのプロセスの再デプロイを許可しません。
development: 同じリビジョンでプロセスを再デプロイすると既存のインスタンスを失効としてマークします。
promiscuous: 同じリビジョンでプロセスを再デプロイしてもインスタンスを失効にしません。作業アイテムは移行されます。
この項では、Oracle WebLogic ServerでのOracle SOA Suiteの使用に特有の問題とその回避方法について説明します。
5.9.3項「Oracle BPELワークリスト・アプリケーションに接続するためのOracle Internet Directoryの構成」
5.9.8項「Oracle WebLogic Server固有のJARファイルを使用してBean定義ファイルを生成できない」
アップグレード・スクリプトを実行して、orabpelスキーマとoraesbスキーマをバージョン10.1.3.xからそれ以上のバージョンにアップグレードすると、スキーマの一部のオブジェクトが無効になります。
次のSQLコマンドをorabpelユーザーとして実行し、orabpelスキーマのすべての無効なオブジェクト表示します。
select object_name from user_objects where status like '%INVALID%';
同じコマンドをoraesbユーザーとして実行し、oraesbスキーマのすべての無効なオブジェクト表示します。
UTL_RECOMPパッケージ関数を実行して、無効なorabpelオブジェクトを再コンパイルします。
EXEC UTL_RECOMP.recomp_serial('ORABPEL');
これにより、orabpelスキーマ内の無効なorabpelオブジェクトがすべて再コンパイルされます。
UTL_RECOMPパッケージ関数を実行して、無効なoraesbオブジェクトを再コンパイルします。
EXEC UTL_RECOMP.recomp_serial('ORAESB');
これにより、oraesbスキーマ内の無効なoraesbオブジェクトがすべて再コンパイルされます。
|
注意: orabpelユーザーまたはoraesbユーザーは、UTL_RECOMPパッケージを使用できないことがあります。場合によっては、このスクリプトをsysユーザーとして実行してください。 |
$ORACLE_HOME/bpel/samplesディレクトリにあるサンプルには、oc4j-ra.xmlファイルの構成に関する参照が多数含まれています。このファイルは、JCAアダプタ（リリース10.1.3.5.1のOracle WebLogic Server構成）には関係ありません。Oracle WebLogic Serverで作動するJCAアダプタの構成方法は、『Oracle SOA Suite WebLogic Serverのためのインストレーション・ガイド』の次の項を参照してください。
アダプタ・サンプルの実行に関する項
Weblogicでのアダプタ用アウトバウンド接続プールの構成に関する項
このマニュアルは、Oracle Technology Networkの次のURLから入手できます。
http://download.oracle.com/docs/cd/E12524_01/nav/portal_booklist.htm
次の手順を実行して、Oracle Internet Directory 10.1.4.3をOracle BPELワークリスト・アプリケーションに接続します。これを実行しないと、Oracle BPELワークリスト・アプリケーションへの接続を試行するときにログイン失敗のエラーが発生します。
管理対象のOracle WebLogic Serverを停止します。
既存の$ORACLE_HOME/bpel/system/services/config/is_config.xmlファイルをバックアップします。
$ORACLE_HOME/bpel/system/services/config/ldap/is_config_for_OID.xmlを$ORACLE_HOME/bpel/system/services/config/is_config.xmlにコピーします。
is_config.xmlが有効なOracle Internet Directoryリポジトリを指すように更新します。
既存の$ORACLE_HOME/j2ee/home/config/jazn.xmlファイルのバックアップを作成し、同じ場所にjazn.xml.origとして保存します。
$ORACLE_HOME/j2ee/home/config/jazn.xmlを開きます。
XMLプロバイダを使用するセクションをコメント・アウトします。
LDAPを使用するセクションを非コメント化し、次のようなOracle Internet Directoryプロバイダの詳細を指定します。
<jazn provider="LDAP" location="ldap://myhost-4.us.oracle.com:40864" default-realm="us"> <property name="ldap.user" value="cn=orcladmin"/> <property name="ldap.password" value="!welcome1"/> <property name="ldap.protocol" value="no-ssl"/> </jazn>
管理対象のOracle WebLogic Serverを再起動します。
クラスタ環境でファイル・アダプタを使用する場合、フェイルオーバー時のメッセージ処理が正常に行われるように必ず次の手順を実行します。
$ORACLE_HOME/soa/connectors/FileAdapter/META-INF/weblogic-ra.xmlファイルを開きます。
次の値を含むようにファイルを更新します。
<pool-params> <initial-capacity>50</initial-capacity> <max-capacity>2147483647</max-capacity> <capacity-increment>100</capacity-increment> <shrinking-enabled>true</shrinking-enabled> <match-connections-supported>false</match-connections-supported> <shrink-frequency-seconds>60</shrink-frequency-seconds> <connection-creation-retry-frequency-seconds>2</connection-creation-retry-fre quency-seconds> <connection-reserve-timeout-seconds>5</connection-reserve-timeout-seconds> <use-first-available>true</use-first-available> </pool-params>
自動車ローンのBPELサンプルが正しく機能するためには、bpel.xmlファイルに対して次の更新を実行する必要があります。これを実行しないと、例外エラーが発生します。
プロジェクトのbpel.xmlファイルを開きます。
<partnerLinkBinding name="LoanAdvisorAgentPL">セクションの下に次の構文があります。
<property
name="wsdlRuntimeLocation">http://${hostname}:${http_port}/rules/${domain_id}/
${process_id}/${process_revision}/ LoanAdvisorAgent
/LoanAdvisorAgent?WSDL</property>
次のように変更します。
<property
name="wsdlRuntimeLocation">http://${hostname}:${http_port}/rules/${domain_id}/
${process_id}/${process_revision}/LoanAdvisorAgent?WSDL</property>
次のファイルを開きます。
AutoLoanFlow\decisionservices\CreditRatingAgent\ear\META-INF\application.xml
AutoLoanFlow\decisionservices\LoanAdvisorAgent\ear\META-INF\application.xml
これら両方のファイルに次の構文があります。
< application version="1.4" xmlns="http://java.sun.com/xmlns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd">
次のように変更します。
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/j2ee/dtds/application_1_3.dtd"> <application>
自動車ローン・デモをデプロイするときに、deployDecisionServicesターゲットでエラーが発生することがあります。
回避方法として、次の手順を実行します。
開発者用のプロンプトでJAVA_HOMEを$ORACLE_HOME/jdkに設定します。
deployDecisionServiceターゲットは、コンパイル用のシステム・クラスパスを使用し、他のobantタスクのようにclient_classpathは使用しません。
obant.shのかわりにantを使用して自動車ローン・デモをデプロイします。
$ORACLE_HOME/bpel/samples/tutorialsディレクトリの127.OrderBookingTutorialは、antを使用すると正常にデプロイされません。ただし、BUILD SUCCESFULLメッセージは表示されます。
これは、127.OrderBookingTutorialのようなチュートリアルにはEAR/WARファイルのデプロイが含まれており、後で手動のデプロイ手順を実行する必要があるためです。次のEAR/WARファイルが$ORACLE_HOME/j2ee/home/applicationsディレクトリに生成され、使用できるようになります。これらを、Oracle WebLogic Server管理コンソールを使用して手動でデプロイする必要があります。
CreateOrderBookingUI.war
SelectManufacturingUI.war
default_OrderApproval_1_0_OrderApproval.ear
default_SelectManufacturing_1_0_Approval.ear
127.OrderBookingTutorialに含まれるBPELおよびESBコンポーネントは、antを使用すると自動的にOracle WebLogic Server管理コンソールにデプロイされることに注意してください。
GenerateBeanDefinitionタスクおよびGenerateWSDLタスクは、古いWeblogic EJBプロジェクトに対して実行できません。Weblogic Workshop 10.3以上を使用して、WSIF-EJBバインディングantツールで使用するためのEJBプロジェクトを生成します。
コレクション・クラスがメソッド記述に含まれるEJBクラスのBean定義ファイルを生成する場合、次のシステム・プロパティを追加してXDKパーサーを指定する必要があります。これを実行しないと、Bean定義の生成中に例外エラーが発生します。
太字で示しているプロパティを含むようにGenerateBeanDefinitionタスクを更新します。
<target name="GenerateBeanDefinition" depends="">
<BeanDefinitionGenerator
jarLocation="${jarLocation}"
beanDefinitionLocation="${beanDefinitionLocation}"
pkg="hello.*,databindingtestejb.*,com.otn.samples.sessionbean.*"
logLevel="debug"
jvmArgs="-Dhttp.proxyHost=www-proxy.us.oracle.com
-Dhttp.proxyPort=80 -DproxySet=true
-Djavax.xml.parsers.DocumentBuilderFactory=oracle.xml.jaxp.JXDocumentBuilderFa
ctory"
failonerror="true">
</BeanDefinitionGenerator>
</target>
GenerateWSDLタスクも同様に更新します。
BeanファイルおよびWSDLファイル生成の詳細は、5.8.11.2項「Bean定義の生成」を参照してください。
手動のワークフローを含むアプリケーションをデプロイすると、TaskActionHandlerとTaskManagerもデプロイ済プロセスとしてOracle BPEL Controlに表示されるはずです。TaskManagerが表示されない場合は、次の回避方法を実行します。
Oracle BPEL Controlを停止します。
bpel_TaskActionHandler.jarが次の場所にあります。
SOA_Oracle_Home/bpel/install/extensions
次の場所にコピーします。
SOA_Oracle_Home/bpel/domains/domain_name/deploy
domain_nameは、手動ワークフロー・アプリケーションがデプロイされるドメインの名前です。
wsif-ejb-tool.xmlファイルを更新します。
.\..\..\..\wlserver_10.3\server\lib\weblogic.jarをプロパティ名のクラスパスに追加します。
<?xml version="1.0"?>
<project name="wsif-ejb-binding" default="" basedir=".">
<property name="classpath" value=".\..\..\..\wlserver_10.3\server\lib\weblogic.jar;
.\..\lib\xmlparserv2.jar;.\..\..\webservices\lib\saaj-api.jar;.\..\..\
webservices\lib\wsa.jar;.\..\..\webservices\lib\wsclient.jar;.\..\..\
webservices\lib\wsserver.jar;.\..\..\webservices\lib\jaxrpc-api.jar;.\..\..\
webservices\lib\orasaaj.jar;.\..\..\webservices\lib\orawsdl.jar;.\..\..\
webservices\lib\orawsmetadata.jar;.\..\..\j2ee\home\lib\ejb30.jar;.\..\..\
j2ee\home\lib\ejb.jar;.\..\..\j2ee\home\lib\mail.jar;.\..\..\j2ee\home\lib\
http_client.jar;.\..\lib\wsif-ejb-design.jar"/>
Oracle BPEL Controlを再起動します。
Oracle BPEL Controlにログインすると、選択できるドメインが1つしない場合でもドメイン・ピッカー・ページが毎回表示されます。そのドメインを選択して続行します。
