Masterthesis „Renewal TeamPortal“
Werbung
Masterthesis „Renewal TeamPortal“
Nummer:
Titel:
Klasse, Datum:
Abstract:
Schlüsselwörter:
Erstellt durch:
Betreuer:
MT-11-02.14
Renewal Teamportal
MT-11-02, 29.03.2012
Das TeamPortal ist der Einstiegspunkt für die 50 Intranet-Entwickler bei der
Schweizerischen Post, um mehr als 380 Applikationen zu administrieren sowie
deren Logs und DB-Jobs zu überwachen. Neu wird es die Entwicklungs-Prozesse
vereinfachen und dem Management aussagekräftige Informationen anbieten.
Visual Studio 2010 SP1, Windows Server 2008 R2, SQL Server 2008 R2,
.NET Framework 4, ASP.NET 4, WCF, NHibernate, SQL Server Integration Services
Die Schweizerische Post
Services
Informationstechnologie
Business Solution IT133
Pascal Irminger
Webergutstrasse 12
3030 Bern (Zollikofen)
Die Schweizerische Post
Services
Informationstechnologie
Business Solution IT132
Marcel Lehmann
Webergutstrasse 12
3030 Bern (Zollikofen)
Die Schweizerische Post
Services
Informationstechnologie
Business Solution IT131
Axel Zenklusen
Webergutstrasse 12
3030 Bern (Zollikofen)
Tel: 079 712 67 91
Tel: 058 338 71 52
Tel: 058 338 75 57
Die Schweizerische Post
Services
Informationstechnologie
Business Solution IT132
Stefan Haefeli
Webergutstrasse 12
3030 Bern (Zollikofen)
Tel: 058 338 04 33
Experte:
Rolf Wenger
Die Schweizerische Post
Informationstechnologie
Management Summary
Dokumentart
Titel
Projektname
Projektabkürzung
Projektmanager
Ausgabedatum
Autor
Übermittler
Empfänger
Klassifizierung
AU
Management Summary - Masterthesis "Renewal TeamPortal"
Corp_PadMan
PADMAN
Irminger Pascal, IT133
28.03.2012
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133; Lehmann Marcel, IT132; Zenklusen Axel, IT131; Haefeli Stefan,
IT132
Nicht klassifiziert
Änderungskontrolle
Version
Datum
Überarbeitung
Ersteller
Freigabe
X01.00
V01.00
28.03.2012
28.03.2012
Neues Dokument
Freigabe
Irminger Pascal, IT133
Irminger Pascal, IT133
Haefeli Stefan, IT132
Management Summary
Das TeamPortal ist der Einstiegspunkt für die rund 50 Intranet-Entwickler bei der Schweizerischen Post, um mehr
als 380 Applikationen zu administrieren sowie deren Logs und DB-Jobs zu überwachen. Neu wird es die
Entwicklungs-Prozesse vereinfachen und dem Management aussagekräftige Informationen anbieten.
PadMan – Post Application Development Manager
PadMan ist eine neue zentrale Intranet-Applikation, welche die aktuellen Bedürfnisse der Entwickler abdeckt, um
die heutigen Prozesse zu verbessern. Sie ermöglicht dem Benutzer, durch die Entwicklungsprozesse geführt zu
werden und automatisiert bislang manuelle Tasks wie z.B. die Interaktion mit der Versionsverwaltung. Als neuer
Dreh- und Angelpunkt für die .NET-Webapplikationen im Intranet der Schweizerischen Post versorgt PadMan
diese mit den benötigten Daten wie z.B. Connection Strings, Sprach-Labels, etc.
LogObi – Organized Bugs and Information
Mit der neuen Intranet-Applikation LogObi werden die Applikations-Logs sämtlicher .NET-Webapplikationen aus
dem Intranet der Schweizerischen Post visualisiert. Die Logfiles werden dabei von der Server-Farm eingesammelt
und nach dem Import vorverarbeitet, so dass die Logs sogleich nach Benutzer-Wünschen vorgefiltert angezeigt
werden können. Die Benutzer können zusätzlich Suchfilter definieren, wonach sie automatisch per E-Mail
informiert werden wollen, sobald konfigurierbare Schwellwerte überschritten werden.
JobMonitor
JobMonitor ist eine neue Intranet-Applikation zur Visualisierung von SQL Server Jobs. Damit lässt sich exakt
feststellen, welche Jobs erfolgreich und welche fehlerhaft ausgeführt wurden. Gegenüber dem Log File Viewer
aus dem SQL Server Management Studio verbindet JobMonitor die SQL Server Agent Logs mit denjenigen aus
den SSIS-Packages. Datenbank-Administratoren können fehlerhafte Job-Runs nach allfälliger Korrektur als
erledigt markieren. Weiter können die verantwortlichen Personen im Fehlerfall automatisch per E-Mail informiert
werden.
AU_PADMAN_ManagementSummary_V01.00.
docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
1/1
Masterthesis „Renewal TeamPortal“
Projektplan
Risikokatalog
Situationsanalyse
Corp_PadMan – Systemanforderungen
Corp_PadMan – Systemdesign
Corp_LogObi – Systemanforderungen
Corp_LogObi – Systemdesign
Corp_JobMonitor – Systemanforderungen
Corp_JobMonitor – Systemdesign
Migration (in der publizierten Version nicht enthalten)
Die Schweizerische Post
Informationstechnologie
Projektplan
Dokumentart
Titel
Projektname
Projektabkürzung
Projektmanager
Ausgabedatum
Autor
Übermittler
Empfänger
Klassifizierung
PP
Projektplan
Corp_PadMan
PADMAN
Irminger Pascal, IT133
28.03.2012
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133; Lehmann Marcel, IT132; Zenklusen Axel, IT131; Haefeli Stefan,
IT132
Nicht klassifiziert
Änderungskontrolle
Version
Datum
Überarbeitung
Ersteller
Freigabe
X01.00
X01.01
X01.02
X01.03
V01.03
24.10.2011
21.11.2011
19.12.2011
28.03.2012
28.03.2012
Neues Dokument
Definition Meilensteine
Aktualisierung gemäss Projektstand
Finalisierung
Freigabe
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
Haefeli Stefan, IT132
PP_PADMAN_Projektplan_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
1/7
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Projektplan
Projektplan
Informationstechnologie
Inhaltsverzeichnis
1 Allgemeines .................................................................................................................................................. 3
1.1 Zweck ........................................................................................................................................................ 3
1.2 Beschreibung ............................................................................................................................................. 3
1.3 Tailoring ..................................................................................................................................................... 3
1.4 Definitionen, Akronyme und Abkürzungen ................................................................................................ 3
1.5 Referenzen ................................................................................................................................................ 3
2 Projektorganisation ....................................................................................................................................... 4
2.1 Aufbauorganisation ................................................................................................................................... 4
2.2 Aufgaben und Verantwortlichkeiten .......................................................................................................... 4
2.3 Schnittstellen ............................................................................................................................................. 4
3 Projektablauf ................................................................................................................................................ 5
3.1 Ergebnisstrukturplan .................................................................................................................................. 5
3.2 Arbeitsstrukturplan .................................................................................................................................... 5
4 Aufwands- und Terminplan ........................................................................................................................... 6
4.1 Grobplan ................................................................................................................................................... 6
4.1.1 Aufwände (Soll und Ist) für SE-/QS-/RM-/KM-/PM-Aktivitäten.................................................................. 6
4.1.2 Termine (Ziel- und Ist-Termine) für SE-/QS-/RM-/KM-/PM-Aktivitäten ....................................................... 6
4.1.3 Meilensteinplan ...................................................................................................................................... 6
4.1.4 Zu- und Ausliefertermine ........................................................................................................................ 6
4.2 Feinplan ..................................................................................................................................................... 6
5 Einsatzmittelplan .......................................................................................................................................... 7
5.1 Personal ..................................................................................................................................................... 7
5.2 Sachmittel.................................................................................................................................................. 7
PP_PADMAN_Projektplan_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
2/7
Projektname
Dokumenttitel
Artifaktname
1
Corp_PadMan
Projektplan
Projektplan
Informationstechnologie
Allgemeines
1.1
Zweck
Der Projektplan enthält die Planung und Organisation des gesamten Projekts und ergänzt das Projekthandbuch
als Handlungsgrundlage. Der Projektplan wird fortlaufend nachgeführt und verfeinert.
1.2
Beschreibung
Der Projektplan definiert nach der Initialisierung des Projekts die Grobplanung für das gesamte Projekt. Am Ende
jeder Phase wird die Planung für die nächste Phase überprüft und verfeinert sowie die Grobplanung für das
ganze Projekt überprüft.
Folgendes Beispiel verdeutlicht dieses Prinzip: Nach der Phase «Initialisierung» enthält der Projektplan die
verfeinerte Planung der Phase «Voranalyse», nach Phasenabschluss die verfeinerte Planung der Phase «Konzept»
und die überarbeitete Grobplanung des gesamten Projekts.
1.3
Tailoring
Der Projektplan darf nie weggelassen werden.
Bei kleinen Projekten kann der Projektplan erst nach dem Projektauftrag erstellt werden, wenn die für den
Projektauftrag notwendigen Regelungen im Projekthandbuch festgelegt sind.
1.4
Definitionen, Akronyme und Abkürzungen
Wort
Definition
Beta
BFH
JIRA
Software Version: Beta
Berner Fachhochschule
Webbasierte Anwendung zur Fehlerverwaltung, Problembehandlung und operativem
Projektmanagement
Projekt «Post Application Development Manager»
Post Wide Web – Intranet der Schweizerischen Post
Software Version: Release Candidate
PadMan
PWW
RC
1.5
Referenzen
Nr.
Titel
[01]
[02]
Projektplan-Excel-Dokument: PP_PADMAN_Projektplan.xlsx
JIRA: https://jira.pnet.ch/browse/PADMAN
PP_PADMAN_Projektplan_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
3/7
Projektname
Dokumenttitel
Artifaktname
2
Corp_PadMan
Projektplan
Projektplan
Informationstechnologie
Projektorganisation
Nachfolgende Abbildung stellt das Projektorganigramm dar. Die jeweiligen Rollen beschreiben den jeweiligen
Verantwortungsbereich. Je Aufgabengebiet – insbesondere in der Entwicklung – werden die Rollen von
mehreren Projektmitarbeitenden wahrgenommen. Die im Organigramm angegebene Person ist die jeweils
Verantwortliche.
Pascal Irminger
Projektleiter
Stefan Haefeli
Betreuer Masterthesis
Marcel Lehmann
Code & Architekt
Axel Zenklusen
Daten & Auswertungen
Abbildung 1: Projektorganisation.
2.1
Aufbauorganisation
Projektorganisation
(Projekt-) Auftraggeber
Projektteam
Qualitätssicherung
Risikomanagement
Konfigurationsmanagement
Name
Haefeli Stefan
Zenklusen Axel
Lehmann Marcel
Irminger Pascal
Haefeli Stefan
Irminger Pascal
Irminger Pascal
Zenklusen Axel
Lehmann Marcel
Funktion / Dienststelle
IT132
IT131
IT132
IT133
IT132
IT133
IT133
IT131
IT132
Betreuer Masterthesis
Experte Masterthesis
Haefeli Stefan
Wenger Rolf
IT132
BFH
Projektausschuss
Legende:
AG
PL
QV
RV
KV
Rolle
AG
PL
AG
PL
QV
RV
KV
= Auftraggeber
= Projektleiter
= Qualitätsverantwortlicher
= Risikoverantwortlicher
= Konfigurationsverantwortlicher
2.2
Aufgaben und Verantwortlichkeiten
Siehe Kapitel 0.
2.3
Schnittstellen
Zumal es sich beim Projekt PadMan um die Masterthesis der drei Entwickler – Pascal Irminger, Marcel Lehmann
und Axel Zenklusen – handelt, stellt die entsprechende Berner Fachhochschule (BFH) einen Experten.
PP_PADMAN_Projektplan_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
4/7
Projektname
Dokumenttitel
Artifaktname
3
3.1
Corp_PadMan
Projektplan
Projektplan
Informationstechnologie
Projektablauf
Ergebnisstrukturplan
Corp_PadMan
Projektdokumentation
Systementwicklung
BFH Upload
Abstract
Projektmanagement
Projektantrag IT Post
Ausgangslage
Poster
Situationsanalyse
Projektantrag BFH
Projektplan
Anforderungen
Projektstatusberichte
Checkliste Corp_PadMan
Systemanforderungen Corp_PadMan
Checkliste Corp_LogObi
Systemanforderungen Corp_LogObi
Checkliste Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Qualitätssicherung
Migrationsdesign (inkl. Tests)
System /
Prototyping
Systemdesign Corp_PadMan
Systemdesign Corp_LogObi
Risikomanagement
Systemdesign Corp_JobMonitor
Risikokatalog
Abbildung 2: Ergebnisstrukturplan.
3.2
Arbeitsstrukturplan
Für den Arbeitsstrukturplan siehe JIRA ([02]).
PP_PADMAN_Projektplan_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
5/7
Projektname
Dokumenttitel
Artifaktname
4
Corp_PadMan
Projektplan
Projektplan
Informationstechnologie
Aufwands- und Terminplan
4.1
Grobplan
Beim Projekt Corp_PadMan handelt es sich um die Masterthesis von Pascal Irminger, Marcel Lehmann und Axel
Zenklusen. Diese Masterthesis dauert vom 24.10.2011 bis 29.03.2012.
4.1.1 Aufwände (Soll und Ist) für SE-/QS-/RM-/KM-/PM-Aktivitäten
Die Aufwände werden während dem Projekt laufend geschätzt und verfolgt. Für weitere Details siehe JIRA ([02]).
4.1.2 Termine (Ziel- und Ist-Termine) für SE-/QS-/RM-/KM-/PM-Aktivitäten
Das Projekt wird in diverse Sprints à zwei Wochen aufgeteilt.
Phase
Initialisierung
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5
Sprint 6
Sprint 7
Termin
30.10.2011
13.11.2011
27.11.2011
11.12.2011
25.12.2011
08.01.2012
22.01.2012
05.02.2012
Sprint 8
19.02.2012
Sprint 9
04.03.2012
Sprint 10
18.03.2012
Bemerkung
Corp_LogObi, Version 1.0 beta
Corp_PadMan, Version 1.0 beta
Corp_PadMan, Version 1.0 RC
Corp_LogObi, Version 1.0 RC
Corp_JobMonitor, Version 1.0 beta
Corp_PadMan, Version 1.0 Final
Corp_LogObi, Version 1.0 Final
Corp_JobMonitor, Version 1.0 Final
Migration
4.1.3 Meilensteinplan
Unten stehende Tabelle zeigt die Meilensteine im Projekt PadMan. Meilensteine, welche eine Interaktion mit der
Berner Fachhochschule BFH haben, erhalten die Markierung [BFH] vorangestellt.
[BFH]
[BFH]
[BFH]
[BFH]
[BFH]
Meilenstein
Eingabe Abstract
Upload Projektantrag
Implementation abgeschlossen
Eingabe Präsentationsbedürfnisse
Migration vorbereitet (Testläufe)
Abgabe Dokumentation/Anhänge
Upload Poster
Termin
28.11.2011
28.11.2011
19.02.2012
02.03.2012
11.03.2012
29.03.2012
29.03.2012
KW
KW 48 / 2011
KW 48 / 2011
KW 07 / 2012
KW 09 / 2012
KW 10 / 2012
KW 12 / 2012
KW 12 / 2012
4.1.4 Zu- und Ausliefertermine
Unten stehende Tabelle hält Termine gesondert fest, welche auch projektexterne Stellen betreffen wie
Bereitstellen von Ergebnissen, usw.
[BFH]
[BFH]
[BFH]
[BFH]
[BFH]
Meilenstein
Eingabe Abstract
Upload Projektantrag
Eingabe Präsentationsbedürfnisse
Abgabe Dokumentation/Anhänge
Upload Poster
Termin
28.11.2011
28.11.2011
02.03.2012
29.03.2012
29.03.2012
KW
KW 48 / 2011
KW 48 / 2011
KW 09 / 2012
KW 12 / 2012
KW 12 / 2012
Verantwortlich
Pascal Irminger
Pascal Irminger
Pascal Irminger
Pascal Irminger
Pascal Irminger
Wo?
Diplomportal
Diplomportal
Diplomportal
Diplomportal
Diplomportal
4.2
Feinplan
Für den Feinplan siehe JIRA ([02]).
PP_PADMAN_Projektplan_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
6/7
Projektname
Dokumenttitel
Artifaktname
5
Corp_PadMan
Projektplan
Projektplan
Informationstechnologie
Einsatzmittelplan
5.1
Personal
Die Arbeiten werden unter den drei Entwicklern gemäss deren Rollen im Organigramm aufgeteilt. Die Personen
sind in den Rollen jeweils verantwortlich und können das Projektteam jeweils in die Arbeiten mit einbeziehen.
Die Aufwände werden möglichst gleichmässig auf die drei Entwickler aufgeteilt.
Die zur Verfügung stehende Zeit ergibt sich aus den Restguthaben den Ausbildungsverträgen AZE
(Arbeitszeiterleichterung) zuzüglich einmalig je Entwickler 100 Stunden auf die Intranet-Wartungskostenstelle
sowie der Freizeit der Entwickler (Ferienguthaben, Überzeit, etc.). Die Buchungen auf die IntranetWartungskostenstelle dürfen in Absprache mit der Leitung IT13 erst ab Januar 2012 erfolgen.
5.2
Sachmittel
Es werden keinerlei besondere Sachmittel benötigt.
PP_PADMAN_Projektplan_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
7/7
Masterthesis „Renewal TeamPortal“
Projektplan
Risikokatalog
Situationsanalyse
Corp_PadMan – Systemanforderungen
Corp_PadMan – Systemdesign
Corp_LogObi – Systemanforderungen
Corp_LogObi – Systemdesign
Corp_JobMonitor – Systemanforderungen
Corp_JobMonitor – Systemdesign
Migration (in der publizierten Version nicht enthalten)
Die Schweizerische Post
Informationstechnologie
Risikokatalog
Dokumentart
Titel
Projektname
Projektabkürzung
Projektmanager
Ausgabedatum
Autor
Übermittler
Empfänger
Klassifizierung
RK
Risikokatalog
Corp_PadMan
PADMAN
Irminger Pascal, IT133
28.03.2012
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133; Lehmann Marcel, IT132; Zenklusen Axel, IT131; Haefeli Stefan,
IT132
Nicht klassifiziert
Änderungskontrolle
Version
Datum
Überarbeitung
Ersteller
Freigabe
X01.00
X01.01
X01.02
X01.03
X01.04
X01.05
X01.06
V01.06
21.11.2011
19.12.2011
09.01.2012
30.01.2012
16.02.2012
05.03.2012
28.03.2012
28.03.2012
Neues Dokument
Aktualisierung Risikokatalog
Aktualisierung Risikokatalog
Aktualisierung Risikokatalog
Aktualisierung Risikokatalog
Aktualisierung Risikokatalog
Abschluss Risikokatalog
Freigabe
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
Haefeli Stefan, IT132
RK_PADMAN_Risikokatalog_V01.06.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
1/6
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Risikokatalog
Risikokatalog
Informationstechnologie
Inhaltsverzeichnis
1 Allgemeines .................................................................................................................................................. 3
1.1 Zweck ........................................................................................................................................................ 3
1.2 Beschreibung ............................................................................................................................................. 3
1.3 Tailoring ..................................................................................................................................................... 3
1.4 Definitionen, Akronyme und Abkürzungen ................................................................................................ 3
1.5 Referenzen ................................................................................................................................................ 3
2 Risiken .......................................................................................................................................................... 4
3 Massnahmen ................................................................................................................................................ 5
3.1 Eingeleitete Massnahmen .......................................................................................................................... 5
3.2 Nicht eingeleitete Massnahmen ................................................................................................................. 6
RK_PADMAN_Risikokatalog_V01.06.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
2/6
Projektname
Dokumenttitel
Artifaktname
1
Corp_PadMan
Risikokatalog
Risikokatalog
Informationstechnologie
Allgemeines
1.1
Zweck
Der Risikokatalog enthält die Auflistung aller Risiken mit deren Bewertung und aller Massnahmen mit deren
Auswirkungen.
1.2
Beschreibung
Die Risiken und Massnahmen werden gesammelt und im Risikokatalog aufgelistet und erklärt. Die Risiken werden bewertet. Dabei kommen entsprechende Hilfsmittel, Messinstrumente und -kriterien (aus dem RM-Plan) zum
Einsatz. Die Auswirkungen der Massnahmen erfolgt indirekt mittels erneuter Risikobeurteilung oder mittels
Feedbacks der Betroffenen zu den eingeleiteten Massnahmen. Der Risikokatalog ist ein dynamisches Dokument
und wird dementsprechend oft in Form einer Tabelle erstellt. Die Archivierung der älteren Versionen, bzw. Ergebnisse muss sichergestellt sein.
1.3
Tailoring
Der Risikokatalog kann in kleinen Projekten weggelassen werden, falls die Überwachung und Auflistung der
Risiken und Massnahmen im RM-Bericht erfolgt.
1.4
Definitionen, Akronyme und Abkürzungen
Wort
Definition
PWW
Post Wide Web – Intranet der Schweizerischen Post
1.5
Referenzen
Nr.
Titel
[01]
[02]
[03]
Checkliste PWW Projekt für Corp_PadMan: CH_PADMAN_ChecklistPWWProjekt.xlsx
Checkliste PWW Projekt für Corp_LogObi: CH_LOGOBI_ChecklistPWWProjekt.xlsx
Checkliste PWW Projekt für Corp_JobMonitor: CH_JOBMON_ChecklistPWWProjekt.xlsx
RK_PADMAN_Risikokatalog_V01.06.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
3/6
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Risikokatalog
Risikokatalog
Informationstechnologie
2
Risiken
ID
Risiko
R01
Akzeptanz der Projektdurchführung bei der
Leitung
Stabilität des Systems (Fehleranfälligkeit,
Performance, etc.)
Zeit – Die Terminsetzung ist von Beginn an
sehr sportlich.
R04
Ressourcenausfall (Person)
R05
Vollständiges Ersetzen und Abschalten der
bestehenden Applikationsverwaltung nicht
möglich.
Bestehende Intranet-Applikationen funktionieren mit neuer Umgebung nicht mehr
und müssen bis zur Einführung aufgrund
Inkompatibilität publiziert werden.
Neue Konzepte der Applikationsverwaltung
werden von den Benutzern nicht verstanden.
Ungenügende Software-Qualität: die neuen
Applikationen sind nicht einsatzfähig oder
werden nicht akzeptiert.
R02
R03
R06
R07
R08
Legende:
Kleines Risiko
RK_PADMAN_Risikokatalog_V01.06.docx
Status
Vorbeugende
Massnahmen
R01M01
Verantwortlich
Termin
Irminger Pascal
24.10.2011
R02M01
Irminger Pascal
28.03.2012
R03M01,
R03M02,
R03M03,
R03M04
R04M01,
R04M02,
R04M03,
R04M04
R05M01,
R05M02
Irminger Pascal
28.03.2012
Irminger Pascal
28.03.2012
Irminger Pascal
28.03.2012
R06M01,
R06M02
Irminger Pascal
28.03.2012
R07M01
Irminger Pascal
28.03.2012
R08M01,
R08M02,
R08M03
Irminger Pascal
28.03.2012
Mittleres Risiko
© Die Schweizerische Post
Ausgabedatum 28.03.2012
Grosses Risiko
4/6
Projektname
Dokumenttitel
Artifaktname
3
3.1
ID
Corp_PadMan
Risikokatalog
Risikokatalog
Informationstechnologie
Massnahmen
Eingeleitete Massnahmen
Massnahmenbeschreibung
R01M01
R02M01
Die Leitung wird so früh
wie möglich ins Boot geholt und darf laufend
mitentscheiden.
Anwenden von Unit-Tests,
etc.
R03M01
Rollende Taskplanung
(iterativ) und -kontrolle
durchführen.
R03M02
Umzusetzende Tasks definieren und priorisieren.
R03M03
PadMan-Features streichen:
Component löschen
R03M04
LogObi-Features streichen:
Applikation je LogEvent
ansehen
Auswertungen ansehen
Reserven einplanen
R04M01
R04M02
Reserven prüfen und gegebenenfalls nutzen
R04M03
Stellvertretung Projektleiter definieren.
R04M04
Rigoroses Changemanagement.
RK_PADMAN_Risikokatalog_V01.06.docx
Soll-Auswirkung
Datum der
Umsetzung
Ist-Auswirkung
Akzeptanz steigern.
24.10.2011
Projekt wird akzeptiert und unterstützt.
Funktionalität
sicherstellen, Refactoring-Qualität
erhöhen.
Endtermin kann
eingehalten werden.
laufend
Vorgehen hat sich
als gut erwiesen.
28.03.2012
laufend
28.03.2012
Es wird klar, welche Features wegfallen würden, so
dass der Endtermin eingehalten
werden kann.
Endtermin kann
eingehalten werden
05.12.2011
Ressourcenengpässe wurden
frühzeitig erkannt
und Nice-to-haveAnforderungen
konnten gestrichen werden.
Am KernteamMeeting wurden
die neuen Features diskutiert
und priorisiert.
19.02.2012
Endtermin kann
eingehalten werden
19.02.2012
Projektumfang
wurde gekürzt.
Endtermin wieder
realistisch.
Projektumfang
wurde gekürzt.
Endtermin wieder
realistisch.
Puffer haben für
Unvorhergesehenes.
Puffer für Unvorhergesehenes
einsetzen, ohne
die Anforderungen kürzen zu
müssen.
Projekt kann bei
Ausfall Projektleiter am Laufen
gehalten werden.
Feature Requests,
welche von aussen hinzukommen, sollen auf
nach dem Projekt
verschoben werden.
21.11.2011
Puffer haben für
Unvorhergesehenes.
Puffer aufgebraucht. Weiterer
ungeplanter Ausfall resultiert in
Kürzung der Anforderungen.
Projekt kann bei
Ausfall Projektleiter am Laufen
gehalten werden.
Vorgehen hat sich
als gut erwiesen.
21.11.2011
19.02.2012
laufend
21.12.2012
laufend
© Die Schweizerische Post
Ausgabedatum 28.03.2012
Beurteilung
der IstAuswirkung
24.10.2011
05.12.2011
19.02.2012
24.01.2012
21.12.2012
28.03.2012
5/6
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Risikokatalog
Risikokatalog
Informationstechnologie
ID
Massnahmenbeschreibung
Soll-Auswirkung
Datum der
Umsetzung
Ist-Auswirkung
R05M01
Frühzeitige Analyse der
Ist-Situation und sämtlicher Schnittstellen.
Migrationsqualität
maximal.
laufend
R05M02
Vorzeitige vorübergehende Umschaltungen vor
eigentlicher Migration
einplanen, durchführen
und analysieren.
Migrationsqualität
erhöhen.
08.03.2012
15.03.2012
R06M01
Design wird insofern erarbeitet, dass die Publikation keine IntranetApplikation betrifft.
Losgelöste produktive
Tests vor der Inbetriebsetzung.
Vereinfachung der
Migration.
laufend
Vorgehen hat sich
als gut erwiesen.
Missachtete
Schnittstellen
wurden während
den Testmigrationen entdeckt und
konnten behoben
werden.
Vorgehen hat sich
als gut erwiesen.
Missachtete
Schnittstellen
wurden während
den Testmigrationen entdeckt und
konnten behoben
werden.
Vorgehen hat sich
als gut erwiesen.
Produktive Lauffähigkeit vor Inbetriebsetzung sichergestellt.
08.03.2011
R07M01
Planung eines KernteamMeetings pro Sprint.
laufend
R08M01
Planung von:
Unit-Tests
DB-Review
Core-Review
CI/CD-Tests
Usability-Check
Tests und Reviews tracken.
Nutzen der Benutzer im Fokus
haben. Akzeptanz
der Anwendung
erhöhen.
Prozesse sind
eingehalten.
Software kann
störungsfrei eingeführt werden.
Software kann
störungsfrei eingeführt werden.
laufend
Abhängigkeiten
sind bekannt.
05.12.2011
R06M02
R08M02
R08M03
Organisation von Kernteam-Meetings, um Abhängigkeiten frühzeitig zu
erkennen.
09.12.2011
Beurteilung
der IstAuswirkung
28.03.2012
28.03.2012
28.03.2012
Vorgehen hat sich
als gut erwiesen.
Missachtete
Schnittstellen
wurden während
den Testmigrationen entdeckt und
konnten behoben
werden.
Ideen und Prozesse werden kritisch
hinterfragt. Anforderungen werden priorisiert.
Prozesse sind
eingehalten.
Software kann
störungsfrei eingeführt werden.
28.03.2012
Reviews sind –
wenn auch etwas
spät – alle erledigt.
Am KernteamMeeting wurden
Abhängigkeiten
besprochen.
28.03.2012
05.03.2012
09.12.2011
05.12.2011
3.2
Nicht eingeleitete Massnahmen
Keine.
RK_PADMAN_Risikokatalog_V01.06.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
6/6
Masterthesis „Renewal TeamPortal“
Projektplan
Risikokatalog
Situationsanalyse
Corp_PadMan – Systemanforderungen
Corp_PadMan – Systemdesign
Corp_LogObi – Systemanforderungen
Corp_LogObi – Systemdesign
Corp_JobMonitor – Systemanforderungen
Corp_JobMonitor – Systemdesign
Migration (in der publizierten Version nicht enthalten)
Die Schweizerische Post
Informationstechnologie
Situationsanalyse
Dokumentart
Titel
Projektname
Projektabkürzung
Projektmanager
Ausgabedatum
Autor
Übermittler
Empfänger
Klassifizierung
SI
Situationsanalyse Corp_PadMan
Corp_PadMan
PADMAN
Irminger Pascal, IT133
29.03.2012
Zenklusen Axel, IT131
Irminger Pascal, IT133
Irminger Pascal, IT133; Lehmann Marcel, IT132; Zenklusen Axel, IT131; Haefeli Stefan,
IT132
Nicht klassifiziert
Änderungskontrolle
Version
Datum
Überarbeitung
Ersteller
Freigabe
X01.00
24.10.2011
Neues Dokument
X01.01
21.11.2011
X01.02
V01.02
22.11.2011
05.12.2011
Haefeli Stefan, IT132
X02.00
28.03.2012
Analyse Usability-Fragebogen hinzugefügt
Ergänzung Job-Journal, Jobübersicht
Freigabe aufgrund KernteamMeeting
Schlussanalyse hinzugefügt
Zenklusen Axel,
IT131
Lehmann Marcel,
IT132
Irminger Pascal, IT133
Irminger Pascal, IT133
V02.00
29.03.2012
Freigabe
Lehmann Marcel,
IT132
Irminger Pascal, IT133
Haefeli Stefan, IT132
SI_PADMAN_Situationsanalyse_V02.00.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
1/18
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
Inhaltsverzeichnis
1 Allgemeines .................................................................................................................................................. 3
1.1 Zweck ........................................................................................................................................................ 3
1.2 Beschreibung ............................................................................................................................................. 3
1.3 Definitionen, Akronyme und Abkürzungen ................................................................................................ 3
1.4 Referenzen ................................................................................................................................................ 3
2 Beschreibung des Ist-Systems ........................................................................................................................ 3
2.1 Übersicht ................................................................................................................................................... 3
2.1.1 Teamportal ............................................................................................................................................. 3
2.1.2 LogEventViewer ...................................................................................................................................... 3
2.1.3 Job-Journal / Jobübersicht ....................................................................................................................... 3
2.2 Funktionen ................................................................................................................................................ 4
2.2.1 Applikationsverwaltung .......................................................................................................................... 4
2.2.2 Jobübersicht ........................................................................................................................................... 4
2.2.3 Auswertung USP ..................................................................................................................................... 4
2.2.4 Relink ..................................................................................................................................................... 4
2.2.5 Brokenlinks ............................................................................................................................................. 4
2.2.6 Shortcuts ................................................................................................................................................ 5
2.2.7 LogEventViewer ...................................................................................................................................... 5
2.2.8 Job-Journal ............................................................................................................................................. 5
2.3 Datenfelder................................................................................................................................................ 6
2.3.1 Applikationsverwaltung .......................................................................................................................... 6
2.3.2 LogEventViewer ...................................................................................................................................... 7
2.4 Abhängigkeiten (Fremdzugriff) .................................................................................................................. 7
2.4.1 Teamportal ............................................................................................................................................. 7
2.4.2 LogEventViewer ...................................................................................................................................... 9
2.4.3 Job-Journal (SysLog) / Jobübersicht ......................................................................................................... 9
3 Usability Fragebogen .................................................................................................................................. 10
3.1 Auswertung ............................................................................................................................................. 12
3.2 Analyse .................................................................................................................................................... 14
4 Schwachstellenanalyse ................................................................................................................................ 14
4.1 Teamportal............................................................................................................................................... 14
4.2 LogEventViewer ....................................................................................................................................... 15
4.3 Job-Journal / Jobübersicht ........................................................................................................................ 15
5 Sicherheit.................................................................................................................................................... 15
5.1 Teamportal............................................................................................................................................... 15
5.2 LogEventViewer ....................................................................................................................................... 15
5.3 Job-Journal / Jobübersicht ........................................................................................................................ 15
6 Zukünftige Entwicklung .............................................................................................................................. 15
6.1 Teamportal............................................................................................................................................... 15
6.2 LogEventViewer ....................................................................................................................................... 16
6.3 Job-Journal / Jobübersicht ........................................................................................................................ 16
7 Schlussanalyse ............................................................................................................................................ 16
7.1 Auswertung ............................................................................................................................................. 16
7.2 Analyse und Fazit ..................................................................................................................................... 18
SI_PADMAN_Situationsanalyse_V02.00.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
2/18
Projektname
Dokumenttitel
Artifaktname
1
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
Allgemeines
1.1
Zweck
Die Situationsanalyse beschreibt und analysiert die gegenwärtige Situation und die zukünftigen Entwicklungen
im Untersuchungsbereich des Systems.
1.2
Beschreibung
Die Situationsanalyse bildet zusammen mit den Systemzielen die fachliche Basis für die Definition der vom zukünftigen System zu erfüllenden Systemanforderungen.
1.3
Definitionen, Akronyme und Abkürzungen
Wort
Definition
HTTP
PWW
SSIS
SQL
Hypertext Transfer Protocol – Protokoll zur Übertragung von Daten über ein Netzwerk
Post Wide Web – Intranet der Schweizerischen Post
SQL Server Integration Services
Structured Query Language
1.4
Referenzen
Keine.
2
Beschreibung des Ist-Systems
2.1
Übersicht
2.1.1 Teamportal
Das Teamportal wird für die Unterstützung der Entwicklung von Applikationen verwendet. Dabei werden Daten
für den Betrieb einer Applikation verwaltet sowie auch Portfolio-Angaben (Hermes etc.) erfasst. Zusätzlich werden auch Personen mit ihrer Rolle zu einer Applikation angegeben.
Für den Betrieb einer Applikation ist die Erfassung des ConnectionStrings für den Datenbankzugriff essentiell.
Zu diesen Hauptfunktionen wurde das Teamportal für das Verwalten des Intranets PWW erweitert. Es ist möglich, eine Serveranfrage sowohl von fehlenden Dateien als auch von existierenden Seiten umzuleiten (Shortcuts
http://pww.post.ch/wcm => http://pww.post.ch/appl/corp/wcm). Auch kann ein Reporting über die HTTPAntwort 404 erstellt werden.
2.1.2 LogEventViewer
Der LogEventViewer holt die Logs aus der Applikation Teamportal und zeigt diese dem Entwickler an. Die Logs
werden von der Library ins Teamportal geschrieben.
2.1.3 Job-Journal / Jobübersicht
Das Job-Journal ist eine weitere bestehende Intranet-Applikation. Es dient als Hilfsmittel zur Überwachung der
SSIS-Jobs, resp. deren Steps (ein Job kann mehrere Steps haben), und zeigt deren Logs an. Es bezieht die LogDaten direkt aus der Datenbank, in welche der SSIS hinein loggt.
Weiter werden auf den Datenbank-Servern regelmässig Traces aufgezeichnet. Das bestehende Job-Journal bietet
eine Webpage, welche diejenigen SQL-Queries mit mehr als 10‘000 Logical Reads anzeigt (konfigurierbar).
Eine weitere Webpage zeigt Indexes, welche der Datenbank-Server zu den bereits bestehenden Indexes dazu
empfehlen würde. Diese Informationen werden direkt aus Systemtabellen des SQL Servers bezogen.
Die Jobübersicht ist eine weitere Software-Komponente, worin die Jobs überwacht werden können. Die Jobübersicht ist direkt in das bestehende Teamportal integriert. Es erhält periodisch Informationen aus der Systemdatenbank msdb des SQL Server Agent, welche verschiedene Daten sämtlicher Jobs, wie z.B. Job-Schedules und
Job-Runs beinhaltet.
Den einzelnen Jobs können hier Bemerkungen hinzugefügt werden. Beispielsweise wird zu einem Job die Information hinterlegt, wie schwerwiegend ein Error-Run ist, damit der entsprechende Datenbankadministrator weiss,
ob der Job im Fehlerfall manuell angestossen werden soll.
SI_PADMAN_Situationsanalyse_V02.00.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
3/18
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
2.2
Funktionen
2.2.1 Applikationsverwaltung
Nr. Kontext
1
Applikationen-Übersicht
2
Applikation-Übersicht
3
4
5
6
7
Kategorie
Personen
Hermes Light
Portfolio
Dokumente
2.2.2 Jobübersicht
Nr. Kontext
1
Übersicht
2.2.3 Auswertung USP
Nr. Kontext
1
Übersicht
2.2.4 Relink
Nr. Kontext
1
Übersicht
2.2.5 Brokenlinks
Nr. Kontext
1
Übersicht
SI_PADMAN_Situationsanalyse_V02.00.docx
Informationstechnologie
SubNr.
1
2
3
4
5
6
7
1
2
1
1
1
1
1
2
Funktion
Applikation erstellen
Applikation anzeigen
Applikation suchen
Applikation im SendTo hinzufügen
Applikation kopieren
Applikation filtern
Applikation löschen
Applikationsdaten CRUD
ConnectionString CRUD
Kategorien (read, update)
Personen und ihre Rollen CRUD
Hermes-Volltext (read, update)
Portfolio-Volltext (read, update)
Links zu Dokumente CRUD
Weitere Angaben zu (Abhängigkeiten, Pendenzen, Problembehandlung, Schnittstellen, Überwachung und Wiederkehrende Aufgaben) CRUD
SubNr.
1
2
3
4
5
6
Funktion
Jobs anzeigen
Jobs filtern
Job Datensatz löschen
Job „obsolete“ setzen
Job-Runs als „erledigt“ markieren
Log von Job-Runs anzeigen
SubNr.
1
2
Funktion
Anzeigen
Auswertung starten
SubNr.
1
2
3
4
5
6
Funktion
Anzeigen
Filtern
Löschen
Bearbeiten
Kopieren
Erstellen
SubNr.
1
2
3
4
5
Funktion
Anzeigen
Filtern
Löschen
Mail an Entwickler senden
Umgebung wechseln (Production, Integration, Development)
© Die Schweizerische Post
Ausgabedatum 29.03.2012
4/18
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
2.2.6 Shortcuts
Nr. Kontext
1
Übersicht
2.2.7 LogEventViewer
Nr. Kontext
1
Filter nach
2
Übersicht
2.2.8 Job-Journal
Nr. Kontext
1
Filter nach
2
Übersicht
SI_PADMAN_Situationsanalyse_V02.00.docx
Informationstechnologie
SubNr.
1
2
3
4
Funktion
Anzeigen
Löschen
Bearbeiten
Testen
SubNr.
1
2
3
4
5
6
7
8
9
10
11
1
Funktion
Applikations-ID
Meine Applikationen
Meine Applikationen inkl. Stellvertretung
Level (Fatal, Error, Warnung, Info)
Datum
Benutzer
Maschine
Platform (Intranet, Extranet etc)
Environment (Dev, Int, Prod)
Pfad
Schlüsselwort
Löschen
SubNr.
1
2
3
1
2
Funktion
Job-Name
AID (Application-ID)
Job-Type (DTS/VBS, SSIS)
Details zu Job-Steps anzeigen
Job-Stets als „erledigt“ markieren
© Die Schweizerische Post
Ausgabedatum 29.03.2012
5/18
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
2.3
Datenfelder
2.3.1 Applikationsverwaltung
Im untenstehenden Bild sind die wichtigsten Tabellen zur Verwaltung der Applikationen dargestellt.
tabApplicationInfo (dbo)
tabApplication (dbo)
lngIID
strAID
strAID
strDescriptionD
intType
strDescriptionF
strHeader
strDescriptionI
memDesc
strDescriptionE
dtmUpdate
strUser
lngNoteTypeID
tabMatrixApplCategory (dbo)
lngMACID
strAID
lngCategoryID
dtmUpdate
strUser
lngStateID
strConnUserID
strConnUserDBName
tabCategory (dbo)
strConnUserPassword
lngCategoryID
strConnUserOptions
strDescD
intTimeOut
strDescF
strConnAdminID
strDescI
strConnAdminDBName
intType
strDescE
strConnAdminPassword
strBookmark
bitActive
strDBServer
strHeaderD
dtmUpdate
strVersion
strHeaderF
strUser
dtmDate
strHeaderI
strContactPerson
strHeaderE
memOrder
tabApplicationInfoTypes (dbo)
memDescription
memCost
tabSensibility (dbo)
memQuantum
lngSensibilityID
memFeature
strBookmark
dtmStartDate
strSensibilityD
dtmEndDate
strSensibilityF
dtmOfferDate
strSensibilityI
curOfferAmount
strSensibilityE
intWorkingDays
bitActive
strUrlUser
strUrlAdmin
strDirectory
tabMatrixAccount (dbo)
lngMatrixAccountID
strAID
strUser
strNTAccount
strSID
lngAccountTypeID
bitActive
dtmUpdate
strUserUpdate
strComment
bitDefault
memComment
curRunningCosts
bitAspNet
tabConnectionString (dbo)
lngCSID
strAID
strKey
strUserID
strDBName
strPassword
strOptions
intTimeOut
strSqlServer
dtmInsert
strInsertUser
dtmUpdate
strUpdateUser
memAspNetFunctiona...
bitExtranet
memExtranetFunction...
memSubstituteInfo
lngSensibilityID
bitDebug
bitSearch
bitOutOfOrder
dtmUpdate
strUser
strEntwickler
strStellvertreter
tabApplicationState (dbo)
lngStateID
strBookmark
strDescD
strDescF
strDescI
strDescE
bitShowWeak
_orgID
strBezD
strBezF
strBezI
dtmDatum
strWeiterePersonen
strKontakt
memPortfolio
SI_PADMAN_Situationsanalyse_V02.00.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
6/18
Projektname
Dokumenttitel
Artifaktname
2.3.2
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
LogEventViewer
Applikations-ID
Beschreibung
Entwickler
Stellvertreter
Kontakt
Maschine
Environment
Platform
Benutzer
Pfad
App-Properties (immer Leerstring)
Message
Exception
Zeit [ms]
RecordNbr
Prozess-ID
Thread-ID
Browser
Level
2.4
Abhängigkeiten (Fremdzugriff)
2.4.1 Teamportal
Die Datenbank des Teamportals wird von einigen Anwendungen benutzt.
Corp_Access
Zugriffsberechtigungsverwaltung für unsere Applikationen.
Zugriff scheint noch ohne Views zu sein.
Corp_Alarming
Alarmierung bei speziellen Ereignissen/Gegebenheiten (applikationsspezifisch).
Zugriff über Views.
CREATE VIEW dbo.qryMandantView
AS
SELECT DISTINCT
dbo.tabMandant.bitUsePikettPlan
,dbo.tabMandant.bitLogging
,dbo.tabMandant.bitWarnLongDuration
,dbo.tabMandant.dtmInsert
,dbo.tabMandant.strInsertUser
,dbo.tabMandant.dtmUpdate
,dbo.tabMandant.strUpdateUser
,dbo.tabMandant.strApplID
,va.strDescriptionD
,va.strDescriptionF
,va.strDescriptionI
,va.strDescriptionE
,va.strDevCalc AS strEntwickler
,va.strDepCalc AS strStellvertreter
,va.lngStateID
FROM
Corp_TeamPortal.dbo.qryViewApplication AS va RIGHT OUTER JOIN
dbo.tabMandant ON va.strAID = dbo.tabMandant.strApplID
SI_PADMAN_Situationsanalyse_V02.00.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
7/18
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
CREATE VIEW dbo.qryUserApplication
AS
SELECT ap.strAID
,ap.strNTAccount
,ap.bitActive
,ap.bitDefault
,e.strEmail
,e.strPhone
,e.strMobilePrivate
,dbo.tabAlarmGroup.bitSMSToDeveloper
,dbo.tabAlarmGroup.bitEmailToDeveloper
,dbo.tabAlarmGroup.bitEmailToStv
,dbo.tabAlarmGroup.bitSMSToStv
,dbo.tabAlarmGroup.lngAlarmGroupID
,CASE lngAccountTypeID
WHEN 1
THEN 'DEV'
ELSE
CASE lngAccountTypeID
WHEN 2
THEN 'DEP'
ELSE 'unknown'
END
END AS strAccountType
FROM
Corp_TeamPortal.dbo.tabMatrixAccount AS ap LEFT OUTER JOIN
Corp_MetaData.dbo.qryOrgEmployee AS e
ON e.strUserID = ap.strNTAccount RIGHT OUTER JOIN
dbo.tabAlarmGroup ON ap.strAID = dbo.tabAlarmGroup.strApplID
WHERE ap.bitActive = 1 AND ap.lngAccountTypeID IN (1, 2)
CREATE VIEW dbo.qryMandantSettings
AS
SELECT DISTINCT
dbo.tabAlarmGroup.lngAlarmGroupID
,dbo.tabAlarmGroup.strName
,dbo.tabAlarmGroup.strApplID AS strGroupOwnerApplId
,dbo.tabAlarm.strApplID AS strGroupUserApplId
,dbo.tabAlarmGroup.dtmInsert
,dbo.tabAlarmGroup.strInsertUser
,dbo.tabAlarmGroup.dtmUpdate
,dbo.tabAlarmGroup.strUpdateUser
,dbo.tabAlarmGroup.bitSMSToDeveloper
,dbo.tabAlarmGroup.bitEmailToDeveloper
,dbo.tabAlarmGroup.bitEmailToStv
,dbo.tabAlarmGroup.bitEmailToPwwAdmin
,dbo.tabAlarmGroup.strDefaultEmailReceiver
,dbo.tabAlarmGroup.strDefaultSMSReceiver
,dbo.tabAlarmGroup.bitSMSToStv
,dbo.tabAlarmGroup.bitGlobalAlarmGroup
,Corp_TeamPortal.dbo.qryViewApplication.strDevCalc AS strDevelopers
,Corp_TeamPortal.dbo.qryViewApplication.strDepCalc AS strDeppen
FROM
Corp_TeamPortal.dbo.qryViewApplication RIGHT OUTER JOIN
dbo.tabAlarmGroup
ON Corp_TeamPortal.dbo.qryViewApplication.strAID =
dbo.tabAlarmGroup.strApplID LEFT OUTER JOIN
dbo.tabAlarm
ON dbo.tabAlarmGroup.lngAlarmGroupID = dbo.tabAlarm.lngAlarmGroupID
SI_PADMAN_Situationsanalyse_V02.00.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
8/18
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
Corp_IISStatisticTool
Anzeige was auf unseren Datenbankservern so läuft.
Zugriff unklar. In Abklärung bei Heuberger Cedric.
Corp_Impressum
Anzeige des Impressums in den Anwendungen.
Zugriff scheint noch ohne Views zu sein. Entwickler Heuberger Cedric ist schon vorinformiert.
Corp_KDPService
Kundendaten Post.
Zugriff unklar. Robert Marti weiss mehr.
Corp_LogEventViewer
Log Anzeige (wird abgelöst durch Corp_LogObi).
Corp_Marge
Mandantenfähige Auftragsgenerierung.
SELECT
strAID AS lngID
,strDescriptiond + ' ('+ strAid + ')' AS strBez
,ROW_NUMBER() over (order by strDescriptionD) as RowNumber
FROM
Corp_Teamportal.dbo.qryApplData WITH (NOLOCK)
WHERE
strState = 'Appl'
ORDER BY 3
Corp_SendTo06
Deployment-Werkzeug.
2.4.2 LogEventViewer
Es bestehen keine Abhängigkeiten.
2.4.3 Job-Journal (SysLog) / Jobübersicht
Es bestehen keine Abhängigkeiten.
SI_PADMAN_Situationsanalyse_V02.00.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
9/18
Projektname
Dokumenttitel
Artifaktname
3
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
Usability Fragebogen
Für das bestehende Teamportal wurde ein Usability Fragebogen bei ausgewählten Personen der Abteilung IT13
verteilt. Diese Umfrage besteht aus folgenden Fragen:
ID
Fragestellung
1
Insgesamt bin ich mit der Applikationsverwaltung zufrieden.
2
Das Layout der Seiten ist übersichtlich.
3
Die Schrift ist immer gut lesbar.
4
Es ist zu jeder Zeit klar ersichtlich, welche Funktionen mir zur
Verfügung stehen.
5
Es ist jederzeit klar ersichtlich, für welche Umgebung
(Dev/Int/Prod) ich Daten sehe bzw. bearbeite.
6
Die Applikation kann ich leicht bedienen.
7
Die Bedienung der Applikation ist intuitiv.
8
Ich komme mit wenigen Klicks an die gewünschten Informationen.
9
Die Seiten werden schnell geladen.
10
Die Applikation unterstützt mich.
11
Die Informationen sind für mich verständlich und logisch.
12
Verstehe ich etwas nicht, so erhalte ich von der Applikation eine
Hilfestellung.
13
Ich finde meine Applikationen leicht.
14
Die Suchfunktion hilft mir eine Applikation zu finden.
15
Der Aufbau ist für mich logisch (Startseite).
16
Die angezeigten Informationen sind für mich nutzlos (Startseite).
SI_PADMAN_Situationsanalyse_V02.00.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
Trifft
zu
Trifft
eher
zu
Trifft
eher
nicht
zu
Trifft
nicht
zu
++
+
-
--
10/18
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
Die folgenden Aussagen betreffen deine Aufgabe bzw. Funktion.
ID
Fragestellung
Trifft
zu
Trifft
eher
zu
Trifft
eher
nicht
zu
Trifft
nicht
zu
++
+
-
--
17
Die Applikation unterstützt mich.
18
Ich erhalte genug Informationen.
19
Ich komme mit wenigen Klicks zu meinen Informationen.
20
Informationen sind an einem Ort vorhanden.
21
Die Suche bietet mir genug Funktionen, um an meine Informationen zu gelangen.
22
Bitte beschreibe deine Ziele in Stichworten, welche Du mit der Applikation erreichen willst. (z.B. Um
den Verantwortlichen zu wissen oder für die Stellvertreter-Infos).
ID
23
Fragestellung
Wie häufig verwendest Du die Applikation (1 = nie / 6 =
täglich).
ID
24
Fragestellung
In welcher Rolle bzw. Aufgabe benutzt Du
die Applikation am häufigsten? (Mehrfachauswahl möglich).
25
Falls Dir eine wichtige Funktion fehlt, trage dies bitte in folgendes Feld.
SI_PADMAN_Situationsanalyse_V02.00.docx
Entwickler
1
2
Support
© Die Schweizerische Post
Ausgabedatum 29.03.2012
3
4
Wartung
5
6
Manager
11/18
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
26
Falls Du einen Kommentar (besonders gut/besonders schlecht) oder Verbesserungsvorschläge hast,
trage dies bitte in folgendes Feld ein.
27
Falls Du eine Anregung beliebiger Form zu dieser Umfrage hast, trage dies bitte in folgendes Feld ein.
3.1
Auswertung
Beim Mittelwert wurde der tiefste Wert sowie der höchste Wert entfernt. Textantworten wurden 1:1 übernommen und Rechtschreibfehler nicht korrigiert.
ID
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Fragestellung
Insgesamt bin ich mit der Applikationsverwaltung
zufrieden.
Das Layout der Seiten ist übersichtlich.
Die Schrift ist immer gut lesbar.
Es ist zu jeder Zeit klar ersichtlich, welche Funktionen mir zur Verfügung stehen.
Es ist jederzeit klar ersichtlich für welche Umgebung (Dev/Int/Prod) ich Daten sehe bzw. bearbeite.
Die Applikation kann ich leicht bedienen.
Die Bedienung der Applikation ist intuitiv.
Ich komme mit wenigen Klicks an die gewünschten Informationen.
Die Seiten werden schnell geladen.
Die Applikation unterstützt mich.
Die Informationen sind für mich verständlich und
logisch.
Verstehe ich etwas nicht, so erhalte ich von der
Applikation eine Hilfestellung.
Ich finde meine Applikationen leicht.
Die Suchfunktion hilft mir eine Applikation zu
finden.
Der Aufbau ist für mich logisch (Startseite).
Die angezeigten Informationen sind für mich
nutzlos (Startseite).
Die Applikation unterstützt mich.
Ich erhalte genug Informationen.
SI_PADMAN_Situationsanalyse_V02.00.docx
Mittelwert
3.6
Minimalwert
0
Maximalwert
6
3.2
5.2
2.8
2
4
2
6
6
4
4.8
2
6
3.6
3.2
3.2
2
2
0
6
4
6
4
3.2
4
2
2
2
6
6
6
0.4
0
2
4.8
5.6
4
2
6
6
4
1.6
2
0
6
4
4
3.2
2
2
6
6
© Die Schweizerische Post
Ausgabedatum 29.03.2012
12/18
Projektname
Dokumenttitel
Artifaktname
ID
19
20
21
23
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
Fragestellung
Ich komme mit wenigen Klicks zu meinen Informationen.
Informationen sind an einem Ort vorhanden.
Die Suche bietet mir genug Funktionen um an
meine Informationen zu gelangen.
Wie häufig verwendest Du die Applikation (1 =
nie / 6 = täglich).
Mittelwert
4
Minimalwert
2
Maximalwert
6
3.2
3.6
2
2
4
6
4.8
3
6
ID
24
Fragestellung
In welcher Rolle bzw. Aufgabe benutzt Du die Applikation am häufigsten? (Mehrfachauswahl möglich).
Entwickler
85%
Support
14%
Wartung
28%
Manager
14%
ID
22
Fragestellung
Bitte beschreibe deine Ziele in Stichworten, welche Du mit der Applikation erreichen willst. (z.B. Um
den Verantwortlichen zu wissen oder für die Stellvertreter-Infos).
Als Stellvertreter möchte ich dort
- Informationen zu Spezialitäten der Applikation finden
- Informationen zu Schnittstellen finden
- Kontaktangaben (Kunde/Majoruser) finden
Für meine eigenen Applikationen möchte ich
- Kontaktangaben (Kunde/Majoruser) finden
- Möglichst einfach meine Applikationen pflegen
- Sqlinstanz sehen
- Pfad auf die Applikation
-Verantwortlicher/Stellvertreter einer Applikation ermitteln.
-Die wichtigsten Informationen zur Applikation Konzept, ERM, anderen Projektspezifischen Dokumente,
u.s.w. schnell und einfach zugänglich machem
-Stellvertreter-Infos
-Verwalten von Applikationseigenschaften(Name, DB, etc.)
- Was für Komponenten gibt es?
- Dokumente?
- Release?
- Personen?
- Jobs, Schnittstellen?
- Applikationen finden
- Fehler einer Applikation anschauen.
- Welche Applikationen setzten welche Technologien ein ( zur Suche von Beispielcode)
- Statis der Applikationen anschauen
- Personalisierte Startseite (welche Applikationen mit welchen Informationen will ich sehen)
- Mehr Hilfe
- Projektdekblatt sollte in der Applikationen geführt werden.
- Prozesse sollten besser in der Applikationen abgebildet und unterstützt werden.
z.B. Die Applikationen sollte Reminder zu den verschiednen Reviews verschicken ( in einem bestimmten
Intervall)
- Grössere Applikationen haben mehrere Releases, diese sollt besser getrennt sein.
z.B. Jeder Release hat seinen eigenen Dokumente wie Offerte, Spezifikation
- Suche nach Verantwortlichen und Kontaktpersonen
- Lesen von Infos für den Stv.
- Nachschlagen auf welcher DB eine Applikation ist
- Error-Log und Job-Kontrolle
SI_PADMAN_Situationsanalyse_V02.00.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
13/18
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
ID Fragestellung
25 Falls Dir eine wichtige Funktion fehlt, trage dies bitte in folgendes Feld.
Diverse einfache Management-Reportings,
Indikator, wie aktuell die Einträge sind
Die Auswertungen (USP) sind gut. Es wäre aber gut wenn man bei einzelnen Prozeduren noch mehr Filter
setzen könnte.
Erweiterte Suche z.B. nach Entwickler oder nach Appl für PF
- parktisch wäre auch wenn es schlaue Schnittstellen ev. Widgets zu den Applikationen ErrorLog, Deployment, Wiki, Translation, Access etc. gibt.
- ReleaseVerwaltung
- Todo-Liste
- ausgebaute API für andere Applikationen
Suche sollte optimiert werden. Es sollte die Möglichkeit geben gewisse Begriffe zu einer Applikation als
Suchbegriffe hinzuzufügen, damit das Suchresultat besser ist.
-Suche über Einträge in alle Applikationen sollte möglich sein => z.B. welche Applikationen sind auf dem
SQL-Server 2
ID
26
Fragestellung
Falls Du einen Kommentar (besonders gut/besonders schlecht) oder Verbesserungsvorschläge hast,
trage dies bitte in folgendes Feld ein.
Suche ist heute nicht schlecht, Tab's haben sich auch bewährt
Hilfe unzureichend
Die Seite ViewApplication.aspx (Icon links) ist aus meiner Sicht unbrauchbar. --> Zuviele Infos, zuwenig
strukturiert.
Die Icons sind für mich nicht sprechend, diese könnten besser gewählt werden.
Weiter finde ich, dass das Tab mit dem vielen Hacken automatisch ausgefüllt werden sollt, oder zumindes
zum Teil. Lib kann anhand der DLL erkannt, welche im Projekt eingebunden werden usw.
Bei den Kategorien verliert man mittlerweile ein wenig den Überblick. Es sind so viele neu dazu gekommen. Eine optische Unterteilung in verschiedene Hauptthemen könnte hier helfen.
- Info für den Stv sollten strukturierter erfasst werden können.
- Erfasste Links und Doku übersichtlicher darstellen.
- Vorgabe was bei den Bemerkungen erfasst werden muss (z.B. Infos die die Leitung braucht)
- klarere Strukturierung und Auflistung aller möglichen "Tools" (Sendto, Translation, Relinks, Jobs, Alarming....) die es im Zusammenhang mit einer Applikation überhaupt gibt.
- Auf einen Blick sollte erkannt werden, was zu einer Applikation alles gehört. (von News, über Jobs,
Schnittstellen....)
ID
27
Fragestellung
Falls Du eine Anregung beliebiger Form zu dieser Umfrage hast, trage dies bitte in folgendes Feld
ein.
Freie "Tags" wären cool, nach welchen man sortieren/finden könnte
3.2
Analyse
Die Rollenverteilung entspricht in etwa der Verteilung innerhalb der Abteilung IT13. Bei der Rolle Manager ist
klar ersichtlich, dass diese Rolle in der aktuellen Applikation sehr wenig berücksichtigt wird.
Für die Entwickler sind die Informationen meist genügend. Handlungsbedarf ist hier bei der Usability angebracht.
Auch gibt es heute wenig bis keine Hilfestellung zu den einzelnen Funktionen bzw. Informationen. Für den
Grossteil der Suchanfragen genügt die bestehende Suche, es wäre aber wünschenswert, wenn hier die Suche
erweitert wird.
4
Schwachstellenanalyse
4.1
Teamportal
Die Applikation ist nun seit über 10 Jahren im Einsatz. In diesen Jahren wurden Anforderungen mit dem Ziel
möglichst schnell und kostengünstig implementiert. Ein Beispiel zeigt hier die Verwaltung der ConnectionStrings
im User-Interface wie auch in der Datenbankstruktur. Der Haupt-ConnectionString ist weiterhin in der Tabelle
tabApplication und wird im User-Interface weiterhin so dargestellt. Die neuen ConnectionStrings, welche
SI_PADMAN_Situationsanalyse_V02.00.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
14/18
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
anhand eines Keys unterschieden werden, durften in eine neue Tabelle und werden im User-Interface tabellarisch dem Benutzer angezeigt. Ein grosser Schwachpunkt der aktuellen Lösung ist die nicht vorhanden Historisierung.
Die Applikation Teamportal hat eine extrem hohe Wichtigkeit für den Betrieb der Applikationen im PWWUmfeld. Anhand den fortwährenden Anpassungen hat die Applikation einen Stand erreicht, dass niemand eine
neue Version publizieren will und falls es doch unumgänglich ist, ist dies mit enormem Zeitaufwand verbunden.
4.2
LogEventViewer
Wichtige Fehler können in der Anzeige schnell untergehen. Es ist nicht möglich die Fehler zu Gruppieren und so
kann ein wichtiger Fehler bei hoher Fehleranzahl untergehen. Auch werden die Fehler beim Entstehen direkt in
die Datenbank von Teamportal geschrieben. Falls nun eine Abfrage mit vielen Daten im LogEventViewer erstellt
wird, so kann dies eine produktive Applikation in die Knie zwingen.
Entstehen plötzlich Fehler welche nicht regelmässig auftreten, so muss unter Umständen der Entwickler von den
Benutzern der Applikation darüber informiert werden.
4.3
Job-Journal / Jobübersicht
Zumindest die Applikation Job-Journal ist schon einige Jahre alt, die Jobübersicht wurde dann später einmal dazu
implementiert. Die beiden Applikationen helfen dabei, die Jobs zu überwachen, sie arbeiten allerdings nicht mit
derselben Terminologie: die eine Applikation betrachtet die Jobs als Ganzes, die andere geht eine Detailstufe
tiefer und betrachtet die einzelnen Job-Steps.
5
Sicherheit
5.1
Teamportal
Im Verlauf der Betriebszeit sowie auch Entwicklungszeit wurde die Sicherheit nicht berücksichtigt. So werden
Account-Informationen sowohl ungeschützt in der Datenbank gespeichert als auch ungeschützt übermittelt und
angezeigt. Eine Rechteverwaltung der einzelnen Applikationen wurde ebenfalls nicht implementiert. Alle können
alles ändern.
5.2
LogEventViewer
Hier bestehen zur Zeit keine Sicherheitsbedürfnisse, welche mit der aktuellen Lösung nicht abgedeckt wurden.
5.3
Job-Journal / Jobübersicht
Hier bestehen zur Zeit keine Sicherheitsbedürfnisse, welche mit der aktuellen Lösung nicht abgedeckt wurden.
6
Zukünftige Entwicklung
6.1
Teamportal
Als die Applikation entwickelt wurde, hatten sehr viele Applikationen ein Budget um 10‘000 CHF. In der heutigen Situation sind die Budgets im Bereich von mehreren 10‘000 CHF bis zu mehreren 100‘000 CHF. Dadurch
sind die Bedürfnisse gestiegen und die Komplexität der Applikationen hat stark zu genommen. Auch werden die
Applikation untereinander immer mehr vernetzt, was zu Abhängigkeiten zwischen den Applikationen führte.
Diese Abhängigkeiten sollen in der Neu-Entwicklung besser dargestellt werden. Auch soll das Management mehr
Werkzeuge für das Administrieren aller Projekte in der Abteilung IT13 erhalten.
Den Entwicklern sollen der Projektstart vereinfacht werden. So soll ihnen das Aufsetzen eines Projektes (VS Solution) als auch das konfigurieren des Konfigurationsmangement abgenommen werden.
Damit mit der Neu-Entwicklung die aktuellen Schwachstellen vermieden werden können, soll die neue Applikation einfacher erweiterbar sein.
Applikationen werden immer komplexer und dies muss abgebildet werden können. Somit ist das Planen der
Releases und das zusammenfassen von fragmentierten Applikationen ein essenzieller Teil der Neuentwicklung.
Es soll auch mehrt Wert darauf gelegt werden, dass die Abläufe der Entwickler einfacher werden. Hierfür ist das
automatische weitergeben der Subversion-Berechtigungen und das Ablösen des Projektdeckblattes angedacht.
Falls man das Teamportal nicht von Grund auf neu entwickelt, werden so lange weitere „Flicke“ programmiert,
bis das Teamportal vollends nicht mehr wartbar ist. Falls dieser Moment erreicht wird, ist es klar, dass der Aufwand einer Neuimplementierung viel teurer wäre als dies jetzt der Fall ist.
SI_PADMAN_Situationsanalyse_V02.00.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
15/18
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
6.2
LogEventViewer
Zur Zeit hat der Entwickler für die Fehler eine Holschuld. Die neue Applikation soll es dem Entwickler ermöglichen, von bestimmte Ereignisse an Logs informiert zu werden.
Vom Entwickler definierte Filtern sollen abgespeichert werden. Auch sollen globale Filter, welche für alle Applikationen zur Verfügung stehen, erstellt werden können und so eine Wiederverwendbarkeit der Filter erreicht werden. Auch soll anhand eines Filters die Fehler gruppiert werden können und so dem Entwickler eine bessere
Übersicht von seinen Fehlern zu gewährleisten.
6.3
Job-Journal / Jobübersicht
Ziel ist es, eine neue Applikation zu erstellen, welche das Gute beider bestehender Applikationen verbindet und
auch die Datenquellen miteinander kombiniert. Derzeit prüft ein Datenbankadministrator manuell, welche Jobs
fehlgeschlagen sind und beurteilt zumeist selbständig, wie kritisch dies ist. Die neue Applikation soll bei Bedarf
ein aktives Alarming betreiben und die entsprechenden Entwickler informieren.
7
Schlussanalyse
Am Ende des Projektes wurde der gleiche Fragebogen nochmals an die Teilnehmer gesendet. Dieses Mal wurde
jedoch die neue Applikation Corp_PadMan, welche das Teamportal ablöst, untersucht.
7.1
Auswertung
Beim Mittelwert wurde der tiefste Wert sowie der höchste Wert entfernt. Textantworten wurden 1:1 übernommen und Rechtschreibfehler nicht korrigiert.
ID
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Fragestellung
Insgesamt bin ich mit der Applikationsverwaltung
zufrieden.
Das Layout der Seiten ist übersichtlich.
Die Schrift ist immer gut lesbar.
Es ist zu jeder Zeit klar ersichtlich, welche Funktionen mir zur Verfügung stehen.
Es ist jederzeit klar ersichtlich für welche Umgebung (Dev/Int/Prod) ich Daten sehe bzw. bearbeite.
Die Applikation kann ich leicht bedienen.
Die Bedienung der Applikation ist intuitiv.
Ich komme mit wenigen Klicks an die gewünschten Informationen.
Die Seiten werden schnell geladen.
Die Applikation unterstützt mich.
Die Informationen sind für mich verständlich und
logisch.
Verstehe ich etwas nicht, so erhalte ich von der
Applikation eine Hilfestellung.
Ich finde meine Applikationen leicht.
Die Suchfunktion hilft mir eine Applikation zu
finden.
Der Aufbau ist für mich logisch (Startseite).
Die angezeigten Informationen sind für mich
nutzlos (Startseite).
Die Applikation unterstützt mich.
Ich erhalte genug Informationen.
Ich komme mit wenigen Klicks zu meinen Informationen.
Informationen sind an einem Ort vorhanden.
Die Suche bietet mir genug Funktionen um an
meine Informationen zu gelangen.
SI_PADMAN_Situationsanalyse_V02.00.docx
Mittelwert
6
Minimalwert
2
Maximalwert
6
6
5.3
4.7
6
4
2
6
6
6
4
2
6
4.6
5.3
6
4
4
4
6
6
6
4.7
6
6
2
4
6
6
6
6
2.7
2
4
6
4.7
4
2
6
6
5.3
1
2
1
6
1
6
5.3
5.3
4
4
4
6
6
6
6
5.3
4
2
6
6
© Die Schweizerische Post
Ausgabedatum 29.03.2012
16/18
Projektname
Dokumenttitel
Artifaktname
ID
23
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
Fragestellung
Wie häufig verwendest Du die Applikation (1 =
nie / 6 = täglich).
Mittelwert
5.7
Minimalwert
5
Maximalwert
6
ID
24
Fragestellung
In welcher Rolle bzw. Aufgabe benutzt Du die Applikation am häufigsten? (Mehrfachauswahl möglich).
Entwickler
75%
Support
40%
Wartung
0%
Manager
20%
ID Fragestellung
25 Falls Dir eine wichtige Funktion fehlt, trage dies bitte in folgendes Feld.
Suche nicht nur über ApplID, sondern auch über den Namen/Titel.
Die Argumente der letzten Suche sollten beim erneuten öffnen der Seite wieder geladen werden.
DB-Reads und fehlende Indexe
- Die Suche sollte nicht sofort ausgeführt werden => unnötige Abfragen mich interessiert nur meine DB's
- Einschränkung nach meinen Applikationen / Stv. sollte ermöglicht werden
- Wenn DB-Server gewählt wurde Dropdown der Datenbanken automatisch einschränken.
- Werte im Dropdown Datenbanken alphabetisch sortieren
Overview:
- mir fehlt eine Zusammenfassung (Druckansicht) für eine Applikation.
-Tab HermesLight => Info für den STV. Wenn dort sehr viel steht ist das nicht schnell und einfach lesbar
=> Lupe-Funktion wo mir der ganze Text dargestellt würde, wäre praktisch
Reportings (z.B. Bei welcher Applikation ist kein Stv vorhanden)
Alle Infos zusätzlich auf einer Seite (ausdruckbar) als Übersicht...?
ID
26
Fragestellung
Falls Du einen Kommentar (besonders gut/besonders schlecht) oder Verbesserungsvorschläge hast,
trage dies bitte in folgendes Feld ein.
Sehr gut finde ich die automatische Berechtigung im Subversion!
Bei den DB-Reads wäre eine Hilfestellung praktisch. Was bedeuten diese Zahlen, wann muss gehandelt
werden => Infos müssten von Aldo kommen
Kennzeichenung welche Umgebung bearbeitet wird => grösster Kübel. Ich hätte die Umgebung als Test
gerne noch ausgeschrieben gehabt => oder wenigstens noch ein Tooltip
Modern, Tabs sind logisch, Extra-Tab erweiterungstechnisch clever
Habe die Frage "Wenn ich etwas nicht verstehe, hilft mir das Programm" tief bewertet, da keine "DirektHilfe" vorhanden ist. Ist aber nicht schlecht, weil die Funktionalitäten uns bekannt sein sollten :-)
Stellvertreter-Infos sind nicht so gut lesbar -> man muss zuviel scrollen bei grösseren Texten.
Jeder Entwickler müsste vermutlich die Schriftgrösse seiner Beiträge anpassen (= verkleinern) :-)
ID
27
Fragestellung
Falls Du eine Anregung beliebiger Form zu dieser Umfrage hast, trage dies bitte in folgendes Feld
ein.
Projektdeckblatt-Funktion weiter ausbauen
SI_PADMAN_Situationsanalyse_V02.00.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
17/18
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Situationsanalyse Corp_PadMan
Situationsanalyse
Informationstechnologie
7.2
Analyse und Fazit
Bei der ersten Umfrage über das existierende System Teamportal wurden über die Zahlenwerte ein Durchschnitt
von 3.76 von 6.00 möglichen Punkten erreicht.
Mit der Neuentwicklung konnte ein Wert von 5.30 von 6.00 möglichen Punkten erreicht werden. Im Gesamten
konnte für die Befragten mit der Neuentwicklung eine deutliche Verbesserung erreicht werden.
Für den nächsten Release sollte vor allem die Hilfestellung für den Benutzer verbessert werden. In der textuellen
Auswertungen wurden die Ziele aus der ersten Umfrage nicht aufgeführt. Es sind jedoch weitere Wünsche für
den nächsten Release aufgekommen, welche in der Auswertung aufgelistet sind.
SI_PADMAN_Situationsanalyse_V02.00.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
18/18
Masterthesis „Renewal TeamPortal“
Projektplan
Risikokatalog
Situationsanalyse
Corp_PadMan – Systemanforderungen
Corp_PadMan – Systemdesign
Corp_LogObi – Systemanforderungen
Corp_LogObi – Systemdesign
Corp_JobMonitor – Systemanforderungen
Corp_JobMonitor – Systemdesign
Migration (in der publizierten Version nicht enthalten)
Die Schweizerische Post
Informationstechnologie
Systemanforderungen
Dokumentart
Titel
Projektname
Projektabkürzung
Projektmanager
Ausgabedatum
Autor
Übermittler
Empfänger
Klassifizierung
SY
Systemanforderungen Corp_PadMan
Corp_PadMan
PADMAN
Irminger Pascal, IT133
29.03.2012
Lehmann Marcel, IT132
Irminger Pascal, IT133
Irminger Pascal, IT133; Lehmann Marcel, IT132; Zenklusen Axel, IT131; Haefeli Stefan,
IT132
Nicht klassifiziert
Änderungskontrolle
Version
Datum
Überarbeitung
Ersteller
Freigabe
X01.00
21.11.2011
Neues Dokument
X01.01
14.12.2011
X01.02
16.01.2012
Korrekturen Review mit Experte. Use
Cases überarbeitet sowie erweitert.
Überarbeitungen
X01.03
28.03.2012
Finalisierung
V01.03
29.03.2012
Freigabe
Lehmann Marcel,
IT132
Lehmann Marcel,
IT132
Lehmann Marcel,
IT132
Lehmann Marcel,
IT132
Irminger Pascal, IT133
Haefeli Stefan, IT132
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
1/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
Inhaltsverzeichnis
1 Allgemeines .................................................................................................................................................. 4
1.1 Zweck ........................................................................................................................................................ 4
1.2 Beschreibung ............................................................................................................................................. 4
1.3 Tailoring ..................................................................................................................................................... 4
1.4 Definitionen, Akronyme und Abkürzungen ................................................................................................ 4
1.5 Referenzen ................................................................................................................................................ 4
2 Allgemeine Beschreibung .............................................................................................................................. 5
2.1 Ausgangslage ............................................................................................................................................ 5
2.2 Produktperspektive .................................................................................................................................... 5
3 Allgemeine Anforderungen ........................................................................................................................... 6
3.1 Personas .................................................................................................................................................... 6
3.2 Domainmodell ........................................................................................................................................... 7
3.2.1 Strukturdiagramm .................................................................................................................................. 7
3.2.2 Konzeptbeschreibung ............................................................................................................................. 7
3.3 Systemgrenzen .......................................................................................................................................... 7
3.4 Use Cases .................................................................................................................................................. 8
3.4.1 P_UC_10: Neue Applikation erfassen ...................................................................................................... 9
3.4.2 P_UC_20: Neue Solution erfassen ......................................................................................................... 10
3.4.3 P_UC_40: Account mit Funktion hinzufügen ........................................................................................ 11
3.4.4 P_UC_50: Komponente hinzufügen ...................................................................................................... 12
3.4.5 P_UC_60: Komponete zwischen Umgebung abgleichen ....................................................................... 13
3.4.6 P_UC_70: SQL Connection erfassen ...................................................................................................... 14
3.4.7 P_UC_80: SQL Connection bearbeiten .................................................................................................. 15
3.4.8 P_UC_90: SQL Connection löschen ....................................................................................................... 16
3.4.9 P_UC_100: Datenbank-Script generieren .............................................................................................. 17
3.4.10 P_UC_110: Umgebung der Anwendungseinstellungen wechseln ......................................................... 18
3.4.11 P_UC_140: Status der Komponente setzen ........................................................................................... 19
3.4.12 P_UC_150: Komponenten suchen ........................................................................................................ 20
3.4.13 P_UC_180: DB-Stammdaten exportieren .............................................................................................. 21
3.4.14 P_UC_190: DB-Schema exportieren ...................................................................................................... 22
3.4.15 P_UC_200: Projektdeckblatt erfassen .................................................................................................... 23
3.4.16 P_UC_210: Projektdeckblatt bearbeiten ................................................................................................ 24
3.4.17 P_UC_220: Projektdeckblatt löschen ..................................................................................................... 25
3.4.18 P_UC_230: Projektdeckblatt Prozess-Schritt planen ............................................................................... 26
3.4.19 P_UC_240: Projektdeckblatt Prozess-Schritt signieren ........................................................................... 27
3.4.20 P_UC_250: SVN Pfad definieren............................................................................................................ 28
3.4.21 P_UC_260: SVN Repository erstellen ..................................................................................................... 29
3.4.22 P_UC_270: SVN-Berechtigung setzen ................................................................................................... 30
3.4.23 P_UC_280: Personen verwalten (CRUD) ................................................................................................ 31
3.5 Nicht-funktionale Anforderungen ............................................................................................................ 32
3.5.1 Technische Anforderung ....................................................................................................................... 32
3.5.2 Ergonomische Anforderung .................................................................................................................. 32
3.5.3 Verfügbarkeit ........................................................................................................................................ 32
3.5.4 Benutzerfreundlichkeit .......................................................................................................................... 32
3.5.5 Datenverlust ......................................................................................................................................... 32
3.5.6 Auftreten von Fehlfunktionen ............................................................................................................... 32
3.5.7 Erweiterbarkeit ..................................................................................................................................... 32
3.5.8 Sicherheit ............................................................................................................................................. 32
3.5.8.1 Authentifizierung ............................................................................................................................... 32
3.5.8.2 Kommunikation ................................................................................................................................. 32
3.5.8.3 SQL-Injektion ..................................................................................................................................... 32
3.5.8.4 X-Side Scripting ................................................................................................................................. 33
3.5.8.5 Scripts................................................................................................................................................ 33
4 Anforderungen an die Entwicklungs- und Wartungsumgebung .................................................................. 33
5 Anforderungen an die externen Schnittstellen ............................................................................................ 33
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
2/33
Projektname
Dokumenttitel
Artifaktname
6
7
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
Detailanforderungen ................................................................................................................................... 33
Sicherheitsanforderungen ........................................................................................................................... 33
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
3/33
Projektname
Dokumenttitel
Artifaktname
1
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
Allgemeines
1.1
Zweck
Die Systemanforderungen beschreiben und strukturieren die Anforderungen an das zukünftige System. Sie
werden vom Auftraggeber und Auftragnehmer beidseitig als Grundlage für die Realisierung und Abnahme des
zukünftigen Systems akzeptiert.
1.2
Beschreibung
Die Systemanforderungen beziehen sich je nach Phase auf die Ebene System, Subsystem oder
Konfigurationseinheit (KE). Eine verfeinerte Gliederung muss vom entsprechenden Vorgehensmodell hinzugefügt
werden. Die Darstellung der Systemanforderungen kann sowohl in strukturiertem Text als auch in Form von
Modellen erfolgen.
1.3
Tailoring
Die Systemanforderungen können auch in mehreren eigenständigen Dokumenten vorliegen, zum Beispiel pro
Subsystem oder Konfigurationseinheit.
1.4
Definitionen, Akronyme und Abkürzungen
Wort
Definition
Corp_TeamPortal
Intranet-Webapplikation. Stellt innerhalb von IT13 eine zentrale Stelle für das Entwickeln
von Intranet-Applikationen dar. Es stellt Konfigurationen wie zum Beispiel
Datenbankzugriff, beteiligte Personen, Publikation etc. für unsere Intranet-Umgebung zur
Verfügung.
Datenbank
Das Hypertext Transfer Protocol ist ein Protokoll zur Übertragung von Daten über ein
Netzwerk. Es wird hauptsächlich eingesetzt, um Webseiten aus dem Internet/Intranet in
einen Webbrowser zu laden.
Das HyperText Transfer Protocol Secure ist die sichere Variante von HTTP. Syntaktisch ist
HTTPS identisch mit dem Schema für HTTP, die zusätzliche Verschlüsselung der Daten
geschieht mittels SSL/TLS.
Internet Information Services. Webserver-Komponente in Microsoft Windows. Über IIS
können ASP- oder .NET-Applikationen (ASP.NET) ausgeführt werden
.NET-Entwicklungsabteilung von IT Post
Informationstechnologie Post
Skriptsprache, die hauptsächlich für das DOM-Scripting in Web-Browsern eingesetzt wird.
.NET-Entwicklungsabteilung von IT Post
Das Lightweight Directory Access Protocol (LDAP) erlaubt die Abfrage und die Modifikation
von Informationen eines Verzeichnisdienstes über ein IP-Netzwerk.
Für .NET portiertes O/R-Mapping Framework (Hibernate).
Technik der Softwareentwicklung, mit der ein in einer objektorientierten
Programmiersprache geschriebenes Anwendungsprogramm seine Objekte in einer
relationalen Datenbank ablegen kann.
Post Wide Web. Das Intranet der Schweizerischen Post.
Structured Query Language
Auch Microsoft SQL Server. SQL Server Produkt von Microsoft. Derzeit in den Versionen
SQL Server 2005 und SQL Server 2008 R2 bei der Schweizerischen Post im Einsatz.
Use Case
Cross-Site-Scripting (XSS) bezeichnet das Ausnutzen einer Sicherheitslücke in
Webanwendungen, indem Informationen aus einem Kontext, in dem sie nicht
vertrauenswürdig sind, in einen anderen Kontext eingefügt werden, in dem sie als
vertrauenswürdig eingestuft werden. Aus diesem vertrauenswürdigen Kontext kann dann
ein Angriff gestartet werden.
zum Beispiel
DB
HTTP
HTTPS
IIS
IT13
IT Post
Javascript
IT13
LDAP
NHibernate
O/R-Mapping
PWW
SQL
SQL Server
UC
X-Site-Scripting
z.B.
1.5
Referenzen
Keine.
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
4/33
Projektname
Dokumenttitel
Artifaktname
2
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
Allgemeine Beschreibung
2.1
Ausgangslage
Die Applikation Teamportal stellt für IT13 eine zentrale Stelle für das Entwickeln von Intranet-Applikationen dar.
Es stellt ein kleines Projektmanagement sowie Konfigurationen wie zum Beispiel Datenbankzugriff, Publikation
etc. für unsere Intranet-Umgebung zur Verfügung. Zusätzlich zu diesem Teamportal gibt es weitere bestenende
Applikationen (Errors, Sendto, Job-Journal), welche für die tägliche Entwicklung hilfreich bzw. notwendig sind.
2.2
Produktperspektive
Es soll eine neue zentrale Intranet-Applikation entstehen, welche die aktuellen Bedürfnisse der Entwickler
abdeckt, um die Schwachstellen der Prozesse, wie sie heute umgesetzt werden, zu beheben. PadMan soll
konkret den folgenden Bedürfnissen gerecht werden:
PadMan als Managementinstrument (für Team-, Abteilungs-, Projektleitung)
PadMan als Wartungsinstrument
PadMan als Entwicklungsinstrument
PadMan als Prozessinstrument
PadMan als Releaseinstrument
Die Applikation soll beispielsweise die Initialisierungsphase der Entwicklung vereinfachen und den
Verwaltungsaufwand während der Implementierung und darüber hinaus verringern. Dabei soll zu Beginn der
Applikations-Entwicklung die Programmierumgebung inkl. Code-Projekten sowie das Versions-Management
eingerichtet werden.
Das neue Teamportal soll aufgetretene Fehlerlogs in produktiven Applikationen nicht mehr länger nur anzeigen
können (Pull), sondern aktiv die verantwortlichen Entwickler darüber informieren (Push). Durch ein geeignetes
Regelwerk sollen die Entwickler in der Lage sein, die Benachrichtigungen, welche sie erhalten, zu steuern und
gegebenenfalls einzuschränken.
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
5/33
Projektname
Dokumenttitel
Artifaktname
3
3.1
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
Allgemeine Anforderungen
Personas
Peter Ledermann (44): Hat gute Computerkenntnisse und arbeitet häufig mit Office
(Word, Excel) sowie mit SAP. Er arbeitet als Manager und muss so die Kosten der
Applikationen sowie deren Offerten überwachen. Er ist verantwortliche für die
Ressourcenplanung der Entwickler und versucht so mit den Kunden eine Terminplanung
der Anwendungen zu definieren. Falls die Kosten einer Anwendungsentwicklung den
Betrag der Offerte überschreiten, versucht er, mögliche Lösungen mit dem Kunde zu
finden. Bei Kundenanfragen für eine neue Anwendung bzw. neue Funktionen zu einer
bestehenden Applikation konsolidiert er die bereits vorhanden Implementierungen und
zeigt dem Kunde mögliche Lösungen wie zum Beispiel mandantenfähige Applikationen.
Manuel Imhof (28): Hat fortgeschrittene Computerkenntnisse und arbeitet als SoftwareEntwickler im Webumfeld. Er nutzt das Internet als Informations- und
Unterhaltungsinstrument. Als Entwickler einer Anwendung ist er meistens zugleich
Projektleiter. Für das Verwalten von Anwendungen für Support sowie Wartung ist er
selber verantwortlich. Für das Entwickeln einer Anwendung verwendet er Visual Studio
und er verwaltet seinen Source Code mit Subversion. Als Unterstützung zur Entwicklung
der Anwendung steht ihm eine Library, welche speziell für diese Abteilung entwickelt
wurde, zur Verfügung. Häufig entwickelt er Anwendungen im Kostenbereich 10‘000 bis
100‘000 Franken. Bei diesen Anwendungen ist er für alle notwendigen Schritte von
Offerte bis zur Publikation der Anwendung selber verantwortlich. Er übernimmt auch die
Schnittstelle zum Kunde. Bei grösseren Anwendung arbeitet er in einem Team von
Entwickler und ihm werden diverse Rollen übergeben. Es kann aber auch sein, dass er die
Funktion Projektleiter übernimmt, jedoch keinen einzigen Code entwickeln wird.
Sabrina Schmid (32): Hat gute Computerkenntnisse und das Arbeiten mit
Webapplikationen fällt ihr leicht. Als 2nd-Level-Supporterin nutzt sie das Telefon und EMail sehr häufig. Sie ist die Schnittstelle zwischen den Entwicklern und den Benutzern.
Kann der 1st-Level-Support eine Anfrage nicht beantworten, so wird diese Anfrage an
Sabrina weitergeleitet. Falls sie die Anfrage nicht selber beantworten kann, informiert sie
den Verantwortlichen der Anwendung, zu welcher die Anfrage gerichtet ist. Die
Kommunikation zum Benutzer übernimmt sie weiterhin. Der Verantwortliche wird ihr die
Antwort entweder mündlich oder schriftlich geben. Das Verwalten sowie Überwachen der
Anfragen und deren Bearbeitungszeit übernimmt ebenfalls Sabrina. Für diese Aufgabe
stehen ihr verschiedene Stellvertreter sowie Mitarbeiter zur Verfügung, so dass während
den Büroarbeitszeiten die Anfragen so schnell wie möglich beantwortet werden können.
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
6/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.2
Domainmodell
3.2.1 Strukturdiagramm
Component
-Id : string
Abbildung 1: Domainmodell Corp_PadMan.
3.2.2 Konzeptbeschreibung
Component
Beschreibung
Stellt eine Komponente wie Applikation dar
Attribute
Beziehung
3.3
Systemgrenzen
PadMan
Via PostLib
PWW
GUI
Arbeitsstation
LogObi
JobMonitor
Abbildung 2: Systemgrenzen von Corp_PadMan.
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
7/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4
Use Cases
In der untenstehenden Tabelle 1 werden alle Use Cases mit deren Gewichtung dargestellt. Die Gewichtung wird
zwischen 1 und 5 definiert. Dabei gilt ein Wert von 5 zwingend zu implementieren und einen Wert von 1 als
„nice to have“. Umso höher der Wert Kritisch ist, je mehr Unklarheiten bzw. Wissen fehlt für die benötigte
Funktion.
Name
Neue Applikation erfassen
Neue Solution erfassen
Neues Projekt erfassen (Wizard)
Account mit Funktion hinzufügen
Komponente hinzufügen
Komponente zwischen Umgebung abgleichen
SQL Connection erfassen
SQL Connection bearbeiten
SQL Connection löschen
Datenbank-Script generieren
Umgebung der Anwendungseinstellungen wechseln
Komponente löschen
Applikation ausser Betrieb nehmen
Status der Komponente setzen
Komponenten suchen
SVN-Repository anlegen
SVN-Berechtigung setzen
DB-Stammdaten exportieren
DB-Schema exportieren
Projektdeckblatt erfassen
Projektdeckblatt bearbeiten
Projektdeckblatt löschen
Projektdeckblatt Prozess-Schritt planen
Projektdeckblatt Prozess-Schritt signieren
SVN Pfad definieren
SVN Repository erstellen
SVN-Berechtigung setzen
Personen verwalten (CRUD)
Bezeichnung
P_UC_10
P_UC_20
P_UC_30
P_UC_40
P_UC_50
P_UC_60
P_UC_70
P_UC_80
P_UC_90
P_UC_100
P_UC_110
P_UC_120
P_UC_130
P_UC_140
P_UC_150
P_UC_160
P_UC_170
P_UC_180
P_UC_190
P_UC_200
P_UC_210
P_UC_220
P_UC_230
P_UC_240
P_UC_250
P_UC_260
P_UC_270
P_UC_280
Gewicht
5
3
1
5
3
5
5
5
5
3
5
1
1
4
5
4
4
1
1
3
2
2
2
3
4
3
3
5
Kritisch
1
1
3
1
1
2
1
1
1
1
1
1
3
1
1
2
4
4
4
2
2
2
1
2
1
2
3
1
Gestrichen
x
x
x
Tabelle 1: Use Case Übersicht von Corp_PadMan.
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
8/33
Projektname
Dokumenttitel
Artifaktname
3.4.1
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
P_UC_10: Neue Applikation erfassen
Bezeichnung
P_UC_10
Name
Neue Applikation erfassen
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
Supporter
Interessen
Entwickler benötigt für sein Projekt eine neue Applikation.
Vorbedingung
Nachbedingung
Neue Applikation wurde gespeichert. Verantwortlicher für die Applikation wurde
bestimmt.
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer will eine neue Applikation
erstellen.
2. Benutzer gibt Applikation -ID und
Verantwortlicher ein.
3. Benutzer teilt dem System mit, dass
er nun die Anwendung anlegen
will.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
4. System speichert die neue
Applikation.
2a. Entwickler gibt optionale Angaben ein.
4a. Ungültige Applikations-ID
1. System signalisiert den Fehler und speichert nichts.
2. Entwickler ändert die Applikations-ID.
wenig
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
9/33
Projektname
Dokumenttitel
Artifaktname
3.4.2
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
P_UC_20: Neue Solution erfassen
Bezeichnung
P_UC_20
Name
Neue Solution erfassen
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
Supporter
Interessen
Entwickler benötigt für sein Projekt eine neue Solution.
Vorbedingung
Nachbedingung
Neue Applikation wurde gespeichert. Verantwortlicher für die Applikation wurde
bestimmt.
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer will eine neue Solution
erstellen.
2. Benutzer gibt Solution-ID und
Verantwortlicher ein.
3. Benutzer teilt dem System mit, dass
er nun die Solution anlegen will.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
4. System speichert die neue Solution.
2a. Entwickler gibt optionale Angaben ein.
4a. Ungültige Solution-ID
1. System signalisiert den Fehler und speichert nichts.
2. Entwickler ändert die Applikations-ID.
wenig
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
10/33
Projektname
Dokumenttitel
Artifaktname
3.4.3
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
P_UC_40: Account mit Funktion hinzufügen
Bezeichnung
P_UC_40
Name
Account mit Funktion hinzufügen
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
Supporter
Interessen
Verwalten welche Accounts mit dieser Component in Verbindung sind und
welche Funktionen diese übernehmen.
Vorbedingung
Komponente ist ausgewählt
Nachbedingung
Neuer Account wurde hinzugefügt
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer will einen neuen Account
mit einer Funktion hinzufügen.
2. Benutzer gibt Account ein.
3. Benutzer wählt aus einer
bestehenden Auswahl eine
Funktion aus.
4. Benutzer teilt dem System mit,
dass er die Änderung übernehmen
will.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
5. System speichert die Änderung.
3a. Benutzer gibt an, ob der Account die Hauptrolle für diese Funktion
übernimmt.
3b. Benutzer gibt an, ob die Funktion des Accounts aktiv ist.
3c. Benutzer gibt einen Kommentar ein.
4a. Ungültiger Account
1. System signalisiert den Fehler und speichert nichts.
2. Entwickler ändert den Account.
wenig
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
11/33
Projektname
Dokumenttitel
Artifaktname
3.4.4
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
P_UC_50: Komponente hinzufügen
Bezeichnung
P_UC_50
Name
Komponente hinzufügen
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
Supporter
Interessen
Struktur eines Projektes in Components abbilden.
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer sucht Basis-Component
2. System zeigt gefunden
Component an.
3. Benutzer wählt Component aus.
4. Benutzer teilt dem System mit, dass
er eine Sub-Component hinzufügen
will.
5. System zeigt dem Benutzer die
möglichen Component an
6. Benutzer wählt die Component aus
und teilt dem System mit, dass er die
Änderung übernehmen will.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
7. System speichert die Änderung.
3a. Component existiert noch nicht
3. Benutzer startet Neue Component erfassen
wenig
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
12/33
Projektname
Dokumenttitel
Artifaktname
3.4.5
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
P_UC_60: Komponete zwischen Umgebung abgleichen
Bezeichnung
P_UC_60
Name
Komponente zwischen Umgebung abgleichen
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
Supporter
Interessen
Einstellungen einer Komponente in eine andere Umgebung übernehmen
Vorbedingung
Nachbedingung
Die Komponenten in beider Umgebung haben die gleichen Einstellungen. Falls
ein Abbruch stattgefunden hat, so haben beide Komponenten wieder die
Einstellungen vor der Durchführung des Use Cases.
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer sucht Komponente
2. System zeigt gefundene
Komponenten an.
3. Benutzer wählt Komponente aus.
4. Benutzer teilt dem System mit,
zwischen welchen Umgebungen er
einen Abgleich durchführen will.
5. System zeigt dem User die
einzelnen Werte an, welche
zwischen den Komponenten
abgeglichen wird.
6. Benutzer wählt die Werte aus,
welche er abgeglichen haben möchte
und startet den Abgleich.
7. System führt den Abgleich aus.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
wenig
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
13/33
Projektname
Dokumenttitel
Artifaktname
3.4.6
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
P_UC_70: SQL Connection erfassen
Bezeichnung
P_UC_70
Name
SQL Connection erfassen
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Der Benutzer benötigt für eine Komponente Zugriff auf eine Datenbank (DBConnection Connection-String).
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer sucht Komponente.
2. System zeigt gefundene
Komponenten an.
3. Benutzer wählt Komponente aus.
4. Benutzer wählt Datenbank
5. Benutzer erfasst Usernamen.
6. Benutzer erfasst Passwort.
7. Benutzer erfasst Timeout.
8. Benutzer erfasst Optionen.
9. Benutzer erfasst Connection-ID.
10. Benutzer wählt Umgebung
11. Benutzer bestätigt die Eingaben.
12. System speichert die Daten.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
6a. Benutzer lässt ein Passwort generieren.
mittel
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
14/33
Projektname
Dokumenttitel
Artifaktname
3.4.7
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
P_UC_80: SQL Connection bearbeiten
Bezeichnung
P_UC_80
Name
SQL Connection bearbeiten
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Der Benutzer möchte eine bestehende SQL Connection bearbeiten
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer sucht Komponente
2. System zeigt gefundene
Komponenten an.
3. Benutzer wählt Komponente aus.
4. Benutzer wählt die zu bearbeitende
SQL Connection aus.
5. Benutzer ändert die Daten.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
6. System speichert die Daten.
5a. Die Umgebung kann nicht geändert werden.
wenig
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
15/33
Projektname
Dokumenttitel
Artifaktname
3.4.8
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
P_UC_90: SQL Connection löschen
Bezeichnung
P_UC_90
Name
SQL Connection löschen
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Der Benutzer möchte eine bestehende SQL Connection löschen
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer sucht Komponente
2. System zeigt gefundene
Komponenten an.
3. Benutzer wählt Komponente aus.
4. Benutzer teilt dem System mit,
welche SQL Connection gelöscht
werden soll.
5. System löscht die SQL Connection.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
wenig
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
16/33
Projektname
Dokumenttitel
Artifaktname
3.4.9
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
P_UC_100: Datenbank-Script generieren
Bezeichnung
P_UC_100
Name
Datenbank-Script generieren
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Für die Applikation benötigt der Entwickler eine Datenbank. Da er keine
Berechtigung für das Erstellen einer neuen Datenbank hat, muss er das Script an
den DBA senden.
Vorbedingung
Benutzer hat Komponente ausgewählt und SQL Connection(s) sind erfasst.
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer teilt dem System mit, dass
er für eine erfasste SQL Connection
das Script für das Erstellen der
Datenbank generieren will.
2. System generiert das Script und
übergibt dieses dem
Standardmailprogramm des
Benutzers.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
mittel
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
17/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.10 P_UC_110: Umgebung der Anwendungseinstellungen wechseln
Bezeichnung
P_UC_110
Name
Umgebung der Anwendungseinstellungen wechseln
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Benutzer möchte Daten für eine Umgebung anpassen
Vorbedingung
Benutzer hat Komponente ausgewählt
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer teilt dem System mit, dass
er die Umgebung wechseln will.
2. System wechselt die Umgebung
und zeigt die Daten für diese
Umgebung an
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
mittel
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
18/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.11 P_UC_140: Status der Komponente setzen
Bezeichnung
P_UC_140
Name
Status der Komponente setzen
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Benutzer möchte den Status einer Komponente ändern
Vorbedingung
Benutzer hat Komponente ausgewählt
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer wählt einen Status aus
einer Liste aus.
2. Benutzer teilt dem System mit, dass
er die Änderung speichern möchte.
3. System ändert den Status der
Komponente.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
mittel
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
19/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.12 P_UC_150: Komponenten suchen
Bezeichnung
P_UC_150
Name
Komponenten suchen
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Benutzer sucht eine Komponente
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer wählt Suchkriterien aus und
startet die Suche
2. System zeigt die gefundenen
Komponenten an.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
1a. Komponentennamen (ApplID)
1b. Er als Entwickler
1c. Er als Stellvertreter
1d. Eine andere Person als Entwickler
1e. Eine andere Person als Stellvertreter
1f. Status einer Komponente
mittel
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
20/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.13 P_UC_180: DB-Stammdaten exportieren
Bezeichnung
P_UC_180
Name
DB-Stammdaten exportieren
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Benutzer möchte Stammdaten aus einer Datenbank als SQL-Insert-Statements z.b
in die Source-Verwaltung für einen Release aufnehmen.
Vorbedingung
Benutzer hat Komponente ausgewählt
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer wählt die SQL-Connection
aus.
2. Benutzer gibt die Tabellen mit den
Stammdaten an.
3. Benutzer startet das Exportieren.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
4. System generiert die SQLStatements und stellt einen
Download zur Verfügung.
4a. Benutzer hat keine Tabellen ausgewählt.
1. System führt das Exportieren nicht aus.
mittel
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
21/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.14 P_UC_190: DB-Schema exportieren
Bezeichnung
P_UC_190
Name
DB-Schema exportieren
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Benutzer möchte das Schema einer Datenbank als SQL-Create-Statements z.B. in
die Source-Verwaltung für einen Release aufnehmen.
Vorbedingung
Benutzer hat Komponente ausgewählt
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer wählt die SQL-Connection
aus.
2. Benutzer gibt die Tabellen an.
3. Benutzer startet das Exportieren.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
4. System generiert die SQLStatements und stellt einen
Download zur Verfügung.
4a. Benutzer hat keine Tabellen ausgewählt.
1. System führt das Exportieren für alle Tabellen aus (Ausgeschlossen sind
Systemtabellen).
mittel
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
22/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.15 P_UC_200: Projektdeckblatt erfassen
Bezeichnung
P_UC_200
Name
Projektdeckblatt erfassen
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Benutzer möchte für einen Release ein Projektdeckblatt erfassen.
Vorbedingung
Benutzer hat Komponente ausgewählt
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer gibt ein Startdatum sowie
Enddatum ein.
2. Benutzer fügt die notwendigen
Prozess-Schritte hinzu.
3. Benutzer teilt dem System mit, dass
er das Projektdeckblatt speichern
möchte.
4. System erstellt neues
Projektdeckblatt.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
mittel
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
23/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.16 P_UC_210: Projektdeckblatt bearbeiten
Bezeichnung
P_UC_210
Name
Projektdeckblatt bearbeiten
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Benutzer möchte ein bestehendes Projektdeckblatt bearbeiten.
Vorbedingung
Benutzer hat Komponente ausgewählt
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer wählt Projektdeckblatt aus.
2. Benutzer ändert die Daten.
3. Benutzer teilt dem System mit, dass
er die Änderung speichern will.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
4. System übernimmt die Änderung.
2a. Benutzer ändert Startdatum
2b. Benutzer ändert Enddatum
2c. Benutzer fügt die neue Prozess-Schritte hinzu
2d Benutzer entfertn Prozess-Schritte.
mittel
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
24/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.17 P_UC_220: Projektdeckblatt löschen
Bezeichnung
P_UC_220
Name
Projektdeckblatt löschen
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Benutzer möchte ein bestehendes Projektdeckblatt löschen
Vorbedingung
Benutzer hat Komponente ausgewählt
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer wählt Projektdeckblatt aus.
2. Benutzer teilt dem System mit, dass
er das Projektdeckblatt löschen
möchte.
3. System löscht das
Projektdeckblatt..
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
mittel
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
25/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.18 P_UC_230: Projektdeckblatt Prozess-Schritt planen
Bezeichnung
P_UC_230
Name
Projektdeckblatt Prozess-Schritt planen
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Benutzer möchte einen Prozess-Schritt planen.
Vorbedingung
Benutzer hat Komponente sowie Projektdeckblatt ausgewählt
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer gibt ein Enddatum für
einen Prozess-Schritt ein.
2. Benutzer teilt dem System mit, dass
er die Änderung speichern will.
3. System speichert das Datum.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
mittel
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
26/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.19 P_UC_240: Projektdeckblatt Prozess-Schritt signieren
Bezeichnung
P_UC_240
Name
Projektdeckblatt Prozess-Schritt signieren
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Interessen
Benutzer möchte einen Prozess-Schritt signieren.
Vorbedingung
Benutzer hat Komponente sowie Projektdeckblatt ausgewählt
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer teilt dem System mit,
welchen Prozess-Schritt er signieren
möchte.
2. System überprüft ob der Benutzer
den Prozess-Schritt signieren darf.
3. Benutzer führt das Signieren aus.
4. System speichert das Signieren.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
2a. Benutzer hat keine Berechtigung
1. Der UseCase wird abgebrochen.
mittel
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
27/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.20 P_UC_250: SVN Pfad definieren
Bezeichnung
P_UC_250
Name
SVN Pfad definieren
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
SVN-Administrator
Interessen
Definieren des SVN-Pfad für eine Komponente.
Vorbedingung
Benutzer hat Komponente ausgewählt
Nachbedingung
SVN-Pfad ist in PadMan konfiguriert.
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer setzt den SVN Repository
Pfad.
2. Benutzer teilt dem System mit, dass
er die Änderung speichern möchte.
3. System speichert die Änderungen
und stellt dem Benutzer weitere
Funktion für SVN zur Verfügung.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
selten
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
28/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.21 P_UC_260: SVN Repository erstellen
Bezeichnung
P_UC_270
Name
SVN Repository erstellen
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
SVN-Administrator
Interessen
Erstellen der Projekt-Unterverzeichnisse im Subversion-Repository.
Vorbedingung
Benutzer hat Komponente ausgewählt und SVN Pfad ist vorhanden
Nachbedingung
Das Subversion-Verzeichnisse existieren.
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer teilt dem System mit, dass
er das SVN-Repository erstellen
möchte.
2. System erstellt aufgrund des
definierten SVN-Pfades ein
Hauptverzeichnis im Subversion
Repository.
3. System erstellt gemäss den
Richtlinien die Unterverzeichnisse
trunk, tags, branches.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
selten
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
29/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.22 P_UC_270: SVN-Berechtigung setzen
Bezeichnung
P_UC_270
Name
SVN-Berechtigung setzen
Scope
PadMan
Level
Systemabsicht
Primärer Aktor
System
Stakeholder
Entwickler
Manager
Interessen
Die SVN-Berechtigungen werden entsprechend den Angaben im Feld SVN-Pfad
und der verantwortlichen Personen gesetzt.
Vorbedingung
SVN-Pfad- und/oder Personen-Mutation hat stattgefunden.
Nachbedingung
Die verantwortlichen Personen sind auf den entsprechenden SVN-Verzeichnissen
berechtigt.
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. System startet das Setzen der SVNBerechtigung.
2. System selektiert zu den
Komponenten die definierten SVNPfade.
3. System selektiert zu den
Komponenten die verantwortlichen
Personen (Entwickler, Stellvertreter).
4. System verbindet die selektierten
Daten und wandelt diese in ein SVNauthz-File-konformes Format um.
5. System speichert die Daten im authzFile auf dem Subversion Server.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
häufig
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
30/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.4.23 P_UC_280: Personen verwalten (CRUD)
Bezeichnung
P_UC_280
Name
Personen verwalten (CRUD)
Scope
PadMan
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
Interessen
Der Entwickler will die verantwortlichen Personen einer Komponente verwalten.
Vorbedingung
Benutzer hat Komponente ausgewählt
Nachbedingung
Personen sind verwaltet.
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer wählt „Editieren“ der
entsprechenden Komponente.
2. System öffnet die Editieransicht der
Komponente. Mit dabei ist eine
Übersicht aller verantwortlichen
Personen für diese Komponente.
3. Benutzer wählt „Person
hinzufügen“.
4. System zeigt eine
Eingabemöglichkeit zum Erfassen
einer Person an.
5. Benutzer definiert User-ID,
Funktion, HasLead, Aktiv und
Kommentar.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
6. System speichert die Eingaben in der
Datenbank.
3a. Benutzer wählt in der Liste „Person editieren“.
3b. Benutzer wählt in der Liste „Person löschen“.
4a. Editieren: Dito 4.
4b. Löschen: System löscht die Person für die entsprechende Komponente. Ende
Use-Case.
häufig
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
31/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.5
Nicht-funktionale Anforderungen
3.5.1 Technische Anforderung
Das System muss mit asp.net in der Sprache C# entwickelt werden und in einem .NET 4.0 Pool auf einem
Windows Server 2008 laufen. Die Anwendung muss mit einem O/R-Mapper implementiert werden und
mindestens mit der Datenbank SQL Server 2008 arbeiten können.
3.5.2 Ergonomische Anforderung
Die Applikation unterstützt die Lokalisierung, es wird jedoch nur eine deutsche Benutzerführung zur Verfügung
gestellt.
3.5.3 Verfügbarkeit
Die Applikation ist während den allgemeinen Bürozeiten (Mo-Fr 07:00 – 19:00) verfügbar. Bei einem Incident,
welcher von der Applikation ausgeht und das PWW betrifft, ist eine max. Behebungszeit von 4 Stunden
notwendig. Ist jedoch der Betrieb von PWW nicht beeinflusst, wird die nach best effort den Incident bearbeitet.
Keine Angaben können bei Incidents, welche in der Umgebung der Applikation und nicht vom Projekt PadMan
beeinflusst werden kann, gemacht.
3.5.4 Benutzerfreundlichkeit
Obwohl die Benutzer der Software über gute bis sehr gute Computerkenntnisse verfügen werden, legen wir viel
Wert auf ein intuitives und übersichtliches Design. Um dies zu erreichen, werden wir uns auf eine einheitliche
Benutzerführung festlegen, wodurch es den Benutzern des System in wenigen Schritten möglich ist, eine
Aufgabe erfolgreich zu lösen. Das System wird über eine grafische Benutzeroberfläche mit übersichtlicher
Menüführung1 verfügen, die mindestens im Internet Explorer 9 dargestellt wird. Andere Browser werden, sofern
diese den Standard implementieren, soweit wie möglich unterstützt.
3.5.5 Datenverlust
Wenn während der Eingabe von Daten eine Fehlfunktion auftritt, gehen nur die noch nicht in die Datenbank
übertragenen Daten verloren. Dabei wird es sich lediglich um gerade eingegebene Daten handeln. Der Verlust
von Daten in der Datenbank wird durch ein Backup, welches in unserer Umgebung bereits im Einsatz ist,
verhindert.
3.5.6 Auftreten von Fehlfunktionen
Sollte tatsächlich eine Fehlfunktion auftreten, so soll dem Benutzer dies mitgeteilt werden. Es soll jedoch nie eine
Fehlerseite des Webservers angezeigt werden.
3.5.7 Erweiterbarkeit
Es soll möglich sein, während des Betriebes die Applikation mit neuen Funktionen zu erweitern, so dass der
Betrieb der Applikation nicht gestört wird. Der Kern der Applikation soll dabei nicht neu publiziert werden
müssen. Beim Entfernen oder Ersetzen bzw. Erweitern von bestehenden Funktionen muss die Applikation
neugestartet werden.
3.5.8 Sicherheit
3.5.8.1 Authentifizierung
Die Authentifizierung wird durch die vorhandenen Mittel der Post (LDAP und Windows-Authentifizierung von IIS)
abgedeckt. Diese wird sowohl für Benutzer als auch für Fremdsysteme, welche über eine Schnittstelle zugreifen,
erforderlich sein.
3.5.8.2 Kommunikation
In der Anwendung werden dem Benutzer Anmeldeinformationen zu Fremdsystemen angezeigt. Aus diesem
Grund wird die Anwendung nur über HTTPS erreichbar sein. Die Schnittstelle für Fremdsysteme werden sowohl
über HTTP als auch HTTPS verfügbar sein. Es werden jedoch nie über diese Schnittstellen Anmeldeinformationen
zur Verfügung gestellt.
3.5.8.3 SQL-Injektion
SQL-Injektion wird durch den Einsatz des O/R-Mappers NHibernate verhindert.
1
Die Übersichtlichkeit wird von ausgewählten Benutzern beurteilt.
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
32/33
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemanforderungen Corp_PadMan
Systemanforderungen
Informationstechnologie
3.5.8.4 X-Side Scripting
Durch das Entfernen von HTML-Tags bei Eingabemöglichkeiten von Benutzern wie auch Fremdsystemen wird das
X-Side Scripting unterbunden.
3.5.8.5 Scripts
Scripts wie Javascript werden durch die Post-Library abgedeckt.
4
Anforderungen an die Entwicklungs- und Wartungsumgebung
Keine weiter führenden Angaben.
5
Anforderungen an die externen Schnittstellen
Keine weiter führenden Angaben.
6
Detailanforderungen
Keine weiter führenden Angaben.
7
Sicherheitsanforderungen
Keine weiter führenden Angaben.
SY_PADMAN_Systemanforderung_V01.03.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
33/33
Masterthesis „Renewal TeamPortal“
Projektplan
Risikokatalog
Situationsanalyse
Corp_PadMan – Systemanforderungen
Corp_PadMan – Systemdesign
Corp_LogObi – Systemanforderungen
Corp_LogObi – Systemdesign
Corp_JobMonitor – Systemanforderungen
Corp_JobMonitor – Systemdesign
Migration (in der publizierten Version nicht enthalten)
Die Schweizerische Post
Informationstechnologie
Systemdesign
Dokumentart
Titel
Projektname
Projektabkürzung
Projektmanager
Ausgabedatum
Autor
Übermittler
Empfänger
Klassifizierung
SD
Systemdesign Corp_PadMan
Corp_PadMan
PADMAN
Irminger Pascal, IT133
29.03.2012
Lehmann Marcel, IT132; Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133; Lehmann Marcel, IT132; Zenklusen Axel, IT131; Haefeli Stefan,
IT132
Nicht klassifiziert
Änderungskontrolle
Version
Datum
Überarbeitung
Ersteller
Freigabe
X01.00
X01.01
16.12.2011
19.12.2011
Neues Dokument
Stand 2. Review Meeting
X01.02
X01.03
30.12.2011
05.03.2012
Überarbeitungen
Überarbeitungen
X01.04
V01.04
28.03.2012
29.03.2012
Finalisierung
Freigabe
Irminger Pascal, IT133
Lehmann Marcel,
IT132
Irminger Pascal, IT133
Lehmann Marcel,
IT132
Irminger Pascal, IT133
Irminger Pascal, IT133
Haefeli Stefan, IT132
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
1/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
Inhaltsverzeichnis
1 Allgemeines .................................................................................................................................................. 3
1.1 Zweck ........................................................................................................................................................ 3
1.2 Beschreibung ............................................................................................................................................. 3
1.3 Tailoring ..................................................................................................................................................... 3
1.4 Definitionen, Akronyme und Abkürzungen ................................................................................................ 3
1.5 Referenzen ................................................................................................................................................ 3
2 Lösungsvorschläge für die Struktur des Systemdesigns .................................................................................. 3
2.1 Modularisierung ........................................................................................................................................ 3
3 Struktur des Systemdesigns........................................................................................................................... 4
3.1 Komponenten............................................................................................................................................ 4
3.1.1 Datenbankmodell ................................................................................................................................... 4
3.2 Modul-Architektur ..................................................................................................................................... 5
3.2.1 Module suchen ....................................................................................................................................... 5
3.2.2 Module im Betrieb .................................................................................................................................. 5
3.2.3 IRunnableModule ................................................................................................................................... 6
3.2.4 IJobModule ............................................................................................................................................. 6
3.2.5 IWebMethodModule .............................................................................................................................. 6
3.2.6 IFilterModule .......................................................................................................................................... 6
3.3 Integration in die Serverumgebung ............................................................................................................ 7
3.4 Generische Datenspeicherung (Value) ........................................................................................................ 8
3.4.1 Datenbankmodell ................................................................................................................................... 8
4 Module ....................................................................................................................................................... 10
4.1 BasicModule ............................................................................................................................................ 10
4.1.1 CreateComponentModule .................................................................................................................... 10
4.1.2 DocumentViewModule ......................................................................................................................... 10
4.1.3 HermesLightModule ............................................................................................................................. 11
4.1.4 OverviewModule .................................................................................................................................. 12
4.1.5 PathModule .......................................................................................................................................... 12
4.1.5.1 Schnittstellen ..................................................................................................................................... 12
4.1.6 PersonViewModule ............................................................................................................................... 13
4.1.7 PersonManagerModule......................................................................................................................... 15
4.1.8 PortfolioModule .................................................................................................................................... 16
4.1.9 ReleaseInfoModule ............................................................................................................................... 16
4.2 DatabaseModule ..................................................................................................................................... 17
4.2.1 DatabaseCreationScriptModule ............................................................................................................ 17
4.2.2 PasswordGeneratorModule ................................................................................................................... 17
4.2.3 SqlConnectionViewModule .................................................................................................................. 17
4.3 ProjectWizard .......................................................................................................................................... 18
4.3.1 ProjectFrontPageModule ....................................................................................................................... 18
4.4 SubversionModule ................................................................................................................................... 20
4.4.1 RepositoryModule................................................................................................................................. 20
4.4.2 CreateRepoFolderModule ..................................................................................................................... 21
4.4.3 PeopleAuthenticationModule ............................................................................................................... 21
5 Schnittstellen .............................................................................................................................................. 21
5.1 ComponentService .................................................................................................................................. 21
5.2 SendToService .......................................................................................................................................... 21
5.3 Informationen zu fehlenden Indexes erhalten .......................................................................................... 22
5.4 Informationen zu Reads-Statistiken erhalten ............................................................................................ 23
6 Beschreibung der Elemente ......................................................................................................................... 24
7 Anforderungszuordnung ............................................................................................................................ 24
8 Sicherheit.................................................................................................................................................... 24
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
2/24
Projektname
Dokumenttitel
Artifaktname
1
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
Allgemeines
1.1
Zweck
Das Systemdesign ist eine Verfeinerung der Systemarchitektur und beschreibt die detaillierten Spezifikationen als
Vorgabe für die Erstellung des Systems.
1.2
Beschreibung
Eine verfeinerte Gliederung muss vom entsprechenden Vorgehensmodell hinzugefügt werden. Die Darstellung
des Systemdesigns kann sowohl in strukturiertem Text als auch in Form von Modellen (z.B. Datenfluss-,
Zustandübergangsmodelle, usw.) erfolgen. Das Systemdesign ist ein abschliessender Entwurf des technischen
und organisatorischen Systems bis auf Stufe «Element».
1.3
Tailoring
Das Systemdesign kann auch in mehreren eigenständigen Dokumenten vorliegen, zum Beispiel pro
Systemelement (entspricht der kleinsten Systemzerlegungsstufe).
1.4
Definitionen, Akronyme und Abkürzungen
Wort
Definition
DAO
NHibernate
Data Access Object
Für .NET portiertes O/R-Mapping Framework (Hibernate).
1.5
Referenzen
Nr.
Titel
[01]
Migrationsdesign
MD_PADMAN_Migrationsdesign_V01.01.docx
2
Lösungsvorschläge für die Struktur des Systemdesigns
2.1
Modularisierung
Damit das Publizieren einzelner Teilbereiche der Applikation vereinfacht werden kann, wird eine ModulArchitektur gewählt. Mit einer Modul-Architektur soll es möglich sein, einzelne Funktionen anpassen zu können,
ohne den Kern oder andere Module verändern zu müssen. Dadurch soll das Publizieren neuer Funktionen oder
Anpassungen bestehender Funktionen vereinfacht werden. Die Module sollen in separaten Assemblies
implementiert werden. Bei einer Publikation einer neuen Assembly soll die Applikation das neue Modul laden
und ausführen.
Um dieses Ziel zu erreichen, wollten wir diese Module als Plugin in eine zusätzliche AppDomain laden. Dadurch
könnten wir auch Module im Betrieb entfernen bzw. ohne abschalten des Applikations-Pools eine neue Version
des Moduls publizieren. Für dieses Ziel haben wir drei Lösungswege untersucht und mussten leider feststellen,
dass im Umfeld mit Web Forms in ASP.NET dieses Ziel so nicht erreicht werden kann.
Bei allen drei Varianten sind wir an den Controls von ASP.NET gescheitert. Damit diese über eine AppDomain
gesendet werden können, müssen diese serialisierbar sein. Die WebControls aus dem .NET Framework sind dies
von Hause aus nicht. Eine eigene Serialisierungsfunktion für diese WebControls zu implementieren, ist ebenfalls
mit grossen Schwierigkeiten verbunden. Grösste Hürde waren die internen Properties wie Controls etc. Um die
Serialisierungsfunktion trotzdem zur Verfügung zu stellen, wären Hacks per Reflection notwendig gewesen.
Eine andere Möglichkeit wäre, für die Controls eine Adapterklasse zu implementieren, welche dann vom
Kern in ein gültiges Control umgewandelt wird. Diese Adapter wären nur implementiert worden, um neue
Plugins ohne Neustart des Application-Pools publizieren zu können. Dies steht in keinem Verhältnis und
deswegen haben wir uns für eine Lösung ohne AppDomain entschieden.
Der DataAccessLayer wird mit NHibernate und der PostLibrary bereitgestellt. Dadurch müssen DAO-Klassen von
Entity ableiten. Um die Architektur-Vorgaben der Post zu erfüllen, entschieden wir uns, die Schnittstelle zwischen
den Modulen und dem Kern mit Interfaces anstatt mit abstrakten Basisklassen zu gestalten, auf Kosten der
einfacheren Erweiterbarkeit. Uns war es wichtig, die Architektur-Vorgaben der Post zu erreichen.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
3/24
Projektname
Dokumenttitel
Artifaktname
3
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
Struktur des Systemdesigns
3.1
Komponenten
In der ersten Version werden zwei verschiedene Komponententypen unterstützt. Dies sind Solution und
Application. Eine Solution fasst mehrere Applications zusammen. Diese Typen wurden als eigene Klassen
realisiert, damit für diese spezifische Aktionen ausgeführt werden können. Diese Aktionen werden jedoch in der
ersten Version noch nicht implementiert, so dass dieses Design zukunftsorientiert ist und momentan einen
Overhead zur Folge hat. Da jedoch bereits Aktionen in Planung sind und im aktuellen Release keinen Platz
hatten, wurde dieser Overhead in Kauf genommen.
Die Verknüpfungen zwischen den Komponenten werden als Graph dargestellt, das bedeutet, eine Komponente
kann mehrer Elternkomponenten haben.
Hat eine Applikation App1 eine Verbindung zu anderen Applikationen, so wird diese Verbindung als UseVerbindung interpretiert. Das bedeutet, die Applikation App1 die anderen verwendet. Ein Beispiel wäre hier
einen Webservice-Aufruf.
Hat eine Solution Verbindungen zu anderen Applikationen, so wird diese als Has-Verbindung interpretiert. Eine
Solution kann mit einer Solution aus dem Visual Studio verglichen werden. Ein Beispiel wäre hier, ein Projekt
stellt eine Web-Applikation und eine WPL-Applikation zur Verfügung.
Abbildung 1: Design Komponente
3.1.1 Datenbankmodell
Damit nicht für je die Tabellen tabApplication und tabSolution eine eigene Verbindungstabelle erstellt
werden muss, wurde die Verbindungstabelle auf Stufe tabComponent realisiert.
tabStatus
PK
tabComponentRef
tabComponent
StatusId
KeyName
LocaleNameId
InsertDate
InsertUser
UpdateDate
UpdateUser
PK
ComponentId
FK1
StatusId
InsertDate
InsertUser
UpdateDate
UpdateUser
tabApplication
PK,FK1
ApplicationId
PK,FK1
PK,FK2
ComponentId
ChildComponentId
tabSolution
PK,FK1
SolutionId
Abbildung 2: Datenbankteilmodell für Komponenten
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
4/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
3.2
Modul-Architektur
3.2.1 Module suchen
Die Module werden mit der Klasse ModuleScanner gesucht. Dabei wird nur das Unterverzeichnis Modules
überprüft. Gefundene Module werden anschliessend in der Datenbank gespeichert, damit nicht bei jedem
Request das Suchen der Module ausgeführt werden muss. Die neu gefundenen Module werden jedoch nicht
direkt aktiviert, dies müssen durch den Benutzer bzw. Administrator manuell aktiviert werden. Der
ModuleScanner wird in einer temporären AppDomain instanziiert, damit wir nicht benötigte Assemblies, welche
keine Module enthalten, wieder entladen können.
Abbildung 3: Module suchen.
3.2.2 Module im Betrieb
Module werden im ModuleManager verwaltet. Dieser Manager ist für das Laden, Instanziieren sowie für die
Kommunikation zwischen den Modulen und den ModuleContainern verantwortlich. Ein ModuleContainer
kann Module aufnehmen und diese darstellen. Häufig wird dies eine Page sein, welche das Interface
IModuleContainer implementieren muss.
Für die Kommunikation werden Nachrichten über den ModuleManager gesendet.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
5/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
Abbildung 4: Modul.
Die Klasse Module, welche von Entity erbt, agiert als DAO-Klasse. Die Implementierungen der Module können
von der abstrakten Klasse Module ableiten oder müssen zumindest das Interface IModule implementieren.
Der Name sowie die Beschreibung der Module werden als Attribute auf der Module-Klasse definiert.
Nachfolgend werden die zusätzlichen Interfaces für die Module beschrieben
3.2.3 IRunnableModule
Stellt ein Modul Funktionen für andere Module zur Verfügung, so kann dieses das
Interface IRunnableModule implementieren. Dieses Interface stellt zwei Methoden
Run mit unterschiedlichen Parametern zur Verfügung. Die erste erwartet nur
Argumente und stellt die default-Run-Methode dar. Stellt ein Modul nur eine Funktion
zur Verfügung, so wird diese Methode verwendet. Möchte ein Modul mehrere
Funktionen zur Verfügung stellen, so kommt die überladene Methode Run mit den
Parametern Key und Argumente ins Spiel. Der Key stellt dabei das Schlüsselwort für die
anzuwendende Funktion dar.
3.2.4 IJobModule
Möchte ein Module durch den täglichen UrlStarter (DB-Job, welcher eine URL aufruft)
aufgerufen werden, so implementiert es dieses Interface. Die Methode Run wird dann
von PadMan aufgerufen.
3.2.5 IWebMethodModule
Benötigt ein Modul eine WebMethod, so muss dieses das Interface IWebMethodModule
implementieren. Dies wird zum Beispiel beim ObjectChooser benötigt.
3.2.6 IFilterModule
Möchte ein Modul – zum Beispiel für die Übersichtseite – Filter zur Verfügung stellen,
so muss es dieses Interface implementieren. Zusätzlich muss es sich jedoch beim Modul,
welches die Übersicht darstellt, registrieren.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
6/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
Abbildung 5: Laden der Module.
Beim Laden der Module wird zusätzlich überprüft, ob in dem Verzeichnis ein module.config vorhanden ist.
Wird ein module.config gefunden, so wird dies in den ConfigManager hinzugefügt. Dadurch kann das
Modul durch den ConfigManager von PadMan auf das module.config zugreifen. Diese Überprüfung sowie
Aktion ist im Sequenzdiagramm nicht ersichtlich.
3.3
Integration in die Serverumgebung
Die Webapplikation Corp_PadMan wird auf der PWW-Serverfarm zu liegen kommen. Die Webapplikation ist
jeweils auf den Master-Server zu publizieren, die Replikation in die Serverfarm geht automatisch vonstatten.
Weitere Details sind im Dokument Migration zu finden.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
7/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
3.4
Generische Datenspeicherung (Value)
Um die Erweiterbarkeit von PadMan zu erreichen, müssen auch die Values generisch aufgebaut werden. Um die
Benutzung der generischen Values zu vereinfachen, können komplexere Values durch Erweiterungen der Klasse
ValueDetail abgedeckt werden.
Values können auch in Listen aufgeführt werden, so können zum Beispiel zu einer Komponente mehrere
ConnectionStrings erfasst werden. Hierfür wurde eine ValueList mit mehreren Values realisiert.
Für eine Komponente können die Werte in einer Umgebung (Environment) unterschiedlich sein. Wurde für einen
Wert jedoch keine Umgebung definiert, so ist dieser Wert in allen Umgebung gültig. Da es für einen Wert eine
Liste von Werten geben kann, werden ValueDetails in der Klasse Value gekapselt. Als Beispiel seien hier die
ConnectionStrings erwähnt. Für eine Component können mehrere ConnectionStrings definiert werden. Hier
wurde das Composite-Pattern angewendet.
Abbildung 6: Klassenübersicht Values.
3.4.1 Datenbankmodell
Damit Abfragen trotz der komplexen Hierarchie performant ausgeführt werden können, wurde eine redundante
Verbindung zwischen ValueDetail und Component hinzugefügt.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
8/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
tabComponent
tabKey
PK
PK
tabValue
KeyId
PK
ValueId
Name
Label
ReadOnly
InsertDate
InsertUser
UpdateDate
UpdateUser
FK1
FK2
KeyId
ComponentId
InsertDate
InsertUser
UpdateDate
UpdateUser
tabValueListValue
PK,FK1
StatusId
InsertDate
InsertUser
UpdateDate
UpdateUser
tabValueList
ValueListId
PK,FK1
ComponentId
tabSimpleValue
ValueListId
PK,FK1
SimpleValueId
tabCinnectionStringValueDetail
PK
ConnectionStringValueDetailId
FK1
Key
Server
DatabaseName
UserId
Password
TimeOut
Options
InsertDate
InsertUser
UpdateDate
UpdateUser
tabValueDetail
PK
ValueDetailId
FK2
EnvironmentId
SimpleValueId
ComponentId
tabTaskValueDetail
PK
TaskValueDetailId
FK1
Name
Must
ApproverUserId
DueDate
SignerUserId
Signature
InsertDate
InsertUser
UpdateDate
UpdateUser
ValueDetailId
tabPersonValueDetail
PK
PersonValueDetailId
FK1
UserId
AccountTypeId
Comment
HasLead
IsActive
InsertDate
InsertUser
UpdateDate
UpdateUser
ValueDetailId
Abbildung 7: Datenbankmodell Values.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
9/24
Projektname
Dokumenttitel
Artifaktname
4
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
Module
Ein Modul wird jeweils durch eine Klasse repräsentiert. Ein Modul kann jedoch weitere Klasse definieren und
verwenden. Damit die Übersicht in den Modulen gewährleistet ist und die Module somit auch besser wartbar
sind, sind sie in verschiedenen Visual Studio Projekte strukturiert. In den nachfolgenden Kapitel werden die
Modulen pro Visual Studio Projekt beschrieben.
4.1
BasicModule
In diesem Projekt sind Module vorhanden, welche die Grundfunktionalitäten der Applikation abdecken.
4.1.1 CreateComponentModule
Stellt die Funktion neue Komponenten erstellen zur Verfügung. Die Funktion wird im UserInterface durch einen
Dialog dargestellt. Für das Auswählen von Personen benötigt dieses Modul eine Web-Methode, welche auf der
Page vorhanden sein muss.
Abbildung 8: Mockup Dialog „Komponente erstellen“.
4.1.2 DocumentViewModule
Mit diesem Modul können Dateien zu einer Komponente bzw. Applikation hochgeladen werden. Zudem ist es
auch möglich, weitere Links zu erfassen. Speziell sei hier erwähnt, dass das Dokument erst beim Zugriff aus der
Datenbank geladen wird. Auch wird durch die Post-Library das Dokument auf der Harddisk des Webservers
zwischengespeichert.
Abbildung 9: Mockup "Dokumente verwalten".
Abbildung 10: Mockup Dialog „Dokument editieren“.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
10/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
Abbildung 11: Klassenübersicht DocumentViewModule.
4.1.3 HermesLightModule
Dieses Modul deckt die Funktion aus Teamportal ab.
Abbildung 12: Mockup "HERMES Light Angaben".
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
11/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
4.1.4 OverviewModule
Durch dieses Modul erhält der Benutzer eine Übersicht über alle existierenden Komponenten, welche in einem
GridView dargestellt werden. Zudem ist es möglich, die darzustellenden Komponenten zu filtern. Module welche
das Interface IFilterModule implementieren, können die Filterfunktionen erweitern. Die Filter der Module
werden im OverviewModule zusammengeführt und anschliessend an das GridView angebunden.
4.1.5 PathModule
Mit diesem Module können Pfade zu einer Komponente erfasst werden. Benutzer, Admin sowie Extranet URL
sind Pfade zu der Applikation. Zudem verwendet die aktuelle Sendto-Applikation den Pfad Extranet zur
Überprüfung ob die Applikation auch ins Extranet publiziert werden muss. Da die Sendto-Applikation nicht Teil
des Projektes ist, wurde dieses Verhalten übernommen.
Abbildung 13: Mockup "Pfadangaben".
4.1.5.1 Schnittstellen
Wird die Run-Methode ohne Key aufgerufen, so wird GetUserUrl ausgeführt.
GetUserUrl
Beschreibung
Parameter
Holt die UserUrl zu einer Komponente
Objekt Komponente
GetExtranetUrl
Beschreibung
Holt die ExtranetUrl zu einer Komponente
Parameter
Objekt Komponente
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
12/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
4.1.6 PersonViewModule
In dieser Darstellung werden alle Personen (Accounts) angezeigt, welche mit dieser Komponente in Verbindung
sind.
Da der Zugriff auf bestimmte Personen auch in anderen Modulen stattfindet, wurde ein weiteres Modul
PersonManager für den Zugriff definiert. Dieses Modul stellt keine Benutzerschnittstelle zur Verfügung. Für die
einfachere Verwendung des PersonManagers, wurde ein zusätzliches Interface IPersonManagerModule in den
Core aufgenommen.
Abbildung 14: Mockup Personen verwalten.
Abbildung 15: Mockup Dialog "Person editieren".
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
13/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
Abbildung 16: Klassenübersicht PersonViewModule.
Im nachfolgenden Bild ist die Datenbank-Abbildung der Personen dargestellt. Alle Personen werden in der
ValueList „people“ aufgeführt.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
14/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
ValueList
„people“
SimpleValue
SimpleValue
SimpleValue
SimpleValue
PersonValueDetail
Pascal Irminger
„PRJMGR“
...
PersonValueDetail
Pascal Irminger
„DEV“
...
PersonValueDetail
Marcel Lehmann
„DEV“
...
PersonValueDetail
Axel Zenklusen
„DEP“
…
Abbildung 17: Value Struktur People.
4.1.7 PersonManagerModule
Damit das Modul PersonViewModule nicht mit Schnittstellen überlagert wird, wurde ein separates Modul mit
Schnittstellen implementiert. Das PersonManagerModule stellt keine Controls für das UserInterface zur
Verfügung. Damit die Verwendung der Schnittstellen für die Module vereinfacht wird, wurde ein zusätzliches
Interface für diese Klasse definiert.
Abbildung 18: Klassenübersicht PersonManagerModule.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
15/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
4.1.8 PortfolioModule
Dieses Modul übernimmt die Funktionalität Portfolio aus dem Teamportal. Da während des Projektes durch das
Management von IT13 eine Änderung angekündigt wurde, wurde die Funktionalität eins zu eins übernommen.
Abbildung 19: Mockup "Portfolio Angaben".
4.1.9 ReleaseInfoModule
Durch dieses Modul lässt sich Informationen zu der aktuellen Version der Komponente erfassen. Diese
Informationen verwendet die Post-Library für die About-Seite in der Applikation.
Abbildung 20: Mockup "Release Informationen".
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
16/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
4.2
DatabaseModule
In diesem Projekt werden Module zusammengefasst, welche Funktionalitäten zur Datenbank zur Verfügung
stellen.
4.2.1 DatabaseCreationScriptModule
Dieses Modul fügt sich in die SqlConnectionViewModule ein. Durch dieses Modul kann anhand einer
Datenbank-Connection das Script für die Erstellung der Datenbank generiert werden. Für den Benutzer wird eine
Mail-Nachricht geöffnet, welche als Inhalt das Script und als Empfänger den Datenbank-Administrator hat. Das
Script sowie der Empfänger können in der Modul-Administrationsseite verändert werden.
4.2.2 PasswordGeneratorModule
Dieses Modul stellt kein UserInterface zur Verfügung. Es implementiert das IRunnable-Interface welches beim
Aufruf ein generiertes Passwort zur Verfügung stellt. Das Modul SqlConnectionViewModul verwendet dieses
Modul.
4.2.3 SqlConnectionViewModule
Das SqlConnectionViewModule zeigt alle erfassten Connections zu einer Komponente an. Zudem ist es
möglich mit diesem Modul, weitere Connections zu erfassen. Da das Passwort in der Datenbank verschlüsselt
abgelegt wird und bei einem Zugriff einen Log-Eintrag erstellt wird, wird bei der Anzeige das Passwort erst nach
einer Benutzeraktion dargestellt.
Abbildung 21: Klassenübersicht SqlConnectionViewModule.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
17/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
4.3
ProjectWizard
In diesem Projekt wird das Projektdeckblatt implementiert.
4.3.1 ProjectFrontPageModule
Diese Klasse ist für die Darstellung des Projektdeckblattes verantwortlich. Es übernimmt das Erstellen, Verwalten
sowie Löschen von Projektdeckblätter. Pro Projektdeckblatt ist es möglich, die notwendigen Tasks zu definieren.
Anschliessend können Termin gesetzt werden, bis wann ein Task abgeschlossen sein muss.
Wurde ein Task in ein Projektdeckblatt (nachfolgend Tasksheet genannt) aufgenommen, so muss dieser
schlussendlich von einer Person signiert werden. Wurde in der Konfiguration für einen Task der Personenkreis für
das Signieren eingeschränkt, so steht diese Funktion in der Benutzeroberfläche nur für diesen Personenkreis zur
Verfügung.
In der Konfiguration eines Tasks kann ebenfalls eine Erinnerungsfunktion definiert werden. Diese wird durch den
UrlStarter ModuleJob.aspx angestossen.
Ein Tasksheet hat ein Start sowie Enddatum, einen Namen. Zusätzlich kann ein Tasksheet 0 bis Anzahl
vorhanden Tasks haben. In der untenstehenden Abbildung ist die Struktur eines Tasksheets in der Datenbank
dargestellt. Für den Tasksheet „Release 1“ wurden in diesem Beispiel nur einen Task definiert.
ValueList
„taskSheets“
ValueList
„taskSheet“
SimpleValue
„taskSheetName“
StringValueDetail
Release 1
SimpleValue
„taskSheetStart“
StringValueDetail
05.12.2011
SimpleValue
„taskSheetEnd“
StringValueDetail
06.05.2012
SimpleValue
„taskSheetTask“
TaskValueDetail
DB-Review
09.12.2011
Aldo Bittel
Abbildung 22: Value Struktur TaskSheets.
Zur einfacheren Anwendung in der Benutzeransicht, wurde die Abbildung mit der Klasse TaskSheet abstrahiert.
Zusätzlich wurden Konverter definiert, welche zwischen der Datenbank-Objekte und der TaskSheet-Klasse den
Inhalt umwandeln.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
18/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
Abbildung 23: Klassenübersicht TaskSheets.
Jeder Task hat einen eindeutigen Name und wird anhand diesem identifiziert und mit einer TaskDefinition
verbunden. Eine TaskDefinition wird im web.config definiert. Ein Auszug einer TaskDefinition im web.config ist
in der untenstehenden Abbildung ersichtlich.
Der Task DB-Review wird dabei von der Klasse DbReviewTask abstrahiert. Diesen Task dürfen nur bittela und
gerberhe signieren. Zusätzlich wurde ein Erinnerungsmail definiert, welches nach 30 Tag ab Start des TaskSheet
ein Mail versendet. Die Empfänger sind dabei die Personen, welche bei der betroffenen Komponente als
Entwickler definiert wurden. Ein Kopie des Mails wird bittela erhalten. Der Inhalt der Mail wird durch subject
und text definiert. Die Texte können Parameter erhalten, welche zusätzlich in der Liste parameters aufgeführt
werden müssen. Hier in diesem Beispiel wird die aktuelle ID der Komponente in den Inhalt einfliessen.
Die Konfiguration wird durch den Konfigurations-Manager von PadMan eingelesen und als Rückgabe erhält man
eine Liste von ITaskDefinition.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
19/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
Abbildung 24: Klassenübersicht Message.
4.4
SubversionModule
4.4.1 RepositoryModule
Stellt das UserInterface für das Erfassen eines SVN-Pfades zur Verfügung. Zusätzlich zur Texteingabe kann mit
dem Repository Browser der Pfad selektiert werden.
Abbildung 25: Mockup „Repository Browser“.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
20/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
4.4.2 CreateRepoFolderModule
Mit diesem Modul kann der SVN-Pfad im Subversion erstellt werden. Zudem werden die Ordner trunk und
branches hinzugefügt. Der Ordner tags wird zur Zeit ausgeschlossen, da das Pre-Commit-Hook dies zur Zeit nicht
zulässt.
Das Modul stellt keine Controls zur Verfügung.
4.4.3 PeopleAuthenticationModule
Mit diesem Modul lassen sich die Berechtigung zu einem Repository setzten. Beim Aufruf der Run-Methode
werden für alle Applikationen die Berechitgung aktualisiert.
Das Modul stellt keine Controls zur Verfügung.
5
Schnittstellen
5.1
ComponentService
PadMan stellt mit dem ComponentService Schnittstellen zur Verfügung, um die vorhandenen Komponenten
mit deren Personen zu laden. Als Parameter können die gewünschten Personengruppen angegeben werden.
Die Schnittstelle gibt als Resultat ein Objekt vom Typ ComponentServiceResult zurück. Diese enthält alle
Komponente sowie deren Beziehungen. Da die Komponenten als Graph und nicht als Baum aufgebaut sind,
werden die Beziehungen separat aufgeführt. Ansonsten hätte die Serialisierung mit zirkulären Beziehungen ihre
Schwierigkeiten.
Abbildung 26: Klassenübersicht Service-Objekte für ComponentService.
5.2
SendToService
Für das Publizieren der Applikationen existiert die Applikation SendTo. Diese Applikationen ist Teil der Arbeit und
existierte bereits. In dieser Applikation kann der Entwickler eine Applikation auswählen, welche er publizieren
möchte. Bisher holte die Applikation die Daten direkt aus der Datenbank Corp_Teamportal. Mit PadMan wurde
für die Applikation SendTo ein Service implementiert. Dieser Service benötigt alle Applikationen bei welchen der
Benutzer Entwickler oder Stellvertreter ist.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
21/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
Abbildung 27: Klassenübersicht Service-Objekte für SendToService.
5.3
Informationen zu fehlenden Indexes erhalten
Um an Informationen zu allen potentiell fehlenden Indexes in bestehenden Datenbanken zu gelangen, ist der
Aufwand schon grösser. Hier kommen sämtliche Applikations-Datenbanken in Frage. Die unten stehende Tabelle
zeigt die Instanzen der PWW Datenbank Server.
Entwicklung (DEV)
serverdbdev01
serverdbdev02
serverdbdev03
serverdbdev04
Integration (INT)
serverdbint01
serverdbint02
serverdbint03
serverdbint04
Produktion (PROD)
serverdbprod01
serverdbprod02
serverdbprod03
serverdbprod04
Tabelle 1: SQL Server Instanzen im PWW-Umfeld (anonymisiert).
Hinzu kommen die Instanzen der MAP Datenbank Server.
Entwicklung (DEV)
serverdbdev
Integration (INT)
serverdbint
Produktion (PROD)
serverdbmobile1
serverdbmobile2
serverdbprod1
serverdbprod2
Tabelle 2: SQL Server Instanzen im MAP-Umfeld (anonymisiert).
Nachfolgendes SQL-Query selektiert in der bestehenden Intranet-Applikation Corp_SysLog mit Hilfe von
Systemtabellen die möglicherweise fehlenden Indexes auf der entsprechenden Datenbank Server Instanz. Wie
bereits in [01] erwähnt, nimmt Corp_SysLog die Datenselektion lediglich auf der eigenen Datenbank Server
Instanz vor.
SELECT
CAST(migs.user_seeks * migs.avg_total_user_cost * (migs.avg_user_impact *
0.01) AS int) AS index_advantage
,migs.user_seeks
,migs.avg_user_impact
,mid.inequality_columns
,mid.included_columns
,mid.statement
,mid.equality_columns
FROM
sys.dm_db_missing_index_group_stats migs WITH (NOLOCK) INNER JOIN
sys.dm_db_missing_index_groups mig WITH (NOLOCK)
ON migs.group_handle = mig.index_group_handle INNER JOIN
sys.dm_db_missing_index_details mid WITH (NOLOCK)
ON mig.index_handle = mid.index_handle
ORDER BY index_advantage DESC
Listing 1: Abfrage, um Informationen zu fehlenden Indexes zu erhalten.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
22/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
Als Beispielresultat sei hier die aktuelle Server-Antwort von serverdbprod01 dargestellt:
index_
advantage
user_
seeks
inequality_
columns
included_columns
statement
equality_columns
2282433
avg_
user_
impact
65.75
124789
NULL
[Corp_TeamWorkPlace]
.[dbo].[tabWidgetInstance]
[lngWidgetZoneID]
27260
129386
83.86
NULL
[Corp_Wiki]
.[dbo].[tabWikipage]
[lngWikiID]
23377
2190
27.56
NULL
[Corp_SysLog]
.[dbo].[sysssislog]
[event]
12972
60
53.1
NULL
1095
27.51
NULL
[Corp_DSP]
.[dbo].[tabHistory]
[Corp_SysLog]
.[dbo].[sysssislog]
[strActivityID]
11667
7752
382
17.75
[lngBcTypeID]
[Corp_DSP].[dbo].[tabBC]
[bitConfidential],
[bitDeleted]
6875
529
93.72
NULL
[lngWidgetInstanceID],
[lngWidgetID],
[intPosY],
[strUser],
[bitDeleted],
[lngWidgetInstanceDefaultID],
[bitLocked],
[dtmUpdate],
[strUpdateUserID]
[lngWikiPageID],
[lngTextID],
[strPageTitle],
[lngPageRestictionsLevel],
[lngCounter],
[bitIsRedirect],
[dtmTouched],
[dtmRedered],
[txtRenderedText],
[bitDiscussion],
[lngCorrespondingWikipageID]
[id],
[sourceid],
[executionid]
[lngBCID],
[dtmUpdate]
[sourceid],
[executionid],
[endtime]
[lngBCID],
[strBC],
[dtmEnd]
[lngBCID]
[Corp_DSP].[dbo].[tabBC]
6706
19984
97.8
NULL
NULL
6104
1722
91.85
[strEmail]
5625
1058
76.6
[strProcessID]
[strLastname],
[strLastnameAlias],
[strFirstname],
[strFirstnameAlias],
[strFullname],
[strFullnameAlias],
[strOeShort],
[strEmployeeNumber],
[strUserID]
[lngBCID]
[Corp_Blog]
.[dbo].[tabBeitrag]
[Corp_MetaData]
.[dbo].[tabOrgEmployee]
[strProcessID],
[bitDeleted]
[strAutor]
[Corp_DSP].[dbo].[tabBC]
[event]
NULL
[bitDeleted]
Tabelle 3: Beispielresultat der Index-Abfrage.
5.4
Informationen zu Reads-Statistiken erhalten
Bei den Reads-Statistiken verhält es sich ganz ähnlich wie bei den Index-Informationen. Auch die ReadsStatistiken müssen von allen Applikations-Datenbanken mit einbezogen werden, um ein möglichst grosses Bild
mit allen Plattformen erhalten zu können.
SELECT
database_id
,tst1.TraceID
,name
,tst1.StartTime
,tst1.CPU
,tst1.Reads AS maxReads
,tst1.TextData
,tst1.LoginName
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
23/24
Projektname
Dokumenttitel
Artifaktname
Corp_PadMan
Systemdesign Corp_PadMan
Systemdesign
Informationstechnologie
FROM
Corp_SysLog.dbo.tabSysTrace AS tst1 INNER JOIN
(
SELECT
MAX(tst1.TraceID) AS TraceID
FROM
Corp_SysLog.dbo.tabSysTrace AS tst1 INNER JOIN
sys.databases ON tst1.DatabaseID = sys.databases.database_id
WHERE
tst1.Reads > 50 AND LoginName LIKE 'IUSR_%'
GROUP BY sys.databases.database_id
) AS tst2 ON tst2.TraceID = tst1.TraceID INNER JOIN
sys.databases ON tst1.DatabaseID = database_id
ORDER BY maxReads DESC
Listing 2: Abfrage, um Informationen zu Reads-Statistiken zu erhalten.
6
Beschreibung der Elemente
Keine weiter führenden Angaben.
7
Anforderungszuordnung
Keine weiter führenden Angaben.
8
Sicherheit
Keine weiter führenden Angaben.
SD_PADMAN_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 29.03.2012
24/24
Masterthesis „Renewal TeamPortal“
Projektplan
Risikokatalog
Situationsanalyse
Corp_PadMan – Systemanforderungen
Corp_PadMan – Systemdesign
Corp_LogObi – Systemanforderungen
Corp_LogObi – Systemdesign
Corp_JobMonitor – Systemanforderungen
Corp_JobMonitor – Systemdesign
Migration (in der publizierten Version nicht enthalten)
Die Schweizerische Post
Informationstechnologie
Systemanforderungen
Dokumentart
Titel
Projektname
Projektabkürzung
Projektmanager
Ausgabedatum
Autor
Übermittler
Empfänger
Klassifizierung
SY
Systemanforderungen Corp_LogObi
Corp_LogObi
LOGOBI
Irminger Pascal, IT133
28.03.2012
Zenklusen Axel, IT131
Irminger Pascal, IT133
Irminger Pascal, IT133; Lehmann Marcel, IT132; Zenklusen Axel, IT131; Haefeli Stefan,
IT132
Nicht klassifiziert
Änderungskontrolle
Version
Datum
Überarbeitung
Ersteller
Freigabe
X01.01
21.11.2011
Neues Dokument
X01.02
05.03.2012
Erweiterungen und Anpassungen
X01.03
26.03.2012
Korrekturen
X01.04
V01.04
28.03.2012
28.03.2012
Finalisierung
Freigabe
Zenklusen Axel,
IT131
Zenklusen Axel,
IT131
Zenklusen Axel,
IT131
Irminger Pascal, IT133
Irminger Pascal, IT133
Haefeli Stefan, IT132
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
1/22
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
Inhaltsverzeichnis
1 Allgemeines .................................................................................................................................................. 3
1.1 Zweck ........................................................................................................................................................ 3
1.2 Beschreibung ............................................................................................................................................. 3
1.3 Tailoring ..................................................................................................................................................... 3
1.4 Definitionen, Akronyme and Abkürzungen ................................................................................................ 3
1.5 Referenzen ................................................................................................................................................ 3
2 Allgemeine Beschreibung .............................................................................................................................. 4
2.1 Ausgangslage ............................................................................................................................................ 4
2.2 Produktperspektive .................................................................................................................................... 4
3 Allgemeine Anforderungen ........................................................................................................................... 5
3.1 Personas .................................................................................................................................................... 5
3.2 Domainmodell ........................................................................................................................................... 6
3.2.1 Strukturdiagramm .................................................................................................................................. 6
3.2.2 Konzeptbeschreibung ............................................................................................................................. 6
3.3 Use Cases .................................................................................................................................................. 6
3.3.1 L_UC_10: LogEvents importieren ............................................................................................................ 7
3.3.2 L_UC_20: LogEvents anzeigen ................................................................................................................ 8
3.3.3 L_UC_30: LogEvent Details anzeigen ...................................................................................................... 9
3.3.4 L_UC_40: LogEvent löschen .................................................................................................................. 10
3.3.5 L_UC_50: LogEvent Status ändern ........................................................................................................ 11
3.3.6 L_UC_60: Library Fehler markieren ....................................................................................................... 12
3.3.7 L_UC_70: Filter verwalten (CRUD) ......................................................................................................... 13
3.3.8 L_UC_80: Filter anwenden .................................................................................................................... 14
3.3.9 L_UC_90: LogEvents gruppieren ........................................................................................................... 15
3.3.10 L_UC_100: Überwachung definieren (CRUD) ........................................................................................ 16
3.3.11 L_UC_110: User informieren / alarmieren ............................................................................................. 17
3.3.12 L_UC_120: Applikationen je LogEvent ansehen .................................................................................... 18
3.3.13 L_UC_130: Auswertungen ansehen ...................................................................................................... 19
3.3.14 L_UC_140: LogEvents säubern (Clean) .................................................................................................. 20
3.4 Nicht-funktionale Anforderungen ............................................................................................................ 21
3.4.1 Technische Anforderung ....................................................................................................................... 21
3.4.2 Ergonomische Anforderung .................................................................................................................. 21
3.4.3 Verfügbarkeit ........................................................................................................................................ 21
3.4.4 Benutzerfreundlichkeit .......................................................................................................................... 21
3.4.5 Datenverlust ......................................................................................................................................... 21
3.4.6 Auftreten von Fehlfunktionen ............................................................................................................... 21
3.4.7 Sicherheit ............................................................................................................................................. 21
3.4.7.1 Authentifizierung ............................................................................................................................... 21
3.4.7.2 SQL-Injektion ..................................................................................................................................... 21
3.4.7.3 X-Site Scripting .................................................................................................................................. 21
3.4.7.4 Scripts................................................................................................................................................ 21
4 Anforderungen an die Entwicklungs- und Wartungsumgebung .................................................................. 22
5 Anforderungen an die externen Schnittstellen ............................................................................................ 22
6 Detailanforderungen ................................................................................................................................... 22
7 Sicherheitsanforderungen ........................................................................................................................... 22
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
2/22
Projektname
Dokumenttitel
Artifaktname
1
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
Allgemeines
1.1
Zweck
Die Systemanforderungen beschreiben und strukturieren die Anforderungen an das zukünftige System. Sie
werden vom Auftraggeber und Auftragnehmer beidseitig als Grundlage für die Realisierung und Abnahme des
zukünftigen Systems akzeptiert.
1.2
Beschreibung
Die Systemanforderungen beziehen sich je nach Phase auf die Ebene System, Subsystem oder
Konfigurationseinheit (KE). Eine verfeinerte Gliederung muss vom entsprechenden Vorgehensmodell hinzugefügt
werden. Die Darstellung der Systemanforderungen kann sowohl in strukturiertem Text als auch in Form von
Modellen erfolgen.
1.3
Tailoring
Die Systemanforderungen können auch in mehreren eigenständigen Dokumenten vorliegen, zum Beispiel pro
Subsystem oder Konfigurationseinheit.
1.4
Definitionen, Akronyme and Abkürzungen
Wort
Definition
DBA
HTTP
Datenbank-Administrator
Das Hypertext Transfer Protocol ist ein Protokoll zur Übertragung von Daten über ein
Netzwerk. Es wird hauptsächlich eingesetzt, um Webseiten aus dem Internet/Intranet in
einen Webbrowser zu laden.
Das HyperText Transfer Protocol Secure ist die sichere Variante von HTTP. Syntaktisch ist
HTTPS identisch mit dem Schema für HTTP, die zusätzliche Verschlüsselung der Daten
geschieht mittels SSL/TLS.
Internet Information Services. Webserver-Komponente in Microsoft Windows. Über IIS
können ASP- oder .NET-Applikationen (ASP.NET) ausgeführt werden
.NET-Entwicklungsabteilung von IT Post
Informationstechnologie Post
Skriptsprache, die hauptsächlich für das DOM-Scripting in Web-Browsern eingesetzt wird.
Das Lightweight Directory Access Protocol (LDAP) erlaubt die Abfrage und die Modifikation
von Informationen eines Verzeichnisdienstes über ein IP-Netzwerk.
Für .NET portiertes O/R-Mapping Framework (Hibernate).
Technik der Softwareentwicklung, mit der ein in einer objektorientierten
Programmiersprache geschriebenes Anwendungsprogramm seine Objekte in einer
relationalen Datenbank ablegen kann.
Post Wide Web. Das Intranet der Schweizerischen Post.
Structured Query Language
Auch Microsoft SQL Server. SQL Server Produkt von Microsoft. Derzeit in den Versionen
SQL Server 2005 und SQL Server 2008 R2 bei der Schweizerischen Post im Einsatz.
Secure Sockets Layer, Transport Layer Security
Cross-Site-Scripting (XSS) bezeichnet das Ausnutzen einer Sicherheitslücke in
Webanwendungen, indem Informationen aus einem Kontext, in dem sie nicht
vertrauenswürdig sind, in einen anderen Kontext eingefügt werden, in dem sie als
vertrauenswürdig eingestuft werden. Aus diesem vertrauenswürdigen Kontext kann dann
ein Angriff gestartet werden.
HTTPS
IIS
IT13
IT Post
Javascript
LDAP
NHibernate
O/R-Mapping
PWW
SQL
SQL Server
SSL/TLS
X-Site-Scripting
1.5
Referenzen
Nr.
Titel
[01]
Systemanforderungen Corp_PadMan
SY_PADMAN_Systemanforderung_V01.03.docx
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
3/22
Projektname
Dokumenttitel
Artifaktname
2
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
Allgemeine Beschreibung
2.1
Ausgangslage
Die Applikation LogEventViewer ist eine der meistbenutzen Applikationen von IT13. Hier werden die Logs
gesammelt und für die Entwickler zugänglich gemacht. Es kann also für jede Applikation überprüft werden, wie
stabil diese läuft.
2.2
Produktperspektive
Mit PadMan wird eine neue zentrale Applikation entstehen, die das Verwalten und Entwickeln von
Applikationen unterstützten soll. Dabei wird den Entwicklern auch ein neues Log/Error Tool „LogObi“ zur
Verfügung gestellt. Im Laufe der Zeit, haben sich immer mehr Anforderungen an das Logging ergeben, die nun
mit LogObi abgedeckt werden sollen. Hierbei ist auch eine Neuausrichtung in Planung. Bis heute gab es einfach
einen LogViewer, in dem die Entwickler ihre Errors und Warnings verfolgen konnten. Das Ziel ist es nun, dieses
System in Benutzerfreundlichkeit und Effizienz zu verbessern. Die Bedürfnisse die LogObi abdecken soll sind:
LogObi als Entwicklungsinstrument
LogObi als Analyseinstrument
LogObi als aktives Alarming
Das neue Logging-Tool soll aufgetretene Fehlerlogs in produktiven Applikationen nicht mehr länger nur anzeigen
können (Pull), sondern aktiv die verantwortlichen Entwickler darüber informieren (Push). Durch ein geeignetes
Regelwerk sollen die Entwickler in der Lage sein, die Benachrichtigungen, welche sie erhalten, zu steuern und
gegebenenfalls einzuschränken.
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
4/22
Projektname
Dokumenttitel
Artifaktname
3
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
Allgemeine Anforderungen
3.1
Personas
Hier seien noch einmal die drei Personas aus [01] erwähnt: Peter Ledermann (44), Manuel Imhof (28) und
Sabrina Schmid (32).
Peter Ledermann (44): Hat gute Computerkenntnisse und arbeitet häufig mit Office
(Word, Excel) sowie mit SAP. Er arbeitet als Manager und muss so die Kosten der
Applikationen sowie deren Offerten überwachen. Er ist verantwortliche für die
Ressourcenplanung der Entwickler und versucht so mit den Kunden eine Terminplanung
der Anwendungen zu definieren. Falls die Kosten einer Anwendungsentwicklung den
Betrag der Offerte überschreiten, versucht er, mögliche Lösungen mit dem Kunde zu
finden. Bei Kundenanfragen für eine neue Anwendung bzw. neue Funktionen zu einer
bestehenden Applikation konsolidiert er die bereits vorhanden Implementierungen und
zeigt dem Kunde mögliche Lösungen wie zum Beispiel mandantenfähige Applikationen.
Manuel Imhof (28): Hat forgeschrittene Computerkenntnisse und arbeitet als SoftwareEntwickler im Webumfeld. Er nutzt das Internet als Informations- und
Unterhaltungsinstrument. Als Entwickler einer Anwendung ist er meistens zugleich
Projektleiter. Für das Verwalten von Anwendungen für Support sowie Wartung ist er
selber verantwortlich. Für das Entwickeln einer Anwendung verwendet er Visual Studio
und er verwaltet seinen Source Code mit Subversion. Als Unterstützung zur Entwicklung
der Anwendung steht ihm eine Library, welche speziell für diese Abteilung entwickelt
wurde, zur Verfügung. Häufig entwickelt er Anwendungen im Kostenbereich 10‘000 bis
100‘000 Franken. Bei diesen Anwendungen ist er für alle notwendigen Schritte von
Offerte bis zur Publikation der Anwendung selber verantwortlich. Er übernimmt auch die
Schnittstelle zum Kunde. Bei grösseren Anwendung arbeitet er in einem Team von
Entwickler und ihm werden diverse Rollen übergeben. Es kann aber auch sein, dass er die
Funktion Projektleiter übernimmt, jedoch keinen Code entwickeln wird.
Sabrina Schmid (32): Hat gute Computerkenntnisse und das Arbeiten mit
Webapplikationen fällt ihr leicht. Als 2nd-Level-Supporterin nutzt sie das Telefon und EMail sehr häufig. Sie ist die Schnittstelle zwischen den Entwicklern und den Benutzern.
Kann der 1st-Level-Support eine Anfrage nicht beantworten, so wird diese Anfrage an
Sabrina weitergeleitet. Falls sie die Anfrage nicht selber beantworten kann, informiert sie
den Verantwortlichen der Anwendung, zu welcher die Anfrage gerichtet ist. Die
Kommunikation zum Benutzer übernimmt sie weiterhin. Der Verantwortliche wird ihr die
Antwort entweder mündlich oder schriftlich geben. Das Verwalten sowie Überwachen der
Anfragen und deren Bearbeitungszeit übernimmt ebenfalls Sabrina. Für diese Aufgabe
stehen ihr verschiedene Stellvertreter sowie Mitarbeiter zur Verfügung, so dass während
den Büroarbeitszeiten die Anfragen so schnell wie möglich beantwortet werden können.
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
5/22
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
3.2
Domainmodell
3.2.1 Strukturdiagramm
Abbildung 1: Domainmodell Corp_LogObi.
3.2.2 Konzeptbeschreibung
LogEvent
Beschreibung
Enthält den eigentlichen Logeintrag
Attribute
Beziehung
Es können verschiedene Filter auf eine beliebige Anzahl LogEvents passen
Filter
Beschreibung
Attribute
Beziehung
Enthält den Filter mit den passenden Kriterien
Es können verschiedene Filter auf eine beliebige Anzahl LogEvents passen
3.3
Use Cases
In der untenstehenden Tabelle werden alle Use Cases mit deren Gewichtung dargestellt. Die Gewichtung wird
zwischen 1 und 10 definiert. Dabei gilt ein Wert von 10 zwingend zu implementieren und einen Wert von 1 als
„nice to have“. Umso höher der Wert Kritisch ist, je mehr Unklarheiten bzw. Wissen fehlt für die benötigte
Funktion.
Name
LogEvents importieren
LogEvents anzeigen
LogEvent Details anzeigen
LogEvent löschen
LogEvent Status ändern
Library Fehler markieren
Filter verwalten (CRUD)
Filter anwenden
LogEvents gruppieren
Überwachung definieren (CRUD)
User informieren / alarmieren
Applikationen je LogEvent ansehen
Auswertungen ansehen
LogEvents säubern (Clean)
SY_LOGOBI_Systemanforderung_V01.04.docx
Bezeichnung
L_UC_10
L_UC_20
L_UC_30
L_UC_40
L_UC_50
L_UC_60
L_UC_70
L_UC_80
L_UC_90
L_UC_100
L_UC_110
L_UC_120
L_UC_130
L_UC_140
© Die Schweizerische Post
Ausgabedatum 28.03.2012
Gewicht
10
10
10
8
5
5
5
5
2
4
4
1
1
5
Kritisch
4
1
1
1
2
1
2
3
3
1
1
3
1
1
6/22
Projektname
Dokumenttitel
Artifaktname
3.3.1
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
L_UC_10: LogEvents importieren
Bezeichnung
L_UC_10
Name
LogEvents importieren
Scope
LogObi
Level
SystemAktion
Primärer Aktor
System
Stakeholder
Entwickler
Interessen
Entwickler will aktuelle LogEvents sehen.
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Aktor löst Event für Import aus
2. System importiert die Daten und
stösst Verarbeitung an
3. Stored Procedure verarbeitet die
importierten Logs und reichert diese
an.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
häufig
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
7/22
Projektname
Dokumenttitel
Artifaktname
3.3.2
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
L_UC_20: LogEvents anzeigen
Bezeichnung
L_UC_20
Name
LogEvents anzeigen
Scope
LogObi
Level
SystemAktion
Primärer Aktor
System
Stakeholder
Entwickler
Interessen
Entwickler will aktuelle LogEvents sehen.
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1.
Benutzer startet die Anwendung
2. System zeigt die auf den Benutzer
passenden LogEvents an.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
häufig
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
8/22
Projektname
Dokumenttitel
Artifaktname
3.3.3
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
L_UC_30: LogEvent Details anzeigen
Bezeichnung
L_UC_30
Name
LogEvent Details anzeigen
Scope
LogObi
Level
SystemAktion
Primärer Aktor
System
Stakeholder
Entwickler
Interessen
Entwickler will die Details des aktuellen LogEvents sehen.
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1.
Benutzer wählt auf einem
Logevent Details an
2.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
System zeigt dem Benutzer alle
Details dieses LogEvents
häufig
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
9/22
Projektname
Dokumenttitel
Artifaktname
3.3.4
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
L_UC_40: LogEvent löschen
Bezeichnung
L_UC_40
Name
LogEvent löschen
Scope
LogObi
Level
Benutzeraktion
Primärer Aktor
Entwickler
Stakeholder
Interessen
Entwickler will den LogEvent aus der Ansicht entfernen.
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Entwickler löscht einen LogEvent
2. Es wird die Liste der verbleibenden
LogEvents angezeigt.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
Dieser Use Case soll auch auf alle LogEvents auf einem Filter anwendbar sein.
häufig
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
10/22
Projektname
Dokumenttitel
Artifaktname
3.3.5
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
L_UC_50: LogEvent Status ändern
Bezeichnung
L_UC_50
Name
LogEvent Status ändern
Scope
LogObi
Level
Benutzeraktion
Primärer Aktor
Entwickler
Stakeholder
Interessen
Entwickler will anderen Entwicklern zeigen, dass er einen LogEvent bearbeitet
oder gelöst hat.
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Entwickler wählt den passenden
LogEvent aus.
2. System zeigt ihm die verfügbaren
Status an.
3. Benutzer wählt den passenden
Status und speichert ihn.
4. Event wird mit dem gewählten
Status gespeichert.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
Dieser Use Case soll auch auf alle LogEvents auf einem Filter anwendbar sein.
häufig
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
11/22
Projektname
Dokumenttitel
Artifaktname
3.3.6
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
L_UC_60: Library Fehler markieren
Bezeichnung
L_UC_60
Name
Library Fehler markieren
Scope
LogObi
Level
Benutzeraktion
Primärer Aktor
Entwickler
Stakeholder
Interessen
Entwickler will den LogEvent als Library verursacht kennzeichnen.
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Entwickler markiert einen Event
der Liste als Library verursacht.
2. System führt den Fehler unter der
Library-Fehlern.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
Dieser Use Case soll auch auf alle LogEvents auf einem Filter anwendbar sein.
häufig
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
12/22
Projektname
Dokumenttitel
Artifaktname
3.3.7
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
L_UC_70: Filter verwalten (CRUD)
Bezeichnung
L_UC_70
Name
Filter verwalten (CRUD)
Scope
LogObi
Level
SystemAktion
Primärer Aktor
System
Stakeholder
Entwickler
Interessen
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer wählt einen Filter den er
bearbeiten will.
2. System zeigt passenden Filter an
3. Benutzer bearbeitet den Filter
4. Benutzer teilt dem System mit,
dass er die Änderungen
übernehmen will
5. System Speichert die Änderungen
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
häufig
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
13/22
Projektname
Dokumenttitel
Artifaktname
3.3.8
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
L_UC_80: Filter anwenden
Bezeichnung
L_UC_80
Name
Filter anwenden
Scope
LogObi
Level
Benutzeraktion
Primärer Aktor
Entwickler
Stakeholder
Interessen
Entwickler will die angezeigten LogEvents einschränken.
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer will einen Filter
definieren.
2. Benutzer erstellt Filter.
3. Filter wird in der Filerliste und im
Dropdown anzezeigt.
Erweiterung
2a. Basisfilter benutzen.
1. Benutzer gibt Filterdaten ein.
1a. Benutzer gibt einen Text ein der auf allen Feldern gesucht wird.
1b. Benutzer schränkt von Datum / Zeit ein.
1c. Benutzer schränkt bis Datum / Zeit ein.
1d. Benutzer schränkt Komponente ein.
1e. Benutzer schränkt User ein.
1f. Benutzer schränkt Machine ein.
1g. Benutzer schränkt Environment ein.
1h. Benutzer schränkt Plattform ein.
1i. Benutzer schränkt Path ein.
1j. Benutzer schränkt Level ein.
2b. Erweiterter Filter benutzen.
1. Benutzer gibt Filterstring ein.
Spezialanforderung Auftrittshäufigkeit
häufig
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
14/22
Projektname
Dokumenttitel
Artifaktname
3.3.9
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
L_UC_90: LogEvents gruppieren
Bezeichnung
L_UC_90
Name
LogEvents gruppieren
Scope
LogObi
Level
Benutzeraktion
Primärer Aktor
Entwickler
Stakeholder
Interessen
Entwickler will einen definierten Filter zusammengefasst anzeigen lassen.
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Entwickler will seine Ansicht der
LogEvents durch Gruppieren
vereinfachen.
2. Entwickler wählt „Gruppe
erstellen“.
3. System zeigt die vorhandenen Filter
an.
4. Benutzer wählt einen oder
mehrere Filter für die Gruppe aus.
4.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
System zeigt nun die Gruppe der
Events an.
4a. Passender Filter existiert noch nicht.
1. Benutzer startet Filter definieren.
wenig
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
15/22
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
3.3.10 L_UC_100: Überwachung definieren (CRUD)
Bezeichnung
L_UC_100
Name
Überwachung definieren (CRUD)
Scope
LogObi
Level
SystemAktion
Primärer Aktor
System
Stakeholder
Entwickler
Interessen
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
1.
Systemverantwortlichkeit
Benutzer wählt Überwachen
2.
System zeigt eingerichtete
Überwachungen benutzerbezogen
an.
5.
System zeigt die Überwachung in
der Liste der Überwachungen an
3.
Benutzer wählt eine Bestehende
Überwachung aus oder erstellt
eine Neue
4. Benutzer macht Anpassungen
und speichert diese
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
häufig
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
16/22
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
3.3.11 L_UC_110: User informieren / alarmieren
Bezeichnung
L_UC_110
Name
User informieren / alarmieren
Scope
LogObi
Level
SystemAktion
Primärer Aktor
System
Stakeholder
Entwickler
Interessen
Vorbedingung
Überwachung ist aktiv und Schwellwert tritt ein
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1.
Aktor informiert System über das
Überschreiten des Schwellwertes
2.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
Benutzer wird durch System
informiert.
häufig
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
17/22
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
3.3.12 L_UC_120: Applikationen je LogEvent ansehen
Bezeichnung
L_UC_120
Name
Applikationen je LogEvent ansehen
Scope
LogObi
Level
Benutzeraktion
Primärer Aktor
Entwickler
Stakeholder
Interessen
Entwickler will sehen, ob der gleiche LogEvent noch in anderen Applikationen
aufgetreten ist.
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Entwickler wählt den passenden
LogEvent/Filter aus.
2. Entwickler teilt dem System mit,
dass er die applikationsübergreifende Ansicht will.
3. Eine Zusammenfassung des
LogEvents wird
applikationsübergreifend
angezeigt.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
Dieser Use Case soll auch auf alle LogEvents auf einem Filter anwendbar sein.
selten
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
18/22
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
3.3.13 L_UC_130: Auswertungen ansehen
Bezeichnung
L_UC_130
Name
Auswertungen ansehen
Scope
LogObi
Level
Benutzeraktion
Primärer Aktor
Manager
Stakeholder
Interessen
Manager will sich über die Verteilung der Fehler informieren
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer wählt welche
Auswertung er sehen will.
2.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
System zeigt passende Auswertung
an.
häufig
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
19/22
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
3.3.14 L_UC_140: LogEvents säubern (Clean)
Bezeichnung
L_UC_140
Name
LogEvents säubern (Clean)
Scope
LogObi
Level
SystemAktion
Primärer Aktor
Job-Agent
Stakeholder
Entwickler
Interessen
Entwickler will keine veralteten Events sehen.
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Aktor teilt System mit, dass die
LogEvents aufgeräumt werden
müssen
2. System löscht die LogEvents die
älter sind, als die definierte
Obergrenze
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
häufig
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
20/22
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
3.4
Nicht-funktionale Anforderungen
3.4.1 Technische Anforderung
Das System muss mit ASP.NET in der Sprache C# entwickelt werden und in einem .NET 4.0 Pool auf einem
Windows Server 2008 laufen. Die Anwendung muss mit einem O/R-Mapper implementiert werden und
mindestens mit der Datenbank SQL Server 2008 arbeiten können.
3.4.2 Ergonomische Anforderung
Die Applikation unterstützt die Lokalisierung, es wird jedoch nur eine deutsche Benutzerführung zur Verfügung
gestellt.
3.4.3 Verfügbarkeit
Die Applikation ist während den allgemeinen Bürozeiten (Mo-Fr 07:00-19:00 Uhr) verfügbar. Bei einem Incident,
welcher von der Applikation ausgeht und das PWW betrifft, ist eine max. Behebungszeit von 4 Stunden
notwendig. Ist der Betrieb von PWW jedoch nicht beeinflusst, wird die Störung nach Best Effort bearbeitet. Bei
Incidents, welche von ausserhalb des Einflussbereiches von Corp_LogObi stammen, können keine Angaben
gemacht werden.
Als „Fallback“ sind die LogFiles für die Entwickler zugänglich. Was aber auch nur als temporäre Lösung
angeboten werden kann.
Es kann sein, dass im Fehlerfall, der Import der Logs von den DBAs abgeschaltet wird, um die Datenbank zu
entlasten. Dies ist ein geplanter Ausfall und wird nicht berücksichtigt.
3.4.4 Benutzerfreundlichkeit
Obwohl die Benutzer der Software über gute bis sehr gute Computerkenntnisse verfügen werden, soll viel Wert
auf ein intuitives und übersichtliches Design gelegt werden. Um dies zu erreichen, soll eine einheitliche
Benutzerführung definiert werden, wodurch es den Benutzern des System in wenigen Schritten möglich ist, eine
Aufgabe erfolgreich zu lösen. Das System wird über eine grafische Benutzeroberfläche mit übersichtlicher
Menüführung1 verfügen, die mindestens im Internet Explorer 9 dargestellt wird. Andere Browser werden, sofern
diese den Standard implementieren, soweit wie möglich unterstützt.
3.4.5 Datenverlust
Wenn während der Eingabe von Daten eine Fehlfunktion auftritt, gehen nur die noch nicht in die Datenbank
übertragenen Daten verloren. Dabei wird es sich lediglich um gerade eingegebene Daten handeln. Der Verlust
von Daten in der Datenbank wird durch ein Backup, welches in unserer Umgebung bereits im Einsatz ist,
verhindert.
3.4.6 Auftreten von Fehlfunktionen
Sollte tatsächlich eine Fehlfunktion auftreten, so soll dem Benutzer dies mitgeteilt werden. Es soll jedoch nie eine
Fehlerseite des Webservers angezeigt werden.
3.4.7 Sicherheit
3.4.7.1 Authentifizierung
Die Authentifizierung wird durch die vorhandenen Mittel der Post (LDAP und Windows-Authentifizierung von IIS)
abgedeckt. Diese wird sowohl für Benutzer als auch für Fremdsysteme, welche über eine Schnittstelle zugreifen,
erforderlich sein.
3.4.7.2 SQL-Injektion
SQL-Injektion wird durch den Einsatz des O/R-Mappers NHibernate verhindert.
3.4.7.3 X-Site Scripting
Durch das Entfernen von HTML-Tags bei Eingabemöglichkeiten von Benutzern wie auch Fremdsystemen wird das
X-Site Scripting unterbunden.
3.4.7.4 Scripts
Scripts wie Javascript werden durch die Post-Library abgedeckt.
1
Die Übersichtlichkeit wird von ausgewählten Benutzern beurteilt.
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
21/22
Projektname
Dokumenttitel
Artifaktname
4
Corp_LogObi
Systemanforderungen Corp_LogObi
Systemanforderungen
Informationstechnologie
Anforderungen an die Entwicklungs- und Wartungsumgebung
Keine weiter führenden Angaben.
5
Anforderungen an die externen Schnittstellen
Keine weiter führenden Angaben.
6
Detailanforderungen
Keine weiter führenden Angaben.
7
Sicherheitsanforderungen
Keine weiter führenden Angaben.
SY_LOGOBI_Systemanforderung_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
22/22
Masterthesis „Renewal TeamPortal“
Projektplan
Risikokatalog
Situationsanalyse
Corp_PadMan – Systemanforderungen
Corp_PadMan – Systemdesign
Corp_LogObi – Systemanforderungen
Corp_LogObi – Systemdesign
Corp_JobMonitor – Systemanforderungen
Corp_JobMonitor – Systemdesign
Migration (in der publizierten Version nicht enthalten)
Die Schweizerische Post
Informationstechnologie
Systemdesign
Dokumentart
Titel
Projektname
Projektabkürzung
Projektmanager
Ausgabedatum
Autor
Übermittler
Empfänger
Klassifizierung
SD
Systemdesign Corp_LogObi
Corp_LogObi
LOGOBI
Irminger Pascal, IT133
28.03.2012
Zenklusen Axel, IT131
Irminger Pascal, IT133
Irminger Pascal, IT133; Lehmann Marcel, IT132; Zenklusen Axel, IT131; Haefeli Stefan,
IT132
Nicht klassifiziert
Änderungskontrolle
Version
Datum
Überarbeitung
Ersteller
Freigabe
X01.00
07.11.2011
Neues Dokument
X01.01
12.12.2011
Erweiterungen Datenbank
X01.02
09.01.2012
Filtern und Alarming
X01.03
29.01.2012
X01.04
05.03.2012
X01.05
16.03.2012
Erweitern um Mockups und Beschreibungen
Aktualisieren DB-Jobs, Komponenten
(Rekursiv)
Windows Service Install und Config
X01.06
26.03.2012
Korrekturen
X01.07
V01.07
28.03.2012
28.03.2012
Finalisierung
Freigabe
Zenklusen Axel,
IT131
Zenklusen Axel,
IT131
Zenklusen Axel,
IT131
Zenklusen Axel,
IT131
Zenklusen Axel,
IT131
Zenklusen Axel,
IT131
Zenklusen Axel,
IT131
Irminger Pascal, IT133
Irminger Pascal, IT133
Haefeli Stefan, IT132
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
1/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
Inhaltsverzeichnis
1 Allgemeines .................................................................................................................................................. 3
1.1 Zweck ........................................................................................................................................................ 3
1.2 Beschreibung ............................................................................................................................................. 3
1.3 Tailoring ..................................................................................................................................................... 3
1.4 Definitionen, Akronyme und Abkürzungen ................................................................................................ 3
1.5 Referenzen ................................................................................................................................................ 3
2 Lösungsvorschläge für die Struktur des Systemdesigns .................................................................................. 4
2.1 Mögliche Importwege ................................................................................................................................ 5
2.2 Filtermöglichkeiten .................................................................................................................................... 6
3 Systemdesign Global ..................................................................................................................................... 7
3.1 Ablauf ....................................................................................................................................................... 7
3.2 Datenbank-Modell ..................................................................................................................................... 7
4 Systemdesign Logs importieren ..................................................................................................................... 9
4.1 LogImporter ............................................................................................................................................... 9
4.1.1 Installation & Starten .............................................................................................................................. 9
4.1.2 Config .................................................................................................................................................... 9
4.2 FileTransferTask ........................................................................................................................................ 10
4.3 FileImportTask .......................................................................................................................................... 10
4.4 BCP ......................................................................................................................................................... 10
5 Datenbank-Jobs .......................................................................................................................................... 11
5.1 Data Processing ....................................................................................................................................... 11
5.1.1 Insert New Values ................................................................................................................................. 12
5.2 Erstellen der Statistik ................................................................................................................................ 12
5.3 Aufräumen der Daten .............................................................................................................................. 12
6 View Applikation ........................................................................................................................................ 14
6.1 Anzeigen der LogEvents ........................................................................................................................... 14
6.2 Filtern ...................................................................................................................................................... 15
6.3 Status Anhand von Filtern setzen ............................................................................................................. 16
6.4 LogEvent Status ....................................................................................................................................... 17
6.5 Alarming.................................................................................................................................................. 18
6.6 Alarming History ...................................................................................................................................... 19
6.7 Auswertungen ......................................................................................................................................... 20
6.8 Applikationen je LogEvent ....................................................................................................................... 20
6.9 Anbieten der Komponenten aus PadMan ................................................................................................ 21
7 Schnittstellen .............................................................................................................................................. 21
7.1 Logfiles .................................................................................................................................................... 21
7.2 Daten aus Corp_PadMan ......................................................................................................................... 21
7.3 Alarming.................................................................................................................................................. 22
8 Beschreibung der Elemente ......................................................................................................................... 23
9 Anforderungszuordnung ............................................................................................................................ 24
10 Sicherheit.................................................................................................................................................... 24
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
2/24
Projektname
Dokumenttitel
Artifaktname
1
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
Allgemeines
1.1
Zweck
Das Systemdesign ist eine Verfeinerung der Systemarchitektur und beschreibt die detaillierten Spezifikationen als
Vorgabe für die Erstellung des Systems.
1.2
Beschreibung
Eine verfeinerte Gliederung muss vom entsprechenden Vorgehensmodell hinzugefügt werden. Die Darstellung
des Systemdesigns kann sowohl in strukturiertem Text als auch in Form von Modellen (z.B. Datenfluss-, Zustandübergangsmodelle, usw.) erfolgen. Das Systemdesign ist ein abschliessender Entwurf des technischen und organisatorischen Systems bis auf Stufe «Element».
1.3
Tailoring
Das Systemdesign kann auch in mehreren eigenständigen Dokumenten vorliegen, zum Beispiel pro Systemelement (entspricht der kleinsten Systemzerlegungsstufe).
1.4
Definitionen, Akronyme und Abkürzungen
Wort
Definition
BCP
Corp_PadMan
Ein DatenbankHilfsprogramm
Corp_PadMan ist die neue Intranet-Applikation zur Verwaltung aller Intranet-Applikationen
im PWW-Umfeld. Die dazugehörige Datenbank trägt denselben Namen.
Siehe Development.
Server-Umgebung Entwicklung (Stufe 1). Die Beschreibung definiert sowohl Datenbank- als
auch Webserver.
Beschreibt die Server-Umgebung. Es wird unterschieden zwischen Entwicklung, Integration
und Produktion resp. Development, Integration und Production.
Foreign Key = Fremdschlüssel
Server-Umgebung Integration (Stufe 2). Die Beschreibung definiert sowohl Datenbank- als
auch Webserver.
Primary Key = Primärschlüssel
Siehe Production.
Server-Umgebung Produktion (Stufe 3). Die Beschreibung definiert sowohl Datenbank- als
auch Webserver.
Die Structured Query Language ist eine Datenbanksprache zur Definition von Datenstrukturen in relationalen Datenbanken sowie zum Bearbeiten (Einfügen, Verändern, Löschen) und
Abfragen von darauf basierenden Datenbeständen.
Der Microsoft SQL Server ist ein relationales Datenbankmanagementsystem von Microsoft.
Der SQL Server Agent ist ein Microsoft Windows-Dienst, der geplante administrative Tasks
ausführt, die als Jobs bezeichnet werden. Der SQL Server Agent verwendet SQL Server, um
Job-Informationen zu speichern.
DEV
Development
Environment
FK
Integration
PK
PROD
Production
SQL
SQL Server
SQL Server Agent
1.5
Referenzen
Nr.
Titel
[01]
Systemanforderungen Corp_LogObi
SY_LOGOBI_Systemanforderung_V01.04.docx
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
3/24
Projektname
Dokumenttitel
Artifaktname
2
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
Lösungsvorschläge für die Struktur des Systemdesigns
Folgende Ziele sollen verfolgt werden:
log4net soll bleiben, da bewährt
Erweiterte Abfragemöglichkeiten
Gruppieren von Fehlern
Es sind 3 Lösungen denkbar:
1. „Alt“: Tabellen so lassen, wie sie sind. Keine Anpassung am Logging.
2. „Job/Trigger“: Neue Tabellen mit aufbereiteten Daten, Import über Datenbank-Job / Trigger.
3. „LogFiles“: Neue Tabellen mit aufbereiteten Daten, Import aus Log-Files.
Bei Variante eins würde jegliche Filterung der Daten mit Abfragen auf dem aktuellen Datenbankmodell sein. Es
würden viele „LIKE“-Abfragen generiert, welche eine hohe Last zur Folge hätten.
Variante zwei und drei würden es erlauben, die Daten in einer abfragefreundlichen Form zu speichern, was bei
den neuen Features sehr nützlich wäre. Bei Variante zwei ist nicht einmal eine Anpassung des Loggings nötig.
Bei Variante „LogFiles“ hingegen würde das Logging so angepasst, dass die aktuellen Applikationen in Files auf
den Webservern loggen würden und diese dann von der „Datenbank“ importiert würden.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
4/24
Projektname
Dokumenttitel
Artifaktname
2.1
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
Mögliche Importwege
Nach dem Abklären, welche Möglichkeiten
und Ziele mit dem Logging erreicht werden
sollen, haben sich drei Wege als möglich
herauskristallisiert.
Einerseits das direkte Logging in die Datenbank. Hier ist der Hauptvorteil im verzögerungsfreien Logging. Da direkt in die Datenbank geloggt wird, sind die Logs sofort abrufbar. Jedoch ist mit den gleichen Problemen zu rechnen wie beim aktuellen Logging.
Dieses kann jedoch den Server zusätzlich
belasten, wenn nebenher eine Störung im
System besteht. Wird bei einer Überlastung
des produktiven Systems das Logging abgeschaltet, gehen Logs verloren.
Als zweite Lösung wurde das indirekte Loggen über eine zweite Datenbank angedacht.
Es wäre noch immer recht schnell, die Logs
würden vorverarbeitet werden und man
könnte im Notfall das Importieren in die
produktive Datenbank abschalten. Sobald
die Überlastung des produktiven Systems
behoben wurde, kann der Import aktiviert
werden und die Logs werden rückwirkend in
das produktive System eingespielt.
Als dritte Lösung wäre das Logging in Files
vorgesehen. Diese Files werden dann von
den Servern gesammelt und in die Datenbank importiert. Hier könnte man die Logs
wieder vorverarbeiten und danach in die
Datenbank einspeisen. Das Sammeln und
Importieren würde durch einen Windows
Service verwirklicht, so könnte man diesen
einfach abschalten und die Logs wären notfalls für die Entwickler auf den Servern als
File auffindbar. Als einziger Nachteil ist die
Geschwindigkeit zu sehen. Sowohl das
Sammeln als auch das Importieren und Filtern dürften höchstens im Minutentakt ablaufen. Im „worst case“ treffen die Logs mit
dreiminütiger Verzögerung auf dem produktiven System ein.
Abbildung 1: Mögliche Importwege.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
5/24
Projektname
Dokumenttitel
Artifaktname
2.2
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
Filtermöglichkeiten
Abbildung 2: Filtermöglichkeiten.
Die anzubietenden Filtermöglichkeiten wurden vom Kernteam in einem Brainstorming gesucht und dann auf den
nun vorhandenen Level verfeinert. Im Mindmap sieht man das Ergebnis des Brainstormings, jedoch noch ohne
die Granularität und „Verknüpfungsmöglichkeiten“ aufzuzeigen.
Es wurde später noch bestimmt, dass die Filterung nach Time / Date nur unzureichende Ergebnisse geliefert hat,
wenn dies nicht fortwährend gefiltert wurde. Die Idee dahinter ist, dass ein Entwickler z.B. nur die LogEvents der
letzten zwei Tage interessieren. Hier ist es dann wichtig, dass das automatische Filtern auf der Datenbank auch
genau diese Funktionalität unterstützt.
Es wurde auch entschieden, dass das Filtern über mehrere Applikationen und die Suche nach Teilen des Applikationsnamens möglich sein soll.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
6/24
Projektname
Dokumenttitel
Artifaktname
3
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
Systemdesign Global
3.1
Ablauf
Gemeinsam mit den Verantwortlichen wurde die Variante drei „LogFiles“ gewählt. Als grosser Vorteil wurde
genannt, dass das Logging Datenbank-unabhängig ist. So ist es möglich, in einem Störungsfall den Import der
Logs abzuschalten und so die unter Last stehende Datenbank nicht weiter zu belasten.
Daher wird die Log-Applikation in zwei Teilen entwickelt. Der erste Teil, der „Importer“, wird ein Windows Service sein, der die Log-Files sammelt und importiert. Der zweite Teil, der „Viewer“, wird eine Webapplikation sein,
welche die Logs anzeigen, filtern und auswerten lässt.
Auch bei der weiteren Entwicklung von Funktionalitäten wird darauf geachtet, dass alle Schritte atomar ausgeführt werden können. So wird z.B. das automatische Nachfiltern nach dem Importieren „asynchron“ durch einen
Datenbank-Job realisiert. Hier gilt das Gleiche wie für alle Jobs: es wird darauf geachtet, dass jeder Job atomar
laufen kann.
3.2
Datenbank-Modell
tab_Filtering_MachineFilter
tab_Filtering_KeywordFilter
PK
FilterMachineID
PK
FilterKeywordID
FK1
FilterID
Name
FK1
FilterID
Value
Exclude
tab_Filtering_Filter
PK
Name
Von
Bis
Userid
Environment
Plattform
Path
Consistent
InsertUser
InsertDate
UpdateUser
UpdateDate
VonDelta
bisDelta
tabStatusTyp
PK
FilterID
StatusTypID
Name
InsertUser
InsertDate
UpdateUser
UpdateDate
tab_Filtering_AppIDFilter
PK
FilterAppID
FK1
FilterID
Value
tab_Filtering_LoglevelFilter
PK
FilterLoglevel
FK1
FilterID
Value
tabStatus
PK
Statusid
FK2
FK1
FK3
LogEventID
FilterID
StatusTypId
Comment
ApplID
InsertUser
InsertDate
UpdateUser
UpdateDate
tabLogEventFiltering
PK
LogGroupingID
FK2
FK1
LogEventID
FilterID
Abbildung 3: Datenbank-Modell Filtern mit Status.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
7/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
tabStatus
tabStatusTyp
PK
PK
Statusid
FK2
FK1
FK3
LogEventID
FilterID
StatusTypId
Comment
ApplID
InsertUser
InsertDate
UpdateUser
UpdateDate
StatusTypID
Name
InsertUser
InsertDate
UpdateUser
UpdateDate
tabLogEventFiltering
tabPlattform
PK
PK
FK2
FK1
LogEventID
FilterID
FK8
FK4
FK9
FK1
tabFilePath
FilePathID
Value
FK7
FK10
FK6
FK3
FK2
FK5
tabMachine
MachineID
Value
tabExceptionText
LogEventID
Value
PK
LogGroupingID
tabLogEvent
PlattformID
PK
PK
PK
TimeInMs
RecordNbr
MachineID
EnvironmentID
PlattformID
ApplID
Prozess
Thread
LogLevelID
UserID
FilePathID
BrowserID
AppPropertiesID
ExceptionTextID
Message
TimeStamp
ImportID
tabApplName
PK
ExceptionTextID
Value
tabAppProperties
PK
AppPropertiesID
Value
tabLogLevel
PK
LogLevelID
Value
tabBrowser
PK
BrowserID
Value
ApplID
Value
tabEnvironment
PK
EnvironmentID
Value
tabUser
PK
UserID
Value
Abbildung 4: Datenbank-Modell Log Event.
Die Trennung von Filterdaten Abbildung 3 und LogEvent-Daten Abbildung 4 wurde mit der Absicht verfolgt,
dass man Filter definieren kann, egal ob sich die Daten in den LogEvents befinden. Nehmen wir an, dass neue
Server angeschafft würden, so wären alle Filter noch vorhanden und man könnte einfach die neuen Server einfügen. Wenn die alten Server irgendwann aus den Logs verschwinden, kann der Filter weiterbenutzt werden. Mit
dem Nachteil, dass man keine Prüfung der Filtereingaben hat. Wenn ein Maschinenname eingegeben wird, den
es nicht gibt, wird das vom Filter also richtig angenommen.
Die Verbindung zwischen Filter- und LogEvent-Daten stellt die Tabelle tabLogEventFiltering her, die auf
beiden Abbildungen zu sehen ist.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
8/24
Projektname
Dokumenttitel
Artifaktname
4
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
Systemdesign Logs importieren
Das Importieren der Logs wird durch ein als Service ausgeführtes Programm (Exe) verwirklicht. Dieser Service
übernimmt dabei zwei Aufgaben, das Sammeln der auf den Servern verteilten LogFiles und danach das Importieren derer.
Aufgrund der Tatsache, dass die Server pro Applikation minütlich ein Logfile schreiben, sind diese zahlreich aber
klein. Daher wurde entschieden, dass nicht importierbare Files einfach übersprungen werden. Nach dem Import
werden die Daten auf die Tabellen verteilt. Dies wird von einem Datenbank-Job vorgenommen.
4.1
LogImporter
Der LogImporter ist eigentlich ein Verwalter von Tasks.Die beiden Haupttasks sind das Sammeln der Logfiles von
den Servern (FileTransferTask) und das Importieren in die Datenbank (FileImportTask).
4.1.1 Installation & Starten
Die Installation muss über die Visual Studio Konsole und das installutil gemacht werden. Der passende Befehl ist:
installutil -i LogImporterService.exe
Listing 1: Installieren des Windows Service.
Bei der Deinstallation wird das „i“ im Befehl durch ein „u“ ersetzt.
installutil -u LogImporterServ
Listing 2: Deinstallieren des Windows Serviceice.exe.
Gestartet und gestoppt wird der Service über die Computerverwaltung unter Services. Er ist bei der Installation
auf „automatisch starten“ gestellt, so dass der Service nach einen Server-Reboot direkt gestartet wird. Bei Fehlern verhält sich der Service so, dass er bis zu zwei Fehler pro 15 Minuten toleriert und sich erst beim Dritten
beendet.
4.1.2
Config
<add key="ApplID" value="LogImporter" />
<add key="FromEmail" value="[email protected]" />
<add key="LogEmail" value="[email protected]" />
<add key="IntervallinMs" value="60000"/>
<tasks>
<task type="ImportTask.FileTransferTask, ImportTask"
targetDirectory="\\serverbds\[Share]\dev\toImport\"
unProcessableDirectory="\\serverbds\[Share]\dev\error\"
importUser="IUSR_Anonym_Corp_LogObi" >
<workdata name="transferDev" type="ImportTask.FileTransferWorkData, ImportTask"
sourceDirectory="\\serverdev\[Share]\PwwLog"
uniqueSourceName="DEV01" />
</task>
<task type="ImportTask.FileImportTask, ImportTask"
importTable="tabImport"
importDatabase="Corp_LogObi"
importUser="IUSR_Anonym_Corp_LogObi"
importPassword="[Passwort]"
importDatabasServer="serverdbdev04"
bcpUtilityPath="C:\\Program Files\\Microsoft SQL Server\\100\\Tools\\Binn\\bcp.exe"
batchSize="10" >
<workdata name="importDev" type="ImportTask.FileImportWorkData, ImportTask"
sourceDirectory="\\serverbds\[Share]\dev\toImport\"
successDirectory="\\serverbds\[Share]\dev\imported\"
errorDirectory="\\serverbds\[Share]\error\"/>
</task>
</tasks>
Listing 3: Task Definieren.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
9/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
Wird die Konfiguration – z.B. zum Aktualisieren der Intervall-Zeiten – verändert, muss der Service neu gestartet
werden.
4.2
FileTransferTask
Dieser Task überwacht die gegebenen Verzeichnisse der Server und reagiert, sobald sich Files in den Verzeichnissen befinden und kopiert diese ins Importverzeichnis. Bei dieser Aktion wird auch der Name so angepasst, dass
man sieht, von welchem Server die Logs kommen. Danach ist das Verarbeiten vom FileTransferTask abgeschlossen.
Sollte ein File durch einen anderen Prozess blockiert sein, so wird dieses File einfach ausgelassen und beim
nächsten Lauf wird versucht, das File zu kopieren.
4.3
FileImportTask
Es wird geprüft, ob Files im Importverzeichnis bereitliegen. Wenn ja, wird versucht die Files zu importieren. Falls
das File nicht zugreifbar ist, wird es ebenfalls ausgelassen und beim nächsten Lauf mitgenommen. Daher liegt
die maximale Verzögerungszeit durch den Import bei maximal zwei Minuten. Im Anschluss wird durch einen
Konsolenbefehl der Import per BCP angestossen.
tabImport
PK
lngLogEventID
dtmLogEvent
strTimeInMs
strRecordNbr
strMachine
strApplID
strEnvironment
strPlattform
intProcessID
intThreadID
strLogLevel
strUser
strAppProperties
strFile
strMessage
strBrowser
strException
strCopyKey
Abbildung 5: tabImport.
4.4
BCP
BCP ist ein Kommandozeilen Programm, welches mit dem MSSQL-Server installiert wird. Es wird dazu benutzt,
unsere LogFiles mit einem Bulkimport in die Datenbank zu importieren.
Durch die Vorgaben von IT13 (z.B.: kein Speichern von Dateien auf den Datenbankservern) ist es nötig, den Bulkimport über BCP zu machen. Das Bulkimport SQL-Kommando von MSSQL-Server funktioniert nur, wenn die
Dateien lokal sind, da es mit UNC Pfaden nicht umgehen kann.
Eine genauere Beschreibung, was BCP noch weiter bietet, findet sich in den Books-Online1 von MSSQL-Server.
Ziel ist es, dass jedes File in einem Stück importiert wird, da dies sehr grossen Einfluss auf die Performance haben
kann. Der Parameter _fileRowsCount ist daher auf die gesamte Filelänge gesetzt.
1
_http://msdn.microsoft.com/en-us/library/aa174646%28v=SQL.80%29.aspx
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
10/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
_command = _database + ".dbo." + _table + " in " + _inProgressFileName + " b " + _fileRowsCount + @" -c -t@~ -r#$#EOR#$# -U " + _dbUser + " P " + _dbPassword + " -S " + @_databaseServer;
Listing 4: BCP Command.
5
Datenbank-Jobs
5.1
Data Processing
Hier ist das Verarbeiten der aus dem Import gefüllten Flattable tabImport, zu den teilnormalisierten Tabellen
von Corp_LogObi gemeint. Als erstes wird die ID des aktuell letzten Logdatensatzes gespeichert, wodruch auch
während dem Datenbank-Job-Run weitere Daten vom Importer her kommen können. Am Ende vom Import
werden die verarbeiteten Datensätze gelöscht.
Als Vorbereitung wird die ID weggespeichert, damit nur Datensätze, die nicht gerade am Importieren sind, verarbeitet werden.
Declare @id int;
set @id = (Select MAX(lngLogEventID) from tabImport);
Listing 5: Maximal zu verarbeitende ID.
Erster Schritt ist das Einfügen der noch nicht vorhandenen Werte in die Filtertabellen. Die Tabellen ApplikationsName (tabApplName) und Applikationseigenschaften (tabApplProperties) dienen hier als Beispiele.
exec dbo.usp_InsertNewValues 'dbo.tabImport','dbo.tabApplName','strApplID','value'
exec dbo.usp_InsertNewValues
'dbo.tabImport','dbo.tabAppProperties','strAppProperties','value'
Listing 6: Aufruf Insert new Values.
Danach wird die eigentliche LogTabelle gefüllt.
insert into tabLogEvent
Select distinct
case when strTimeInMs like '%(null)%'
then 0
else replace(strTimeInMs,'''', '')
end,
case when strRecordNbr like '%(null)%'
then 0
else replace(strRecordNbr,'''', '')
end,
m.MachineID,
e.EnvironmentID,
p.PlattformID,
a.ApplID,
intProcessID,
intThreadID,
l.LogLevelID,
u.UserID,
F.FilePathID,
b.BrowserID,
ap.AppPropertiesID,
et.ExceptionTextID,
strMessage,
dtmLogEvent,
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
11/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
null
tabImport with (nolock) left outer join
tabMachine as m with (nolock) on m.Value = strMachine left outer join
tabEnvironment as e with (nolock)on e.Value = strEnvironment left outer join
tabPlattform as p with (nolock) on p.Value = strPlattform left outer join
tabApplName as a with (nolock) on a.Value = strApplID left outer join
tabLogLevel as l with (nolock) on l.Value = strLogLevel left outer join
tabUser as u with (nolock) on u.Value = strUser left outer join
tabFilePath as F with (nolock) on F.Value = strFile left outer join
tabBrowser as b with (nolock) on b.Value = strBrowser left outer join
tabAppProperties as ap with (nolock)
on ap.Value = strAppProperties left outer join
tabExceptionText as et with (nolock) on et.Value = strException
where lngLogEventID <= @maxid and lngLogEventID >= @minid
from
Listing 7: Laden vom Import zu der LogTabelle.
5.1.1 Insert New Values
'insert into '+@TargetTableName+' ('+@TargetField+') (
select distinct '+@SourceField +'
from '+@SourceTableName+'
where not exists (
select '+@TargetField +'
from '+@TargetTableName+'
where '+@TargetField +' = '+@SourceField +'
)
)'
Listing 8: Statement von Insert new Values.
5.2
Erstellen der Statistik
Hier ist die erste Vorbereitung für die Management Ansicht von LogObi gemacht. Die Daten müssen für diese
Anfragen weniger granular sein, als LogObi die Daten speichert. Dafür wären Auswertungen über die drei Monatsgrenzen wünschenswert. So könnten die Logs über einen grossen Zeitraum ausgewertet werden. Dies wird
kurze, z.B: Feiertagbedingte Schwankungen ausgleichen. Hierfür wird ein stundenweises Zusammenrechnen der
LogEvents gemacht und in die tabStatistic (siehe Abbildung 6) gespeichert. Diese werden nur mit den für
das Management interessanten Daten gespeichert.
tabStatistic
PK
StatisticID
Anzahl
Hour
Datum
ApplID
Browser
Environment
Abbildung 6: tabStatistic.
5.3
Aufräumen der Daten
Es werden alle LogEvents gelöscht die älter als 90 Tage sind. Die Statistik wird anfangs unbeschränkt behalten
und je nach Nutzung des Managements werden die Daten gelöscht, wenn sie nicht mehr gebraucht werden;
zum Beispiel nach 1.5 Jahren. So wären auch Auswertungen mit einem Jahresrückblick möglich.
PROCEDURE [dbo].[usp_DeleteOldLogs]
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
12/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
@daysToKeep int,
@DeleteBatchSize int
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
CREATE TABLE #t(ID INT PRIMARY KEY);
-- Zu löschende LogEvents bestimmen
insert into #t
select top(@deleteBatchSize) LogEventID
from tabLogEvent with (nolock)
where [TimeStamp] < DATEADD(d, -@daysToKeep, getdate())
order by [TimeStamp]
-- Filtering auflösen
delete from tabLogEventFiltering where LogEventID in(
select id from #t
)
-- Status löschen
delete from tabStatus where LogEventID in(
select id from #t
)
-- LogEvents löschen
delete from tabLogEvent where
select id from #t
)
LogEventID in(
-- Temporäre Tabelle leeren
drop table #t;
END
Listing 9: Veraltete Logs löschen.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
13/24
Projektname
Dokumenttitel
Artifaktname
6
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
View Applikation
6.1
Anzeigen der LogEvents
Auf der Einstiegsseite werden jedem Benutzer seine LogEvents der letzten zwei Tage angezeigt. Dies entspricht
der „Standardsuche“ aus dem alten Tool. Hier wird die Filtermaske (siehe Abbildung 7) beschrieben. Diese besteht aus einer Filterliste der TopFilter, die Error gruppiert nach Anwendung und die ersten 25 LogEvents auf der
ersten Seite des Datagrids.
Abbildung 7: Anzeigen der LogEvents.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
14/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
6.2
Filtern
Ein zentraler Bestandteil von LogObi ist das Filtern. Diese sind neu speicherbar und wiederverwendbar. Falls es
gewünscht ist, kann man diesen so einrichten, dass die neuen LogEvents beim Import gefiltert werden. So wird
zur Zeit der Anzeige keine Last erzeugt.
Abbildung 8: Filtern.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
15/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
6.3
Status Anhand von Filtern setzen
Hier wird der Filter nur zur Info angezeigt. Falls man nun auf den Filter einen Status setzt, so ist der nachher in
allen Logs, die dem Filter entsprechen, sichtbar. So ist es gegeben, dass wenn mehrere Entwickler an einer Applikation entwickeln, jeder sehen kann, ob einer der Kollegen bereits an dem/den LogEvents dran ist.
Abbildung 9: Status auf Filter.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
16/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
6.4
LogEvent Status
Hier wird dasselbe Prinzip wie oben angewendet. Es wird einfach statt auf einen Filter auf einen LogEvent angewendet.
Es ist möglich einen LogEvent als Library LogEvent zu markieren. Die Library Entwickler können über eine einfache Auswertung die passenden ErrorLogs finden. Es ist weiter möglich, den LogEvents weitere Status mit Bemerkung zu setzen.
Abbildung 10: Status auf LogEvent.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
17/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
6.5
Alarming
Im LogObi können Alarme verwaltet werden. Das eigentliche Überwachen der Alarme erfolgt über die separate
Alarming-Applikation. Die Daten werden im LogObi zwischengespeichert und mit der AlarmingID aus der Alarming-Applikation angereichert.
Abbildung 11: Alarming.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
18/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
6.6
Alarming History
Die Alarming-Historie wird über einen Button im GridView auf der „Alarming“-Seite aufgerufen. Hier werden die
letzten 25 Alarming-Events angezeigt. Die Menge ist über das web.config konfigurierbar. Diese werden live über
den Webservice von der Alarming-Applikation abgerufen. So ist die Seite zwar etwas langsamer, aber die Daten
sind dafür immer aktuell.
<xsd:element name="GetAlarmEvents">
<xsd:complexType>
<xsd:sequence>
<xsd:element minOccurs="0" name="plngAlarmId" type="xsd:int" />
<xsd:element minOccurs="0" name="plngNumEvents" type="xsd:int" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Listing 10: Alarming History Webservice.
Abbildung 12: Alarming History.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
19/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
6.7
Auswertungen
Die Auswertungen sind eine Management Funktion. Der „frühere“ LogEventViewer hatte keine Funktionen die
für das Management interessant waren. Hier ist es mit einfachen Kriterien möglich, eine Auswertung zu erstellen, z.B. Anzahl Fehler pro Applikation. Die Granularität ist in Absprache mit dem Management auf eine Stunde
festgelegt. Dies ist wichtig für das Zusammenfassen der Daten, da nur das Nötigste gespeichert werden soll.
Abbildung 13: Auswertungen.
6.8
Applikationen je LogEvent
Diese Funktion ist eine Ergänzung zu den Library-Fehlern. Falls man ein anormales Verhalten der Umgebung
vermutet, kann man die Fehler applikationsübergreifend suchen lassen und so herausfinden, ob der Fehler in
weiteren Applikationen auftritt.
Abbildung 14: Applikationen je LogEvent.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
20/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
6.9
Anbieten der Komponenten aus PadMan
Es ist im Filter auch möglich, die Komponenten anhand der Beziehungen zwischen den Komponenten auszuwählen. Hier werden die von PadMan importierten Komponenten mit folgenden rekursiven SQL Statement abgefragt.
Unten die ausgefüllte Beispielanfrage für alle Komponenten, die an PadMan hängen und mit „Has“ verknüpft
sind.
WITH ComponentRe AS (
SELECT ToComponentID
FROM
tabComponentRelation
WHERE FromComponentID = 'Corp_Padman' and RelationTyp =1
UNION ALL
SELECT e.ToComponentID
FROM
tabComponentRelation e INNER JOIN
ComponentRe base
ON base.ToComponentID = e.FromComponentID and e.RelationTyp = 1
)
SELECT *
FROM ComponentRe
Listing 11: PadMan Komponenten - Rekursive Abfrage.
7
Schnittstellen
7.1
Logfiles
Die Logfiles stellen die Schnittstelle zwischen log4net und Corp_LogObi dar. Die Logfiles mussten soweit angepasst werden, dass das Trennzeichen nicht mehr mit dem Pipe-Symbol („|“), aus der Konsole, entspricht. Dies
war nötig, da der BCP Import über eine Kommandozeile angestossen wird und der Befehl mit dem Zeichen |
ungültig wird. Speziell sind hier die Trennzeichen @~ für Feldtrennung und #$#EOR#$# für das Ende der Zeile,
da in den Log-Nachrichten Zeilenumbrüche enthalten sein können.
Hier eine Beispielzeile aus einem neuen Logfile:
@~2011-08-29 13:27:58.123@~
256@~
0@~w07949@~Corp_DMS@~Local@~Intranet@~ 8088@~
8@~DEBUG @~unknown
@~@~/appl/corp/dms/WPL/statistic.aspx@~Application Corp_DMS on Host: W07949 entering
LogController::StartLogging, Hello...@~Type=IE9, Browser=IE, Version=9.0, Beta=False,
MajorVersion=9, MinorVersion=0, Crawler=False, Platform=WinNT, ClrVersion=0.0, MSDomVersion=9.0, W3CDomVersion=1.0, ActiveXControls=True, Cookies=True, EcmaScriptVersion=1.2, Frames=True, JavaScript=1.2, VBScript=True@~@~#$#EOR#$#
Listing 12: LogFile Auszug - ein Log.
7.2
Daten aus Corp_PadMan
LogObi benötigt Informationen bezüglich Komponenten von Corp_PadMan. Diese werden von Corp_PadMan
mit dem WCF-Service ComponentService zur Verfügung gestellt.
Der Webservice wird von LogObi täglich in der Nacht aufgerufen, damit die Komponenten aktualisiert werden
können. Vom Webservice werden sämtliche Komponenten, die verantwortlichen Personen sowie die Relationen
zwischen den Komponenten erhalten. Diese werden in die in Abbildung 15 dargestellte Datenbank-Struktur
eingefügt.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
21/24
Projektname
Dokumenttitel
Artifaktname
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
tabComponentPersonMapping
tabPersonType
PK
Informationstechnologie
TypeId
PK
MappingId
Name
InsertDate
InsertUser
UpdateDate
UpdateUser
FK1
FK2
FK3
ComponentId
PersonId
TypeId
InsertDate
tabPerson
PK
PersonId
UserId
InsertDate
tabComponentRelation
tabComponent
PK
PK
lngRelationID
FK1
FK2
FromComponentID
ToComponentID
RelationTyp
ComponentId
InsertDate
Abbildung 15: Daten aus Corp_PadMan.
7.3
Alarming
Das Alarming wird über einen Webservice, der von der Alarming-Applikation angeboten wird, verwirklicht. Es
werden die Daten der Alarme auch in der LogObi Datenbank gespeichert. Erst beim Aktualisieren werden die
Daten über den Webservice ans Alarming weitergegeben.
Eine zweite Funktion des Webservices erlaubt das Abfragen der letzten X Alarming-Events abzurufen. So kann in
LogObi eine Ansicht der letzten Alarmauslösungen angeboten werden.
Alle Parameter an den Alarming Service sind fakultativ, daher könnte bei einem Updaten nur das übergeben
werden was, geändert werden soll.
<xsd:complexType name="AlarmParameters">
<xsd:sequence>
<xsd:element minOccurs="0" name="Action" nillable="true" type="xsd:string" />
<xsd:element minOccurs="0" name="ActiveFlag" nillable="true" type="xsd:boolean" />
<xsd:element minOccurs="0" name="AlarmId" nillable="true" type="xsd:int" />
<xsd:element minOccurs="0" name="AlarmName" nillable="true" type="xsd:string" />
<xsd:element minOccurs="0" name="AlarmType" nillable="true" type="xsd:int" />
<xsd:element minOccurs="0" name="ApplId" nillable="true" type="xsd:string" />
<xsd:element minOccurs="0" name="CheckFrequency" nillable="true" type="xsd:int" />
<xsd:element minOccurs="0" name="ConnectionKey" nillable="true" type="xsd:string" />
<xsd:element minOccurs="0" name="DeleteFlag" nillable="true" type="xsd:boolean" />
<xsd:element minOccurs="0" name="Description" nillable="true" type="xsd:string" />
<xsd:element minOccurs="0" name="EmailAddress" nillable="true" type="xsd:string" />
<xsd:element minOccurs="0" name="Environment" nillable="true" type="xsd:int" />
<xsd:element minOccurs="0" name="IgnoreFeiertag" nillable="true" type="xsd:boolean" />
<xsd:element minOccurs="0" name="Lang" nillable="true" type="xsd:string" />
<xsd:element minOccurs="0" name="Mandant" nillable="true" type="xsd:string" />
<xsd:element minOccurs="0" name="MobileNumber" nillable="true" type="xsd:string" />
<xsd:element minOccurs="0" name="MoreLess" nillable="true" type="xsd:boolean" />
<xsd:element minOccurs="0" name="NumEvents" nillable="true" type="xsd:int" />
<xsd:element minOccurs="0" name="RunningExclusion" nillable="true" type="xsd:string" />
<xsd:element minOccurs="0" name="SqlStatement" nillable="true" type="xsd:string" />
<xsd:element minOccurs="0" name="Timeout" nillable="true" type="xsd:int" />
</xsd:sequence>
</xsd:complexType>
Listing 13: Alarming Service XML.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
22/24
Projektname
Dokumenttitel
Artifaktname
8
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
Beschreibung der Elemente
Das innere Design der Applikation dreht sich um die beiden zentralen Elemente LogEvent und Filter. Es ist so,
dass die LogEvents nach dem Import analysiert und wo sinnvoll normalisiert werden. Ebenso wird dann eine
Analyse mit den Filtern über die Logs laufen gelassen, um diese den passenden Kategorien zuzuordnen.
So ist ein schnelles Anbieten der vorgefilterten LogEvents für die Benutzer möglich.
tabLogEvent
PK
tab_Filtering_Filter
LogEventID
PK
FK8
FK4
FK9
FK1
FK7
FK10
FK6
FK3
FK2
FK5
TimeInMs
RecordNbr
MachineID
EnvironmentID
PlattformID
ApplID
Prozess
Thread
LogLevelID
UserID
FilePathID
BrowserID
AppPropertiesID
ExceptionTextID
Message
TimeStamp
ImportID
tabLogEventFiltering
PK
LogGroupingID
FK2
FK1
LogEventID
FilterID
FilterID
Name
Von
Bis
Userid
Environment
Plattform
Path
Consistent
InsertUser
InsertDate
UpdateUser
UpdateDate
VonDelta
bisDelta
Abbildung 16: LogEventFiltering.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
23/24
Projektname
Dokumenttitel
Artifaktname
9
Corp_LogObi
Systemdesign Corp_LogObi
Systemdesign
Informationstechnologie
Anforderungszuordnung
Die Tabelle 1 listet die Anforderungszuordnung für Corp_LogObi auf.
Bezeichnung
L_UC_10
L_UC_20
L_UC_30
L_UC_40
L_UC_50
L_UC_60
L_UC_70
L_UC_80
L_UC_90
L_UC_100
L_UC_110
L_UC_120
L_UC_130
L_UC_140
Name
LogEvents importieren
LogEvents anzeigen
LogEvent Details anzeigen
LogEvent löschen
LogEvent Status ändern
Library Fehler markieren
Filter verwalten (CRUD)
Filter anwenden
LogEvents gruppieren
Überwachung definieren (CRUD)
User informieren / alarmieren
Applikationen je LogEvent ansehen
Auswertungen ansehen
LogEvents säubern (Clean)
Kapitelzuordnung
Kapitel 4
Kapitel 6
Kapitel 6.1
Kapitel 6.1
Kapitel 6.4
Kapitel 6.4
Kapitel 6.2
Kapitel 5.1 & 6.2
Kapitel 6.1
Kapitel 6.5
Kapitel 6.5
Kapitel 6.8
Kapitel 5.2 & 6.7
Kapitel 5.3
Tabelle 1: Kapitelzuordnung der Use Cases aus dem Anforderungsdokument [01].
10 Sicherheit
Keine weiter führenden Angaben.
SD_LOGOBI_Systemdesign_V01.07.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
24/24
Masterthesis „Renewal TeamPortal“
Projektplan
Risikokatalog
Situationsanalyse
Corp_PadMan – Systemanforderungen
Corp_PadMan – Systemdesign
Corp_LogObi – Systemanforderungen
Corp_LogObi – Systemdesign
Corp_JobMonitor – Systemanforderungen
Corp_JobMonitor – Systemdesign
Migration (in der publizierten Version nicht enthalten)
Die Schweizerische Post
Informationstechnologie
Systemanforderungen
Dokumentart
Titel
Projektname
Projektabkürzung
Projektmanager
Ausgabedatum
Autor
Übermittler
Empfänger
Klassifizierung
SY
Systemanforderungen Corp_JobMonitor
Corp_JobMonitor
JOBMON
Irminger Pascal, IT133
28.03.2012
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133; Lehmann Marcel, IT132; Zenklusen Axel, IT131; Haefeli Stefan,
IT132
Nicht klassifiziert
Änderungskontrolle
Version
Datum
Überarbeitung
Ersteller
X01.00
X01.01
X01.02
27.11.2011
16.01.2012
28.03.2012
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
V01.02
28.03.2012
Neues Dokument
Überarbeitung
Verschieben der Use Cases zu Reads
und Indexes nach Corp_PadMan
Freigabe
SY_JOBMON_Systemanforderung_V01.02.docx
Irminger Pascal, IT133
© Die Schweizerische Post
Ausgabedatum 28.03.2012
Freigabe
Haefeli Stefan, IT132
1/16
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Informationstechnologie
Inhaltsverzeichnis
1 Allgemeines .................................................................................................................................................. 3
1.1 Zweck ........................................................................................................................................................ 3
1.2 Beschreibung ............................................................................................................................................. 3
1.3 Tailoring ..................................................................................................................................................... 3
1.4 Definitionen, Akronyme und Abkürzungen ................................................................................................ 3
1.5 Referenzen ................................................................................................................................................ 4
2 Allgemeine Beschreibung .............................................................................................................................. 5
2.1 Ausgangslage ............................................................................................................................................ 5
2.2 Produktperspektive .................................................................................................................................... 5
3 Allgemeine Anforderungen ........................................................................................................................... 6
3.1 Personas .................................................................................................................................................... 6
3.2 Domainmodell ........................................................................................................................................... 6
3.2.1 Strukturdiagramm .................................................................................................................................. 6
3.2.2 Konzeptbeschreibung ............................................................................................................................. 7
3.3 Systemgrenzen .......................................................................................................................................... 8
3.4 Use Cases .................................................................................................................................................. 8
3.4.1 J_UC_10: Jobs ansehen (Liste) ................................................................................................................ 9
3.4.2 J_UC_20: Job einer Komponente zuordnen .......................................................................................... 10
3.4.3 J_UC_30: Job-Details editieren .............................................................................................................. 11
3.4.4 J_UC_40: Job-Runs ansehen (Liste) ....................................................................................................... 12
3.4.5 J_UC_50: Job-Run-Details ansehen ....................................................................................................... 13
3.4.6 J_UC_60: Fehlerhafter Job-Run als erledigt markieren ........................................................................... 14
3.5 Nicht-funktionale Anforderungen ............................................................................................................ 15
3.5.1 Technische Anforderung ....................................................................................................................... 15
3.5.2 Ergonomische Anforderung .................................................................................................................. 15
3.5.3 Verfügbarkeit ........................................................................................................................................ 15
3.5.4 Benutzerfreundlichkeit .......................................................................................................................... 15
3.5.5 Datenverlust ......................................................................................................................................... 15
3.5.6 Auftreten von Fehlfunktionen ............................................................................................................... 15
3.5.7 Sicherheit ............................................................................................................................................. 15
3.5.7.1 Authentifizierung ............................................................................................................................... 15
3.5.7.2 Kommunikation ................................................................................................................................. 15
3.5.7.3 SQL-Injektion ..................................................................................................................................... 15
3.5.7.4 X-Site Scripting .................................................................................................................................. 15
3.5.7.5 Scripts................................................................................................................................................ 15
4 Anforderungen an die Entwicklungs- und Wartungsumgebung .................................................................. 16
5 Anforderungen an die externen Schnittstellen ............................................................................................ 16
6 Detailanforderungen ................................................................................................................................... 16
7 Sicherheitsanforderungen ........................................................................................................................... 16
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
2/16
Projektname
Dokumenttitel
Artifaktname
1
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Informationstechnologie
Allgemeines
1.1
Zweck
Die Systemanforderungen beschreiben und strukturieren die Anforderungen an das zukünftige System. Sie werden vom Auftraggeber und Auftragnehmer beidseitig als Grundlage für die Realisierung und Abnahme des zukünftigen Systems akzeptiert.
1.2
Beschreibung
Die Systemanforderungen beziehen sich je nach Phase auf die Ebene System, Subsystem oder Konfigurationseinheit (KE). Eine verfeinerte Gliederung muss vom entsprechenden Vorgehensmodell hinzugefügt werden. Die
Darstellung der Systemanforderungen kann sowohl in strukturiertem Text als auch in Form von Modellen erfolgen.
1.3
Tailoring
Die Systemanforderungen können auch in mehreren eigenständigen Dokumenten vorliegen, zum Beispiel pro
Subsystem oder Konfigurationseinheit.
1.4
Definitionen, Akronyme und Abkürzungen
Wort
Definition
Corp_SysLog
Intranet-Webapplikation. Zeigt letzte Datenbank-Job-Executions sowie deren Resultate an.
Enthält weiter – nur via URL zugänglich (d.h., keine Navigation) – Informationen zu möglicherweise fehlenden Indexes in den Datenbanken sowie zu von den SQL Servern einer
erhobenen Read-Statistik.
Intranet-Webapplikation. Stellt innerhalb von IT13 eine zentrale Stelle für das Entwickeln
von Intranet-Applikationen dar. Es stellt Konfigurationen wie zum Beispiel Datenbankzugriff, beteiligte Personen, Publikation etc. für unsere Intranet-Umgebung zur Verfügung.
Datenbank-Administrator
Das Hypertext Transfer Protocol ist ein Protokoll zur Übertragung von Daten über ein
Netzwerk. Es wird hauptsächlich eingesetzt, um Webseiten aus dem Internet/Intranet in
einen Webbrowser zu laden.
Das HyperText Transfer Protocol Secure ist die sichere Variante von HTTP. Syntaktisch ist
HTTPS identisch mit dem Schema für HTTP, die zusätzliche Verschlüsselung der Daten geschieht mittels SSL/TLS.
Internet Information Services. Webserver-Komponente in Microsoft Windows. Über IIS
können ASP- oder .NET-Applikationen (ASP.NET) ausgeführt werden
.NET-Entwicklungsabteilung von IT Post
Informationstechnologie Post
Skriptsprache, die hauptsächlich für das DOM-Scripting in Web-Browsern eingesetzt wird.
Bestehende – in die Applikation Corp_TeamPortal eingegliederte – Webpage zur Darstellung der letzten Datenbank-Job-Executions.
Das Lightweight Directory Access Protocol (LDAP) erlaubt die Abfrage und die Modifikation
von Informationen eines Verzeichnisdienstes über ein IP-Netzwerk.
Für .NET portiertes O/R-Mapping Framework (Hibernate).
Technik der Softwareentwicklung, mit der ein in einer objektorientierten Programmiersprache geschriebenes Anwendungsprogramm seine Objekte in einer relationalen Datenbank
ablegen kann.
Post Wide Web. Das Intranet der Schweizerischen Post.
Structured Query Language
Auch Microsoft SQL Server. SQL Server Produkt von Microsoft. Derzeit in den Versionen
SQL Server 2005 und SQL Server 2008 R2 bei der Schweizerischen Post im Einsatz.
Secure Sockets Layer, Transport Layer Security
Siehe Corp_SysLog
Siehe Corp_TeamPortal
Use Case
Corp_TeamPortal
DBA
HTTP
HTTPS
IIS
IT13
IT Post
Javascript
Jobübersicht
LDAP
NHibernate
O/R-Mapping
PWW
SQL
SQL Server
SSL/TLS
SysLog
TeamPortal
UC
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
3/16
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Informationstechnologie
Wort
Definition
X-Site-Scripting
Cross-Site-Scripting (XSS) bezeichnet das Ausnutzen einer Sicherheitslücke in Webanwendungen, indem Informationen aus einem Kontext, in dem sie nicht vertrauenswürdig sind,
in einen anderen Kontext eingefügt werden, in dem sie als vertrauenswürdig eingestuft
werden. Aus diesem vertrauenswürdigen Kontext kann dann ein Angriff gestartet werden.
1.5
Referenzen
Nr.
Titel
[01]
Systemanforderungen Corp_PadMan
SY_PADMAN_Systemanforderung_V01.03.docx
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
4/16
Projektname
Dokumenttitel
Artifaktname
2
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Informationstechnologie
Allgemeine Beschreibung
2.1
Ausgangslage
Die Applikation Corp_TeamPortal stellt für IT13 eine zentrale Stelle für das Entwickeln von IntranetApplikationen dar (siehe [01]). Darin enthalten ist die sogenannte „Jobübersicht“, eine Auflistung sämtlicher
Datenbank-Jobs im Umfeld des .NET-Intranets. Die „Jobübersicht“ enthält für DBAs wichtige Informationen zu
den einzelnen Datenbank-Jobs wie beispielsweise Verantwortliche und Entwickler der Jobs, Beschreibung der
Jobs, Abhängigkeiten sowie, was im Fehlerfall zu tun ist.
Daneben gibt es eine eigenständige Intranet-Webapplikation Corp_SysLog, das sogenannte „Job-Journal“. Sie
zeigt letzte Datenbank-Job-Executions an und visualisiert deren SSIS Package Logs. Sie enthält weiter – nur via
URL zugänglich (d.h., keine Navigation) – Informationen zu möglicherweise fehlenden Indexes in den Datenbanken sowie zu von den SQL Servern einer erhobenen Read-Statistik.
Die bestehende Problematik liegt nun darin, dass beide Tools prinzipiell gut und von den DBAs auch regelmässig
verwendet werden. Doch wünschen sich die DBAs ein alleinstehendes Tool, welches die Informationen der beiden bestehenden Tools verbinden kann.
Weiter zeigen die beiden Tools seit der Server-Migration von 2011, wo die Intranet-Applikationen von weitgehend einem einzigen SQL Server auf vier SQL Server Instanzen verteilt wurden, nicht mehr alle Daten an. Gerade
das „Job-Journal“ zeigt nur noch Informationen zu anderen Intranet-Applikationen an, welche sich auf der selben SQL Server Instanz befinden.
2.2
Produktperspektive
Es soll eine neue zentrale Intranet-Applikation entstehen, welche die aktuellen Bedürfnisse der DBAs abdeckt,
um die Schwachstellen der Prozesse, wie sie heute umgesetzt werden, zu beheben. Corp_JobMonitor soll konkret den folgenden Bedürfnissen gerecht werden:
Corp_JobMonitor als Managementinstrument (für Team-, Abteilungs-, Projektleitung)
Corp_JobMonitor als Wartungsinstrument (für DBAs)
Corp_JobMonitor als Entwicklungsinstrument (für DBAs und weitere Entwickler von Datenbank-Jobs)
Der neue JobMonitor soll aufgetretene Fehler in produktiven Datenbank-Jobs nicht mehr länger nur anzeigen
können (Pull), sondern aktiv die verantwortlichen Entwickler darüber informieren (Push). Durch ein geeignetes
Regelwerk sollen die Entwickler in der Lage sein, die Benachrichtigungen, welche sie erhalten, zu steuern und
gegebenenfalls einzuschränken.
DB-Job
SQL Server
Agent Log
Job Run Log
SSIS Package
Log
JobMonitor
Abbildung 1: Ablauf Datenaufbereitung (Grobskizze).
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
5/16
Projektname
Dokumenttitel
Artifaktname
3
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Informationstechnologie
Allgemeine Anforderungen
3.1
Personas
Hier seien noch einmal die drei Personas aus [01] erwähnt: Peter Ledermann (44), Manuel Imhof (28) und Sabrina Schmid (32).
Peter Ledermann (44): Hat gute Computerkenntnisse und arbeitet häufig mit Office
(Word, Excel) sowie mit SAP. Er arbeitet als Manager und muss so die Kosten der Applikationen sowie deren Offerten überwachen. Er ist verantwortliche für die Ressourcenplanung der Entwickler und versucht so mit den Kunden eine Terminplanung der Anwendungen zu definieren. Falls die Kosten einer Anwendungsentwicklung den Betrag der
Offerte überschreiten, versucht er, mögliche Lösungen mit dem Kunde zu finden. Bei
Kundenanfragen für eine neue Anwendung bzw. neue Funktionen zu einer bestehenden
Applikation konsolidiert er die bereits vorhanden Implementierungen und zeigt dem Kunde mögliche Lösungen wie zum Beispiel mandantenfähige Applikationen.
Manuel Imhof (28): Hat fortgeschrittene Computerkenntnisse und arbeitet als SoftwareEntwickler im Webumfeld. Er nutzt das Internet als Informations- und Unterhaltungsinstrument. Als Entwickler einer Anwendung ist er meistens zugleich Projektleiter. Für das
Verwalten von Anwendungen für Support sowie Wartung ist er selber verantwortlich. Für
das Entwickeln einer Anwendung verwendet er Visual Studio und er verwaltet seinen
Source Code mit Subversion. Als Unterstützung zur Entwicklung der Anwendung steht
ihm eine Library, welche speziell für diese Abteilung entwickelt wurde, zur Verfügung.
Häufig entwickelt er Anwendungen im Kostenbereich 10‘000 bis 100‘000 Franken. Bei
diesen Anwendungen ist er für alle notwendigen Schritte von Offerte bis zur Publikation
der Anwendung selber verantwortlich. Er übernimmt auch die Schnittstelle zum Kunde.
Bei grösseren Anwendung arbeitet er in einem Team von Entwickler und ihm werden
diverse Rollen übergeben. Es kann aber auch sein, dass er die Funktion Projektleiter übernimmt, jedoch keinen einzigen Code entwickeln wird.
Sabrina Schmid (32): Hat gute Computerkenntnisse und das Arbeiten mit Webapplikationen fällt ihr leicht. Als 2nd-Level-Supporterin nutzt sie das Telefon und E-Mail sehr häufig.
Sie ist die Schnittstelle zwischen den Entwicklern und den Benutzern. Kann der 1st-LevelSupport eine Anfrage nicht beantworten, so wird diese Anfrage an Sabrina weitergeleitet.
Falls sie die Anfrage nicht selber beantworten kann, informiert sie den Verantwortlichen
der Anwendung, zu welcher die Anfrage gerichtet ist. Die Kommunikation zum Benutzer
übernimmt sie weiterhin. Der Verantwortliche wird ihr die Antwort entweder mündlich
oder schriftlich geben. Das Verwalten sowie Überwachen der Anfragen und deren Bearbeitungszeit übernimmt ebenfalls Sabrina. Für diese Aufgabe stehen ihr verschiedene
Stellvertreter sowie Mitarbeiter zur Verfügung, so dass während den Büroarbeitszeiten die
Anfragen so schnell wie möglich beantwortet werden können.
3.2
Domainmodell
Nachfolgend soll das geplante Domainmodell von Corp_JobMonitor mit einem Strukturdiagramm und einer
Beschreibung aller Objekte aufgezeigt werden.
3.2.1 Strukturdiagramm
Die Abbildung 2 zeigt das Strukturdiagramm von Corp_JobMonitor. Das zentrale Objekt ist der Job; dabei handelt es sich effektiv um den auf dem SQL Server Agent eingerichteten Datenbank-Job. Den Job kann es daher –
falls notwendig – einmal je Environment (Development, Integration, Production) geben; daher die Zusammenfassung in der Job-Definition. Ein Job kann mehrere Job-Steps haben, beides wird Runs resp. Executions haben,
welche alle auf definierte Weise Logs hinterlassen.
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
6/16
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
JobDefinition
-JobName
-Komponente
-Beschreibung
-Schnittstelle
-Abhaengigkeit
-Fehlermassnahme
Informationstechnologie
Job
1
*
-JobName
-Typ
-Environment
-Enabled
-MustRun
JobStep
-StepName
-PackageName
1
*
1
1
*
*
JobRun
JobStepRun
-Startzeit
-Endzeit
-Dauer
-Status
-Solved
1
*
-Startzeit
-Endzeit
-Dauer
-Status
-Solved
1
1
*
*
JobRunLog
-ForeignDatabase
-ForeignTable
-ForeignId
-Status
JobStepLog
-ForeignDatabase
-ForeignTable
-ForeignId
-Status
Abbildung 2: Strukturdiagramm von Corp_JobMonitor.
3.2.2 Konzeptbeschreibung
Job-Definition
Beschreibung
Fasst einen Job, der auf verschiedenen Environments sein kann, zusammen.
Attribute
Job-Name, Komponente, Beschreibung, Schnittstelle, Abhängigkeit, Fehlermassnahme.
Beziehung
Eine Job-Definition hat einen oder mehrere Jobs.
Job
Beschreibung
Attribute
Beziehung
Job-Step
Beschreibung
Attribute
Beziehung
Run
Beschreibung
Attribute
Beziehung
Stellt einen Datenbank-Job dar.
Job-Name, Typ, Environment, Enabled, MustRun.
Ein Job gehört zu einer Job-Definition und hat sowohl einen oder mehrere Job-Steps als
auch mehrere Runs.
Ein Datenbank-Job ist aus mindestens einem Job-Step zusammengesetzt.
Step-Name, Package-Name
Ein Job-Step gehört zu einem Job und hat mehrere Runs.
Ein Run resp. eine Execution stellt einen erfolgreichen oder fehlerhaften Durchlauf eines
Datenbank-Jobs resp. dessen Job-Steps dar.
Startzeit, Endzeit, Dauer, Status, Solved.
Ein Run gehört zu einem Job. Ein Job kann mehrere Runs haben.
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
7/16
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Log
Beschreibung
Attribute
Beziehung
Informationstechnologie
Ein Log beschreibt einen Run resp. Execution eines Job-Runs oder eines Job-Step-Runs.
Foreign-Database, Foreign-Table, Foreign-ID, Status.
Ein Log gehört zu einem Job-Run oder zu einem Job-Step-Run. Beide können jeweils
mehrere Logs haben.
3.3
Systemgrenzen
Die Abbildung 3 zeigt die Systemgrenzen von Corp_JobMonitor. Mehrere Datenbanken kommen hierbei zum
Zuge. Die Datenbank-Jobs laufen auf dem Job-Server serverBDS, die Logs befinden sich ebenfalls dort sowie auf
den Applikations-Datenbank-Servern.
Corp_PadMan
Corp_JobMonitor
pwwdbprod04
pwwdbprod03
pwwdbprod02
serverdbprod01
PWW-DB-Server
GUI
pwwdbmobile2
serverdbmobile1
Arbeitsstation
MAP-DB-Server
serverBDS
Job-DB-Server
Abbildung 3: Systemgrenzen von Corp_JobMonitor.
3.4
Use Cases
In der untenstehenden Tabelle 1 werden alle Use Cases mit deren Gewichtung dargestellt. Die Gewichtung wird
zwischen 1 und 10 definiert. Dabei gilt ein Wert von 10 zwingend zu implementieren und einen Wert von 1 als
„nice to have“. Umso höher der Wert Kritisch ist, je mehr Unklarheiten bzw. Wissen fehlt für die benötigte Funktion.
Name
Jobs ansehen (Liste)
Job einer Komponente zuordnen
Job-Details editieren
Job-Runs ansehen (Liste)
Job-Run-Details ansehen
Fehlerhafter Job-Run als erledigt markieren
Bezeichnung
J_UC_10
J_UC_20
J_UC_30
J_UC_40
J_UC_50
J_UC_60
Gewicht
10
10
10
10
10
10
Kritisch
1
3
1
1
1
1
Tabelle 1: Use Case Übersicht von Corp_JobMonitor.
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
8/16
Projektname
Dokumenttitel
Artifaktname
3.4.1
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Informationstechnologie
J_UC_10: Jobs ansehen (Liste)
Bezeichnung
J_UC_10
Name
Jobs ansehen
Scope
JobMonitor
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
Supporter
DBAs
Interessen
Verwalten und Überwachung der Datenbank-Jobs.
Vorbedingung
Komponenten müssen bekannt und daher bereits von Corp_PadMan erhalten
und abgeglichen sein.
Nachbedingung
Liste der selektierten Datenbank-Jobs wird angezeigt.
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer will Datenbank-Jobs
ansehen.
2. Benutzer filtert die anzuzeigenden
Datenbank-Job-Resultate.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
3. System zeigt Datenbank-Jobs
entsprechend dem Filter mit
wenigstens den folgenden
Informationen an.
- Job-Name
- Letzte Execution Produktion
- Letzte Execution Integration
- Letzte Execution Entwicklung
- Massnahmen im Fehlerfall
2a. Benutzer wählt einen Job-Namen aus.
2b. Benutzer wählt eine Komponente resp. eine Applikations-ID (Appl ID) aus.
2c. Benutzer definiert, ob nur Jobs, deren letzte Execution mit Fehlern und/oder
Warnungen geendet hatten, angezeigt werden sollen.
2d. Benutzer definiert, ob für 2c. nur die noch nicht gefixten Datenbank-Jobs
angezeigt werden sollen.
2e. Benutzer schränkt auf Jobs ein, die keiner Komponente zugeordnet sind.
2f. Benutzer schränkt auf Jobs ein, die als „disabled“ markiert sind.
2g. Benutzer schränkt auf Jobs ein, die als „obsolete“ markiert sind.
mittel
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
9/16
Projektname
Dokumenttitel
Artifaktname
3.4.2
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Informationstechnologie
J_UC_20: Job einer Komponente zuordnen
Bezeichnung
J_UC_20
Name
Job einer Komponente zuordnen
Scope
JobMonitor
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
Supporter
DBAs
Interessen
Der Entwickler will einen Datenbank-Job logisch mit einer Komponente verknüpfen.
Vorbedingung
Komponenten müssen bekannt und daher bereits von Corp_PadMan erhalten
und abgeglichen sein.
Nachbedingung
Datenbank-Job ist mit der Komponente verknüpft.
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer will einen Datenbank-Job
einer Komponente logisch
zuordnen.
2. Benutzer filtert die anzuzeigenden
Datenbank-Job-Resultate.
3. System zeigt Datenbank-Jobs
entsprechend dem Filter an.
4. Benutzer wählt einen DatenbankJob zur Zuordnung aus.
5. System zeigt eine Auswahl aller
Komponenten an, die es aus
Corp_PadMan erhält.
6. Benutzer wählt eine der
Komponenten aus.
7. Benutzer bestätigt seine Auswahl.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
8. System speichert die KomponentenZuordnung.
2a. Benutzer wählt einen Job-Namen aus.
2b. Benutzer wählt eine Komponente resp. eine Applikations-ID (Appl ID) aus.
2c. Benutzer definiert, ob nur Jobs, deren letzte Execution mit Fehlern und/oder
Warnungen geendet hatten, angezeigt werden sollen.
2d. Benutzer definiert, ob für 2c. nur die noch nicht gefixten Datenbank-Jobs
angezeigt werden sollen.
2e. Benutzer schränkt auf Jobs ein, die keiner Komponente zugeordnet sind.
2f. Benutzer schränkt auf Jobs ein, die als „disabled“ markiert sind.
2g. Benutzer schränkt auf Jobs ein, die als „obsolete“ markiert sind.
wenig
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
10/16
Projektname
Dokumenttitel
Artifaktname
3.4.3
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Informationstechnologie
J_UC_30: Job-Details editieren
Bezeichnung
J_UC_30
Name
Job-Details editieren
Scope
JobMonitor
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
Supporter
DBAs
Interessen
Der Entwickler will die Detailinformationen zu einem Datenbank-Job editieren.
Vorbedingung
Nachbedingung
Die getätigten Benutzereingaben müssen gespeichert sein.
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer will die
Detailinformationen zu einem
Datenbank-Job editieren.
2. Benutzer filtert die anzuzeigenden
Datenbank-Job-Resultate.
3. System zeigt Datenbank-Jobs
entsprechend dem Filter an.
4. Benutzer wählt einen DatenbankJob aus.
5. System zeigt die Detailinformationen
in einer Editiermaske an.
6. Benutzer ändert
Detailinformationen.
7. Benutzer bestätigt seine Eingaben.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
8. System speichert die
Benutzereingaben.
2a. Benutzer wählt einen Job-Namen aus.
2b. Benutzer wählt eine Komponente resp. eine Applikations-ID (Appl ID) aus.
2c. Benutzer definiert, ob nur Jobs, deren letzte Execution mit Fehlern und/oder
Warnungen geendet hatten, angezeigt werden sollen.
2d. Benutzer definiert, ob für 2c. nur die noch nicht gefixten Datenbank-Jobs
angezeigt werden sollen.
2e. Benutzer schränkt auf Jobs ein, die keiner Komponente zugeordnet sind.
2f. Benutzer schränkt auf Jobs ein, die als „disabled“ markiert sind.
2g. Benutzer schränkt auf Jobs ein, die als „obsolete“ markiert sind.
wenig
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
11/16
Projektname
Dokumenttitel
Artifaktname
3.4.4
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Informationstechnologie
J_UC_40: Job-Runs ansehen (Liste)
Bezeichnung
J_UC_40
Name
Job-Runs ansehen
Scope
JobMonitor
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
Supporter
DBAs
Interessen
Der Entwickler will die Datenbank-Job-Runs überwachen.
Vorbedingung
Nachbedingung
Liste der Datenbank-Jobs-Runs wird angezeigt.
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer will Informationen zu den
einzelnen Runs / Executions eines
einzelnen Datenbank-Jobs
ansehen.
2. Benutzer filtert die anzuzeigenden
Datenbank-Job-Resultate.
3. System zeigt Datenbank-Jobs
entsprechend dem Filter an.
4. Benutzer wählt einen DatenbankJob aus.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
5. System zeigt die Informationen zu
den einzelnen Runs / Executions
eines einzelnen Datenbank-Jobs an.
2a. Benutzer wählt einen Job-Namen aus.
2b. Benutzer wählt eine Komponente resp. eine Applikations-ID (Appl ID) aus.
2c. Benutzer definiert, ob nur Jobs, deren letzte Execution mit Fehlern und/oder
Warnungen geendet hatten, angezeigt werden sollen.
2d. Benutzer definiert, ob für 2c. nur die noch nicht gefixten Datenbank-Jobs
angezeigt werden sollen.
2e. Benutzer schränkt auf Jobs ein, die keiner Komponente zugeordnet sind.
2f. Benutzer schränkt auf Jobs ein, die als „disabled“ markiert sind.
2g. Benutzer schränkt auf Jobs ein, die als „obsolete“ markiert sind.
häufig
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
12/16
Projektname
Dokumenttitel
Artifaktname
3.4.5
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Informationstechnologie
J_UC_50: Job-Run-Details ansehen
Bezeichnung
J_UC_50
Name
Job-Run-Details ansehen
Scope
JobMonitor
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
Supporter
DBAs
Interessen
Der Entwickler will die Details eines Datenbank-Job-Runs ansehen.
Vorbedingung
Nachbedingung
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer will die DetailInformationen zu einem
Datenbank-Job-Run / -Execution
ansehen.
2. Benutzer filtert die anzuzeigenden
Datenbank-Job-Resultate.
3. System zeigt Datenbank-Jobs
entsprechend dem Filter an.
4. Benutzer wählt einen DatenbankJob aus.
5. System zeigt die Informationen zu
den einzelnen Runs / Executions des
ausgewählten Datenbank-Jobs an.
6. Benutzer wählt einen DatenbankJob-Run / -Execution aus.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
7. System zeigt die DetailInformationen zu den einzelnen Runs
/ Executions des ausgewählten
Datenbank-Jobs an.
2a. Benutzer wählt einen Job-Namen aus.
2b. Benutzer wählt eine Komponente resp. eine Applikations-ID (Appl ID) aus.
2c. Benutzer definiert, ob nur Jobs, deren letzte Execution mit Fehlern und/oder
Warnungen geendet hatten, angezeigt werden sollen.
2d. Benutzer definiert, ob für 2c. nur die noch nicht gefixten Datenbank-Jobs
angezeigt werden sollen.
2e. Benutzer schränkt auf Jobs ein, die keiner Komponente zugeordnet sind.
2f. Benutzer schränkt auf Jobs ein, die als „disabled“ markiert sind.
2g. Benutzer schränkt auf Jobs ein, die als „obsolete“ markiert sind.
mittel
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
13/16
Projektname
Dokumenttitel
Artifaktname
3.4.6
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Informationstechnologie
J_UC_60: Fehlerhafter Job-Run als erledigt markieren
Bezeichnung
J_UC_60
Name
Fehlerhafter Job-Run als erledigt markieren
Scope
JobMonitor
Level
Benutzerabsicht
Primärer Aktor
Entwickler
Stakeholder
Manager
Supporter
DBAs
Interessen
Der Entwickler will einen oder mehrere fehlerhafte Job-Runs als erledigt markieren.
Vorbedingung
Nachbedingung
Der selektierte Job-Run erhält den Status „erledigt“.
Hauptszenario
Aktor Aktionen und Absichten
Systemverantwortlichkeit
1. Benutzer will einen fehlerhaften
Datenbank-Job-Run / -Execution als
erledigt markieren.
2. Benutzer filtert die anzuzeigenden
Datenbank-Job-Resultate.
3. System zeigt Datenbank-Jobs
entsprechend dem Filter an.
4. Benutzer wählt einen DatenbankJob aus.
5. System zeigt die Informationen zu
den einzelnen Runs / Executions des
ausgewählten Datenbank-Jobs an.
6. Benutzer wählt einen DatenbankJob-Run / -Execution aus, welcher
als erledigt markiert werden soll.
Erweiterung
Spezialanforderung
Auftrittshäufigkeit
7. System speichert die
Benutzereingaben.
2a. Benutzer wählt einen Job-Namen aus.
2b. Benutzer wählt eine Komponente resp. eine Applikations-ID (Appl ID) aus.
2c. Benutzer definiert, ob nur Jobs, deren letzte Execution mit Fehlern und/oder
Warnungen geendet hatten, angezeigt werden sollen.
2d. Benutzer definiert, ob für 2c. nur die noch nicht gefixten Datenbank-Jobs
angezeigt werden sollen.
2e. Benutzer schränkt auf Jobs ein, die keiner Komponente zugeordnet sind.
2f. Benutzer schränkt auf Jobs ein, die als „disabled“ markiert sind.
2g. Benutzer schränkt auf Jobs ein, die als „obsolete“ markiert sind.
6a. Benutzer definiert, dass sämtliche Job-Runs als erledigt markiert werden sollen.
mittel
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
14/16
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Informationstechnologie
3.5
Nicht-funktionale Anforderungen
3.5.1 Technische Anforderung
Das System muss mit ASP.NET in der Sprache C# entwickelt werden und in einem .NET 4.0 Pool auf einem Windows Server 2008 laufen. Die Anwendung muss mit einem O/R-Mapper implementiert werden und mindestens
mit der Datenbank SQL Server 2008 arbeiten können.
3.5.2 Ergonomische Anforderung
Die Applikation unterstützt die Lokalisierung, es wird jedoch nur eine deutsche Benutzerführung zur Verfügung
gestellt.
3.5.3 Verfügbarkeit
Die Applikation ist während den allgemeinen Bürozeiten (Mo-Fr 07:00-19:00 Uhr) verfügbar. Bei einem Incident,
welcher von der Applikation ausgeht und das PWW betrifft, ist eine max. Behebungszeit von 4 Stunden notwendig. Ist der Betrieb von PWW jedoch nicht beeinflusst, wird die Störung nach Best Effort bearbeitet. Bei Incidents, welche von ausserhalb des Einflussbereiches von Corp_JobMonitor stammen, können keine Angaben
gemacht werden.
3.5.4 Benutzerfreundlichkeit
Obwohl die Benutzer der Software über gute bis sehr gute Computerkenntnisse verfügen werden, soll viel Wert
auf ein intuitives und übersichtliches Design gelegt werden. Um dies zu erreichen, soll eine einheitliche Benutzerführung definiert werden, wodurch es den Benutzern des System in wenigen Schritten möglich ist, eine Aufgabe
erfolgreich zu lösen. Das System wird über eine grafische Benutzeroberfläche mit übersichtlicher Menüführung 1
verfügen, die mindestens im Internet Explorer 9 dargestellt wird. Andere Browser werden, sofern diese den
Standard implementieren, soweit wie möglich unterstützt.
3.5.5 Datenverlust
Wenn während der Eingabe von Daten eine Fehlfunktion auftritt, gehen nur die noch nicht in die Datenbank
übertragenen Daten verloren. Dabei wird es sich lediglich um gerade eingegebene Daten handeln. Der Verlust
von Daten in der Datenbank wird durch ein Backup, welches in unserer Umgebung bereits im Einsatz ist, verhindert.
3.5.6 Auftreten von Fehlfunktionen
Sollte tatsächlich eine Fehlfunktion auftreten, so soll dem Benutzer dies mitgeteilt werden. Es soll jedoch nie eine
Fehlerseite des Webservers angezeigt werden.
3.5.7 Sicherheit
3.5.7.1 Authentifizierung
Die Authentifizierung wird durch die vorhandenen Mittel der Post (LDAP und Windows-Authentifizierung von IIS)
abgedeckt. Diese wird sowohl für Benutzer als auch für Fremdsysteme, welche über eine Schnittstelle zugreifen,
erforderlich sein.
3.5.7.2 Kommunikation
Die Schnittstellen für Fremdsysteme werden sowohl über HTTP als auch HTTPS verfügbar sein.
3.5.7.3 SQL-Injektion
SQL-Injektion wird durch den Einsatz des O/R-Mappers NHibernate verhindert.
3.5.7.4 X-Site Scripting
Durch das Entfernen von HTML-Tags bei Eingabemöglichkeiten von Benutzern wie auch Fremdsystemen wird das
X-Site Scripting unterbunden.
3.5.7.5 Scripts
Scripts wie Javascript werden durch die Post-Library abgedeckt.
1
Die Übersichtlichkeit wird von ausgewählten Benutzern beurteilt.
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
15/16
Projektname
Dokumenttitel
Artifaktname
4
Corp_JobMonitor
Systemanforderungen Corp_JobMonitor
Systemanforderungen
Informationstechnologie
Anforderungen an die Entwicklungs- und Wartungsumgebung
Keine weiter führenden Angaben.
5
Anforderungen an die externen Schnittstellen
Keine weiter führenden Angaben.
6
Detailanforderungen
Keine weiter führenden Angaben.
7
Sicherheitsanforderungen
Keine weiter führenden Angaben.
SY_JOBMON_Systemanforderung_V01.02.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
16/16
Masterthesis „Renewal TeamPortal“
Projektplan
Risikokatalog
Situationsanalyse
Corp_PadMan – Systemanforderungen
Corp_PadMan – Systemdesign
Corp_LogObi – Systemanforderungen
Corp_LogObi – Systemdesign
Corp_JobMonitor – Systemanforderungen
Corp_JobMonitor – Systemdesign
Migration (in der publizierten Version nicht enthalten)
Die Schweizerische Post
Informationstechnologie
Systemdesign
Dokumentart
Titel
Projektname
Projektabkürzung
Projektmanager
Ausgabedatum
Autor
Übermittler
Empfänger
Klassifizierung
SD
Systemdesign Corp_JobMonitor
Corp_JobMonitor
JOBMON
Irminger Pascal, IT133
28.03.2012
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133; Lehmann Marcel, IT132; Zenklusen Axel, IT131; Haefeli Stefan,
IT132
Nicht klassifiziert
Änderungskontrolle
Version
Datum
Überarbeitung
Ersteller
Freigabe
X01.00
X01.01
X01.02
X01.03
X01.04
V01.04
16.01.2012
25.01.2012
25.02.2012
05.03.2012
28.03.2012
28.03.2012
Neues Dokument
Schnittstellen dokumentiert
SSIS-Jobs dokumentiert
GUI-Komponenten dokumentiert
Finalisierung
Freigabe
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
Irminger Pascal, IT133
Haefeli Stefan, IT132
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
1/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Inhaltsverzeichnis
1 Allgemeines .................................................................................................................................................. 4
1.1 Zweck ........................................................................................................................................................ 4
1.2 Beschreibung ............................................................................................................................................. 4
1.3 Tailoring ..................................................................................................................................................... 4
1.4 Definitionen, Akronyme und Abkürzungen ................................................................................................ 4
1.5 Referenzen ................................................................................................................................................ 5
2 Lösungsvorschläge für die Struktur des Systemdesigns .................................................................................. 6
3 Struktur des Systemdesigns........................................................................................................................... 7
3.1 Integration in die Serverumgebung ............................................................................................................ 7
3.2 Datenbankmodell ...................................................................................................................................... 8
4 Schnittstellen ................................................................................................................................................ 9
4.1 Informationen zu Datenbank-Jobs erhalten ................................................................................................ 9
4.2 SSIS-Job Corp_JobMonitor_Job_Basic_Import .......................................................................................... 10
4.2.1 Variablen .............................................................................................................................................. 10
4.2.2 Control Flow ......................................................................................................................................... 10
4.2.3 Execute SQL Task: DELETE tabJobImport ............................................................................................... 11
4.2.4 Data Flow Task: Read Job-Data and Insert Into tabJobImport ................................................................ 11
4.2.4.1 OLE DB Source Task: Read Job-Data from JobServer ........................................................................... 12
4.2.4.2 OLE DB Destination Task: INSERT INTO tabJobImport ......................................................................... 13
4.2.5 Execute SQL Task: Save PackageName .................................................................................................. 13
4.2.6 Execute SQL Task: INSERT new INTO tabJobDefinition ........................................................................... 13
4.2.7 Execute SQL Task: INSERT new INTO tabJob .......................................................................................... 14
4.2.8 Execute SQL Task: INSERT new INTO tabJobStep ................................................................................... 14
4.2.9 Execute SQL Task: UPDATE tabJob SET Enabled, CategoryName ............................................................ 15
4.3 SSIS-Job Corp_JobMonitor_Job_Logs_Import ........................................................................................... 16
4.3.1 Variablen .............................................................................................................................................. 16
4.3.2 Control Flow ......................................................................................................................................... 17
4.3.3 Execute SQL Task: Zuletzt geladene Daten bestimmen .......................................................................... 18
4.3.4 Sequence Container: Import data from msdb ....................................................................................... 18
4.3.4.1 Execute SQL Task: TRUNCATE TABLE tabJobAgentImport ................................................................... 19
4.3.4.2 Data Flow Task: Get msdb-Data ......................................................................................................... 19
4.3.4.2.1 OLE DB Source: Read JobAgent Logs .............................................................................................. 19
4.3.4.2.2 OLE DB Source: Read Job-Ids .......................................................................................................... 21
4.3.4.2.3 Sort Transformation & Merge Join Transformation .......................................................................... 21
4.3.4.2.4 OLE DB Destination: INSERT INTO tabJobAgentLog ......................................................................... 21
4.3.4.3 Execute SQL Task: Update Status in tabJobAgentImport ..................................................................... 21
4.3.4.4 Execute SQL Task: INSERT INTO tabJobRun......................................................................................... 22
4.3.4.5 Execute SQL Task: INSERT INTO tabJobRunLog ................................................................................... 22
4.3.4.6 Execute SQL Task: INSERT INTO tabJobStepRun .................................................................................. 23
4.3.4.7 Execute SQL Task: INSERT INTO tabJopStepLog .................................................................................. 24
4.3.5 Sequence Container: Import data from Corp_SysLog (PROD) ................................................................ 24
4.3.5.1 Execute SQL Task: TRUNCATE TABLE tabSysLogImport ....................................................................... 25
4.3.5.2 Data Flow Task: Get Corp_SysLog-Data (PROD) .................................................................................. 26
4.3.5.2.1 OLE DB Source Task: Read from PROD SysLog ................................................................................. 26
4.3.5.2.2 OLE DB Destination Task: INSERT INTO tabSysLogImport ................................................................. 27
4.3.5.3 Execute SQL Task: Update Status in tabSysLogImport ......................................................................... 27
4.3.5.4 Execute SQL Task: INSERT INTO tabJobStepLog .................................................................................. 27
4.3.6 Sequence Container: Import data from Corp_SysLog (INT) .................................................................... 29
4.3.7 Sequence Container: Import data from Corp_SysLog (DEV) .................................................................. 30
4.3.8 Execute SQL Task: Update Status in tabJobStepRun .............................................................................. 30
4.3.9 Execute SQL Task: Update Status in tabJobRun ..................................................................................... 31
4.4 SSIS-Job Corp_JobMonitor_CleanUp ........................................................................................................ 31
4.4.1 Variablen .............................................................................................................................................. 32
4.4.2 Control Flow ......................................................................................................................................... 32
4.4.3 Execute SQL Task: DELETE tabJobStepLog ............................................................................................. 32
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
2/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
4.4.4 Execute SQL Task: DELETE tabJobStepRun ............................................................................................. 32
4.4.5 Execute SQL Task: DELETE tabJobRunLog .............................................................................................. 33
4.4.6 Execute SQL Task: DELETE tabJobRunLog .............................................................................................. 33
4.5 ComponentService .................................................................................................................................. 33
5 Beschreibung der Elemente ......................................................................................................................... 34
5.1 Ansicht JobList ......................................................................................................................................... 34
5.2 Ansicht EditJob ........................................................................................................................................ 35
5.3 Ansicht ViewJobHistory ............................................................................................................................ 36
5.4 Ansicht ViewJobRunDetail ....................................................................................................................... 37
5.5 Datenbank-Zugriff auf unterschiedliche Environments derselben Datenbank ............................................ 38
5.5.1 Klasse JobMonitorProvider .................................................................................................................... 39
6 Anforderungszuordnung ............................................................................................................................ 40
7 Sicherheit.................................................................................................................................................... 40
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
3/40
Projektname
Dokumenttitel
Artifaktname
1
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Allgemeines
1.1
Zweck
Das Systemdesign ist eine Verfeinerung der Systemarchitektur und beschreibt die detaillierten Spezifikationen als
Vorgabe für die Erstellung des Systems.
1.2
Beschreibung
Eine verfeinerte Gliederung muss vom entsprechenden Vorgehensmodell hinzugefügt werden. Die Darstellung
des Systemdesigns kann sowohl in strukturiertem Text als auch in Form von Modellen (z.B. Datenfluss-, Zustandübergangsmodelle, usw.) erfolgen. Das Systemdesign ist ein abschliessender Entwurf des technischen und organisatorischen Systems bis auf Stufe «Element».
1.3
Tailoring
Das Systemdesign kann auch in mehreren eigenständigen Dokumenten vorliegen, zum Beispiel pro Systemelement (entspricht der kleinsten Systemzerlegungsstufe).
1.4
Definitionen, Akronyme und Abkürzungen
Wort
Definition
Control Flow Item1
SSIS Tasks, mit denen Arbeitseinheiten definiert werden, die in einem SSIS Package Control
Flow ausgeführt werden. Ein SSIS Package besteht aus einem oder mehreren Tasks. Enthält
das Paket mehrere Tasks, werden sie im Control Flow durch sogenannte „Precedence
Constraints“ miteinander verbunden und angeordnet.
Corp_JobMonitor ist die in diesem Dokument beschriebene Intranet-Applikation für das
Monitoring von Datenbank-Jobs. Die dazugehörige Datenbank trägt denselben Namen.
Corp_PadMan ist die neue Intranet-Applikation zur Verwaltung aller Intranet-Applikationen
im PWW-Umfeld. Die dazugehörige Datenbank trägt denselben Namen.
Ein SSIS Control Flow Item. Der Data Flow Task2 kapselt die Data Flow Engine, mit dem
Daten zwischen Quellen und Zielen verschoben werden, und ermöglicht dem Benutzer das
Transformieren, Bereinigen und Ändern von Daten beim Verschieben. Durch das Hinzufügen eines Data Flow Task zu SSIS Package Control Flow kann das Package Daten extrahieren, transformieren und laden.
Siehe Development.
Server-Umgebung Entwicklung (Stufe 1). Die Beschreibung definiert sowohl Datenbank- als
auch Webserver.
Beschreibt die Server-Umgebung. Es wird unterschieden zwischen Entwicklung, Integration
und Produktion resp. Development, Integration und Production.
Ein SSIS Control Flow Item. Der Execute SQL Task3 führt SQL-Anweisungen oder gespeicherte Prozeduren einem SSIS Package Control Flow aus.
Foreign Key = Fremdschlüssel
Index (Datenbankmodell)
Siehe Integration.
Server-Umgebung Integration (Stufe 2). Die Beschreibung definiert sowohl Datenbank- als
auch Webserver.
Der Job beschreibt in diesem Dokument einen im SQL Server Agent unter Jobs gespeicherter Datenbank-Job. Der Job kann in diesem Dokument Job-Steps und Job-Runs besitzen.
Der Job-Run beschreibt in diesem Dokument die / eine Ausführung eines Datenbank-Jobs.
Es spielt dabei keine Rolle, ob der Datenbank-Job automatisch durch den SQL Server Agent
(Schedule) oder manuell durch einen Benutzer gestartet wurde. Der Job-Run kann in diesem Dokument Job-Step-Runs besitzen.
Der Job-Step beschreibt in diesem Dokument einen Prozess-Schritt innerhalb eines im SQL
Server Agent unter Jobs gespeicherter Datenbank-Jobs. Der Job-Step kann in diesem Dokument Job-Step-Runs besitzen.
Corp_JobMonitor
Corp_PadMan
Data Flow Task
DEV
Development
Environment
Execute SQL Task
FK
I
INT
Integration
Job
Job-Run
Job-Step
1
http://msdn.microsoft.com/en-us/library/ms139892.aspx
http://msdn.microsoft.com/en-us/library/ms141122.aspx
3
http://msdn.microsoft.com/en-us/library/ms141003.aspx
2
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
4/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Wort
Definition
Job-Step-Run
Der Job-Step-Run beschreibt in diesem Dokument die / eine Ausführung eines Job-Steps. Es
spielt dabei – wie auch beim Job-Run – keine Rolle, ob der Datenbank-Job automatisch
durch den SQL Server Agent (Schedule) oder manuell durch einen Benutzer gestartet wurde.
Die Merge Join Transformation4 stellt einen Output bereit, welcher durch Verknüpfen von
zwei sortierten Input Datasets mithilfe einer FULL JOIN-, LEFT JOIN- oder INNER JOINAnweisung generiert wird.
Die OLE DB Destination5 lädt Daten mithilfe einer Datenbanktabelle, einer Datenbankview
oder eines SQL-Befehls in eine OLE DB-kompatible Datenbanken. Beispielsweise können
aus der OLE DB Source Daten in Tabellen in SQL Server-Datenbanken geladen werden.
Die OLE DB Source6 extrahiert Daten mithilfe einer Datenbanktabelle, einer Datenbankview
oder eines SQL-Befehls aus einer OLE DB-kompatiblen relationalen Datenbanken. Beispielsweise kann die OLE DB Source Daten aus Tabellen in SQL Server-Datenbanken extrahieren.
Primary Key = Primärschlüssel
Siehe Production.
Server-Umgebung Produktion (Stufe 3). Die Beschreibung definiert sowohl Datenbank- als
auch Webserver.
Post Wide Web. Das Intranet der Schweizerischen Post.
Ein SSIS Control Flow Item. Der Sequence Container7 definiert einen Control Flow und
gruppieren das Package zu mehreren separaten Control Flows, die jeweils Tasks und Container enthalten, die innerhalb des übergeordneten Package Control Flow ausgeführt werden.
Die Sort Transformation8 sortiert den Input in auf- oder absteigender Reihenfolge und kopiert die sortierten Daten in den Output. Auf einen Input können mehrere Sortierungen
angewendet werden.
SQL Server Integration Services ist ein ETL-Serverprodukt (Massendaten importieren, transformieren und exportieren), das mit Microsoft SQL Server 2005 resp. 2008 mitgeliefert
wird. SSIS besteht aus einem Windows-Systemdienst, einer Verwaltungskonsole und einem
Entwicklerprodukt (SQL Server Business Intelligence Development Studio).
Die Structured Query Language ist eine Datenbanksprache zur Definition von Datenstrukturen in relationalen Datenbanken sowie zum Bearbeiten (Einfügen, Verändern, Löschen) und
Abfragen von darauf basierenden Datenbeständen.
Der Microsoft SQL Server ist ein relationales Datenbankmanagementsystem von Microsoft.
Der SQL Server Agent ist ein Microsoft Windows-Dienst, der geplante administrative Tasks
ausführt, die als Jobs bezeichnet werden. Der SQL Server Agent verwendet SQL Server, um
Job-Informationen zu speichern.
Merge Join Transformation
OLE DB Destination
OLE DB Source
PK
PROD
Production
PWW
Sequence Container
Sort Transformation
SSIS
SQL
SQL Server
SQL Server Agent
1.5
Referenzen
Nr.
Titel
[01]
Systemanforderungen Corp_JobMonitor
SY_JOBMON_Systemanforderung_X01.02.docx
Systemdesign Corp_PadMan
SD_PADMAN_Systemdesign_V01.04.docx
[02]
4
http://msdn.microsoft.com/en-us/library/ms141775.aspx
http://msdn.microsoft.com/en-us/library/ms141237.aspx
6
http://msdn.microsoft.com/en-us/library/ms141696.aspx
7
http://msdn.microsoft.com/en-us/library/ms139855.aspx
8
http://msdn.microsoft.com/en-us/library/ms140182.aspx
5
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
5/40
Projektname
Dokumenttitel
Artifaktname
2
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Lösungsvorschläge für die Struktur des Systemdesigns
Ein Punkt im Systemdesign hat massgeblich zu Diskussionen mit dem Kernteam sowie mit den DatenbankAdministratoren geführt: wie wird mit der Fülle an Logs umgegangen und wie werden sie in Corp_JobMonitor
gespeichert resp. verwendet?
Um diese Frage zu klären, muss zunächst festgehalten werden, wo sich die Logs derzeit befinden. Es werden
grundsätzlich zwei Arten von Job-Logs unterschieden:
1. SQL Server Agent Logs: Dabei handelt es sich um Logs, welche vom SQL Server Agent selber gespeichert werden. Diese haben hauptsächlich mit dem Job Schedule und dementsprechend mit der Ausführung (Start und Ende) von Job-Steps.
Die SQL Server Agent Logs befinden sich grundsätzlich in der Systemdatenbank msdb. Weiter führende
Informationen dazu finden sich in Kapitel 4.1.
2. SSIS Package Logs: Ein Datenbank-Job besteht bekanntlich aus einem oder mehreren Job-Steps. Eine
Form der Job-Steps ist das SSIS Package (SQL Server Integration Services). SSIS Packages sind DatenAblaufsteuerungen, welche mit Visual Studio implementiert werden können. Diese können selbständig
Logs erzeugen, wovon der SQL Server Agent prinzipiell nichts erfährt.
Die SSIS Package Logs befinden sich für Datenbank-Jobs – aus dem Intranet der Schweizerischen Post –
in der dafür konfigurierten Datenbank Corp_SysLog verteilt in allen Environments (Development, Integration, Production).
Aus oben stehenden Gegebenheiten sind folgende Varianten entstanden:
Variante 1
Beschreibung
Vorteile
Nachteile
Die Logs beider Arten werden vollständig in die Datenbank von Corp_JobMonitor übernommen und „lokal“ zur Anzeige gebracht.
Alle benötigten Daten liegen an einem Ort gemeinsam vor (Datenbank von
Corp_JobMonitor).
Womöglich schnellere Abfragegeschwindigkeit.
Grosser Speicherbedarf der Datenbank Corp_JobMonitor.
Duplizierung der Log-Daten.
Tabelle 1: Beschreibung der Variante 1.
Variante 2
Beschreibung
Vorteile
Nachteile
Sämtliche Logs beider Arten werden bei der Übernahme berücksichtigt. Effektiv übernommen und in Corp_JobMonitor gespeichert werden allerdings lediglich der Status sowie
eine ID und Angaben zur Datenquelle. Für die Anzeige in der Webapplikation sind dann
erneut Abfragen in die Quellsysteme notwendig.
Überschaubarer Speicherbedarf der Datenbank Corp_JobMonitor.
Keine Duplizierung der Log-Daten
Mehrere Round-Trips, bis sämtliche Daten selektiert sind.
Tabelle 2: Beschreibung der Variante 2.
Mit den Datenbank-Administratoren wurde massgeblich aufgrund des Speicherbedarfs die Variante 2 priorisiert.
Die Datenübernahme (Log-IDs und Status) wird mit einem Datenbank-Job (SSIS-Package) realisiert (siehe dazu
Kapitel 4.3).
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
6/40
Projektname
Dokumenttitel
Artifaktname
3
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Struktur des Systemdesigns
Dieser Abschnitt zeigt und beschreibt den Aufbau des technischen und organisatorischen Systems bis auf Elementebene.
3.1
Integration in die Serverumgebung
Die Webapplikation Corp_JobMonitor wird auf der PWW-Serverfarm zu liegen kommen. Die Webapplikation ist
jeweils auf den Master-Server zu publizieren, die Replikation in die Serverfarm geht automatisch vonstatten. Die
Datenbank von Corp_JobMonitor wird jeweils auf der 01-Instanz der Datenbank-Server liegen: serverdbdev01,
serverdbint01, serverdbprod01.
Die Abbildung 1 zeigt die Systemgrenzen des Systems Corp_JobMonitor. Die Verbindung zu Corp_PadMan dient
dazu, an die Komponenten-Informationen zu kommen, denen die einzelnen Jobs in Corp_JobMonitor zugewiesen werden, so dass die Benutzer leicht an die verantwortlichen Personen gelangen können.
Corp_PadMan
Corp_JobMonitor
pwwdbprod04
pwwdbprod03
pwwdbprod02
serverdbprod01
PWW-DB-Server
GUI
pwwdbmobile2
serverdbmobile1
Arbeitsstation
MAP-DB-Server
serverBDS
Job-DB-Server
Abbildung 1: Systemgrenzen von Corp_JobMonitor (Production).
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
7/40
Projektname
Dokumenttitel
Artifaktname
3.2
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Datenbankmodell
tabComponentPersonMapping
tabComponent
PK
ComponentId
InsertUser
InsertDate
UpdateUser
UpdateDate
PK
MappingId
FK1,I1
FK2,I2
FK3,I3
ComponentId
PersonId
TypeId
InsertUser
InsertDate
UpdateUser
UpdateDate
tabPerson
PK
PersonId
UserId
InsertUser
InsertDate
UpdateUser
UpdateDate
tabPersonType
PK
tabJobDefinition
PK
JobName
ComponentId
Description
Interface
Dependency
ErrorHandling
InsertUser
InsertDate
UpdateUser
UpdateDate
tabEnvironment
PK
EnvironmentId
TextD
TextF
TextI
TextE
Short
Image
InsertUser
InsertDate
UpdateUser
UpdateDate
tabJob
PK
JobId
FK2,I2
JobDefinitionId
JobName
TypeId
EnvironmentId
Enabled
MustRun
InsertUser
InsertDate
UpdateUser
UpdateDate
CategoryName
CreatedDate
ModifiedDate
FK3,I3
FK1,I1
tabJobType
PK
KeyName
NameD
NameF
NameI
NameE
InsertUser
InsertDate
UpdateUser
UpdateDate
JobDefinitionId
FK1,I1
TypeId
TypeId
Name
InsertUser
InsertDate
UpdateUser
UpdateDate
tabJobStep
PK
JobStepId
FK1,I1
tabJobRun
Name
PackageName
JobId
InsertUser
InsertDate
UpdateUser
UpdateDate
tabJobStepRun
PK
JobRunId
PK
JobStepRunId
FK1,I1
JobId
StartTime
EndTime
Duration
StatusId
Succeeded
Solved
InstanceId
InsertUser
InsertDate
UpdateUser
UpdateDate
FK2,I2
FK1,I1
JobStepId
JobRunId
StartTime
EndTime
Duration
StatusId
Succeeded
Solved
InsertUser
InsertDate
UpdateUser
UpdateDate
FK2,I2
FK3,I3
tabJobStepLog
tabJobRunLog
PK
JobRunLogId
FK1,I1
JobRunId
SSISExecutionId
InstanceId
StatusId
InsertUser
InsertDate
UpdateUser
UpdateDate
FK2,I2
PK
JobStepLogId
FK1,I1
JobStepRunId
ExternalDatabase
ExternalDataTable
ExternalId
StatusId
StartTime
EndTime
Solved
InsertUser
InsertDate
UpdateUser
UpdateDate
tabStatus
PK
StatusId
Name
InsertUser
InsertDate
UpdateUser
UpdateDate
FK2,I2
Abbildung 2: Datenbankmodell Corp_JobMonitor.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
8/40
Projektname
Dokumenttitel
Artifaktname
4
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Schnittstellen
4.1
Informationen zu Datenbank-Jobs erhalten
Um an Informationen zu Datenbank-Jobs zu gelangen, bedarf es einer Schnittstelle zu den entsprechenden Datenbank Servern, welche den SQL Server Agent verwendet. Im PWW-Umfeld ist das derzeit lediglich ein einziger:
serverBDS.
Auf einem Datenbank-Job-Server stellt die Systemdatenbank msdb die entsprechenden SQL Server Agent Systemtabellen zur Verfügung, um an die Details der Datenbank-Jobs zu gelangen.
msdb.dbo.sysjobactivity9
msdb.dbo.sysjobhistory10
msdb.dbo.sysjobs11
msdb.dbo.sysjobschedules12
msdb.dbo.sysjobservers13
msdb.dbo.sysjobsteps14
msdb.dbo.sysjobstepslogs15
Die benötigten Daten werden nun von zwei verschiedenen Datenbank-Jobs für Corp_JobMonitor gesammelt.
Corp_JobMonitor_Job_Basic_Import importiert die Job-Basis-Informationen (siehe Kapitel 4.2).
Corp_JobMonitor_Job_Logs_Import importiert Log-Daten der Datenbank-Jobs (siehe Kapitel 4.3).
9
http://msdn.microsoft.com/en-us/library/ms190484.aspx
http://msdn.microsoft.com/en-us/library/ms174997.aspx
11
http://msdn.microsoft.com/en-us/library/ms189817.aspx
12
http://msdn.microsoft.com/en-us/library/ms188924.aspx
13
http://msdn.microsoft.com/en-us/library/ms187761.aspx
14
http://msdn.microsoft.com/en-us/library/ms187387.aspx
15
http://msdn.microsoft.com/en-us/library/ms174353.aspx
10
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
9/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
4.2
SSIS-Job Corp_JobMonitor_Job_Basic_Import
Bevor überhaupt an einen Import von Logs gedacht werden kann, müssen zunächst die Job-Basis-Informationen
importiert werden. Dazu gehören Informationen wie Job-Namen und -IDs, Job-Steps mit Namen und IDs sowie
Informationen dazu, auf welchen Environments die Jobs aktiv sind. All diese Informationen können aus den beiden Systemtabellen msdb.dbo.sysjobs und msdb.dbo.sysjobsteps erhalten werden.
Die Abbildung 3 zeigt diejenigen Tabellen der Datenbank Corp_JobMonitor, welche vom SSIS-Package
Corp_JobMonitor_Job_Basic_Import tangiert sind.
tabJobDefinition
PK
FK1,I1
tabEnvironment
PK
EnvironmentId
TextD
TextF
TextI
TextE
Short
Image
InsertUser
InsertDate
UpdateUser
UpdateDate
JobName
ComponentId
Description
Interface
Dependency
ErrorHandling
InsertUser
InsertDate
UpdateUser
UpdateDate
tabJob
PK
JobId
FK2,I2
JobDefinitionId
JobName
TypeId
EnvironmentId
Enabled
MustRun
InsertUser
InsertDate
UpdateUser
UpdateDate
CategoryName
CreatedDate
ModifiedDate
FK3,I3
FK1,I1
tabJobType
PK
JobDefinitionId
TypeId
Name
InsertUser
InsertDate
UpdateUser
UpdateDate
tabJobStep
PK
FK1,I1
JobStepId
Name
PackageName
JobId
InsertUser
InsertDate
UpdateUser
UpdateDate
Abbildung 3: Datenbank-Teilmodell mit den Tabellen, welche vom SSIS-Job Corp_JobMonitor_Job_Basic_Import
tangiert sind.
4.2.1 Variablen
Das SSIS-Package verwendet zwei Variablen: Die Applikations-ID sowie einen Fake-Benutzernamen, damit die
durch den Job hinzugefügten Rows wieder erkannt werden können. Beide Variablen gelten für das ganze SSISPackage; dies ist auch dem Scope zu entnehmen.
Name
_strApplID
_strImportUser
Scope
Corp_JobMonitor_Job_Basic_Import
Corp_JobMonitor_Job_Basic_Import
Data Type
String
String
Value
Corp_JobMonitor
ImportJob
Tabelle 3: Variablen des SSIS-Package Corp_JobMonitor_Job_Basic Import.
4.2.2 Control Flow
Die Abbildung 4 zeigt den gesamten Control Flow des SSIS-Packages Corp_JobMonitor_Job_Basic_Import. Die
einzelnen Tasks sind in den jeweiligen Unterkapiteln genauer beschrieben. Die Tabelle 4 enthält eine Kapitelzuordnung.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
10/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Abbildung 4: SSIS-Package Corp_JobMonitor_Job_Basic_Import.
Type
Execute SQL Task
Data Flow Task
Execute SQL Task
Execute SQL Task
Execute SQL Task
Execute SQL Task
Execute SQL Task
Task
DELETE tabJobImport
Read Job-Data and Insert Into tabJobImport
Save PackageName
INSERT new INTO tabJobDefinition
INSERT new INTO tabJob
INSERT new INTO tabJobStep
UPDATE tabJob SET Enabled, CategoryName
Kapitel
4.2.3
4.2.4
4.2.5
4.2.6
4.2.7
4.2.8
4.2.9
Tabelle 4: Kapitelzuordnung Corp_JobMonitor_Job_Logs_Import.
4.2.3 Execute SQL Task: DELETE tabJobImport
Der Task „DELETE tabJobImport” räumt zunächst den temporären Import der letztmaligen SSIS-PackageAusführung wieder auf, indem es die Import-Tabelle tabJobImport leert. Listing 1 zeigt den SQL-Befehl dieses
Tasks.
DELETE tabJobImport
Listing 1: DELETE tabJobImport.
4.2.4 Data Flow Task: Read Job-Data and Insert Into tabJobImport
Nun müssen die benötigten Daten von der Systemdatenbank msdb auf der SQL Server Instanz serverBDS (JobServer) geladen und in die Import-Tabelle tabJobImport der Datenbank Corp_JobMonitor geschrieben wer-
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
11/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
den. Dazu wird ein Data Flow Task verwendet, dessen Sub-Tasks in den nachfolgenden Unterkapiteln genauer
beschrieben sind. Die Abbildung 5 zeigt den Ablauf dieses Data Flow Tasks.
Abbildung 5: Data Flow Task: „Read Job-Data and Insert Into tabJobImport”.
4.2.4.1 OLE DB Source Task: Read Job-Data from JobServer
Listing 2 zeigt das SQL-Query, mit welchem der OLE DB Source Task „Read Job-Data from JobServer“ die Daten
des Job-Servers ins Memory lädt.
j.name sieht in der Quell-Tabelle sysjobs zum Beispiel wie folgt aus: „Int_PL_SMW_Trans_Generate_Tours“.
Die Spalte job_name übernimmt den ganzen Inhalt und konvertiert ihn in ein varchar(200) Feld, während in
den Spalten strJobName sowie strEnvironment Substrings landen; hier „PL_SMW_Trans_Generate_Tours“
resp. „Int_“.
Die Spalte js.command der Quell-Tabelle sysjobsteps wird – vom CAST-Befehl abgesehen – 1:1 übernommen.
Diese Information wird später weiter verarbeitet (siehe Kapitel 4.2.5).
SELECT js.step_uid
,j.job_id
,CONVERT(varchar(200), j.name) AS job_name
,CAST(REPLACE(REPLACE(REPLACE(CONVERT(varchar(200), j.name),
'Prod_',
''),
'Int_',
''),
'Dev_',
'') AS varchar(200)) AS strJobName
,CAST(js.step_name AS varchar(200)) AS step_name
,SUBSTRING(CONVERT(varchar(50), j.name),
0,
CHARINDEX('_', CONVERT(varchar(50), j.name)) + 1) AS strEnvironment
,j.date_created
,j.date_modified
,j.[enabled]
,c.category_id
,c.name AS category_name
,CAST(js.command AS varchar(4000)) AS strcommand
FROM
sysjobs j WITH (NOLOCK) LEFT OUTER JOIN
sysjobsteps js WITH (NOLOCK) ON j.job_id = js.job_id LEFT OUTER JOIN
syscategories c ON j.category_id = c.category_id
WHERE SUBSTRING(j.name, 0, CHARINDEX('_', j.name) + 1) <> ''
AND js.subsystem IN ( 'SSIS', 'CmdExec' )
Listing 2: Read Job-Data from JobServer.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
12/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
4.2.4.2 OLE DB Destination Task: INSERT INTO tabJobImport
Der OLE DB Destination Task „INSERT INTO tabJobImport” macht im Prinzip nichts Anderes als ein Insert aller
geladenen Daten in die Ziel-Tabelle tabJobImport der Datenbank Corp_JobMonitor. Die Ziel-Tabelle enthält
nun Daten auf der Granularität-Stufe Job-Step.
4.2.5 Execute SQL Task: Save PackageName
Die Funktion fctGetPackageName() extrahiert aus dem Command den Package-Namen.
UPDATE tabJobImport
SET
strPackageName = fctGetPackageName(command)
Listing 3: Save PackageName.
4.2.6 Execute SQL Task: INSERT new INTO tabJobDefinition
Zunächst werden die Job-Definitionen eingefügt, wo sie noch nicht existieren. Eine Job-Definition ist die übergeordnete Instanz eines Jobs, welcher auf der Umgebung Development, Integration oder Production platziert ist.
Beispiel: Den Job PL_SMW_Trans_Generate_Tours gibt es für die Umgebungen Integration und Production. Es
gibt daher einen Eintrag in der Tabelle tabJobDefinition und deren zwei in der Tabelle tabJob, wie die Tabelle 5 dies gut visualisiert.
Job-Definition
PL_SMW_Trans_Generate_Tours
Job
Int_PL_SMW_Trans_Generate_Tours
Prod_PL_SMW_Trans_Generate_Tours
Umgebung
Integration
Production
Tabelle 5: Beispiel Job PL_SMW_Trans_Generate_Tours auf Integration und Production.
Listing 4 zeigt den SQL-Befehl dieses Tasks, um die Job-Definitionen in die Tabelle tabJobDefinition zu
schreiben.
INSERT INTO tabJobDefinition
(
JobName
,InsertUser
,InsertDate
,UpdateUser
,UpdateDate
)
SELECT DISTINCT strJobName
,'ImportJob'
,GETDATE()
,'ImportJob'
,GETDATE()
FROM
tabJobImport WITH (NOLOCK)
WHERE strJobName NOT IN
(
SELECT DISTINCT JobName
FROM
tabJobDefinition WITH (NOLOCK)
)
AND job_name_sys IN
(
SELECT
MAX(strEnvironment) + strJobName
FROM
tabJobImport WITH (NOLOCK)
GROUP BY strJobName
)
Listing 4: INSERT new INTO tabJobDefinition.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
13/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
4.2.7 Execute SQL Task: INSERT new INTO tabJob
Nun folgen die konkreten Jobs. Listing 5 zeigt den SQL-Befehl dieses Tasks, um die Jobs in die Tabelle tabJob zu
schreiben.
INSERT INTO tabJob
(
JobId
,JobDefinitionId
,JobName
,EnvironmentId
,[Enabled]
,MustRun
,InsertUser
,InsertDate
,UpdateUser
,UpdateDate
)
SELECT DISTINCT job_id
,jd.JobDefinitionId
,job_name_sys
,env.EnvironmentId
,[enabled]
,0
,'ImportJob'
,GETDATE()
,'ImportJob'
,GETDATE()
FROM
tabJobImport ji WITH (NOLOCK) INNER JOIN
tabJobDefinition jd WITH (NOLOCK) ON ji.strJobName = jd.JobName INNER JOIN
tabEnvironment env WITH (NOLOCK) ON ji.strEnvironment = env.Short
WHERE job_id NOT IN
(
SELECT DISTINCT JobId FROM tabJob WITH (NOLOCK)
)
Listing 5: INSERT new INTO tabJob.
4.2.8 Execute SQL Task: INSERT new INTO tabJobStep
Schlussendlich werden noch die Job-Steps hinzugefügt. Listing 6 zeigt den SQL-Befehl dieses Tasks, um die JobSteps in die Tabelle tabJobStep zu schreiben.
INSERT INTO tabJobStep
(
JobStepId
,Name
,PackageName
,JobId
,InsertUser
,InsertDate
,UpdateUser
,UpdateDate
)
SELECT DISTINCT step_uid
,step_name
,strPackageName
,job_id
,'ImportJob'
,GETDATE()
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
14/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
,'ImportJob'
,GETDATE()
FROM
tabJobImport WITH (NOLOCK)
WHERE step_uid NOT IN
(
SELECT DISTINCT JobStepId FROM tabJobStep WITH (NOLOCK)
)
AND job_id IN
(
SELECT DISTINCT JobId FROM tabJob WITH (NOLOCK)
)
Listing 6: INSERT INTO tabJobStep.
4.2.9 Execute SQL Task: UPDATE tabJob SET Enabled, CategoryName
Zuletzt werden noch Felder aktualisiert, welche sich womöglich in der Job-Definition des SQL Server Agents verändert haben: Enabled, CategoryName, CreatedDate, ModifiedDate. Listing 7 zeigt den SQL-Befehl dieses Tasks.
UPDATE tabJob
SET
tabJob.[Enabled] = ji.[enabled]
,tabJob.CategoryName = ji.category_name
,tabJob.CreatedDate = ji.date_created
,tabJob.ModifiedDate = ji.date_modified
FROM
tabJobImport ji WITH (NOLOCK)
WHERE tabJob.JobId = ji.job_id
Listing 7: UPDATE tabJob SET Enabled, CategoryName.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
15/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
4.3
SSIS-Job Corp_JobMonitor_Job_Logs_Import
Sind die Job-Basis-Informationen geladen, können die Logs hinzu genommen werden. Hier sind einmal die Logs
des SQL Server Agent zu erwähnen, welche sich genau wie die Job-Basis-Informationen in der SystemDatenbank msdb in der System-Tabelle msdb.dbo.sysjobhistory befinden. Derzeit liegen die Datenbank-Jobs
für alle Environments auf der SQL Server Instanz serverBDS (siehe Tabelle 6).
Entwicklung (DEV)
serverBDS
Integration (INT)
serverBDS
Produktion (PROD)
serverBDS
Tabelle 6: SQL Server Instanzen für Datenbank-Jobs (anonymisiert).
Weiter loggen die SSIS-Packages selber noch Fehler, Warnungen und Informationen. Diese Logs landen seit jeher
in der Datenbank Corp_SysLog je Environment. Dies bedeutet, diese Datenbank gibt es auf Development, Integration sowie Production jeweils auf der SQL Server Instanz serverdbZzz01 (siehe Tabelle 7).
Entwicklung (DEV)
serverdbdev01
Integration (INT)
serverdbint01
Produktion (PROD)
serverdbprod01
Tabelle 7: SQL Server Instanzen für System-Logs (anonymisiert).
Das SSIS-Package Corp_JobMonitor_Job_Logs_Import ist daher viergeteilt, um alle Daten-Quellen abdecken zu
können und das Package einigermassen übersichtlich zu halten.
Die Abbildung 6 zeigt diejenigen Tabellen der Datenbank Corp_JobMonitor, welche vom SSIS-Package
Corp_JobMonitor_Job_Logs_Import tangiert sind. Die Tabelle tabStatus wird zwar nicht verändert, doch zeigen alle anderen betroffenen Tabellen via Foreign-Key auf sie.
tabJobRun
tabJobStepRun
PK
JobRunId
PK
JobStepRunId
FK1,I1
JobId
StartTime
EndTime
Duration
StatusId
Succeeded
Solved
InstanceId
InsertUser
InsertDate
UpdateUser
UpdateDate
FK2,I2
FK1,I1
JobStepId
JobRunId
StartTime
EndTime
Duration
StatusId
Succeeded
Solved
InsertUser
InsertDate
UpdateUser
UpdateDate
FK2,I2
FK3,I3
tabJobStepLog
tabJobRunLog
PK
JobRunLogId
FK1,I1
JobRunId
SSISExecutionId
InstanceId
StatusId
InsertUser
InsertDate
UpdateUser
UpdateDate
FK2,I2
PK
JobStepLogId
FK1,I1
JobStepRunId
ExternalDatabase
ExternalDataTable
ExternalId
StatusId
StartTime
EndTime
Solved
InsertUser
InsertDate
UpdateUser
UpdateDate
tabStatus
PK
StatusId
Name
InsertUser
InsertDate
UpdateUser
UpdateDate
FK2,I2
Abbildung 6: Datenbank-Teilmodell mit den Tabellen, welche vom SSIS-Job Corp_JobMonitor_Job_Logs_Import
tangiert sind.
4.3.1 Variablen
Das SSIS-Package verwendet drei Variablen: Die Applikations-ID sowie einen Fake-Benutzernamen, damit die
durch den Job hinzugefügten Rows wieder erkannt werden können. Des weiteren eine Variable, welche erst im
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
16/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Verlauf des Packages befüllt werden (siehe Kapitel 4.3.3). Alle drei Variablen gelten für das ganze SSIS-Package;
dies ist auch dem Scope zu entnehmen.
Name
_strApplID
_strImportUser
dtmLastRunEnd
Scope
Corp_JobMonitor_Job_Logs_Import
Corp_JobMonitor_Job_Logs_Import
Corp_JobMonitor_Job_Logs_Import
Data Type
String
String
DateTime
Value
Corp_JobMonitor
ImportJob
-
Tabelle 8: Variablen des SSIS-Package Corp_JobMonitor_Job_Logs_Import.
4.3.2 Control Flow
Die Abbildung 7 zeigt den gesamten – zusammen geklappten(!) – Control Flow des SSIS-Packages
Corp_JobMonitor_Job_Logs_Import. Die einzelnen Tasks sind in den jeweiligen Unterkapiteln genauer beschrieben. Die Tabelle 9 enthält eine Kapitelzuordnung.
Abbildung 7: SSIS-Package Corp_JobMonitor_Job_Logs_Import (eingeklappt!).
Type
Execute SQL Task
Sequence Container
Sequence Container
Sequence Container
Sequence Container
Execute SQL Task
Execute SQL Task
Task
SELECT MAX(dtmEndTime) FROM tabJobRun
Import data from msdb
Import data from Corp_SysLog (PROD)
Import data from Corp_SysLog (INT)
Import data from Corp_SysLog (DEV)
Update Status in tabJobStepRun
Update Status in tabJobRun
Kapitel
4.3.3
4.3.4
4.3.5
4.3.6
4.3.7
4.3.8
4.3.9
Tabelle 9: Kapitelzuordnung Corp_JobMonitor_Job_Logs_Import.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
17/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
4.3.3 Execute SQL Task: Zuletzt geladene Daten bestimmen
Zunächst wird in der eigenen Datenbank Corp_JobMonitor nach dem zuletzt geladenen Job-Run gesucht.
Listing 8 zeigt das SQL-Query dieses Tasks.
SELECT MAX(EndTime) AS dtmLastRunEnd
FROM
tabJobRun WITH (NOLOCK)
Listing 8: SELECT MAX(dtmEndTime) FROM tabJobRun.
Das Resultat wird in die Variable User::dtmLastRunEnd gespeichert.
4.3.4 Sequence Container: Import data from msdb
Nun geht es an das Importieren der SQL Server Agent Logs, welche in unserem Fall auf der SQL Server Instanz
serverBDS liegen. Die Systemdatenbank msdb ist nun also die erste von vier Log-Datenquellen.
Die Abbildung 8 zeigt den gesamten Sequence Container: „Import data from msdb“. Die einzelnen Tasks sind in
den jeweiligen Unterkapiteln genauer beschrieben. Die Tabelle 10 enthält eine Kapitelzuordnung.
Abbildung 8: Sequence Container: „Import data from msdb”.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
18/40
Projektname
Dokumenttitel
Artifaktname
Type
Execute SQL Task
Data Flow Task
Execute SQL Task
Execute SQL Task
Execute SQL Task
Execute SQL Task
Execute SQL Task
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Task
TRUNCATE TABLE tabJobAgentImport
Get msdb-Data
Update Status in tabJobAgentImport
INSERT INTO tabJobRun
INSERT INTO tabJobRunLog
INSERT INTO tabJobStepRun
INSERT INTO tabJobStepLog
Kapitel
4.3.4.1
4.3.4.2
4.3.4.3
4.3.4.4
4.3.4.5
4.3.4.6
4.3.4.7
Tabelle 10: Kapitelzuordnung Sequence Container: „Import data from msdb“.
4.3.4.1 Execute SQL Task: TRUNCATE TABLE tabJobAgentImport
Der Task „TRUNCATE TABLE tabJobAgentImport” räumt zunächst den temporären Import der letztmaligen SSISPackage-Ausführung wieder auf, indem es die Import-Tabelle mit den TRUNCATE Befehl leert. Listing 9 zeigt den
SQL-Befehl dieses Tasks.
TRUNCATE TABLE tabJobAgentImport
Listing 9: TRUNCATE TABLE tabJobAgentImport.
4.3.4.2 Data Flow Task: Get msdb-Data
Für das Laden der SQL Server Agent Log-Daten wird wiederum ein Data Flow Task verwendet. Dieses Mal müssen die geladenen Daten allerdings mit bereits Vorhandenem verknüpft werden. Die Sub-Tasks sind in den nachfolgenden Unterkapiteln genauer beschrieben. Die Abbildung 9 zeigt den Ablauf dieses Data Flow Tasks.
Abbildung 9: Data Flow Task: „Get msdb-Data”.
4.3.4.2.1 OLE DB Source: Read JobAgent Logs
Mit einer OLE DB Source werden die Daten aus der Systemtabelle sysjobhistory geladen. Dem JOIN mit der
Systemtabelle sysjobhistory liegt die Tatsache zugrunde, dass die Logs des SQL Server Agent auf Granularität-Stufe Job-Step vorliegen. Listing 10 zeigt die SQL-Abfrage dieses Tasks, eine detaillierte Beschreibung folgt im
Anschluss.
SELECT CASE WHEN jh.step_id = 0
THEN jh.instance_id
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
19/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
ELSE
(
SELECT MIN(instance_id)
FROM sysjobhistory AS c WITH (NOLOCK)
WHERE c.job_id = jh.job_id
AND step_id = 0
AND c.instance_id > jh.instance_id
)
END AS instance_base_id
,jh.instance_id
,jh.job_id
,js.step_uid
,jh.step_id
,jh.sql_message_id
,jh.message
,jh.run_status
,CAST(LTRIM(STR(jh.run_date))+'
'+STUFF(STUFF(right('000000'+LTRIM(STR(jh.run_time)), 6), 3, 0, ':'), 6, 0, ':') AS
datetime) AS 'run_start'
,DATEADD(ss
,(jh.run_duration / 10000) * 60 * 60 + ((jh.run_duration % 10000) / 100) * 60
+ (jh.run_duration % 100)
,CAST(LTRIM(STR(jh.run_date))+'
'+STUFF(STUFF(right('000000'+LTRIM(STR(jh.run_time)), 6), 3, 0, ':'), 6, 0, ':') AS
datetime)) AS 'run_end'
,(jh.run_duration / 10000) * 60 * 60 + ((jh.run_duration % 10000) / 100) * 60 +
(jh.run_duration % 100) AS 'run_duration'
,jh.server
FROM
sysjobhistory AS jh WITH (NOLOCK) LEFT OUTER JOIN
sysjobsteps AS js WITH (NOLOCK) ON jh.job_id = js.job_id AND jh.step_id =
js.step_id
WHERE DATEADD(ss
,(jh.run_duration / 10000) * 60 * 60 + ((jh.run_duration % 10000) / 100) * 60
+ (jh.run_duration % 100)
,CAST(LTRIM(STR(jh.run_date))+'
'+STUFF(STUFF(right('000000'+LTRIM(STR(jh.run_time)), 6), 3, 0, ':'), 6, 0, ':') AS
datetime))
> ?
Listing 10: Read JobAgent Logs.
Wichtig zu wissen: Die Systemtabelle sysjobhistory enthält grundsätzlich Informationen des SQL Server Agent
bezüglich Start und Ende einzelner Job-Runs resp. dessen Job-Step-Runs. Das Datenmodell von
Corp_JobMonitor sieht einerseits vor, dass Job-Runs und Job-Step-Runs unterschieden werden. Andererseits
unterscheidet es den eigentlichen Run von dessen Logs. Hintergrund davon ist, dass ein Job mehrere Job-Steps
und ein Run wiederum mehrere Logs haben kann.
Ziel dieser Abfrage ist, nebst all den Logs auch zu wissen, welche Logs zum selben Job-Run gehören. Die Systemtabelle sysjobhistory enthält als gruppierende Information lediglich die Job-ID (GUID). Damit kann ein Job
identifiziert werden, nicht aber ein einzelner Job-Run. Problematisch ist dies hauptsächlich bei Jobs, die in dichter
Abfolge aufeinander ablaufen. Mit dem CASE-Konstrukt, welches zu Beginn der Abfrage steht, werden die Logs
zu einem Job-Run gebündelt. Es kann dabei glücklicherweise davon ausgegangen werden, dass das SQL Server
Agent Log für Step-ID = 0 (Zusammenfassung Job-Run) stets am Schluss steht.
Die nahezu kryptisch anmutenden Abfrage-Elemente am Schluss führen dazu, dass die geloggten Start und Endzeiten in ein mittels SQL weiter bearbeitbaren Format gespeichert werden. In der Systemtabelle sysjobhistory
steht beispielsweise die Zeit 150309 für 15:03:09 Uhr oder aber 1728 für 00:17:28 Uhr.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
20/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
4.3.4.2.2 OLE DB Source: Read Job-Ids
Damit schlussendlich nur zu den bekannten Jobs Logs in der Datenbank Corp_JobMonitor landen, werden mit
dieser zusätzlichen OLE DB Source die Job-IDs auf den Job-Basis-Informationen geladen und später mit den Logs
zusammengeführt. Listing 11 zeigt die SQL-Abfrage dieses Tasks.
SELECT JobId
FROM
tabJob WITH (NOLOCK)
Listing 11: Read Job-Ids.
4.3.4.2.3 Sort Transformation & Merge Join Transformation
Die beiden OLD DB Sourcen werden anschliessend mittels Merge Join Transformation miteinander verknüpft.
Dazu ist es zwingend notwendig, dass die Sourcen sortiert werden. Dies geschieht beidseitig mit einer Sort
Transformation. Es wird beidseits nach der Job-ID sortiert.
4.3.4.2.4 OLE DB Destination: INSERT INTO tabJobAgentLog
Der OLE DB Destination Task „INSERT INTO tabJobAgentLog” macht wiederum nichts Anderes als ein Insert aller
Daten in die Ziel-Tabelle tabJobAgentImport der Datenbank Corp_JobMonitor. Die Ziel-Tabelle enthält nun
Daten auf der Granularität-Stufe Job-Step-Log sowie Job-Run-Log.
4.3.4.3 Execute SQL Task: Update Status in tabJobAgentImport
Nun findet eine Status-Interpretation der ausschliesslich textuell vorliegenden Logs statt. Sowohl für SQL Server
Agent Logs wie auch für SSIS Package Logs wird in Corp_JobMonitor eine Status-Mapping-Tabelle geführt. Die
Tabelle 11 stellt den aktuellen Tabellen-Inhalt dar. Sollte mit der Status-Interpretation etwas nicht stimmen, kann
die Korrektur zur Laufzeit in dieser Tabelle von einem Datenbank-Administrator selbständig vorgenommen werden. Alle anschliessenden Status-Interpretationen werden dann korrigiert stattfinden.
StatusText
DTSER_FAILURE
DTSER_SUCCESS
The job failed.
The job succeeded.
The job was stopped
The step failed.
The step succeeded.
The step was cancelled
StatusId
2
0
2
0
2
2
0
2
Bedeutung
Fehler
Info
Fehler
Info
Fehler
Fehler
Info
Fehler
Tabelle 11: Inhalt Status-Mapping-Tabelle tabJobAgentStatusMapping.
Listing 12 zeigt die SQL-Abfrage dieses Tasks. Sie nimmt die in Listing 13 gezeigte View qryJobAgentStatus zu
Hilfe.
UPDATE
SET
FROM
WHERE
tabJobAgentImport
tabJobAgentImport.StatusId = jas.StatusId
dbo.qryJobAgentStatus jas
tabJobAgentImport.instance_id = jas.instance_id
Listing 12: Update Status in tabJobAgentImport.
SELECT qInner.instance_id
,MAX(qInner.StatusId) AS StatusId
FROM
(
SELECT jai.instance_base_id
,jai.instance_id
,jai.job_id
,jai.step_uid
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
21/40
Projektname
Dokumenttitel
Artifaktname
FROM
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
,jai.step_id
,jai.sql_message_id
,jai.[message]
,jai.run_status
,jai.run_start
,jai.run_end
,jai.run_duration
,jai.[server]
,jasm.StatusId
tabJobAgentImport jai WITH (NOLOCK) INNER JOIN
tabJobAgentStatusMapping jasm WITH (NOLOCK)
ON jai.[message] LIKE '%' + jasm.StatusText + '%'
) qInner
GROUP BY qInner.instance_id
Listing 13: View qryJobAgentStatus.
4.3.4.4 Execute SQL Task: INSERT INTO tabJobRun
Der Task „INSERT INTO tabJobRun” fügt nun aufgrund eines Teils der geladenen Logs Job-Run-Einträge in die
Tabelle tabJobRun hinzu. Lediglich Log-Einträge mit step_id = 0 aus dem SQL Server Agent Log gehören zu
keinem Job-Step und somit zum Job selbst. Listing 14 zeigt den SQL-Befehl zum INSERT dieser Daten.
INSERT INTO Corp_JobMonitor.dbo.tabJobRun
(
JobId
,StartTime
,EndTime
,Duration
,Succeeded
,Solved
,InstanceId
,InsertUser
,InsertDate
,UpdateUser
,UpdateDate
)
SELECT job_id
,run_start
,run_end
,run_duration
,1
,0
,instance_id
,'ImportJob'
,GETDATE()
,'ImportJob'
,GETDATE()
FROM
tabJobAgentImport WITH (NOLOCK)
WHERE step_id = 0
Listing 14: INSERT INTO tabJobRun.
4.3.4.5 Execute SQL Task: INSERT INTO tabJobRunLog
Sind die eigentlichen Job-Runs hinzugefügt worden, übernimmt der Task „INSERT INTO tabJobRunLog“ die Aufgabe, deren Logs in die Tabelle tabJobRunLog einzufügen. Listing 15 zeigt den SQL-Befehl zum INSERT dieser
Daten.
INSERT INTO tabJobRunLog
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
22/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
(
JobRunId
,SSISExecutionId
,InstanceId
,StatusId
,InsertUser
,InsertDate
,UpdateUser
,UpdateDate
)
SELECT jr.JobRunId
,null
,jai.instance_id
,jai.StatusId
,'ImportJob'
,GETDATE()
,'ImportJob'
,GETDATE()
FROM
tabJobAgentImport jai WITH (NOLOCK) INNER JOIN
tabJobRun jr WITH (NOLOCK) ON jai.instance_id = jr.InstanceId
Listing 15: INSERT INTO tabJobRunLog.
4.3.4.6 Execute SQL Task: INSERT INTO tabJobStepRun
Der Task „INSERT INTO tabJobStepRun“ fügt nun die Job-Step-Runs in die Tabelle tabJobStepRun hinzu. Infrage kommen hier alle Logs mit step_id <> 0 (ungleich). Listing 16 zeigt den SQL-Befehl zum INSERT dieser
Daten.
INSERT INTO tabJobStepRun
(
JobStepId
,JobRunId
,StartTime
,EndTime
,Duration
,Succeeded
,Solved
,InsertUser
,InsertDate
,UpdateUser
,UpdateDate
)
SELECT jai.step_uid
,jr.JobRunId
,jai.run_start
,jai.run_end
,jai.run_duration
,1
,0
,'ImportJob'
,GETDATE()
,'ImportJob'
,GETDATE()
FROM
tabJobAgentImport jai WITH (NOLOCK) INNER JOIN
tabJobRun jr WITH (NOLOCK)
ON jai.instance_base_id = jr.InstanceId AND jai.step_id <> 0
Listing 16: INSERT INTO tabJobStepRun.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
23/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
4.3.4.7 Execute SQL Task: INSERT INTO tabJopStepLog
Sind die eigentlichen Job-Step-Runs hinzugefügt worden, übernimmt der Task „INSERT INTO tabJopStepLog“
abschliessend die Aufgabe, deren Logs in die Tabelle tabJopStepLog einzufügen. Listing 17 zeigt den SQLBefehl zum INSERT dieser Daten. Die SQL Server Agent Logs sind danach vollständig in die Datenstruktur der
Datenbank Corp_JobMonitor importiert. Das SSIS-Package fährt mit dem ersten der drei SSIS Package Log
Imports aus den Datenbanken Corp_SysLog weiter.
INSERT INTO Corp_JobMonitor.dbo.tabJobStepLog
(
JobStepRunId
,ExternalDatabase
,ExternalDataTable
,ExternalId
,StatusId
,StartTime
,EndTime
,Solved
,InsertUser
,InsertDate
,UpdateUser
,UpdateDate
)
SELECT jsr.JobStepRunId
,'msdb'
,'sysjobhistory'
,jai.instance_id
,jai.StatusId
,jai.run_start
,jai.run_end
,0
,'ImportJob'
,GETDATE()
,'ImportJob'
,GETDATE()
FROM
tabJobAgentImport jai WITH (NOLOCK) INNER JOIN
tabJobRun jr WITH (NOLOCK)
ON jai.instance_base_id = jr.InstanceId AND jai.step_id <> 0 INNER JOIN
tabJobStepRun jsr WITH (NOLOCK)
ON jr.JobRunId = jsr.JobRunId AND jai.step_uid = jsr.JobStepId
Listing 17: INSERT INTO tabJopStepLog.
4.3.5 Sequence Container: Import data from Corp_SysLog (PROD)
Als nächster Schritt folgt der Import der SSIS Package Logs aus den drei Corp_SysLog Datenbanken auf Development, Integration und Production. Dieses Kapitel beschreibt den produktiven Ablauf stellvertretend für alle
drei Environments.
Die Abbildung 10 zeigt den gesamten Sequence Container „Import data from Corp_SysLog (PROD)“. Die einzelnen Tasks sind in den jeweiligen Unterkapiteln genauer beschrieben. Die Tabelle 12 enthält eine Kapitelzuordnung.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
24/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Abbildung 10: Sequence Container: Import data from Corp_SysLog (PROD).
Type
Execute SQL Task
Data Flow Task
Execute SQL Task
Execute SQL Task
Task
TRUNCATE TABLE tabSysLogImport
Get Corp_SysLog-Data (PROD)
Update Status in tabSysLogImport
INSERT INTO tabJobStepLog
Kapitel
4.3.5.1
4.3.5.2
4.3.5.3
4.3.5.4
Tabelle 12: Kapitelzuordnung Sequence Container: Import data from Corp_SysLog (PROD).
4.3.5.1 Execute SQL Task: TRUNCATE TABLE tabSysLogImport
Der Task „TRUNCATE TABLE tabSysLogImport” räumt zunächst den temporären Import der letztmaligen SSISPackage-Ausführung wieder auf, indem es die Import-Tabelle mit den TRUNCATE Befehl leert. Listing 18 zeigt
den SQL-Befehl dieses Tasks.
TRUNCATE TABLE tabSysLogImport
Listing 18: TRUNCATE TABLE tabSysLogImport.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
25/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
4.3.5.2 Data Flow Task: Get Corp_SysLog-Data (PROD)
Für das Laden der SSIS Package Logs wird erneut ein Data Flow Task verwendet. Dieses Mal werden die gelesenen Daten direkt in die temporäre Zieltabelle geschrieben. Die Abbildung 11 zeigt den Ablauf dieses Data Flow
Tasks.
Abbildung 11: Data Flow Task: Get Corp_SysLog-Data (PROD).
4.3.5.2.1 OLE DB Source Task: Read from PROD SysLog
Listing 19 zeigt die SQL-Abfrage des OLE DB Source Tasks. Selektiert werden die Daten aus der Datenbank
Corp_SysLog. Abhängig vom Environment befindet sich diese Tabelle auf der SQL Server Instanz serverdbdev01, serverdbint01 oder serverdbprod01.
Die View qryJobMonitorLog in der Datenbank Corp_SysLog hilft dabei, alle benötigten Daten aus der Datenbank zentral zu retournieren. Dabei vereint sie mit dem UNION Befehl Daten aus den Tabellen sysssislog sowie sysdtslog90. Sie definiert auch eine fiktive ID, welche in die Datenbank Corp_JobMonitor übernommen
werden und bei Benutzerabfragen später wieder gegen diese View verwendet werden kann. Listing 20 zeigt die
SQL-Abfrage dieser View.
SELECT
FROM
WHERE
ORDER BY
*
qryJobMonitorLog
dtmStartTime > DATEADD(hh, -12, GETDATE())
dtmStartTime
Listing 19: Read from PROD SysLog.
SELECT 'sysssislog' + CAST(id AS varchar) AS strId
,'sysssislog' AS strDataTable
,id AS lngId
,[event] AS strEvent
,computer AS strComputer
,operator AS strOperator
,[source] AS strSource
,sourceid AS uidSourceId
,executionid AS uidExecutionId
,starttime AS dtmStartTime
,endtime AS dtmEndTime
,datacode AS lngDataCode
,databytes AS imgDataBytes
,[message] AS strMessage
,errorcode AS lngErrorCode
,errorcolumn AS lngErrorColumn
,bitErledigt
FROM
sysssislog WITH (NOLOCK)
UNION ALL
SELECT 'sysdtslog90' + CAST(id AS varchar) AS strId
,'sysdtslog90' AS strDataTable
,id AS lngId
,[event] AS strEvent
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
26/40
Projektname
Dokumenttitel
Artifaktname
FROM
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
,computer AS strComputer
,operator AS strOperator
,[source] AS strSource
,sourceid AS uidSourceId
,executionid AS uidExecutionId
,starttime AS dtmStartTime
,endtime AS dtmEndTime
,datacode AS lngDataCode
,databytes AS imgDataBytes
,[message] AS strMessage
,errorcode AS lngErrorCode
,errorcolumn AS lngErrorColumn
,bitErledigt
sysdtslog90 WITH (NOLOCK)
Listing 20: View qryJobMonitorLog.
4.3.5.2.2 OLE DB Destination Task: INSERT INTO tabSysLogImport
Der OLE DB Destination Task „INSERT INTO tabSysLogImport” macht wiederum nichts Anderes als ein Insert aller
Daten in die Ziel-Tabelle tabSysLogImport der Datenbank Corp_JobMonitor. Die Ziel-Tabelle enthält nun
Daten auf der Granularität-Stufe Job-Run-Log.
4.3.5.3 Execute SQL Task: Update Status in tabSysLogImport
Nun findet wiederum eine Status-Interpretation der ausschliesslich textuell vorliegenden Logs statt. Wie für die
SQL Server Agent Logs wird auch für die SSIS Package Logs eine Status-Mapping-Tabelle geführt. Die Tabelle 13
stellt den aktuellen Tabellen-Inhalt dar. Sollte mit der Status-Interpretation etwas nicht stimmen, kann die Korrektur zur Laufzeit in dieser Tabelle von einem Datenbank-Administrator selbständig vorgenommen werden. Alle
anschliessenden Status-Interpretationen werden dann korrigiert stattfinden.
StatusText
CustomErrorRow
CustomInformation
OnError
OnTaskFailed
OnWarning
PackageEnd
PackageStart
StatusId
2
0
2
2
1
0
0
Bedeutung
Fehler
Info
Fehler
Fehler
Warnung
Info
Info
Tabelle 13: Inhalt Status-Mapping-Tabelle tabSysLogStatusMapping,
Listing 21 zeigt die SQL-Abfrage dieses Tasks.
UPDATE
SET
FROM
WHERE
tabSysLogImport
tabSysLogImport.StatusId = slsm.StatusId
tabSysLogStatusMapping slsm
tabSysLogImport.strEvent LIKE '%' + slsm.StatusText + '%'
Listing 21: Update Status in tabSysLogImport.
4.3.5.4 Execute SQL Task: INSERT INTO tabJobStepLog
Nachdem die Status gesetzt sind, fügt der Task „INSERT INTO tabJobStepLog“ die SSIS Package Logs direkt in die
Tabelle tabJobStepLog hinzu. Listing 22 zeigt den SQL-Befehl zum INSERT dieser Daten.
INSERT INTO Corp_JobMonitor.dbo.tabJobStepLog
(
JobStepRunId
,ExternalDatabase
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
27/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
,ExternalDataTable
,ExternalId
,StatusId
,StartTime
,EndTime
,Solved
,InsertUser
,InsertDate
,UpdateUser
,UpdateDate
)
SELECT jsr.JobStepRunId
,'Corp_SysLog'
,sli.strDataTable
,sli.lngId
,sli.StatusId
,sli.dtmStartTime
,sli.dtmEndTime
,0
,'ImportJob'
,GETDATE()
,'ImportJob'
,GETDATE()
FROM
tabJobAgentImport jai WITH (NOLOCK) INNER JOIN
tabJobRun jr WITH (NOLOCK)
ON jai.instance_base_id = jr.InstanceId AND jai.step_id = 0 INNER JOIN
tabJob j WITH (NOLOCK) ON j.EnvironmentId = 3 AND jr.JobId = j.JobId INNER JOIN
tabJobStepRun jsr WITH (NOLOCK) ON jr.JobRunId = jsr.JobRunId INNER JOIN
tabJobStep js WITH (NOLOCK) ON jsr.JobStepId = js.JobStepId INNER JOIN
qrySysLogImport sli
ON sli.dtmStepStartTime BETWEEN jsr.StartTime AND jsr.EndTime
AND sli.dtmStepEndTime BETWEEN jsr.StartTime AND jsr.EndTime
AND sli.strSource = js.PackageName
Listing 22: INSERT INTO tabJobStepLog.
Der Vollständigkeit halber zeigt Listing 23 hier noch die SQL-Abfrage der View qrySysLogImport.
SELECT sli.strDataTable
,sli.lngId
,sli.strEvent
,sli.strComputer
,sli.strOperator
,sli.strSource
,sli.uidSourceId
,sli.uidExecutionId
,sli.dtmStartTime
,sli.dtmEndTime
,sli.lngDataCode
,sli.imgDataBytes
,sli.strMessage
,sli.lngErrorCode
,sli.lngErrorColumn
,sli.bitErledigt
,sli.StatusId
,q.dtmStepStartTime
,q.dtmStepEndTime
FROM
dbo.tabSysLogImport AS sli WITH (NOLOCK) INNER JOIN
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
28/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
(
SELECT
uidExecutionId
,MIN(dtmStartTime) AS dtmStepStartTime
,MAX(dtmEndTime) AS dtmStepEndTime
FROM
dbo.tabSysLogImport WITH (NOLOCK)
WHERE
strEvent IN ( 'PackageStart', 'PackageEnd' )
GROUP BY uidExecutionId
) AS q ON sli.uidExecutionId = q.uidExecutionId
Listing 23: View qrySysLogImport.
4.3.6 Sequence Container: Import data from Corp_SysLog (INT)
Der Import der SSIS Package Logs aus dem Integration Environment funktioniert analog demjenigen für die Production. Die Log-Daten werden entsprechend von der Integration-Datenbank Corp_SysLog geladen und innerhalb der Datenstruktur von Corp_JobMonitor den INT-Jobs zugewiesen.
Die Abbildung 12 zeigt den gesamten Sequence Container „Import data from Corp_SysLog (INT)“. Die Beschreibung der einzelnen Tasks kann den vorangegangenen Kapiteln entnommen werden.
Abbildung 12: Sequence Container: Import data from Corp_SysLog (INT).
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
29/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
4.3.7 Sequence Container: Import data from Corp_SysLog (DEV)
Der Import der SSIS Package Logs aus dem Development Environment funktioniert analog demjenigen für die
Production. Die Log-Daten werden entsprechend von der Development-Datenbank Corp_SysLog geladen und
innerhalb der Datenstruktur von Corp_JobMonitor den DEV-Jobs zugewiesen.
Die Abbildung 13 zeigt den gesamten Sequence Container „Import data from Corp_SysLog (DEV)“. Die Beschreibung der einzelnen Tasks kann den vorangegangenen Kapiteln entnommen werden.
Abbildung 13: Sequence Container: Import data from Corp_SysLog (DEV).
4.3.8 Execute SQL Task: Update Status in tabJobStepRun
Momentan befinden sich Status lediglich auf Stufe Job-Run-Log sowie Job-Step-Run-Log in der Datenbank
Corp_JobMonitor. In der Webapplikation wird der Status allerdings ebenfalls auf Stufe Job-Run benötigt. Damit sich die Webapplikation diesen Status nicht zusammen selektieren muss, wird in zwei Schritten der Status
nach oben in der Datenstruktur propagiert.
Der Execute SQL Task „Update Status in tabJobStepRun” nimmt die Status der einzelnen Job-Step-Run-Logs und
propagiert ihn hinauf zum Job-Step-Run. Listing 24 zeigt den entsprechenden SQL-Befehl dieses Tasks.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
30/40
Projektname
Dokumenttitel
Artifaktname
UPDATE
SET
FROM
WHERE
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
tabJobStepRun
StatusId = q.StatusId
qryJobStepRunStatusGrouped q
tabJobStepRun.JobStepRunId = q.JobStepRunId
Listing 24: Update Status in tabJobStepRun.
Der Vollständigkeit halber zeigt Listing 25 hier noch die SQL-Abfrage der View qryJobStepRunStatusGrouped.
SELECT
FROM
jsl.JobStepRunId, MAX(jsl.StatusId) AS StatusId
tabJobAgentImport AS jai WITH (NOLOCK) INNER JOIN
tabJobRun AS jr WITH (NOLOCK) ON jai.instance_id = jr.InstanceId INNER JOIN
tabJobStepRun AS jsr WITH (NOLOCK) ON jr.JobRunId = jsr.JobRunId INNER JOIN
tabJobStepLog AS jsl WITH (NOLOCK) ON jsr.JobStepRunId = jsl.JobStepRunId
GROUP BY jsl.JobStepRunId
Listing 25: View qryJobStepRunStatusGrouped.
4.3.9 Execute SQL Task: Update Status in tabJobRun
Der Execute SQL Task „Update Status in tabJobRun” nimmt nun diesen propagierten Job-Step-Run Status und
verbindet ihn mit den Job-Run-Log Status. Daraus ergibt sich der Job-Run Status, welcher in die Tabelle tabJobRun propagiert wird. Listing 26 zeigt den entsprechenden SQL-Befehl dieses Tasks.
UPDATE
SET
FROM
WHERE
tabJobRun
StatusId = q.StatusId
qryJobRunStatusGrouped q
tabJobRun.JobRunId = q.JobRunId
Listing 26: Update Status in tabJobRun.
Der Vollständigkeit halber zeigt Listing 27 hier noch die SQL-Abfrage der View qryJobRunStatusGrouped.
SELECT
FROM
JobRunId, MAX(StatusId) AS StatusId
(
SELECT jrl.JobRunId, jrl.StatusId
FROM
tabJobAgentImport AS jai WITH (NOLOCK)
tabJobRun AS jr WITH (NOLOCK)
ON jai.instance_id = jr.InstanceId
tabJobRunLog AS jrl WITH (NOLOCK)
ON jr.JobRunId = jrl.JobRunId
UNION ALL
SELECT jsr.JobRunId, jsr.StatusId
FROM
tabJobAgentImport AS jai WITH (NOLOCK)
tabJobRun AS jr WITH (NOLOCK)
ON jai.instance_id = jr.InstanceId
tabJobStepRun AS jsr WITH (NOLOCK)
ON jr.JobRunId = jsr.JobRunId
) AS qInner
GROUP BY JobRunId
INNER JOIN
INNER JOIN
INNER JOIN
INNER JOIN
Listing 27: View qryJobRunStatusGrouped.
4.4
SSIS-Job Corp_JobMonitor_CleanUp
Der dritte SSIS-Job von Corp_JobMonitor ist der Clean-Up-Job. Er löscht Job-Run-Daten weg, die nicht mehr
benötigt werden. Dazu entfernt er Einträge aus den Tabellen tabJobStepLog, tabJobStepRun, tabJobRunLog
sowie tabJobRunLog.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
31/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
4.4.1 Variablen
Das SSIS-Package verwendet zwei Variablen: Die Applikations-ID sowie eine numerische Variable, welche definiert, wie viele Tage die JobMonitor-Daten behalten werden sollen. Als Default-Wert wird von 31 Tagen ausgegangen. Beide Variablen gelten für das ganze SSIS-Package; dies ist auch dem Scope zu entnehmen.
Name
_strApplID
lngKeepForDays
Scope
Corp_JobMonitor_CleanUp
Corp_JobMonitor_CleanUp
Data Type
String
Int32
Value
Corp_JobMonitor
31
Tabelle 14: Variablen des SSIS-Package Corp_JobMonitor_CleanUp.
4.4.2 Control Flow
Die Abbildung 14 zeigt den gesamten Control Flow des SSIS-Packages Corp_JobMonitor_CleanUp. Die einzelnen
Tasks sind in den jeweiligen Unterkapiteln genauer beschrieben.
Abbildung 14: SSIS-Package Corp_JobMonitor_CleanUp.
4.4.3 Execute SQL Task: DELETE tabJobStepLog
Der Task „DELETE tabJobStepLog” löscht zunächst die Einträge aus der Tabelle tabJobStepLog. Listing 28 zeigt
den SQL-Befehl dieses Tasks.
DELETE tabJobStepLog
FROM
tabJobStepRun jsr WITH (NOLOCK) INNER JOIN
tabJobRun jr WITH (NOLOCK) ON jsr.JobRunId = jr.JobRunId
WHERE jsr.JobStepRunId = tabJobStepLog.JobStepRunId and jr.StartTime < GETDATE() - ?
Listing 28: DELETE tabJobStepLog.
4.4.4 Execute SQL Task: DELETE tabJobStepRun
Der Task „DELETE tabJobStepRun” löscht die Einträge aus der Tabelle tabJobStepRun. Listing 29 zeigt den
SQL-Befehl dieses Tasks.
DELETE tabJobStepRun
FROM
tabJobRun jr WITH (NOLOCK)
WHERE tabJobStepRun.JobRunId = jr.JobRunId and jr.StartTime < GETDATE() - ?
Listing 29: DELETE tabJobStepRun.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
32/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
4.4.5 Execute SQL Task: DELETE tabJobRunLog
Der Task „DELETE tabJobRunLog” löscht die Einträge aus der Tabelle tabJobRunLog. Listing 30 zeigt den SQLBefehl dieses Tasks.
DELETE tabJobRunLog
FROM
tabJobRun jr WITH (NOLOCK)
WHERE tabJobRunLog.JobRunId = jr.JobRunId and jr.StartTime < GETDATE() - ?
Listing 30: DELETE tabJobRunLog.
4.4.6 Execute SQL Task: DELETE tabJobRunLog
Der Task „DELETE tabJobRunLog” löscht die Einträge aus der Tabelle tabJobRunLog. Listing 31 zeigt den SQLBefehl dieses Tasks.
DELETE tabJobRun
WHERE StartTime < GETDATE() - ?
Listing 31: DELETE tabJobRunLog.
4.5
ComponentService
Corp_JobMonitor benötigt Informationen bezüglich Komponenten von Corp_PadMan. Diese werden von
Corp_PadMan mit dem WCF-Service ComponentService zur Verfügung gestellt.
Der Webservice wird von Corp_JobMonitor täglich in der Nacht aufgerufen, damit die Komponenten aktualisiert
werden können. Vom Webservice werden sämtliche Komponenten sowie die verantwortlichen Personen erhalten. Diese werden in die in Abbildung 15 dargestellte Datenbank-Struktur eingefügt.
tabComponentPersonMapping
tabComponent
PK
ComponentId
InsertUser
InsertDate
UpdateUser
UpdateDate
PK
MappingId
FK1,I1
FK2,I2
FK3,I3
ComponentId
PersonId
TypeId
InsertUser
InsertDate
UpdateUser
UpdateDate
tabPerson
PK
PersonId
UserId
InsertUser
InsertDate
UpdateUser
UpdateDate
tabPersonType
PK
TypeId
KeyName
NameD
NameF
NameI
NameE
InsertUser
InsertDate
UpdateUser
UpdateDate
Abbildung 15: Datenbank-Teilmodell mit den Tabellen, welche von der Webservice-Interpretation tangiert sind.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
33/40
Projektname
Dokumenttitel
Artifaktname
5
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Beschreibung der Elemente
5.1
Ansicht JobList
Die Ansicht JobList ist der Einstiegspunkt in die Webapplikation Corp_JobMonitor. Sie zeige eine Liste von JobDefinitionen mit deren Namen, Komponenten, Status (Development, Integration und Production) sowie allfälliger
Fehlermassnahmen.
Die Ansicht JobList verfügt über mehrere Filtermöglichkeiten. Gefiltert werden kann nach:
Job Name
Komponente
Fehlerhaften Job-Runs sowie Job-Runs mit Warnungen
Nicht gefixte Job-Runs
Nicht zugeteilten Job-Definitionen (d.h., Job-Definitionen ohne Komponente)
Inaktiven Jobs
Obsolete Jobs
All diese Filter werden in Cookies gespeichert, so dass sie bei neuerlichem Laden der Seite gleich wieder aktiv
sein können.
Abbildung 16: Mockup Ansicht JobView.
Zusätzlich kann die Ansicht JobList mit URL-Parametern gesteuert resp. deren Inhalt vorgefiltert werden. Es bietet
sich schlussendlich an, diese Funktionalität gegebenenfalls auf einem (neuen) Entwickler-Portal anzubieten. Via
URL-Parameter kann folgendes vorgefiltert werden:
Zeige Job-Runs von heute (boolean -> ja/nein)
Zeige Job-Runs von gestern (boolean -> ja/nein)
Zeige alle Job-Definitionen (boolean -> ja/nein)
Zeige Job-Definitionen, bei deren Komponente der Benutzer Entwickler ist (boolean -> ja/nein)
Zeige Job-Definitionen, bei deren Komponente der Benutzer Stellvertreter ist (boolean -> ja/nein)
Beispiel:
.../JobList.aspx?ViewAll=false&ViewOwn=true&ViewStv=true&Today=true&Yesterday=true
Alle diese Filter, welche via URL-Parameter erhalten werden, können auf der Ansicht JobList verändert werden.
Gegenüber den „normalen“ Filter gelten die URL-Parameter-Filter nur Session-weit.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
34/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
5.2
Ansicht EditJob
Die Ansicht JobList enthält pro Job-Definition im GridView einen Button, mit welchem der Benutzer auf die Ansicht EditJob gelangt. In dieser Ansicht kann eine Job-Definition einer auf Corp_PadMan geladenen Komponente
zugewiesen werden.
Die Komponenten sind in der Webapplikation Corp_PadMan hierarchisch gespeichert und können dort nach den
Bedürfnissen der Entwickler gegliedert werden. Diese Hierarchie wird in Corp_JobMonitor derzeit nicht unterstützt. Sollte das Bedürfnis zu einem späteren Zeitpunkt dennoch bestehen, diese Funktionalität ebenfalls abzudecken, kann dies in Corp_JobMonitor erweitert werden.
Die Ansicht EditJob bietet des Weiteren analog dem bestehenden Tool im TeamPortal grosse Textfelder an, in
welchen der Benutzer eine Beschreibung, vorhandene Schnittstellen und Abhängigkeiten sowie allfällige Fehlermassnahmen pro Job-Definition dokumentieren kann.
Zuletzt sind auf der Ansicht EditJob in einem GridView alle Jobs zur Job-Definition aufgelistet. Dies können im
Minimum ein Job auf einem einzigen Environment oder maximal drei Jobs auf allen Environments (Development,
Integration, Production) sein. Hier lässt sich via CheckBox definieren, ob ein Job unbedingt laufen muss und falls
nicht, wer weiss was in Gang gesetzt werden muss. Diese CheckBox setzt und entfernt das MustRun-Bit in der
Tabelle tabJob. Dasselbe GridView enthält ReadOnly-Informationen wie Job-Name, Enabled, etc.
Die Abbildung 17 zeigt ein Mockup der Ansicht EditJob.
Abbildung 17: Mockup Ansicht EditJob.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
35/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
5.3
Ansicht ViewJobHistory
Die Ansicht ViewJobHistory erreicht der Benutzer mittels Klick auf eines der drei Environment-Status-Symbols auf
der Ansicht JobList (siehe Abbildung 16). Diese Ansicht zeigt sämtliche Job-Runs des selektierten Jobs.
Mit dem EnvironmentSwitcher oben rechts kann innerhalb des selektierten Jobs zwischen den Environments
gewechselt werden. Das Icon des aktuell selektierten Environments ist grösser dargestellt, im Mockup zu dieser
Ansicht (siehe Abbildung 18) ist es das rote – die Production.
Die Ansicht ViewJobHistory zeigt nebst der eigentlichen History wiederum eine kleine Übersicht über den Job
und deren verantwortlichen Personen, sofern eine Komponente zugeordnet wurde. Zu den Job-Details gehören
der Job-Name, die Komponente sowie verantwortlich Personen (Entwickler, Stellvertreter, Job- Verantwortlicher
und -Schreiber). Mittels Klick auf das E-Mail-Icon oder die E-Mail-Adresse lässt sich der entsprechenden Person
ein E-Mail schreiben, dazu wird mittels <a href=“mailto:...“ />-Tag ein Outlook-Fenster geöffnet.
Das History-GridView zeigt schlussendlich Informationen zu Job-Runs an:
Job-Name
Startzeitpunkt
Endzeitpunkt
Dauer in Sekunden
Status
Die Abbildung 18 zeigt ein Mockup der Ansicht ViewJobHistory.
Abbildung 18: Mockup Ansicht ViewJobHistory.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
36/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Ein Job-Run mit Fehler (Status-Icon = rot) oder Warnung (Status-Icon = gelb) kann mit der CheckBox rechts neben dem Status als erledigt markiert werden, sobald der Job-Run zu Ende analysiert und/oder gefixt wurde. Im
Footer des GridView (im Mockup nicht ersichtlich) befindet sich ein zusätzlicher Button, welcher für den selektierten Job im selektierten Environment das Flag „Erledigt“ aller Job-Runs mit Fehlern oder Warnungen auf true
setzt; eine sehr praktische Funktionalität, welche den bestehenden Applikationen stets gefehlt hatte.
5.4
Ansicht ViewJobRunDetail
Zuletzt gibt es noch die Ansicht ViewJobRunDetail, welche der Benutzer mit einem Klick auf den „View“-Button
auf der Ansicht ViewJobHistory erreicht. Diese Ansicht zeigt Detail-Informationen zu einem einzelnen Job-Run
an.
Dazu gehören:
Job Name
Startzeitpunkt
Endzeitpunkt
Dauer in Sekunden
Computername, auf welchem der Job-Run ausgeführt wurde
User-ID, womit der Job-Run ausgeführt wurde
Source ID – definiert den Job
Execution ID – definiert im SSIS Package Log den Job-Run
Direkt anschliessend folgen die Details zu den einzelnen Job-Step-Runs, dazu gehören:
Step-Nummer
Job Step Name
Startzeitpunkt
Endzeitpunkt
Dauer in Sekunden
Status – basierend auf den Logs des Job-Step-Runs
Schlussendlich beinhaltet die Ansicht ViewJobRunDetail die Logs – sowohl die SQL Server Agent Logs als auch
die SSIS Package Logs. Als geeignetste Darstellung für diese Daten hat die Tab-Struktur erwiesen. Nun gibt es in
dieser Ansicht stets ein Tab „Übersicht“, welches die SQL Server Agent Logs visualisiert. Für jeden Job-Step gibt
es dann ein weiteres Tab mit dessen SSIS Package Logs.
Die Log-Daten in allen Tabs werden aufgrund der Tatsache, dass Corp_JobMonitor zu den Logs nur eine ID
und den Status kennt, direkt auf den Quell-Datenbanken msdb sowie Corp_SysLog geladen. Für die SSIS Package Logs ist es daher wichtig, dass die Webapplikation Corp_JobMonitor die Möglichkeit hat, die Datenbank
Corp_SysLog auf unterschiedlichen Umgebungen (Development, Integration, Production) anzusprechen. Im
nachfolgenden Kapitel 5.5 wird dieses Vorgehen beschrieben.
Die Abbildung 19 zeigt ein Mockup der Ansicht ViewJobRunDetail.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
37/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
Abbildung 19: Mockup Ansicht ViewJobRunDetail.
5.5
Datenbank-Zugriff auf unterschiedliche Environments derselben Datenbank
Die Logs der SSIS-Packages sind – wie früher in diesem Dokument beschrieben – auf unterschiedlichen SQL Server Instanzen (Development, Integration, Production) gespeichert. Auf alle drei Environments muss aus derselben
Intranet-Applikation zugegriffen werden können.
SSIS Package Logs von Development-Jobs befinden sich auf der SQL Server Instanz serverdbdev01.
SSIS Package Logs von Integration-Jobs befinden sich auf der SQL Server Instanz serverdbint01.
SSIS Package Logs von Production-Jobs befinden sich auf der SQL Server Instanz serverdbprod01.
Mit dem Verwenden der Post.Lib erben eigene Konfigurations-Klassen grundsätzlich von der Lib-Klasse
Post.Lib.Data.NHibernate.Session.ManagerWebConfiguration. Werden nun drei verschiedene Connections benötigt, müssen auch drei Ableitungen dieser Klasse implementiert werden. Diese unterscheiden sich
lediglich im Aufbau des Connection-Strings, welcher wiederum mittels Post.Lib erhalten wird.
Listing 32, Listing 33 sowie Listing 34 zeigen den Code der entsprechenden Klassen im Namespace
Post.Appl.Corp.JobMonitor.DAL.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
38/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
public class SysLogDevManagerWebConfiguration : ManagerWebConfiguration
{
public override void Init()
{
base.Init();
ConnectionString = PwwDatabase.GetConnectionString(AppGlobal.Id,
"Corp_SysLog",
DBEnvironment.Development);
}
}
Listing 32: Klasse SysLogDevManagerWebConfiguration.
public class SysLogIntManagerWebConfiguration : ManagerWebConfiguration
{
public override void Init()
{
base.Init();
ConnectionString = PwwDatabase.GetConnectionString(AppGlobal.Id,
"Corp_SysLog",
DBEnvironment.Integration);
}
}
Listing 33: Klasse SysLogIntManagerWebConfiguration.
public class SysLogProdManagerWebConfiguration : ManagerWebConfiguration
{
public override void Init()
{
base.Init();
ConnectionString = PwwDatabase.GetConnectionString(AppGlobal.Id,
"Corp_SysLog",
DBEnvironment.Production);
}
}
Listing 34: Klasse SysLogProdManagerWebConfiguration.
5.5.1 Klasse JobMonitorProvider
Die Klasse JobMonitorProvider, über welche die NHibernate-Repositories bezogen werden, kann mit diesem
Konstrukt umgehen. Den Kontext selektiert man in diesem konkreten Fall mit der Methode
SysLogContext(Environment).
public class JobMonitorProvider : PostProvider
{
public IDbContext JobMonitorContext { get; private set; }
public IDbContext MsdbContext { get; private set; }
public IDbContext SysLogDevContext { get; private set; }
public IDbContext SysLogIntContext { get; private set; }
public IDbContext SysLogProdContext { get; private set; }
public IValidatorFactory ValidatorFactory { get; private set; }
public JobMonitorProvider(IConfigManager configManager,
IDbContext jobMonitorContext,
IDbContext msdbContext,
IDbContext sysLogDevContext,
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
39/40
Projektname
Dokumenttitel
Artifaktname
Corp_JobMonitor
Systemdesign Corp_JobMonitor
Systemdesign
Informationstechnologie
IDbContext sysLogIntContext,
IDbContext sysLogProdContext,
IValidatorFactory validatorFactory)
: base(configManager)
{
ConfigManager = configManager;
JobMonitorContext = jobMonitorContext;
MsdbContext = msdbContext;
SysLogDevContext = sysLogDevContext;
SysLogIntContext = sysLogIntContext;
SysLogProdContext = sysLogProdContext;
ValidatorFactory = validatorFactory;
}
public IDbContext SysLogContext(Environment environment)
{
if (AppGlobal.Production().Equals(environment))
{
return SysLogProdContext;
}
if (AppGlobal.Integration().Equals(environment))
{
return SysLogIntContext;
}
if (AppGlobal.Development().Equals(environment))
{
return SysLogDevContext;
}
return null;
}
}
Listing 35: Klasse JobMonitorProvider.
6
Anforderungszuordnung
Die Tabelle 15 listet die Anforderungszuordnung für Corp_JobMonitor auf.
Bezeichnung
J_UC_10
J_UC_20
J_UC_30
J_UC_40
J_UC_50
J_UC_60
Name
Jobs ansehen (Liste)
Job einer Komponente zuordnen
Job-Details editieren
Job-Runs ansehen (Liste)
Job-Run-Details ansehen
Fehlerhafter Job-Run als erledigt markieren
Kapitelzuordnung
Kapitel 5.1
Kapitel 5.2
Kapitel 5.2
Kapitel 5.3
Kapitel 5.4
Kapitel 5.3
Tabelle 15: Kapitelzuordnung der Use Cases aus dem Anforderungsdokument [01].
7
Sicherheit
Keine weiter führenden Angaben.
SD_JOBMON_Systemdesign_V01.04.docx
© Die Schweizerische Post
Ausgabedatum 28.03.2012
40/40
