1

受信場所での奇妙な動作:

RL_REPRESENTATIVEは REPRESENTATIVE テーブルからの通知を待っています (フィールド: (PK)id、fname、lname など)。

RL_CLIENT_REPRESENTATIVEは、CLIENT_REPRESENTATIVE テーブル (フィールド: (FK)id_rep、(FK)id_client) からの通知を待っています。

両方の場所がアクティブで、 CLIENT_REPRESENTATIVE.id_rep テーブルの変更をコミットすると、いくつかの警告が表示されます (明らかにRL_REPRESENTATIVEから)。

The adapter "WCF OracleDB" raised an error message. Details "System.InvalidOperationException: The notification query returned an error. Info="Error". Source="Data". Type="Change".
   at Microsoft.Adapters.OracleDB.OracleDBInboundContract.Notification_TryReceive(OracleCommonExecutionHelper executionHelper, Message& wcfMessage)
   at Microsoft.Adapters.OracleDB.OracleDBInboundContract.TryReceive(TimeSpan timeout, Message& message, IInboundReply& reply)
   at Microsoft.ServiceModel.Channels.Common.Channels.AdapterInputChannel.TryReceive(TimeSpan timeout, Message& message)
   at System.ServiceModel.Dispatcher.InputChannelBinder.TryReceive(TimeSpan timeout, RequestContext& requestContext)
   at System.ServiceModel.Dispatcher.ErrorHandlingReceiver.TryReceive(TimeSpan timeout, RequestContext& requestContext)".

と

The adapter "WCF OracleDB" raised an error message. Details "The WCF service host at address oracledb://d01-isis:1521/D01ISIS/Dedicated?CallingTable=REPRESENTATIVE has faulted and as a result no more messages can be received on the corresponding receive location. To fix the issue, BizTalk Server will automatically attempt to restart the service host.".

それ以外の場合、CLIENT_REPRESENTATIVE の変更によってアクティブ化されるプロセスは問題なく実行されます。

(代わりに、CLIENT_REPRESENTATIVE の id_client を更新すると、CLIENT テーブルからの通知をサブスクライブする別の受信場所からエラーが発生します。)

さらに2つの手がかり:

  • RL_REPRESENTATIVEを無効にすると、警告は表示されません。

  • CLIENT_REPRESENTATIVE.id_rep と REPRESENTATIVE.fname の両方を更新し、同じトランザクションで両方をコミットすると、警告は表示されません。

どちらのテーブルにもトリガーがなく、すべてのタイムアウトがほぼ 24 時間に設定されていることに注意してください。

FK 制約は、最終的にポートに通知を送信する方法で機能すると思われますが、受信するはずの実際のメッセージを取得することはありません。

質問: Oracle には、この動作を制御するパラメーターはありますか? この問題に遭遇した Biztalk 開発者はいますか?

4

2 に答える 2

0

結局、解決策は、すべての受信場所 (NotifyOnListenerStart) のフラグを「false」に変更することでした。

さらなる開発の後、この解決策は完全ではありませんでした。誤ったトリガーが再び発生しています。そのため、私 (または他の誰か) が正しい解決策を見つけるまで、チェックをオフに切り替えます。

編集: これは FK の副作用です。その値を変更すると、PK を含むテーブルの変更の通知がトリガーされるようです (何もないにもかかわらず)。

于 2012-01-12T16:19:26.133 に答える
0

かもしれない：

  • 物事が保存される順序。
  • トランザクションの問題、別のトランザクションで場所を受け取るため、関連するアイテムが欠落しているように見えます
  • トランザクションの問題に関連するロックの問題

それを追跡する方法は、データベースでプロファイリングをセットアップし、どのコマンドがどの順序で送信されているかを正確に確認することです。

于 2011-11-21T21:54:48.783 に答える