Klein-Ridder / Barnstedt SharePoint 2019

Das Praxisbuch für Entwickler
1. Auflage 2019
ISBN: 978-3-8362-7082-3
Verlag: Rheinwerk
Format: EPUB
Kopierschutz: 0 - No protection

E-Book, Deutsch, 704 Seiten

Reihe: Rheinwerk Computing

Mit den Best Practices aus diesem Buch passen Sie SharePoint 2019 an Ihren Anforderungskatalog an und entwickeln maßgeschneiderte Lösungen. Viele Praxisbeispiele helfen Ihnen bei der Planung und ermöglichen es Ihnen, eine individuelle SharePoint-Anwendung zu entwickeln, die genau zu Ihrem Workflow passt.

Aus dem Inhalt:

• Infrastruktur planen
• Anwendungsstruktur
• Prozessbeschreibung
• Webparts
• Infrastruktur konfigurieren
• Website-Properties
• Konfigurationslisten
• Logging
• Change Requests
• Visual Studio Solution
• Datenstrukturen
• Feature Event Receiver
• Anwendungskonfiguration
• UI-Entwicklung
• Deployment
• PowerShell

Fabian Klein-Ridder ist seit 2004 in der SharePoint-Entwicklung tätig. Er arbeitet als Senior-SharePoint-Entwickler und Teamleiter der Software-Entwicklungsabteilung bei der amexus Informationstechnik GmbH und Co. KG. Darüber hinaus führt er individuelle Schulungen für Endanwender und Softwareentwickler zu SharePoint durch.

Autoren/Hrsg.

Klein-Ridder, Fabian

Barnstedt, Björn

Inhaltsverzeichnis

Danksagung ... 11  Vorwort ... 13

Teil I  Planung ... 17  1.  Planungsbeispiel ... 19  1.1 ... Einleitung ... 19  1.2 ... Infrastruktur ... 19  1.3 ... Anwendungsstruktur ... 21  1.4 ... Prozessbeschreibung ... 50  1.5 ... Ablaufpläne ... 78  1.6 ... WebParts ... 89  1.7 ... Weitere Anforderungen und Funktionen ... 96  1.8 ... Konfiguration ... 96  1.9 ... Berechtigungen ... 112  1.10 ... Oberfläche ... 120  1.11 ... Mehrsprachigkeit ... 132  1.12 ... Logging ... 135  1.13 ... Change Requests ... 136

Teil II  Umsetzung ... 139  2.  Entwicklungsumgebung ... 141  2.1 ... Web Essentials ... 142  2.2 ... ILMerge ... 143  2.3 ... SharePoint Manager ... 144  2.4 ... smtp4dev ... 145  2.5 ... SharePoint LogViewer ... 145  2.6 ... DebugView ... 146  2.7 ... Developer Dashboard ... 146  2.8 ... PowerGUI Script Editor ... 147  2.9 ... CAML Designer ... 148  2.10 ... Notepad++ ... 149  2.11 ... GetStrongName ... 150  2.12 ... Tipps ... 151  3.  Struktur der VS-Solution ... 153  3.1 ... Namespaces ... 160  3.2 ... Verzeichnisse ... 163  3.3 ... Features vorbereiten ... 169  4.  Basisfunktionen ... 173  4.1 ... Additional Page-Header ... 174  4.2 ... Logging ... 178  4.3 ... Mehrsprachigkeit ... 184  4.4 ... JavaScript global einbinden ... 188  4.5 ... JS from Codebehind ... 193  4.6 ... Projekttemplate erstellen ... 197  5.  Datenstruktur aufbauen ... 201  5.1 ... Spalten ... 202  5.2 ... Inhaltstypen ... 239  5.3 ... Listen und Bibliotheken ... 265  5.4 ... Ansichten ... 299  5.5 ... Archivstruktur ... 312  6.  Feature-EventReceiver ... 319  6.1 ... Nachschlagespalten ... 321  6.2 ... Abhängigkeiten zwischen Features ... 324  7.  Berechtigungsmodell ... 327  7.1 ... Stufen erstellen ... 330  7.2 ... Rollen anlegen ... 331  7.3 ... Berechtigungen zuordnen ... 332  8.  Ribbonsteuerung ... 335  8.1 ... Via »Elements.xml« ... 335  8.2 ... Via Code zur Laufzeit ... 347  9.  Anwendungskonfiguration ... 367  9.1 ... CustomAction-Links ... 367  9.2 ... Property Bag ... 375  9.3 ... ApplicationPage ... 380  9.4 ... Basiskonfiguration ... 397

10.  UI-Entwicklung ... 401  10.1 ... Vor- und Nachteile individueller Formulare ... 401  10.2 ... Eigene Formulare entwickeln und einbinden ... 403  10.3 ... Umsetzung Use Cases ... 434

11.  Umsetzung EventReceiver ... 449  11.1 ... Benutzerbenachrichtigungen ... 450  11.2 ... EMail-Versand ... 463

12.  Umsetzung Workflows ... 473  12.1 ... Workflow erstellen ... 474  12.2 ... EMail-Benachrichtigungen ... 477  12.3 ... Workflow Installation ... 482  12.4 ... Workflow starten ... 487

