BizTalk 2010 - Создание подтверждений
Информация:
Входящее сообщение имеет тип HL7. Я использую в конвейере приема "Flafile-Disassembler", а не компонент конвейера "BTAHL7 2.x Disassembler", потому что HL7-схема немного изменена, а дизассемблер BTAHl7 разделяет сообщение (составные сообщения), и мы не хочу; И мы не хотим использовать оркестровку.
Вопросы:
Как я могу создавать подтверждения в приемном конвейере в BizTalk 2010, не используя "BTAHL7 Disassembler" (без разделения -> подход из нескольких сообщений)?
Или можно предотвратить разбиение сообщения в компоненте конвейера дизассемблера BTAHL7?
положительный ACK будет достаточно.
Благодарю.
3 ответа
Как говорит @boatseller, вы не можете запретить дизассемблеру HL7 создавать сообщения, состоящие из нескольких частей.
Другой вопрос: вы можете создать пользовательский конвейерный компонент для отправки подтверждения HL7, а затем просто использовать собственную схему плоских файлов (с готовым компонентом конвейерного компонента дизассемблера плоских файлов).
1. Используйте двусторонний порт приема.
Это должно работать с использованием двустороннего порта, даже с адаптером MLLP, но вам нужно все проверить и протестировать и понять, что Microsoft может поддерживать или не поддерживать использование адаптера MLLP без конвейера дизассемблера HL7 2.X или использование BizTalk в способ, предложенный ниже.
2. Соотнесите запрос и ответ.
Вам потребуется пользовательский компонент конвейера в конвейере получающего местоположения, чтобы BizTalk создал подписку для ответа. Используйте Мастер компонентов конвейера, чтобы быстро приступить к созданию компонента.
В методе Execute вашего пользовательского класса компонента конвейера (который вы получаете от реализации интерфейса IComponent) напишите что-то похожее на приведенный ниже код.
public Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(Microsoft.BizTalk.Component.Interop.IPipelineContext pc, Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg)
{
const string sysPropertyNamespace = "http://schemas.microsoft.com/BizTalk/2003/system-properties";
var epmToken = inmsg.Context.Read("EpmRRCorrelationToken", sysPropertyNamespace);
var correlationToken = epmToken != null
? (string) epmToken
: Guid.NewGuid().ToString();
inmsg.Context.Promote("EpmRRCorrelationToken", sysPropertyNamespace, correlationToken);
inmsg.Context.Promote("RouteDirectToTP", sysPropertyNamespace, true);
return inmsg;
}
Использование или EpmRRCorrelationToken а также RouteDirectToTP свойства для обработки сообщения запрос-ответ без оркестровки описаны в этом сообщении блога MSDN.
3. Создайте и отправьте подтверждение
Вы можете использовать другой пользовательский компонент конвейера внутри вашего конвейера отправки, чтобы вручную создать подтверждение на основе входного сообщения, возможно, с некоторой дополнительной конфигурацией компонента конвейера, которая читается во время выполнения.
Как и первый пользовательский конвейерный компонент, вы можете реализовать метод Execute интерфейса IComponent. Код, подобный этому, должен работать:
public Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(Microsoft.BizTalk.Component.Interop.IPipelineContext pc, Microsoft.BizTalk.Message.Interop.IBaseMessage inmsg)
{
string msgOut;
var bodyPart = inmsg.BodyPart;
if (bodyPart == null)
return inmsg; // Maybe throw an exception instead?
var inboundStream = new ReadOnlySeekableStream(bodyPart.GetOriginalDataStream());
inboundStream.Position = 0;
using (var reader = new StreamReader(inboundStream))
{
var builder = new StringBuilder();
// Read the input stream's first line - this should be the MSH segment:
var firstLine = reader.ReadLine();
// TODO: read search/replacement values from pipeline configuration
// TODO: make a better ACK header than this
builder.AppendLine(firstLine.Replace("ADT^A01", "ACK"));
// Construct your acknowledgement segment, preferably without hardcoding it here:
builder.AppendLine("MSA|AA|ADT^A01");
msgOut = builder.ToString();
}
// Write out the output
var outputStream = new VirtualStream();
var writer = new StreamWriter(outputStream, Encoding.Default);
writer.Write(msgOut);
writer.Flush();
outputStream.Seek(0, SeekOrigin.Begin);
inmsg.BodyPart.Data = outputStream;
pc.ResourceTracker.AddResource(inboundStream);
pc.ResourceTracker.AddResource(outputStream);
return inmsg;
}
Помимо обработки встроенных TODO и добавления более нулевой проверки, это должно быть довольно полным решением, хотя ваш пробег может варьироваться, особенно когда речь идет о возврате действительного подтверждающего сообщения HL7.
Бонус. Почему бы не использовать оркестровку?
Это было задано в комментарии к вопросу, и вот несколько причин для использования пользовательских компонентов конвейера вместо оркестровки:
- Оркестровки медленные. Microsoft в своей статье " Оптимизация производительности оркестровки" говорит, что по возможности следует избегать использования оркестровки. Оркестровки увеличивают время ожидания и время отклика, потому что они требуют дополнительных обращений к базе данных BizTalk MessageBox, а дополнительные процессы и потоки запускаются на сервере BizTalk.
- Благодарности возвращаются быстрее. Интеграции HL7 обычно используют подтверждения приема / получения. Многие системы не будут отправлять дополнительные сообщения, пока последнее отправленное сообщение не будет подтверждено. Поэтому, если вам нужно дождаться ускорения оркестровки, прочитать вход, построить выход ACK, вернуть ACK в порт и затем отправить ACK обратно, вы значительно замедлите обработку. Да, это похоже на № 1 выше, но это важно понимать.
- Оркестровка делает ваше решение более подверженным сбоям. Оркестровка - это еще одна точка отказа. Если вам нужно отключить создаваемую ACK-оркестровку или связанные с ней экземпляры хоста, то вы утратили способность получать сообщения. Большим преимуществом BizTalk является его способность изолировать различные части интеграционного решения, обеспечивая высокую доступность и повышенную надежность. Когда ваши разветвленные компоненты конвейера принимающего порта возвращают подтверждение после простой публикации входящего сообщения в окне сообщений BizTalk, получение сообщений может продолжаться, даже если ваши внутренние системы / компоненты не работают.
Чтобы ответить на ваши конкретные вопросы:
Ack HL7 является специфической функцией дизассемблера HL7. Вам нужно будет создать свой собственный собственный компонент дизассемблера, который будет запускать ffdasm внутри, и сгенерировать свой собственный ack для имитации поведения дизассемблера HL7.
Нет, я не знаю, как запретить дизассемблеру HL7 создавать сообщения из нескольких частей. Вы можете легко рекомбинировать сегменты на карте, выполненной в оркестровке.
Пара вещей здесь.
Номер 1 - По моему опыту, оркестровки для HL7 должны использоваться только в крайних случаях. В нашей реализации есть только несколько, где нам нужно раскрутить несколько сообщений из одного входящего сообщения. Подход только для обмена сообщениями лучше всего подходит для HL7. Они дорогостоящие и медленные, и, повторяя сказанное, добавьте дополнительную точку отказа.
Номер 2 - Кусочки того, что было сказано, должно быть правдой, по крайней мере, как я это делаю. Вы можете обойти некоторые аспекты DASM, и я это сделаю, потому что он определенно не идеален. Так что я бы обернул его и включил ваш пользовательский функционал. DASM возвращает очередь в модуль обмена сообщениями, который содержит дизассемблированное сообщение и подтверждение, вы можете удалить ACK и поставить свой собственный "статический" подтверждение.
DASM создает и ставит в очередь ACK в формате xml, чтобы ASM в конвейере отправки мог собрать его обратно в необработанный формат HL7 вместе с некоторыми другими компонентами. Таким образом, вы можете сделать то же самое в пользовательском конвейерном компоненте или найти способ вызвать те частные методы в DASM, которые создают ACK и позволяют ему делать все это за вас.