3. Konfiguration

3.1. Überblick

Wie bereits im letzten Kapitel beschrieben ist ein Standard Datenserver ein "normaler" GeoShop, welcher zuerst auch wie ein normaler GeoShop konfiguriert werden muss (s.a. Beispiel Datenserver auf der Referenz CD). Die dazu notwendigen Konfigurationsschritte sind in [2] beschrieben.

Nach der Konfiguration des Standard Datenserver wird der Portalserver zunächst einmal als Kopie des Standard Datenserver erstellt. Der Portalserver wird dann zusätzlich um folgende Konfigurationselementen ergänzt:

  • Den Zugriffsdefinitionen für die Datenserver (sog. Uploadbenutzer).

  • Die Mischskripts, welche die Mischung der Datenbestellungen besorgen.

  • Die Definition der globalen Verrechnungsfunktion.

  • Dem Benutzer (z.B. Spezialrabatt für amtl. Stellen).

  • Weiteren Datenebenen, welche für die zentrale Visualisierung im Portalserver benötigt werden (z.B. Rasterebenen).

Jede lokale Installation des Standardserver muss schliesslich mit dem zentralen Portalserver verbunden werden. Dazu sind in der Optionendatei appserver.opt einige Optionen zu definieren welche festlegen, welche Dateien an den Portalserver weiter geleitet werden sollen. Ausserdem muss ein Portalbenutzer definiert werden, mit welchem der Portalserver auf den lokalen Datenserver zugreifen kann.

3.2. Konfiguration des Datenserver

3.2.1. Definitionen in appserver.opt

Nachfolgend ist ein Beispiel für die notwendigen Einträge angegeben (s.a. Referenz CD):

PortalServer MAP
   SERVER STRING http://localhost:3501
   USER STRING data
   PASSWORD STRING data
   MODEL_DM01AVCH24D STRING idx
   MODEL_SIA405_mit_Erweiterungen STRING idx
   MODEL_Meta STRING itf
}

Die einzelnen Einträge unter PortalServer haben folgende Bedeutung:

OptionTypBeschreibung
SERVERSTRINGGeoShop Connectstring zum Portalserver in der Form <server>:<serverport>.
USERSTRINGUploadbenutzer auf dem Portalserver. Bemerkung: für jeden Datenserver wird ein eigener Upload Benutzer benötigt.
PASSWORDSTRINGPasswort des Upload Benutzers.
MODEL_<Modelname>STRINGPro Datenmodell bei welchem Dateien an den Portalserver weiter geleitet werden sollen, muss angegeben werden welche Dateitypen betroffen sind (idx, geo oder itf). Falls mehrere Dateitypen weiter geleitet werden, so sind die Dateitypen als kommaseparierte Liste anzugeben (z.B. idx,geo). Es gibt aber auch Typenkombinationen, welche nicht unbedingt sinnvoll sind. Z.B. bewirkt itf allein schon, dass nach dem Upload auch die .idx und .geo Dateien auf dem Portalserver erzeugt werden. Die Definition MODEL_<Modelname> STRING itf,idx,geo ist daher überflüssig.

3.2.2. Portalbenutzer

Der Portalbenutzer ist ein Benutzer, welcher vom Portalserver für die Auslösung von Teilbestellungen auf dem lokalen Datenserver verwendet wird. Der Portalbenutzer muss daher Zugriff auf alle im Portalserver definierten Produkte haben. Nachfolgend ist die Definition des Portalbenutzer von der Referenz CD angegeben:

USER
   name STRING portal
   password STRING portal
   privileges LIST
      STRING client
   }
   views LIST
   }
   queries LIST
   }
   products LIST
      STRING av_dxf
      STRING av_itf
      STRING lk_wasser_dxf
      STRING lk_wasser_itf
   }
   preferences MAP
   }
}
[Anmerkung]

Die via den Portalserver erfolgten Teilbestellungen werden auf dem lokalen Datenserver unter dem Portalbenutzer registriert. Eine Kontrolle der via den Portalserver erfolgten Datenbezüge ist daher über den Portalbenutzer jederzeit möglich.

