問題タブ [biztalk-2013]

分解するのに長い時間 (たとえば 1 時間) かかる、大きくて複雑なファイルがあります。メッセージが受信パイプラインを離れ、ファイルが終了する直前に旅程を開始するときに、メッセージをスピンオフできれば素晴らしいことです。簡単ではないことはわかりますが、まったく可能ですか？

最近BizTalk 2013 CU2ESBにアップグレードしてインストールしました。

を取得しないと展開できないため、これにはいくつかの副作用がありましたdatabase FK reference error。

これを前に見た人はいますか？

新しいアセンブリを DEV 環境にデプロイしようとすると、次のエラーが表示されます。

タイトル: BizTalk Server の管理

アプリケーションのリソースを更新できませんでした。

追加情報：

リソースを追加できませんでした。( mscorlib)

一部のリソースの変更リクエストが失敗しました。( Microsoft.BizTalk.ApplicationDeployment.Engine)

BizTalkAssemblyResourceManager は、終了タイプの変更要求を完了できませんでした。( Microsoft.BizTalk.ResourceManagers)

アセンブリの削除に失敗しました。削除しようとしているアセンブリ内のすべての項目が次の条件を満たしていることを確認してください。

1. パイプライン、マップ、およびスキーマが、同じまたは参照されているアプリケーションの送信ポートまたは受信場所で使用されていません。

2. ロールには参加しているパーティがありません。

データベースエラー：

DELETE ステートメントが REFERENCE 制約と矛盾しています bts_receiveport_transform_foreign_transformid。データベース "BizTalkMgmtDb"、テーブル "dbo.bts_receiveport_transform"、列 'uidTransformGUID' で競合が発生しました。DELETE ステートメントは、REFERENCE 制約 "fk_bt_mapspec_bts_item" と競合しました。データベース "BizTalkMgmtDb"、テーブル "dbo.bt_MapSpec"、列 'itemid' で競合が発生しました。DELETE ステートメントは、REFERENCE 制約 "bts_receiveport_transform_foreign_transformid" と競合しました。データベース "BizTalkMgmtDb"、テーブル "dbo.bts_receiveport_transform"、列 'uidTransformGUID' で競合が発生しました。ステートメントは終了されました。ステートメントは終了されました。ステートメントは終了されました。(mscorlib)

SQL トレースを実行したところ、これが table から削除しようとすると壊れる SP であることがわかりましたdbo.bt_MapSpec。

exec dpl_DeleteAssembly @Guid=N'00000000-0000-0000-0000-000000000000',@Name=N'theassemblynamegoeshere',@VersionMajor=1,@VersionMinor=0,@VersionBuild=0,@VersionRevision=0,@PublicKeyToken=N '89e32fae0caf808e',@Culture=N'neutral',@Type=N'2',@NoSchemasVerify=0

BizTalk 2013 でフラット ファイルを分解するためのスキーマを開発しています。しかし、解析結果がゴミなので、スキーマに大きな問題があります。解析しているフラット ファイルの種類は次のようになります。

フラット ファイルには、次の 3 つの階層部分があります。

トップレベル: ' で区切られたセグメント(改行ではなく、読みやすくするために追加されたものです)

中間レベル: + 文字で区切られたフィールド。値または値のグループを直接含むことができます (下のレベルを参照)

最下層:属性: 文字で区切られる

TAG以来？-セグメントは部分的にオプションであり、複数の順序で発生する可能性があります。私は parser_optimization="complexity" オプションを lookahead_depth="0" と共に使用しており、TAG を使用していますか? -セグメントの種類を識別するための名前。すべてを解析するために使用しています。child_order="postfix" であるセグメントを除いて、すべての区切り文字は child_order="infix" です。

一部のセグメント、フィールド、および属性は必須ですが、ほとんどは必須ではありません。ただし、最初のフィールドとその属性 (タグ名など) は常に必須です。セグメントの分離と識別は正常に機能し、フィールドも正しく機能しています。ただし、オプション属性のグループを含むオプション フィールドがある場合、スキーマが正しく解析されません。例: 構文:

全部？属性はオプションです

次のようにセグメントを解析している間、属性値は正しい XML フィールドに入れられています。

ただし、フラット ファイルの仕様ではオプションのフィールドを省略できるため、メッセージは次のようになります。

この場合、値は本来あるべき 2 番目と 3 番目の XML フィールドに入れられず、3 番目と 4 番目に入れられます。セグメントに含める : 記号の量に応じて、1 番目と 6 番目、または 2 番目と 4 番目の XML フィールドも埋められる場合があります。

現在使用している混沌とした方法ではなく、これらのフィールドを左から右に入力するには、フラット ファイル パーサーが必要です。ただし、parser_optimization="speed" への切り替えはオプションではありません。これは、スキーマの残りの部分が複雑すぎるためです (ローカルで行う方法がない限り)。

これらは、そのようなフィールドの解析に使用されている XSD スキーマの一部です (スキーマが非常に大きいため、抽出された部分のみ)

共通部分の定義 (スキーマ自体に含まれ、他のスキーマでも使用されています。この例では、4 つの部分からなる属性グループです):

特定のスキーマの抜粋:

タイトルが示すように、BRE リゾルバーを使用する場合、本当にポリシー バージョンを指定する必要がありますか?

BRE を使用するアイデアの一部は、BRE でポリシーを変更することにした場合 (新しいポリシー バージョンにつながる)、展開されたソリューション (旅程を含む) を変更する必要がないことだと思いました。

ご入力いただきありがとうございます。

ベスト プラクティスに従って、成果物 (スキーマ、パイプライン、マップなど) に基づいて BizTalk ソリューションをプロジェクトに分割しました。また、ビジネス プロセスをソリューション フォルダーに分けました。それぞれに利用可能にする必要があるスキーマを保持するための共通プロジェクトを作成し、必要に応じてこれらを参照しました...これまでのところ良いです。

展開すると、共通のスキーマと各参照が展開され、複数のスキーマが生成されます。プロジェクト アセンブリで依存関係のチェックを外そうとすると、エラーが発生します。

この依存関係はプロジェクトによって追加されたものであり、削除することはできません。

何か不足していますか？

Visual Studio 2012、BizTalk Server Dev Ed 2013。