(2008/04/08 リンクを変更)
環境:
.NET Framework 3.0
BizTalk Server 2006 R2
Visual Studio 2005
WCF LOB Adapter SDK
BizTalk LOB Adapter Pack
Oracle 10 g Express Edition
Oracle Data Access Components (ODAC) 2.0
- WCF と BizTalk、そして LOB Adapter
- WCF における Binding と Channel の基礎
- WCF LOB Adapter SDK によるカスタムアダプター実装
- WCF からの LOB Adapter の使用
- BizTalk Server からの LOB Adapter の使用 – schema 編
- BizTalk Server からの LOB Adapter の使用 – orchestration 編
- BizTalk Server からの LOB Adapter の使用 – deploy 編
こんにちは。
今回は、前回までに作成した BizTalk プロジェクトを配置して、実際に動作を確認してみましょう。
(長々とすみませんでしたが、いよいよ最後です。後半はちょっと飛ばしましたが、29日に福井でセミナーがあり、そのサンプルコードとして間に合わせたかったのです、、、)
BizTalk プロジェクトのビルドと配置
- まず、ビルドをおこなう前に、前回作成したプロジェクトに署名を添付します。
- Visual Studio コマンドプロンプトを立ち上げ、以下のコマンドを実行してキーファイルを作成します。
C:\Demo\IntegrationSample> sn -k IntegrationSample.snk - ソリューションエクスプローラでプロジェクトを右クリックし、[共通プロパティ] – [アセンブリ] ノードの [アセンブリキーファイル] 欄に、上記で作成したキーファイルを指定します。
- ビルドをおこないます。
- つぎに、配置をおこないます。
まず、ソリューションエクスプローラでプロジェクトを右クリックし、[構成プロパティ] – [展開] ノードの [アプリケーション名] 欄に、「IntegrationSample」などのアプリケーション名を設定します。
そして、ソリューションエクスプローラでプロジェクトを右クリックし、[配置] を選択します。
以上で、作成したプロジェクトが dll としてコンパイルされて GAC に登録され、BizTalk Server にアプリケーション登録がおこなわれます。
BizTalk アプリケーションの設定
オーケストレーション構築の際には接続の “論理ポート” の設定を実施しました。
ここからは、上記で配置した BizTalk アプリケーションの “物理ポート” (Oracle 接続、ファイル接続、など) の設定をおこなっていきます。
- [スタート] メニューから、[BizTalk Server 管理] で管理コンソールを起動します。
- まずは、Oracle からのデータ受信のための物理ポートを設定します。
- 管理コンソールの [コンソール] – [BizTalk Group [<構成データベース名>]] – [アプリケーション] – [IntegrationSample] ノードの下の、[受信ポート] ノードをクリックします。
- 右ペイン上で右クリックをおこない、[新規作成] – [一方向の受信ポート] を選択します。
- 表示される画面で [受信場所] を選択し、[新規作成 …] ボタンをクリックします。
- さらに表示された画面上で、[トランスポート] – [種類] として「WCF-Custom」を選択し、[受信パイプライン] として「XMLReceive」を選択して [構成] ボタンを押します。(前々回ご説明したように、LOB Adapter は WCF-Custom アダプターの上で動く、ということを思い出してください。)
- 表示された画面で、以下の通り入力します。[全般] – [URI] : OracleDb://<data source name>[バインド] – [バインドの種類] : OracleDBBinding
[バインド] – [PollingInterval] : 30
[バインド] – [PollingStatement] : SELECT * FROM TESTORDER WHERE ID NOT IN (SELECT ID FROM TESTORDERHISTORY) FOR UPDATE
[バインド] – [PostPollStatement] : BEGIN TESTPKG.POSTPOLL_ACTION(); END;[その他] – [ユーザアカウント] – [ユーザ名] : <Oracle のログインユーザ ID>
[その他] – [ユーザアカウント] – [パスワード] : <Oracle のパスワード>
(注意 : ID / パスワードはすべて大文字で記入してください)[メッセージ] : ボディ
- つぎに、CustomAdapter1 に送信/受信するための物理ポートを作成します。
- 今度は [送信ポート] ノードから [新規作成] – [静的な送信請求 – 応答の送信ポート] を選択して作成します。
- 同様に、型とパイプラインを下図の通り入力し、[構成] ボタンに進みます。(XML の送信時は、下図のように XMLTransmit を選択します)
- 表示される画面で、こんどは以下の通り設定します。
ポイントは「SOAP アクションヘッダ」です。第 3 回「WCF LOB Adapter SDK によるカスタムアダプター実装」で記載したように、「Node ID は、BizTalk から使用する際に重要な文字列です」 の意味がここになります。
Oracle アダプターの場合には、このノードIDとして「http://Microsoft.LobServices.OracleDB/2007/03/SCOTT/Package/ACCOUNT_PKG/CREATE_ACCOUNT」などの一意なノードIDの文字列が使用されていますが、今回は第 3 回で以下のようなノードIDで作成してしまったので、その ID をそのまま使用します。
また今回は、[Count] プロパティを 3 としていますので、この CustomAdapter1 は、文字列を 3 回繰り返して応答を返すように動作します。[全般] – [URI] : myscheme://hostname
[全般] – [SOAP アクションヘッダ] : Custom1/EchoTimes[バインド] – [バインドの種類] : myCustomBinding1
[バインド] – [Count] : 3[メッセージ] – [送信 WCF メッセージ本文] : ボディ
[メッセージ] – [受信 BizTalk メッセージ本文] : ボディ
[メッセージ] – [エラー処理] : エラーメッセージを伝達する - さいごに、ファイル送信用の送信ポートを作成します。
- [送信ポート] ノードから [新規作成] – [静的な一方向の送信ポート] を選択して作成します。
- 同様に、型として「FILE」、パイプラインとして「XMLTransmit」を選択し、[構成] ボタンに進みます。
- 表示される画面の [コピー先フォルダ] として、ファイルを保存する先のフォルダを選択します。(以下の通りになります。今回はメッセージIDをファイル名としていますが、出力ファイル名をカスタマイズしたいときには、オーケストレーションで扱ったメッセージオブジェクト (Out) の属性を設定し、ここでその属性に応じたファイル名の指定をおこなうことで思い思いにファイル名をカスタマイズすることができます。)
- さいごに、作成した物理ポートと、オーケストレーションの際に作成した論理ポートをマップします。
- 管理コンソールで、[オーケストレーション] ノードを選択し、表示されているオーケストレーション (1 つです) を右クリックして、[プロパティ] を選択します。
- 表示される画面で [バインド] ノードをクリックし、左に表示されている論理ポートに、それぞれ物理ポートを選択して設定します。(ホストも、物理ポートで選択していたホストと同一のホストを選択しておきましょう。)
以上で物理アダプターの設定は終了です。
実行と動作確認
では実行し、動作を確認してみましょう。
まず、管理コンソール上から上記の「IntegrationSample」を開始します。
これで、このビジネスは稼働しています。
では、SQL Plus などで Oracle にログインし、行を挿入してみましょう。
SQL > insert into testorder (id, name) values (1, 'laptop');SQL > insert into testorder (id, name) values (2, 'printer');SQL > commit;
すると、30 秒ほど経過すると、挿入した行数分のファイルがアダプターで指定したフォルダに作成されているのがわかります。
ファイルを開くと、以下のように文字列が 3 回繰り返されて出力されているのがわかります。(あまり楽しくないサンプルかもしれませんが、こんな調子で SharePoint、メインフレーム、などさまざまなアプリケーションやシステム、プロトコルと連携できます。)
<?xml version="1.0" encoding="utf-8" ?> <EchoTimesResponse xmlns="myscheme://myadapter"> <EchoTimesResult>laptoplaptoplaptop</EchoTimesResult> </EchoTimesResponse>
なお、エラーが発生した場合、イベントログに書き込まれますので確認してください。(BizTalk の管理コンソールから参照できます。また、オーケストレーション内部であればデバッグをおこなうことができます。)
また、スキーマやアセンブリの変更に際しては BizTalk Server の管理コンソールからホストインスタンスの再起動などが必要になる場合がありますので注意しましょう。
ここで作成したサンプルプロジェクト -> Download
最後に
以上で、BizTalk において WCF がどのような役割を果たすかをみてきました。
クライアント – サーバ間の通信や、リアルタイムなシステム連携、UI 連携のシナリオなど、「SOA」などと大上段に構えない通常の「通信処理」においては WCF 単体で充分ですが (むしろ余計な処理は必要ありませんが)、BizTalk Server 2006 R2 を使用すると、こうした「SOA」におけるシステム連携アダプターの場面でも、優れた WCF の仕組みの恩恵を受けることができるようになっていることがおわかり頂けたと思います。(WCF のこの優れたフレームワークによって、高度なアダプターの構築も “比較的” 簡単に可能なことがおわかり頂けると思います。また、例えば IBM Wepshere MQ 用の TransportBindingElement を構築して、WCF で使うときにはこの BindingElement を組み合わせて軽量な Binding を構成し、BizTalk から使うときにはこの BindingElement を組み合わせて Adapter 用に Binding を構成する、などといったアーキテクチャ統一も可能です。)
.NET Framework に詳しい方は、もう 1 つ気になっていることがあるのではないかと思います。
それは、.NET Framework 3.0 で追加されたもう 1 つの基盤である WF (Windows Workflow Foundation) です。こちらも BizTalk Server の “オーケストレーション” を見て頂いておわかりの通り、SOA においてその 1 部が必要とされている Foundation の 1 つです。
この点について、まず誤解のないように記載しておくと、単にワークフローとして統一できれば良いというわけではないという点です。
ワークフローと一口に言っても、
- データの遷移や自動応答/自動運用アプリケーションなど、アプリケーションの一部として組み込まれる機械的なワークフロー
- SharePoint の承認フローなどに代表されるドキュメントワークフロー / ヒューマンワークフロー
- そして今回扱ったようなもっと大きな粒度のシステム間の 「オーケストレーション」
といった具合です。
システムオーケストレーションの粒度の場合には、企業の「ビジネス」そのものが表現されたレベルであるべきで、ここにシステム的な動作など細かなものを混ぜるべきではありません。例えば、「SharePoint で扱うヒューマンワークフローで注文書が承認されたら、企業内の経理システム、発注管理システム、予算管理システムにその結果を通知して、さらに各部門でこれらのシステムを通しておのおののプロセスが走る」 といった例の場合に、これらすべてのフローを 1 つにまとめてしまうのはナンセンスです。
またそれぞれに利用者も微妙に異なってきます。例えばヒューマンワークフローでは、エンドユーザレベルでコンポジット可能な SharePoint Designer のようなツールも必要になるわけです。
つまり、第 1 回に WCF と BizTalk の関係を説明したときと同様、WF の登場によって BizTalk がなくなってしまうということはありえません。双方共、それぞれの意味で必要となります。
では「それぞれのツールがまったく別で良いのではないか ?」と思われるかもしれません。
しかし、それもある意味不正解です。もし、まったくばらばらなワークフローエンジンを使っていたならば、いざ何かあった場合の保守・管理も異なる 「知識」 が必要になりますし、ワークフローどうしの連携やインターセプターなどが必要になった場合にもアーキテクチャの相違などが生じてやっかいなことになってしまうでしょう。
WF は、まさしくそうした基盤を提供する「共通的なエンジン」(= あらゆるレベルのワークフローのエンジンとしての基盤) として登場しました。WCF 同様、「製品」ではなく「基盤」なのです。
WF をご存知な方は、オーケストレーションの作成の際に、メモリからの非活性化の考え方など、部分部分似ているところを発見されたかもしれません。WF は、実はマイクロソフトの BizTalk 開発チームメンバの多くが関与して構築されています。ばらばらのチームが勝手に開発したのではなく、将来的なテクノロジー統合なども見据えて設計されています。
書籍「プロフェッショナル BizTalk Server 2006」にも記載されている通り、上述のエンジンのレベルでの連携/統一を見据え、今後 (将来) の BizTalk Server のリリースにおいては現在の XLANG ベースのオーケストレーションエンジンと並行して、WF も採用されることが “今のところ” 予定されています (今回の WCF のケースと同様、以前のオーケストレーションとアーキテクチャ上の不整合のない形で (いま作った資産をそのまま踏襲できる形で) BizTalk のエンジンの一部として搭載されていくことでしょう)。
【参考リソース】
Installing Microsoft BizTalk Adapter Pack :
http://download.microsoft.com/download/e/6/a/e6a2d71d-b4bb-4c7c-959d-0b0f14b6e5df/InstallationGuide.htm
Microsoft BizTalk Adapter Pack Samples :
http://msdn2.microsoft.com/en-us/biztalk/cc196386.aspx
Receiving Polling-based Data-changed Messages :
http://msdn2.microsoft.com/en-us/library/cc185357.aspx
BizTalk : Constructing Messages in User Code :
http://msdn2.microsoft.com/ja-jp/library/aa578196.aspx
MSDN Forum (日本) : BisTalk Server
http://forums.microsoft.com/MSDN-JA/ShowForum.aspx?ForumID=361&SiteID=7
MSDN Forum (US) : BizTalk R2 Adapters and Adapter Pack
http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1471&SiteID=1
【ここまで読み進めてこられた方へ (訂正)】
すみません、BizTalk から動かしてみたところ、今まで作ったもので一点だけ修正がありました。カスタムアダプターで、ClearContext() メソッドもコールされるので、ここも NotImplementException を外しておいてください。
第 3 回「WCF LOB Adapter SDK によるカスタムアダプター実装」の中に、赤字で追記しておきました。
(申し訳ありません _○_)
Categories: Uncategorized
PingBack from http://blogs.msdn.com/tsmatsuz/archive/2008/03/27/soa-wcf-6-lob-adapter-biztalk-server-orchestration.aspx
LikeLike
環境: Office SharePoint Server (MOSS) 2007 BizTalk Server 2006 R2 SharePoint と BizTalk の連携 考え方と環境準備 WSS
LikeLike
環境: Microsoft Office SharePoint Server (MOSS) 2007 (または WSS 3.0) BizTalk Server 2006 R2 Visual Studio
LikeLike