Freigeben über

OneDrive for Business Anpassung im SharePoint-Add-In-Modell

  • Artikel

Der Ansatz, den Sie verwenden, um OneDrive for Business Websites im neuen SharePoint-Add-In-Modell anzupassen, unterscheidet sich von dem mit voll vertrauenswürdigem Code. In einem typischen Szenario mit voll vertrauenswürdigem Code (Full Trust Code, FTC)/Farmlösung wurden Zeitgeberaufträge mit dem serverseitigen SharePoint-Objektmodell-Code erstellt, über Farmlösungen bereitgestellt und auf der SharePoint-Zentraladministrationswebsite verwaltet. SharePoint behandelt die Planung und Ausführung des Zeitgeberauftrags in diesem Szenario.

In einem SharePoint-Add-In-Modellszenario werden Zeitgeberaufträge außerhalb von SharePoint erstellt und geplant. SharePoint ist nicht für die Planung oder Ausführung des Zeitgeberauftrags in diesem Szenario verantwortlich.

Warum würden Sie OneDrive for Business Websites anpassen?

Es gibt zahlreiche verschiedene Aspekte beim Anwenden von Anpassungen auf OneDrive for Business -Websites (OD4B). Sie können diese Websites sicherlich anpassen, da es sich um SharePoint-Websites handelt, aber gleichzeitig sollten Sie immer die kurz- und langfristigen Auswirkungen der Anpassung berücksichtigen.

Allgemeine Richtlinien

Als Faustregel möchten wir die folgenden allgemeinen Richtlinien zum Anpassen von OD4B-Websites bereitstellen.

  • Anwenden der Brandinganpassung mit Office 365 Designs oder sharePoint-Websitedesign-Engine
  • Wenn Design-Engines nicht ausreichen, können Sie einige CSS-Einstellungen mithilfe einer alternativen CSS-Option anpassen.
  • Vermeiden Sie das Anpassen von OD4B-Websites mithilfe von benutzerdefinierten master Seiten, da dies bei zukünftigen Updates zu zusätzlichen langfristigen Kosten und Herausforderungen führt.
    • In den meisten Fällen können Sie alle gängigen Brandingszenarien mit Designs und alternativen CSS erreichen, daher ist dies nicht wirklich der begrenzende Faktor.
    • Wenn Sie sich für die Verwendung von benutzerdefinierten master Seiten entschieden haben, sollten Sie sich darauf vorbereiten, Änderungen auf die Websites anzuwenden, wenn wichtige funktionsbezogene Updates auf Office 365
  • Sie können die JavaScript-Einbettung verwenden, um funktionen in der Website zu ändern oder auszublenden.
  • Sie können CSOM verwenden, um beispielsweise Sprach- oder Regionseinstellungen in den OD4B-Websites zu steuern (siehe neue APIs).
  • Die Verwendung von Inhaltstypen und Websitespalten in OD4B-Websites wird nicht empfohlen, um Probleme mit den erforderlichen Feldern oder anderen Elementen zu vermeiden, die bei normalen Anwendungsfällen mit OD4B-Websites zu Problemen führen können.
    • Denken Sie an OD4B-Websites für personenbezogene unstrukturierte Daten und Dokumente. Teamwebsites und Zusammenarbeitssitze sind dann für Unternehmensdaten und -dokumente vorgesehen, bei denen Sie sicherlich die gewünschten Informationsverwaltungsrichtlinien und Metadaten verwenden können.

Zusammenfassend lässt sich sagen, dass die Anpassung in Office 365 definitiv unterstützt wird und Sie sie weiterhin mit OD4B-Websites verwenden können. Wir möchten nur sicherstellen, dass Sie die kurz- und langfristigen Auswirkungen der Anpassung aus Betriebs- und Wartungsperspektive berücksichtigen. Dies ist nicht wirklich spezifisch für SharePoint, sondern eine Faustregel für jeden IT-Lösungsbuild mit jeder Plattform.

Hier sehen Sie ein Beispiel für eine OD4B-Website, die mithilfe der oben genannten Richtlinien angepasst wurde. In diesem Fall wurde das Endergebnis mit einer Kombination aus Office 365 Designs, Websitedesign und Verwendung des so genannten JavaScript-Einbettungsmusters erzielt.

Eine Ansicht einer fertig gestellten benutzerdefinierten OD4B-Website.

Problem beim Anwenden von OneDrive for Business-Websiteanpassungen

Beginnen wir mit der Definition, was die Herausforderung ist und was wir hier zu lösen versuchen. Technisch gesehen verwendet jede OneDrive for Business Website derzeit dieselbe Architektur wie die persönlichen oder meine Websites, die in sharePoint 2007 oder 2010 verwendet wurden. Dies bedeutet, dass technisch gesehen jede OneDrive for Business Website eine eigene Websitesammlung ist und wir keinen zentralen Ort zum Anwenden von Branding oder anderen Anpassungen haben.

Problem beim Anwenden von OneDrive for Business-Websiteanpassungen

Die klassische Lösung zum Anwenden der erforderlichen Konfiguration auf die OneDrive for Business Websites (einschließlich meiner oder persönlicher Websites) basiert auf der Feature-Heftung auf Farmebene. Dies bedeutete, dass Sie eine Farmlösung für Ihre SharePoint-Farm bereitgestellt und das Featureframework verwendet haben, um Ihr benutzerdefiniertes Feature zuzuordnen, das jedes Mal aktiviert wird, wenn eine meine Website bewertet wird, die dann für die Anwendung der erforderlichen Anpassungen verantwortlich war. Dieser ähnliche Ansatz funktioniert in Office 365 nicht, da eine Farmlösung bereitgestellt werden muss und dies mit Office 365 Websites einfach nicht möglich ist. Daher müssen wir Alternativen suchen, um die erforderlichen Änderungen auf die Websites anzuwenden.

In Office 365 wird kein zentralisiertes Ereignis ausgelöst, an das wir unseren benutzerdefinierten Code anfügen können, wenn die OD4B-Website erstellt wird. Dies bedeutet, dass wir über alternative Lösungen nachdenken müssen, was bei App-Modellansätzen durchaus üblich ist. Bleiben Sie nicht bei alten Modellen hängen, denken Sie darüber nach, wie Sie mit neuen APIs und Technologien dasselbe Endergebnis erzielen können. Aus sicht der reinen Anforderung spielt es keine Rolle, wie wir die Anpassungen auf die Websites anwenden, solange sie angewendet werden. Da die Geschäftsanforderung nicht die Verwendung von Feature-Stapling ist, geht es darum, erforderliche Anpassungen mithilfe eines beliebigen unterstützten technischen Mechanismus anzuwenden.

Verschiedene Optionen zum Anwenden von Anpassungen

In der Praxis haben wir vier verschiedene Mechanismen, um die zentralisierte Anpassung auf OD4B-Websites im Office 365 anzuwenden. Sie könnten auch die manuelle Option als fünfte Option betrachten, aber im Fall von Hunderten oder Tausenden von OD4B-Websites ist die Verwendung manueller Optionen nicht wirklich eine realistische Option. Hier sind die verschiedenen Optionen, die wir haben.

  1. Einstellungen auf Ebene der Office 365-Suite (Office 365-Designs und andere Einstellungen)
  2. Ausgeblendetes App-Webpart mit Benutzerkontext
  3. Voraberstellen und Anwenden der Konfiguration
  4. Remotezeitgeberauftrag basierend auf Benutzerprofilaktualisierungen

