Sitzungsverwaltung

Die Sitzungsverwaltung ermöglicht die Überwachung und Verwaltung der Arbeitssitzungen von Benutzern im täglichen Betrieb von proALPHA. Dazu werden alle Zugriffe von Clients, die im Rahmen von Arbeitssitzungen auf die proALPHA Datenbanken erfolgen, als Sitzungen geführt. Dies können sowohl Clients für die proALPHA Benutzeroberfläche (UI-Clients) als auch Clients für Hintergrundprozesse (z.B. Queue-Server) sein. Die Clients werden beim Start der proALPHA Arbeitssitzung an den Datenbanken angemeldet. Der physische Zugriff auf die Datenbanken erfolgt über Verbindungen, die beim Start der Sitzung gestartet werden.

Für eine Sitzung können mehrere verschiedene Verbindungen benötigt werden. So benötigt z.B. ein Benutzer für die Arbeit in proALPHA eine Verbindung für den entsprechenden UI-Client und eine Verbindung über einen Application Server (AppServer). Damit ein Benutzer eine bestimmte Verbindung nutzen kann, muss im Benutzerstamm der entsprechende Service für ihn freigegeben sein.

Welche Verbindungen im Rahmen einer Sitzung gestartet werden, bestimmt die Startkonfiguration für die Sitzung. Dabei können mehrere Sitzungen dieselbe Verbindung nutzen. So können z.B. mehrere Benutzer (UI-Clients) dieselbe Verbindung über einen AppServer nutzen, um auf die Datenbanken zuzugreifen.

Die aktuell laufenden Sitzungen und Verbindungen können Sie jeweils in einer Übersicht einsehen. In der Übersicht der Verbindungen können Sie ggf. auch die automatische Beendung von Arbeitssitzungen veranlassen.

Arbeitssitzungen starten

Beim Start einer Arbeitssitzung werden die verschiedenen Clients wie folgt an den Datenbanken angemeldet:

  • Clients für die proALPHA Oberfläche: Anmeldung durch den Benutzer mit Eingabe von Benutzerkennung und Passwort oder mit LDAP

  • Clients für Hintergrundprozesse, z.B. Queue-Server oder AppServer: Automatische Anmeldung mit Benutzerkennung und Passwort aus der Startkonfiguration.

    Voraussetzung für die Anmeldung ist, dass Benutzerkennung und Passwort in der Startkonfiguration für den Client hinterlegt sind. Die Benutzerkennung wird anhand des Startparameters UserID und das Passwort anhand des Startparameters PasswordBatch hinterlegt. Der Startparameter PasswordBatch kann ausschließlich in der Konfigurationsdatei der Startkonfiguration definiert werden und ist nicht übersteuerbar. Das Passwort wird in der Startkonfiguration verschlüsselt gespeichert und ist somit für niemanden einsehbar.

Beim Start der Arbeitssitzung werden die Einstellungen geladen, die für das Arbeiten mit proALPHA über den betreffenden Client benötigt werden. Dazu wird die für den Client vorgesehene Anwendungskonfiguration geladen.

Die Daten der aktuell angemeldeten Clients können Sie im Fenster Verbindungen einsehen.

Arbeitssitzungen verwalten

Sitzungen einsehen und verwalten

In der Übersicht Sitzungen können Sie die Daten aller laufenden Sitzungen einsehen. Anhand der Übersicht erkennen Sie z.B., welche Benutzer in proALPHA in welchen Mandanten angemeldet sind oder welche Queue-Server aktiv sind. Ihre eigenen Sitzungen sind in der Übersicht farbig unterlegt (blau).

Die Übersicht können Sie aktualisieren (Schaltfläche ). Beim Aktualisieren werden die Daten der laufenden Arbeitssitzungen zur Anzeige in der Übersicht neu geladen. Dabei werden die Daten von zwischenzeitlich gestarteten Sitzungen in der Übersicht ergänzt und die Daten von beendeten Sitzungen entfernt.

Im laufenden Betrieb wird regelmäßig geprüft, welche Arbeitssitzungen von Benutzern oder Servern nicht mehr aktiv sind. Solche inaktiven Sitzungen entstehen z.B., wenn ein Benutzer seine Arbeitssitzung nicht vorschriftsmäßig beendet. Inaktive Sitzungen werden automatisch beendet. Diese Bereinigung, d.h. die Prüfung und das Beenden inaktiver Sitzungen können Sie in der Übersicht Sitzungen auch manuell starten (Menüpunkt Extras | Bereinigung). Zudem können Sie einzelne inaktive Sitzungen löschen (Schaltfläche ).

Erläuterungen zum Bereinigen von Sitzungen

Für jede Datenbankverbindung eines Clients im Rahmen einer Arbeitssitzung werden in den Tabellen BCR_Agent (physische Datenbankverbindungen) und BCR_Connection (aktuell bestehende Verbindungen) entsprechende Sitzungsdatensätze angelegt.

