Individuell geschriebenes ERP-System passt ideal - Midrange ...

42
TECHnIK & InTEGRATIOn
Distributed Data Management (DDM) in der Praxis
Die Konfiguration einer
kompletten DDM-umgebung
Bei der klassischen Client/Server-Architektur läuft das Datenbanksystem auf einem einzigen
Server, auf den dann mehrere Clients zugreifen. Das Problem an dieser Architektur ist, dass
man einen sogenannten „single point of failure“ haben kann, also eine einzige Fehlerquelle.
Fällt der Datenbankserver aus, so steht die gesamte Datenbank nicht mehr zur Verfügung.
Dies ist aber nicht der einzige Grund, verteilte Datenbankobjekte einzusetzen.
Viele Unternehmen sind oftmals
dezentral organisiert, haben al‑
so mehrere Filialen, weshalb manche
Daten ortsspezifisch zu klassifizieren
sind und andere unternehmensspezi‑
fisch. Es macht beispielsweise keinen
Sinn, dass in der Münchener Filiale die
Kundendaten der Hamburger Filiale
einsehbar sind. So halten die einzelnen
Filialen nur die Daten vor, die sie auch
wirklich benötigen. Die zentralen Fir‑
mendaten sollen hingegen nicht auf je‑
dem Filialrechner bereitgestellt werden,
sondern zentralseitig abgelegt werden.
Die klassische Client/Server‑Architek‑
tur spiegelt diesen Sachverhalt nicht
korrekt wider. Hierzu sind verteilte
Datenbanken besser geeignet. Hierbei
ist selbst ein heterogener Datenbank‑
einsatz denkbar, bei welchem auf den
verschiedenen Rechnern unterschiedli‑
che Datenbanksysteme eingesetzt wer‑
den. Doch ganz egal, ob es sich um eine
verteilte heterogene oder eine homoge‑
ne Datenbank handelt, wichtig ist, dass
der Anwender keine Unterschiede beim
Datenzugriff feststellt.
IBM hat schon früh verteilte Da‑
tenbanken auf dem heutigen System‑
i‑Server implementiert, doch erst seit
der Betriebssystemversion V5R2 kön‑
nen verteilte Datenbankobjekte direkt
über TCP/IP adressiert werden, so dass
aufwendige SNA‑Konfigurationen der
MIDRANGE MAgAZIN · 12/2012
Vergangenheit angehören. Der TCP/IP‑
Zugriff erfolgt über die relationale Da‑
tenbank, die dann wiederum die TCP/
IP‑Verbindung spezifiziert. Sie vermu‑
ten richtig: Dieses Prozedere benötigt
ein wenig Vorarbeit. Anschließend ist
alles Weitere ein Kinderspiel.
Die DDM-Konfiguration des Servers
Konfigurieren wir also gemeinsam
eine solche DDM‑Umgebung. Dafür
dient das folgende Ausgangsszenario
(Bild 1): Der Server 172.16.111.1 ist un‑
ser Quellsystem, auf dem die Daten er‑
fasst werden. Wir könnten auch sagen,
dass der ITP SERVER der lokale Server
ist. Die Daten sollen mittels entspre‑
chender Datenbankobjekte aber nicht
auf dem Quellsystem, sondern auf dem
Zielsystem 172.16.110.22 – also dem
EPS SERVER – gespeichert werden.
Damit der Verbindungsaufbau vom
ITP SERVER auf den EPS SERVER mittels
TCP/IP gelingt, müssen Sie zunächst
auf dem Quell‑System – also dem ITP­
SERVER – einen Datenbankeintrag für
das Zielsystem hinzufügen. Hierzu ge‑
ben Sie auf einer 5250‑Befehlszeile den
Befehl WRKRDBDIRE (Mit Einträgen im
RDB‑Verzeichnis arbeiten) ein – siehe
Bild 2.
Wenn Sie jetzt in der Anzeige fest‑
stellen, dass auf dem Quellsystem ein
entsprechender Eintrag für Ihr Zielsys‑
tem fehlt, fügen Sie ihn mit der Option
1 hinzu. Es sollte sich daraufhin der
Dialog aus Bild 3 (Einträge im RDB‑Ver‑
zeichnis hinzufügen) öffnen. Er zeigt
vier Parameter:
Der Parameter RDB enthält einen
beliebigen Datenbanknamen, den wir
allerdings später für die Erstellung der
DDM‑Objekte noch einmal benötigen.
Im Parameter RMTLOCNAME tra‑
gen Sie die IP‑Adresse des fernen Sys‑
tems ein; in unserem Beispiel also die
Adresse des EPS SERVERs.
1
AUSGAnGSSzEnARIO