|
|
この節では、BEA WebLogic® Workshop の BPEL インポート ツールを使用して BPEL ファイルをインポートする方法を説明します。
WS-BPEL (一般に「BPEL」と呼ばれる Web サービスの Business Process Execution Language) はビジネス プロセス自動化のための正式な言語仕様を定義します。
BPEL で記述されたプロセスは、XML ドキュメントを使用する Web サービス間の対話を、標準化された方法で統合することができます。BPEL 仕様に準拠していればどのプラットフォームや製品であってもこれらのプロセスを実行できます。したがって、BPEL により、プロセスの定義をさまざまな作成ツールと実行プラットフォーム間で移動することが可能になり、プロセスの自動化に対する顧客の投資を保護することができます。ビジネス プロセス定義を標準化しようとする試みは以前からありましたが、BPEL はそれまでで最大の注目を浴び、必要なソフトウェア ベンダの支持を獲得した第一号です。
WS-BPEL 2.0 は現在、OASIS 標準です。BPEL の詳細については、BPEL4WS 仕様 v1.1 および
WS-BPEL 仕様 2.0 を参照してください。また、OASIS が運営する BPEL 標準化作業の公式ページも参照してください。BPEL のインポートおよびエクスポート ツールは主として、1.1 および 2.0 の仕様をサポートする他のツールとの設計時における相互運用を可能にするために提供されています。
BPEL インポート ツールで JPD ファイルに BPEL ファイルをインポートして、BEA WebLogic Workshop 設計環境で使用することができます。BPEL ファイルの主な統合ロジックは JPD ファイルにインポートされますが、インポートされた JPD ファイルは通常、Workshop でただちに実行することはできません。
特定の状況では、JPD と BPEL 言語間、または XQuery、Xpath、XSLT 間の相違を含むさまざまな表現言語間の機能的な不一致のため、実行時セマンティクスは保証されていません。ベンダ拡張機能、外部アーティファクト、または環境設定に関わる場合、実行時セマンティクスも保証されません。したがって、インポートされた JPD ファイルは、正常な動作を確保するために加える必要のある変更をすべて検討し、テストする必要があります。
一般に、BPEL インポート ツールは、入力として、完全な BPEL と WSDL アーティファクトを想定しています。ツールはある程度までは、不完全な BPEL や、WSDL アーティファクトを扱います。このため、進行中の BPEL ファイルを JPD としてインポートしてから WebLogic Integration 環境で処理を完了することができます。不完全なケースは多く、他のケースと同様に、WSDL ファイル、型定義、ポート型定義が不足していたり、<while>、<switch>、<invoke>、<receive>、<reply>、<onMessage>、<onAlarm>、<throw> の構造が不完全であることがあります。BPEL インポートが JPD ファイルに入力アーティファクトをインポートすることができない場合、エラー メッセージが現れ、将来のインポートのために入力アーティファクトを修正することができます。
インポート] の順に選択します (図 1-1 を参照)。[インポート] ペインが表示されます。| 注意 : | BPEL インポート ツールは、スキーマ/プロジェクト ルート ディレクトリへのインポートをサポートしません。ルート ディレクトリにインポートしようとすると、以下のエラー メッセージが表示されます (図 1-2)。 |
.bpel ファイルを選択します。同様に、図 1-3 に示すように、[WSDL/XSD の場所] を参照し、Web Services Description Language の WSDL および XSD ファイルのパスを設定します。| 注意 : | [パッケージ名] フィールドには適切なパッケージ名を入力します。 |
| 注意 : | [Util プロジェクト] フォルダを選択します。Weblogic Process Application によって作成された Util プロジェクトをポイントするようにします。 |
| 注意 : | インポート プロセスのログ ファイルは BpelImport.log という名前で workspace/.metadata フォルダに格納されます (workspace は現在の Weblogic Process Application ワークスペースを示す)。 |
新しい JPD ファイルが手順 2 で指定されたフォルダに現れ、図 1-6 のように WSDL ファイルがスキーマ フォルダにコピーされ、置かれます。
これによりインポート プロセスが完了し、新しい JPD ファイルが手順 2 で指定されたフォルダに置かれます。
この節では、BPEL インポート ツールのいくつかの確認済みの制限事項および問題について説明します。これらの問題の大部分が JPD と BPEL 言語間の本来有する違いによるものです。
| 注意 : | 生成された JPD ファイルが入力 BPEL ファイルと意味的に対応することを確認する必要があります。 |
![[問題] ビュー - 警告メッセージ](wwimages/import_problemview.gif)
eventHandler はサポートされていません。BPEL ファイルに含まれていると、変換プロセスでは無視され、「グローバルなイベント ハンドラはサポートされないため、無視されます。until 属性で期間が指定された wait および onAlarm の変換はサポートされていません。BPEL ファイルに until 属性が含まれていると、その属性はサポートされていないため、生成される JPD ファイルでは無視されることを通知する警告が表示されます。この警告が表示された後、変換プロセスは続行されます。| 注意 : | 有効な BPEL ファイルに両方の属性 (for と until) を指定することはできません。 |
flow で始まる BPEL ファイルはサポートされていません。最初の論理的な子が flow 構造体である BPEL ファイルは変換できません。ここでは、論理アクティビティとは、シーケンスおよびスコープ以外のアクティビティを指します。flow アクティビティの links の変換はサポートされていません。変換する BPEL ファイルに links が含まれていると、links、source、target が含まれるため、生成される JPD ファイルが有効ではないことを通知する警告が表示されます。変換プロセスは続行され、サポートされていないこれらのアクティビティは無視されます。reply アクティビティを使用して通常の出力/結果を返す BPEL ファイルの変換はサポートされていません。適切に変換するために、BPEL ファイルには、通常の結果を返す reply アクティビティを 1 つだけ指定する必要があります。これは、JPD ファイルには、同期 clientReceive に対する returnMethod を 1 つしか含めることができないためです。これに対して、BPEL ファイルには、単一の receive に対して複数の reply アクティビティを含めることができます。単一の receive ノードと複数の reply ノードを単一の clientRequestWithReturn に直接マップする方法はありません。OnAlarm アクティビティを含む pick アクティビティの変換はサポートされません。これは、pick は eventChoice に変換されるためです。各 eventChoice に含めることができる timeoutEvent ノードは最大 1 つですが、これは 1 つの onAlarm アクティビティに対して 1 つ生成されます。 bpws:getVariableData(..) による onAlarm アクティビティの for 属性の指定はサポートされていません。bpws:getVariableData(..) を使用して for 属性を指定すると、インポートされたコードに構文エラーが発生します。WARNING: Failed to parse input XSD & WSDL files. Please see logs for detail」というメッセージが表示され、ログ ファイルに「Duplicate global type」というエラー メッセージがある場合は、ネームスペースの複数の定義を無視するように指定する必要があります。
インポート プロセス用のログ ファイル BpelImport.log は BEA_HOME\user_projects\workspaces\bpel_import\.metadatap に格納されます。%BEA_HOME% は製品のホーム ディレクトリです。このログ ファイルは、インポート プロセスに関する情報を提供します。
ネームスペースの複数の定義を無視するように指定するには、[スキーマ プロジェクトプロパティビルド] を選択し、無視するネームスペースを [次のネームスペース内にある複数の定義を無視] フィールドに指定します。
assign アクティビティをインポートしたときに実行されるクエリ解析が制限されます。したがって、生成される XQuery 式が常に正しい構文とは限りません。生成されたすべての XQuery 式が正しいことを確認してください。assign を変数に変換すると、変換後の XQuery ファイルをデザイン ビューで表示したときに「メインの XML 要素がターゲット スキーマのルート ノードと一致しません。」という解析エラーが発生する場合があります。ただし、実行時には正しい値が生成されるので、このメッセージは無視できます。このエラーは、XML Mapper のデザイン ビューの制限により、正しい XQuery 式も常に解析できるわけではないために発生します。eventHandlers が含まれる BPEL ファイルをインポートすると、eventHandler onMessage パスに対してダミーの Timer メソッドが生成されます。JPD の仕様では、onMessage パスと onTimeout パスは、自動的に実行されないプロセス ノード (またはノード ブロック) にのみ関連付けることができます。この制約に対応するために、eventHandler が receive、onMessage、flow、wait のどのアクティビティも含まないスコープに関連付けられる場合は、1 秒でタイムアウトするダミーの Timer ノードが作成されます。attributeFormDefault="qualified" と elementFormDefault="qualified" を設定し、修飾クエリ文字列を使用して、クエリ文字列を適切に修飾する必要があります。適切に修飾されていない場合、生成された XQueries は実行時に失敗します。reply アクティビティを指定できます。JPD ファイルでは、これはサポートされていません。複数のパートナ リンクのうち 1 つだけが、応答セマンティクスに合致する clientRequestWithReturn として変換されます。他のパートナ リンクの reply アクティビティは非同期インタフェースに変換されます。onMessage パスに変換されますが、セマンティクスに多少の違いがあります。インポートされた JPD ファイルでは、イベントが受信され、onMessage パスが実行されると、その onMessage パスが完了するまでブロック (BPEL のスコープに相当) の実行は継続されません。つまり、イベント ハンドラのインスタンスは、常に 1 つだけアクティブになることができます。invoke アクティビティを Web サービスの controlSend 呼び出しに変換します。指定したパートナ サービスの Web サービス コントロールが生成され、JPD ファイルはコントロールの対応するメソッドを呼び出します。今回のリリースでは、特定の状況での Web サービス コントロール (JCX ファイル) を生成機能に制限があります。生成された JCX ファイルの内容を慎重に調査して、コンパイル可能であることを確認してください。 <reply> が含まれる BPEL プロセスから生成される JPD ファイルが、論理的に正しくありません。これは、同期操作の対応する receive と reply が同じレベルに存在しないためです。 <receive> - <reply> ブロック内の任意のノードに関連付けられたイベント ハンドラはサポートされません。このような場合、生成された JPD はコンパイルできません。 until および repeatEvery はサポートされておらず、無視されます。suppressJoinFailure および exitOnStandardFault は無視されます。
  
|
