0

約 6 つのシステム (すべて内部システム) があり、それらの間でデータを送信する必要があります。現在、これを行う一貫した方法はありません。SSIS、SQL Server リンク サーバーを使用してデータベースを直接更新し、ODBC 接続を使用してデータベースやテキスト ファイルなどを直接更新します。

私たちの目標は次のとおりです。

1) アプリケーションを接続する一貫した方法を用意します。
2) アプリケーション間の接続を監視および記録する中心的な方法を用意します。
3) Web サービスを提供するアプリケーションについては、データベースに直接接続するのではなく、それらの使用を開始したいと考えています。

使用するものは何でも、Web サービス、データベース、フラット ファイルに接続できる必要があり、TCP 接続を介してデータを受け入れることもできる必要があります。

Biztalk はこれに適したソリューションですか、それともやり過ぎですか?

4

3 に答える 3

2

それは本当に依存します。あなたが説明しているアーキテクチャの場合、それはぴったりのようです。ただし、biztalk が統合しようとしているシステムと通信できるかどうかを検証する必要があります。例えば; これらのシステムが Web サービス、メッセージ キュー、またはファイル ベースの通信を使用する場合、それが適している可能性があります。

Biztalk を使い始めるときは、ハードウェア、ソフトウェア、そして何よりもその使用法を学ぶことに進んで投資する必要があります。

あなたのポイントに関して：1）はい、システムコネクタを正しくカプセル化することを確認した場合2）はい、biztalkはBAMでこれをサポートします3）はい、それは完全に一致します

于 2012-08-23T21:15:28.460 に答える
1

あなたが説明したこと（6つのシステム）から、ポイントツーポイント/直接統合アプローチでは多数の新しいシステムが追加されるたびに順列/スパゲッティ。

BizTalk は、ハブ アンド スポークとバス タイプのトポロジ (ESB ツールキットを使用) の両方をサポートしており、どちらもシステム間の相互接続の数を減らします。

oɔɯǝɹ に追加するには:

  1. はい。最終的に、BizTalk はすべてを内部で XML に変換します。ビジュアル マップまたは xslt を使用して、メッセージの種類を変換します。
  2. はい。すぐに使用できる多くの WMI および Perfmon カウンターがあり、BizTalk には BizTalk の正常性を監視するための SCOM 管理パックがあります。アプリの場合、BAM (単純な監視には TPE を使用しますが、BAM API を使用するとより高度な処理を行うことができます)。
  3. はい - BizTalk は、すべての一般的な WCF バインディング タイプと基本的な SOAP Web サービスをサポートしています。BizTalk のメッセージ ボックスは、後の段階で他のプロセスをメッセージに「フック」できるパブ/サブ エンジンとして使用できます。

いくつかの注意事項:

. BizTalk は、メッセージ (組織全体の電子ドキュメントなど) には使用する必要がありますが、大量のデータの同期には使用しないでください。SSIS は、非常に大きなデータ転送/データ移行/データ同期パターンに適しています。

. David が指摘するように、BizTalk の学習曲線は急勾配であり、ツール自体は無料ではありません (SQL と BizTalk のライセンスが必要で、通常は SCOM などの監視ツールも使用する必要があります)。これを迅速に追跡するには、BizTalk トレーニングで開発者を派遣するか、BizTalk コンサルタントを連れてくる必要があります。

. Microsoft はAzure Service Busに注力しているようで、BizTalk が将来的に Azure Service Bus に統合されるという憶測があります。エンタープライズ戦略が完全に Microsoft ではない場合は、ESB 用のNServiceBus やFUSEなどの製品を検討することもできます。

于 2012-08-24T05:07:14.433 に答える
1

あなたの問題は典型的な企業の問題です。企業は、人事、Web、サプライ チェーン、在庫管理、クライアント管理などの独立したアプリケーションの構築を何年にもわたって開始し、これらのアプリケーションが単独では機能せず、互いに対話する必要があるポイントに到達すると、通常、ハッキングされたソリューションを開始します。データベース レベルでのデータ移行のようなものです。

しかしすぐに、彼らは明確な可視性の欠如、貧弱な管理、基準の欠如などの問題に気づき、本当のスパゲッティを作成します. 最大の脅威は、アプリケーションが相互に依存するようになり、何かを変更する機敏性を失うことです。システムへの変更には、厳しいテストと長いリリース サイクルが必要です。

これは、BizTalk Server のようなミドルウェア プラットフォームが解決する種類の問題です。スレッド内の多くの返信は、BizTalk サーバーのコストに焦点を当てています (記載されているコストの一部は正確ではありません)。安価な製品ではありませんが、すべてのアプリケーションを接続する中央ミドルウェア プラットフォームとして組織内で果たす役割と、ほとんどのサード パーティ製品へのアダプターのように箱から出してすぐに得られる非機能的な利点の数を見ると、 SAP、Oracle、FTP、FILE、Web サービスなど、プラットフォームを簡単にスケーリングする機能、パフォーマンス、長時間実行されるワークフロー、耐久性、長時間実行されるワークフローの補正ロジック、環境の調整など、すぐにコスト要因が減少します。

私のお勧めは、BizTalk を見てみることです。初めての場合は、ローカルの Microsoft オフィスに相談してください。彼らは、あなたの状況を分析しに来てくれるパートナーを助けるか、推薦することができます.

于 2012-08-26T15:03:00.813 に答える