1 Themenübersicht

Dieses Dokument beschreibt zunächst den Aufbau und die Arbeitsweise des ERP-System-Output-Managers (SOM). Im Anschluss werden die verschiedenen Konfigurations- sowie Verwaltungsmöglichkeiten vorgestellt. Den Abschluss bildet ein Kapitel mit Hilfestellungen bei Problemen bzw. der Fehlerdiagnose und Fehlerbeseitigung.

Die Installation des ERP-System-Output-Managers ist im Dokument Installation ERP-System-Output-Manager (SOM) beschrieben.

2 Zielgruppe

Administratoren

3 Einführung

Das Ausgabemanagement nutzt einen oder mehrere ERP-System-Output-Manager für die Ausgabe von Belegen und Berichten. Ein ERP-System-Output-Manager (SOM) ist ein auf die Ausgabe von Dokumenten spezialisierter Server. Ähnlich wie ein Druckserver stellt er seine Ausgabedienste anderen Computern (Clients) zur Verfügung. Bei den Clients handelt es sich in diesem Fall um die ERP-System-Application-Server (SAS), die ihre Ausgabeaufträge zur Bearbeitung an die ERP-System-Output-Manager schicken.

Ein SOM kann die Ausgaben für ein oder mehrere Application Server übernehmen, wobei die Application Server sogar zu unterschiedlichen Systemen gehören können[1]. Einem System können wiederum ein oder mehrere SOMs zugeordnet werden[2]. SOM und SAS (bzw. Systeme) stehen sozusagen in einer N:M Beziehung.

Während der Bearbeitung eines Auftrags wechselt der SOM die Rolle und wird selbst zum Client, beispielsweise wenn er eine aktuelle Berichtsvorlage (*rpt) von einem SAS anfordert, per ODBC Daten von einem „ODBC-Server“ abfragt, Mails über einen Mailserver versendet oder Archivkopien im Knowledge Store ablegt.

Systemlandschaft

Die Kommunikation zwischen SAS und SOM basiert, wie die Kommunikation zwischen Browser und SAS, auf dem HTTPS-Protokoll und erlaubt somit die sichere Kommunikation auch über das Internet. Es besteht also auch die Möglichkeit, einen SOM außerhalb des (Server-)LANs zu platzieren[3].

3.1 Ausgabegeräte und -medien

Der SOM unterstützt folgende Arten von Ausgabegeräten bzw. -medien:

Drucker
Fax
E-Mail
Ablage von Dateien im Knowledge Store

Der Begriff „Ausgabegerät“ wird dabei als Verallgemeinerung eines Druckers benutzt. Ein SOM stellt in der Regel mehrere solche Ausgabegeräte zur Verfügung. Wobei jeder Drucker und jedes Fax jeweils separate Ausgabegeräte darstellen. Jedes Ausgabegerät besitzt bestimmte Eigenschaften bzw. Fähigkeiten. Einige dieser Eigenschaften/Fähigkeiten gelten generell für die Art des Ausgabegerätes, andere sind spezifisch für das jeweilige Gerät.

Ein SOM stellt grundsätzlich alle Drucker und Faxgeräte zur Verfügung, die auf dem jeweiligen Computer installiert sind. Um diese Geräte in einem System nutzen zu können, müssen sie jedoch erst einem Ausgabegerät zugeordnet werden. Diese indirekte Zuordnung bringt folgende Vorteile:

Gezielte Auswahl der tatsächlich benötigten Drucker.
Einzelne Drucker (oder auch der SOM) können geändert bzw. ausgetauscht werden, ohne dass sich der Name des Ausgabegerätes ändert. Damit entfällt beispielsweise die Notwendigkeit, Belegdokument-Vorlagen oder Benutzereinstellungen anpassen zu müssen.
Die Verwendung des Ausgabegeräts kann über eine Berechtigungsrolle berechtigt werden.

3.1.1 Drucker

Für die Druckausgabe nutzt der SOM die auf der Betriebssystemebene installierten Drucker. Es werden somit alle Drucker unterstützt, die auch von dem Betriebssystem unterstützt werden, bzw. für die entsprechende Druckertreiber verfügbar sind[4]. Grundsätzlich kann es sich bei den Druckern um lokale oder „Netzwerkdrucker“ handeln. Es wird aber empfohlen die Drucker – wie bei einem Druckerserver üblich – direkt (also lokal) zu installieren[5].

3.1.2 Fax

Für das Versenden von Belegen und Berichten als FAX nutzt der SOM die in Windows 2000 bzw. Windows 2003 integrierte Faxlösung von Microsoft (Windows Fax). Um diese nutzen zu können wird ein von dieser Software unterstütztes Faxmodem bzw. eine entsprechende ISDN-Karte benötigt[6].

Die Faxaufträge werden von dem SOM überwacht und es können Benachrichtigungen erzeugt werden, wenn das Versenden erfolgt bzw. fehlgeschlagen ist[7].

Es besteht auch die Möglichkeit, Faxlösungen von Drittherstellern einzubinden (siehe „Einbinden von Faxlösungen“). Da der SOM nur die integrierte Faxlösung von Microsoft überwachen kann, hängt es von der jeweiligen Faxlösung selbst ab, ob und wie sie den Status von Aufträgen protokolliert bzw. Benachrichtigungen versendet.

3.1.3 E-Mail

Belege und Berichte können vom SOM auch als E-Mail versendet werden, wobei die erzeugten Ausgabedokumente als Anhang der E-Mail beigefügt werden. Das Dokumentformat für den Anhang lässt sich dabei wählen.

Das Versenden der E-Mails delegiert der SOM an einen SMTP-Server, d.h. ein solcher Server muss vorhanden sein und dem SOM bekannt gemacht werden.

3.1.4 Knowledge Store

Belege und Berichte können ebenso als Datei ausgegeben und im Knowledge Store abgelegt werden. Folgende Dateiformate werden dabei unterstützt:

Portable Document Format (PDF)
HTML (*.html)
Text (*.txt)
Text (Komma-getrennt) (*.csv)
Text (Tapstopp-getrennt) (*.tsv)
Rich Text Format (*.rtf)
Microsoft Word (*.doc)
Microsoft Excel (*.xls)
Crystal Reports (*.rpt)
XML (*.xml)
Druckerdatenstrom (z.B. PCL, Postscript)

3.2 Crystal Reports

Grundlage für alle Beleg- und Berichtsdokumente sind entsprechende Berichtsvorlagen. Die Erstellung bzw. der Entwurf solcher Berichtsvorlagen erfolgt mit der (externen) Anwendung „Crystal Reports“ von der Firma „Business Objects“. Die mit Crystal Reports erstellten (*.rpt) Dateien werden in der Repository-Datenbank gespeichert[8].

In den SOM ist die so genannte „Print Engine“ von Crystal Reports integriert[9], die es erlaubt, die Ausgabe von Berichten zu automatisieren.

Der SOM lädt die Berichtsvorlagen (*.rpt) bei Bedarf über den SAS, der den entsprechenden Ausgabeauftrag gestellt hat. Die geladenen Berichtsvorlagen werden auf dem SOM zwischengespeichert, sodass bei Aufträgen mit gleicher Berichtsvorlage der Zugriff auf den SAS eingespart werden kann[10].

3.2.1 Datenzugriff

Der Zugriff auf die Datenbanken der Systeme erfolgt über einen speziellen ODBC-Treiber, der die Datenbanken als so genannte ODBC-Datenquellen für Crystal Reports verfügbar macht. Es existieren zwei Versionen dieses ODBC-Treibers. Eine Version für normale (interaktive) Client-Computer und eine spezielle Version für den SOM. Die Client-Version wird beispielsweise für die Erstellung von Berichtsvorlagen benötigt und muss zusammen mit Crystal Reports auf den Computern installiert werden, auf denen Berichtsvorlagen erstellt werden sollen. Die SOM-Version des ODBC-Treibers ist Bestandteil des SOMs und wird zusammen mit diesem auf entsprechenden Server-Computern installiert.