13.  Umsetzung TimerJobs ... 491  13.1 ... Konfiguration ... 492  13.2 ... Grundgerüst ... 508  13.3 ... Archivierungs-TimerJob ... 510  13.4 ... Eskalations-TimerJob und Erinnerungs-TimerJob ... 518  13.5 ... Report-TimerJob ... 521

14.  WebParts ... 525  14.1 ... Lösungssuche ... 526  14.2 ... Ticketauswertung ... 556  14.3 ... Abrechnung ... 570

15.  Anpassung der Navigation ... 597

16.  Aufbau der WebPart-Seiten ... 605

17.  Umsetzung des Brandings ... 611

18.  Deployment ... 619  18.1 ... Via PowerShell ... 619  18.2 ... Via Code (einen Installer entwickeln) ... 622

19.  Produktbesonderheiten ... 639  19.1 ... Releasezyklen ... 640  19.2 ... Lizenzierung ... 641

20.  Zusammenfassung ... 663  A.  SharePoint 2019 - Versionsunterschiede ... 664  B.  Berechtigungsstufen ... 672  C.  Ribbon-Location ... 679  Index ... 701

Leseproben

1.4    Prozessbeschreibung

Im Bereich der Prozessbeschreibungen sollten Sie alle geplanten Funktionen der Anwendung so genau wie möglich definieren. Am einfachsten beginnen Sie dazu mit der Definition von User Stories, in denen Sie die fachlichen Anforderungen zusammentragen. Aufbauend auf die User Stories und die verwendeten Objekte in der Anwendung können Use Cases erstellt werden. Mithilfe der Use Cases können die grundlegende Anwendungsstruktur, benötigte Trigger im UI und die Rollenzugehörigkeiten zum Auslösen der Trigger grafisch dargestellt werden.

Als letzten Schritt können Sie anhand der Use Cases die benötigten Programmablaufpläne erstellen.

Mit diesem Vorgehen hangeln Sie sich von einer sehr fachlichen und unscharfen Sicht auf die Anwendung in den User Stories über eine Funktions- und Rollenübersicht in den Use Cases hin zu einem hohen technischen Detailgrad in den Programmablaufplänen. Durch diese schrittweise Verfeinerung des Detailgrads nehmen Sie den Kunden von Anfang an mit, können ihm die fachlichen Wünsche entlocken und die technischen Anforderungen für die Umsetzung verdeutlichen. In keinem dieser Schritte ist technisches Know-how des Kunden erforderlich, und dennoch erhalten Sie im Anschluss ein Dokument, anhand dessen Ihnen jeder Entwickler ohne weitere Fragen die fertige Anwendung bauen kann.

Das Kapitel »Prozessbeschreibung« enthält alle fachlichen Anforderungen an die zu erstellende Anwendung und erläutert alle relevanten Objekte, wo diese im späteren UI zu finden sind und welche Rollenzugehörigkeit zum Aufrufen der jeweiligen Funktion erforderlich ist.

Dabei werden die fachlichen Anforderungen als User Stories definiert. Die entstandenen User Stories werden anhand von Use Cases mit den Objekten der Anwendung verknüpft, woraus grobe Vorgaben an das UI-Modell entstehen. Das bedeutet, dass an dieser Stelle definiert wird, welche Schaltflächen zum Aufrufen von Funktionen an welcher Stelle der Anwendung zur Verfügung stehen müssen. Zusätzlich werden die Berechtigungen der Benutzergruppen an die jeweiligen Use Cases geknüpft. Aufbauend auf die Use Cases werden die detaillierten Abläufe der Anwendung in Programmablaufplänen dargestellt.

1.4.1    User Stories

Um die fachlichen Anforderungen an eine Anwendung darzustellen, sind User Stories ein sehr gutes Hilfsmittel. Ohne die Notwendigkeit technischer Details schildert der Fachanwender die einzelnen Funktionen, die aus seiner Sicht für die Arbeit mit einer Anwendung notwendig sind. Dazu sollte jede Anforderung in einem oder zwei einfachen und möglichst präzisen Sätzen erläutert werden. Die technische Umsetzung ist dabei nicht von Belang. Es gilt lediglich, die Anforderung des Anwenders in Worte zu fassen. Aus jeder dieser User Stories ergibt sich im weiteren Verlauf das technische Design der Anwendung. Jede User Story wird auf technischer Ebene in eine oder mehrere Funktionen gekapselt und kann als einzelner Baustein in der Anwendung implementiert werden. Einzelne User Stories stellen somit in sich geschlossene, logische Arbeitspakete dar, nach deren Abarbeitung die Anwendung alle fachlichen Anforderungen des Benutzers erfüllen sollte.

Neben der Planung einer fachlich kompletten Anwendung stellen die einzelnen User Stories einen guten Grundstein für Anwendungstests im Bereich der Qualitätssicherung dar. Wird einer Person, der die fachlichen Anforderungen an die Anwendung nicht bekannt sind, die Liste der User Stories übergeben, kann sie trotzdem testen, ob die Anwendung alle an sie gestellten Anforderungen erfüllt. Die Summe der User Stories kann somit als Basis für einen Testkatalog betrachtet werden.

