BizTalk: абонаменти за отговор на множество заявки

Имаме съхранена процедура, която регистрира състоянието в нашата база данни. За съществуващо приложение потребителите решиха, че искат да напишат състоянието на различен сървър.

  • Дублирахме таблицата и съхранената процедура на новия сървър
  • Създадох нов порт за изпращане по избор на wcf и го конфигурирах да използва новата база данни.
  • Промених обвързването на оркестрацията, за да използвам новия порт за изпращане.

Сега получавам следната грешка:

The message found multiple request response subscriptions. A message can only be routed to a single request response subscription.

Вярвам, че въпреки че обвързването на оркестрацията указва кой порт да се използва, BizTalk също намира старата дефиниция на порт за изпращане.

Как работи подвързването на оркестрацията? Някакви идеи защо е объркан?

(Оригиналния порт за изпращане се използва от други приложения, така че не мога да го премахна или редактирам)


biztalk wcf
person Jay    schedule 08.01.2014    source източник

Отговори (3)


arrow_upward
1
arrow_downward

Когато обвържете оркестрация към порт, всяко съобщение за този порт, публикувано от оркестрацията, ще има свойството на контекста на SPTransportID, зададено на GUID на порта. Когато добавите филтър към порт, той го добавя като ИЛИ. Можете да видите това, като отидете на Нова заявка, Търсене на абонаменти и намерите въпросния порт. Например ще видите такъв абонамент

http: //schemas.microsoft.com/BizTalk/2003/system-properties.SPTransportID == {E1293B10-2763-4600-B795-A0C4B4D5E6EC} 
   Or 
http: //schemas.microsoft.com/BizTalk/2003/system-properties.ReceivePortName == ExamplePort

Така че, за да разрешите този проблем, ще трябва или да актуализирате филтъра на стария порт, така че да изключва съобщенията от оркестрацията, която пренасочвате. Или ако другото, ако другите оркестрации на приложения са обвързани със стария порт, можете просто да премахнете филтъра и той трябва да работи.

person Dijkgraaf    schedule 08.01.2014
comment
Благодаря за чудесното обяснение. Ще го тествам след малко. - person Jay; 09.01.2014
comment
Еха. Не очаквах такова поведение. Благодаря много - person Jay; 10.01.2014

arrow_upward
1
arrow_downward

Изглежда, че или старият порт все още е включен (може просто да е спрян), или евентуално трябва да рестартирате вашите BizTalk хостове.

person StuartLC    schedule 08.01.2014
comment
Старият порт все още е необходим за други приложения на BizTalk. Все пак ще опитам да рестартирам хостовете. Добра идея - person Jay; 08.01.2014
comment
Това може да е проблем - според грешката съобщение request response не може да има абонаменти за множество портове, тъй като в противен случай задействащите орки могат потенциално да получат повече от един отговор, вероятно в конфликт. Можете ли да направите абонаментите на 2-та порта взаимно изключващи се, напр. с филтри за контекстни свойства? - person StuartLC; 08.01.2014
comment
Съгласен съм. Така че защо два различни порта, единият от които не е обвързан с тази оркестрация, се броят за възможни абонати? Какви критерии използва, за да реши кой порт да се използва? Трябва да е нещо освен обвързването. - person Jay; 08.01.2014
comment
Вероятно сте използвали директно обвързване на поне един от тях, като филтърът е базиран само на message type? - person StuartLC; 08.01.2014
comment
Той има критерии за филтриране на типа съобщение. Това не е директно свързан порт към кутия за съобщения. Рестартирах инстанциите на хоста и ще изпълним отново заданието. Чудя се дали е създал новия порт за изпращане, но тъй като не отхвърлих копията, той все още съдържа препратка към другия. - person Jay; 08.01.2014
comment

Вашият клас е дефиниран в основното пространство от имена, трябва да добавите \ преди името на класа. В противен случай php ще мисли, че е в същото пространство от имена като текущия клас, в момента App\Http\Controllers.

Трябва да направите нещо подобно:

$id3 = new \getID3;
- person Jay; 08.01.2014
comment
Не е съвсем очевидно какво да направя, за да поправя проблема, така че просто ще го заобиколя. Ще пренапиша едното приложение, така че да няма шанс за припокриване. - person Jay; 09.01.2014
comment
Защо имате критерии за филтър за типа на съобщението, когато сте обвързали Оркестрацията към порта? Това, което направихте, като добавихте този филтър, както съобщенията, свързани с порта, така и всички други съобщения, публикувани с този тип съобщение, също ще отидат до този порт. Ако другите оркестрации на приложения са обвързани с порта, тогава премахнете филтъра и нещата ще работят. В противен случай ще трябва да актуализирате филтъра, така че да изключи онези съобщения, които трябва да отиват към новия порт. - person Dijkgraaf; 09.01.2014

arrow_upward
0
arrow_downward

За да постигнете това, което описвате, не е необходимо да създавате нов порт за изпращане.

Просто променете URI на съществуващия порт за изпращане, за да сочи към новата база данни.

person Johns-305    schedule 08.01.2014
comment
Старият порт все още е необходим за други приложения на BizTalk - person Jay; 08.01.2014