Ob und wie Sie auf solche Sitzungsdatensätze zugreifen können, z.B. zum Bereinigen inaktiver Sitzungen, hängt von der Art der Datenbankverbindung ab. Dabei wird wie folgt unterschieden:

  • Sitzungen mit direkter 1:1-Verbindung zur Datenbank

  • Sitzungen ohne direkte 1:1-Verbindung zur Datenbank

Sitzungen mit direkter 1:1-Verbindung zur Datenbank

Die Sitzungsdatensätze sind durch den Client für die Dauer der Sitzung verriegelt. Andere Clients können nicht auf die Sitzungsdatensätze zugreifen.

Wenn der Client ohne Abmeldung beendet wird, dann können Sie die Sitzungsdatensätze ggf. nicht bereinigen, weil die Verriegelung weiter besteht. Verriegelte Sitzungsdatensätze werden bei der automatischen oder manuell gestarteten Bereinigung von Sitzungen nicht berücksichtigt. Sie können die Sitzungen auch nicht einzeln manuell löschen.

Ob und wie lange Sitzungsdatensätze verriegelt sind, ist abhängig von der Situation beim Beenden des Clients:

  • Wenn nur der Client beendet wird, z.B. durch einen Netzwerkfehler, dann bleiben die Sitzungsdatensätze zunächst verriegelt. Die Verriegelung wird erst aufgehoben, wenn die Datenbank das Beenden registriert und auch die Verbindung des Clients trennt.

  • Wenn auch die Datenbank heruntergefahren wird, dann werden alle Verriegelungen von Sitzungsdatensätzen sofort aufgehoben.

Sitzungen ohne direkte 1:1-Verbindung zur Datenbank

Solche Sitzungen werden über proALPHA Services mit festgelegten Timeouts gesteuert. Über Services werden z.B. Datenbankverbindungen von AppServern gesteuert. Dabei können mehrere Clients dieselbe Datenbankverbindung nutzen.

Wenn ein Client ohne Abmeldung beendet wird, dann können Sie die Sitzungsdatensätze des Clients erst nach Ablauf des Timeouts für den genutzten Service bereinigen. Vorher werden die Sitzungsdatensätze bei der automatischen oder manuell gestarteten Bereinigung von Sitzungen nicht berücksichtigt. Sie können die Sitzungen jedoch einzeln manuell löschen. Beim Löschen einer solchen Sitzung werden Sie in einer Systemmeldung über das laufende Timeout informiert.

Verbindungen einsehen und verwalten

In der Übersicht Verbindungen können Sie die Daten aller laufenden Verbindungen einsehen, die zu den Datenbanken bestehen, z.B. Verbindungen von Clients für die proALPHA Benutzeroberfläche (UI-Clients) oder von AppServern. Ihre eigene aktuelle UI-Client-Verbindung ist in der Übersicht farbig unterlegt (blau).

Je Verbindung können Sie verschiedene Parameter einsehen, u.a. den Namen des verbundenen Rechners, die Windows Prozess-ID sowie weitere Daten zum Betriebssystem (Menüpunkt Info | Parameter). Die Parameterwerte können im Falle von Problemen der schnellen Informationsgewinnung und dem Debugging dienen.

Die Übersicht können Sie aktualisieren (Schaltfläche ). Beim Aktualisieren werden die Daten der laufenden Verbindungen zur Anzeige in der Übersicht neu geladen. Dabei werden die Daten von zwischenzeitlich gestarteten Verbindungen in der Übersicht ergänzt und die Daten von beendeten Verbindungen entfernt.

Im laufenden Betrieb wird regelmäßig geprüft, welche Verbindungen von Benutzern oder Servern nicht mehr aktiv sind. Solche inaktiven Verbindungen entstehen z.B., wenn ein Benutzer seine Arbeitssitzung nicht vorschriftsmäßig beendet. Inaktive Verbindungen werden automatisch beendet. Diese Bereinigung, d.h. die Prüfung und das Beenden inaktiver Verbindungen können Sie in der Übersicht Verbindungen auch manuell starten (Menüpunkt Extras | Bereinigung). Zudem können Sie einzelne inaktive Verbindungen löschen (Schaltfläche ).

Hinweis: Im Fenster Verbindungen stehen zusätzlich verschiedene Funktionen zur Verfügung, die der Informationsgewinnung im Fehlerfall dienen. So kann z.B. das Debug Framework aktiviert werden. Weiterführende Informationen zu den Funktionen finden Sie im proALPHA Wiki. Das proALPHA Wiki ist Bestandteil des proALPHA Kundenportals. Die Zugangsdaten für das proALPHA Kundenportal erhalten Sie vom proALPHA Service. Für die Verwendung der Funktionen sind hinreichende Fachkenntnisse nötig. Probleme, die durch die Verwendung entstehen, unterliegen ausschließlich der Verantwortung des Benutzers. Wir empfehlen den Besuch der proALPHA Seminare.

