Каков наилучший способ создания / использования идентификатора при обработке сообщения в Biztalk?

Question

Наша программа на данный момент: у нас есть процесс, который включает в себя несколько схем, оркестровок и отправленных / полученных сообщений.

Наше желание: иметь идентификатор, который связывает весь процесс вместе, когда мы регистрируем наш прогресс вТаблица SQL-сервера.

Пока у нас есть таблица, в которой регистрируется наш прогресс, но при наличии нескольких сообщений ее очень сложно прочитать, поскольку иногда Biztalk будет обрабатывать некоторые сообщения не по порядку.

Например, мы могли бы иметь:

1 Beginning process for client1
2 Second item for client1
3 Third item for client1
4 Final item for client1

Легко следовать, если за один раз обновляется только один клиент.С другой стороны, это будет гораздо более вероятным:

1 Beginning process for client1
2 Beginning process for client2
3 Second item for client2
4 Third item for client2
5 Second item for client1
6 Third item for client1
7 Final item for client1
8 Final item for client2

Было бы неплохо иметь идентификатор для всего объекта, чтобы последний список мог быть упорядочен по этому полю идентификатора.

Какой самый лучший и / или самый быстрый способ сделать это?Мы думали добавить идентификатор, который мы создадим, с начального момента срабатывания первой оркестровки и продолжать передавать это значение всем схемам и последующим оркестрациям.Это кажется большой работой и потребовало бы, чтобы мы изменили все схемы - что кажется неправильным.

Должны ли мы вообще иметь такой идентификатор?Какие еще решения приходят на ум?

Answer 1

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

В нашем приложении мы должны использовать предоставленный извне идентификатор (от клиента).У нас есть многочастное сообщение с этим идентификатором.Вы могли бы рассмотреть это также

Answer 2

Вы можете создать UniqueId и StepId и передать их в контексте сообщения. Когда новый процесс для клиента запускается, задайте для UniqueId значение Guid, а для StepId - 1. По мере передачи следующему процессу увеличивайте StepId.

Это позволит вам запрашивать события, сгруппированные по идентификатору клиента и в порядке (stepId) события, которое произошло.

Answer 3

Я не уверен, что полностью понимаю все детали вашей конкретной настройки, но здесь идет речь:

Если вы можете сопоставить сообщения от одного и того же клиента в «длительную» оркестровку (которая ожидает последующие сообщения от того же клиента), то для оркестрации будет автоматически назначен идентификатор ServiceId, который будет сохраняться в течение всей оркестровки .

Как вы говорите, для целей корреляции вы обычно пытаетесь использовать естественные ключи в существующих схемах входящих сообщений для корреляции последующих сообщений обратно с работающей оркестровкой - таким образом, вам не нужно менять схемы. В вашем примере ClientId может быть хорошей корреляцией при условии, что один и тот же клиент не может отправлять несколько наборов сообщений одновременно. (и в худшем случае, если вы добавите новый ключ корреляции к схемам, все системы, участвующие в оркестрации, необходимо будет изменить, чтобы «запомнить» этот ключ и вернуть его вам.) Опять же, принимая ClientId в качестве ключа корреляции, в вашем примере 2 оркестровки будут работать одновременно - одна для клиента 1 и одна для клиента 2

Однако, по причинам масштабируемости и контроля версий, (очень) длительных оркестровок, как правило, следует избегать, если только они не являются абсолютно необходимыми (например, если вы не можете запустить процесс только после получения всех 4 клиентских сообщений). Если вы решили сохранить каждое сообщение как отдельную оркестровку или просто сопоставить и отфильтровать по порту, другой способ «отслеживать» наборы - это использовать BAM - вы можете использовать продолжение, чтобы связать все клиентские сообщения обратно, например, для целей отчета или тому подобного.

Answer 4

Посмотрите на БАМ.Он предназначен для выполнения именно того, что вы описываете: Использование мониторинга бизнес-активности

В этой книге есть очень хорошая глава о BAM и этот инструмент Один из авторов книги может помочь вам в разработке вашего BAM-решения.И, наконец, хороший BAM Poster .

Не отчаивайтесь первоначальной сложностью.Когда вы обдумываете это, BAM - это одна из самых классных функций BizTalk.

Надеюсь, это поможет.Удачи.

Answer 5

Это может быть не самый простой способ, но вы смотрели на это:

http://blogs.msdn.com/b/appfabriccat/archive/2010/08/30/biztalk-application-tracing-made-easy-with-biztalk-cat-instrumentation-framework-controller.aspx

По сути, это инструментарий, который позволяет вам проводить события с конвейеров, карт, садов и т. Д.

Когда вы записываете в трассировку событий, вы можете использовать «бизнес-ключ», который свяжет множество событий в цепочку, аналогично тому, что вы говорите.

Доступно здесь http://btscatifcontroller.codeplex.com/