Jede der Optionen hat Vor- und Nachteile, und die richtige Option hängt von Ihren detaillierten Geschäftsanforderungen ab. Einige der Einstellungen, die Sie auch von der Office 365 Suite-Ebene anwenden können, aber häufig würden Sie nach einigen weiteren Besonderheiten suchen, sodass tatsächliche Anpassungen erforderlich sind. Es kommt natürlich alles auf genaue Anforderungen und Business Case-Analysen auf deren Kurz- und Langfristigkeit an.

Einstellungen auf der Ebene der Office 365-Suite

Office 365 ist viel mehr als nur SharePoint, wie Sie wissen. Sie finden immer mehr zusätzliche Dienste, die nicht einmal auf der SharePoint-Architektur basieren, wie Delve, Yammer und viele bevorstehende Dienste. Dies bedeutet, dass es beim Branding und der Konfiguration des Unternehmens nicht nur darum geht, zu steuern, was wir auf den SharePoint-Websites haben, sondern dass wir uns gedanken über die allgemeine Endbenutzererfahrung und wie wir konsistente Konfigurationen über verschiedene Dienste hinweg bereitstellen.

Klassisches Beispiel für diese Unternehmensanforderungen ist Branding, und dafür haben wir bereits Office 365 Design eingeführt, das verwendet werden kann, um eine bestimmte Brandingebene zu steuern. Wir verfügen auch über weitere zukünftige Features, mit denen Sie Ihre Websitegovernance und andere Einstellungen von einem zentralen Standort außerhalb der Websitesammlungseinstellungen steuern können, z. B. das bevorstehende Compliance Center für Office 365, das derzeit in der Office 365 Roadmap aufgeführt ist.

Die folgende Abbildung zeigt die verschiedenen Einstellungen für die Office 365 Design, die dann für alle Office 365-Dienste angewendet werden.

Zeigt die Office 365 Website an, auf der die Registerkarte

Da Office 365 Designeinstellungen standardmäßig für die Steuerung der OD4B-Websitesammlungsleiste vorgesehen sind, verwenden Sie diese Optionen höchstwahrscheinlich zusammen mit anderen Optionen, um sicherzustellen, dass Sie mindestens die richtigen Brandingelemente für Ihre OD4B-Websites bereitstellen können. Beachten Sie, dass es ziemlich lange dauert, bis die Einstellungen für OD4B-Websites angewendet werden, wenn Sie z. B. Office 365 Designeinstellungen in Office 365 Administratortool ändern.

Ausgeblendetes App-Webpart mit Benutzerkontext

Dies ist ein Ansatz, bei dem eine zentrale Landing Page als Speicherort zum Starten des erforderlichen Anpassungsprozesses verwendet wird. Dies bedeutet, dass Sie über einen zentralen Ort verfügen müssten, z. B. die Intranet-Startseite des Unternehmens, auf der die Benutzer immer landen, wenn sie ihren Browser öffnen. Dies ist ein ziemlich typischer Prozess bei mittleren und größeren Unternehmen, bei dem die Unternehmenszielseite dann mithilfe von Gruppenrichtlinieneinstellungen im AD gesteuert wird. Dadurch wird sichergestellt, dass Endbenutzer die Standard-Willkommensseite der in die Unternehmensdomäne eingebundenen Browser nicht außer Kraft setzen können.

Wenn der Benutzer im Intranet eintrifft, wird der App-Teil auf der Seite ausgeblendet, wodurch der Anpassungsprozess gestartet wird. Es kann auch für die gesamte OD4B-Websiteerstellung verantwortlich sein, da der Benutzer normalerweise die OD4B-Website einmal besuchen muss, bevor der Websiteerstellungsprozess gestartet wird. Der ausgeblendete App-Teil hostet tatsächlich eine Seite der vom Anbieter gehosteten App, die in Azure gehostet wird. Diese Seite ist dann für das Starten des Anpassungsprozesses zuständig.

Sehen wir uns den logischen Entwurf dieses Ansatzes genauer an.

Diagramm zum Anzeigen von Beziehungen. Der App-Teil auf der SharePoint-Website verwendet instanziieren, um zu Vom Anbieter gehostete Apps zu wechseln. Vom Anbieter gehostete Apps verwendet Nachricht hinzufügen, um zur Speicherwarteschlange zu wechseln. Storage Queue verwendet instanziieren, um zu WebJob zu wechseln. WebJob verwendet Änderungen anwenden, um zur OD4B-Website zu wechseln.

  1. Platzieren Sie einen ausgeblendeten App-Teil auf einer zentralisierten Website, an der Endbenutzer landen werden. In der Regel ist dies die Titelseite des Unternehmensintranets.
  2. App-Teil hostet eine Seite der vom Anbieter gehosteten App, wobei wir im serverseitigen Code den Anpassungsprozess initiieren, indem wir der Azure Storage-Warteschlange erforderliche Metadaten hinzufügen. Dies bedeutet, dass diese Seite nur die Anpassungsanforderung empfängt, aber keine Änderungen tatsächlich anwendet, um die Verarbeitungszeit normal zu halten.
  3. Dies ist die tatsächliche Azure Storage-Warteschlange, die die Nachrichten empfängt, die zur Verarbeitung in die Warteschlange gestellt werden. Auf diese Weise können wir den Anpassungssteuerungsprozess asynchron verarbeiten, sodass es keine Rolle spielt, wie lange der Endbenutzer auf der Startseite des Intranets bleibt. Wenn der Anpassungsprozess synchron wäre, sind wir davon abhängig, dass der Endbenutzer den Browser auf der Intranet-Startseite geöffnet hält, bis die Seitenausführung abgeschlossen ist. Dies wäre nicht definitiv optimal und es war die Herausforderung mit dem ursprünglichen OD4B-Anpassungsprozess, den ich bloggt, als ich zurück war.
  4. WebJob ist so eingebunden, dass er der Speicherwarteschlange folgt, die aufgerufen wird, wenn ein neues Element in die Speicherwarteschlange eingefügt wird. Dieser WebJob empfängt die erforderlichen Parameter und Metadaten aus der Nachricht in der Warteschlange, um auf die richtige Websitesammlung zuzugreifen. WebJob verwendet nur App-Token und hat die erforderlichen Berechtigungen zum Bearbeiten von Websitesammlungen auf Mandantenebene erhalten.
  5. Tatsächliche Anpassungen werden einzeln auf die Websites der Personen angewendet, die die Intranet-Startseite besuchen, um den Prozess zu starten.

Dies ist definitiv der zuverlässigste Prozess, um sicherzustellen, dass die richtigen Konfigurationen in den OD4B-Standorten vorhanden sind. Sie können dem Prozess problemlos Eine Anpassungsversionslogik hinzufügen, bei der auch alle erforderlichen Updates auf die OD4B-Websites angewendet werden, wenn ein Update erforderlich ist und der Benutzer das nächste Mal die Intranet-Startseite besucht. Diese Option erfordert jedoch, dass Sie über den zentralen Ort verfügen, an dem Ihre Endbenutzer landen.

Wenn Sie mit klassischen SharePoint-Entwicklungsmodellen mit Farmlösungen vertraut sind, ist dies ähnlich wie die einmalige Ausführung von Zeitgeberaufträgen.

Voraberstellen und Anwenden der Konfiguration

Diese Option basiert auf der Voraberstellung der OD4B-Websites, bevor Benutzer darauf zugreifen. Dies kann mithilfe einer relativ neuen API erreicht werden, die es uns ermöglicht, OD4B-Websites für bestimmte Benutzer im Batchprozess zu erstellen, entweder mit CSOM oder REST. Der erforderliche Code kann mithilfe eines PowerShell-Skripts oder durch Schreiben von tatsächlichem Code initiiert werden, der die Remote-APIs aufruft.

