UNIFY Anforderungen

Heidler UNIFY ist die browserbasierte Logistikplattform, die Ihre Versanddaten standortübergreifend an einer Stelle zusammenführt. Die Daten werden von den vorhandenen HVS32-Installationen über den Sync-Manager an UNIFY übertragen. UNIFY selbst wird auf einem von Ihnen bereitgestellten Server installiert und von den Arbeitsplätzen ausschließlich im Browser aufgerufen.

Diese Seite richtet sich an Ihre IT. Sie beschreibt, was vor der Installation bereitstehen muss: Softwarestände, Server, Ports, Firewall-Freigaben und das Zertifikat.

 

Benötigte Softwarestände

Die folgende Aufstellung ist ein allgemeiner Hinweis und dient dazu, dass Sie vorab erkennen können, ob bei Ihnen Aktualisierungen notwendig sind. Liegt eine Ihrer Komponenten unter dem angegebenen Stand, fragen Sie das Update bitte rechtzeitig vor dem Installationstermin bei unserem Support an.

Komponente	Mindestversion	Anmerkung
HVS32	7.118.1	Versandsystem an jedem Standort, der Daten an UNIFY liefert
Firebird	5	Datenbank-Engine des HVS32.
Sync-Manager	1.0.0	überträgt die Versanddaten aus HVS32 an UNIFY
UNIFY	1.0.0	die Weboberfläche selbst
DataGatewayServer (DGS)	3.9.8	nur erforderlich, wenn aus UNIFY heraus Aktionen am Packstück ausgelöst werden (z.B. Etikett erneut drucken, stornieren, Online-Tracking)
Datenbankarchivierung	4.8.0	nur bei eingesetzter Archivierung

 

Server für UNIFY

UNIFY wird mit einem Setup auf einem Windows-Server installiert. Das Setup richtet fünf Windows-Dienste ein:

Dienst	Aufgabe
HSC-UNIFY-Web	Webserver (nginx) – liefert die Oberfläche aus und ist der einzige Eingang von außen
HSC-UNIFY-Service	Anwendungsdienst (Auskunft, Verwaltung)
HSC-UNIFY-Import	Datenannahme vom Sync-Manager
HSC-UNIFY-Auth	Anmeldung und Token
HSC-UNIFY-Postgres	Datenbank

Alles Benötigte bringt das Setup mit – Java-Laufzeitumgebung, Datenbank, Anmeldedienst und Webserver sind im Installationsmedium enthalten. Es wird keine Software nachinstalliert, und während der Installation wird keine Internetverbindung benötigt.

Betriebssystem und Rechte

Unterstützt werden Windows-Server-Versionen, für die Microsoft noch Support leistet. Betriebssysteme, deren Supportzeitraum abgelaufen ist, erhalten keine Sicherheitsupdates mehr und werden von uns weder getestet noch unterstützt. Derzeit sind das Windows Server 2019 und neuer.

Punkt	Anforderung
Betriebssystem	Microsoft Windows Server, 64-Bit, Version 2019 oder neuer – siehe Hinweis oben
Rechte	Das Setup muss als Administrator ausgeführt werden – es registriert Dienste und legt eine geplante Aufgabe an
Virenscanner	Das Installationsverzeichnis von der Echtzeitprüfung ausnehmen. Sperrt der Virenscanner Datenbankdateien, fallen Dienste ohne erkennbaren Zusammenhang aus

Der Betrieb auf einer virtuellen Maschine ist möglich und üblich. Bitte achten Sie darauf, dass die VM später einfach skalierbar ist und nicht auf einem Host liegt, dessen Festplattenleistung bereits durch andere VMs ausgelastet ist.

Ausstattung

Bei den folgenden Werten handelt es sich um Richtwerte. Der Bedarf hängt an der Datenmenge, nicht an der Zahl der Anwender.

Punkt	Minimum	Empfohlen
Prozessor	4 Kerne	4 Kerne
Arbeitsspeicher	8 GB	16 GB
Freier Festplattenspeicher	20 GB (SSD)	50 GB und mehr, je nach Aufbewahrungsdauer
Netzwerkanbindung	100 Mbit/s	1.000 Mbit/s

Die Dienste belegen zusammen rund 6 GB Arbeitsspeicher (Datenbank-Cache, die beiden Anwendungsdienste, der Anmeldedienst und Windows selbst). Bei weniger Arbeitsspeicher weicht der Server auf die Auslagerungsdatei aus, was sich in der Oberfläche deutlich bemerkbar macht.

Beim Festplattenspeicher zählt neben der Installation (rund 2 GB) vor allem das Wachstum der Datenbank sowie der Ordner Backup\: dort liegt jede Sicherung vollständig, die letzten zehn werden aufbewahrt.

Die Werte gelten für UNIFY allein. Laufen auf demselben Server weitere Anwendungen – etwa der DataGatewayServer –, ist deren Bedarf zusätzlich einzuplanen. Die Richtwerte der übrigen HSC-Applikationen stehen auf der Seite Systemvoraussetzungen.

Weitere Voraussetzungen