Die in den Berichtsvorlagen verwendeten ODBC-Datenquellen müssen im Allgemeinen auch auf dem SOM verfügbar bzw. eingerichtet sein. Nur für die OLTP-, OLAP-, Repository- bzw. Konfigurationsdatenbanken ist dies nicht notwendig. Berichtsvorlagen für diese Datenbanken sollten stattdessen die folgenden symbolischen Namen verwenden:

„Semiramis OLTP“
„Semiramis OLAP“
„Semiramis Repository“
„Semiramis Configuration“

Diese symbolischen Namen erlauben die Erstellung von Berichtsvorlagen, die ohne Änderung (!), für verschiedene Datenbanken (und Systeme) genutzt werden können.

Der SOM ist in der Lage, diese Namen zur Laufzeit automatisch durch die Namen von temporären Datenquellen zu ersetzen und diese so zu konfigurieren, dass sie den Datenbanken des jeweiligen Benutzers entsprechen.

4 Aufbau und Ablauf

Der SOM besteht aus folgenden Komponenten:

Web-Server
Warteschlange für Ausgabeaufträge
Scheduler
Berichts-Prozessor(en)
Report Cache
OBDC-Treiber
Schnittstelle für Windows Drucker
Client für Windows Fax
Client für E-Mail (SMTP) Server
Client für WebDAV (Knowledge Store)
Client zum Laden von Berichtsvorlagen (*.rpt)
Benachrichtigungsdienst

4.1 Web-Server

Der SOM verfügt über einen integrierten HTTPS-Server, über den er seine Dienste entsprechenden HTTPS-Clients zur Verfügung stellt. Zu diesen Clients zählen in erster Linie die ERP-System-Application-Server (SAS), die ihre Ausgabeaufträge und Statusabfragen an den SOM schicken. Aber auch mit einem normalen Browser können bestimmte (HTML-)Statusseiten des SOM abgefragt werden.

Eingehende Anfragen (Ausgabeaufträge, Statusabfragen etc.) werden von dem Web-Server in der Regel nicht selbst bearbeitet, sondern an entsprechenden Subkomponenten des SOM weitergereicht.

4.2 Warteschlange

Alle eingehenden Aufträge werden zunächst in einer zentralen Warteschlange zwischengespeichert. Diese (erste) Warteschlange arbeitet ausgabegerät-unabhängig und erfüllt folgende Aufgaben:

Asynchrone Bearbeitung der Aufträge, d.h. die Benutzer können weiterarbeiten und müssen nicht warten, bis ihre Aufträge abgearbeitet sind.
Kontrolle/Steuerung des Ressourcen-Verbrauchs (Hauptspeicher, CPU-Last, ODBC-Zugriffe), d.h. es werden nur soviel Aufträge gleichzeitig bearbeitet wie es die Ressourcen des SOM und der verwendeten Server (insbesondere ODBC-Server) zulassen.
Prioritätsgesteuerte Abarbeitung der Aufträge, d.h. Aufträge mit höherer Priorität werden vor Aufträgen mit niedriger Priorität abgearbeitet, selbst wenn diese früher eingegangen sein sollten.
Ressourcengesteuerte Abarbeitung der Aufträge, d.h. Aufträge, für die noch nicht alle notwendigen Ressourcen bereitstehen, werden solange „angehalten“, bis diese Ressourcen verfügbar werden. Zu diesen „Ressourcen“ zählen sowohl die physikalischen Ausgabegeräte (Drucker) als auch die Berichtsvorlagen (*.rpt), die erst von einem SAS geladen werden müssen.

Die Warteschlange dient gleichzeitig als Auftragshistorie, d.h. sie speichert auch den Status der bereits abgeschlossenen bzw. abgebrochenen Aufträge[11]. Eine Ansicht aller in der Warteschlange befindlichen Aufträge ist über die URL https://som-hostname:8443/jobs möglich.

4.3 Scheduler

Die Abarbeitung der zentralen Warteschlange und die Überwachung der Status der Aufträge erfolgt durch einen zentralen „Scheduler“. Dabei stehen folgende Aspekte im Vordergrund:

Die Erstellung von umfangreichen Berichten bzw. Belegen mit Crystal Reports kann längere Zeit in Anspruch nehmen. Eine rein sequentielle Abarbeitung würde dazu führen, dass alle nachfolgenden Berichte bzw. Belege erst mit großer Verzögerung ausgegeben werden könnten. Um dies zu verhindern, sollten die Aufträge möglichst parallel bearbeitet werden.
Es können nicht beliebig viele Berichte bzw. Belege gleichzeitig erstellt werden, da die dazu benötigten Ressourcen beschränkt sind. Dies gilt sowohl für die Ressourcen auf dem SOM (CPU, Hauptspeicher, Festplatte) als auch für die Ressourcen auf den benötigten Servern (ODBC-Server, Datenbank).
Bei einer Folge von Druckerausgaben (bezogen auf einen Drucker) ist es in der Regel wichtig, dass die Ausdrucke in der Reihenfolge ausgegeben werden, wie sie als Auftrag eingegangen sind. Bei einer parallelen Abarbeitung könnte dies aber nicht gewährleistet werden, da sich die Bearbeitungszeiten der einzelnen Aufträge stark unterscheiden können.

Die Erstellung der Berichte bzw. Belege erfolgt daher durch so genannte „Berichts-Prozessoren“, deren Anzahl sich über die Konfigurationsdatei des SOM anpassen lässt. Da die Anzahl dieser Prozessoren normalerweise gering ist (der voreingestellte Wert beträgt 3), ist es besonders wichtig, dass sie möglichst effizient genutzt werden. Daher werden von diesen Prozessoren nur die Arbeitsschritte eines Auftrags ausgeführt, für die die „Report Engine“ von Crystal Reports wirklich benötigt wird. Alle anderen Arbeitsschritte, wie beispielsweise die Beschaffung der Berichtsvorlage, das Versenden per Mail oder das Speichern im Knowledge Store erfolgt grundsätzlich davor bzw. danach. So wird erreicht, dass die Prozessoren nicht selbst auf externe Ressourcen warten müssen, sondern in dieser Zeit schon andere Aufträge bearbeiten können. Bei Druckausgaben stellt der Scheduler zudem sicher, dass nicht mehrere Prozessoren gleichzeitig für einen Drucker arbeiten.

4.3.1 Subsysteme

Die für einen Ausgabeauftrag notwendigen Arbeitschritte (z.B.: Berichtsvorlage prüfen bzw. laden, Bericht erstellen, Bericht als E-Mail verschicken, Kopie im Knowledge Store speichern und SAS benachrichtigen) werden jeweils durch eigene Subsysteme ausgeführt. Einige dieser Arbeitsschritte können erst dann ausgeführt werden, wenn der vorangegangene Arbeitsschritt abgeschlossen ist (der Bericht muss fertig gestellt sein, bevor er als E-Mail versendet werden kann), andere können hingegen parallel durchgeführt werden (z.B. das Versenden als E-Mail und das Speichern im Knowledge Store).

Zu diesen Subsystemen zählen:

Subsystem zum Laden für Berichtsvorlagen (*.rpt)
Subsystem zum Erstellen von Berichten (Berichts-Prozessoren)
Subsystem zum Speichern von Dokumenten im Knowledge Store
Subsystem zum Versenden von Dokumenten als E-Mail
Subsystem zum Versenden von Dokumenten als Fax
Subsystem zum Versenden von Benachrichtigungen an die SAS

Jedes dieser Subsysteme verfügt intern selbst über eine Warteschlage sowie über eine begrenzte Anzahl von Threads, die diese Warteschlage „abarbeiten“. Die Anzahl der Threads ist dabei abhängig von dem jeweiligen Subsystem. Für das Subsystem zum Erstellen von Berichten kann die Anzahl der Threads (Prozessoren) in der Konfigurationsdatei festgelegt werden, die Subsysteme für E-Mail und Fax benutzen jeweils nur einen Thread und die Subsysteme, die auf SAS zugreifen benutzen für jeden SAS einen eigenen Thread.

Die Aufgabe des Schedulers liegt im Wesentlichen darin, die Aufträge je nach Art und Status zum richtigen Zeitpunkt an die notwendigen Subsysteme zu übergeben. Diese informieren nach Abschluss ihrer Arbeit ihrerseits wieder den Scheduler, der dann ggf. den oder die nächsten Arbeitsschritte anstößt.

