Отслеживание сообщений от внешней программы до biztalk и обратно

Question

У меня есть внешняя программа, которая выведет XML-документ из db и передаст его BizTalk. Возможно ли создать идентификатор транзакции или что-то (идентификатор сообщения как в БД), чтобы я мог отслеживать сообщение в BizTalk и хранить информацию в настраиваемой конвейере BizTalk в базе данных с данным идентификатором транзакции?

Я хочу сохранить, если он не удается или нет, и у меня есть настраиваемые конвейеры, которые захватывают эту информацию для хранения. Я не хочу быть в зависимости от HAT для обработки ошибок.

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

Answer 1

Если вы публикуете сообщение BizTalk, оно возвращает вам по умолчанию SubmissionHandle. Это свойство Context, доступное вам из порта приема. Затем он может быть захвачен в оркестровке и использован для корреляции ошибок с исходным представлением.

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

Good Luck

Answer 2

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

В BizTalk лучшим способом отслеживания потока, инициированного конкретным сообщением, является идентификатор обмена.

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

Если вам нужен единый идентификатор для группировки «все» вместе, это он.

Если в вашем сценарии у вас есть возможность вернуть его обратно своему абоненту, он сможет связать его со всем, что вам нужно (в и из базы данных).

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

Поскольку процессы прогрессируют (успешно или нет), вы всегда можете вернуться и обновить эту запись, поскольку вы ВСЕГДА имеете доступ к идентификатору обмена в BizTalk.

Answer 3

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

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

Другим подходом является использование БАМа и создание веб-сайта, который клиент может использовать для определения статуса своего сообщения, например, у самой компании доставки, например, DHL. Это может потребоваться еще несколько усилий, но я думаю, что лучше подобрать решение для удовлетворения потребностей.

С помощью BAM вы можете извлекать данные без изменения проектов BizTalk вообще. «Просто» проанализируйте свои потребности, чтобы узнать, какие данные извлекать или собирать в BAM-Excel, экспортировать в базу данных BizTalk, активировать и подключить его к редактору профиля отслеживания.

Затем вы можете показать важные камни для миллионов клиентов на веб-сайте. Я знаю, что это не так просто, как я описал выше, но это будет хорошо :)