Ein Administrator verwendet vorab erstellen und anpassen, um eine OD4B-Website zu erstellen.

  1. Der Administrator verwendet die Remoteerstellungs-APIs zum Erstellen von OD4B-Websites für Benutzer und wendet die erforderlichen Anpassungen im Rahmen des Skriptprozesses auf die OD4B-Websites an.
  2. Tatsächliche OD4B-Websites werden für die Office 365 für bestimmte Benutzer erstellt und ihren Benutzerprofilen zugeordnet.

In gewisser Weise ist dies auch ein wirklich zuverlässiger Prozess, aber Sie müssten neue Personen und Updates "manuell" verwalten, was mehr Arbeit bedeuten könnte als die Verwendung des versteckten App-Part-Ansatzes . Dies ist definitiv ein gültiger Ansatz, der verwendet werden kann und besonders nützlich ist, wenn Sie von einer anderen Dateifreigabelösung zu OD4B migrieren und vermeiden möchten, dass Endbenutzer einmal auf die OD4B-Website zugreifen müssen, bevor die eigentliche Websiteerstellung gestartet wird.

Remotezeitgeberauftrag basierend auf Benutzerprofilaktualisierungen

Dieser Ansatz umfasst das Durchsuchen von Benutzerprofilen, um zu überprüfen, an wen die OD4B-Website erstellt wurde, und die Änderungen dann bei Bedarf auf die Websites anzuwenden. Dies würde einen geplanten Auftrag bedeuten, der außerhalb von SharePoint ausgeführt wird, wodurch die status regelmäßig überprüft und die erforderlichen Anpassungen durchgeführt werden. Ein geplanter Auftrag kann als WebJob in Azure oder als einfaches PowerShell-Skript ausgeführt werden, das in Ihrem eigenen Windows-Scheduler geplant ist. Offensichtlich hat der Umfang der Bereitstellung große Auswirkungen auf die gewählte Planungsoption.

Ein Remote-Zeitgeberauftrag verwendet Die Schleife durch Websitesammlungen, um die einzelnen Websites anzupassen.

  1. Es wird eine geplante Aufgabe initiiert, die auf Benutzerprofile der Benutzer zugreift, um zu überprüfen, für wen die OD4B-Website bereitgestellt wurde.
  2. Die tatsächlichen Websites werden nacheinander basierend auf den Geschäftsanforderungen angepasst.

Einer der wichtigsten Nachteile dieser Option ist, dass es eindeutig Situationen geben kann, in denen Benutzer auf die OD4B-Websites zugreifen können, bevor die Anpassungen angewendet wurden. Gleichzeitig ist diese Option ein interessantes Add-On für andere Optionen, um sicherzustellen, dass Endbenutzer keine der erforderlichen Einstellungen auf den Websites geändert haben, oder um zu überprüfen, ob der OD4B-Websiteinhalt den Unternehmensrichtlinien entspricht.

Erweiterte App-Part-basierte Anpassung

Hier finden Sie eine ausführlichere Beschreibung der auf App-Teilen basierenden Anpassungen, die der typische Ansatz zum Anwenden und Verwalten der erforderlichen Anpassungen auf den OD4B-Websites zu sein scheint. Quellcode und zusätzliche Details zu dieser Lösung finden Sie im Leitfaden für Office 365 Entwicklermuster und -methoden.

Der tatsächliche logische Entwurf folgt dem Ansatz des ausgeblendeten App-Teils, der zuvor in diesem Blogbeitrag erwähnt wurde. Dies bedeutet, dass davon ausgegangen wird, dass Sie ein zentrales Intranet in der Office 365-Umgebung haben, in der Sie den erforderlichen App-Teil platzieren können, und dass die Endbenutzer auf diese Willkommensseite gelangen, wenn sie ihren Browser öffnen. Es ist üblich, dass jeder Unternehmensbrowser dieselbe Startseite mithilfe von Gruppenrichtlinien festgelegt hat, sodass Endbenutzer immer an einem zentralen Ort beginnen, wenn sie ihren Browser öffnen. Dies ist die Position, an der Sie das App-Teil platzieren würden. Die Größe kann auf 0 Pixel Breite und Höhe festgelegt werden. Der wichtigste Punkt ist, dass Sie den Endbenutzerkontext verwenden, um den App-Teil auszuführen, der die Seite des vom Anbieter gehosteten Add-Ins enthält.

Überlegungen zur Leistungsoptimierung und -wartung

Da dieser App-Teil jedes Mal ausgeführt wird, wenn der Benutzer zur Startseite des Intranets gelangt, müssen wir die Auswirkungen auf die Leistung berücksichtigen oder den Code so gestalten, dass er effizient funktioniert und nur dann wichtige Teile der Codeausführungen ausführt, wenn dies wirklich erforderlich ist. Die zweite Optimierungsüberlegung ist auch, wo wir die tatsächlichen Ressourcen platzieren, die an den einzelnen Standorten verwendet werden. Dies sind ziemlich typische Herausforderungen, die mit anpassungen bewältigt werden müssen. Hier finden Sie eine kurze Liste von Dingen, die sie bei App-Modellimplementierungen konzentrieren müssen.

  • Speicherort der Ressourcen – CDN-Lösung (Centralized Content Delivery Network) in jeder Websitesammlung oder in der Stammwebsitesammlung?
  • Aktualisierungsrate der Ressourcen oder wie kann sichergestellt werden, dass unabhängig von der clientseitigen Browserzwischenspeicherung sichergestellt werden kann, dass wir die neuesten Versionen der Skripts (JavaScript) ausführen oder die neuesten Versionen der Bilder anzeigen?
  • Reduzierte Ausführung von Code, um unnötige Last in Azure und Office 365 Dienst zu vermeiden
  • Versionsanpassungen, die auf die OD4B-Website angewendet werden

Speicherort der Ressourcen

Dafür gibt es einige unterschiedliche Lösungen. Im Referenzcodebeispiel verwenden wir die JavaScript-Einbettung in jede der OD4B-Websites, um eine Unternehmensrichtliniennachricht bereitzustellen und die Möglichkeit zu entfernen, Unterwebsites zu erstellen (oder den Link auszublenden). In dieser speziellen Lösung laden wir die erforderliche JavaScript-Datei in die Stammwebsitesammlung des OneDrive for Business Adressschemas hoch, und wir verweisen auf diese Datei direkt von diesem einen Speicherort in den einzelnen OD4B-Websites. Dies bedeutet, dass Sie nur über einen Speicherort zum Verwalten und Aktualisieren der JavaScript-Datei verfügen, wenn Änderungen erforderlich sind.

In dieser Referenzimplementierung aktualisieren wir diese Datei auch jedes Mal, wenn der WebJob ausgeführt wird, was sicherlich nicht benötigt wird, aber der Beispielcode sollte so einfach ohne zusätzliche Schritte und möglich funktionieren. Ebenso gut können Sie die JavaScript-Datei manuell in die Stammwebsitesammlung hochladen und dann von dort darauf verweisen. Eine alternative Lösung wäre auch die Verwendung eines CND zum Speichern der erforderlichen Datei oder verweisen auf JavaScript von der anbieterseitig gehosteten App. Solange Sie nur über eine Kopie der Datei verfügen, verfügen Sie über Folgendes:

Speicherort der Ressourcen

Herausforderung beim clientseitigen Zwischenspeichern und vorgehensweisen