Folgendes Beispiel soll diesen Ablauf verdeutlichen. Ein Beleg soll als E-Mail verschickt und eine Kopie im Knowledge Store gespeichert werden:

Der SAS schickt einen entsprechenden Auftrag an den SOM.
Dieser reiht den Auftrag in die zentrale Warteschlange ein, informiert den Scheduler und liefert dem SAS eine (positive) Eingangsbestätigung zurück.
Der Scheduler stellt fest, dass es einen neuen Auftrag gibt und dass dieser eine Berichtsvorlage benötigt. Er übergibt den Auftrag an das Subsystem für die Berichtsvorlagen.
Das Subsystem für Berichtsvorlagen verfügt über einen Cache mit bereits geladenen Berichtsvorlagen. Wenn die benötigte Berichtsvorlage bereits vorhanden und noch aktuell ist, wird der Scheduler sofort benachrichtigt. Wenn die Berichtsvorlage fehlt oder möglicherweise nicht mehr aktuell ist, wird eine entsprechende Ladeaufforderung in die Warteschlange des Subsystems eingereiht. Das Laden bzw. Prüfen der Berichtsvorlage erfolgt dann asynchron. Nach Abschluss des Ladens/Prüfens wird der Scheduler informiert.
Der Scheduler stellt fest, dass es einen Auftrag gibt, der an einen Berichts-Prozessor weitergeben werden kann. Er übergibt den Auftrag an das Subsystem für die Erstellung von Berichten.
Das Subsystem für die Berichtserstellung reiht den Auftrag gemäß seiner Priorität in die Warteschlange für die Berichts-Prozessoren ein. Die Berichts-Prozessoren arbeiten diese Warteschlange kontinuierlich ab. Wenn ein Bericht erstellt wurde, wird wieder der Scheduler informiert.
Der Scheduler stellt nun fest, dass die Berichtserzeugung für einen Auftrag abgeschlossen wurde, aber die erzeugte (temporäre) Datei noch per E-Mail verschickt und im Knowledge Store gespeichert werden muss. Er informiert (gleichzeitig) die entsprechenden Subsysteme.
Das Subsystem zum Versenden von E-Mails reiht den Auftrag in seine Warteschlange ein. Die Warteschlange wird kontinuierlich von einem Thread abgearbeitet. Nach erfolgreichem Versenden wird der Scheduler benachrichtigt.
Analog reiht das Subsystem zum Speichern von Dokumenten im Knowledge Store den Auftrag ebenfalls in seine Warteschlange ein. Hier existiert für jeden SAS eine separate Warteschlange, die jeweils von einem Thread abgearbeitet wird. Nach erfolgreichem Speichern wird auch hier der Scheduler informiert.
Sowie der Scheduler die Benachrichtigungen von beiden Subsystemen erhalten hat, setzt er den Status des Auftrages auf „abgeschlossen“ und informiert anschließend das Subsystem für die Benachrichtigungen.
Das Subsystem zum Versenden von Benachrichtigungen reiht den Auftrag wieder in seine Warteschlange ein. Auch hier existiert für jeden SAS eine separate Warteschlange, die jeweils von einem Thread abgearbeitet wird. Da für den Scheduler der Auftrag bereits abgeschlossen ist, erfolgt hier keine abschließende Rückmeldung mehr.
Damit ist die Bearbeitung auf dem SOM abgeschlossen

Die geschilderte Vorgehensweise dient dazu, die für einen Auftrag notwendigen Ressourcen (dazu zählen auch die benötigten Server) möglichst effizient zu nutzen ohne sie dabei zu überlasten.

4.3.2 Priorität von Aufträgen

Das Subsystem für die Berichtserstellung berücksichtigt bei der Abarbeitung die Priorität der jeweiligen Ausgabeaufträge. In der Standardkonfiguration arbeiten dabei alle Berichts-Prozessoren nach der selben Regel: Wenn für einen frei gewordenen Berichts-Prozessor der nächste Auftrag auszuwählen ist, wird aus der Warteschlange der Auftrag mit der höchsten Priorität ausgewählt. Wenn mehrere Aufträge mit gleicher Priorität vorhanden sind, wird der erste (älteste) Auftrag ausgewählt.

Ein einmal begonnener Auftrag wird von dem jeweiligen Berichts-Prozessor nicht unterbrochen, wenn danach ein Auftrag mit höherer Priorität eingeht. Im ungünstigsten Fall kann es in der Standardkonfiguration daher doch vorkommen, dass alle Berichts-Prozessoren mit lang laufenden Berichten beschäftigt sind und Aufträge mit höherer Priorität warten müssen. Um dies zu verhindern kann für jeden Berichts-Prozessor separat festgelegt werden, dass er nur Aufträge mit einer bestimmten Priorität (Minimum/Maximum) verarbeiten darf. Auf diese Weise kann beispielsweise ein Berichts-Prozessor für Aufträge mit hoher Priorität reserviert werden, der dann durch die lange laufenden Aufträge nicht mehr blockiert werden kann (vorausgesetzt, dass diese eine niedrigere Priorität haben). Aber auch der ungekehrte Fall ist möglich, d.h. die Minium- und Maximumprioritäten der Berichts-Prozessoren können so konfiguriert werden, dass die Aufträge mit niedriger Priorität nur noch durch einen Berichts-Prozessor abgearbeitet werden.

5 Konfiguration

5.1 ERP-System-Output-Manager

5.1.1 Konfigurationsordner

Bei der Installation des SOM wird in dem Installationsordner[12] ein Unterordner config angelegt. In diesem Verzeichnis liegen nach der Installation folgende Dateien:

Dateiname	Beschreibung
server.properties	Konfigurationsdatei
localhost.jks	Zertifikat für „localhost“ im „*.jks“-Format
localhost.pfx	Zertifikat für „localhost“ im „*.pfx“-Format

Die Datei server.properties dient dabei als Vorlage und ist entsprechend anzupassen (siehe „Konfigurationsdatei“). Die „localhost“-Zertifikate werden im Normalbetrieb nicht benötigt, sie sind ausschließlich für Demo- bzw. Testzwecke vorgesehen[13]. Stattdessen muss in diesem Verzeichnis ein Zertifikat („*.jks“-Format) abgelegt werden, das auf den tatsächlichen Hostnamen des SOM ausgestellt ist.

5.1.2 Konfigurationsdatei

Die als Vorlage ausgelieferte Konfigurationsdatei (server.properties) enthält bereits alle Standardeinstellungen für den SOM. Einzelne Einträge müssen aber angepasst werden[14], dies gilt beispielsweise für den Hostnamen des SOM und den zu verwendenden SMTP-Server.

Die nachfolgenden Abschnitte beschreiben die vorhandenen Konfigurationsparameter und deren Bedeutung.

5.1.2.1 Einstellungen für den integrierten Web-Server

Die nachfolgend beschriebenen Parameter dienen der Konfiguration des integrierten Web-Servers.

com.cisag.sys.www.daemon.baseURI

Mit diesem Parameter wird die Basisadresse (-URL) des SOM festgelegt, z.B. https://som.yourcompany.com:8443. Alle (HTTPS-) Anfragen, die an den SOM geschickt werden, müssen diese Basisadresse verwenden[15]. Die Basisadresse spezifiziert das Protokoll, den Servernamen (Hostname) und eine Portnummer. Weiterhin muss der Servername mit dem Dateinamen des Server-Zertifikats übereinstimmen (also beispielsweise: som.yourcompany.com.jks) und das Zertifikat muss auf diesen Namen ausgestellt sein.

com.cisag.sys.www.daemon.bindURI

Über diesen Parameter kann ein spezielles Netzwerk-Interface ausgewählt werden. Typischerweise erfolgt die Auswahl des Netzwerk-Interfaces über den Servernamen (siehe com.cisag.sys.www.daemon.baseURI). Wenn dies nicht erwünscht ist, kann mit der „bindURI“ ein alternativer Name und damit das gewünschte Netzwerk-Interface spezifiziert werden.

com.cisag.sys.www.daemon.needClientAuth

