この章では、Oracle BPEL Process Managerに関連する問題について説明します。内容は次のとおりです。
この項では、次の問題と回避方法について説明します。
WindowsおよびLinuxでパッチ10.1.3.4を削除すると、次の状態が発生します。
パスワードがクリアテキストで表示されます。
パスワードの入力を3回要求されます。
入力したパスワードが検証されず、削除が続行されます。
IRCA.SH
を実行してOracle BPEL Process Managerスキーマをデータベースに入力した後、orabpel
、oraesb
およびorawsm
のパスワードが、LinuxまたはUNIXでは/tmp
ディレクトリ、Windowsでは定義した一時ディレクトリにあるログ・ファイルにクリアテキストで表示されます。このディレクトリのファイルは必ず削除してください。
Oracle BPEL Process Managerを「基本インストール」オプションでインストールすると、Oracle Database Lite(Olite)がインストールされます。このインストールに10.1.3.4パッチを適用すると、Oracle BPEL Controlの「インスタンス」タブの下にあるBPELプロセス・インスタンスが表示されません。
回避方法として、「拡張インストール」オプションを使用すれば、Olite以外のデータベースをインストールできます。
中間層にインストールされたスタンドアロンのOracle BPEL Serverをアップグレードした後、タスクの詳細アプリケーションが起動しません。
回避方法として、Oracle Enterprise Managerにログインし、タスクの詳細アプリケーションを手動で起動します。
パッチ10.1.3.4の適用後、Oracle BPELワークリスト・アプリケーションなどのアプリケーションが起動しないことがあります。この状態が発生した場合、Oracle Enterprise Managerにログインして、それらのアプリケーションを再起動する必要があります。
Oracle Enterprise Manager 10g Application Server Controlコンソールにログインします。
http://hostname:port/em
「アプリケーション」をクリックします。
「表示」リストで「アプリケーション」を選択します。
アプリケーションのリストを表示し、現在実行されていないアプリケーションを確認します。
再起動の必要があるアプリケーションを選択し、「再起動」をクリックします。
この項では、次の問題と回避方法について説明します。
リリース10.1.3.4を単一インスタンス・データベース環境で使用する場合、またはデハイドレーション・ストアとしてOracle Real Application Clustersデータベースとともに使用する場合は、SOA_Oracle_home
\j2ee\oc4j_soa\config\data-sources.xml
ファイルでXAデータソースを使用するためにBPELPM_CONNECTION_POOL
を設定します。
<connection-pool name="BPELPM_CONNECTION_POOL">
<connection-factory factory-class="oracle.jdbc.xa.client.OracleXADataSource"
. . .
. . .
</connection-pool>
注意: この項では、『Oracle BPEL Process Manager管理者ガイド』の第2章「サービス構成」の、Oracle Internet DirectoryがOracle Application Serverインスタンスに関連付けられている場合に関する項に影響を与える、hw_services.ear ファイルに対する変更について説明します。 |
hw_services.ear
ファイルは、hw_services.ear
ファイルとdeploy_service.ear
という、次のような新しいEARファイルに分割されました。
orabpel
を親としてoc4j_soa
にインストールされます。
デプロイメント・モジュールを含みます。
BPELプロセスのデプロイはすべて、hw_services.ear
ではなく、deploy_service.ear
を経由するようになりました。Oracle Enterprise Managerで、orabpelとhw_servicesの両方にOracle Internet Directoryを使用するようにセキュリティ・プロバイダが構成されていると、デプロイは失敗します。これは、新しいdeploy_serviceモジュールがデフォルトでファイルベースのセキュリティ・プロバイダを使用するように構成されているためです。
デプロイの失敗を防ぐには、次の手順を実行して、Oracle Enterprise Managerでdeploy_serviceのセキュリティ・プロバイダを、ファイルベースからOracle Internet Directoryに変更します。
Oracle Enterprise Manager 10g Application Server Controlコンソールにログインします。
http://hostname:port/em
「oc4j_soa」→「管理」→「セキュリティ」→「セキュリティ・プロバイダ」に移動します。
「セキュリティ・プロバイダ」を開きます。
deploy_serviceという新しいアプリケーションが、orabpelを親として表示されます。セキュリティ・プロバイダは、デフォルトではファイルベースです。
「orabpel」→「deploy_service」→「管理」→「セキュリティ」→「セキュリティ・プロバイダ」に移動します。
「セキュリティ・プロバイダの変更」をクリックします。
「Oracle Identity Managementセキュリティ・プロバイダ」を選択します。
「OK」をクリックします。
Oracle Application Serverを再起動します。
opmnctl stopall opmnctl startall
Oracle Enterprise Manager 10g Application Server Controlコンソールでorabpelおよびhw_servicesに対するシングル・サインオン(SSO)を有効にする場合、新しいdeploy_serviceに対するSSOは一緒に有効にしないでください。
Oracle JDeveloperのデザイナ・ウィンドウで相関セットのプロパティ・エイリアスを作成し、同じプロパティ・エイリアスの複数のエントリを作成すると、BPELアーティファクト・ファイルで2番目のエントリにより最初のエントリが上書きされます。これは、BPELプロセスのコンパイル時に問題が発生する原因となります。
回避方法としては、Oracle JDeveloperの左下隅にある構造ウィンドウで、(同じプロパティを参照する)2番目のプロパティ・エイリアスの定義を作成します。
次の手順に従い、UDDIサービスを呼び出すようにBPELプロセスを構成します。
Oracle BPEL Controlで、「構成」→「ドメイン」を選択します。
uddiLocatonプロパティでUDDI照会URLを指定します。
Oracle BPEL Serverを再起動します。
Oracle JDeveloperのUDDIレジストリ接続の作成ウィザードを使用してUDDI接続を作成します。
デザイナにパートナ・リンク・アクティビティをドラッグ・アンド・ドロップします。
パートナ・リンクの作成ウィンドウで「サービス・エクスプローラ」アイコンを選択します。
「UDDIレジストリ」フォルダの下のUDDIサービスを選択します。
「OK」をクリックします。
registryServiceKey
をbpel.xml
に追加します。
<partnerLinkBinding name="HelloBPELProcess">
<property name="wsdlLocation">wsdllocation</property>
<property name="registryServiceKey">uddi:6644</property>
</partnerLinkBinding>
注意: セキュアなUDDIサービスのHTTPS呼出しは、リリース10.1.3.4ではサポートされていません。 |
BPEL JavaクライアントAPIを使用する際に必要なJARファイルの最小リストは、Oracle BPEL Process Managerを使用している環境に基づきます。表5-1に、必須ファイルを示します。
この項では、次の問題と回避方法について説明します。
Oracle BPELワークリスト・アプリケーションをアンデプロイするためのアンデプロイ機能は、Oracle Enterprise Managerでサポートされていません。ワークリスト・アプリケーションのアンデプロイではBPELアプリケーションはアンデプロイされませんが、タスク・アプリケーションはアンデプロイされます。このため、ワークリスト・アプリケーションではタスクの詳細を表示できません。この問題を回避する方法はありません。
Oracle Real Application Clustersデータベースをデハイドレーション・ストアとして使用する場合は、SOA_Oracle_Home
\bpel\system\config\collaxa-config.xml
ファイルでnonFatalConnectionMaxRetry
プロパティの値をデフォルト値の2
から5
に増やすことをお薦めします。この設定により、Oracle Real Application Clustersインスタンスのフェイルオーバーが発生した場合に、Oracle BPEL Process Managerで十分な接続試行が実行されます。
Microsoft VistaおよびWindows 2008システムへのBPELプロセスのデプロイにOracle JDeveloperまたはobant
を使用する場合は、SOA_Oracle_Home
\bpel\utilities\ant-orabpel.properties
ファイルの次の行を変更する必要があります。
hostname = hostname.us.oracle.com
次のように変更します。
hostname = 127.0.0.1
変更しないと、プロセスのデプロイが失敗します。
この項では、次の問題と回避方法について説明します。
XSLTマッパーが、xmlparserv2.jar
ファイルによる問題のために、設計ビューで開かないことがあります。ソースまたはターゲット・スキーマが開けないという次のエラー・メッセージが表示されます。
Failed to open the source schema: Invalid value 'enumeration' specified for facet '{1}'.
回避方法として、次のコマンドでxmlparserv2.jar
ファイルからXMLDocument.class
ファイルを抽出し、このXMLDocument.class
ファイルが入ったXMLDocument.jar
ファイルをpatches
ディレクトリに作成します。
jdk\bin
ディレクトリが自分のパスにあることを確認するか、jar.exe
へのフルパスを指定します。
次のコマンドを入力します。
cd jdev_home/lib
jar xvf xmlparserv2.jar oracle/xml/parser/v2/XMLDocument.class
jar cvf ../jdev/lib/patches/XMLDocument.jar oracle/xml/parser/v2/XMLDocument.class
この項では、次の問題と回避方法について説明します。
5.5.1項「Oracle Internet DirectoryおよびOracle BPELワークリスト・アプリケーションでのSSLの使用方法」
5.5.2項「スキーマでuid属性を使用しないActive Directoryまたはその他のLDAPサーバーの構成要件」
5.5.3項「ヒューマン・ワークフローがActive Directoryで構成される場合、Oracle BPELワークリスト・アプリケーションの標準ビューが機能しない」
Oracle Internet DirectoryをOracle BPELワークリスト・アプリケーションのアイデンティティ・プロバイダとして使用し、10.1.3.4へのアップグレード後にSecure socket layer(SSL)接続モードの使用を希望する場合、SOA_Oracle_Home
\bpel\system\services\config\
is_config.xml
ファイルでconnection
要素の下に次の要素を追加する必要があります。Oracle Internet Directoryに対して非SSL接続を使用している場合は、このファイルを変更しないでください。
<property name="SSLSocketFactoryImplClass" @ value="oracle.tip.pc.services.identity.common.SSLSocketFactoryImpl"/> <property name="securityProtocol" value="ssl"/> <pool initsize="2" maxsize="25" prefsize="10" timeout="60"/>
uid
スキーマ属性を使用しないActive Directoryまたは別のLDAPサーバーでヒューマン・ワークフローを使用し、10.1.3.4にアップグレードする場合、SOA_Oracle_Home
\bpel\system\services\config\
is_config.xml
ファイルにnicknameAttribute
プロパティとsAMAccountName
属性を追加する必要があります。このプロパティと属性は、ユーザー・ログイン認証に使用されます。
これらのコンポーネントを追加しないと、認証の失敗の原因になります。これは、Active Directoryでは、Oracle Internet Directory、iPlanet、openLDAPなどの他のLDAPサーバーと異なり、ユーザー・ログイン認証にuid
属性が使用されないためです。
nicknameAttribute
プロパティでは、アイデンティティ・サービス認証に使用されるLDAP属性の名前を定義します(デフォルト値はuid
)。この属性の値は、name
属性に移入され、アイデンティティ・サーバーでユーザーを一意に識別します。nameAttribute
プロパティは、Users
DNで使用されるname
属性を意味します。たとえば、次のようなUsers
DNの場合を考えてみます。
cn=jcooper, cn=Users,dc=us,dc=oracle,dc=com
nameAttribute
を次のように定義します。
<property name="nameAttribute" value="cn"/>
nicknameAttribute
プロパティは、is_config.xml
で上書きされていないかぎり、デフォルトのuid
値が使用されるすべてのLDAPサーバーに関連します。大部分のLDAPサーバーでは、uid
属性がサポートされています(詳細はinetOrgPerson
オブジェクト・クラスを参照)。
Active Directoryなどのプロバイダで、LDAPスキーマのuid
属性がサポートされていないか、認証に異なる属性を使用する場合、nicknameAttribute
プロパティを次のように使用して、name
属性を上書きできます。
<?xml version = '1.0' encoding = 'UTF-8'?> <ISConfiguration xmlns="http://www.oracle.com/pcbpel/identityservice/isconfig"> <configurations> <configuration realmName="AD" > <provider providerType="LDAP" name="Active Directory" service="Identity"> <connection url="ldap://host:port" binddn="cn=administrator,cn=Users,dc=us,dc=oracle,dc=com" password="welcome1" encrypted="true"> <pool initsize="2" maxsize="25" prefsize="10" timeout="300000"/> </connection> <userControls> <property name="nameAttribute" value="cn"/> <property name="nicknameAttribute" value="sAMAccountName"/> <property name="objectClass" value="user"/> <search searchbase="cn=Users,dc=us,dc=oracle,dc=com" scope="subtree" maxSizeLimit="1000" maxTimeLimit="120000"/> </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" scope="subtree" maxSizeLimit="1000" maxTimeLimit="120000"/> </roleControls> </provider> </configuration> </configurations> </ISConfiguration>
Active Directoryでヒューマン・ワークフローを使用すると、Oracle BPELワークリスト・アプリケーションの標準ビューが機能しません。
Oracle BPELワークリスト・アプリケーションで「ユーザー・タスク」→「ユーザー作業キュー」→「標準ビューに移動します。
「高優先度のタスク」、「期日の近いタスク」、「新規タスク」の標準ビューをクリックします。
次のような例外エラーがユーザー・インタフェースに表示されます。
Internal Error in Verification Service for user createContext. {1}. If you need more information, please check with your administrator with the following exception-identifier: "*2008/07/15_02:04:03:826_jstein*"
Oracle BPELワークリスト・アプリケーションでタスクを承認しようとして、次のエラー・メッセージが表示された場合、Oracle BPEL Serverを再起動します。
次のメッセージが、Oracle BPELワークリスト・アプリケーションに表示されます。
your request was not successful
次のエラー・メッセージが、Oracle BPEL Serverログ・ファイルに表示されます。
<2008-06-05 19:05:30,246> <ERROR> <oracle.bpel.services.workflow> <::> The Scheduler has been shutdown. org.quartz.SchedulerException: The Scheduler has been shutdown. at org.quartz.core.QuartzScheduler.validateState(QuartzScheduler.java:502) at org.quartz.core.QuartzScheduler.unscheduleJob(QuartzScheduler.java:678) at org.quartz.impl.StdScheduler.unscheduleJob(StdScheduler.java:268) at oracle.bpel.services.workflow.task.impl.WorkflowTimerAgent.unscheduleExpiratio n(WorkflowTimerAgent.java:294) at oracle.bpel.services.workflow.task.impl.WorkflowTimerAgent.unscheduleExpiratio n(WorkflowTimerAgent.java:282) at oracle.bpel.services.workflow.task.impl.WorkflowTimerAgent.rescheduleExpiratio n(WorkflowTimerAgent.java:321) at oracle.bpel.services.workflow.task.impl.WorkflowTimerAgent.scheduleTimers(Work flowTimerAgent.java:115) at oracle.bpel.services.workflow.task.impl.TaskService.performPostActionOperation (TaskService.java:3062) at oracle.bpel.services.workflow.task.impl.TaskService.performPostActionOperation (TaskService.java:2918)
アクション可能な電子メールのレスポンスが送信されていない(たとえば、アクション可能な電子メールで提供されているリンクを使用して、タスクを承認または拒否できない)場合、使用されている電子メール・クライアントをシステムのデフォルトのメール・クライアントにします。たとえば、Microsoft Windows XPでデフォルトの電子メール・クライアントを設定するには、次の手順を実行します。
「スタート」メニューに移動します。
「コントロール パネル」→「インターネット オプション」→「プログラム」を選択します。
デフォルトの電子メール・クライアントとしてその電子メール・クライアントを選択します。
大/小文字を区別しない場合のワークフロー・サービスの動作は次のようになります。
タスク・メタデータ(.task
ファイル)でのOracle BPELワークリスト・アプリケーションへのログイン時、ユーザー名は大/小文字のどちらでもかまいません。
データベースでのユーザー名はすべて小文字です。
ユーザー名の場合のみ、大/小文字を区別しません。グループ名は、ユーザー・ディレクトリで指定したものと同一にする必要があります。
タスク属性assigneeUsers
、acquiredBy
、updatedBy
(コメントおよび添付ファイルも)、creator
、ownerUser
およびfromUser
の値は、常に小文字です。
ユーザー・ディレクトリにない作成者は、小文字で保存されます。デフォルトの動作では、大/小文字が区別されます。これは、大/小文字を区別するユーザー・ディレクトリに対して使用するのが理想的です。
ワークフロー構成は、大/小文字を区別する場合としない場合のどちらでも、基礎となるユーザー・ディレクトリと一致する必要があります。ワークフロー・サービスが大/小文字を区別するように構成されている場合(デフォルトの構成)、ワークフロー・ユーザー名は、ユーザー・ディレクトリ内のものと正確に一致する必要があります。
ワークフロー・サービスでワークフローのユーザー名について大/小文字が区別されないようにする際、ワークフロー・データがデータベースにある場合は、ユーザー・データが10.1.3.4パッチの機能と一致するようにデータをアップグレードします。データはSOA_Oracle_home
\bpel\system\database\scripts\upgrade_WFUserIgnoreCase.sql
スクリプトを使用してアップグレードします。ルール・ディクショナリに格納されているタスク割当てルールはアップグレードされず、再作成する必要があります。
ワーフロー・サービスが大/小文字を区別せずに機能するようにする場合、is_config.xml
ファイルおよびwf_client_config.xml
ファイルを更新する必要があります。is_config.xml
では、ISConfiguration
要素内に<property name="caseSensitive" value="false"/>
を追加します。
<?xml version = '1.0' encoding = 'UTF-8'?>
<ISConfiguration
xmlns="http://www.oracle.com/pcbpel/identityservice/isconfig">
<configurations>
...........
</configurations>
<property name="caseSensitive" value="false"/>
</ISConfiguration>
ワークフロー・サービス・クライアントがカスタム・アプリケーションによって使用される場合、wf_client_config.xml
ファイルは次のように変更する必要があります。
<servicesClientConfigurations
xmlns="http://xmlns.oracle.com/bpel/services/client">
.....
<caseSensitive>false</caseSensitive>
</servicesClientConfigurations>
is_config.xml
ファイルが更新された場合、Oracle BPEL Serverを再起動します。
これらの設定の結果、それぞれのアイデンティティ・プロバイダでは次のように動作します。
大/小文字を区別するアイデンティティ・プロバイダ
caseSensitive
をfalse
に設定しても影響はありません。たとえば、アイデンティティ・プロバイダで指定されているユーザーがjcooper
であるとします。アイデンティティ・サービス・プロバイダが大/小文字を区別するため、Jcooper
でログインすると失敗します。
大/小文字を区別しないアイデンティティ・プロバイダ
caseSensitive
がtrue
に設定されるまで、jcooper
と同一であるJcooper
に割り当てられたタスクは、jcooper
受信ボックスには表示されません。ただし、caseSensitive
をfalse
に設定すると、Jcooper
に割り当てられたタスクはjcooper
受信ボックスに表示されます。
アイデンティティ・サービスの構成プロパティはすべて大/小文字が区別され、同じCamelCase表記法に従う必要があります。この問題は、すべての10.1.3.xリリースに該当します。大/小文字を正しく使用しないと、指定したプロパティ値が無視され、BPELアイデンティティ・サービスではデフォルトのプロパティ値が使用されます。次のプロパティでは、大/小文字を示されたとおりに使用する必要があります。
usersPropertiesFile
nicknameAttribute
nameAttribute
objectClass
memberAttribute
membershipSearchScope
roleOwnerAttribute
caseSensitive
アクション可能な電子メールの場合、必ずヒューマン・ワークフロー・システム用とエンド・ユーザー通知用に異なる電子メール・アドレスを使用してください。両方の電子メール・アドレスが同じ場合、予期できない動作が発生する可能性があります。これは、エンド・ユーザー(たとえば、jstein
)に送信されたアクション可能な通知は、jstein
が見る前に、ヒューマン・ワークフロー・システムによってアクセス(および電子メール・サーバーから削除)される可能性があるためです。
異なるアドレスは、次のように作成します。
JAZNファイルベースのセキュリティを使用する場合、user-properties.xml
ファイルを編集し、1つのアドレス(たとえば、jstein@example.com
)をjstein
(この例では、エンド・ユーザー)のアドレスとして指定します。
ns_emails.xml
ファイルを編集し、ヒューマン・ワークフロー用に異なる電子メール・アドレス(たとえば、hwfaccount@example.com
)を指定します。
さらに、SOA_Oracle_Home
\bpel\system\services\config\wf_config.xml
ファイルで、actionableEmailAccountName
要素の値を、SOA_Oracle_Home
\bpel\system\services\config\
ns_emails.xml
ファイルのName
要素にマップする必要があります。
たとえば、ns_emails.xml
で電子メール・アドレスとしてDefault
を使用する場合は、次のようになります。
<EmailAccount>
<Name>Default</Name>
. . .
. . .
. . .
</EmailAccount>
actionableEmailAccountName
値も、wf_config.xml
で次のようにDefault
に設定する必要があります。
<actionableEmailAccountName>Default</actionableEmailAccountName>
ヒューマン・ワークフローの通知を有効にする場合、SOA_Oracle_Home
\bpel\system\services\config\
ns_emails.xml
ファイルでIMAPまたはPOP3を大文字で指定しないでください。サポートされているのは小文字のみです。大文字を使用すると、次のエラーが発生します。
Email protocol not supported
ヒューマン・タスクの「タスク・パラメータ」ダイアログでペイロードを再マップしようとすると、古いペイロードがそのまま残ります。たとえば、次の手順を実行すると、古いペイロードのマッピングが残ります。
デフォルトのプロジェクト設定を使用してBPELプロジェクトを作成します。
receiveアクティビティの後にヒューマン・タスクを追加します。これにより「ヒューマン・タスクの追加」ダイアログが開きます。
「タスク定義:」フィールドの右にある2つ目のアイコンをクリックして、新しいタスク定義を作成します。これによりヒューマン・タスク・エディタが表示されます。
ヒューマン・タスク・エディタの「タスク・パラメータの追加」ダイアログでpayload1
というパラメータ文字列を作成します。
変更を保存して、ヒューマン・タスク・エディタを閉じます。
BPELプロセスでヒューマン・タスク・アクティビティをダブルクリックして、「ヒューマン・タスク」ダイアログを開きます。
「タスク・パラメータ」表で「参照」アイコンをクリックします。
「タスク・パラメータ」ダイアログでpayload1をinputVariable/client:inputにマップし、「OK」をクリックします。
このヒューマン・タスクのヒューマン・タスク・エディタに戻ります。
「タスク・パラメータの編集」ダイアログで、パラメータ名をpayload1からpayload2に変更します。
変更を保存して、ヒューマン・タスク・エディタを閉じます。
「ヒューマン・タスク」ダイアログを再び開きます。
「ヒューマン・タスク」ダイアログの「タスク・パラメータ」ダイアログで、payload2をinputVariable/client:inputに再マップし、「OK」をクリックします。
ソース・コード・モードに切り替え、payload1
を検索します。コードにpayload1
がまだ残っていることに注意してください。
これが、次のようなランタイム・エラーの原因になります。
Error in <assign> expression: <to> value is empty at line "123". The XPath expression : "" returns zero node, when applied to document shown below:less
回避方法として、古いマッピング(payload1
)のコピー操作をソースから手動で削除します。
<copy> <from variable="inputVariable" part="payload" query="/client:BPELProcess1ProcessRequest/client:input"/> <to variable="initiateTaskInput" part="payload" query="/taskservice:initiateTask/task:task/task:payload/task:Payload1"/> </copy>
ヒューマン・ワークフロー・タスク割当てに使用されるデフォルトのユーザー・アカウント(たとえば、wfaulk
またはjstein
)は、j2ee/home/config/system-jazn-data.xml
ファイルに含まれています。セキュリティ上の理由で、これらのアカウントに対するデフォルトのパスワードを変更するか、またはそれらが不要ならば完全に削除することを検討してください。
Oracle Enterprise Manager 10g Application Server Controlコンソールにログインします。
http://hostname:port/em
oc4j_soa(または使用している別のOC4Jインスタンス)をクリックします。
「管理」をクリックします。
「セキュリティ」の下にある「セキュリティ・プロバイダ」リンクをクリックします。
「インスタンス・レベルのセキュリティ」をクリックします。
「レルム」をクリックします。
jazn.comレルムの「ユーザー」の下にあるリンクをクリックします。
実行するアクションに応じて、次の手順に従います。
実行するアクション | 手順 |
---|---|
ユーザーの削除 |
|
ユーザー・パスワードの変更 |
|
この項では、次の問題と回避方法について説明します。
SSLはサポートされず、ns_emails.xml
内のUseSSL
要素は使用されません。
ページャおよびFAXチャネルは、オラクル社がホストするワイヤレス・サービスではサポートが停止されました。また、非推奨です。
通知サービスによって使用される電子メール・サーバーでは、通知サービスのデモ用に1つの電子メール・アカウントが必要です(この例では、hwfaccount
を使用)。その他の電子メール・アカウント(たとえば、jcooper
、jstein
およびwfaulk
)は、エンド・ユーザーが使用するためのものです。
注意: 次の項で示す値example.com は、単なる例です。これを使用する電子メール・サーバーの名前またはドメイン名に置き換えてください。 |
ns_emails.xml
のDefault
EmailAccount
セクションを使用環境に適した値で編集します。
番号 | 要素/属性 | 値 | 注意 |
---|---|---|---|
1 | NotificationMode |
ALL またはEMAIL |
通知を送信するためのチャネル |
2 | FromAddress |
hwfaccount@example.com |
From 電子メール・アドレス |
3 | SMTPHost |
example.com |
SMTPサーバー名 |
4 | SMTPPort |
25 |
デフォルトのSMTPポート |
users-properties.xml
を編集し、電子メールを受信するユーザーの電子メールIDを指定します(たとえば、jcooper
、jstein
および指定する追加のユーザー)。
番号 | ユーザー | 値 |
---|---|---|
1 | jcooper |
jcooper@example.com |
2 | jstein |
jstein@example.com |
5.6.3.1項「送信通知のみのデモを行う手順」で説明した変更を行います。
ns_emails.xml
を編集し、Default
EmailAccount
セクションの下で使用環境に適した変更を行います。
番号 | 要素/属性 | 値 | 注意 |
---|---|---|---|
1 | Server |
example.com |
IMAPまたはPOP3サーバー名 |
2 | Port |
143/110 |
デフォルトのIMAPまたはPOP3サーバー・ポート |
3 | Protocol |
imap またはpop3 |
IMAPまたはPOP3電子メール・プロトコル |
4 | UserName |
hwfaccount |
アカウントのユーザー名 |
5 | Password |
hwfaccountpwd |
ユーザー名のパスワード |
wf_config.xml
を編集し、次を変更します。
<actionableEmailAccountName/>
次のように変更します。
<actionableEmailAccountName>Default</actionableEmailAccountName>
actionableEmailAccountName
は、ns_emails.xml
のEmailAccount
の下で構成したアカウントと一致する必要があります。この例では、Default
が使用されます。
通知サービスのデバッグを行うには、まずOracle Process Manager and Notification Server(OPMN)のログを調べます。ログには、間違った動作に関する詳細がわかる例外、エラーまたは警告のメッセージが含まれている可能性があります。表5-2では、通知サービスの問題をデバッグするためのその他の方法について説明しています。
表5-2 通知サービスのデバッグ
番号 | 症状 | 問題の原因 | 考えられる解決策 |
---|---|---|---|
1 |
電子メール通知が送信されない。 |
|
設定を |
|
注意: 任意の電子メール・クライアントでSMTPサーバーへの接続にそれらの設定値を使用して値を検証します。 |
||
|
次の行を <AuthenticationRequired>true </AuthenticationRequired> <UserName>SMTP_user_name</UserName> <Password ns0:encrypted="false"xmlns:ns0= "http://xmlns.oracle.com/ias/pcbpel/ NotificationService">'SMTP_password'</Password> |
||
2 |
電子メール・クライアントによる通知の受信に一貫性がない。 |
|
通知が同じアカウントに送信される場合、電子メール・クライアントが電子メールを表示する前に、ヒューマン・ワークフロー・サービスで電子メールがダウンロードされ処理される可能性があります。 |
3 |
通知は送信されるが、アクション可能ではない。 |
|
|
|
ヒューマン・タスク・エディタ(Oracle JDeveloperで |
||
4 |
アクション可能な通知が送信されるが、応答後アクションが実行されない。 |
|
注意: 任意の電子メール・クライアントでIMAPまたはPOP3サーバーへの接続にそれらの設定値を使用して値を検証します。 |
|
|
||
|
この機能は現在のところサポートされていません。 注意: |
||
|
一部の電子メール・サーバーでは、 |
||
|
ユーザーが承認リンクをクリックすると、デフォルトのメール・クライアントのページが開き、このページから別の電子メール・サーバーに電子メールが送信される可能性があります。 アクション可能な通知を受信するように、デフォルトの電子メール・クライアントを構成します。 |
この項では、次の問題と回避方法について説明します。
5.7.1項「JDK 6を使用してデプロイ済のBPELプロセスに対してテスト・インスタンスを開始するとエラーが表示される」
5.7.2項「10.1.3.1の完了したインスタンスを10.1.3.4で表示するとOracle BPEL Controlのエラー・メッセージが表示される」
5.7.4項「Oracle BPEL ServerがSSL対応の場合のOracle BPEL Process Managerの使用方法」
5.7.6項「Mozilla Firefoxを使用したOracle BPEL管理コンソールでのロギング・レベルの設定に「すべて変更」リストを使用できない」
5.7.7項「Oracle BPEL Controlアクティビティ・センサー・レポートでセンサー・データを表示できない」
JDK 6を使用してデプロイ済のBPELプロセスに対してテスト・インスタンスの開始を試行すると、次のJSPエラーが表示されます。
500 Internal Server Error OracleJSP: An error occurred. Consult your application/system administrator for support. Programmers should consider setting the init-param debug_mode to "true" to see the complete exception message
この問題を解決するには、次の手順を実行します。
Oracle MetaLinkのサイトにアクセスします。
http://metalink.oracle.com
付属のREADMEファイルの手順に従って、パッチ7309482をダウンロードしてインストールします。
次の手順を実行するとします。
Oracle SOA Suite 10.1.3.1を「拡張インストール」オプションでインストールします。
休暇願いなどのサンプルをデプロイし、複数の10.1.3.1インスタンスを作成します。
Oracle BPELワークリスト・アプリケーションから1つのインスタンスを完了します。
10.1.3.4パッチでアップグレードします。
Oracle BPEL Serverを再起動します。
Oracle BPELワークリスト・アプリケーションから別のインスタンスを完了します。
10.1.3.4の完了したインスタンスで、Oracle BPEL Controlに次のエラー・メッセージが表示されます。
this.wi.state is null'
機能が損われることはなく、このメッセージは無視してかまいません。10.1.3.4の新規インスタンスを作成すると、このメッセージは表示されません。
変更されたフォルト・ポリシーは、Oracle BPEL Serverを再起動しなくても、Oracle BPEL Controlからリロードできます。
次のJSPページを呼び出します。
http://host:port/BPELConsole/domain_name/doReloadFaultPolicy.jsp
要求されたら、Oracle BPEL Controlにログインします。
次のメッセージが表示されます。
Fault Policy and Fault Bindings file is reloaded All Fault Policy and Fault Binding cached for the BPEL domain your_domain_name have been reloaded.
Oracle BPEL ServerがSSL対応である場合、Oracle BPEL Process Managerを使用するには次の手順を実行します。
Oracle BPEL管理コンソール(http://
soaSuiteServerHostName
:port
/BPELAdmin
)を開きます。
SoapServerUrl
プロパティおよびSoapCallbackUrl
プロパティで、次の操作を行います。
ホスト名とフル・ドメイン名のURLでhttp
をhttps
に変更します。
正しいSSLポートが指定されていることを確認します。
テストを行い、証明書ベースのHTTPSが使用できるようになったことを確認します。ホスト名およびhttpsPort
をターゲットのOracle SOA Suiteインストールの情報、https://
hostname:httpsPort/
BPELConsole
に置き換えます。
Oracle BPEL管理コンソールでドメインを削除しようとすると、次のメッセージが表示されます。
To preserve deployed processes and data logs associated with the BPEL Domain, check the keep directory box (the old domain directory will be moved to home/domains/.deleted where home is the BPEL server installation directory).
このドメインにデータを保存する場合、このページで選択するディレクトリを保存チェック・ボックスがありません。
回避方法として、ドメインを削除する前に、ドメイン・データを手動でバックアップします。たとえば、UNIXまたはLinuxオペレーティング・システムでは、次の手順を実行します。
ディレクトリを次の場所に変更します。
cd $ORACLE_HOME/bpel/domains
ドメインを表す基礎となるディレクトリをバックアップの場所にコピーします。
Mozilla Firefoxを使用して、Oracle BPEL管理コンソールの「ロギング」タブの「すべて変更」リストでロギング・レベルを設定すると、すべてのロギング・コンポーネントでロギング・レベルが変更されるとはかぎりません。
回避方法として、Microsoft Internet Explorerを使用します。
Oracle BPEL Controlのアクティブ・センサー・レポートでセンサー・データを表示できません。たとえば、次の手順を実行するとします。
Oracle JDeveloperでBPELプロセスのアクティビティに関するデータベース・センサーを作成します。
BPELプロセスをデプロイします。
Oracle BPEL ControlでBPELプロセスのインスタンスを作成します。
「プロセス」→「Deployed_BPEL_Process」→「レポート」に移動し、「レポート・タイプ」リストから「アクティビティ・センサー」を選択します。
インスタンスが完了した時間間隔を含む問合せを指定し、「実行」をクリックします。
アクティビティ・センサー・データが存在する場合でも、次のメッセージが表示されます。
No Data Found
回避方法として、Oracle BPEL Controlで「インスタンス」→「BPEL_Process_Name」→「センサー」を選択することで、BPELプロセスのアクティビティのセンサー・データを表示できます。
次の状況では、Oracle BPEL Controlへの初回アクセスが失敗する可能性があります。
Oracle BPEL Controlのシングル・サインオンを構成します。
一般的なJavaシングル・サインオン(JSSO)・ページから初回ログインします。次に例を示します。
http://myhost.us.mycompany.com:47804/jsso/
JSSOページの使用するSOAスイートの管理セクションでBPEL Controlリンクをクリックします。
Oracle BPEL Controlにアクセスできません。
回避方法として、もう一度BPEL Controlリンクをクリックすると、Oracle BPEL Controlが表示されます。または、JSSOページを使用せず、Oracle BPEL Controlに直接ログインします。
BPELプロセスのassignアクティビティでtoCDATA
関数を使用すると、Oracle BPEL Controlでは監査証跡に出力データが正しく表示されません。
[2008/05/01 16:20:33] Updated variable "output"less 322 GE 12.3 750 true Hello 322 <![CDATA[322 ]]>
この問題は、Oracle BPEL Controlでのみ発生するもので、toCDATA
関数は正しく機能します。RAW XMLデータの場合、toCDATA
関数は正しくデータを表示します。
この項では、次の問題と回避方法について説明します。
HTTP GETおよびPOSTでマルチバイト・データを処理するには、次の手順を実行する必要があります。
SOA_Oracle_Home
\opmn\conf\
opmn.xml
にoc4j_soa
起動オプションとして、次の行を追加します。
<process-type id="oc4j_soa" module-id="OC4J" status="enabled">
<module-data>
<category id="start-parameters">
<data id="java-options" value="-server -XX:MaxPermSize=128M
-ms512M -mx1024M -XX:AppendRatio=3 -Djava.security.policy=$ORACLE_HOME/j2ee/oc4j_
soa/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false
-Doraesb.home=/home/zhua/product/10.1.3.1/OracleAS_1/integration/esb
-Dhttp.proxySet=false -Doc4j.userThreads=true -Doracle.mdb.fastUndeploy=60
-Dorabpel.home=/home/zhua/product/10.1.3.1/OracleAS_1/bpel
-Xbootclasspath^/p:/home/zhua/product/10.1.3.1/OracleAS_
1/bpel/lib/orabpel-boot.jar -Dhttp.proxySet=false -Dfile.encoding=UTF8"/>
</category>
. . .
. . .
<module-data>
. . .
. . .
</process-type>
次の方法のいずれかを使用してoc4j_soa
を再起動します。
Oracle Enterprise Managerから管理者ロールを持つユーザーとしてログインし、「クラスタ・トポロジ」ページでoc4j_soa
を選択して、「再起動」をクリックします。
opmnctl
ユーティリティで、次のコマンドを入力します。
opmnctl restartproc process-type=oc4j_soa
この項では、次の問題と回避方法について説明します。
SOA_Oracle_Home
\bpel\samples
ディレクトリに含まれている一部のサンプルおよびチュートリアルで、パスワードについての記載があります。
サンプルのホスティングについて懸念する場合は、samples
ディレクトリ全体を削除します。これは、特にSOAをインストールした本番サーバーについて当てはまります。これには、すべての10.1.3.x
リリースが該当します。
SOA_Oracle_Home
\bpel\samples\demos\ResilientDemo\ResilientFlow
にあるPDFドキュメントのリジリエント・フロー・サンプルを実行する方法を説明する項は不完全です。次の手順も実行する必要があります。
Apache AXISサービスをダウンロードし、$TOMCAT_HOME/webapps
フォルダにコピーします。
ResilientDemo/AxisServices
で、コンパイル・ターゲットを明示的に実行します。この手順を実行しないと、classes
フォルダは作成されません。
『Oracle BPEL Process Manager開発者ガイド』の第16章「ワークリスト・アプリケーション」のグループ・ルールに関する項には、再割当て先アクションについての次の説明があります。
再割当て先: ユーザー・ルールと同様に、タスクを自分が直接管理する下位ユーザーまたはグループに再割当てできます。BPMWorkflowReassign
ロールを付与されている場合は、どのユーザーまたはグループ(担当する管理階層外)にでもタスクを再割当てできます。
この記述では、再割当ての許可が、ルールが作成される対象のグループではなく、ルールを作成するユーザーによって決まるように読み取れます。この説明は、次のように読み取る必要があります。
再割当て先: ユーザー・ルールと同様に、グループはタスクをそのグループが直接管理する下位ユーザーまたはグループに再割当てできます。グループがBPMWorkflowReassign
ロールを付与されている場合は、グループはどのユーザーまたはグループ(担当する管理階層外)にでもタスクを再割当てできます。
『Oracle BPEL Process Manager開発者ガイド』の第5章「非同期Webサービスの呼出し」の同期サービス用TCPリスナーの設定に関する項では、Apache Axisに含まれるTCPトンネルを構成する際にorabpel.apache.axis.utils.tcpmon
を使用するように誤って記述されています。かわりに、org.collaxa.thirdparty.apache.axis.utils.tcpmon
を使用します。
『Oracle BPEL Process Manager開発者ガイド』の第20章「BPELプロセスのテスト」の非同期イベントのエミュレーションに関する項を読むときには、onMessageイベントでは同期(双方向)操作がサポートされていないことに注意してください。
Oracle Application ServerでのHTTPポートの変更について、『Oracle Application Server管理者ガイド』の第4章「ポートの管理」で説明されています。Oracle BPEL Process Managerを使用している場合、HTTPポートに次の追加の変更を加える必要があります。
Oracle BPEL管理コンソールまたはSOA_Oracle_Home
\bpel\system\config\collaxa-config.xml
ファイルでsoapServerUrl
プロパティおよびsoapCallbackUrl
プロパティを更新します。
Oracle BPELワークリスト・アプリケーションまたはカスタマイズされたワークリスト・アプリケーションを使用している場合は、SOA_Oracle_Home
\bpel\system\services\config\wf_client_config.xml
ファイルでidentityService
、identityConfigService
、taskService
、taskMetadataService
、taskQueryService
、userMetadataService
およびruntimeConfigService
soapEndPoint
URL HTTPポートを更新します。
カスタマイズされたワークリスト・アプリケーションを使用している場合は、クライアント・コードのwf_client_config.xml
も変更したことを確認します。
タスク更新の電子メール通知を使用している場合は、SOA_Oracle_Home
\bpel\system\services\wf_config.xml
ファイルでworklistApplicationURL
を更新します。
注意: SOA_Oracle_Home \bpel\samples ディレクトリの一部のチュートリアル、デモ、ユーティリティおよびリファレンスでもハードコードされたHTTPポートが使用されることに注意してください。 |
『Oracle BPEL Process Manager開発者ガイド』の第3章「BPELでのXMLデータの操作」のBPELでのSOAPヘッダーの操作に関する項には、次の2つの段落があります。
これらのデフォルト・アクティビティでは、各方向で1つの変数の操作が許可されます。たとえば、invokeアクティビティには、inputVariable
およびoutputVariable
属性があります。この2つの属性にそれぞれ変数を1つ指定できます。関連する特定の操作で使用するペイロード・メッセージが各方向で1つのみの場合は、これで十分です。
ただし、WSDLは1つの操作における複数のメッセージをサポートしています。SOAPの場合、SOAPヘッダーとしてメイン・ペイロード・メッセージとともに複数のメッセージを送信できます。ただし、BPELのデフォルトの通信アクティビティは、追加のヘッダー・メッセージに対応できません。
これら2つの段落を読むと、WSDLでは1つの操作において複数のペイロード・メッセージがサポートされるという印象を受けます。これは間違いです。メッセージ・ペイロードとヘッダーは、異なるエンティティです。ヘッダーは、メッセージ・ペイロードを送信するためのものではありません。
2番目の段落では、WSDLが1つの操作において複数のメッセージをサポートすると述べています。WSDLではなく、SOAPが、操作の呼出しの一部としてメッセージ・ヘッダーの送信をサポートします。
『Oracle BPEL Process Manager開発者ガイド』の付録C「デプロイメント・ディスクリプタのプロパティ」のリストにあるserviceProperties
には説明がありません。このプロパティは、WSIFプロバイダに渡されるXML要素です。
この項では、10.1.3.4の新機能について説明します。
10.1.3.4では、Oracle BPEL Controlの機能の場所についていくつかの変更が加えられました。
Oracle BPEL Controlのメイン・タブのいくつかは、新しくなったか、名前が変更されました。表5-3では、これらの変更について説明しています。
リリース10.1.3.4より前のリリースの「BPELドメインの管理」ページで使用可能な機能は、「構成」タブおよび「管理」タブに移動しました。10.1.3.4より前のリリースの「BPELプロセス」タブおよび「インスタンス」タブで使用可能な機能の一部も移動しました。表5-4では、Oracle BPEL Controlでのこの機能の新しい場所と古い場所について説明しています。
表5-4 Oracle BPEL Controlのタブに対する変更
10.1.3.4より前のリリースのOracle BPEL Controlでのタブ名の場所 | リリース10.1.3.4のOracle BPEL Controlでのタブ名の場所 |
---|---|
「BPELドメインの管理」→「構成」 |
「構成」→「ドメイン」 |
「BPELドメインの管理」→「ロギング」 |
「構成」→「ロギング」 |
「BPELドメインの管理」→「XPathライブラリ」 |
「構成」→「XPathライブラリ」 |
「BPELドメインの管理」→「スレッド」 |
「管理」→「スレッド」 |
「BPELドメインの管理」→「統計」 |
「管理」→「統計」 |
「BPELドメインの管理」→「アダプタ統計」 |
「管理」→「アダプタ統計」 |
「BPELプロセス」→「プロセス・ログの表示」 |
「管理」→「プロセス・ログ」 |
「BPELプロセス」→「WSDLキャッシュのクリア」 |
「管理」→「アクション」→「WSDLキャッシュのクリア」 |
「BPELプロセス」→「アラーム表のリフレッシュ」 |
「管理」→「アクション」→「アラーム表のリフレッシュ」 |
「BPELプロセス」→「新規プロセスのデプロイ」 |
「プロセス」→「新規プロセスのデプロイ」 |
「BPELプロセス」→「手動リカバリの実行」 |
「管理」→「リカバリ(起動)」 「管理」→「リカバリ(コールバック)」 「管理」→「リカバリ(アクティビティ)」 |
「インスタンス」→「すべてのインスタンスを消去」 |
「管理」→「アクション」→「すべてのインスタンスを消去」 |
「インスタンス」→「センサー・データの消去」 |
「管理」→「アクション」→「センサー・データの消去」 |
この項では、Oracle BPEL Controlでの構成プロパティの変更について説明します。
表5-5に示すプロパティは、10.1.3.4の新しいプロパティです。これらのプロパティにアクセスするには、Oracle BPEL Controlで、「構成」→「ドメイン」を選択します。
表5-5 新しいプロパティ
プロパティ | 説明 | 値 |
---|---|---|
|
エンジン・ディスパッチャ・メッセージを処理するために割り当てられたスレッドの総数。エンジン・ディスパッチ・メッセージは、アクティビティがOracle BPEL Serverで非同期に処理される必要のある場合に生成されます。Oracle BPEL Serverにデプロイされたプロセスの大部分に、多数のデハイドレーション・ポイント(中間プロセスのreceive、onMessage、onAlarmおよびwaitアクティビティ)による永続性がある場合、エンジン・スレッド数を増やすことでパフォーマンスが向上する可能性があります。スレッド数が多くなればなるほど、コンテキスト切替えコストが高くなるため、CPU使用率が高まる可能性があることに注意してください。 |
デフォルト値は |
|
呼出しディスパッチャ・メッセージを処理するために割り当てられたスレッドの総数。呼出しディスパッチ・メッセージは、Oracle BPEL Serverで受信されるペイロードごとに生成され、新規インスタンスをインスタンス化するためのものです。エンジンによって処理される大部分のリクエストがインスタンス呼出し(インスタンス・コールバックの反対)である場合、呼出しスレッド数を増やすことにより、パフォーマンスが向上する可能性があります。スレッド数が多くなればなるほど、コンテキスト切替えコストが高くなるため、CPU使用率が高まる可能性があります。 |
デフォルト値は |
|
システム・ディスパッチャ・メッセージを処理するために割り当てられたスレッドの総数。システム・ディスパッチ・メッセージは、通常サーバーにより迅速に処理される一般的なクリーンアップ・タスクです(たとえば、ステートフル・メッセージBeanを元のプールに解放)。通常、実行時に生成されたシステム・ディスパッチ・メッセージの数を処理するために必要なスレッド数はごく少数です。 |
デフォルト値は |
表5-6のプロパティは、10.1.3.4より前のリリースで除外されましたが、10.1.3.4で再導入されました。
表5-6 再導入されたプロパティ
プロパティ | 説明 | 値 |
---|---|---|
|
このプロパティでは、インスタンスの完了後に保存するデータのタイプ(および量)を制御します。 プロセス・インスタンスが完了すると、Oracle BPEL Serverではデフォルトでプロセスの最後の状態(たとえば、変数値)が保存されます。完了後にこれらの値を保存する必要がない場合は、このプロパティをインスタンスのメタデータ(完了の状態、開始日および終了日など)のみを保存するように設定できます。このプロパティは、一時BPELプロセスに適用できます。 このプロパティは、 このプロパティは、データベースの増大(特に |
|
|
このプロパティにより、インスタンスを持続させるかどうか、およびその時期を制御します。インスタンスが保存されないと、Oracle BPEL Controlに表示されません。このプロパティは、一時BPELプロセスに適用できます。 このプロパティは、 このパラメータは、データベース(特に、 |
|
関連項目: completionPersistLevel およびcompletionPersistPolicy の詳細は、『Oracle Application Serverパフォーマンス・ガイド』を参照してください。 |
validateXML
プロパティにより、受信および送信XMLドキュメントを検証します。このプロパティには次の値があります。
warning
: 検証エラーがある場合、警告メッセージを受信します。
none
(デフォルト): スキーマ検証は、XMLドキュメントには適用されません。それでもXMLドキュメントは整形式で、XMLネームスペースが正しく使用されている必要があります。プロセスで受信されたXMLドキュメントが有効であると安全に想定できる場合、本番環境ではパフォーマンス上の理由でこの値の使用を検討してもかまいません。
strict
: 受信および送信XMLドキュメントにスキーマ検証が適用されます。XMLドキュメントでエラーを検出するために、BPELプロセスの開発時にこの値の使用を検討します。
dspMaxRequestDepth
プロパティでは、同じリクエスト内で処理するメモリー内アクティビティの最大数を設定します。アクティビティ・リクエストの処理後、Oracle BPEL Process Managerでは、リクエストのトランザクションを損うことなく、できるだけ多くの後続アクティビティの処理が試みられます。アクティビティの処理チェーンがこの深さまで達すると、インスタンスではデハイドレーションが行われ、次のアクティビティが別のトランザクションで実行されます。リクエストの深さが深すぎると、リクエストの合計時間がアプリケーション・サーバーのトランザクション・タイムアウト制限を超える可能性があります。このプロパティは、永続プロセスに適用できます。
デフォルト値は600
です。
Oracle BPEL管理コンソールの「スレッド」タブは、除外されました。スレッド機能は、Oracle BPEL Controlで使用可能です。「管理」→「スレッド」を選択して詳細を表示します。
Oracle BPEL Controlの「このBPELドメインのスレッド割当て統計」ページでは、次の点が改善されました。
保留中およびスケジュール済のメッセージの両方について詳細を表示することにより、BPELディスパッチャ・キューの見やすさが向上しました。
Oracle BPEL Serverのパフォーマンスの監視中に必要なクリック数を最小限に抑えるためにリフレッシュされる視覚化ツール(グラフなど)により、操作性が向上しました。
Oracle BPEL Controlでディスパッチャ・キューの詳細を表示するには、次の手順に従います。
「管理」→「スレッド」を選択します。
保留中およびスケジュール済のメッセージとOracle BPEL Serverのパフォーマンスの詳細を表示します。
Oracle BPEL Controlの「分析」ページにより、ソース・コードをフロー・チャートで分析し、BPELプロセスにおけるアクティビティ実行CPU時間を監視できます。
「分析」ページでは、プロセス・レベルでの統計を収集し、インスタンス・レベルで(最後のnリクエストについて)表示できます。これによりリクエストを送信し、そのBPELフロー内のどこに問題のアクティビティがあるのかを確認でき、集計された統計から判断する必要はありません。
Oracle BPEL Controlでインスタンス・レベルの統計を表示するには、次の手順を実行します。
「ダッシュボード」タブをクリックします。
新規インスタンスを作成するデプロイ済のBPELプロセスを選択します。「開始」タブが表示されます。
新規インスタンスを作成し、「XMLメッセージの転送」をクリックします。
「分析」タブをクリックします。
「プロセス分析データのリフレッシュ」をクリックするか、ページがリフレッシュされるまで数秒待ちます。
次のような詳細が表示されます。
注意: Oracle BPEL Serverを再起動する場合、分析統計は、デハイドレーション・ストア・データベースに保存されないため残りません。 |
Oracle BPEL Serverのクラッシュが発生するなどの状況の場合、BPELプロセス・メッセージの自動リカバリを実行できます。
Oracle BPEL Controlで自動リカバリのプロパティを構成するには、次の手順に従います。
「構成」→「自動リカバリ」を選択します。ページは2セットの構成プロパティに分かれています。
起動スケジュール
Oracle BPEL Serverの起動直後にリカバリが発生します。デフォルトでは、startupRecoveryDuration
が0
に設定されているために、起動リカバリは無効です。maxMessageRaiseSize
を0
に設定しても、起動リカバリが無効になります。
反復スケジュール
リカバリは、1日に1回発生するように構成できます。デフォルトでは、startWindowTime
およびstopWindowTime
は同じ値に設定されているため、反復リカバリは無効です。maxMessageRaiseSize
を0
に設定しても、反復リカバリが無効になります。
起動スケジュールのプロパティについては、次の表で説明しています。
プロパティ | 説明 | 値 |
---|---|---|
maxMessageRaiseSize |
起動リカバリが試行されるたびに送信されるメッセージの最大数を指定します。このプロパティにより、Oracle BPEL Serverでのリカバリの影響を制限できます。この値で、アクティビティ、呼出しおよびコールバックの各問合せからフィルタ処理するメッセージの最大数を指定します。つまり、アクティビティ、呼出しおよびコールバックの各表から50メッセージです。
デフォルト値は |
デフォルト値は50 です。 |
startupRecoveryDuration |
起動リカバリ期間が持続する秒数を指定します。Oracle BPEL Serverは起動後、起動リカバリ期間に入ります。この期間中、保留アクティビティと未配信コールバックおよび呼出しメッセージは、処理のために再送信されます。
デフォルト値は |
デフォルト値は0 です。 |
subsequentTriggerDelay |
Oracle BPEL Server起動リカバリ期間中のリカバリ試行間の秒数を指定します。次のリカバリ・トリガーがサーバー起動期間から外れると、そのトリガーはスケジュールされず、Oracle BPEL Serverは反復リカバリ期間に入ります。
デフォルト値は |
デフォルト値は300 です。 |
反復スケジュールのプロパティについては、次の表で説明しています。
プロパティ | 説明 | 値 |
---|---|---|
maxMessageRaiseSize |
反復リカバリが試行されるたびに送信されるメッセージの最大数を指定します。このプロパティにより、Oracle BPEL Serverでのリカバリの影響を制限できます。この値で、アクティビティ、呼出しおよびコールバックの各問合せからフィルタ処理するメッセージの最大数を指定します。つまり、アクティビティ、呼出しおよびコールバックの各表から50メッセージです。
デフォルト値は |
デフォルト値は50 です。 |
startWindowTime |
毎日のリカバリ・ウィンドウの開始時間を24時間表記法で指定します。したがって、午後2:00時は14:00 と指定します。1桁の時間の値(1:00〜9:00)には、先頭のゼロは指定する必要がありません。デフォルト値は午前0時(00:00 )です。無効で解析済の時間の値は、デフォルトの午前0時に設定されます。 |
デフォルト値は00:00 です。 |
stopWindowTime |
毎日のリカバリ・ウィンドウの停止時間を24時間表記法で指定します。したがって、午後2:00時は14:00 と指定します。1桁の時間の値(1:00〜9:00)には、先頭のゼロは指定する必要がありません。
毎日のリカバリが必要ない場合、ウィンドウの開始および停止時間を同じ値に設定します。ウィンドウ停止時間が開始時間より早いと、ウィンドウ開始時間と停止時間はどちらも、それぞれのデフォルト値に変更されます。 デフォルト値は午前0時( |
デフォルト値は00:00 です。 |
subsequentTriggerDelay |
毎日の反復起動リカバリ期間中のリカバリ試行間の秒数を指定します。次のリカバリ・トリガーが現行のリカバリ期間を外れると、そのトリガーは、次の反復リカバリ期間(翌日)までスケジュールされません。
デフォルト値は |
デフォルト値は300 です。 |
これらのプロパティを使用環境に適した値で編集します。
短期間にわたるログ、スレッド・ダンプおよびランタイム統計を診断のために収集できます。たとえば、インスタンスに障害が発生した場合、統計の収集を開始し、障害インスタンスを再度呼び出して、そのインスタンスの統計収集を完了できます。これらの統計は、障害インスタンスのデバッグに使用することも、バグ・レポートに添付することもできます。これにより、問題のデバッグのためにサポートと交わすやり取りの回数が減ります。
Oracle BPEL Controlで診断のために障害インスタンスに関する統計の収集を開始するには、次の手順に従います。
「管理」→「診断」を選択します。「診断収集」ページが表示されます。
「収集の開始」をクリックして、統計の収集を開始します。診断を収集中であるというメッセージが表示されます。ログ出力はすべてDEBUG
モードに設定されています。5分に到達するか、「収集の停止」が選択されるまで、10秒ごとに統計が収集されます。
「ダッシュボード」タブに戻り、前に障害が発生したBPELプロセスのインスタンスを呼び出します。
「診断収集」ページに戻り、統計収集が続行中であることに注意します。
5分待つか、統計の収集を停止する場合は「収集の停止」をクリックします。ログを収集中であるというメッセージが表示されます。
要求されたら、収集された統計、ログおよびスレッド・ダンプを含むZIPファイルを開くか保存するかを選択します。これらの統計は、障害インスタンスのデバッグに使用することも、バグ・レポートに添付することもできます。
注意: Oracle BPEL Controlで「ダッシュボード」の下の「エクスポート・プロセス」→「BPEL_process_name」→「管理」をクリックすることにより、BPELプロセスのZIPファイルをエクスポートできます。 |
BPELプロセスの入力メッセージ・タイプに対して、XML入力ペイロードを検証できます。これにより、インスタンスを呼び出す前にペイロードを検証できます。これは、間違った無効なXMLペイロードがプロセスに配信されないようにし、XPathエラーが後続のassignアクティビティで表示されないようにするのに役立ちます。
XMLペイロードを検証するには、次の手順に従います。
「ダッシュボード」→「BPEL_process_name」→「XMLの検証」を選択します。
検証するペイロード・スキーマを入力します。ペイロードは、SOAPエンベロープ全体か要素タイプ(soap:Body
タグなし)のいずれかです。
「XMLの検証」をクリックします。
検証が成功したか失敗したかを示すメッセージが表示されます。検証に失敗した場合、エラーについて説明されます。
境界から境界に渡されるBPELプロセス用の機密ペイロードの暗号化および復号化ができます。さらに、このデータは監査およびデバッグのログには表示されません。
データの暗号化および復号化を行うには、次の手順に従います。
Oracle JDeveloperで暗号化するデータ要素のプロパティおよびプロパティ・エイリアスを作成します。
プロパティを作成するには、BPELデザイナで右クリックし、「表示」→「プロパティ」を選択してから、「プロパティ」フォルダを選択して、「作成」アイコンをクリックします。
この例の場合、ssn
プロパティとrating
プロパティが作成されます。
プロパティ・エイリアスを作成するには、右クリックし、「表示」→「プロパティ・エイリアス」を選択してから、「プロパティ・エイリアス」フォルダを選択して、「作成」アイコンをクリックします。
完了したら、BPELプロセスのWSDLファイルで更新が反映されます。
<bpws:property name="ssn" type="xsd:string" xmlns:ssnns="http://a" /> <bpws:property name="rating" type="xsd:string" xmlns:rating="http://b" /> <bpws:propertyAlias xmlns:services="http://services.otn.com" xmlns:rating="http://b" propertyName="rating:creditrating" messageType="services:LoanServiceRequestMessage" part="payload" query="/s1:loanApplication/s1:creditRating"/> <bpws:propertyAlias xmlns:services="http://services.otn.com" xmlns:rating="http://b" propertyName="rating:rating" messageType="services:CreditRatingServiceResponseMessage" part="payload" query="/services:rating"/> <bpws:propertyAlias xmlns:ssnns="http://a" xmlns:services="http://services.otn.com" propertyName="ssnns:ssn" messageType="services:CreditRatingServiceRequestMessage" part="payload" query="/services:ssn"/> <bpws:propertyAlias xmlns:ssnns="http://a" xmlns:services="http://services.otn.com" propertyName="ssnns:ssn" messageType="services:LoanServiceRequestMessage" part="payload" query="/s1:loanApplication/s1:SSN"/> <bpws:propertyAlias xmlns:ssnns="http://a" propertyName="ssnns:ssn" messageType="tns:LoanFlowRequestMessage" part="payload" query="/s1:loanApplication/s1:SSN"/>
bpel.xml
ファイルを開きます。
configurations
セクションの下にencryptProperties
プロパティとdecryptProperties
プロパティを追加します。
<configurations> <property name="encryptProperties">{http://a}ssn {http://b}rating</property> <property name="decryptProperties">{http://a}ssn {http://b}creditrating</property> </configurations>
すべてのパートナ・リンクで、次のタスクが実行されるようになります。
/s1:loanApplication/s1:SSN
および/services:rating
の暗号化(メッセージ・タイプに基づく)
/s1:loanApplication/s1:SSN
および/s1:loanApplication/s1:creditRating
の復号化(メッセージ・タイプに基づく)
これまでのリリースでは、開発から、テストおよび本番サーバー環境に移行するときに、BPELプロセスのbpel.xml
、WSDLおよびスキーマ・ファイルでいくつかのURLとプロパティを変更する必要がありました。リリース10.1.3.4では、異なる環境で使用するURLとプロパティの値を定義するXMLファイルで、BPELデプロイ・プランを作成できます。プロセス・デプロイ時に、このデプロイ・プランを使用してBPELスーツケースJARファイルでファイルが検索され、それらのファイルが環境に適したURLとプロパティを含むファイルに置き換えられます。
この項では、デプロイ・プランがどのような役割を果すかの概要を説明します。
次の属性とプロパティを置換できるデプロイ・プラン・ファイルを作成し、編集します。
BPELデプロイメント・ディスクリプタ・ファイル(bpel.xml
)の構成プロパティ
bpel.xml
ファイルのパートナ・リンク・バインディング・プロパティ
WSDLファイルのimportのschemaLocation
属性
WSDLファイルのincludeのschemaLocation
属性
XSDファイルのinclude、importおよびredefineのschemaLocation
属性
注意: デプロイ・プラン・ファイルを使用して、XSL内の参照を変更することはできません。かわりに、開発から、テスト、本番の環境に移行するときには、Oracle JDeveloperのXSLTマッパーで手動により変更する必要があります。こうすれば、XSLTマッパーが設計時に問題なく確実に開きます。ただし、参照を変更しないままにすると、ランタイム動作には影響がありません。 |
次の例は、デプロイ・プランのbpel.xml
の部分を示しています。このセクションでは、パートナ・リンク・バインディングCreditRatingAgentPL
に次の検索および置換ルールが指定されています。
myhost.us.oracle.com
の検索およびmyhost17
との置換
${domain_id}
の検索およびorabpel
との置換
特定の値のかわりにアスタリスクを指定することもできます。たとえば、次のようになります。
BPELProcess id="AutoLoanFlow"
これを次のように置き換えます。
BPELProcess id="*"
こうすることで、このデプロイ・プランで指定した検索および置換のオプションを、すべてのプロセスで適用できるようになります。1つのデプロイ・プランをプロセス間で共有することができます。
. . . . . . <BPELProcess id="AutoLoanFlow"> . . . . . . <partnerLinkBindings> <partnerLinkBinding name="CreditRatingAgentPL"> <property name="*"> <searchReplace> <search>myhost17.us.oracle.com</search> <replace>myhost17</replace> </searchReplace> </property> </partnerLinkBinding> </partnerLinkBindings> </BPELProcess> <BPELProcess id="*"> <partnerLinkBindings> <partnerLinkBinding name="*"> <property name="*"> <searchReplace> <search>${domain_id}</search> <replace>orabpel</replace> </searchReplace> </property> </partnerLinkBinding> </partnerLinkBindings> </BPELProcess> . . . . . .
デプロイ・プラン・ファイルをBPELスーツケースJARファイルに添付します。
デプロイ時に、デプロイ・プラン・ファイルは、BPELスーツケースJARファイル内でのbpel.xml
、WSDLおよびXSDファイルの検索と、環境に適したURLとプロパティを含むファイルとの置換に使用されます。サーバー側には、変更されたアーティファクトの受信時に変更はありません。
次の手順は、開発環境からテスト環境への移行時に、デプロイ・プランを使用する方法の概要を示しています。
ユーザーAがBPELプロセスFooを作成します。
ユーザーAは、プロセスFooを開発サーバーにデプロイし、不具合を修正して、ステージング領域でのテストの準備ができるまで、プロセスの調整を行います。
ユーザーAは、Fooのデプロイ・プランを作成し、編集します。これにより、プロセスのURLとプロパティをテスト環境に合うように変更できます。
ユーザーAは、Oracle JDeveloperまたは一連のコマンドライン・スクリプト(ant
ベースも可)を使用して、Fooをテスト・サーバーにデプロイします。手順3で作成したデプロイ・プランにより、FooのURLとプロパティが変更されます。
ユーザーAは、将来プロセス・バーをデプロイし、デプロイ時に同じプランを適用します。URLとプロパティも変更されます。
次の手順は、環境に依存しないプロセスの作成時に、デプロイ・プランを使用する方法の概要を示しています。
注意: このユースケースは、独自の開発サーバー、および同じプロセスの開発を共有する場合は、共通の開発およびテスト・サーバーを持つユーザーに役立ちます。同じデプロイ環境(つまり、同じ開発サーバー)を共有するユーザーには、このユースケースは役に立たない場合があります。 |
ユーザーAがBPELプロセスFooを作成します。
ユーザーAは、プロセスFooを開発サーバーにデプロイし、不具合を修正して、ステージング領域でのテストの準備ができるまで、プロセスの調整を行います。
ユーザーAは、Fooのデプロイ・プランを作成します。これにより、プロセスのURLとプロパティをユーザーAの環境の設定に一致するように変更できます。
ユーザーAは、プロセスFooと手順3で作成したデプロイ・プランをソース・コントロール・システムにチェックインします。
ユーザーBは、ソース・コントロールからプロセスFooをチェックアウトします。
ユーザーBは、使用環境に一致するようにデプロイ・プランのコピーを作成し、新しいデプロイ・プランをプロセスFooのアーティファクトに適用します。
ユーザーBは、Oracle JDeveloperにプロセスをインポートし、いくつかの変更を行います。
ユーザーBは、プロセスFooとデプロイ・プランB(ユーザーBの環境に適合)の両方をチェックインします。
ユーザーAは、再びプロセスFooを、両方のデプロイ・プランとともにチェックアウトします。
この項では、デプロイ・プランの作成および使用方法について説明します。特に、この項では、次のことを説明します。
デプロイ・プランの作成および編集
デプロイ・プランのスーツケースJARファイルへの添付
デプロイ・プランの検証
デプロイ・プランが含まれているスーツケースJARファイルのデプロイ
この項では、Oracle JDeveloperを使用してこれらのタスクを実行する方法について説明します。さらに、オペレーティング・システムのコマンド・プロンプトからこれらのタスクを実行するためのant
コマンドのリストを示しています。
次のant
コマンドをbuild.xml
ファイルに追加します。このファイルは、Oracle JDeveloperのデプロイ・プランを作成するBPELプロセスの「リソース」フォルダにあります。特定のant
コマンド(たとえば、validateplan
またはextractplan
)を使用する予定がない場合、ファイルにその構文を含める必要はありません。
<target name="generateplan1"> <generateplan planfile="genSOAB2.xml" verbose="true" overwrite="true" descfile="${process.dir}/bpel/bpel.xml"/> </target> <target name="generateplan2"> <generateplan planfile="genSOAB2.xml" verbose="true" overwrite="true" suitecase="${process.dir}/output/bpel_SOAOrderBooking_ 1.0.jar"/> </target> <target name="attachplan"> <attachplan planfile="genSOAB2.xml" verbose="true" overwrite="true" suitecase="${process.dir}/output/bpel_SOAOrderBooking_ 1.0.jar"/> </target> <target name="validateplan"> <validateplan planfile="genSOAB2.xml" verbose="true" overwrite="true" suitecase="${process.dir}/output/bpel_SOAOrderBooking_ 1.0.jar" reportfile="${process.dir}/output/aa.txt"/> </target> <target name="extractplan"> <extractplan planfile="genSOB1.xml" verbose="true" overwrite="true" suitecase="${process.dir}/output/bpel_SOAOrderBooking_1.0.jar"/> </target>
これらのant
コマンドは、次のタスクを実行します。
要素 | 説明 |
---|---|
generateplan |
このオプションにより、BPELプロセスのすべてのパートナ・リンク、構成プロパティおよびWSDLインポートを含む編集用のデプロイ・プラン・ファイルを作成します。planfile 属性は、そのデプロイ・プラン・ファイル用に使用する名前を示します。次の2ソースのいずれかからプランを作成できます。
注意: デプロイ・プランの内容は、いずれかのソースと同じです。 |
attachplan |
このオプションにより、デプロイ・プラン・ファイルがスーツケースJARファイルとパッケージ化されます。デプロイ・プラン・ファイルは、スーツケースJARファイル内で自動的に名前がbpeldeployplan.xml に変更されます。このファイルがスーツケースJARファイル内にすでに存在する場合は、新しいプランにより上書きされます。 |
validatePlan |
このオプションにより、デプロイ・プランを検証し、BPELプロセスのデプロイ時に、サーバー側で行われるすべての検索および置換の変更を確認します。このオプションはデバッグ用にのみ使用してください。reportfile 属性により、このテストの結果が書き込まれるファイル名を指定します。たとえば、reportfile="${process.dir}/output/aa.txt" のようになります。 |
extractplan |
このオプションにより、編集のためにスーツケースJARファイルとパッケージ化された既存のデプロイ・プランを抽出します。プラン・ファイルが存在しない場合、これはgenerateplan を使用して新規ファイルを作成するのと同じです。 |
使用環境に適した値を指定します(前述の例でtarget name
、planfile
、descfile
、reportfile
およびsuitecase
に指定されている値は単なる例です)。
編集が完了したら、変更を保存します。
build.xml
を右クリックし、「Antを実行」を選択します。
deploy(デフォルト)を「選択したターゲット」セクションから「使用可能なターゲット」セクションに移動します。
手順2で入力したターゲット名(この例の場合、generateplan1またはgenerateplan2)を「使用可能なターゲット」セクションから「選択したターゲット」セクションに移動します。
「OK」をクリックします。
これによりgenerateplan
が実行され、1つのデプロイ・プラン・ファイルが作成されます。このファイルで、BPELプロセスのbpel.xml
、WSDLおよびスキーマ・ファイルのURLとプロパティを変更できます。このファイルは、planfile
プロパティで明示的にパス(c:\temp\genSOAB2.xml
など)を指定しないかぎり、デフォルトでは、JDeveloper_Home
\JDev\bin
ディレクトリに作成されます。
手順1で説明したbpel.xml
デプロイメント・ディスクリプタ・ファイル・オプションを使用してデプロイ・プラン・ファイルを生成した場合、デプロイ・プラン・ファイルをbuild.xml
ファイルと同じディレクトリに移動する必要があります。手順1で説明したBPELスーツケースJARファイル・オプションを使用した場合、このファイルを移動する必要はありません。
エディタでデプロイ・プラン・ファイルを開き、手動で検索および置換構文を追加します。既存の検索および置換構文を、デプロイ・プラン・ファイルの下部から挿入および編集用のファイルの適切なセクションにコピーすることもできます。この構文を使用して、サーバー名、ポート番号などの値を置換します。新しい値を指定するときに、置換のみの構文を追加することもできます。(partnerLinkBindings
セクションに示すように)各セクションに複数の検索および置換コマンドを追加できます。ファイルの一番下のwsdlAndSchema
セクションで、スキーマ・ファイルの変更を行います。
デプロイ・プラン・ファイルのサンプルを次に示します。
注意: デプロイ・プラン・ファイルには、次に示すJCA構文は自動的に含まれません。JCA値を検索して置換する場合、次に示す構文を編集のためにデプロイ・プラン・ファイルに手動で追加する必要があります。 |
<?xml version="1.0" encoding="UTF-8"?> <!--BPELDeploymentPlan for a suitcase, the file is re usable across suitcases--> <BPELDeplymentPlan xmlns="http://schemas.oracle.com/bpel/deployplan" xmlns:jca="http://xmlns.oracle.com/pcbpel/wsdl/jca/"> <!-- BPELProcess tag indicates the rules apply to a specific process or all processes in the suitcase. A '*' indicates all processes. --> <BPELProcess id="Process1|Process2|Process3"> <!-- this section applies to the configurations in bpel.xml file --> <configurations> <!-- a '*' in name indicates all properties --> <property name="defaultInput|myproperty"> <!-- Use this section to provide a search and replace string --> <searchReplace> <search>http://my.globalcompany.com:9700</search> <replace>http://my.oracle.com:1234</replace> </searchReplace> <searchReplace> <search>/autoloan/mybank</search> <replace>/allloans//boa/</replace> </searchReplace> </property> <property name="property4"> <!-- Use this to replace the value of the property4 --> <replace>![CDATA[This demo showcases the integration of synchronous and asychronous services into an end-to-end business process. This sample application. ]] </replace> </property> </configurations> <partnerLinkBindings> <!-- this section applies to the partnerlink bindings in bpel.xml file. Give '*' to apply for all partner link bindings.--> <partnerLinkBinding name="LoanService1|StarLoan"> <property name="*"> <!-- Use this section to provide a search and replace string --> <searchReplace> <search>http://mydevserver:9700</search> <replace>http://mytestserver:9500</replace> </searchReplace> </property> </partnerLinkBinding> <partnerLinkBinding name="AutoLoanService"> <!-- a '*' in name indicates all properties --> <property name="wsdlRuntimeLocation"> <!-- in this case we are providing a new value for the property, there is no search and replace --> <replace> <value>http://autoloan_test_server:1234/AutoLoan?wsdl</value> </replace> </property> </partnerLinkBinding> <!-- Note: we gave specific search and replace rules for some partner link bindings and this is the rule for all other partner link bindings--> <partnerLinkBinding name="*"> <property name="*"> <!-- Use this section to provide a search and replace string --> <searchReplace> <search>9700</search> <replace>9500</replace> </searchReplace> </property> </partnerLinkBinding> </partnerLinkBindings> </BPELProcess> <!-- This section applies to all wsdl and xsd files in the suitecase, give specific names separated by '|' is need specific replacement--> <wsdlAndSchema name="FlatStructureOutbound.wsdl"|Loademo.xsd> <!-- Remember to add xmlns:jca="http://xmlns.oracle.com/pcbpel/wsdl/jca/" in BPELDeploymentPlan if you want to replace jca properties as shown below. --> <jca:property name="PhysicalDirectory"> <searchReplace> <search>/tmp/dev/inbound</search> <replace>/tmp/test/inbound</replace> </jca:property> <jca:property name="FileNamingConvention"> <searchReplace> <search>.txt</search> <replace>.doc</replace> </searchReplace> </jca:property> <!-- Note: any searchReplace should always be added after jca properties section. --> <searchReplace> <search>http://mydevserver:9700</search> <replace>http://mytestserver:9500</replace> </searchReplace> <searchReplace> <search>dev.xsd</search> <replace>test.xsd</replace> </searchReplace> </wsdlAndSchema> </BPELDeplymentPlan>
BPELデプロイ・プラン・スキーマを次の図に示します。最初の図は、ルート構成BPELDeploymentPlan
を示しています。これにはBPELProcess
構成とwsdlAndSchema
構成が含まれます。
BPELProcess
構成は、次のように構成されています。
wsdlAndSchema
構成は、次のように構成されています。
Oracle JDeveloperに戻ります。
build.xml
ファイル内を再び右クリックし、「Antを実行」を選択します。
attachplanを「選択したターゲット」セクションから「使用可能なターゲット」セクションに移動します。
「OK」をクリックします。
この結果、新しいデプロイ・プラン・ファイルがBPELスーツケースJARファイルにパッケージ化されます。ファイル名はbpeldeployplan.xml
に変更されます。スーツケースJARファイルは、BPELプロセスのoutput
ディレクトリに作成されます。
注意: attachplan コマンドでは、古いbpel.xml 、WSDLおよびXSDファイルが、新しい値を含むファイルと置換されません。置換は、手順20でBPELプロセスがデプロイされる場合にのみ発生します。 |
build.xml
ファイル内を再び右クリックし、「Antを実行」を選択します。
validateplanを「選択したターゲット」セクションから「使用可能なターゲット」セクションに移動します。これはオプションのコマンドです。
「OK」をクリックします。
Oracle JDeveloperのログ・ウィンドウには、検証が成功したかどうかが表示され、BPELプロセスのデプロイ中に実行されるすべての検索および置換コマンドのリストが示されます。この情報は、手順2でbuild.xml
ファイルのreportfile
属性で指定したファイルにも書き込まれます。
すべての検索および置換構文が正しいことを確認するために、情報を見なおします。
build.xml
ファイル内を再び右クリックし、「Antを実行」を選択します。
deploy(デフォルト)を「選択したターゲット」セクションから「使用可能なターゲット」セクションに移動します。
注意: これらのコマンドを別々に指定する他に、attachplan、validateplanおよびdeploy(デフォルト)を「使用可能なターゲット」セクションに一緒に移動し、「OK」をクリックすることもできます。これにより、3つのコマンドがすべてバッチ・プロセスとして実行されます。 |
「OK」をクリックします。
BPELスーツケースJARファイル内のファイルは、次の環境に適したURLとプロパティを含むファイルに置き換えられます。
表5-7では、デプロイメント・ディスクリプタ・プロパティの変更について説明しています。
表5-7 デプロイメント・ディスクリプタ・プロパティの変更
名前 | タイプ | ステータス | 説明 |
---|---|---|---|
|
構成 |
10.1.3.4で除外 |
|
|
構成 |
10.1.3.3以降アクティブ |
これは、配信レイヤーでのこのプロセスの永続ポリシー用の設定です。この設定により、
|
|
構成 |
10.1.3.3以降アクティブ |
インスタンスが完了すると、Oracle BPEL Serverでは、インスタンス・ストアにグローバル変数値が保存されます。指定可能な値は、次のとおりです。
|
|
partnerLinkBinding |
10.1.3.3以降アクティブ |
複数のWSDLポートが使用可能な場合に使用する優先ポート。値は、WSCLポートの |
|
partnerLinkBinding |
10.1.3.3以降アクティブ |
指定可能な値は、次のとおりです。
|
|
partnerLinkBinding |
10.1.2以降アクティブ |
指定可能な値は、次のとおりです。
|
注意: 10.1.3.4では、transaction=participate プロパティはbpel.xml のconfiguration プロパティ・セクションでサポートされていません。フォルトが発生しないようにするには、プロセス・レベルの有効範囲でcatchAllブランチを使用するようにBPELプロセスを変更します。 |
リリース10.1.3.4では、ora-retry
アクションによりインスタンスのリカバリが行われるようにフォルト・ポリシーを構成し、指定したインスタンスの再試行回数を超えたときのために、フォルト管理フレームワークの動作が変更されました。この変更については、表5-8で説明されています。
表5-8 フォルト管理フレームワークの変更
リリース10.1.3.3.0 | リリース10.1.3.4 |
---|---|
インスタンスの再試行回数を超えると、インスタンスが |
インスタンスの再試行回数を超えると、インスタンスが |
インスタンスをopen.faulted
としてマークすることで、失われるインスタンスはなくなります。フォルト・ポリシー・ファイルで次のようにora-retry
アクションの後に別のフォルト処理アクションを構成できます。
Oracle BPEL Controlから手動でインスタンス・リカバリを実行するためにora-human-interventionアクションを構成
インスタンスを閉じ(closed.faulted
としてマーク)再試行を行わないようにora-terminate
アクションを構成
ただし、フォルト・ポリシー・ファイルでora-retry
アクション後に実行されるようにアクションを設定せず、インスタンスの再試行回数を超えると、インスタンスはopen.faulted
としてマークされたままで、リカバリでそのインスタンスの処理を試みます。
たとえば、次のフォルト・ポリシー・ファイルでora-retry
の後にアクションが定義されていない場合があるとします。
<Action id="ora-retry"> <retry> <retryCount>2</retryCount> <retryInterval>2</retryInterval> <exponentialBackoff/> </retry> </Action>
Oracle BPEL Serverでは、次のアクションが実行されます。
invokeアクティビティを試行(フォルトを処理する前述のフォルト・ポリシー・コードを使用)
間隔を増加して2回再試行(2秒後、次に4秒後)
すべての再試行が失敗すると、Oracle BPEL Serverで次のアクションが実行されます。
監査証跡に詳細なフォルト・エラー・メッセージを記録
インスタンスをopen.faulted
(進行中の状態)としてマーク
インスタンスを取得し、invokeアクティビティを再試行
Oracle BPEL Serverのリカバリも失敗する可能性があります。その場合、invokeアクティビティが再実行されます。追加の監査メッセージが記録されます。
関連項目: フォルト管理フレームワークの詳細は、『Oracle SOA Suite New Features』を参照してください。このドキュメントは、次のURLで入手可能です。
|
10.1.3.4より前のリリースでは、監査証跡とBPELプロセスが、同じトランザクションに参加します。特定の状況下で、BPELプロセスのインスタンスはOracle BPEL Controlに表示されませんでした。これは、そのプロセスが実行されていないという印象を与えました。実際には、プロセスは実行されましたが、どのような理由であれ、トランザクションはロールバックされました。この場合、監査証跡もロールバックされました。したがって、インスタンスのエビデンスはOracle BPEL Controlに表示されませんでした。
Oracle BPEL Serverは正しく動作しました。つまり、コミットする必要のないデータはコミットされず、メッセージは失われませんでした。Oracle BPEL Controlの「手動リカバリの実行」リンクの下で、デハイドレートされた最後のメッセージが使用可能で、BPELプロセスは取得可能でした。ただし、トランザクションがロールバックされたインスタンスがOracle BPEL Controlで表示されないいくつかの状況がありました。
リリース10.1.3.4では、監査証跡が独自の個々のトランザクションに参加します。BPELインスタンスがロールバックされる場合、すべての動作は同じです。Oracle BPEL Controlでインスタンスが見られるようになった点だけが異なります。さらに、監査証跡スレッドは非同期であるため、監査証跡がデハイドレーション・ストアに保存されるのを待つ間、BPELインスタンスはブロックされません。