Eine der Herausforderungen bei der JavaScript-basierten Implementierung ist das clientseitige Zwischenspeichern. Wenn Browser verwendete JavaScript-Dateien herunterladen, werden diese Dateien zwischengespeichert, um die Menge der heruntergeladenen Ressourcen für folgende Anforderungen zu reduzieren. Dies ist aus Sicht der Leistungsoptimierung hervorragend, führt aber zu einer Herausforderung, wenn wir die JavaScript-Datei aktualisieren müssen. Im schlimmsten Fall führt eine zwischengespeicherte JavaScript-Datei zu Ausnahmen mit anderen Updates, die mit aktualisierten Versionen eingeführt wurden.

Um dieses Problem zu beheben, können wir mit der Verwendung des Revisionsattributs mit JavaScript-URL-Verweis beginnen. Wenn wir der OD4B-Website eine benutzerdefinierte Benutzeraktion zuordnen, schließen wir die URL des JavaScript ein, um eine eindeutige GUID in der URL zu erhalten. Hier sehen Sie ein Beispiel für den Verweis, der auf die Stammwebsite der Websitesammlung verweist. Beachten Sie die zusätzliche GUID, die nach dem Rev-Attribut in der URL hinzugefügt wurde. Jedes Mal, wenn der Customizer für einen bestimmten OD4B-Standort ausgeführt wird, wird dieses Attribut aktualisiert. In der Praxis bedeutet dies, dass die JavaScript-Datei im Browser zwischengespeichert wird, bis eine neue Version zur OD4B-Website hinzugefügt wird, wodurch die URL geändert wird. Daher lädt der Browser die neue Version herunter und speichert diese nach dem nächsten Update zwischen.

  • /OneDriveCustomization/OneDriveConfiguration.js?rev=4bb89029e7ba470e893170d4cba7de00

Hier ist der Code, der zum Generieren der JavaScript-URL für die benutzerdefinierte Benutzeraktion verwendet wird.

/// <summary>
/// Just to build the JS path which can be then pointed to the OneDrive site.
/// </summary>
/// <returns></returns>
public string BuildJavaScriptUrl(string siteUrl)
{
    // Solve root site collection URL
    Uri url = new Uri(siteUrl);
    string scenarioUrl = String.Format("{0}://{1}:{2}/{3}", 
                            url.Scheme, url.DnsSafeHost, 
                            url.Port, JSLocationFolderName);
    // Unique rev generated each time JS is added, so that we force browsers to 
    // refresh JS file wiht latest version
    string revision = Guid.NewGuid().ToString().Replace("-", "");
    return string.Format("{0}/{1}?rev={2}", scenarioUrl, JSFileName, revision);
}

Reduzierte Ausführung von Code

Da dieser Prozess auf einem ausgeblendeten App-Teil auf der Startseite des Intranets basiert, bedeutet dies, dass der Code jedes Mal ausgeführt wird, wenn Benutzer ihren Browser aktualisieren oder zur Seite wechseln. Da diese Startseite häufig als Standardstartseite des Browsers für die Unternehmensbenutzer festgelegt wird, wird bei jedem Start einer Browsersitzung Code ausgeführt.

Da wir jedoch die Anpassungen, die häufig auf die OD4B-Websites angewendet werden, nicht aktualisieren, gibt es wirklich keinen Sinn, den gesamten Anpassungsaktualisierungsprozess an erster Stelle zu starten. Auf diese Weise reduzieren wir die Nutzung der Speicherwarteschlangen und die Ausführung von Webaufträgen, wodurch die Kosten aufseiten der vom Anbieter gehosteten App direkt reduziert werden, da wir nicht so viel CPU und andere Ressourcen in unserem Entwurf verwenden.

Die einfachste Möglichkeit, sicherzustellen, dass unsere Verarbeitung nicht in jeder Anforderung erfolgt, ist die Verwendung des klassischen Browser-Cookie-Ansatzes, bei dem wir bestimmte Cookies für den Clientbrowser mit einer bestimmten Lebensdauer speichern. Durch die Überprüfung dieses Cookie-Vorhandenseins können wir die Ausführung überspringen, bis das Cookie abgelaufen ist und wir die tatsächliche Anpassung status auf den OD4B-Websites erneut überprüfen.

Hier sehen Sie, was wir in der Seitenlademethode für das App-Teil haben. Dieser Methodenaufruf überprüft das Vorhandensein des Cookies, und wenn das Cookie vorhanden ist, überspringen wir den tatsächlichen Geschäftscode, bis die Ausführung erneut erforderlich ist.

// Check if we should skip this check. We do this only once per hour to avoid 
// perf issues and there's really no point even hitting the user profile 
// in every request.
if (CookieCheckSkip())
    return;

Die tatsächliche Cookie-status und Das Setzen des Cookies erfolgt wie folgt.

/// <summary>
/// Checks if we need to execute the code customization code again. 
/// Timer set to 60 minutes to avoid constant execution of the code for nothing.
/// </summary>
/// <returns></returns>
private bool CookieCheckSkip()
{
    // Get cookie from the current request.
    HttpCookie cookie = Request.Cookies.Get("OneDriveCustomizerCheck");

    // Check if cookie exists in the current request.
    if (cookie == null)
    {
        // Create cookie.
        cookie = new HttpCookie("OneDriveCustomizerCheck");
        // Set value of cookie to current date time.
        cookie.Value = DateTime.Now.ToString();
        // Set cookie to expire in 60 minutes.
        cookie.Expires = DateTime.Now.AddMinutes(60);
        // Insert the cookie in the current HttpResponse.
        Response.Cookies.Add(cookie);
        // Output debugging information
        WriteDebugInformationIfNeeded(
            string.Format(@"Cookie did not exist, adding new cookie with {0} 
                            as expiration. Execute code.",
                            cookie.Expires));
        // Since cookie did not existed, let's execute the code, 
        // so skip is false.
        return false;
    }
    else
    {
        // Output debugging information
        WriteDebugInformationIfNeeded(string.Format(@"Cookie did existed, 
                                    with {0} as expiration. Skipping code.", 
                                    cookie.Expires));
        //  Since cookie did existed, let's skip the code
        return true;
    }
}

Wenn Sie den Code auf der App-Teilseite genauer betrachten, sehen Sie, dass wir bei jedem Aufruf die Existenz der OD4B-Website für den Endbenutzer überprüfen. Da dies nur durch Zugriff auf das Benutzerprofil möglich ist, hat Code Auswirkungen auf die Leistung. Durch die Verwendung der oben genannten Cookie-Überprüfung können wir die Endbenutzererfahrung verbessern und vermeiden, dass der Benutzerprofildienst ständig ohne tatsächliche Anforderungen getroffen wird. Es ist auch gut zu beachten, dass wir diese Cookieüberprüfung als ersten Schritt in der Page_Load-Methode platziert haben, sodass wir bei Bedarf die gesamte Verarbeitung überspringen. Hier sehen Sie einen kurzen Codeausschnitt aus der Page_Load-Methode aus dem Customizer.aspx , um den Codeprozess anzuzeigen.

