|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Привествую всех! Вопрос по очередям Service Broker. Для очереди был определен специальный тип сообщений с контролем по XSD: Код: sql 1.
Однако данная очередь без проблем "жрет" пустые сообщения (пустая строка) и при этом говорит, что сообщение валидно. При этом прямая конвертация тела сообщения в процедуре активации завершается ошибкой: Код: sql 1.
В чем прикол? Какие еще нюансы есть при использовании VALID_XML WITH SCHEMA COLLECTION ? Допонительный вопрос - как через MSSMS удалять конкретные сообщения из очереди? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 12:24 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Tketano, коллекцию схем в студию ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 12:58 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
а сорян невнимательно прочитал вопрос. Да есть такой нюанс, пустой xml не запускает валидацию по схеме у вас даже инструкция вида Код: sql 1.
должна нормально отработать. точнее смотрите как: валидации есть два вида content и document вот в случае declare @x xml(xsd_doc) = ''; используется content validation которая разрешает пустой элемент declare @x xml(document xsd_doc) = ''; используется document validation которая проверяет что бы в теле был именно валидный документ. в случае валидации service broker используется content validation ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 13:11 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
felix_ff, При использовании типизированного xml такого поведения не замечал. Конструкция вида Код: sql 1.
возвращает ошибку "Проверка XML: экземпляр XML должен быть документом". Но я кажись понял в чем проблема... в типизированном xml указан DOCUMENT, т.е.ровно 1 элемент верхнего уровня. А при создании типа сообщения указать данных флаг возможности нет. В этом случае пустая строка естественно валидна. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 13:22 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
felix_ff, Ага, спасибо, тоже допер. Важный нюанс. Получается может прилететь много сообщений в одном при такой валидации. Может тогда откажусь от XSD в пользу well formed xml )) Все равно потом типизируется документ. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 13:26 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Tketano, вы лучше вообще откажитесь от валидации типа, пусть будет разрешена validation = none. а валидацию будуте производить непосредственно перед отправкой на инициаторе или после получения на таргете сами. использование validation отличной от none - несколько нагружает очередь, при больших объемах сообщений это становится заметно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 13:29 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
felix_ff, Сейчас подумаю над типизацией сообщений, хорошо. Дополнительный вопрос. Что за особенное поведение у очереди, если в нее подпадает сообщение с телом NULL? Ошибка при отправке естесвенно появляется, однако сообщение в очереди так же оказывается. И далее сваливается процедура активации (где вроде бы есть попытка отловить этот NULL). ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 13:46 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Tketano, это в какой это ситуации у вас разрешается тело null? оно может быть быть только в двух случаях: 1)тело сообщения обязано быть null если validation на message_type = EMPTY; 2) тело сообщения может быть null если при инструкции send не указывать содержимое аля Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 14:10 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
felix_ff, В том то и дело, что null не разрешено. Тестирую очередь на сбои. При попытке вставить null выдается сообщение "Тело сообщения не может быть равно NULL. Допустимо использование имеющей нулевую длину строки в Юникоде или двоичной строки". Однако само сообщение попадает в очередь с пустым телом ('') и после этого очередь сваливается. После того, как включил VALIDATION = NONE проблема вроде ушла. Ну понятно почему. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 14:28 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Tketano, если валидацию выполнять на принимающей стороне, то контроль ошибок становится проще. WITH SCHEMA COLLECTION XSD_DOC используют, если принимающая сторона нам недоступна, то есть мы должны гарантировать внешней системе, что передали то, что они хотят. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 14:36 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Владислав Колосов, Ну контролировать мне все равно где. Хотел облегчить себе жизнь, а как будто усложнил. Моя задача сейчас сделать очередь максимально отказоустойчивой. Положили в нее левое сообщение - ну ок, сформируем ответ, что валидацию не прошло. Главное чтобы очередь не останавливалась. На VALID_XML WITH SCHEMA часто выключается при попытке отправить кривое сообщение. В данном случае я - принимающая сторона, а внешние системы в этот сервис отправляют запросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2020, 15:04 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Tketano, Убрал валидацию по умолчанию. Решилась одна проблема, появилась новая. Процедура активации стандартная, предлагаемая BOL: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46.
Валидация схемой внутри dbo.DO_SOMETHING происходит следующим кодом: Код: sql 1. 2. 3. 4. 5.
Валидация происходит корректно. Однако исключение рушит внешнюю транзакцию из процедура активации и команда COMMIT TRAN выполняется с ошибкой (нельзя зафиксировать транзакцию). Пробовал добавить анализ XACT_STATE() ( если = -1, то откат). Но тогда под откат попадает и контрукция SEND ON CONVERSATION. В общем блуждаю в трех соснах. Если убрать все транзакции в процедуре активации, то работать начинает. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2020, 17:59 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Tketano, сообщение Код: sql 1.
специально не надо отправлять, его отсылает команда Код: sql 1.
Забираете из очереди, если это шпионское сообщение, то машете в ответ рукой и закрываете диалог. Если прилетела с той стороны ошибка и ее нет интереса обрабатывать, то тоже машете рукой. Свои сообщения обрабатываете. Передающая сторона вам ошибку врят ли пришлёт. А вот это: BEGIN TRANSACTION; приедет к интересному результату. Если в процессе валидации будет выброшено исключение, то транзакция откатится и сообщение останется в очереди. После пятого отката очередь остановится в случае включения параметра обработки отравленных/токсичных сообщений. Причем, неважно на каком уровне стека выполнения процедур произойдет откат. Даже если это откат, обработанный через try-catch. Чтобы ловить ошибки и не повторять проверку одного и того же сообщения, "отравленное" сообщение после отката необходимо извлекать из очереди или отказаться от использования транзакции. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2020, 19:17 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Владислав Колосов, Владислав Колосовсообщение N'http://schemas.microsoft.com/SQL/ServiceBroker/EndDialog' специально не надо отправлять, его отсылает команда END CONVERSATION @CONVERSATION_HANDLE; Я, честно говоря, таких сообщений в очереди не видел и теоретически не понимаю откуда оно может там взяться. Как и писал выше, использовал шаблон обработки microsoft по умолчанию, где обрабатывается Error и EndDialog в явном виде. Владислав КолосовА вот это: BEGIN TRANSACTION; приедет к интересному результату. Если в процессе валидации будет выброшено исключение, то транзакция откатится и сообщение останется в очереди. После пятого отката очередь остановится в случае включения параметра обработки отравленных/токсичных сообщений. Причем, неважно на каком уровне стека выполнения процедур произойдет откат. Даже если это откат, обработанный через try-catch. Да, все именно так и происходит по логу. Сообщение неудовлетворяющее XSD схеме является в данном коде токсичным и после 5-ти попыток его обработки очередь просто отключается и весь сервис падает. Владислав КолосовЧтобы ловить ошибки и не повторять проверку одного и того же сообщения, "отравленное" сообщение после отката необходимо извлекать из очереди или отказаться от использования транзакции. Вот тут самое непонятное. Почему не отрабатывается примерно следующий код? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
После данного кода сообщение не удаляется из очереди, хотя мы в явном виде вызвали ROLLBACK и только после этого вызвали конструкцию SEND ON CONVERSATION. Неужели надо повторно выбирать данное сообщение из очереди (RECEIVE)? А какие опасности отказа от транзакции в активирующей процедуре? Без нее есть риск при некорректной обработке сообщения (или сбоя) потерять сообщение в принципе? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2020, 20:18 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Tketano, в do_something отключите xact_abort, что бы у вас транзакция не принимала uncommitable state Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2020, 22:16 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
felix_ff, Попробовал. Транзакция все равно сваливается в нефиксируемое состояние. Пробовал следующим примером: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
Как итог стандартная ошибка: Код: sql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2020, 11:27 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Tketano, Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2020, 11:31 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Tketano, авторЯ, честно говоря, таких сообщений в очереди не видел и теоретически не понимаю откуда оно может там взяться. Моя вина, невнимательно посмотрел. Показалось, что сообщение отправляется в очередь. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2020, 12:40 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Tketano, а да, согласен ошибка проверке по схеме вызывает исключение которое приводит к откату транзакции и в случае с xact_abort off к нефиксируемуму состоянию. ну тогда здесь как вариант решения использовать "автономную транзакцию" через петлю линкованного сервера. то есть валидацию проводите в виде процедуры Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20.
и типа валидацию производить вида Код: sql 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2020, 02:39 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Владислав Колосов, felix_ff Спасибо! Был занят переделкой лога и изменением валидации сообщений в очереди. Новый вопрос. Почему conversation_handle после инструкции BEGIN DIALOG не совпадает со значением conversation_handle в очереди? В чем прикол? При том, что значения крайне похоже и, судя по всему, отличаются всего на тройку байт: Код: sql 1. 2. 3. 4. 5.
Задача после BEGIN DIALOG записать в лог присвоенный conversation_handle (для отладки сообщений очереди). ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2020, 18:40 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Tketano, вы не учитываете тот факт что у вас conversation_handle от инструкции begin dialog conversation это хэндл отправляющей стороны а в очереди лежит хэндл принимающей стороны . если посмотрите в sys.conversation_endpoints вот так то поймете: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2020, 19:17 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
felix_ff, Так, так, так... ну приехали)) Еще один сюрприз) После инструкции BEGIN DIALOG можно узнать CH принимающего сервиса? Необходимо зафиксировать его в логе, чтобы в случае сваливания принимающей очереди разобраться что с чем связано. Судя по всему в sys.conversation_endpoints для обоих сообщений одниковый conversation_id... Возможно, это странный подход, не отрицаю) ... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2020, 21:10 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Tketano felix_ff, Так, так, так... ну приехали)) Еще один сюрприз) После инструкции BEGIN DIALOG можно узнать CH принимающего сервиса? Необходимо зафиксировать его в логе, чтобы в случае сваливания принимающей очереди разобраться что с чем связано. Судя по всему в sys.conversation_endpoints для обоих сообщений одниковый conversation_id... Возможно, это странный подход, не отрицаю) Ну типа такого варианта (не уверен в нем): Код: sql 1. 2. 3. 4.
... |
|||
:
Нравится:
Не нравится:
|
|||
09.09.2020, 22:33 |
|
Service Broker, MESSAGE TYPE VALIDATION через XSD
|
|||
---|---|---|---|
#18+
Tketano Tketano felix_ff, Так, так, так... ну приехали)) Еще один сюрприз) После инструкции BEGIN DIALOG можно узнать CH принимающего сервиса? Необходимо зафиксировать его в логе, чтобы в случае сваливания принимающей очереди разобраться что с чем связано. Судя по всему в sys.conversation_endpoints для обоих сообщений одниковый conversation_id... Возможно, это странный подход, не отрицаю) Ну типа такого варианта (не уверен в нем): Код: sql 1. 2. 3. 4.
немного не так. для точки получателя far_service будет имя сервиса отправителя. поэтому вот так: Код: sql 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.09.2020, 00:49 |
|
|
start [/forum/topic.php?fid=46&msg=39991855&tid=1685674]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
40ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 262ms |
total: | 401ms |
0 / 0 |