WARNUNG: Sie betrachten nicht die Live-Version, sondern eine ältere Version.

Portal & Organisation

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.

Organisationsverwaltung

Mandantenverwaltung

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.

Organisationsstrukturen

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:

  • hierarchische Aufbauorganisation
  • Lose Gruppen
  • Projektgruppen
  • Kostenstellen

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.

Organigramm_lose gruppen

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.

Gruppenverwaltung

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).

Personenverwaltung

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. 

Rollen

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).

Kompetenzziel

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.

Vererbungsrichtung

Die Vererbungsrichtung bestimmt de Richtung bei der Suche nach definierten Rolleninhabern (z.B. in einem Workflow-Verlauf):

  • aufwärts - sinnvoll bei Suche nach Rolle Vorgesetzter (Suche nach Vorgesetzten verläuft in den übergeordneten Abteilungen oder Gruppen)
  • abwärts - sinnvoll bei Krankmeldungen (z.B. Krankmeldung von Kollegen innerhalb der eigenen Abteilung und der darunterliegenden Abteilungen)
  • keine - Suche nach Rolleninhaber findet nur innerhalb der eigenen Gruppe oder Abteilung statt.

Vererbungsrichtung keine

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.

Vererbungsrichtung aufwärts

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").

vererbungsrichtung keine

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:

vererbungsrichtung keine2

Vererbungsrichtung abwärts

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.

vererbungsrichtung abwärts

Stellvertreterregelung

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.

Suche nach Rolleninhabern

Die Suche nach Rolleninhabern verläuft in 2 Phasen:

  • Phase 1 - Ermittlung aller möglichen Rolleninhabern
  • Phase 2 - Rausfiltern der tatsächlichen Rolleninhaber, unter Berücksichtigung deren Stellvertreterregelung (allerdings nur bei Rollen vom Typ hierarchische Aufbauorganisation)

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

  • es gibt direkte Zuordnungen
  • es gibt keine direkte Zuordnungen

Es gibt mind. eine direkte Zuordnung

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).

Es gibt keine direkten Zuordnungen

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.

Abschliessend (für beide Varianten gültig)

Nun kommen noch die dynamischen Rolleninhaber mit Kompetenzziel Alle hinzu. Anschliessend wird das Resultat auch noch um generelle Rolleninhaber (Auch Kompetenzziel Alle) erweitert.

Organigramm

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.

Aussehen der Applikation

Aktionsverwaltung

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.

  • Von jeder konfigurierbaren Aktion können beliebig viele Konfigurationen (d.h. Aktionstyp = "Konfiguration")  abgeleitet werden.
  • In einer konkreten Konfiguration kann bestimmt werden, welche und wie viele Felder dem Benutzer angezeigt werden. Dadurch wird ermöglicht, daß Formulare an die Bedürfnisse und Wünsche einzelner Benutzer bzw. Benutzergruppen angepasst werden.
  • Ob eine Aktion konfigurierbar ist, oder nicht erkennt man in der Aktionsmaske: Wenn es den Button "Neue Konfiguration" gibt im Reiter "Einstellungen", so können neue Konfigurationen (Abwandlungen) hinzugefügt werden.

Konfigurationen

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. 

Berechtigungssteuerung

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:

  • Mandantenberechtigung
  • Gruppenberechtigung
  • Personenberechtigung
  • Rollenberechtigung.

Mandantenberechtigung

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.

Gruppenberechtigung

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).

Gruppenberechtigung

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.

Gruppen mit untergeordneten

Personenberechtigung

Die Personenberechtigung ermöglicht, daß nur eine bestimmte Person die Einsichtserlaubnis für bestimmte Aktionen bekommt.

Personenberechtigung

Rollenberechtigung

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).

Rollenberechtigung

Die Vergabe der Berechtigung erfolgt entweder über die Aktion, Person oder die Rolle.

Einsichtserlaubnis

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.

Eigene Person

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.

Einsichtserlaubnis Person

Orgeinheit

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.

Einsichtserlaubnis Orgeinheit

Orgeinheit und untergeordnete

Die Einsichtserlaubnis gilt für die eigene Abteilung und ihr untergeordnete Abteilungen (Gruppen, ...), d.h. alle Gruppen, die hierarchisch darunter liegen.

einsichtserlaubnis org+untergeordnete

Rollenkompetenz

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.

Mandant

 Die Einsichtserlaubnis erstreckt sich auf alle Personen des eigenen Mandanten, d.h. es werden auch alle Mitarbeiter angezeigt:

Eisichtserlaubnis mandant

Alle Mandanten

Die Einsichtserlaubnis erstreckt sich auf alle Personen aller Mandanten.

Speziell

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.

einsichtserlaubnis speziell personeinsichtserlaubnis speziellgruppe

Die Einsichtserlaubnis wird bei der Aktion bestimmt, außer bei der Rollenkompetenz. Bei der Rollenkompetenz wird diese bereits bei der Rolle definiert.

