Biztalk message agnostic оркестровка

Question

После перехода от Biztalk с BT2006 мы пытаемся вернуть его в организацию. Одно из разочарований, которые я имел на раннем этапе, заключалось в том, что когда вы занимались whl HL7 и оркестровки, нам нужно было иметь отдельную оркестровку для каждого типа сообщения ADT, хотя схема для каждого типа по существу одинакова, и каждая оркестровка выполняла то же самое. Двигаясь вперед в мире BizTalk 2010, здесь что-то улучшилось? Есть ли шаблон, который я могу использовать для использования одной оркестровки для всех типов ADT?

Answer 1

Обмен сообщениями HL7 в BizTalk остается неизменным с момента выпуска 2006 года. Поскольку BizTalk определяет схему для каждого сообщения и типа события (например, ADT^A01, ADT^A03, ADT^A08), а не только для , каждый тип сообщения (например, ADT, BAR, MDM), ваше сопоставление и оркестровки быстро стать беспорядком.

Вот что я сделал в прошлом, чтобы обойти это ограничение:

1. Разрешить сообщения прийти в нетипизированном к гармоническому. Это устанавливается MessageType = System.Xml.XmlDocument. Я обнаружил, что в общем, меня интересует только разбор или обновление нескольких элементов, поэтому я просто напишу вспомогательную библиотеку с несколькими родовыми операторами linq, чтобы получить нужные мне данные. Таким образом, я мог бы написать инструкцию linq, которая попадает на PID-3 (номер идентификатора пациента), и я смогу последовательно использовать ее над любым типом сообщения или события, потому что PID остается неизменным. Аналогичным образом, я бы использовал тот же метод для обновления сообщения. Этот метод не работает отлично, если есть большие структурные различия в полях, которые вы хотите обновить, или если вы хотите читать/обновлять большой объем данных.
2. Создание типовых/канонических схем типа сообщений HL7. Это требует немного больше работы, но в зависимости от того, сколько типов сообщений вы хотите обработать, это действительно может окупиться и более соответствует тому, как организации здравоохранения думают о своих интерфейсах HL7. Для этого вам нужно будет определить новую схему для типа сообщения и включить все возможные сегменты для этого сообщения. Таким образом, вместо того, чтобы определить несколько типов ADT, вы свернете все возможные варианты для A01, A03, A04 и т. Д. По одной главной схеме. Это позволит вам значительно уменьшить количество необходимой логики отображения и разбора. К сожалению, поскольку это не поведение по умолчанию ускорителя HL7, и для достижения этого потребуются некоторые пользовательские конвейеры и логика оркестровки. В принципе, вам нужно будет изменить некоторые свойства, чтобы заставить Accelerator думать, что ваше новое главное сообщение действительно.

Для большинства сквозных интерфейсов я бы рекомендовал технику # 1.В противном случае, если вы будете генерировать или потреблять в основном любое событие сообщения каноническим способом, техника № 2 может окупиться в долгосрочной перспективе.

Answer 2

Как я вижу, у вас есть две возможности.

1. Рассматривать сообщение как анонимное. Это означает, что ваше сообщение «непечатано» (вы объявляете его как тип System.Xml.XmlDocument). Тогда ваша оркестровка может опросить сообщение, чтобы решить, какой тип он есть.
2. Создайте сообщение с конвертом, тело которого может содержать все возможные типы сообщений (с помощью селектора групп выбора xsd). Затем ваша оркестровка обрабатывает тип сообщения о конверте. При таком подходе вы можете объявить тип, содержащийся в теле конверта, задав значение в заголовке конверта.

Я бы предпочел второй; в то время как это, безусловно, больше работает (вам нужно обернуть все входящие сообщения в конверте), это позволяет вам понять, что такое сообщение, просто глядя на заголовок конверта. Это означает, что вы можете маршрутизировать по типу сообщений, если вам нужно.