• Port 443 sollte frei sein. UNIFY wird im Standard auf Port 443 ausgeliefert. Läuft auf dem Server bereits ein IIS oder ein anderer Webserver auf diesem Port, teilen Sie uns das bitte vor der Installation mit, damit unser Support einen abweichenden Port einträgt. Was dabei zu beachten ist, steht unter Abweichender Web-Port.
• Die Systemzeit muss stimmen. Die Anmeldung arbeitet mit Token, deren Gültigkeit sekundengenau geprüft wird. Ein Server, dessen Uhr um Minuten abweicht, meldet Anwender wieder ab. Wir empfehlen eine Zeitsynchronisation gegen einen Domänen- oder NTP-Server.
• Der Servername muss im Netz auflösbar sein – und derselbe sein, unter dem die Anwender UNIFY später aufrufen. Er geht in das Zertifikat und in die Ausstellerangabe der Token ein. Eine nachträgliche Änderung bedeutet: neues Zertifikat und Neustart der Dienste.

 

Standardports

Die aufgeführten Werte sind Vorgaben und bei der Installation änderbar. Das Setup prüft vor der Installation, ob die Ports auf dem Server frei sind, und meldet Belegungen und Dopplungen.

UNIFY

Dienst	Port	Protokoll	Gebunden an	Von außen erreichbar
Web (nginx)	443	HTTPS	alle Adressen	ja – der einzige Eingang
Anwendungsdienst	9080	HTTP	127.0.0.1	nein
Anwendungsdienst, Verwaltung	9090	HTTP	127.0.0.1	nein
Import-Dienst	9081	HTTP	127.0.0.1	nein
Import-Dienst, Verwaltung	9091	HTTP	127.0.0.1	nein
Anmeldedienst	9082	HTTP	127.0.0.1	nein
Datenbank (PostgreSQL)	9432	TCP	localhost	nein

Die sechs inneren Ports hören ausschließlich auf der Loopback-Adresse. Sie sind vom Netz aus nicht ansprechbar, auch ohne Firewall-Regel. Alles, was von außen kommt, läuft über den Webserver auf Port 443.

Abweichender Web-Port

Ist Port 443 auf dem Server bereits belegt, wird UNIFY bei der Installation auf einen anderen Port gelegt. Bitte melden Sie das vorab beim Support, damit der Wert gleich bei der Installation gesetzt wird. Eine nachträgliche Änderung ist möglich, zieht aber dieselben Anpassungen nach sich.

Bei einem abweichenden Web-Port ist Folgendes zu beachten:

• Der Port gehört in die Aufrufadresse. Die Oberfläche wird dann über https://<servername>:<port>/sm/ui/ aufgerufen. Verknüpfungen, Lesezeichen und Links aus anderen Anwendungen müssen den Port enthalten.
• Die Firewall-Freigabe gilt für diesen Port, nicht für 443.

Die übrigen Ports (9080, 9081, 9082, 9090, 9091, 9432) sind ebenfalls änderbar, falls sie auf dem Server bereits belegt sind. Auch das bitte vorab melden.

DataGatewayServer (DGS)

Der DataGatewayServer wird benötigt, wenn aus UNIFY heraus Aktionen am Packstück ausgelöst werden (Etikett drucken, stornieren, sperren, Online-Tracking). Er kann auf dem HVS32-Server liegen – oder gemeinsam mit UNIFY auf demselben Server betrieben werden.

Komponente	Port	Bereich	Zweck
DGS – REST-Server	9035	intern (LAN)	Schnittstelle, über die UNIFY Aktionen anstößt
DGS – HVS-Client	9034	intern (LAN)	Verbindung zum HVS32

 

Firewall-Freigaben

Das Setup legt keine Firewall-Regeln an. Die Freigaben richten Sie selbst ein. Solange das nicht geschehen ist, lässt sich UNIFY nur auf dem Server selbst aufrufen; von den Arbeitsplätzen aus läuft der Browser ohne Fehlermeldung in den Zeitablauf.

Einzurichten

Richtung	Port	Quelle	Zweck
eingehend	TCP 443 (bzw. der gewählte Web-Port)	Netze der Arbeitsplätze	Aufruf der Weboberfläche
eingehend	TCP 443	Rechner, auf denen der Sync-Manager läuft	Datenübertragung nach UNIFY
ausgehend (HVS32-Server)	TCP 443	Sync-Manager → UNIFY-Server	Gegenrichtung derselben Verbindung

Weitere Freigaben sind nicht erforderlich:

• Keine Freigabe für 9080, 9081, 9082, 9090, 9091 und 9432. Diese Ports sind nur über die Loopback-Adresse erreichbar und gehören nicht ins Netz.
• Keine ausgehende Regel für den UNIFY-Server ins Internet. UNIFY ruft von sich aus keinen Dienst im Internet auf.

Was dabei häufig übersehen wird

