コーヒーブレイク(1) デバッグルール
このコーナー(?)では、BizTalkと微妙に関係の無い話題を触れたいと思います。
BizTalkの開発で一番難しい点は、ずばりデバッグだと思います。
これは、BizTalkがIISやSQL Server、.NET、MSMQ、COM+など複数のテクノロジから構成されていることと、バックエンドで動くブラックボックスな製品であることが理由です。
BizTalkのデバッグでお困りの方は一度読んでみられてはいかがでしょうか？
（本の内容自体は、BizTalkとは全く関係ありません）
『デバッグルール』
http://www.amazon.co.jp/exec/obidos/ASIN/4891004398/qid%3D1106520859/250-3262856-9210619
それでは、この本で解説されているデバッグルールをBizTalk の開発に適用してみましょう。
1. システムを理解する
BizTalkの機能、仕組みを理解しないとどこで問題が起きているかわかりません。
ヘルプやMSDN、必要であればサポート技術情報を調べてみましょう。
特に、送受信メッセージポート、オーケストレーションが、
BizTalk内部でコンポーネントがどの順番で処理されるか理解しておくことが重要になります。2. わざと失敗してみる
エラーが起きたときのメッセージ（XMLデータ）を取得し、テストしてみましょう。
状態と動作状況の監視（HAT）ツールを使ってメッセージを取得できますし、
受信したメッセージをログとして残す仕組みを用意してるとデバッグが便利になります。
（例えばパイプラインコンポーネントでログを残すようにしておくとか）3. 考えるのをやめて観察する
あれこれ憶測するのではなく、状況、状態をよく観察しましょう。
BizTalkのエラー情報はイベントログのアプリケーションログに記録されるので、そのメッセージを調べましょう。
慣れてくるとエラーメッセージの内容で、どこに問題が生じているかわかるようになります。4. 分割して攻略する
エラーが発生している場所が特定できない場合は、機能を分割して絞り込みます。
メッセージングでエラーが発生しているのか？オーケストレーションで発生しているのか？
オーケストレーションの場合は、処理を分割してテストしていきます。5. 一度に１つずつ変える
メッセージポートの設定変更、オーケストレーションの変更などは１つずつ行い、テストしましょう。
よくやりがちですがいっぺんに変更すると（たとえうまくいったとしても）問題の原因がわからなくなります。6. 履歴をつける
デバッグに限らず変更内容は細かく履歴に残しましょう。
エラーが発生した場合、正常に処理できていた時点までさかのぼることができます。
何を行ってからエラーが発生するようになったか知ることもできます。7. 電源を確認する
エラーは自分の思い込みが間違っていたことから発生していることがよくあります。
BizTalkに関連するWindowsサービスが正常に起動されているか？
メッセージポート、オーケストレーションは正常に開始されているか？
デバッグがうまくいかない場合は、これらを確認してみてください。8. 新しい視点でものを見る
色々テストしてみて、それでもうまくいかない場合は他の人に聞いてみましょう。
単に他の人にエラーの状況を説明するだけでも、自分の頭の中で今の状況を整理することができます。9. あなたがしなければ問題は解決しない
複数人でBizTalkの開発を行っている場合は特に重要です。
他の人が変更を加えていないか確認しましょう、
何もしてないのに自然とバグが無くなるということはありえません。
特に結合テスト時は、他の人が設定など変更してないか注意しましょう。
デバッグがうまくいかずに煮詰まっているときは、これらを読み返してみてください。
きっとデバッグのために何をやればよいか、何をやり忘れていたか思いつくと思います。
