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

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

Наше желание: иметь идентификатор, который связывает весь процесс вместе, когда мы регистрируем наш прогресс в таблице 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

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

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

Должны ли мы вообще хотеть иметь такое удостоверение личности? Любые другие решения, которые приходят на ум?


biztalk biztalk-2010
person Alex In Paris    schedule 05.10.2011    source источник

Ответы (5)


arrow_upward
1
arrow_downward

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

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/

person tom redfern    schedule 05.10.2011

arrow_upward
1
arrow_downward

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

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

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

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

person StuartLC    schedule 05.10.2011

arrow_upward
1
arrow_downward

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

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

Пусть вас не смущает первоначальная сложность. Если разобраться, BAM — это одна из самых крутых функций BizTalk.

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

person Fabio    schedule 05.10.2011

arrow_upward
1
arrow_downward

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

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

person Jay    schedule 06.10.2011

arrow_upward
1
arrow_downward

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

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

person Derek Beattie    schedule 06.10.2011
comment
Это не отвечает на мой вопрос о том, как реализовать UniqueId. Мне нравится идея StepId, спасибо. - person Alex In Paris; 21.10.2011
comment
Guid.NewGuid, по крайней мере, это то, что я делал в прошлом, когда процесс начинается, а затем, как я уже сказал, он проходит через весь процесс. Если только я не понял. - person Derek Beattie; 21.10.2011
comment
Думаю, я тоже не совсем понял... Суть вопроса в том, как передать это значение из одной оркестровки в другую? Первоначальное сообщение запускает O1, который выполняет некоторую обработку, а затем O2 выполняет дополнительную обработку и обновляет базу данных, а затем отправляет другое сообщение O3. Как я увижу одного и того же Guid во всех этих сообщениях, отправляемых туда и обратно из всех трех оркестровок? - person Alex In Paris; 21.10.2011