2

BizTalkプロジェクトを開始するとき、私は通常、ここにある命名規則に従います。プロジェクトとアセンブリに名前を付ける場所は次のとおりです。

MyCompany.MyProject.Orchestrations.dll
MyCompany.MyProject.Schemas.dll
MyCompany.MyProject.Pipelines.dll
MyCompany.MyProject.Transforms.dll
MyCompany.MyProject.PipelineComponents.dll

他のBizTalkの人々へのいくつかの質問：

1）私は通常、スキーマを含む複数のプロジェクトがあるか、スキーマを分離する必要があることに気付きます。それらを別々のアセンブリに貼り付けますか？はいの場合、プロジェクト/アセンブリに名前を付けるためにどのような規則に従いますか？いいえの場合、それらを1つのアセンブリのサブフォルダーに貼り付けますか。

2）間違っているかもしれませんが、上記のように、プロジェクトとアセンブリに同じ名前を付けるのは一種のBizTalk規則でした。プロジェクトに完全なアセンブリ名と同じ名前を付けることをやめようと思ったので、Mapsという名前のプロジェクトがあり、そのアセンブリの名前はMyCompany.MyProject.Mapsです。他の人はこれをしますか？

4

2 に答える 2

4

BTS 2009以降、プロジェクトとアセンブリに、それらが属するアプリケーションと、オプションのサブアプリケーションまたは懸念範囲に応じて名前を付けました。

MyCompany.Biz.MyFirstApp.dll
MyCompany.Biz.MyFirstApp.Util.dll
MyCompany.Biz.MyFirstApp.ConcernOne.dll
MyCompany.Biz.MySecondApp.dll

マルチアセンブリの依存関係によりデプロイメントが非常に面倒になる可能性があるため、オーケストレーション、スキーマ、およびマップを一緒に維持するための道を歩みました。

私たちの主な目標は、ソースシステムとターゲットシステムを分離して、直接の参照を回避することでした。これは、私たちが扱っているすべての懸念事項に「コア」コンポーネントを導入することで達成されました。

BTSアプリケーションMyFirstApp

MyCompany.Biz.MyFirstApp.OrderProcessing.dll
MyCompany.Biz.MyFirstApp.Util.dll

BTSアプリケーションCORE

MyCompany.Biz.CORE.OrderProcessing.dll

BTSアプリケーションMySecondApp

MyCompany.Biz.MySecondApp.OrderProcessing.dll

との両方MyFirstAppで、MySecondAppのスキーマを参照しCORE.OrderProcessingます。

アップデート

MyCompany.Biz.MyFirstApp.OrderProcessingには、受信注文ドキュメントのメッセージスキーマと、それらをコア注文メッセージスキーマ（ MyCompany.Biz.CORE.OrderProcessingに含まれている）にマッピングするためのマップが含まれます。必要に応じて、メッセージを受信するためのオーケストレーションと（受信する）パイプラインコンポーネントを含めることもできます（たとえば、フラットファイルを処理する場合）。

MyCompany.Biz.MySecondApp.OrderProcessingには、送信ドキュメントのメッセージスキーマと、コア注文メッセージスキーマから（送信へ）マッピングするためのマップが含まれます。

この基本的なレイアウトでは、COREは内部メッセージスキーマのコンテナにすぎませんが、注文ドキュメントに情報を追加するのに最適な場所です。たとえば、クラスAの顧客にグローバル割引を提供するオーケストレーション（ビジネスルール！）です。要するに、基本的に、メッセージを送受信するときに2回またはそれ以上実行するステップであり、着信または発信メッセージスキーマが変更されたり、新しいアプリケーションが追加されたりした場合に触れたくないものです。

于 2010-11-12T10:10:43.163 に答える
3

これは、 ScottColestockによるすばらしいBizTalk命名規則ガイドです。

于 2010-11-25T14:35:24.273 に答える