Bei den Erweiterten Fuknktionen handelt es sich um modulspezifische Aktionen, bzw. Aktionen, welche die Kern-Funktionalität betreffen. Diese erlauben die Verwaltung und Wartung des Webdesk EWP.
Workflow-Anträge werden in einem Cache zwischengespeichert. Durch Klick auf den Button wird dieser Cache geleert. Beispiel: Zwei Workflow-Engines greifen auf die selbe Datenbank zu. Um beide Engines nach einer Veränderung eines Workflow-Antrages in einen konsistenten Zustand zu bringen, ist es nötig den Workflow-Cache zu aktualisieren.
Im Kalender- aber auch in Journalansichten können Feiertage angezeigt werden (farblich abgesetzt). Diese werden im Jahresprogramm der 6020 definiert. Damit diese Tage nicht immer von Neuem ausgelesen werden müssen, werden diese in einem Cache (Speicher) verwaltet. Werden nun neue Feiertage hinzugefügt und wurden die Feiertage für die ausführende Person bereits ausgelesen, so werden die Daten aus dem Speicher genommen. (Was natürlich kurzfristig zu einer Inkonsistenz der Daten führt. - Diese würde sich aber von alleine nach einer Zeit auflösen.) Will man aber nicht warten so kann man den Speicher auch einfach leeren und die Funktion lädt die Feiertage erneut.
Die Log-Einträge, welche individuell für verschiedene Aktionen und Benutzer in unterschiedlichen Stufen aktiviert werden können, werden in der Datenbank persistiert. Durch betätigen dieses Buttons werden alle alten Log-Einträge aus der Datenbank gelöscht.
Berechtigungen für bestimmte Aktionen werden durch den Administrator an Personen, Gruppen oder Rollen vergeben. Bei jedem Aktionsaufruf durch einen Benutzer wird überprüft, ob dieser auch die nötige Berechtigung besitzt diese Aktion auszuführen. Um die Performance dieser Überprüfung zu erhöhen, werden die Berechtigungen in einem Cache gespeichert. Damit Aktionszuweisungen an eine Person, Gruppe oder Rolle wirksam werden, muß zuvor der Berechtigungs-Cache durch Klick auf den Button geleert werden.
Die Aktionsberechtigungen im Navigations-Menü werden in einem Cache zwischengespeichert. Durch Klick auf den Button "Menü-Cache leeren" wird dieser Cache geleert. Jedes Menü wird für 5000 Sekunden im Cache gehalten bevor es erneuert wird. Wird eine Menü länger als 2000 Sekunden nicht benutzt, wird dieses aus dem Cache entfernt.
Die Übersetzungen der Textbausteine werden in einer XML-Datei im Filesystem des Servers abgelegt. Änderungen an Textbausteinen werden aber nur in der Datenbank festgeschrieben. Damit Änderungen an Textbausteinen wirksam werden, müssen XML-Datei und Datenbank durch Klick auf den Button in einen konsistenten Zustand gebracht werden.
Gesperrte Textbausteine können nicht überschrieben werden. Damit Textbausteine, z.B. bei einem Versionsupdate des Webdesk, neu geschrieben werden können, müssen diese zuvor durch Klick auf den Button entsperrt werden.
Durch betätigen dieses Buttons werden alle Textbausteine in der Datenbank gesperrt. Bei einem Update auf eine aktuellere Version des Webdesk können dadurch die Textbausteine vor ungewolltem Überschreiben geschützt werden.
Durch Klick auf den Button "Neuinitialisierung JobService" wird das gesamte Job-Service neu initialisiert und auf die Ausgangswerte zurückgesetzt.
Einzelne Module können individuell durch Update-Scripts aktualisiert und verändert werden. Diese Scripte sind im jeweiligen Modul im Package "impl.update" zu hinterlegen. In diesem Package befindet sich eine readme.txt mit einer detaillierten Beschreibung wie diese Scripte zu hinterlegen sind. Weiters muss die Property "versionNumber" im applicationContext des Moduls auf die Versionsnummer des Update-Skript gesetzt werden. Durch Klick auf den Button werden die Scripte im Webdesk ausgeführt, ohne dass der Server neu gestartet werden muss.
Dies ist im Regelfall aber nicht nötig, da diese Scripts schon während des Starts des Webdesk's ausgeführt werden.
Der Webdesk R3 verfügt über schiedene Bereiche oder auch Packages [wf, gw, po, ta,..]. Beim Start werden diese, falls so eingestellt (mind. aber einmal), registriert. Die Registrierung legt die in dem Package vorkommenden Aktionen, Sprachbausteine, Updatescripts, .... an. Will man dies händisch nachziehen so kann es hier gemacht werden. Die Einschränkung dient dazu, nicht immer alle Aktionen ausführen zu müssen.
Die Registrierung ist sehr rechenintensiv.
Anzuwenden z.B. bei erweiterten Lizenzen > Module werden ohne Neustart nachgeladen. Beim Registrierungsmodus können folgende Parameter selektiert werden:
Mit dieser Aktion werden alle Module des Webdesk neu registriert. Dabei werden für jedes Modul im Webdesk
Interessanten Aufschluss über den Verlauf der Registrierung bietet die Datei $CATALINA_HOME/webapps/webdesk3/WEB-INF/logs/log4j.log
Achtung: Diese Aktion kann mehrere Minuten in Anspruch nehmen. Der Webdesk ist während dieser Zeit nicht verfügbar!
Es gibt Aktionen welche nach der Durchführung überprüfen, ob die Aktion überhaupt ausgeführt werden darf.
Mit den Log-Einstellungen kann die Funktionsweise der Protokollierung punktgenau festgelegt werden. Es ist möglich festzulegen, bei welchen Usern und bei welchen Bildschirm-Aktionen gelogged werden soll Des weiteren ist es möglich auch festzulegen, welche Programmteile protokollieren sollen.
Wohin die Protokolle geschrieben werden sollen ist über die sogenannten Appender einstellbar. Im Webdesk EWP stehen standardmässig 4 Appender zur Verfügung:
|
Appender |
Beschreibung |
|---|---|
|
Database |
Dieser Appender stellt das komfortabelste Log-Medium dar, hier wird jedes Event in einen Log pro Aktion und User geschrieben. Dieses Log gilt für die gesamte Verweildauer innerhalb einer Aktion (das bedeutet, dass auch das Blättern innerhalb eines Aktion dazuzählt!) Der Nachteil ist, dass diese Protokolierungsart auch die aufwendigste darstellt, da ständig schreibende Datenbankzugriffe erfolgen. |
|
Console |
Dieser Appender schreibt auf die Konsole des Servlet Containers (z.b. Tomcat) in welchem der Webdesk EWP Server abläuft. Es handelt sich hierbei um ein Text-File, dass chronologisch aufgebaut ist. Es ist hier naturgemäss schwierig, Logevents von einzelnen Usern herauszufiltern. |
|
Error-File |
Dieser Appender ist ein spezieller Appender, welcher nur Events vom Typ ERROR oder FATAL entgegennimmt. Das Ziel ist ein File im Webdesk Verzeichnis (webdesk3/WEB-INF/logs/error.log) |
|
Log-File |
Dieser Appender schreibt auf ein Logfile innerhalb der Webdesk Applikation. Im Unterschied zum Console-Log werden in diesem Fall nur Logevents vom Webdesk in dieses Log geschrieben. Während beim Console Appender auch andere Webapplikationen im selben Container auf diesen Appender loggen könnten. (webdesk3/WEB-INF/logs/log4j.log) |
Die Datenbankprotokollieren (Appender = DATABASE) ist ausschliesslich aktiviert, wenn der angemeldete User und die augerufene Aktion zur Protokollierung aktiviert wurden. Hier ist die korrekte Parametrierung des oberen Teils des Formular von wesentlicher Bedeutung!
|
Name des Loggers |
Beschreibung |
|---|---|
|
shark |
Logger für die Workflow Engine |
|
at.workflow.webdesk |
Logger über alle Webdesk Klassen und Services |
|
org.hibernate.SQL |
Logger über alle SQL generierende Klassen im Hibernate |
|
DatabaseManager |
Logger über DODS (O/R Mapping Tool, welches von Shark verwendet wird) |
|
Persistence |
Logger über DAOs von Workflow Engine |
Umgekehrt ist es nicht notwendig, Aktionen oder Benutzer für die Protokollierung zu aktivieren, wenn in andere Medien als die Datenbank gelogged werden soll. (Beispiel: CONSOLE, FILE, ERROR-FILE)
Die Systemparameter stellen Datenobjekte dar, aufgrund welcher der Webdesk konfiguriert wird.
Hier können Sie grundlegende Einstellungen am Webdesk EWP ändern. Dieser Bereich ist ähnlich der Windows Registry - Änderungen haben direkten Einfluss auf die Funktionsweise des Webdesk und sollten mit Vorsicht durchgeführt werden.
Jobs sind periodisch laufende Hilfsprogramme, welche Massendaten auf Grund einer Parametrierung bearbeiten oder synchronsieren. Sie können auch dazu verwendet werden um speziellen Java-Code periodisch oder einmalig auszuführen (als CustomJavaJobs). Das Anwendungsgebiet von Jobs ist mannigfaltig.
Ein Connector dient im Normalfall zum Abgleich bzw. Synchronisation zweier "Seiten" (Quell- bzw. Zielconnector). Z.B. um die Gruppen aus dem Ta-Modul (Zeitwirtschaft) mit den Gruppen aus dem Po-Modul zu synchronisieren. Praktisch finden Connectoren Anwendung, wenn man die Organisationsstammdaten (Personen und Organsationseinheiten) aus dem Zeitwirtschaftssystem importieren möchte.
todo
todo
todo