このトピックでは、BizTalk アプリケーションの展開に従う必要があるベスト プラクティスの一覧を示します。
BizTalk アプリケーションの展開
アプリケーションの展開手順を文書化する
アプリケーションのデプロイで使用されるすべての手順が詳細に文書化されていることを確認します。そのため、デプロイの実行方法を記録し、さらにデプロイする方法やデプロイを解除する方法を把握します。 スクリプト化されていないものは、詳細な手順で文書化する必要があります。 これには、外部システムに対する変更の文書化と、サード パーティ製コンポーネントのデプロイが含まれます。
スクリプト アプリケーションのデプロイ
できるだけ多くのアプリケーション展開手順をスクリプト化します。 スクリプトを使用すると、デプロイ プロセス中に人為的エラーが発生するリスクが軽減されます。
BizTalk アプリケーションの作成
BizTalk アプリケーションと .msi ファイルの作成をスクリプト化する
- BtsTask.exe を使用して、BizTalk アプリケーションの作成をスクリプト化できます。 アプリケーションの作成がスクリプト化されている場合は、ビルド サーバー上の自動化されたプロセスを使用してパッケージを自動的にビルドできます。 アプリケーションの作成スクリプトの詳細については、「 BizTalk アプリケーションの展開と管理」を参照してください。
BizTalk アセンブリの展開
Visual Studio から運用環境のコンピューターにアセンブリを配置しない
開発プロセス中、開発者は多くの場合、Visual Studio からアセンブリを再デプロイする必要があります。 再デプロイを有効にするために、Visual Studio はアセンブリに含まれる成果物の展開、バインド解除、停止、およびリスト解除を行うことができます。 これは開発環境で必要かつ適切ですが、運用環境では予期しない、望ましくない結果を引き起こす可能性があります。 このため、運用環境のコンピューターに Visual Studio からアセンブリを展開できないようにするため、Visual Studio を運用コンピューターにインストールしないようにすることをお勧めします。
また、Visual Studio を実行しているコンピューターから実稼働データベースを参照しないでください。
BizTalk アプリケーションへの成果物の追加
1 つのアプリケーションで関連する成果物をグループ化する
可能な限り、関連する成果物を同じ BizTalk アプリケーションに配置します。 これにより、成果物を 1 つのエンティティとして管理およびデプロイできるため、管理が容易になります。 同じビジネス プロセスをサポートする成果物、または同様の機能を実行する成果物を 1 つのアプリケーションにグループ化できます。
別のアプリケーションに共有成果物をデプロイする
成果物が 2 つ以上のアプリケーションによって共有される場合は、共有成果物を別のアプリケーションにデプロイします。 たとえば、2 つのアプリケーションがスキーマを共有している場合は、スキーマを別のアプリケーションに配置します。 これは、BizTalk グループ内の 1 つの成果物のみが 1 つのローカル一意識別子 (LUID) を持つ可能性があるため、これをお勧めします。 LUID は、アーティファクト名と必要に応じて他の属性で構成されます。 あるアプリケーションに成果物を含め、別のアプリケーションから成果物への参照を作成した場合、成果物を含むアプリケーションを停止すると、参照元アプリケーションが正しく機能しない可能性があります。
このベスト プラクティスは、ファイルの種類としてアプリケーションに追加される Readme ファイルやスクリプトなど、ファイルを除くすべての成果物の種類に適用されます。 これは、同じ名前の複数のファイル成果物を BizTalk グループに展開できるためです。 そのため、2 つ以上のアプリケーションで同じ名前のファイルを使用できます。 この場合、1 つのアプリケーションを停止すると、もう一方のアプリケーションには影響しません。 ファイル成果物の追加の詳細については、「 アプリケーションにファイルを追加する方法」を参照してください。
別のアプリケーションに共有 Web サイトを展開する
Web サイトが複数のビジネス ソリューションによって共有される場合は、別のアプリケーションに Web サイトを展開します。 これは、BizTalk アプリケーションをアンインストールすると、Web サイトが実行されている場合でも、アプリケーションの一部である Web サイトの仮想ディレクトリが削除されるためです。 Web サイトが別のビジネス ソリューションと共有されている場合、その結果、他のビジネス ソリューションは正しく機能しなくなります。
別のアプリケーションに共有ポリシーを展開する
1 つのポリシーが 2 つ以上のアプリケーションで使用されている場合は、あるアプリケーションから別のアプリケーションへの参照を作成するのではなく、別のアプリケーションに展開する必要があります。 これは、アプリケーションを停止すると、そのポリシーがデプロイ解除されるためです。 別のアプリケーションで使用されているポリシーを含むアプリケーションを停止した場合、ポリシーはどちらのアプリケーションでも機能しなくなります。
別のアプリケーションに共有証明書をデプロイする
証明書が 2 つ以上のアプリケーションで送信ポートまたは受信場所によって使用される場合は、証明書を別のアプリケーションに展開し、証明書を使用する必要があるアプリケーションからこのアプリケーションを参照する必要があります。 これは、BizTalk グループ内の 1 つの成果物のみが 1 つの LUID を持つ可能性があるため、2 つの異なるアプリケーションで同じ証明書をインポートできないためです。 それぞれが同じ証明書を使用する 2 つのアプリケーションをインポートしようとすると、最初のインポートは成功し、2 つ目は成功しません。 この場合、[インポートの上書き] オプションを使用しても、上書きする既存の証明書が別のアプリケーションに含まれているため、問題は解決しません。
BizTalk アプリケーションのエクスポートとインポート
大きな .msi ファイルを展開する場合は、BizTalk Server でアプリケーションを展開するために使用される COM+ コンポーネントの既定のトランザクション タイムアウトを増やす必要がある場合があります
非常に大きい (100 MB を超える) .msi ファイルを展開しようとすると、アプリケーションの展開中に BizTalk Server によって使用される COM+ コンポーネントの既定のトランザクション タイムアウト内にアプリケーションが展開されない可能性があります。 これらの COM+ コンポーネントに関連付けられているトランザクションがデプロイが完了する前にタイムアウトした場合、デプロイは失敗します。 非常に大きな .msi ファイルをデプロイする場合は、次のいずれかの方法を使用してこの問題を軽減することを検討してください。
1 つの大きな .msi ファイルではなく、複数の小さな .msi ファイルをデプロイします。
- コンポーネント サービス管理インターフェイスの Microsoft.BizTalk.ApplicationDeployment.Group および Microsoft.BizTalk.Deployment.DeployerComponent コンポーネントに関連付けられている既定のトランザクション タイムアウトを 3,000 秒増やします。 これらのコンポーネントは、それぞれ Microsoft.BizTalk.ApplicationDeployment.Engine および Microsoft.Biztalk.Deployment COM+ アプリケーションに属しています。 詳細については、「 トランザクションタイムアウトの設定」を参照してください。
バインドが上書きされないようにする
エクスポートするアプリケーション内のバインドで、.msi ファイルをインポートするアプリケーション内のバインドを上書きしたくない場合は、エクスポート操作中にエクスポートするリソースとしてバインド ファイルを選択しないでください。
.msi ファイルがセキュリティで保護されていることを確認する
.msi ファイルには機密データが含まれている場合があります。 ファイルがセキュリティで保護されていることを確認するための手順を必ず実行してください。 .msi ファイルのセキュリティの詳細については、「 セキュリティと Windows インストーラー」を参照してください。
バインド ファイルがセキュリティで保護されていることを確認する
バインド ファイルには機密データが含まれている場合があります。 ファイルがセキュリティで保護されていることを確認するための手順を必ず実行してください。
成果物に変更を加えるユーザーがいない場合にエクスポートをスケジュールする
ユーザーが成果物に変更を加える可能性が高くない時間帯にエクスポート操作をスケジュールします。 これは、エクスポート操作の進行中にユーザーがデータベース ベースの成果物、仮想ディレクトリ、証明書、またはポリシーを変更している場合、エクスポートされた .msi ファイルに変更が反映されないため、重要な場合があります。
BizTalk アプリケーションのインポート
.msi ファイルのインポートをスクリプト化する
BtsTask.exe を使用して、既存の BizTalk .msi ファイルのインポートをスクリプト化できます。 ファイルのインポート .msi スクリプトの詳細については、「 BizTalk アプリケーションの展開と管理」を参照してください。
注
ホワイト ペーパーは BizTalk Server にも適用されます。
事前処理または後処理スクリプトとして実行するスクリプトを追加できます。 ただし、スクリプトで実行されているコンテキスト (インポート、インストール、またはアンインストール) を決定し、それに応じて処理するために、環境変数を確認するロジックをスクリプトに含める必要があります。 前処理スクリプトと後処理スクリプトの使用の詳細については、「 前処理スクリプトと後処理スクリプトを使用してアプリケーションの展開をカスタマイズする」を参照してください。
参照される成果物の存在を確認する
インポートするアプリケーションが別のアプリケーションへの参照を持っている場合、BizTalk Server は参照先のアプリケーションが存在することを確認します。 ただし、アプリケーションに依存関係がある成果物が参照先アプリケーションに含まれていることは確認されません。 依存関係を持つアプリケーションを別のアプリケーションの成果物にインポートする場合は、参照先のアプリケーションに必要な成果物が含まれていることを確認することをお勧めします。
.msi ファイルからインポートすると、変更されたアセンブリをグローバル アセンブリ キャッシュに格納できなくなります
アプリケーション内の成果物を更新するには、変更または更新された成果物を .msi ファイルからアプリケーションにインポートします。 .msi ファイルを使用して成果物をインポートしない場合は、変更されたアセンブリをグローバル アセンブリ キャッシュに格納して、グループ内のすべてのサーバーを更新する必要があります。
サーバー全体のサブセットを更新する処理グループをホストする
アプリケーション内の成果物を更新する場合は、通常、BizTalk グループ内のすべてのサーバーを更新する必要があります。 ただし、ホスト処理グループを使用する場合は、グループ内の合計サーバーのサブセットのみを更新する必要があります。
インポート操作がタイムアウトした場合は、アプリケーションを追加の .msi ファイルに分割します
インポート操作は、期間が 3,600 秒を超えるとタイムアウトします。 .msi ファイルをインポートしようとして操作がタイムアウトした場合は、アプリケーションを再エクスポートし、エクスポートする成果物のサブセットを選択して、アプリケーションの内容を複数の .msi ファイルに分割する必要があります。 アプリケーションを .msi ファイルにエクスポートする方法の詳細については、「 BizTalk アプリケーションのエクスポート」を参照してください。