Mit diesem Parameter wird festgelegt, ob für die Authentifizierung ein (Client-)Zertifikat benötigt wird. Die Voreinstellung (true) für diesen Parameter sollte nicht geändert werden.

5.1.2.2 Einstellungen für den ODBC-Zugriff

Die nachfolgend beschriebenen Parameter dienen der Konfiguration des vom SOM verwendeten ODBC-Treibers.

somodbc.certname

Dieser Parameter gibt an, unter welchem Namen das Benutzerzertifikat für den ODBC-Zugriff im persönlichen Zertifikatsspeicher (mit dem „Zertifikatsimport-Assistenten“) gespeichert wurde. In der Regel ist dieser Name identisch mit dem „Common Name“ (CN) aus dem Zertifikat. Für das hier gewählte Beispiel ist dies som.yourcompany.com, also der Servername des SOM.

somodbc.timeout

Über diesen Parameter kann festgelegt werden, nach welcher Zeit (Sekunden) die Kommunikation zwischen SOM (ODBC-Treiber) und SAS (ODBC-Server) mit einem „Timeout“-Fehler abgebrochen werden soll. Die Voreinstellung beträgt 15 Minuten (900 Sekunden). Falls bei langlaufenden Berichten (oder bei hoher Serverlast) entsprechende ODBC-Fehlermeldungen auftreten (siehe Ereignisanzeige von Windows), sollte der Wert dieses Parameters versuchsweise erhöht werden.

5.1.2.3 Einstellungen für Faxdrucker

Über diesen Parameter können Drucker als „Faxdrucker“ gekennzeichnet werden. Durch diese Kennzeichnung werden sie im ERP-System wie ein Faxgerät behandelt. In der Regel werden solche „Faxdrucker“ durch entsprechende Faxlösungen von Drittherstellern bereitgestellt.

fax.printerNames

Als Wert sind der oder die Namen der jeweiligen Drucker anzugeben, ggf. getrennt durch ein „|“ Zeichen.

Beispiel:

fax.printerNames=MeinFaxDrucker

oder:

fax.printerNames=FaxDrucker1|FaxDrucker2

5.1.2.4 Einstellungen für den Mail Server

Die nachfolgend beschriebenen Parameter dienen der Konfiguration des vom SOM verwendeten SMTP-Servers.

mail.smtp.host

Hier ist der (vollständige) Hostname des Mailservers einzutragen, der von dem SOM zum Versenden von E-Mails benutzt werden soll.

mail.smtp.user

Wenn der Mailserver so konfiguriert ist, dass eine Authentifizierung notwendig ist, kann über diesen Parameter der Benutzername spezifiziert werden.

mail.smtp.pwd

Wenn der Mailserver so konfiguriert ist, dass eine Authentifizierung notwendig ist, kann über diesen Parameter das Kennwort spezifiziert werden.

mail.smtp.from

Einige Mailserver erlauben nicht, Mails mit einer beliebigen Absenderadresse („From“) zu versenden. In diesem Fall kann über diesen Parameter eine Adresse spezifiziert werden, die von dem Mailserver akzeptiert wird. In der Regel muss diese Adresse zu dem angemeldeten Benutzer (mail.smtp.user) passen. Wenn diese Option verwendet wird, wird die spezifizierte Absenderadresse bei allen versendeten Mails eingetragen, unabhängig davon, welche Absenderadresse in den jeweiligen Ausgabeaufträgen verwendet wird.

mail.smtp.port

Falls der Mailserver nicht den Standardport (25) verwendet, kann über diesen Parameter ein abweichender Wert spezifiziert werden.

5.1.2.5 Einstellungen für die Berichts-Prozessoren

Die nachfolgend beschriebenen Parameter dienen der Konfiguration der vom SOM verwendeten „Berichts-Prozessoren“.

rptproc.poolsize

Mit diesem Parameter kann die maximale Anzahl von parallelen „Berichts-Prozessoren“ eingestellt werden. Voreingestellt sind 3 Prozessoren (entspricht 3 Windows-Prozessen). Im Allgemeinen stellt dieser Wert einen guten Kompromiss zwischen Durchsatz und Ressourcenbedarf dar und sollte nur erhöht werden, wenn die Leistungsfähigkeit der beteiligten Server (SOM, SAS, ODBC-Server, Datenbank) dies erlaubt.

rptproc.minprio
rptproc.maxprio

Mit rptproc.minprio.i=Pmin bzw. rptproc.maxprio.i=Pmax wird für den Berichts-Prozessor i eine minimale bzw. maximale Auftragspriorität festgelegt, die er bearbeiten darf, wobei die Werte von Pmin bzw. Pmax zwischen 1 und 100 (jeweils inklusive) liegen müssen.

In den Anwendungen (d. h., auf der Oberfläche) werden Prioritäten durch die Werte „1“ (höchste Priorität) bis „9“ (niedrigste Priorität) ausgedrückt. Intern bzw. auf dem SOM werden jedoch die Werte „1“ (niedrigste Priorität) bis „100“ (höchste Priorität) verwendet. Mit folgender Tabelle können die Werte ineinander umgerechnet werden:

Anwendungen (Oberfläche)	SOM (intern)
1 (höchste Priorität)	100
2 (hohe Priorität)	88
3 (hohe Priorität)	75
4 (mittlere Priorität)	63
5 (mittlere Priorität)	50
6 (mittlere Priorität)	38
7 (niedrige Priorität)	25
8 (niedrige Priorität)	13
9 (niedrigste Priorität)	1

Beispiel 1:

rptproc.poolsize=4
rptproc.minprio.1=100
#rptproc.maxprio.1=100

Von den insgesamt 4 Prozessoren ist „Prozessor 1“ für Aufträge mit Priorität 100 (höchste Priorität) reserviert. Für die Prozessoren 2, 3 und 4 gelten die Defaults (rptproc.minprio.x=1 und rptproc.maxprio.x=100). Damit werden Jobs mit den Prioritäten 1-99 nur auf die Prozessoren 2, 3 und 4 verteilt; Aufträge mit der Priorität 100 können hingegen durch alle vier Prozessoren bearbeitet werden.

Beispiel 2:

rptproc.poolsize=3
rptproc.minprio.1=2
rptproc.minprio.2=2
#rptproc.minprio.3=1
rptproc.maxprio.3=1

Von den insgesamt 3 Prozessoren ist „Prozessor 3“ für Jobs mit Priorität 1 (niedrigste Priorität) reserviert. Die Prozessoren 1 und 2 sind so konfiguriert, dass sie keine Aufträge mit Priorität 1 bearbeiten. Damit können diese Aufträge nur von Prozessor 3 bearbeitet werden.

Hinweis:
Die Prozessoren werden nicht nur zur Ausgabe, sondern auch zur Analyse von *.RPT Dateien benötigt. Solche Anfragen werden beispielsweise von der Anwendung „Berichtsdokumente ausgeben“ benutzt um Informationen über die, in einem Bericht verwendeten Parameter zu bekommen. Diese Anfragen haben zwar die höchste Priorität (100), können aber auch nur dann bearbeitet werden, wenn ein entsprechender Prozessor frei ist. Wenn alle Prozessoren belegt sind, dann werden auch die entsprechenden Anwendungen entsprechend verzögert. Um Verzögerungen durch langlaufende Berichte zu vermeiden, sollte mindestens ein Prozessor für Aufträge mit Priorität 100 reserviert werden (siehe Beispiel 1), zudem sollte im ERP-System bei Ausgabeaufträge die Priorität 100 möglichst nicht vergeben werden.

rptproc.reportcache

Jeder Berichts-Prozessor verfügt über einen internen (LRU-)Cache für Berichtsvorlagen (*.rpt). Mit diesem Parameter kann festgelegt werden, wie viele Berichtsvorlagen in diesem Cache maximal gespeichert werden sollen. Voreingestellt sind 10 Berichtsvorlagen. Im Allgemeinen stellt dieser Wert einen guten Kompromiss zwischen Zugriffszeit und Speicherverbrauch dar und sollte nur erhöht werden, wenn der verfügbare Hauptspeicher dies erlaubt.

rptproc.checkTableMask