• Der Server muss sich selbst unter seinem Namen erreichen können. Anwendungs- und Import-Dienst prüfen jedes Token gegen den eigenen Anmeldedienst und holen dessen Schlüssel über https://<servername>/…, also über den regulären Weg durch den Webserver. Löst der Name auf dem Server selbst nicht auf, oder blockiert die lokale Firewall die Verbindung des Servers zu sich selbst, wird jede Anfrage mit HTTP 401 beantwortet, obwohl die Zugangsdaten korrekt sind.

 

Zertifikat / HTTPS

UNIFY wird ausschließlich über HTTPS aufgerufen. Für das Zertifikat gibt es zwei Möglichkeiten. Die Entscheidung sollte vor der Installation fallen, da der Servername in das Zertifikat eingeht.

Möglichkeit 1: UNIFY erzeugt ein eigenes Zertifikat

Das Setup legt ein selbst ausgestelltes Zertifikat an (10 Jahre Laufzeit, RSA 2048), das den Servernamen, den Rechnernamen, den FQDN, localhost und die lokalen IPv4-Adressen als Subject Alternative Name trägt.

Für Testbetrieb und den reinen Innenbetrieb reicht das aus. Die Browser der Anwender kennen den Aussteller allerdings nicht und zeigen bei jedem Aufruf eine Warnung. Für den Dauerbetrieb empfehlen wir Möglichkeit 2.

Möglichkeit 2: Sie stellen ein eigenes Zertifikat bereit

Benötigt werden zwei Dateien im PEM-Format:

Datei	Inhalt
server.crt	das Zertifikat – zuerst das eigene, dahinter die Zwischenzertifikate der CA
server.key	der zugehörige private Schlüssel, ohne Passphrase

Anforderungen an das Zertifikat:

• Der Name, unter dem die Anwender UNIFY aufrufen, muss als Subject Alternative Name (SAN) eingetragen sein. Ein Name nur im Feld CN genügt nicht, da Browser und Java dieses Feld nicht mehr auswerten. Werden Kurzname und FQDN verwendet, gehören beide hinein.
• Ausgestellt von einer CA, der die Arbeitsplätze vertrauen. Bei einer internen CA bedeutet das: deren Wurzelzertifikat ist auf den Clients verteilt, üblicherweise per Gruppenrichtlinie.
• RSA ab 2048 Bit oder ECDSA.
• Der private Schlüssel muss exportierbar sein. Ein Zertifikat, das im Windows-Zertifikatspeicher liegt und sich dort nicht herauslösen lässt, ist nicht verwendbar; in dem Fall wird ein neues Zertifikat auf dem Server beantragt.
• Der Schlüssel darf keine Passphrase tragen. Andernfalls wartet der Webserver beim Start auf eine Eingabe und startet nicht durch.

Der private Schlüssel verlässt Ihren Server nicht. Sie legen beide Dateien selbst ab und rufen anschließend das mitgelieferte Skript setup\zertifikat-uebernehmen.cmd als Administrator auf. HSC benötigt weder Schlüssel noch Passwort.

Erneuerung

Die Erneuerung des Zertifikats liegt bei Ihnen. Nach jedem Austausch muss setup\zertifikat-uebernehmen.cmd erneut ausgeführt werden: das Skript nimmt das neue Zertifikat in die Vertrauensspeicher der internen Dienste auf und startet sie neu. Wird dieser Schritt vergessen, antwortet die Anwendung mit HTTP 401, ohne dass der Browser einen Zertifikatsfehler anzeigt.

 

Arbeitsplätze

Auf den Arbeitsplätzen wird keine Software installiert. UNIFY läuft vollständig im Browser.

• Aktueller Browser in einer gepflegten Fassung: Google Chrome, Microsoft Edge oder Mozilla Firefox.
• Der Servername muss vom Arbeitsplatz aus auflösbar und der Web-Port erreichbar sein.
• Bei einem Zertifikat aus interner CA: deren Wurzelzertifikat muss auf den Arbeitsplätzen im Vertrauensspeicher liegen, damit keine Zertifikatswarnung erscheint.
• Empfohlene Bildschirmauflösung: 1920 × 1080 oder höher. Die Oberfläche arbeitet mit breiten Tabellen.

 

Datensicherung

Die Datensicherung liegt in Ihrer Verantwortung. Das Setup richtet keinen Sicherungszeitplan und keine geplante Sicherungsaufgabe ein. Selbsttätig entsteht nur eine Sicherung: der Installer legt vor jedem Update eine an.

Zu sichern ist das gesamte Installationsverzeichnis, nicht nur die Datenbank. Dort liegen auch die verschlüsselten Zugangsdaten und die Zertifikate. Ein reiner Datenbankauszug lässt sich ohne diese nicht wieder in Betrieb nehmen.

 

Test- und Produktivsystem

Für ein Testsystem ist keine zweite UNIFY-Installation erforderlich. Test- und Produktivsystem können über dasselbe UNIFY laufen. Das Testsystem wird als eigener Standort mit eigener TenantId angelegt und liefert seine Daten wie jeder andere Standort an. In der Oberfläche wählen Sie über die Standortauswahl in der Kopfzeile, welche Daten angezeigt werden.

Die Bestände bleiben dabei getrennt, ohne dass ein weiterer Server bereitgestellt, gepflegt und gesichert werden muss.