protected void Page_Load(object sender, EventArgs e)
{
    // Check if we should skip this check. We do this only once per hour to avoid 
    // perf issues and there's really no point even hitting the user profile 
    // in every request.
    if (CookieCheckSkip())
        return;
  
    var spContext = 
        SharePointContextProvider.Current.GetSharePointContext(Context);
    using (ClientContext clientContext = 
        spContext.CreateUserClientContextForSPHost())
    {
        // Get user profile
        ProfileLoader loader = ProfileLoader.GetProfileLoader(clientContext);
        UserProfile profile = loader.GetUserProfile();
        Microsoft.SharePoint.Client.Site personalSite = profile.PersonalSite;

        clientContext.Load(profile, prof => prof.AccountName);
        clientContext.Load(personalSite);
        clientContext.ExecuteQuery();

        // Let's check if the site already exists
        if (personalSite.ServerObjectIsNull.Value)
        {

Versionsanpassungen, die auf die OD4B-Website angewendet werden

Die zweite Optimierungsebene für unsere Codeverarbeitung erfolgt durch Versionsverwaltung speziell der Anpassungen, die wir auf den OD4B-Websites bereitstellen. Dies bedeutet, dass wir die Version der Anpassungen im OD4B-Websiteeigenschaftenbehälter speichern und die Dateien und Ressourcen nur bei Bedarf aktualisieren. Dies bedeutet, dass wir in der WebJob-Ausführung die aktuelle Anpassungsversion in OD4B mit der Version vergleichen, die wir bereitstellen möchten. Nur wenn die Anpassungsversion odes nicht auf der OD4B-Website vorhanden ist, laden wir die erforderlichen Ressourcen hoch und wenden andere Einstellungen an.

Durch diesen Ansatz werden auch die benötigten Ressourcen von Microsoft Azure erheblich reduziert, da wir das Aktualisieren oder Ausführen von tatsächlichem Anpassungscode vermeiden, wenn er nicht benötigt wird. Dies bedeutet eine Verringerung der CPU- und anderer Ressourcenauslastung in Microsoft Azure und weniger Anforderungen an Office 365.

Die gesamte Anpassungslogik in diesem Beispiel befindet sich in der ApplySiteConfiguration-Methode bei OD4B. Configuration.Async.Common.SiteModificationManager-Klasse . Diese Methode wird auch vom WebJob mit den richtigen Parametern aufgerufen, um den Anpassungsprozess zu starten. Bevor wir tatsächlich Vorgänge ausführen, überprüfen wir den Eigenschaftsbehälterwert mit dem Schlüssel "Contoso_OneDriveVersion", und die Ausführung wird nur fortgesetzt, wenn die aktuelle Version auf der Website niedriger ist als die Version, die wir anwenden möchten. Hier ist der tatsächliche Code, der die Office PnP Core-Komponente verwendet, um den Code zu vereinfachen.

// Check current site configuration status - is it already in right version?
if (ctx.Web.GetPropertyBagValueInt(
    SiteModificationManager.OneDriveMarkerBagID, 0) 
    < SiteModificationManager.BrandingVersion)
{

Wenn die Anpassung auf die Website angewendet wird, legen wir die angewendete Anpassungsversion für die folgende Ausführung auf den Eigenschaftenbehälter fest.

// Save current branding applied indicator to site
ctx.Web.SetPropertyBagValue(SiteModificationManager.OneDriveMarkerBagID, SiteModificationManager.BrandingVersion);

Dies ist ein relativ einfacher Prozess, reduziert jedoch die benötigten Ressourcen von Azure erheblich und reduziert auch nicht erforderliche Remotevorgänge in Richtung Office 365, was sich positiv auf die Leistung auswirken wird.

Erforderliche Konfiguration in Azure

Die wichtigste Voraussetzung für die ordnungsgemäße Funktionsweise dieses Beispiels besteht darin, dass Sie Azure Storage Data Service erstellt haben und die Speicherverbindungszeichenfolgen für die Projekte, die sie verwenden, entsprechend aktualisiert haben. Sie können einfach über das Azure-Verwaltungsportal (manage.windowssazure.com) als Speicherdienst erstellen, indem Sie Neu –> Datendienste –> Speicher –> Schnell Create auswählen. Danach müssen Sie nur den Namen, den Standort und einige andere Einstellungen definieren, und Sie können losgehen.

Quick Create Settings: The URL field is set to myveryownstorage, Location/Affinity group is set to USA, West, Subscription is set to MSDN Ultimate and Replication is set to Geo-Redundant.

Wenn Speicher erstellt wurde, müssen Sie den Schlüssel kopieren, der für die Verbindungszeichenfolge benötigt wird. Wenn Sie zur Seite mit den Speicherdetails wechseln, können Sie auf wichtige Informationen zugreifen, indem Sie unten auf der Seite auf "Zugriffsschlüssel verwalten" klicken.

Der Link zu

Sie müssen App.config Datei für die folgenden Projekte in der Visual Studio-Projektmappe aktualisieren. Jedes der Projekte wird später in diesem Blogbeitrag ausführlicher erläutert.

OD4B. Configuration.Async.WebJob OD4B. Das WebJob-Projekt Configuration.Async.Console.SendMessage verfügt über zwei Schlüssel, die aktualisiert werden können, um auf dieselbe Verbindung zu verweisen, und sendMessage hat nur einen Schlüssel, der aktualisiert werden muss.

Die App.config-Datei ist in Visual Studio im appSettings-Element geöffnet. Zwei untergeordnete Elemente mit dem Namen Add werden unter dem appSettings-Element aufgeführt. Für das erste Add-Element sind das Attribut key=ClientId und das Value-Attribut gleich einem Paar doppelter Anführungszeichen. Für das zweite Add-Element sind das Attribut key=ClientSecret und das Value-Attribut gleich einem Paar doppelter Anführungszeichen.

Referenzlösungsstruktur

Diese Visual Studio-Projektmappe besteht aus einer Reihe von Projektmappen, aber jede von ihnen hat einen ziemlich vernünftigen Grund, dabei zu sein. Hier finden Sie eine Einführung in die einzelnen Projekte in der Projektmappe und warum sie vorhanden sind oder wozu sie dienen.

Die Projektmappen-Explorer zeigt einen Ordner mit dem Namen Dokumentation an, gefolgt von sechs Projekten, die unten ausführlich beschrieben werden.

OD4B.Configuration.Async

Dies ist das eigentliche SharePoint-App-Projekt, das die vom Anbieter gehostete App in SharePoint einführt und die erforderlichen Berechtigungen anfragt. Beachten Sie, dass wir zwar keine Vorgänge auf Mandantenebene aus dem App-Teil selbst ausführen, aber ziemlich hohe Berechtigungen für das Add-In anfordern. Dies liegt daran, dass wir die gleiche Client-ID und den gleichen geheimen Schlüssel aus dieser App-Datei in unserer WebJob-Ausführung verwenden. Bei diesem Ansatz müssen Sie die App-ID und das Geheimnis nicht manuell für SharePoint registrieren, sondern nur den gleichen Bezeichner und die gleiche geheimnisübergreifende Lösung verwenden.

Die Liste der Berechtigungen: Der Bereich Mandant verfügt über die Berechtigung FullControl. Der Bereich Benutzerprofile (Soziale Netzwerke) verfügt über die Berechtigung FullControl. Das Kontrollkästchen Zulassen, dass die App nur App-Aufrufe an SharePoint durchführt, ist aktiviert.

Dieses Projekt enthält auch die App-Partdefinition, die dann im Hostweb bereitgestellt wird.

OD4B. Configuration.Async.Common

Dieses Projekt enthält alle tatsächlichen Geschäftslogik- und freigegebenen Codeübergreifende Projekte, z. B. die Definition für das Datenobjekt, das in der Speicherwarteschlange platziert wird, und die tatsächliche Geschäftslogik zum Anpassen von OD4B-Websites. Der Grund, Code hier einzugeben, ist einfach, dass wir einfachere Möglichkeiten zum Entwickeln und Testen der Vorgänge bieten, wenn das Projekt erstellt wird. Wie bei der allgemeinen Entwicklung sollten Sie Ihren Geschäftslogikcode nicht wirklich direkt in den WebJob oder in den App-Teil platzieren, sondern diesen in der Geschäftslogikebene finden, um tests und codeverwenden zu können.

Alle tatsächlichen Vorgänge zu den OD4B-Standorten befinden sich in OD4B. Configuration.Async.Common.SiteModificationManager-Klasse .

OD4B. Configuration.Async.Console.Reset

Dieses Projekt ist unser Test- und Debugprojekt für die tatsächlichen Anpassungen. Es kann verwendet werden, um die gewünschten Anpassungen manuell auf eine beliebige OD4B-Website anzuwenden. Während der Entwicklungszeit war dieses Projekt unser Testprojekt, um den Anpassungsprozess zu testen, bevor es mit dem WebJob eingebunden wurde. Project kann auch verwendet werden, um Anpassungen von jeder OD4B-Website zu Demonstrations- oder Testzwecken zurückzusetzen. Da sich die tatsächliche Geschäftslogik im gemeinsamen Projekt befindet, verwendet dieses Projekt dieselbe SiteModificationManager-Klasse wie die anderen, um Anpassungen von den Websites anzuwenden oder zurückzusetzen.

Wenn Sie die Anpassungen testen, können Sie einfach den Code in der Main-Methode zwischen Apply und Reset ändern, um den gewünschten Vorgang zu ändern.

static void Main(string[] args)
{
  
    Uri url = 
        new Uri("https://vesaj-my.sharepoint.com/personal/vesaj_veskuonline_com");
  
        //get the new site collection
    string realm = TokenHelper.GetRealmFromTargetUrl(url);
    var token = TokenHelper.GetAppOnlyAccessToken(
                    TokenHelper.SharePointPrincipal, 
                    url.Authority, realm).AccessToken;
    using (var ctx = 
        TokenHelper.GetClientContextWithAccessToken(url.ToString(), 
        token))
    {
        // Uncomment the one you need for testing/reset
        // Apply(ctx, url);
        Reset(ctx);
    }
}

Beachten Sie, dass Sie sicherstellen müssen, dass die App-ID und das Geheimnis für dieses Projekt im app.config mit denen übereinstimmen, die Sie Ihrem Mandanten die erforderlichen Berechtigungen erteilt haben. Sie können das Projekt ganz einfach ausführen, indem Sie mit der rechten Maustaste auf das Projekt klicken und Debuggen – Neue Instanz starten auswählen, damit Sie den tatsächlichen Code, der Zeile für Zeile ausgeführt wird, durchlaufen können.

OD4B. Configuration.Async.Console.SendMessage

Dieses Projekt wurde der Projektmappe hinzugefügt, um den Speicherwarteschlangenmechanismus zu testen, bevor er mit dem App-Teil eingebunden wurde. Project kann verwendet werden, indem der App-Partprozess zum Hinzufügen neuer Nachrichten zur Speicherwarteschlange übergeben wird. Beachten Sie, dass Sie die Speicherwarteschlange Verbindungszeichenfolge im app.config entsprechend aktualisieren müssen, damit das Projekt ordnungsgemäß funktioniert.

Sie können das Projekt ganz einfach ausführen, indem Sie mit der rechten Maustaste auf das Projekt klicken und Debuggen – Neue Instanz starten auswählen, damit Sie den tatsächlichen Code, der Zeile für Zeile ausgeführt wird, durchlaufen können.

OD4B. Configuration.Async.WebJob

Dies ist das eigentliche WebJob-Projekt, das mithilfe der WebJob-Projektvorlage erstellt wurde, die im Visual Studio 2013 Update 4 eingeführt wurde. Diese Vorlage erleichtert das Erstellen von WebJob-Projekten, indem richtige Verweise direkt hinzugefügt werden, und sie bietet außerdem eine ansprechende Bereitstellungsautomatisierung mit Rechtsklickunterstützung für das Projekt. Sie können einfach die erste Version oder neue Version des Projekts in Azure bereitstellen, indem Sie mit der rechten Maustaste klicken und als Azure-Webauftrag veröffentlichen... auswählen. dadurch wird der Veröffentlichungs-Assistent geöffnet.

Das Dialogfeld Web veröffentlichen wird angezeigt, und die Registerkarte Verbindung wird angezeigt. Das Feld Server enthält den Wert vesaj-od4bconf.scm.azurewebsites.net:443, das Feld Standortname enthält den Wert vesaj-0d4bconf, das Feld Benutzername ist redigiert, das Feld Kennwort ist maskiert, das Kontrollkästchen Kennwort speichern ist aktiviert, und das Feld Ziel-URL enthält den Wert. http://vesaj-od4bconf.azurewebsites.net.

Dieser WebJob wird als fortlaufender WebJob erstellt, der für die warteschlangenbasierte Verarbeitung benötigt wird. Dies bedeutet, dass in der Main-Methode nur festgelegt wird, dass der Prozess wie folgt fortlaufend ausgeführt wird.

class Program
{
    // Please set the following connection strings in app.config for this 
    // WebJob to run: AzureWebJobsDashboard and AzureWebJobsStorage
    static void Main()
    {
        var host = new JobHost();
        // The following code ensures that the WebJob will be 
        // running continuously
        host.RunAndBlock();
    }
}

Die tatsächliche Warteschlangenverarbeitung ist mit WebJobs sehr einfach. Wir müssen nur die richtigen Attribute für die -Methode festlegen und sicherstellen, dass die Azure Storage-Verbindungszeichenfolgen in der App-Konfiguration entsprechend aktualisiert werden und den Von Ihnen erstellten Speicherwarteschlangen für Microsoft Azure entsprechen. Es folgt die ProcessQueueMessage-Methode aus der klasse functions.cs. Beachten Sie, dass wir das Tokenmodell Nur App verwenden, um über den WebJob auf SharePoint zuzugreifen. Damit dies funktioniert, müssen Sie sicherstellen, dass Sie die richtige App-ID und das geheimnis in die app.config des Projekts kopiert haben. Die tatsächliche Geschäftslogik befindet sich in der SiteModificationManager-Klasse , daher rufen wir sie einfach mit dem richtigen Clientkontext und den richtigen Parametern auf.

// This function will get triggered/executed when a new message is written 
// on an Azure Queue called queue.
public static void ProcessQueueMessage(
    [QueueTrigger(SiteModificationManager.StorageQueueName)] 
    SiteModificationData request, TextWriter log)
{
    Uri url = new Uri(request.SiteUrl);
  
    //Connect to the OD4B site sing App Only access
    string realm = TokenHelper.GetRealmFromTargetUrl(url);
    var token = TokenHelper.GetAppOnlyAccessToken(
        TokenHelper.SharePointPrincipal, url.Authority, realm).AccessToken;

    using (var ctx = TokenHelper.GetClientContextWithAccessToken(
        url.ToString(), token))
    {
        // Set configuration object properly for setting the config
        SiteModificationConfig config = new SiteModificationConfig()
        {
            SiteUrl = url.ToString(),
            JSFile = Path.Combine(Environment.GetEnvironmentVariable
                ("WEBROOT_PATH"), "Resources\\OneDriveConfiguration.js"),
            ThemeName = "Garage",
            ThemeColorFile = Path.Combine(Environment.GetEnvironmentVariable
                ("WEBROOT_PATH"), "Resources\\Themes\\Garage\\garagewhite.spcolor"),
            ThemeBGFile = Path.Combine(Environment.GetEnvironmentVariable
                ("WEBROOT_PATH"), "Resources\\Themes\\Garage\\garagebg.jpg"),
            ThemeFontFile = "" // Ignored in this case, but could be also obviously set
        };

        new SiteModificationManager().ApplySiteConfiguration(ctx, config);
    }
}

Beachten Sie auch, dass Sie sicherstellen müssen, dass Sie die Eigenschaft Lokal kopieren für die SharePoint CSOM-Assemblyverweise-Eigenschaft für das Projekt festgelegt haben, damit alle abhängigen Assemblys ordnungsgemäß nach Azure kopiert werden, wenn Sie den Webauftrag bereitstellen. Dies liegt einfach daran, dass sich diese Assemblys standardmäßig nicht auf der normalen Azure-Website befinden. Wenn Sie also diese Eigenschaft True festlegen, stellen Sie sicher, dass die Assemblys, auf die verwiesen wird, auch in die Cloud kopiert werden.

OD4B. Configuration.AsyncWeb

Dies ist die tatsächliche vom Anbieter gehostete App, die in Microsoft Azure gehostet wird. Sie enthält die Seite, die auf den App-Teil auf der Startseite des Intranets abgelegt wird. Default.aspx Seite dieser App keine Vorgänge enthält, enthält sie Details zur Verwendung der App.

Bemerken. Wenn beim WebJob- oder App-Zugriff im Allgemeinen Probleme mit der Berechtigungsverweigerung auftreten, stellen Sie sicher, dass Sie die App-Client-ID und den geheimen Schlüssel im app.config aktualisiert haben, damit sie mit den Werten im web.config dieses Projekts übereinstimmen. Visual Studio kann diese Werte in bestimmten Szenarien ändern.

Warteschlangenverarbeitung in WebJob

Die Verwendung der Speicherwarteschlangen ist mit den in Azure verfügbaren APIs wirklich einfach. Die einfachste Möglichkeit für den Einstieg ist die Verwendung des NuGet-Pakets "Windows Azure Storage", das Ihrem Projekt alle erforderlichen APIs und anderen Pakete zuordnet. Nachdem Sie dieses NuGet-Paket hinzugefügt haben, können Sie einfach mit der Verwendung der Speicherwarteschlangen-APIs für die Verarbeitung beginnen. Es folgt ein Codeausschnitt aus dem OD4B. Configuration.Async.Common-Projekt (AddConfigRequestToQueue-Methode in der SiteModificationManager-Klasse), das tatsächlichen Code für die Verarbeitung von Warteschlangennachrichten enthält und aus zahlreichen Projekten verwendet wird (für einfacheres Debuggen bei der Entwicklung).

public void AddConfigRequestToQueue(
            string account, string siteUrl, string storageConnectionString)
{
    CloudStorageAccount storageAccount = 
                        CloudStorageAccount.Parse(storageConnectionString);
  
    // Get queue... create if does not exist.
    CloudQueueClient queueClient = storageAccount.CreateCloudQueueClient();
    CloudQueue queue = 
        queueClient.GetQueueReference(SiteModificationManager.StorageQueueName);
    queue.CreateIfNotExists();

    // Pass in data for modification
    var newSiteConfigRequest = new SiteModificationData()
    {
        AccountId = account,
        SiteUrl = siteUrl
    };

    // Add entry to queue
    queue.AddMessage(
        new CloudQueueMessage(
            JsonConvert.SerializeObject(newSiteConfigRequest)));
}

Die tatsächliche Warteschlangenverarbeitung wurde in diesem Fall mit dem WebJob-Projekt durchgeführt. Im Fall von WebJob können wir einfach bestimmte Attribute verwenden, um die Warteschlangenverarbeitung zu automatisieren. Wir müssen nur sicherstellen, dass wir denselben Speicher- Verbindungszeichenfolge und Warteschlangennamen sowohl beim Senden als auch beim Empfangen von Teilen verwenden.

// This function will get triggered/executed when a new message is written 
// on an Azure Queue called queue.
public static void ProcessQueueMessage(
    [QueueTrigger(SiteModificationManager.StorageQueueName)] 
    SiteModificationData request, TextWriter log)
{
    Uri url = new Uri(request.SiteUrl);

Es wird wirklich nicht einfacher als das. Beachten Sie, dass siteModificationManager.StorageQueueName auf beiden Seiten verwendet wird, um sicherzustellen, dass der Warteschlangenname übereinstimmt.

Anwenden tatsächlicher Konfigurationen auf den Standort

In diesen Referenzimplementierungen führen wir die folgenden Anpassungen an den einzelnen OD4B-Websites durch.

  • Hinzufügen einer Unternehmensrichtliniennachricht, die ständig auf den OD4B-Websites angezeigt wird
  • Option "Unterwebsitelink erstellen" auf der Websiteinhaltsseite ausblenden
  • Anwenden eines benutzerdefinierten Designs auf die OD4B-Website, um dem Unternehmensbranding zu entsprechen

Die Unternehmensrichtlinie und das Ausblenden des Links zum Erstellen einer Unterwebsite werden mithilfe eines so genannten JavaScript-Einbettungsmusters erreicht, bei dem wir der Websiteebene eine benutzerdefinierte Benutzeraktion mit Verweis auf eine bestimmte JavaScript-Datei hinzufügen, die dann in jeder Seitenanforderung ausgeführt wird. Dies bedeutet, dass wir die Seitenverarbeitung mithilfe clientseitiger Technologien steuern können, indem wir beliebige Elemente auf einer beliebigen Seite hinzufügen, entfernen oder aktualisieren. Bei diesem Ansatz müssen wir keine benutzerdefinierte master-Seite einführen, was zu erheblichen langfristigen Wartungskosten führen kann, insbesondere wenn die erforderlichen Änderungen ziemlich gering sind.

Der zweite Vorgang mit den benutzerdefinierten Designs erfordert, dass wir einige zusätzliche Dateien auf die Website hochladen und diese dann als Designeinstellungen festlegen. Wir verwenden ausschließlich CSOM, um alle erforderlichen Dateien auf die Websites hochzuladen, um zukünftige Komplikationen mit Featureframeworkelementzuordnungen zu vermeiden. Da das Hochladen einer Datei in SharePoint mit dem CSOM wirklich einfach ist, ist dies definitiv die einfachste Möglichkeit, die Automatisierung durchzuführen, und Sie müssen sich keine Gedanken über xml-spezifische Konfigurationen abhängigkeiten von Sandboxlösungen machen. Hier sehen Sie die tatsächliche Standortkonfigurationsmethode von OD4B. Configuration.Async.Common.SiteModificationManager-Klasse. Beachten Sie, dass wir die PnP-Kernkomponente Office 365 Developer verwenden, um einige der erforderlichen Vorgänge zu vereinfachen.

Es ist auch gut zu beachten, dass wir tatsächlich bei jeder Anpassung der persönlichen OD4B-Website eine neue Version von JS in die Stammwebsitesammlung hochladen. Dies ist definitiv nicht die optimale Lösung, sondern aus Gründen der Einfachheit für diese Referenzlösung. Sie können diesen JavaScript-Dateiuploadvorgang zum App Installed-Ereignis hinzufügen, sodass er nur einmal ausgeführt wird, wenn die App installiert wird. In diesem Fall müssen Sie jedoch zusätzliche Arbeit mit allen Updates für diese JS-Datei ausführen.

// This function will get triggered/executed when a new message is written 
// on an Azure Queue called queue.
public static void ProcessQueueMessage(
    [QueueTrigger(SiteModificationManager.StorageQueueName)] 
    SiteModificationData request, TextWriter log)
{
    Uri url = new Uri(request.SiteUrl);
  
    //Connect to the OD4B site using App Only token
    string realm = TokenHelper.GetRealmFromTargetUrl(url);
    var token = TokenHelper.GetAppOnlyAccessToken(
        TokenHelper.SharePointPrincipal, url.Authority, realm).AccessToken;

    using (var ctx = TokenHelper.GetClientContextWithAccessToken(
        url.ToString(), token))
    {
        // Set configuration object properly for setting the config
        SiteModificationConfig config = new SiteModificationConfig()
        {
            SiteUrl = url.ToString(),
            JSFile = Path.Combine(Environment.GetEnvironmentVariable
                ("WEBROOT_PATH"), "Resources\\OneDriveConfiguration.js"),
            ThemeName = "Garage",
            ThemeColorFile = 
                Path.Combine(Environment.GetEnvironmentVariable
                ("WEBROOT_PATH"), "Resources\\Themes\\Garage\\garagewhite.spcolor"),
            ThemeBGFile = 
                Path.Combine(Environment.GetEnvironmentVariable
                ("WEBROOT_PATH"), "Resources\\Themes\\Garage\\garagebg.jpg"),
            ThemeFontFile = "" // Ignored in this case, but could be also set
        };

        new SiteModificationManager().ApplySiteConfiguration(ctx, config);
    }
}

Offensichtlich hängen die erforderlichen Vorgänge stark von Ihren Geschäftlichen Anforderungen ab. Sie können mehrere verschiedene Muster und Ansätze mit CSOM-basierten Vorgängen in den Office 365 Developer Patterns and Practices finden.

Zusätzliche Hinweise zu WebJob-basierten Lösungen

Hier sind einige zusätzliche Hinweise zur WebJob-Entwicklung in Azure. Dies ist eine äußerst leistungsstarke Technik, die auf jeden Fall weit Office 365 Anpassungen verwendet wird. Sie werden sicherlich sehen, dass neue und erweiterte Lösungen, die auf der WebJob-Technologie basieren, auch dem programm Office 365 Developer Patterns & Practices hinzugefügt werden.

Debuggen von WebJobs und Anpassungsprozess

Eine der bewährten Methoden für Ihren Code im Allgemeinen besteht darin, die tatsächlichen Vorgänge außerhalb des eigentlichen, endgültigen Ausführungsprozesses zu lokalisieren, sodass Sie sich zunächst einfach auf das Testen des benötigten Codes konzentrieren können, indem Sie einfach eine Konsolenanwendung verwenden oder z. B. testprojekte in Visual Studio verwenden. Auf diese Weise können Sie sicherstellen, dass die tatsächliche Geschäftslogik vollständig funktionsfähig ist, bevor Sie sie tatsächlich mit dem endgültigen Prozess verbinden, in diesem Fall den WebJob. In diesem Referenzlösungsfall haben wir den gesamten Geschäftscode in OD4B platziert. Die Configuration.Async.Common.SiteModificationManager-Klasse wird von zahlreichen Standorten aufgerufen.

Dies bedeutete, dass wir während der Entwicklungszeit OD4B verwenden konnten. Configuration.Async.Console.Reset-Konsolenanwendung, um die Anpassungen so oft wie nötig von den Standorten zu testen und zurückzusetzen, um sicherzustellen, dass die Geschäftslogik vollständig solide ist. Dies hat wirklich nichts mit dem SharePoint-Add-In-Modell oder der Azure-Entwicklung zu tun, sondern mit praktischen Schritt-für-Schritt-Entwicklungsmethoden, unabhängig davon, welche Technologie Sie verwenden. In Zeiten, als ich in der MCM für SharePoint-Zertifizierungsschulung war, habe ich dies als die NKOTB-Methode bezeichnet, aber das ist nicht wirklich eine Branchenstandard-Terminologie :-)

Eine der großen Verbesserungen aus der Debugperspektive für die WebJobs wurde in Visual Studio 2014 Update 4 eingeführt. Mit den neu eingeführten Azure-Verbindungen und -Projektvorlagen können Sie tatsächlich Remotedebuggen mit WebJob ausführen, der auf Azure-Seite ausgeführt wird. Sie müssen den WebJob in Azure bereitstellen. Anschließend können Sie die Debugsitzung starten, indem Sie im Server-Explorer mit der rechten Maustaste auf WebJob instance klicken und im Kontextmenü Debugger anfügen auswählen.

Der Server Explorer die geschachtelten Objekte Websites, vesaj-od4bconf, WebJobs, Continuous, OD4BConfigurationAsyncWebJob erweitert. Über OD4BConfigurationAsyncWebJob wird ein Kontextmenü angezeigt, und die Kontextmenüoption Debugger anfügen ist hervorgehoben.

Es gibt sogar einen Tester für das Senden richtig formatierter Nachrichten an die Warteschlange in der Referenzlösung. OD4B. Das Projekt Configuration.Async.Console.SendMessage wurde einfach erstellt, um die Möglichkeit zu haben, den WebJob-Prozess zu debuggen, ohne gezwungen zu werden, den App-Teil an einer beliebigen Stelle bereitzustellen. Dies kam beim Debuggen und Testen des gesamten Prozesses schritt für Schritt wieder zurück.

WebJob-Umgebungsvariablen

Eines der interessanten Dinge an den WebJobs ist, dass sie unter einer Azure-Website ausgeführt werden, aber ihr Ausführungsspeicherort unterscheidet sich geringfügig von normalen Websites in Azure. Wenn Sie zusätzliche Dateien oder Ressourcen zusammen mit dem WebJob in Azure bereitstellen, kann es zu Herausforderungen kommen, wenn Sie davon ausgehen, dass Sie direkt auf diese Ressourcen mit klassischen relativen Pfaden im WebJob-Code verweisen können.

In diesem Fall hatten wir eine JavaScript-Datei und einige Dateien für das benutzerdefinierte Design, die auf der Azure-Website bereitgestellt wurden, damit sie bei Bedarf auf die SharePoint-Websites hochgeladen werden konnten. Sie können diese Dateien in Azure sehen, wenn Sie den Branch Dateien unter einer bestimmten Website erweitern.

Der Server Explorer die geschachtelten Objekte Websites, vesaj-od4bconf, Dateien, Ressourcen, Designs, Garage und zeigt Dateien im Ordner Garage an.

In der Regel können Sie auf Azure-Websites mithilfe des folgenden Formats auf diese Dateien verweisen.

string path = HostingEnvironment.MapPath(
    string.Format("~/{0}", "Resources/OneDriveConfiguration.js"));

Da WebJobs jedoch an einem anderen Speicherort und nicht im Kontext von IIS ausgeführt werden, würde der obige Verweis auf die Datei nicht funktionieren, da die Zuordnung aus dem Kontext des WebJob-Prozesses fehlschlagen würde. Hier können WebJob-spezifische Umgebungsvariablen hilfreich sein. Im Fall der Referenzlösung haben wir webJob-spezifische Umgebungsvariable WEBROOT_PATH verwendet, um Zugriff auf den zugeordneten Websiteordner zu erhalten.

string jsFile = Path.Combine(
    Environment.GetEnvironmentVariable("WEBROOT_PATH"), 
    "Resources\\OneDriveConfiguration.js");

Es gibt auch einige andere Umgebungsvariablen für WebJobs, die Ihnen möglicherweise helfen können. Sie können die verschiedenen Umgebungsvariablen mithilfe von Code überprüfen, und dafür gibt es im GitHub gute Verweise.

Video zur Veranschaulichung der Lösung und der Aktionen

Hier ist ein Video, das die Lösung in der Praxis zeigt, einschließlich einer Erläuterung der Lösungsstrukturen und wie Sie sie in Ihrer Office 365 Umgebung verwenden würden, um OneDrive for Business Websites zu ändern.

PnP-Beispiele

Gilt für

  • Office 365 mit mehreren Mandanten (MT)
  • Office 365 dediziert (D) teilweise
  • SharePoint 2013 lokal – teilweise

Muster für dedizierte und lokale Umgebungen sind identisch mit SharePoint-Add-In-Modelltechniken, aber es gibt Unterschiede bezüglich der verwendbaren Technologien.