Über diesen Parameter kann spezifiziert werden, dass die Berichtsvorlagen vor ihrer Benutzung auf Aktualität (bezüglich Datenbankänderungen) geprüft werden sollen. Wenn diese Option genutzt wird und die Berichtsvorlage nicht mehr mit dem Datenbankschema übereinstimmt, wird die Berichtserzeugung mit einem Fehler abgebrochen. Es wird zwischen verschiedenen Arten von Änderungen unterschieden. Welche Arten von Änderungen zum Abbruch führen sollen, kann durch eine Bitmaske spezifiziert werden. Die nachfolgende Tabelle zeigt die Zuordnung zwischen Änderung und Bitwert[16]:

Fehler (Änderung)	Wert
DATABASENOTFOUND	0x00000001
SERVERNOTFOUND	0x00000002
SERVERNOTOPENED	0x00000004
ALIASCHANGED	0x00000008
INDEXESCHANGED	0x00000010
DRIVERCHANGED	0x00000020
DICTIONARYCHANGED	0x00000040
FILETYPECHANGED	0x00000080
RECORDSIZECHANGED	0x00000100
ACCESSCHANGED	0x00000200
PARAMETERSCHANGED	0x00000400
LOCATIONCHANGED	0x00000800
DATABASEOTHER	0x00001000
NUMFIELDSCHANGED	0x00010000
FIELDOTHER	0x00020000
FIELDNAMECHANGED	0x00040000
FIELDDESCCHANGED	0x00080000
FIELDTYPECHANGED	0x00100000
FIELDSIZECHANGED	0x00200000
NATIVEFIELDTYPECHANGED	0x00400000
NATIVEFIELDOFFSETCHANGED	0x00800000
NATIVEFIELDSIZECHANGED	0x01000000
FIELDDECPLACESCHANGED	0x02000000

Warnung:

Es wird nicht empfohlen diese Option zu verwenden, da häufig auch „harmlose“ Änderungen als Fehler erkannt werden.

5.1.2.6 Spezielle Parameter für die Fehlersuche

Die nachfolgend beschriebenen Parameter können für die Eingrenzung von Fehlern bzw. ein erweitertes „Logging“ verwendet werden. Sie sind nicht für den Produktivbetrieb gedacht und können beispielsweise aufgrund der ausgegebenen Datenmenge die Verarbeitungsgeschwindigkeit stark beeinträchtigen.

Die hier aufgeführten Einträge sind in der Konfigurationsdatei bereits eingetragen, aber durch ein „#“ Zeichen am Zeilenanfang deaktiviert (auskommentiert). Eine Aktivierung kann daher einfach durch das Entfernen dieses Zeichens erfolgen.

com.cisag.sys.www.daemon.connection.traceProcessingTime=true

Durch diese Option wird der integrierte Web-Server veranlasst, jeden Zugriff zu protokollieren, dabei wird die URI und die benötigte Zeit ausgegeben.

javax.net.debug=ssl:handshake

Über diese Option wird die SSL/TLS Implementierung veranlasst, Informationen über den Verbindungsaufbau (inkl. Austausch der Zertifikate) auszugeben.

mail.debug=true

Mit dieser Option kann die Kommunikation zwischen SOM und Mail-Server überwacht werden.

5.1.3 Schriftarten

Wenn in den Berichten bzw. Belegen besondere Schriftarten oder Zeichensätze verwendet werden, müssen diese auch auf dem SOM-Computer installiert werden. Dies gilt auch für die Unterstützung von speziellen Unicode-Unterbereichen.

5.1.4 Microsoft Windows-Registrierung

Die Konfigurationsdaten für den Windows Dienst, den ODBC-Treiber sowie die „Crystal Reports Print Engine“ werden in der Registrierungsdatenbank („Registry“) von Microsoft Windows gespeichert. Diese Daten werden durch das Installationsprogramm automatisch gesetzt und sollten nicht verändert werden. Für den Fall, dass dies in Ausnahmefällen doch notwendig werden sollte, werden hier einige ausgewählte Einträge beschrieben.

Hinweis:
Wenn Sie Änderungen an der Windows Registrierung vornehmen wollen, beachten Sie unbedingt die Hinweise in der Knowledge-Base von Microsoft (Artikel 256986).

5.1.4.1 SOM Dienst

HKLM\SYSTEM\CurrentControlSet\Services\somsvc\Parameters

Durch den Parameter CommandLine=… wird die Kommandozeile zum Starten des SOMs festgelegt. Falls notwendig, kann hier der Pfad zu dem installierten JDK/JRE direkt angegeben und/oder zusätzliche Parameter an die JVM übergeben werden.

5.1.4.2 Crystal Reports Print Engine

HKLM\SOFTWARE\Crystal Decisions\9.0\Crystal Reports\Export\PDF

Durch den Parameter ForceLargerFonts=1 wird Crystal Reports veranlasst, bei der Generierung von PDF-Dateien die gleiche Schriftgröße zu verwenden, wie dies auch bei einer Ausgabe auf einem Drucker der Fall wäre. Wenn man diesen Parameter löscht oder den Wert auf „0“ setzt, verhält sich Crystal Reports wie in früheren Versionen und verwendet in PDF-Dateien eine reduzierte Schriftgröße.

5.2 SAS und System

Damit der SOM von den SAS eines Systems genutzt werden kann, sind folgende Konfigurationsschritte notwendig:

Der SOM muss dem System durch eine „ERP-System-Output-Manager-Verbindung“ in der Anwendung „Systemcockpit“ bekannt gemacht werden.
Für den SOM ist ein Zertifikat zu erstellen (dieses muss sowohl im *.pfx als auch im *.jks Format vorliegen).
Für den SOM ist auf dem System ein Benutzer (mit Administratorrechten) einzurichten.
Für den OBDC-Zugriff ist ein dedizierter Server bereitzustellen[17]
Damit die einzelnen Drucker, Faxgeräte bzw. Mail genutzt werden können, müssen sie in der Anwendung „Ausgabegeräte“ angelegt und mit der Anwendung „Berechtigungsrollen“ entsprechenden Berechtigungsrollen zugeordnet werden.

Eine detaillierte Beschreibung der notwenigen Schritte ist in der Installationsdokumentation Installation ERP-System-Output-Manager (SOM) zu finden.

5.2.1 Systemcockpit

Damit die Application-Server eines Systems auf einen SOM zugreifen können, muss dieser dem System bekannt gemacht werden. Hierzu dient der Typ „ERP-System-Output-Manager-Verbindung“ im System-Cockpit.

Der SOM wiederum muss auf die SAS zugreifen können (insbesondere auf *.RPT-Dateien, Knowledge Store und ODBC-Server). Damit dies möglich ist, muss für den SOM ein entsprechender Benutzer eingerichtet und dem System zugeordnet sein.

5.2.1.1 ERP-System-Output-Manager-Verbindung

Für eine „ERP-System-Output-Manager-Verbindung“ sind folgende Werte notwendig:

Server-URI
Verbindungen
ODBC-Ziel-Server

Im Feld „Server-URI“ sind die Werte für Protokoll, Hostname und der Port anzugeben, über die der SOM im Netzwerk erreichbar ist. Diese Werte müssen mit den Angaben in der Konfigurationsdatei des SOMs (com.cisag.sys.www.daemon.baseURI) übereinstimmen.

Über das Feld „Verbindungen“ kann die maximale Anzahl von Verbindungen spezifiziert werden, die ein SAS zu diesem SOM gleichzeitig (parallel) verwenden darf. Der Standardwert ist „5“. In der Regel ist es nicht notwendig, einen abweichenden Wert zu verwenden. In folgenden Fällen kann es aber sinnvoll sein:

Wenn mehr als ein SOM verwendet wird, entscheidet der größte Wert, welcher SOM zum Parsen von *.RPT-Dateien verwendet wird.
Wenn sehr viele Benutzer mit den Anwendungen „Berichte“ oder „Berichtsdokumente ausgeben“ arbeiten.
Über den Wert „0“ lässt sich die Verwendung eines SOMs deaktivieren.

Mit dem Feld „ODBC-Ziel-Server“ ist es möglich, einen bestimmten SAS als speziellen ODBC-Server zu verwenden. Ohne diese Angabe schickt der SOM seine ODBC-Anfragen immer an den SAS, von dem er den betreffenden Ausgabeauftrag erhalten hatte.