Arbeitssitzungen beenden

In der Regel wird eine Arbeitssitzung beendet, wenn der Benutzer proALPHA schließt. Arbeitssitzungen können jedoch auch automatisch beendet werden.

Sie können die automatische Beendung von Arbeitssitzungen von UI-Clients in proALPHA veranlassen, z.B. für Wartungszwecke. Dazu können Sie an einzelne oder auch sämtliche Verbindungen zu laufenden Arbeitssitzungen sogenannte Shutdown-Anfragen senden. Sie können:

  • Shutdown-Anfrage für die in der Übersicht ausgewählte Arbeitssitzung senden

    (Menüpunkt Extras | Beenden anfragen (selektierte Sitzung))

  • Shutdown-Anfrage für alle Arbeitssitzungen senden

    (Menüpunkt Extras | Beenden anfragen (alle Sitzungen))

  • Shutdown-Anfrage für alle Arbeitssitzungen in einem inaktiven Pool senden

    (Menüpunkt Extras | Beenden anfragen (alle Sitzungen inaktiver Pool))

Die betroffenen Benutzer werden jeweils mit einer Desktopbenachrichtigung (Desktop Alert) zum Schließen ihrer Arbeitssitzung aufgefordert sowie über die bevorstehende automatische Beendung ihrer Arbeitssitzung informiert. Der Zeitraum zwischen der Benachrichtigung und der automatischen Beendung der Arbeitssitzung ist auf fünf Minuten festgelegt. So bleibt den Benutzern ggf. genug Zeit zum Sichern der gerade bearbeiteten Daten und zum manuellen Beenden der Arbeitssitzung.

Informationen zu Arbeitssitzungen

Informationen

Informationsquellen

Startparameter der laufenden Sitzungen

Infofenster "Sitzungsparameter"

Anwendungsparameter der Sitzung des angemeldeten Benutzers

Infofenster "Sitzungsparameter (ACM)"

Laufende Verbindungen

Fenster Verbindungen: Menüpunkt Systemverwaltung | Sitzungen in der Programmauswahl

Laufende Sitzungen

Fenster Sitzungen: Menüpunkt Systemverwaltung | Sitzungen in der Programmauswahl

Protokoll über Benutzeraktionen beim Starten und Beenden von Sitzungen, z.B. Fehler beim Anmelden oder Passwortänderungen

Protokollierung von Applikationsauditereignissen im Auditing. Das Protokoll kann in der Systemverwaltung eingesehen werden.

Historisierte Verbindungen (vergebene Sitzungsschlüssel)

Tabelle BCL_ConnectionHist

Die Historie kann z.B. zur Fehleranalyse herangezogen werden. Dazu kann die Tabelle BCL_ConnectionHist über den Database Explorer beauskunftet werden.

Die Tabelle wird nur dann geführt, wenn für die Daten eine Speicherdauer größer "0" festgelegt ist (Speicher BCLCON).

Administration

Objekte

Bedeutung

AppServerConnect

Festlegung, ob der Client eine Verbindung zum AppServer aufbaut

Defaultwert ist "yes", d.h. der Client wird mit Verbindung zum AppServer gestartet.

Der Wert "no" (Start ohne Verbindung zum AppServer) ist ausschließlich für das Debugging im Falle von Problemen vorgesehen.

AppserverstartConnectionCycles

Anzahl der Verbindungsversuche des AppServers zu den Datenbanken

Der AppServer versucht alle zehn Sekunden, die Verbindung zu den Datenbanken aufzubauen. Falls die Datenbanken beim Start des AppServers noch nicht gestartet sind, wird so der Start nicht sofort abgebrochen. Der Parameter "AppserverstartConnectionCycles" bestimmt, wie oft der Verbindungsaufbau erneut versucht wird. Der Abbruch erfolgt erst, wenn auch nach der festgelegten Anzahl von Verbindungsversuchen noch keine Verbindung zu den Datenbanken möglich ist.

Defaultwert ist "60".

AlwaysConnectAppServerOnQueue

Festlegung, ob AppServer-Verbindungen für Queues auch im Shared Memory aufgebaut werden

Defaultwert ist "no", d.h. eine Queue kann nur dann AppServer verbinden, wenn sie nicht über eine Shared-Memory-Verbindung auf die Datenbank zugreift.

Beim Wert "yes" kann die Queue auch im Shared Memory einen oder mehrere AppServer verbinden. Dabei ist der mehrfache asynchrone Aufruf von AppServern durch eine Queue möglich. So können z.B. mehrere Verarbeitungsläufe parallelisiert und so die Performance verbessert werden.

Speicher BCLCON

Speicherdauer für historisierte Verbindungen (vergebene Sitzungsschlüssel)