Achten Sie bei der Erstellung der User Stories darauf, dass der Anwender sich auf die Schilderung seiner Anforderung konzentriert und sich nicht von dem Versuch, technisch zu werden, ablenken lässt. Dem Aspekt der technischen Umsetzung wird im weiteren Verlauf Genüge getan, er würde in diesem Stadium lediglich von den fachlichen Anforderungen ablenken.

Nachfolgend werden die fachlichen Anforderungen an die Anwendung in den sogenannten User Stories zusammengefasst. Die Gesamtheit dieser User Stories stellt die zu erstellende Anwendung dar. Als User Story gelten Anforderungen an eine Softwareanwendung, die in einem, maximal zwei Sätzen beschrieben werden.

• Priorität erstellen
  Als Administrator oder Supportleiter möchte ich jederzeit neue Prioritäten für Tickets anlegen können.

• Priorität anzeigen
  Als Administrator oder Supportleiter möchte ich alle Prioritäten ansehen können.

• Priorität ändern
  Als Administrator oder Supportleiter möchte ich eine Priorität ändern können.

• Priorität löschen
  Als Administrator oder Supportleiter möchte ich eine bestehende Priorität löschen können.

• Ticketstatus erstellen
  Als Administrator oder Supportleiter möchte ich jederzeit neue Ticketstatus für Tickets anlegen können.

• Ticketstatus anzeigen
  Als Administrator oder Supportleiter möchte ich mir alle Ticketstatus ansehen können.

• Ticketstatus ändern
  Als Administrator oder Supportleiter möchte ich einen Ticketstatus ändern können.

• Ticketstatus löschen
  Als Administrator oder Supportleiter möchte ich einen bestehenden Ticketstatus löschen können.

• Ticket erstellen
  Als Kunde oder Supporter möchte ich ein neues Ticket in der Ticketliste erstellen können. Dabei muss ich den Betreff und eine Problembeschreibung angeben.

• Benachrichtigung neuer Tickets
  Als Supporter möchte ich automatisch über neue Tickets per E-Mail informiert werden.

• Ticket anzeigen
  Als Kunde möchte ich jederzeit meine Tickets einsehen können.

  Als Supporter möchte ich jederzeit alle für mich relevanten Tickets einsehen können.

• Ticket bearbeiten
  Als Administrator oder Supportleiter möchte ich bestehende Tickets bearbeiten können.

• Ticket löschen
  Als Administrator oder Supportleiter möchte ich bestehende Tickets löschen können.

• Ticket übernehmen
  Als Supporter möchte ich jederzeit ein nicht abgeschlossenes Ticket zur Bearbeitung übernehmen können.

• Ticket weiterleiten
  Als Supporter möchte ich jederzeit ein Ticket, das ich bearbeitet habe, an einen anderen Supporter weiterleiten können.

• Kommentar erstellen
  Als Supporter oder Kunde möchte ich jederzeit einen Kommentar zu einem bestehenden Ticket hinzufügen können.

  Wenn Bearbeitungszeiten angefallen sind, möchte ich diese gemeinsam mit einem Bearbeitungskommentar dem Ticket hinzufügen können.

• Kommentar bearbeiten
  Als Administrator oder Supportleiter möchte ich bestehende Kommentare zu Tickets bearbeiten können.

• Kommentar löschen
  Als Administrator oder Supportleiter möchte ich in der Lage sein, einen bestehenden Kommentar aus einem Ticket zu entfernen.

• Anhang hochladen
  Als Supporter oder Kunde möchte ich jederzeit einen Anhang zu einem bestehenden Ticket hochladen können.

  Alle hochgeladenen Anhänge zu einem Ticket sollen in diesem angezeigt werden.

• Ticket abschließen
  Als Supporter möchte ich die Möglichkeit haben, ein Ticket, das ich derzeit bearbeite, als abgeschlossen zu markieren.

• Benachrichtigung Ticketänderung
  Als Supporter oder Kunde möchte ich die Möglichkeit haben, über Änderungen an für mich relevanten Tickets per E-Mail informiert zu werden.

• Ticketerinnerung
  Als Supporter möchte ich per E-Mail an nicht bearbeitete Tickets erinnert werden.

• Ticket eskalieren
  Als Supportleiter möchte ich über die drohende Eskalation eines Tickets per E-Mail informiert werden.

...

Über Autor(innen)

Klein-Ridder, Fabian
Fabian Klein-Ridder ist seit 2004 in der SharePoint-Entwicklung tätig. Er arbeitet als Senior-SharePoint-Entwickler und Teamleiter der Software-Entwicklungsabteilung bei der amexus Informationstechnik GmbH und Co. KG. Darüber hinaus führt er individuelle Schulungen für Endanwender und Softwareentwickler zu SharePoint durch.

Barnstedt, Björn
Björn Barnstedt ist als Senior-SharePoint-Entwickler seit
vielen Jahren bei der amexus Informationstechnik GmbH und Co. KG tätig. Er leitet Softwareprojekte beim Kunden und führt Schulungen durch.