Warnung:
Das Neuerstellen, Löschen oder Ändern einer „ERP-System-Output-Manager-Verbindung“ wird erst nach dem Neustart der SAS wirksam. Es sollten nach einer Änderung immer alle SAS neu gestartet werden, damit alle SAS eine gemeinsame Datenbasis verwenden.

5.2.1.2 Application-Server

Jeder SAS, der die ODBC-Anfragen eines SOMs entgegennehmen soll, sollte für den „unbeschränkten ODBC-Zugriff“ konfiguriert sein. Ferner sollte auch die Anzahl der Datenbankverbindungen „ausreichend“ bemessen werden. Für jeden Berichts-Prozessor eines SOMs sollten 3 Datenbankverbindungen zur Verfügung stehen. In der Standardkonfiguration arbeitet ein SOM mit bis zu 3 Berichts-Prozessoren gleichzeitig, sodass allein hierfür 9 Datenbankverbindungen (pro SOM) benötigt werden. Als „Sicherheitsreserve“ sollten 3 weitere Datenbankverbindungen vorgesehen werden. Wenn der SAS zusätzlich noch andere Aufgaben erledigen und/oder interaktive (ODBC-) Benutzer bedienen soll, dann müssen natürlich noch weitere Datenbankverbindungen zur Verfügung gestellt werden.

In den Fällen, in denen der SOM *.RPT-Dateien lädt, Dateien im Knowledge Store ablegt oder Benachrichtigungen verschickt, werden auf dem betroffenen SAS ebenfalls Datenbankverbindungen benötigt. Wobei (je)der SOM pro Zugriffsart maximal nur eine Datenbankverbindung benötigt. Es sollte daher reichen, (pro SOM) 3 Datenbankverbindungen für die Repository-Datenbank und jeweils eine Datenbankverbindung pro OLTP-Datenbank zu reservieren.

5.2.1.3 Benutzer

Damit der SOM auf die SAS zugreifen kann, muss ein Benutzer erfasst werden. Dabei sollte als Typ der Wert „Server“ ausgewählt werden. Dies stellt sicher, dass unter diesem Konto keine Dialog-Anwendungen gestartet werden können und sorgt gleichzeitig dafür, dass dadurch keine Benutzerlizenz „verbraucht“ wird.

In der Tabelle „Identifikationen“ muss das Zertifikat[18] importiert werden, welches für den SOM ausgestellt und in dessen Konfigurationsordner abgelegt wurde.

Hinweis:
Wenn mehrere SOMs verwendet werden, können diese einen gemeinsamem Benutzer verwenden. Es reicht, diesem Benutzer die Zertifikate der jeweiligen SOMs zuzuordnen. Bei diesem Vorgehen verliert man aber die sonst vorhandene Eindeutigkeit der Benutzernamen, was eventuell bei einigen Meldungen oder Anzeigen stören könnte.

5.2.1.4 Benutzergruppe

Der „SOM-Benutzer“ benötigt Administrator-Rechte und muss deshalb der Benutzergruppe „ADMINISTRATORS“ zugefügt sein.

5.2.1.5 System

Der „SOM-Benutzer“ muss dem System als „Mitarbeiter“ (Lizenztyp) mit „Vollzugriff (Zugriffsmodus) zu geordnet sein.

5.2.2 Ausgabegeräte

Auf einem SOM können Drucker und Faxgeräte zur Laufzeit beliebig hinzugefügt oder entfernt werden, ohne dass dazu der SOM oder die SAS neu gestartet werden müssen. Um Drucker bzw. Faxgeräte nutzen zu können, müssen sie dort jedoch einem „Ausgabegerät“ zugeordnet sein.

Mit der Anwendung „Ausgabegeräte“ können Ausgabegeräte anlegt und ihnen (jeweils genau ein) Drucker, Faxgerät oder E-Mail-Gateway eines SOMs zugeordnet werden.

5.2.3 Berechtigungsrollen

Mithilfe der Anwendung „Berechtigungsrollen“ sind die Zugriffsberechtigungen auf die Ausgabegeräte zu konfigurieren.

5.2.3.1 Ausgabegeräte

Ausgabegeräte können von Benutzern nur dann verwendet werden, wenn sie dazu berechtigt wurden. Über den Karteireiter „Weitere Objekte“ in der Anwendung „Berechtigungsrollen“ können Ausgabegeräte einer Berechtigungsrolle zugeordnet werden.

5.3 Einbinden von Faxlösungen

Es besteht auch die Möglichkeit, Faxlösungen von Drittherstellern einzubinden. Voraussetzung hierfür ist, dass diese Faxlösungen einen so genannten „Faxdrucker“ bereitstellen, der für den Serverbebetrieb geeignet ist. Der Faxdrucker muss in der Lage sein, alle notwendigen Parameter (insbesondere die Faxnummer) aus dem zu versendenden Dokument zu extrahieren. Er darf hierzu keine Dialogfenster verwenden.

Um einen solchen Faxdrucker als „Fax“ verwenden zu können, muss dieser in der Konfigurationsdatei des SOMs entsprechend gekennzeichnet werden (siehe Einstellungen für Faxdrucker).

Die zweite Voraussetzung ist, dass alle Parameter, die der Faxdrucker benötigt, in dem auszugebenden Dokument stehen und zusammen mit diesem „gedruckt“ werden. Typischerweise sehen die Faxlösungen vor, dass die Parameter durch zusätzliche Zeichenketten eingerahmt werden können, um sie eindeutig erkennbar zu machen[19]. Belegdokumente und Berichte, die über einen Faxdrucker versendet werden sollen, müssen deshalb entsprechend gestaltet werden.

Um die Faxsoftware diesbezüglich zu unterstützen, stellt der SOM eine Reihe von Parametern („Systemvariablen“) bereit, die mit Hilfe von Crystal Reports ausgegeben werden können (siehe Berichte entwickeln). Zu diesen Parametern zählen alle fax-spezifischen Ausgabeeinstellungen des betreffenden Ausgabeauftrages:

Systemvariable	Wert
FAX_RECIPIENT_NUMBER	Entspricht dem Feld „Faxnummer“ in den Ausgabeneinstellungen für das Ausgabemedium „Fax“.
FAX_TRANSMITTING_STATION_ID	Entspricht dem Feld „Absenderkennung“ in den Ausgabeneinstellungen für das Ausgabemedium „Fax“.
FAX_SCHEDULE_ACTION	Entspricht dem Feld „Senden“ in den Ausgabeneinstellungen für das Ausgabemedium „Fax“. Mögliche Werte sind: • Sofort („now“) • Nicht früher als („specific-time“) • Zur ermäßigten Zeit („discount-time“)
FAX_SCHEDULE_TIME	Entspricht dem Feld „Sendezeitpunkt“ in den Ausgabeneinstellungen für das Ausgabemedium „Fax“. Diese Variable ist nur dann relevant, wenn die Systemvariable „FAX_SCHEDULE_ACTION“ den Wert „specific-time“ (Nicht früher als) hat.
FAX_DELIVERY_REPORT_ADDRESS	In diesem Feld wird die Email-Adresse des Benutzers übertragen. Diese Variable kann durch die Faxlösung genutzt werden, um eine automatische Sendebestätigung an den Benutzer zu erzeugen.
FAX_CONTROL_SEQUENCE	Entspricht dem Feld „Steuersequenz“ in den Ausgabeneinstellungen für das Ausgabemedium „Fax“. Diese Variable kann genutzt werden, um der Faxlösung beliebige Daten zu übergeben.

6 Verwaltung und Überwachung

6.1 ERP-System-Output-Manager

Der integrierte Web-Server des SOMs erlaubt den Zugriff auf bestimmte Statusinformationen des SOMs. Folgende URIs stehen zur Verfügung:

URI	Information
/conf	Zeigt alle Java System Properties sowie die Einstellungen aus der Konfigurationsdatei des SOMs an.
/printers	Listet alle installierten Ausgabegeräte und ihren aktuellen Status auf. Über Hyperlinks können die aktuellen Aufträge der jeweiligen Ausgabegeräte eingesehen werden.
/jobs	Listet die Aufträge aller Ausgabegeräte gemeinsam auf. Es werden zuerst die aktiven und dann die erledigten (Historie[20]) Aufträge angezeigt.
/logs	Bietet Zugriff auf die Log-Dateien des SOMs