3.3. Konfiguration des Portalserver

3.3.1. Uploadbenutzer

Pro Datenserver muss auf dem Portalserver ein Uploadbenutzer definiert werden. Nachfolgend ist der Uploadbenutzer von der Referenz CD angegeben:

USER
   name STRING data
   password STRING data
   prefix STRING data_
   privileges LIST
      STRING upload_DM01AVCH24D
      STRING upload_SIA405_mit_Erweiterungen
      STRING upload_Meta
   }
   views LIST
   }
   queries LIST
   }
   products LIST
   }
   preferences MAP
      order.name1 STRING ''
      order.name2 STRING ''
      order.adr1 STRING ''
      order.adr2 STRING ''
      order.tel STRING ''
      order.fax STRING ''
      order.remark STRING ''
      order.zip STRING ''
      order.city STRING ''
      order.email STRING ''
      range.maxY REAL 245435.0
      range.maxX REAL 675850.0
      range.minY REAL 245364.0
      range.minX REAL 675776.0
      order.country STRING ''
   }
}

Ausserdem muss ein Uploadbenutzer folgende Bedingungen erfüllen:

  • Für jeden Datenserver muss ein eigener Uploadbenutzer definiert werden.

  • Der Uploadbenutzer muss upload_* Privilegien für alle Datenmodelle haben.

  • Für jeden Uploadbenutzer muss ein Datenpräfix in der Form <user>_ definiert werden. Anhand des Datenpräfix erkennt der Portalserver im Moment der Bestellung welche .idx Datei von welchem Datenserver geliefert wurde und kann so die Teilbestellungen an die richtigen Datenserver weiter leiten.

3.3.2. Angabe der Datenserver in appserver.opt

Pro Datenserver muss auf dem Portalserver in appserver.opt ein Eintrag der folgenden Form definiert werden:

DataServer_data MAP
   SERVER STRING http://localhost:3600
   USER STRING data
   PASSWORD STRING data
}

Die einzelnen Einträge in der Gruppe DataServer_<server> haben folgende Bedeutung:

OptionTypBeschreibung
USERSTRINGZugeordneter Bestellbenutzer auf dem angeschlossenen Datenserver. Bei Bestellungen auf dem Portalserver wird der angegebene Bestellbenutzer auf dem angeschlossenen Datenserver benutzt.
PASSWORDSTRINGPasswort des Bestellbenutzers.
SERVERSTRINGAdresse des Datenserver in der Form <server>:<port>.

3.3.3. Mischskript

Nach der erfolgreichen Ausführung der Teilbestellungen auf den Datenservern wird der Mischscript ausgeführt. Der Mischscript wird in jeder Produktdefinition auf dem Portalserver eingetragen, d.h. die Produktdefinitionen auf dem Portalserver und den Datenservern unterscheiden sich lediglich in diesem Punkt.

Beispiel für eine Produktdefinition auf dem Portalserver (s.a. Referenz CD):

PRODUCT
   name STRING av_dxf
   display_name STRING 'AV: AutoCAD-DXF'
   models LIST
      MODEL
         name STRING DM01AVCH24D
         display_name STRING 'amtl. Vermessung'
         topics LIST
            STRING FixpunkteKategorie1
            STRING FixpunkteKategorie2
            STRING FixpunkteKategorie3
            STRING Liegenschaften
         }
      }
   }
   params MAP
   }
   services MAP
      DM01AVCH24D MAP
         script STRING \script\il2dxf\merge.cfg
         service STRING download
      }
   }
   price_function STRING \script\price\price.cfg,AV_Meta
}

Beispiel für eine Produktdefinition auf dem Datenserver (s.a. Referenz CD).

