| Änderungen von: | |
| bis: | |
| Typ: | |
 erste | letzte  |
Das Modul Portal & Organisation bildet eine Basis für den Webdesk EWP. Dieses Modul dient hauptsächlich der Userverwaltung (Mandant, Gruppen, Personen, Rollen) sowie der Menüdarstellung (Gestaltung des Menübaumes), welche durch die unterschiedlichen Aktionen dem Benutzer zugänglich gemacht wird. Mit Hilfe der Aktionen (Konfigurationen, Prozessreferenzen) erhält der User die Möglichkeit, im Webdesk zu arbeiten, Informationen, Anträge aufzurufen etc.
Ein Mandant stellt eine Firma dar. Damit der Webdesk funktionieren kann, muß zumindest ein Mandant angelegt werden. Dieser Mandant bildet sozusagen die Basis, anhand welcher die Oranisationsstruktur bestimmt wird, Gruppen und Personen zugeordnet oder Berechtigungen vergeben werden können. Der Mandantenname darf nur einmalig vergeben werden, damit auch die Zuordnung bei den Gruppen o.a. eindeutig ist, da eine Gruppe oder eine Person nur einem Mandanten zugeordnet werden kann.
In einem großen Konzern können auch mehrere Mandanten vorkommen, was eine klare Trennung innerhalb der Struktur gewährleistet (z.B. Unterteilung eines Mandanten in Teilbereiche). Diesen mehreren Mandanten können beispielsweise eigene Gruppen zugeordnet werden, sie können jedoch auch über gemeinsame Rollen verfügen (z.B. Rolle Vorstand als konzernübergreifende Rolle).
Dem Mandanten können Berechtigungen zugeteilt werden, welche dann für alle Mitarbeiter gelten. Dies erleichtert die Handhabung von allgemeinen Aktionen, wie z.B. Buchen, Gruppenkalender, Monatsjournal, Einsicht in die diversen Formulare, wie z.B. Fehlzeitantrag, Krankmeldung etc.
Die Organisationsstruktur erlaubt eine Einteilung des Mandanten (Unternehmens) in Abteilungen bzw. Gruppen dar. Sie spielt bei der Abfrage div. Listen und Darstellungen eine wesentliche Rolle (z.B. Abfrage eines Anwesenheitstableaus, Managementlisten, ...)
Es stehen folgende Organisationstypen zur Auswahl:
Die hierarchische Aufbauorganisation wird in einem Organigramm des Unternehmens (Mandanten) dargestellt. Diese Hierarchie bestimmt das Verhalten bzw. die Beziehungen der Gruppen (Abteilungen) zueinander. Es wird beispielsweise eine oberste Gruppe in der Organisationsstruktur definiert (z.B. Vorstand), weiters bestimmen übergeordnete bzw. untergeordnete Gruppen (Einteilung im Menüpunkt Gruppen) das Aussehen des Organigramms und das verhalten der Gruppen zueinander. Eine Person kann nur einer hierarchischen Gruppe angehören (jedoch zusätzlich auch noch zu diversen Projekt, losen Gruppen oder Kostenstellenn zugeteilt werden).
Bei den losen Gruppen können diverse Gruppen eingerichtet werden, wie z.B. Teilzeitmitarbeiter, Gleitzeitmitarbeiter, Pauschalisten, o.a. Diese Gruppen werden nur dann im Organigramm angezeigt, wenn sie einem Mandanten zugeordnet sind (auch ein Zuteilung zu Allen Mandanten wäre möglich). Diese losen Gruppen werden im Organigramm (sofern eine entsprechende Einsichtsberechtigung vorhanden ist) unter Diverses oder Lose Gruppen eingesehen werden. Bei den losen Gruppen besteht keine Verbindung der Gruppen untereinander.
Die Projektgruppen funktionieren im Prinzip genauso wie die losen Gruppen. Die Unterteilung zwischen Llosen Gruppen und Projektgruppen erlaubt eine saubere thematische Trennung. Die Projektgruppen können ebenfalls ohne Verbindung zueinander existieren, oder es kann auch eine oberste Gruppe in Struktur definiert werden, was somit eine hierarchische Ordnung herstellt.
Ähnlich funktioniert die Zuteilung von Personen zu diversen Kostenstellen. Eine Person kann ja nur einer hierarchsichen Gruppe angehören, jedoch mehreren Kostenstellen (oder Projektgruppen oder losen Gruppen) zugeordnet sein.
Ein Gruppe (Abteilung, Team, ...) erlaubt die Zusammenfassung von mehreren Personen. Diese Gruppen können in einer hierarchischen Ordnung zueinander stehen (hierarchische Aufbauorganisation). Ihre Beziehungen zueinander werden beispielsweise durch die Bestimmung einer "obersten Gruppe in Struktur" bzw. einer übergeordneten oder untergeordneten Gruppe geregelt. Wird eine übergeordnete Gruppe selektiert, so erscheinen alle anderen Gruppen im Organigramm dieser Gruppe untergeordnet. Eine übergeordnete Gruppe kann mehrere Untergruppen unter sich haben. Die Gruppenkönnen jedoch auch absolut unabhängig zueinander sein, wenn man als Organisationsstruktur eine lose Gruppe / Projektgruppe selektiert. So können Mitarbeiter, welche an bestimmten Projekten zusammenarbeiten sollen in einer solchen Gruppe zusammengefasst werden.
Ebenso kann man die Zuordnung von Mitarbeitern zu einer Gruppe im voraus planen, indem man das Datum der Gültigkeit des jeweiligen Mitarbeiters bestimmt. So kann beispielsweise geplant werden, dass ein Mitarbeiter, welcher der Gruppe A zugeteilt ist ab einem bestimmten Datum (gültig von - bis) zu einer anderen Gruppe zugeteilt werden soll.
Die Mitarbeiter können jeweils nur einer hierarchsichen Gruppe zugeteilt werden, jedoch mehreren losen Gruppen oder Projektgruppen, Kostenstellen.
Den jeweiligen Gruppen können Aktionsberechtigungen zugeordnet werden, oder aber auch bestimmte Rollen. Alle Mitarbeiter dieser Gruppe verfügen dann über diese Aktionsberechtigung, bzw. sind Inhaber der zugeordneten Rolle(n).
Bei der Suche nach einer estimmten Gruppe stehen folgende Suchkriterien zus Auswahl: die Suche nach Namen, Kurznamen, nach Beschreibung oder Mandantenzugeörigkeit (bei mehreren Mandanten).
in der Personenübersicht werden alle Mitarbeiter eines Unternehmens dargestellt. Diese Personen können nur einem Mandanten zugeordnet werden, und einer hierarchischen Gruppe, jedoch mehreren Kostenstellen, Projektgruppen oder losen Gruppen.
In den Personenstammdaten finden sich alle relevanten Informationen zu dem jeweiligen Mitarbeiter, wie z.B. Benutzername, Stammsatznummer, Personalnummer, zu welcher Gruppe der Mitarbeiter zugeordnet ist, welche Rollen er innehat, über welche Aktionberechtigungen er/sie verfügt und auch wer für diesen Mitarbeiter verantwortlich ist.
In den Personenstammdaten können auch neue Gruppenzuordnungen vorgenommen werden, ebenso wie die Vergabe neuer Aktionsberechtigungen oder neuer Rollen.
Möchte man nach einer Person gezielt suchen, so stehen folgende Möglichkeiten zur Auswahl: Suche nach Namen, Vornamen, Benutzernamen, Mandantenzugeörigkeit, Gruppe, nach der Personalnummer oder der TA-ID.
Eine Rolle beschreibt eine Funktion innerhalb eines Unternehmens. Die Rollen ermöglichen es, den Zugriff auf bestimmte Bereiche und Funktionen zu erweitern bzw. einzuschränken. Dies geschieht durch die Auswahl des Kompetenzziels: Einsicht auf ALLE, bestimmte PERSON(en) oder bestimmte GRUPPE(n).
Als Kompetenzziel wird eine Person oder Gruppe verstanden, für welche der Rolleninhaber verantwortlich ist, bzw. welche eingesehen werden darf. Bei Kompetenzziel ALLE werden alle Mitarbeiter des Unternehmens eingesehen. Eine gleichzeitige Zuordnung von mehreren Kompetenzzielen ist möglich.
Die Vererbungsrichtung bestimmt de Richtung bei der Suche nach definierten Rolleninhabern (z.B. in einem Workflow-Verlauf):
Ist bei der Vererbungsrichtung "keine" eingestellt, so wird nur innerhalb der Gruppe bzw. Abteilung nach einem Rolleninhaber gesucht. Die Suche wird nicht außerhalb der Gruppe/Abteilung fortgesetzt. Befindet sich in der Gruppe/Abteilung kein geeigneter Rolleninhaber, wird der Prozess gestoppt.
Ausgehend von der Gruppe in der sich der Antragsteller befindet, wird das Organigramm aufwärts nach Rolleninhaber der Rolle untersucht. Sobald ein Rolleninhaber gefunden wird, wird dieser als Rolleninhaber für den Prozess des Antragstellers verwendet (in diesem Beispiel ist es die Rolle "Vorgesetzter").
Befindet sich in der übergeordneten Gruppe kein Rolleninhaber, wird die Suche so lange fortgesetzt, bis ein Rolleninhaber (in diesem Beispiel wird nach der Rolle "Vorgesetzter" gesucht) gefunden wird:
Ausgehend von der Gruppe in der sich der Antragsteller befindet, wird das Organigramm nach abwärts nach Rolleninhaber der Rolle untersucht. Bei der Krankmeldung wird das Organigramm nach Rolle "Kollege" untersucht, es werden alle, die die Rolle "Kollege" innehaben angezeigt.
Die Stellvertreterregelung wird über die Benutzer-Einstellungen aktiviert: Mein Stellvertreter darf für mich genehmigen > Möchte der Vorgesetzte, dass der Stellvertreter auch Anträge genehmigen darf, muss dieser Parameter auf Ja gestellt werden.
Dieser Parameter beeinflusst alle ab dem Zeitpunkt der Aktivierung gestellten Anträge. Es werden zusätzlich zum Rolleninhaber alle nachgelagerten Rolleninhaber (insofern sie gemäß der Stellvertretungsregelung Stellvertreter sind) als Stellvertreter in die Anträge geschrieben. In diesem Zusammenhang muss derzeit auch die Vererbungsrichtung innerhalb der Rolle beachtet werden.
Die Stellvertreter können unabhängig von der Abteilungszugehörigkeit bestimmt werden, d.h. Mitarbeiter anderer Gruppen oder Abteilungen können ebenso als Stellvertreter bestimmt werden. Sind mehrere Stellvertreter definiert, bestimmt das System, welcher von ihnen den Antrag zuerst zur Bearbeitung bekommt.
Achtung: haben alle die Stellvertreterregelung auf Ja gestellt, bekommen auch alle den Antrag angezeigt !
Der Stellverterter kann zusätzlich zu den Benutzer-Einstellungen ebenfalls in der Prozessdefinition (im Workflow-Verlauf > Auswahl Rolleninhaber bei Prozessstart notwendig) bestimmt werden.
Die Suche nach Rolleninhabern verläuft in 2 Phasen:
Die Suche nach einem Rolleninhaber verfolgt folgende Strategie; nur wenn man diese auch wirklich versteht, kann eine sinnvolle Reihung erfolgen. Das Ranking alleine ist hierfür nicht ausreichend. Siehe diesbezüglich auch hier.
Am Stärksten ziehen immer direkte Zuordnungen: z.B.. Person A hat die Rolle R mit dem Kompetenzziel Person B. Ist diese Zuordnung gegeben, so wird Person A immer an erster Stelle sein (Ausnahme wäre, wenn es mehrere direkte Zuordnungen geben würde, wobei Person A ein niedrigeres Ranking hat.) Das Gleiche gilt auch für Gruppen, d.h. gibt es eine direkte Zuordnung einer Gruppe G zu der Person A, so sind alle Personen der Gruppe G Rolleninhaber mit Kompetenz für die Person B.
Nun gibt es zwei Unterscheidungen
Nachdem die direkten Zuordnungen der resultierenden Menge an Rolleninhabern für eine Person B bestimmt wurden, kommen zusätzlich noch die dynamischen Rolleninhaber hinzu. (zu diesem Zeitpunkt jedoch nur diejenigen, die nicht Alle als Kompetenzziel haben).
Nun werden die zugeordneten Gruppen der Person untersucht. (Hier ist die Vererbungsrichtung zu beachten) Ist eingestellt, dass die hierarchische Gruppe berücksichtigt werden soll, so wird die hierarchische Gruppe untersucht (gibt es Zuordnungen, wobei die hierarchische Gruppe das Kompetenzziel ist) und anschliessend die Vererbungsrichtung, andererseits wird sofort die nächste Ebene betrachtet (je nach Vererbungsrichtung nach oben, unten oder gar nicht).
Gibt es keine direkten Zuordnungen, so werden die dynamischen Rolleninhaber untersucht und der Resultatsmenge hinzugefügt. Anschliessend werden die Gruppen (inklusive der hierarchischen, auch wenn das Flag gesetzt ist, die hierarchische Gruppe nicht zu berücksichtigen) untersucht. Auch hier ist die Vererbungsrichtung zu beachten.
Nun kommen noch die dynamischen Rolleninhaber mit Kompetenzziel Alle hinzu. Anschliessend wird das Resultat auch noch um generelle Rolleninhaber (Auch Kompetenzziel Alle) erweitert.
Das Organigramm bietet eine graphische Übersicht über die Unternehmensstrukturierung (Organisationsstrukturen). Beim Organigrammaufbau können bestimmte Rollen gesucht werden, bzw. die Gruppen mit den dazugehörigen Mitarbeitern angezeigt werden (Mitarbeiter anzeigen oder nur die Gruppen).
Mit dieser Übersicht erhält man sofort den Überblick, wie die Gruppen hierarchisch zueinander stehen. Lose Gruppen bzw. Projektgruppen oder Kostenstellen werden in diesem Organigramm nicht angezeigt. Hierarchische Gruppen, die noch nicht zugeordnet sind (keine übergeordnete Gruppe zugeordnet haben) werden farblich anders dargestellt. Diese können dann direkt über das Organigramm an die gewünschte Stelle zugereiht werden.
Die Aktion stellt eine Definition des Dialoges dar, welchen der User mit dem Webdesk führen kann, d.h. fast alle Tätigkeiten, welche der Benutzer im Webdesk durchführt, lassen sich auf Aktionen zurückführen.
Bei den Aktionen kann man folgende Unterscheidung treffen:
Aktionen - Stammaktionen, welche nicht abgewandelt (konfiguriert) werden können. Ist eine Aktion n icht konfigurierbar, so gibt es keine Möglichkeit, eine Konfiguration zu erstellen.
Konfigurationen - hierbei handelt es sich um Aktionen, welche konfiguriert werden können. Sollte der Bedarf für eine neue Konfiguration eines bestehenden Formulars gegeben sein, so kann diese ohne größeren Aufwand erstellt werden. Dies wäre beispielsweise der Fall, wenn bei bestimmten Gruppen einige Fehlgründe zusätzlich angelegt werden müssen, oder bei anderen Gruppen die Ausgabe der Stamm/Konten-Maske zusätzliche Daten enthalten soll. Hier kann eine neue Konfiguration des Formulars erstellt werden, die nur eine oder einige Gruppen betrifft.
Prozessreferenzen - nach Erstellung eines Prozesses muß dieser mit einer Aktion verknüpft werden, um in den Menübaum eingepflegt zu werden. Man erstellt eine neue Aktion, welche als Prozessreferenz für den jeweiligen Prozess gilt. So kann es beispielsweise für den Prozess Urlaubsantrag eine Prozessreferenz (Aktion) geben, welche ebenfalls Urlaubsantrag heißt. Diese Aktion wird mit dem Prozess verknüpft und gilt auch nur für diesen einen Prozess. Das bedeutet, dass man für jeden Prozess, der erstellt wird, auch eine entsprechende Prozessreferen (Aktion) anlegen und mit diesem verknüpfen muß, da die Prozesse sonst nicht im Menübaum zugeordnet und angezeigt werden können.
Mit einer Aktionsberechtigung wird grundsätzlich bestimmt, wer eine Aktion aufrufen kann (z.B. wer den Gruppenkalender oder die Management-Listen aufrufen darf).
Bei den Aktionsberechtigungen finden sich folgende Berechtigungsarten:
Mit der Mandantenberechtigung wird die Ausführung div. Aktionen für alle Mitarbeiter des Mandanten ermöglicht. Das ist besonders sinnvoll bei Aktionen, wie Buchen, Monatsjournal, Einstellungen oder Paßwort ändern.
Mit der Gruppenberechtigung wird die Ausführung von diversen Aktionen für eine bestimmte Gruppe (Abteilung) ermöglicht. Das nachfolgende Beispiel zeigt eine Gruppenberechtigung der Gruppe "Bereich Ost" (rot markiert).
Weiters ist es möglich, die Gruppenberechtigung auf die untergeordneten Gruppen auszuweiten. Somit erhalten die Untergruppen die gleiche Einsichtserlaubnis wie die übergeordnete Gruppe. In unserem Beispiel werden deshalb auch die Gruppen "Wien" und "Beratung" rot markiert, da diese Untergruppen der Gruppe "Bereich Ost" sind.
Die Personenberechtigung ermöglicht, daß nur eine bestimmte Person die Einsichtserlaubnis für bestimmte Aktionen bekommt.
Die Rollenberechtigung erlaubt die Ausführung div. Aktionen nur für bestimmte Rollen (Teamleiter, Vorgesetzter, ...). Mit dieser Berechtigung wird den Rolleninhabern ermöglicht, z.B. Einsicht in Management-Listen zu bekommen. Es erhalten somit alle Rolleninhaber der gewählten Rolle der Organisation die Rollenberechtigung und Einsichtserlaubnis (gemäß der rollenkompetenz, welche in der Rolle definiert wird > Kompetenzziel Alle, Person oder Gruppe).
Die Vergabe der Berechtigung erfolgt entweder über die Aktion, Person oder die Rolle.
Mit der Einsichtserlaubnis wird das Kompetenzziel definiert, d.h. es wird bestimmt, wer bei der Ausführung einer Aktion eingesehen werden darf. D.h. mit der Einsichtserlaubnis wird defniert, wer z.B. bei den Managementlisten eingesehen werden kann, oder für wen man bestimmte Anträge stellen kann.
Die Einsichtserlaubnis gilt nur für die eigene Person, d.h. bei Auswertungen oder Listen werdennur die eigenen Daten angezeigt, bzw. man darf Anträge nur für sich selbst stellen.
Es darf nur die eigene Abteilung (Team, Gruppe,...) eingesehen werden. Dies ist z.B. beim Gruppenkalender sinnvoll, wo alle Kollegen aus der Abteilung angezeigt werden. Auch bei der Krankmeldung ist diese Einsichtserlaubnis sinnvoll, da dann alle Kollegen aus der eigenen Abteilung angezeigt und somit selektiert werden können.
Die Einsichtserlaubnis gilt für die eigene Abteilung und ihr untergeordnete Abteilungen (Gruppen, ...), d.h. alle Gruppen, die hierarchisch darunter liegen.
Hier wird die Einsichtserlaubnis gemäß der Rollenkompetenz vergeben, welche bei der Rolle bereits definiert wurde (Kompetenzziel Person > es darf nur eine bestimmte Person eingesehen werden kompetenzziel Gruppe > Einsichtserlaubnis für eine bestimmte Gruppe, Einsichtserlaubnis Alle > Einsicht auf alle Mitarbeiter im Unternehmen). Es können mehrere Zuordnungen nebeneinander vorliegen, d.h. der Rolleninhaber sieht eine ganze Gruppe und einzelne Personen aus anderen Gruppen.
Die Einsichtserlaubnis erstreckt sich auf alle Personen des eigenen Mandanten, d.h. es werden auch alle Mitarbeiter angezeigt:
Die Einsichtserlaubnis erstreckt sich auf alle Personen aller Mandanten.
Bei der Gruppen und Personenberechtigung gibt es noch die Möglichkeit, eine spezielle Einsichtserlaubnis auszuwählen. Mit dieser speziellen Einsichtserlaubnis können einzelne Personen (auch mehrere) aus verschiedenen Gruppen oder mehrere Gruppen auf einmal ausgewählt werden. Dieser Parameter erspart sozusagen die mehrmalige Eingabe verschiedener Gruppen, da man mehrere davon auf einmal selektieren kann.
Die Einsichtserlaubnis wird bei der Aktion bestimmt, außer bei der Rollenkompetenz. Bei der Rollenkompetenz wird diese bereits bei der Rolle definiert.
Die Menüstruktur dient dazu, einem Benutzer ein Set an Menüleisten und dazu gehörigen Menüpunkten zur Verfügung zu stellen.
Bei der Erstparametrierung (Neuanlage eines Mandanten) besteht der Menübaum zunächst nur aus den Menüpunkten "Neuer Mandant" und "Logout". Hier müssen alle gewünschten Menüpunkte, welche bestimmten Aktionen, Konfigurationen, Prozessreferenzen entsprechen erst zugeordnet werden. Dies geschieht mit Hilfe einesKontextmenüs, in welchem alle vorhandenen Aktionen aufgelistet sind. Damit der Menübaum dann in der Form bestehen bleibt muß er auch unbedingt abgespeichert werden, da sonst alle Einträge verloren gehen.
Im Menübaum können alle möglichen Aktionen und Prozessreferenzen abgebildet sein, jedoch werden beim User nur jene Menüpunkte angzeigt, für welche er die Aktionsberechtigung inne hat. Es können ebenso mehrere Konfigurationen einer Aktion vorhanden sein, angezeigt werden bei Benutzer lediglich jene, für welche er die Aktionsberechtigung erhalten hat.
Zwecks einer übersichtlichen Aufteilung können die einzelnen Menüpunkte (Aktionen/Konfigurationen/Prozessreferenzen) in eigenenn Foldern zusammengefasst sein. Die Reihung dieser Folder, sowie aller Menüpunkte kann beliebig geändert werden (Verschiebung hinauf, hinuter, an den Beginn, ans Ende).
Bestehen mehrere Mandanten, so hat jeder Mandant einen eigenen Menübaum. Sollen diese Menübäume ähnlich aufgebaut sein, so kann ein bereits angelegter Menübaum als Grundlage für alle anderen Mandanten gespeichert und dann bei Bedarf angepasst werden.
Da der Webdesk EWP mehrsprahig konfiguriert werden kann, bietet der Menüpunkt Sprachen eine Übersicht über die derzeit verfügbaren Sprachen. Der Webdesk EWP wird prinzipiell in 2 Sprachen ausgeliefert: Deutsch und Englisch. Sollen andere Sprachen verfügbar sein, so wird einfach eine neue Sprache angelegt (z.B. Italienisch, Spanisch, Tschechisch...), und alle Textbausteine der eingestellten Hauptsprache kopiert.
Achtung: Das Anlegen einer neuen Sprache kann, abhängig von der Leistung des Rechners, längere Zeit in Anspruch nehmen! Um Performanceprobleme zu vermeiden sollte diese Aktion nur außerhalb der Hauptarbeitszeit vorgenommen werden.
Die Textbausteine einer neu angelegten Sprache sind Kopien der eingestellten Standardsprache. Jeder Textbaustein wird charakterisiert durch einen Schlüssel und einen Wert (bzw. Übersetzung). Weiters wird jeder Textbaustein einer Aktion und einer Sprache zugeordnet. Es gibt jedoch auch Textbausteine, die keiner Aktion zugeordnet sind. Diese beinhalten meist Übersetzungen, die für ein ganzes Modul gültig sind und sich nie oder nur selten ändern. Hierbei handelt es sich beispielsweise um allgemeingültige Übersetzungen für „Mandant“, „Gruppe“ oder „gültig Von“.
Um die Wartung der Textbausteine zu erleichtern wurde folgende Namenskonvention für eine Schlüssel festgelegt: <modul>_<Aktionsname>.<Aktionstyp>_text
|
Schlüssel |
Sprache |
Übersetzung |
|
po_showTextModules.act_lngcode po_showTextModules.act_lngcode |
Deutsch Englisch |
Sprachcode Languagecode |
Um nicht ein und dasselbe Wort in vielen Formularen mehrmals übersetzen zu müssen, wurde das Prinzip der Vererbung eingeführt. Dadurch kann ein Textbaustein die Übersetzung eines anderen Textbausteins „erben“.
"Vererbte" Textbausteine werden von übergeordneten Textbauseinen abgeleitet (vererbt). Bei den übergeordneten Aktionen handelt es sich um Aktionen, in welchen sich der übergeordnete Textbaustein befindet. Textbausteine aus "allgemein" sind keiner bestimmten Aktion zugeordnet und sind im ganzen Modul gültig.
Beispiel: Die deutsche Übersetzung für Client ist mit „Mandant“ voreingestellt. Möchte man diese in allen Formularen auf „Klient“ ändern wäre es nötig, in jeder Aktion die das Wort „Mandant“ enthält, den Textbaustein getrennt zu bearbeiten. Da aber die Textbausteine für „Mandant“ vererbt werden, muss man die Änderung nur einmal im übergeordneten Textbaustein vornehmen.
Neben dem Parameter "Vererbt" gibt es noch die Möglichkeit, die Textbasteine als "Benutzerdefiniert" zu parametrieren. Ein "Benutzerdefinierter" Textbaustein wird nicht vererbt, sondern es liegt eine eigene Übersetzung vor. Dies ist sinnvoll bei Textbausteinen, welche der firmeninternen Ausdrucksweise angepasst sein sollen. Wichtig hierbei ist, dass bei der Bearbeitung der Parameter "Änderung bei Versionswechsel" nicht angehakt ist, da sonst beim nächsten Update alle Änderungen verloren gehen, da die Textbausteine auf den Standardwert zurückgesetzt werden.
TIPP: Wenn man im Menüpunkt Textbausteine in die Filterkriterien [["Sprachkürzel"]], z.B. [[en]] , unter MySql installationen nur [en] eingibt, so sieht man alle noch nicht übersetzten Textbausteine, da diese mit dem Wert angelegt werden. Bearbeitet man nun einen Textbaustein und wählt dann "Speichern&Schliessen" so fällt der Textbaustein aus den Filterkriterien. So ist es einfacher die Textbausteine abzuarbeiten.
Die Änderungen in den Textbausteinen können entweder direkt über den Menüpunkt Textbausteine vorgenommen werden, oder auch über die jeweilige Aktin, im Reiter Textmodule.
Die Anlage neuer Textbausteine bzw. Übersetzungen der bestehenden Textbausteine erfolgt direkt in der jeweiligen Aktion/Konfiguration (Reiter Textmodule).
Bei den Übersetzungen empfiehlt es sich, den Textbaustein durch einen techn. Key austauschen: z.B. Datum > wird zu "Buchen_Datum01". Anschließend wird bei der entsprechenden Sprache die gewünschte Übersetzung eingegeben. So verfährt man mit jedem Textbaustein einer jeder Aktion/Konfiguration, bis alle übersetzt sind. Auch hierbei ist es wichtig, den Flag "Änderung bei Versionswecel" nicht angehakt zu lassen, da die Textbausteine sonst wieder auf den Standardwert gesetzt werden.
Im ersten Schritt müssen in der zu übersetzenden Konfiguration, die Überschriften bzw. Elemente, welche durch einen Textbaustein ersetzt werden sollen, durch einen technischen Key ersetzt werden. Hierbei ist zu beachten, dass die Namenskonvention eingehalten wird: <Name der Konfiguration>_<Nummer des Textbausteins> zB.: kurzjournal_journal01
Achtung: bei Konfigurationen für Statistiken sollte die Übersetzung nicht mehr als 20 Zeichen enthalten.
Die Systemeinstellungen erlauben die Wartung und das Monitoring des Webdesk EWP.
Mit den Schlüsselwerten können Schlüsselwortlisten für benutzerdefinierte Formulare und Applikationen verwaltet werden. Die Schlüsselwortliste wird durch den Namen eindeutig identifiziert und hat x verschiedene angehängte Schlüsselwerte. Für jeden dieser Schlüsselwerte gibt es für alle definierten Sprachen einen Langtext. In der Datenbank wird jedoch immer nur der Kurzname (Keyword) abgespeichert und im Normalfall auch nicht dem Benutzer angezeigt.
Im Falle einer Löschung eines Schlüsselwerts wird dieser das gültig-bis Feld auf "jetzt" gesetzt, somit fällt dieser Datensatz bei zukünftigen Abfragen raus und ist logisch gelöscht.
Die Systemmeldungen erlauben es, den User auf eventuelle Unregelmäßigkeiten oder anstehende Ereignisse aufmerksam machen, wie z.B. anstehende Ereignisse im Unternehmen oder beispielsweise bevorstehende Wartungsarbeiten am System. Diese Systemmeldungen erscheinen direkt nach der Anmeldung auf dem Welcome-Bildschirm. Der Administrator kann den Zeitpunkt des Erscheinens der Meldung bestimmen, ebenso wie die Dauer, für welche die Meldung erscheinen soll.
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.
|
Modul |
Gruppe |
Eigenschaft |
mögl. Werte |
Beschreibung |
|---|---|---|---|---|
|
po |
PoUtilServiceTarget |
timeToLiveLoginToken |
numerisch |
Wert in Sekunden, wie lange ein Logintoken Gültigkeit hat |
|
po |
PoOptions |
firstAction |
z.B.
|
Name der Aktion, welche beim Start aufgerufen wird |
|
webdesk-DataSource |
max Idle |
z.B. 5 | ||
|
webdesk-DataSource |
maxActive |
z.B. 100 | ||
|
SharkDataSource |
max Idle |
z.B. 5 | ||
|
SharkDataSurce |
maxActive |
z.B. 100 | ||
|
auth |
Authentication |
authentication Mode |
DB | |
|
auth |
Authentication |
authentication sysAdminUser |
sadmin | |
|
auth |
Authentication |
authentication sysAdminPassword | ||
|
auth |
Authentication |
authentication sysAdminCommonName |
Full System Administrator | |
|
auth |
AuthenticationBackupForSSO |
authenticationMode |
DB | |
|
auth |
AuthenticationLDAP |
ldapUser |
z.B. cn=Florian Weiss, o=Zeit | |
|
auth |
AuthenticationLDAP |
ldapPassword |
z.B. wef | |
|
auth |
AuthenticationLDAP |
ldapProviderUrl |
z.B. ldap://localhost:389 | |
|
auth |
AuthenticationLDAP |
ldapBaseDn |
z.B. o=Zeit | |
|
# # | ||||
|
# # | ||||
|
po |
PoActionDAO |
sysAdminUser |
sadmin | |
|
po |
PoOptions |
jsErrorHandling |
true | |
|
po |
PoOptions |
pathToWelcomeLogo |
Hier kann ein Pfad auf ein Logo definiert werden. Bilder müssen immer mittels führendem images angegeben werden. Die Sitemap leitet dann weiter, und zwar zu den Pfaden:
steht in diesem Fall für den Pfad der angegeben wird. Z.b. Wert: images/logo.gif
Bild kann sich nun entweder unter
Damit das Logo angezeigt wird, ist ein Neustart des Servers notwendig. | |
|
po |
PoRegistrationBean_po |
versionNumber |
16 | |
|
po |
PoUtilServiceTarget |
smtpServer |
asterix.workflow.at | |
|
po |
PoUtilServiceTarget |
smtpServerPort | ||
|
po |
PoUtilServiceTarget |
smtpServerUser | ||
|
po |
PoUtilServiceTarget |
smtpServerPassword | ||
|
po |
PoUtilServiceTarget |
defaultSender | webmaster@workflow.at | |
|
po |
PoUtilServiceTarget |
messageType |
html | |
|
po |
PoUtilServiceTarget |
timeToLiveLoginToken |
10 | |
|
po |
PoActionServiceTarget |
syncActionsOnStartup |
true | |
|
po |
PoLogServiceTarget |
logAllActions |
true | |
|
po |
PoLogServiceTarget |
logAllUsers |
true | |
|
po |
PoJobServiceTarget |
noOfSchedulerThreads |
1 | |
|
po |
PoRegistrationServiceTarget |
destinationOfMessageFile |
cache/translations | |
|
po |
PoRegistrationServiceTarget |
includeFiles |
cache/flows/Actions.js | |
|
po |
PoRegistrationServiceTarget |
globalIncludeFile |
cache/flows/LoadGlobalScripts.js | |
|
po |
PoAuditLogInterceptor |
functionConstraints |
save | |
|
wf |
wfProcessDefinitionDAO |
defaultmailSubject |
webdesk-TODO | |
|
wf |
wfProcessDefinitionDAO |
defaultMailBody |
<h1>You have something to do in your Workflow-List | |
|
wf |
wfTarget |
confFile |
WEB-INF/classes/shark.conf | |
|
wf |
wfTarget |
confDirDODS |
conf/dods | |
|
wf |
wfTarget |
engineName |
Shark | |
|
wf |
wfTarget |
toolagentPluginDir |
WEB-INF/lib/plugins | |
|
wf |
wfTarget |
externalRepositoryDir |
WEB-INF/work/repository | |
|
wf |
wfTarget |
assignmentManagerClass |
at.workflow.webdesk.wf.sharkimpl.WfSharkAssignment | |
|
wf |
wfTarget |
useCaches |
true | |
|
wf |
wfOptions |
switchUserMayApprove |
true | |
|
gw |
GwCalendarService |
serverparams |
w2ktestsrv2;W2KTESTSRV2;80;administrator;t$st | |
|
gw |
GwCalendarService |
monthsToCheckInPast |
5 | |
|
gw |
GwCalendarService |
monthsToCheckInFuture |
5 | |
|
gw |
GwCalendarService |
descPrefix |
wd_ | |
|
gw |
GwCalendarService |
allowedEntriesPostfix |
(allowed) | |
|
gw |
GwCalendarService |
notAllowedEntriesPostfix |
(not Allowed) | |
|
gw |
GwCalendarService |
groupsToCheck |
* | |
|
G01 | ||||
|
gw |
GwCalendarService |
personsNotToCheck |
wef | |
|
gw |
GwCalendarService |
absenceReasonsToSync |
1, 2, 3, ... | |
|
gw |
GwCalendarService |
syncType |
0 | |
|
gw |
GwCalendarService |
wfFlag |
Webdesk3 | |
|
gw |
GwADLdapClient |
ldapProviderUrl |
ldap://192.168.1.182 | |
|
gw |
GwADLdapClient |
ldapUser |
W2KDOM\Administrator | |
|
gw |
GwADLdapClient |
ldapPassword |
t$st | |
|
gw |
GwADLdapClient |
ldapBaseDn |
CN=Users,DC=w2kdom,DC=at | |
|
gw |
GwADLdapClient |
ldapSearchQuery |
(&(objectsclass=user)(mailNickname={0})) | |
|
gw |
GwADLdapClient |
ldapSearchSubTree |
true | |
|
gw |
GwADLdapClient |
cutDomain |
true | |
|
gw |
PoRegistrationBean_gw |
versionNumber |
1 | |
|
ta |
Ta |
if6020User |
super | |
|
ta |
Ta |
if6020Password |
TOPSTAR | |
|
ta |
Ta |
excludeHolidays |
A,C | |
|
ta |
PoRegistrationBean_ta |
versionNumber |
3 | |
|
ta |
TaOptions |
absenceCodesWithAttendantBehavior |
99 | |
|
ta |
PoOptions |
firstAction | ||
|
auth |
AuthenticationLDAP |
tlsEnabled |
true |
Jobs
Konnektoren
Verknüpfte Konnektoren
Module
Dateien
Monitoring
Organisationsverwaltung
| Mime Type | text/xml |  | text/xml |
| Datei-name | | ||
| Größe (in Bytes) | 7343 |  | 53954 |
|
Version 7 von Mrs. Ex-Mitarbeiter
am 11.08.08 16:23:26 Name: Portal & Organisation Variante: main - default Status: Veröffentlichung |  |
Version 8 von Mrs. Ex-Mitarbeiter
am 12.08.08 13:32:22 Name: Portal & Organisation Variante: main - default Status: Veröffentlichung |
Vergleiche Versionen 6 und 7