Menübaum

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.

Internationalisierung

Sprachen

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.

Textbausteine

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

  • Beispiel: dem Wort „Name“ in der Überschriftszeile der List liegt das Textmodul mit dem Schlüssel po_showTextModules.act_name
  • Abhängig von der gewählten Sprache im Browser des Benutzers wird die richtige Übersetzung angezeigt:

Schlüssel

Sprache

Übersetzung

po_showTextModules.act_lngcode

po_showTextModules.act_lngcode

Deutsch

Englisch

Sprachcode

Languagecode

Bearbeiten vonTextbausteinen

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.

Erstellen von neuen Textbausteinen / Übersetzungen

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.

Systemeinstellungen

Die Systemeinstellungen erlauben die Wartung und das Monitoring des Webdesk EWP.

Schlüsselwerte

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.

Systemmeldungen

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.

Erweiterte Funktionen

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.

Modulspezifische Aktionen

Workflow-Cache aktualisieren

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.

Aktionsnamen der Standardsprache reparieren ([de]...)

Feiertagsspeicher des TA-Connectors Löschen

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.

Kern-Funktionalität

Alle Log-Einträge aus Datenbank löschen

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.

Berechtigungs-Cache leeren

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.

Menü-Cache leeren

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.

Aktualisiere Übersetzungsfiles

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.

Entsperre alle Textmodule

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.

Sperre alle Textmodule

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.

Neuinitialisierung JobService

Durch Klick auf den Button "Neuinitialisierung JobService" wird das gesamte Job-Service neu initialisiert und auf die Ausgangswerte zurückgesetzt.

Starte Modulupdate

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.

Lockkontroller leeren

Einschränkung der Registrierung auf

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.

Registrierungsmodus

Anzuwenden  z.B. bei erweiterten Lizenzen > Module werden ohne Neustart nachgeladen. Beim Registrierungsmodus können folgende Parameter selektiert werden:

  • complete - alles wird registriert
  • Everything except Textmodules - alles ausserhalb der Textmodule wird registriert.
  • actions and Flowscripts - nur Aktionen sowie FlowScripts werden registriert.

Starte Registrierung aller Module

Mit dieser Aktion werden alle Module des Webdesk neu registriert. Dabei werden für jedes Modul im Webdesk

  • Aktionen am Webdesk registriert
  • Jobs registriert
  • Action-Flowscripts registriert und in die Datei $CATALINA_HOME/webapps/webdesk3/cache/flows/Actions.js geschrieben
  • die Datei $CATALINA_HOME/webapps/webdesk3/cache/flows/LoadGlobalScrips.js geschrieben
  • Konfigurationen registriert
  • Selbstdefinierte Aktionen (Custom Actions) synchronisiert
  • Textbausteine registriert
  • Connectoren registriert

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!

Auffrischung der erlaubten Aktionen

Es gibt Aktionen welche nach der Durchführung überprüfen, ob die Aktion überhaupt ausgeführt werden darf.

Log-Einstellungen

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!

Wichtige Logger:

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)

Systemparameter

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.

Referenz der Systemparameter

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.
ta_doBooking.act

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:

  • custom/resources/images/{1}
  • resource://at/workflow/webdesk/po/resources/images/{1}
{1}

steht in diesem Fall für den Pfad der angegeben wird.

Z.b. Wert: images/logo.gif

Bild kann sich nun entweder unter
custom/resources/images/logo.gif befinden, oder unter
at/workflow/webdesk/po/resources/images/logo.gif

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

    • Mandantenverwaltung
      • Was ist ein Mandant?
      • Wozu brauche ich einen Mandant?
      • Was kann ich mit einem Mandanten machen? (Anwendungsbeispiele)
    • Organisationsstrukturen
      • ...
    • Gruppenverwaltung
    • Personenverwaltung
    • Rollen
  • Aussehen der Applikation
    • Aktionsverwaltung
      • Was ist eine Aktion?
      • Was ist eine Konfiguration?
      • Was ist eine Prozessreferenz?
    • Menübaum
    • Internationalisierung
      • Sprachen, Textbausteine
      • Funktionsweise (Auslieferungszustand, Möglichkeit der Änderung durch den Kunden, Flag "UpdateOnVersionChange"...)
  • Berechtigungssteuerung
    • Dialogberechtigung
    • Einsichtsberechtigung definieren.
  • System Einstellungen
    • Einstellungen
      • Jobs
      • Schlüsselwerte
      • Connectoren
      • Connector-Links
      • Module
      • Systemparameter
      • Log einstellungen
    • Monitoringen
      • Logs
      • Liste der Caches
      • Liste der angemeldeten User
      • Continuations
      • Status Report Cocoon
      • Aktive Jobs
  • Spezielle Funktionen
    • Switch
    • Systemmeldungen
Kommentare (0)