Einleitung

Um, zum Beispiel, einem Profil Daten per HTTP zu senden, muss man eine bestimmte URL ansprechen. Der schematische Aufbau der URL ist:

Wenn nun ein DMZ-Server im Einsatz ist, möchte man, dass Anfragen dieser Art an den DMZ-Server gehen und von dort an den inneren Integration Server weitergeleitet werden (Forwarding).

Hinweis: Bedenken Sie bitte generell, welche Pfade Sie über den DMZ-Server zugänglich machen möchten und richten Sie nur die ein, die Sie wirklich benötigen.

Standard-Kontext auf DMZ-Server

Per Default wird auf dem DMZ-Server auf HTTP-Anfragen reagiert, deren URL-Pfad mit dem URL-Kontext /forward beginnen. Diese Vorgabe kann in der Konfigurationsdatei ./etc/startup_dmz.xml (auf dem DMZ-Server) über die Parameter‌ servletContext und servletPath geändert werden. Nachfolgend gehen wir davon aus, dass die Default-Einstellungen verwendet werden, also servletContext=/forward und servletPath=/*

Forwarding-Regeln auf DMZ-Server

Auch wenn per Default auf dem DMZ-Server auf den URL-Kontext /forward reagiert wird, müssen dort noch Forwarding-Regeln definiert werden, also wie solche Anfragen weitergeleitet werden, da der DMZ-Server selbst nicht auf die Anfragen antwortet. Die Definition dieser Forwarding-Regeln erfolgt in der Konfigurationsdatei ./etc/forward.properties (auf dem DMZ-Server).

Falls der DMZ-Server innerhalb ./etc/hub.xml mehrere HTTP-Listener (Port 80, 443, usw.) hat, werden alle Requests, die über einen der HTTP-Listener eintreffen und einer Forwarding-Regel entsprechen, entsprechend der Regel weitergeleitet.

• Jede Zeile stellt eine unabhängige Regel dar. Die linke Seite (Quell-Kontext), links neben dem Gleichheitszeichen, muss eindeutig sein.

• Änderungen in der Datei ./etc/forward.properties werden zur Laufzeit erkannt und neu ausgewertet. Ein Neustart des Systems ist nicht notwendig.

• Für Diagnosezwecke kann man das HTTP-Requestlog und das Serverlog unter ./logs auswerten. Achtung: Die Zeiten im Requestlog sind in der Zeitzone UTC, die im Serverlog sind in der Systemzeitzone.

Gehen wir nun von folgender Forwarding-Regel aus und davon, dass der innere Integration Server die gezeigte IP hat.

In diesem Fall werden alle Anfragen an den DMZ-Server, die mit dem Pfad /forward beginnen, an den inneren Integration Server weitergeleitet. Alle anderen Pfade werden nicht weitergeleitet.

Die Anfrage http://<URL/IP und Port DMZ-Server>/forward/dw/Request/<URL-Suffix des Profils> würde also weitergeleitet werden an http://192.168.213.12:80/dw/Request/<URL-Suffix des Profils>.

Wenn man nicht alle Anfragen weiterleiten möchte, kann man es auch etwas spezifischer machen.

Oder noch spezifischer mit folgender Regel. Damit könnte man die URL-Suffixe von HTTP-Profilen so setzen, dass nur manche von außen über den DMZ-Server ansprechbar sind. Ein HTTP-Profil mit URL-Suffix outside/example1 wäre dann über den DMZ-Server erreichbar und ein HTTP-Profil mit URL-Suffix example2 wäre nur über den inneren Integration Server erreichbar.

Weitere Kontexte auf DMZ-Server einrichten

Damit auf dem DMZ-Server auf weitere Kontexte reagiert wird (also nicht nur auf /forward), auf der innere Integration Server normalerweise reagiert, muss für den CommunicationForwardManager der Parameter addStandardServlets in der Konfigurationsdatei ./etc/startup_dmz.xml (auf dem DMZ-Server) auf true gesetzt werden.

Folgende Kontexte werden damit auf dem DMZ-Server aktiviert.

Auch hier müssen erst entsprechende Forwarding-Regeln definiert werden, damit eine Weiterleitung stattfindet. Wichtiger Hinweis: Beachten Sie bitte, dass hier Groß-/Kleinschreibung relevant ist und definieren Sie bitte jeweils beide Varianten Request/request und Trigger/trigger.

Hinweis: Wenn auf dem inneren System ein HTTPS-Listener aktiv ist, kann das Forwarding auch über HTTPS erfolgen. Da die Verbindung vom DMZ-Server zum inneren Integration Server in einem geschützten Netzwerkteil erfolgt, ist aber dort eine nochmalige Verschlüsselung per HTTPS normalerweise nicht notwendig.

AS2-Handling

AS2-Requests können entweder auf dem DMZ-Server behandelt oder an den inneren Integration Server weitergeleitet werden. Zudem ist eine Kombination beider Varianten möglich.

HTTPS einrichten (DMZ-Server)

Sie können HTTPS für die Kommunikation zwischen dem externen Client und dem DMZ-Server verwenden.

Siehe Abschnitt Hinzufügen eines HTTPS-Listeners.

HTTP(S) tunneln (vom DMZ-Server zum inneren System)

Es ist möglich HTTP(S)-Requests über den MessageService zu tunneln. Dazu fügen Sie bitte folgende Option in der Konfigurationsdatei ./etc/startup_dmz.xml (auf DMZ-Server) ein. Die Forwarding-Regeln müssen auch in diesem Fall angepasst werden (siehe oben).