Bei der Entwicklung einer BizTalk Anwendung, die Nachrichten über TCP/IP versenden und empfangen muss, könnte man auf eine kleine Hürde stoßen.

BizTalk besitzt nativ keinen TCP-Adapter. Da kommt natürlich die Frage auf, wie man dieses Problem löst. Online findet man oft beschrieben, wie der MLLP-Adapter (Minimal Lower Layer Protocol) genutzt werden kann. Aber es gibt auch andere Lösungswege. Eine Lösung, für die wir uns entschieden haben, war ein Windows Service, der die Übertragung und den Empfang der TCP/IP Nachrichten übernimmt.

Warum kein MLLP-Adapter?

Der MLLP-Adapter ist primär für HL7-Nachrichten im Gesundheitswesen gedacht. Auch wenn MLLP über TCP funktioniert, gibt es mehrere Gründe, warum man sich dagegen entscheiden könnte.

  • MLLP ist speziell für HL7-Nachrichten gedacht und erfordert einen bestimmten Nachrichtenaufbau mit Start- und Endzeichen.
  • Wenig Flexibilität, da MLLP auf ein spezifisches Nachrichtenformat beschränkt ist.
  • Keine direkte Kontrolle der Verbindung, da das Verbindungsmanagement durch den Adapter vorgegeben wird.

Warum ein Windows Service?

  • Erhöhte Flexibilität: Das TCP-Protokoll kann genauso umgesetzt werden, wie es das System benötigt.
  • Unterstützung für verschiedene Formate, Protokolle und Authentifizierungsmechanismen.
  • Volle Kontrolle über Fehlerhandling und (Wieder-)Aufbau der Verbindung.
  • Unabhängigkeit von HL7: Kein festgelegtes Nachrichtenformat erforderlich.
  • Erweiterbarkeit: Anpassungen an zukünftige Anforderungen sind leichter möglich.

Aber es gibt auch Nachteile:

  • Zusätzlicher Entwicklungsaufwand, um den eigenen Service zu entwerfen und entwickeln.
  • Eigenes Monitoring erforderlich, da alles im Windows Service außerhalb der BizTalk-Umgebung läuft.
  • Es ist eine zusätzliche Schnittstelle nötig (z.B. über Dateien), um BizTalk mit dem Windows Service zu verbinden.

Fazit

Die Entwicklung eines eigenen Windows Services anstelle des MLLP-Adapters ist sinnvoll, wenn:

  • Das externe System kein HL7 nutzt.
  • Spezielle Anforderungen an die TCP-Kommunikation bestehen.
  • Volle Kontrolle über das Fehlerhandling und Verbindungsmanagement benötigt wird

Der größte Nachteil ist der zusätzliche Entwicklungsaufwand. In den meisten Fällen wird man eine Lösung für das Monitoring implementieren müssen, um eine „Blackbox“ außerhalb der BizTalk Infrastruktur zu vermeiden.

Dieser Tipp kommt von Michael Fulde.