PRODUCT
   name STRING av_dxf
   display_name STRING 'AV: AutoCAD-DXF'
   models LIST
      MODEL
         name STRING DM01AVCH24D
         display_name STRING 'amtl. Vermessung'
         topics LIST
            STRING FixpunkteKategorie1
            STRING FixpunkteKategorie2
            STRING FixpunkteKategorie3
            STRING Liegenschaften
         }
      }
   }
   params MAP
   }
   services MAP
      DM01AVCH24D MAP
         script STRING \script\il2dxf\DM01AVCH24D.cfg
         service STRING download
      }
   }
   price_function STRING \script\price\price.cfg,AV_Meta
}

Mit dem Mischscript können beliebig komplexe Mischoperationen auf den angelieferten Teilresultaten ausgeführt werden. Im Mischscript können z.B. Doppelte Linien etc. eliminiert werden. Es muss jedoch beachtet werden, dass die Mischscripts z.T. abhängig vom gelieferten Datenformat und u.U. sogar produktabhängig sind. Der auf der Referenz CD enthaltene Mischscript kopiert die gelieferten Teilbestellungen lediglich in eine einzigige .zip Datei.

3.3.4. Globale Verrechungsfunktion

Die Globale Verrechungsfunktion baut auf dem auf der Referenz CD mitgelieferte INTERLIS Datenmodell Meta auf. In Meta sind neben Metainformationen zum Datenserver auch die preisrelevanten Tarifinformationen eingetragen (z.B. Flächen- und Punkttarif). Jeder angeschlossene Datenserver muss für seine Daten das Datenmodell Meta füllen und die Metadaten auf den Portalserver replizieren. Der Portalserver kann dann über die in Meta enthaltenen Preisinformationen den Gesamtpreis einer Bestellung ermitteln und dem Benutzer online anzeigen. Zusätzlich sind in auch die eigentlichen Metainformationen zu den einzelnen Datenservern in Meta enthalten.

[Anmerkung]

Die Benutzung von Meta ist für die Funktionsweise des Portalserver nicht zwingend notwendig. Gegenüber einem "normalen" Metamodell enthält Meta zusätzlich die Preisinformationen. Die Preisinformationen werden in Meta ebenfalls als Metainformationen zu den Daten betrachtet.

3.4. Nützliche Hinweise

3.4.1. Minimale Konfiguration

Bei der Konfiguration des Standard Datenserver ist darauf zu achten, dass nur die minimal notwendigen Konfigurationen (Skripts, Produktdefinitionen, etc.), welche für den Betrieb im Portalnetz notwendig sind, definiert werden. Damit kann der Aufwand beim Abgleich der angeschlossenen Standard Datenserver klein gehalten werden.

3.4.2. Verteilung der Konfigurationen via Patchserver

Bei mehreren dezentral betriebenen Datenservern wird die Verteilung bzw. Synchronisation aller Datenserver Konfigurationen rasch relativ aufwendig. Die Konfigurationen sollten daher automatisch via einen zentralen Patchserver verteilt werden. Der Patchserver gehört zum Lieferumfang des GeoShop Enterprise.

3.4.3. Umgang mit Firewalls

Jegliche Kommunikation zwischen den Datenservern und dem Portalserver erfolgt über HTTP. Für die Datenserver muss daher der Firewall für den HTTP Port des Datenserver geöffnet werden (Inbound). Ausserdem muss ein Datenserver via den HTTP Port des Portalserver auf den Portalserver zugreifen können (Outbound).

Grundsätzlich kann ein Datenserver auf dem HTTP Port 80 gestartet werden. Falls dies nicht möglich sein sollte (weil der Webserver bereits auf Port 80 läuft), kann der Datenserver über das Redirector Servlet in den lokal vorhanden Webserver eingebunden werden. Das Redirector Servlet gehört zum Lieferumfang des GeoShop Enterprise.

3.4.4. Performance des Portalserver

Der Portalserver dient als zentraler Eingang in das Netz der Datenserver. An den Portalserver werden daher erhöhte Performance Anforderungen gestellt. Über die im GeoShop Enterprise enthaltene Skalierungsoption ist aber die Skalierung des Portalserver über beliebige viele Prozessoren oder Zusatzrechner (ohne weitere Softwarekosten) jederzeit möglich (s.a. [4]).