6.2 SAS und System

6.2.1 Ausgabeaufträge

Mit der Anwendung Ausgabeaufträge können die Status der erzeugten Ausgabeaufträge abgefragt werden. Neben dem generellen Status („In Bearbeitung“, „Abgeschlossen“, …) können über „Eigenschaften“ auch detaillierte Informationen zu einem Ausgabeauftrag, seinen Parametern oder seinem Status (inkl. Fehlermeldungen) eingesehen werden.

Die Anwendung ermöglicht es auch, einzelne Ausgabeaufträge zu kopieren und damit erneut auszugeben.

6.2.2 Ausgabegeräte

Neben der Anlage und Pflege von Ausgabegeräten erlaubt diese Anwendung auch, einzelne Ausgabegeräte „anzuhalten“. Nachdem ein Ausgabegerät angehalten wurde, werden nachfolgende Ausgabeaufträge nicht mehr sofort an den SOM weitergeleitet, sondern solange zwischengespeichert, bis die Sperre des Ausgabegerätes wieder aufgehoben wurde.

6.2.3 Ausgabegerätestatus abfragen

Mit dieser Anwendung können die Status der angelegten Ausgabegeräte abgefragt werden (z. B. Drucker angehalten, SOM nicht erreichbar, kein Papier etc.).

Hinweis:
Die Anzeige wird nicht automatisch aktualisiert, sondern nur über den „Aktualisieren“-Button in der Symbolleiste.

Hinweis:
Der angezeigte Druckerstatus entspricht dem Status, wie er auch unter Microsoft Windows angezeigt wird. Der tatsächliche Status des Druckers kann aber davon abweichen. Abhängig von Drucker, Druckertreiber und Anschlussart kann es vorkommen, dass die Statussynchronisation zwischen Drucker und Windows mit starker Verzögerung bzw. erst mit einem der nächsten Aufträge erfolgt.

6.2.4 Systemcockpit

6.2.4.1 ERP-System-Output-Manager-Verbindung

Im Karteireiter „Aufträge“ werden die aktuellen Aufträge des zugehörigen SOMs angezeigt. Die Anzeige entspricht genau der Anzeige, wie sie auch der SOM über die URI „/jobs“ bereitstellt.

Hinweis:
Die Anzeige der Aufträge ist nur möglich, wenn Sie Zugriff auf den ERP-System-Output-Manager haben (per https auf die Server-URI) und Ihr Client-Zertifikat auch vom ERP-System-Output-Manager akzeptiert wird.

7 Vorgehensweisen

7.1 Drucker installieren

Hinweis:
Das Hinzufügen eines Druckers kann in der Regel im laufenden Betrieb erfolgen, d.h. es braucht weder der SOM noch der Application-Server neu gestartet werden. Abhängig von dem Installationsprogramm des Druckers kann dieses aber möglicherweise nach einem Neustart des Computers verlangen. Vorsicht ist ebenfalls geboten, wenn bei der Installation des neuen Druckers gleichzeitig die Treiber von bereits vorhandenen Druckern aktualisiert werden (siehe Abschnitt „Druckertreiber installieren oder aktualisieren“).

Hinweis:
Installieren Sie die Drucker möglichst direkt (lokal) auf dem SOM Computer. Bei Verwendung von Druckern, die an einem anderen Druckserver angeschlossen sind, kann es zu Leistungseinbußen kommen – speziell wenn es sich um eine Vielzahl solcher Drucker handelt.

Hinweis:
Nutzen Sie nur die neusten Druckertreiber und achten Sie darauf, dass diese Treiber für das von ihnen genutzte Betriebssystem durch Microsoft zertifiziert wurden. Die Verwendung von alten, falschen oder inkompatiblen Treibern kann zu Leistungseinbußen und/oder Stabilitätsproblemen führen.

Installieren Sie zunächst den Drucker unter Windows gemäß der Anleitung des Herstellers bzw. Installationsprogramms
Prüfen Sie, ob der Drucker unter Windows einwandfrei arbeitet (z.B. Testseite drucken)
Prüfen Sie, ob der Drucker vom SOM erkannt wird (URI „/printers“)
Starten Sie die Anwendung „Ausgabegeräte“
Wählen Sie „Neu“
Wähen Sie in dem Dialog „Ausgabemedien suchen“ im Feld „Ausgabemedium“ den Wert „Drucker“ aus und drücken Sie dann auf „Start“.
Wählen Sie aus der Liste mit den angezeigten Druckern den neuen Drucker aus
Geben Sie dann in dem Feld „Ausgabegerät“ einen Namen für das neue Ausgabegerät an
Prüfen Sie die anderen Felder und passen Sie diese gegebenenfalls an
Drücken Sie auf „Speichern“
Prüfen Sie mit der Anwendung „Ausgabegerätestatus abfragen“, ob das neue Ausgabegerät dort korrekt aufgelistet wird.
Prüfen Sie beispielsweise mit der Anwendung „Berichtsdokumente ausgaben“, ob die Ausgabe auf dem Gerät korrekt funktioniert.

7.2 Drucker entfernen

Hinweis:
Bevor sie einen Drucker entfernen, vergewissern Sie sich, dass dieser nicht mehr benutzt wird. Prüfen Sie, welche Ausgabegeräte diesen Drucker benutzen. Wenn Sie die Ausgabegeräte nicht löschen möchten, weisen Sie diesen über das Feld „URI“ einen anderen Drucker zu. Falls Sie auch die Ausgabegeräte löschen möchten, prüfen Sie vorher, ob diese innerhalb von „Belegdokumentvorlagen“ und/oder „Benutzereinstellungen“ verwendet werden.

Hinweis:
Vergewissern Sie sich ebenfalls, dass der Drucker auf dem SOM-Computer nicht in Benutzung ist. Auch in der Warteschlange des SOM sollten sich keine Aufträge für den Drucker mehr befinden. Die Deinstallation eines Druckers, während ein Prozess darauf zugreift, kann zum Abbruch des Prozesses oder anderen schweren Fehlern führen.

Wenn Sie auch die zugehörigen Ausgabegeräte löschen möchten, beachten Sie bitte den ersten Hinweis und suchen Sie bitte nach den Verwendungen dieser Ausgabegeräte um diese vorher zu ändern oder ebenfalls zu löschen. Löschen Sie dann das Ausgabegerät über die Anwendung „Ausgabegeräte“
Löschen Sie den Drucker auf dem SOM-Computer
Prüfen Sie, ob die Löschung des Drucker vom SOM erkannt wurde (URI „/printers“)
Prüfen Sie mit der Anwendung „Ausgabegerätestatus abfragen“, ob die gelöschten Ausgabegeräte dort korrekt entfernt wurden.

Hinweis:
Der letzte Schritt, d.h. der Aufruf der Anwendung „Ausgabegerätestatus abfragen“, sollte grundsätzlich immer durchgeführt werden, wenn auf dem SOM eine Änderung an den Druckern bzw. ihren Eigenschaften erfolgt ist. Nur auf diese Weise wird sichergestellt, dass die auf den ERP-System-Application-Servern gespeicherte Informationen dem aktuellen Stand des SOMs entsprechen.

7.3 Druckertreiber installieren oder aktualisieren

Hinweis:
Das Austauschen oder Aktualisieren eines Druckertreibers während ein Prozess gerade darauf zugreift, kann zum Abbruch des Prozesses oder anderen schweren Fehlern führen. Da der SOM normalerweise die Drucker ständig in Benutzung hat, sollte ein solcher Austausch bzw. die Aktualisierung eines Druckertreibers nicht im Betrieb erfolgen.

Hinweis:
Bitte beachten Sie auch, dass die Anmeldung auf den SOM Computer per „Remote Desktop“ dazu führen kann, dass die Client-Drucker sowie ihre Treiber temporär auf dem SOM-Rechner installiert bzw. aktualisiert werden. Es sollte daher unbedingt darauf geachtet werden, dass bei „Remote Desktop“-Zugriffen auf den SOM die lokalen Drucker des Clients nicht aktiviert sind (sicherheitshalber sollte dies per Gruppenrichtlinie gesteuert werden).

