Проблема гидратации/регидратации оркестровки BizTalk

У меня есть настраиваемый конвейер приема, который разбивает большой файл на отдельные файлы и отправляет их в окно сообщений, а оркестровка подписывается на эти сообщения и обрабатывает их. В моей оркестровке у меня есть несколько форм выражений, которые выполняют методы в .net dll. Я также добавил ведение журнала на каждом этапе. В любой момент окно сообщения может быть заполнено сотнями сообщений. Я заметил, что некоторые сообщения выполняются несколько раз. Я дважды проверил, чтобы убедиться, что я не генерирую несколько одинаковых сообщений. Это наводит меня на мысль, что, возможно, это как-то связано с увлажнением. Из того, что я исследовал, когда оркестровка гидратирована, она сохранится в той форме, в которой она была, а также в состоянии dll. Когда он возобновится, он возобновится в своей сохраненной форме, а не начнется с самого начала.

Кто-нибудь видел эту проблему? Какие тесты/конфигурации я могу сделать, чтобы проверить/исправить эту проблему?!

Вот часть оркестровки

Вот метод .net, который вызывает каждая фигура Expression

Большое спасибо!

Энджи


.net biztalk orchestration
person Angela    schedule 09.11.2011    source источник
comment
Вы пытались использовать атомный прицел?   -  person javros    schedule 09.11.2011
comment
Пожалуйста, опубликуйте скриншот оркестровки дизассемблера, а также образцы кода в библиотеке .net, которую вы вызываете.   -  person tom redfern    schedule 09.11.2011
comment
Да, гидратация просто позволяет BizTalk сериализовать текущее состояние незанятых оркестровок (например, ожидание коррелированных сообщений, ожидание таймеров и т. д.), чтобы ресурсы можно было перераспределить для более срочных задач. Вы используете прямую привязку к мессенджеру? Может где-то есть обратная связь?   -  person StuartLC    schedule 09.11.2011
comment
nonnb, да, я использую прямую привязку из окна сообщений на основе свойства типа сообщения, которое я продвигал в своем пользовательском полученном конвейере. Я попробую фиктивную оркестровку, чтобы получить сообщение и написать его, чтобы увидеть, не дублируется ли сообщение.   -  person Angela    schedule 09.11.2011
comment
Евгений.. Пробовал атомарный и длинноходный прицел, результат тот же.   -  person Angela    schedule 09.11.2011
comment
Хью, я загрузил изображение оркестровки и некоторые методы .net. Спасибо за вашу помощь.   -  person Angela    schedule 09.11.2011
comment
Использование предложения Евгения (атомарная область) должно полностью предотвратить гидратацию, а это означает, что дублирование сообщений не происходит из-за этого. Если вы публикуете сообщения с той же схемой, что и получаете, вы можете вызвать обратную связь. Попробуйте отфильтровать входящее сообщение (например, в BTSOperation или в каком-либо конкретном свойстве адаптера).   -  person StuartLC    schedule 10.11.2011
comment
я не думаю, что это гидратация, потому что я следил за монитором производительности, и он показал, что оркестрация вообще не гидратирована. Так что же может заставить оркестровку вернуться к оркестровке и начать все заново? Могу ли я использовать какую-либо фильтрацию? Сообщение изначально исходило из пользовательского конвейера.   -  person Angela    schedule 11.11.2011

Ответы (3)


arrow_upward
1
arrow_downward

Я думаю, вы путаете гидратацию с точками устойчивости. Буквы в сочетании с некоторой логикой try\catch могут привести к перезапуску с последней точки сохранения. Вы не выложили полную картину своих оркестровок, но я вижу там размах. У вас там есть обработка исключений?

В любом случае оркестрация не может публиковать какие-либо сообщения в окне сообщений без явной формы отправки. Также проверьте, установлены ли у вас последние SP и накопительные обновления.

person Dmitry Golubets    schedule 16.11.2011

arrow_upward
0
arrow_downward

Интересная проблема :)

Гидратация и регидратация происходят, когда оркестровка бездействует, ожидая чего-то. Следовательно, это не должно происходить в процессе обработки файла.

  • Чтобы убедиться, что это не проблема качества данных, убедитесь, что во входных файлах нет повторяющихся данных.
  • Вы можете использовать функции регулирования, чтобы обеспечить обработку только одного файла за раз. Это устранит один потенциальный источник ошибки.
  • Еще одна вещь, которую вы могли бы сделать, это проверить обработку ошибок, есть ли у вас какая-либо логика повторных попыток, когда первый вызов терпит неудачу? Если Biztalk также выполняет повторную попытку, это может объяснить дублирование.
person Shiraz Bhaiji    schedule 13.11.2011
comment
Думаю дело не в гидратации/регидратации. Проблема может быть в прямой привязке из окна сообщений. По какой-то причине оркестровка возвращает сообщение в окно сообщений, и оно снова выполняется с самого начала. Я попытался создать новое сообщение и изменить продвигаемое свойство для нового сообщения, но проблема осталась прежней. Я не уверен, если по какой-то причине оркестровка отбрасывает сообщение обратно в MessageBox, какое сообщение она отбрасывает? оригинал или новый? - person Angela; 15.11.2011

arrow_upward
0
arrow_downward

Я бы предложил в таком случае продвигать 2 новых настраиваемых свойства на этапе конвейера для каждого нового сообщения, которое вы создаете -

1) Общее количество сообщений 2) Номер текущего сообщения

Таким образом, вы можете отслеживать, распечатывать или сохранять каждый номер сообщения в начале оркестровки или на любом другом этапе, который вы выберете, и это может упростить работу.

person Shay Feldman    schedule 22.11.2011
comment
когда сообщение каким-то образом возвращается в окно сообщения, имеет ли оно тот же номер сообщения? - person Angela; 23.11.2011
comment
Если это тот же экземпляр сообщения, то да. А даже если нет, то когда вы попытаетесь напечатать номер сообщения в оркестровке, вы увидите, что у него нет номера сообщения, и тогда это означает, что это клон и точно не пришло из пайплайна и это тоже может вам помочь с расследованиями. Я бы также предложил использовать счетчики производительности, чтобы убедиться, что ваша система не переходит в состояние регулирования, и если это произойдет, проверьте, что вы можете сделать, чтобы позволить системе работать с достаточным количеством ресурсов и избежать этого состояния. - person Shay Feldman; 24.11.2011