8 Fehlerdiagnose

8.1 Log-Dateien

Der SOM speichert seine Log-Dateien in dem Unterverzeichnis „logs“. In diesem Verzeichnis werden zwei getrennte Log-Dateien geführt. Die erste Datei, „somsvc.log“ wird von dem Windows Dienst genutzt, über den der SOM ausgeführt wird. In dieser Datei werden alle Ausgaben und Fehlermeldungen protokolliert, die vor bzw. während des Starts des eigentlichen SOMs auftreten[21]. Nach dem Start nutzt der SOM dann die Dateien „som-0.log“ bis „som-4.log“ für die regulären Ausgaben und Fehlermeldungen. Diese Dateien arbeiten „rollierend“, d.h. alle Ausgaben werden solange als Ende der Datei „som-0.log“ angehängt, bis eine Maximalgröße (1MB) erreicht wird. Bei Überschreiten der Maximalgröße wird die Datei „som-0.log“ in „som-1.log“ umbenannt (und vorher „som-1.log“ in „som-2.log“ usw.) und dann wieder mit einer leeren Datei „som-0.log“ fortgesetzt. In der Datei „som-0.log“ sind also immer die jüngsten Meldungen und in der Datei „som-4.log“ immer die ältesten Meldungen gespeichert.

In den Dateien „som-x.log“ protokolliert der SOM nicht nur seine eigenen Meldungen, sondern auch die Fehler, die durch die „Crystal Reports Report Engine“ (s. unten) bzw. den ODBC-Treiber festgestellt wurden.

Der Zugriff auf alle in dem Verzeichnis „logs“ gespeicherten Log-Dateien kann auch per Browser (https://som-hostname:8443/logs) erfolgen.

8.1.1 Fehlercodes von Crystal Reports

Die nachfolgende Tabelle listet ausgewählte[22] Fehlercodes der „Crystal Reports Report Engine“ und deren Bedeutung auf.

Fehlercode	Beschreibung
513 (INVALIDPRINTER)	Der Druckertreiber für den spezifizierten Drucker konnte nicht gefunden werden.
525 (BADREPORTFILE)	Die Datei mit der Berichtsvorlage (*.rpt) ist fehlerhaft bzw. kann nicht gelesen werden.
536 (DATABASELOGON)	In der Kommunikation mit dem ODBC-Server ist ein Fehler aufgetreten. Es sollte zusätzlich die Ereignisanzeige von Windows und die Log-Datei des zugehörigen ODBC-Servers geprüft werden. Typische Ursachen sind: · ODBC-Server nicht erreichbar · kein oder ungültiges Zertifikat · Probleme mit dem TEMP-Verzeichnis[23]
998 (INTERNALERROR)	Dieser Fehlercode kennzeichnet (Programmier-) Fehler innerhalb der Print Engine. Ein solcher interner Fehler kann beispielsweise auftreten, wenn über den ODBC-Treiber keine Verbindung zum ODBC-Server aufgebaut werden konnte (siehe Ereignisanzeige von Windows).

8.2 Ereignisanzeige

Sowohl der SOM Service als auch der ODBC-Treiber nutzen die Ereignisanzeige von Windows für die Ausgabe von Fehlermeldungen.

Die Meldungen des ODBC-Treibers werden auch in den Log-Dateien des SOMs protokolliert und können auch dort eingesehen werden. Insbesondere bei Meldungen, die auf Verbindungsprobleme mit einem ODBC-Server hinweisen, sollte auch immer der jeweilige ODBC-Server auf entsprechende Meldungen (Meldungsprotokolle, Log-Datei) untersucht werden.

[1] Die Application-Server (bzw. Systeme) müssen dabei nicht einmal auf demselben Softwarestand basieren, im Allgemeinen ist es nur notwendig, dass der SOM selbst auf dem neusten Stand ist.

[2] Dies kann beispielsweise als Maßnahme zur Lastverteilung, Erhöhung der Ausfallsicherheit oder aufgrund von örtlichen Gegebenheiten (entfernte Standorte) interessant sein.

[3] Die Anforderungen (Bandbreite, Latenzzeiten etc.) an den Internetzugang hängen dabei stark von der Art und dem Umfang der Nutzung ab. Dabei ist insbesondere auch die Datenübertragung zwischen SOM und ODBC-Server zu berücksichtigen.

[4] Um die für ein Serversystem notwendige Zuverlässigkeit zu gewährleisten, sollten nur solche Druckertreiber verwendet werden, die von dem Betriebssystemhersteller zertifiziert wurden.

[5] Das „Hintereinanderschalten“ von mehreren Druckerservern führt im Allgemeinen zu schlechterer Leistung (höhere Netzwerkbelastung, längere Antwortzeiten).

[6] Die Faxlösung von Microsoft erlaubt über ein so genanntes „Fax Service Provider“ API auch das Einbinden spezieller Hard- bzw. Software.

[7] Die integrierte Faxlösung von Windows 2003 kann so konfiguriert werden, dass der jeweilige Semiramis-Benutzer eine E-Mail als Sendebestätigung bzw. Fehlermeldung bekommt. Unabhängig davon können auch die vielfältigen Benachrichtigungsmöglichkeiten der Verarbeitungsaufträge genutzt werden.

[8] Wahlweise in einem Entwicklungsobjekt oder in einem Systemobjekt

[9] Die integrierte „Print Engine“ entspricht funktional der englischen Version von Crystal Reports 9 inklusive Service Pack 5 und der zum 19.10.2005 verfügbaren Updates

[10] Es erfolgt eine regelmäßige Überprüfung, ob die gespeicherte Berichtsvorlage noch aktuell ist

[11] Es werden aktuell die Status der letzten 1000 Aufträge gespeichert (unabhängig davon, ob sie im Status „Abgeschlossen“ bzw. „Abgebrochen“ sind).

[12] Typischerweise „\Programme\Semiramis\SOM\1.1\“ bei Computern mit (deutschsprachigen) Windows 2000 bzw. Windows 2003 Server Betriebssystem.

[13] Wenn Browser, SAS und SOM zusammen auf einem Computer installiert werden, also kein Netzwerk benötigt wird, kann als „Hostname“ für SAS und SOM der Name „localhost“ verwendet werden.

[14] Zur schnelleren Auffindbarkeit sind diese Einträge mit dem Kommentar „TODO“ gekennzeichnet, sodass man mit einem Texteditor danach suchen kann.

[15] Im Systemcockpit (ERP-System-Output-Manager-Verbindung) muss im Feld „Server-URI“ daher genau diese Basisadresse eingetragen sein.

[16] Die Angaben entsprechen genau den Werten, wie sie von Crystal Reports („Print Engine“) geliefert werden.

[17] Alternativ ist bei allen SAS der „unbeschränkte ODBC Zugriff“ zu erlauben (nicht empfohlen).

[18] Es genügt der öffentliche Schlüssel aus dem Zertifikat

[19] Durch eine geeignete Schriftfarbe (z.B. weiß) kann man verhindern, dass die Parameter oder die zusätzlichen Zeichenketten nachher auf dem Fax zu sehen sind. Der Text sollte jedoch in einer „Drucker“-Schriftart ausgegeben werden, um Windows daran zu hindern, den Text als Grafik auszugeben.

[20] Die Historie ist auf maximal 1000 erledigte Aufträge begrenzt, ältere Aufträge werden vom SOM automatisch gelöscht.

[21] Ein Beispiel hierfür sind Fehler beim Starten der Java Virtual Machine.

[22] Diese Fehler deuten in der Regel auf eine fehlerhafte Konfiguration, falsche bzw. unvollständige Berichtsparameter oder Kommunikationsfehler mit dem ODBC-Server hin.

[23] In diesem Fall sollte versucht werden, ein Verzeichnis „C:\TEMP“ anzulegen und die Umgebungsvariablen „TMP“ und „TEMP“ auf dieses Verzeichnis zu setzen.

Comarch ERP Enterprise 6.4