Dabei bin ich immer wieder auf das Selbe Problem gestoßen. Der Workflow reagierte auf meine gesetzte Daten manchmal 2h später als angegeben.

Nach langer Suche stellt sich heraus, dass das Problem darin besteht wie SharePoint Daten speichert. Tatsächlich konvertiert SharePoint Daten nach UTC….! Ich habe also Berechnungen mit Daten zweier verschiedenen Zeitzonen durchgeführt, da z.B. Benutzereingaben in meiner Umgebung in der aktuellen MEZ angegeben werden. Das Ergebnis lag somit manchmal 2h in der Vergangenheit, ein anderes mal 2h in der Zukunft.

Ich habe im SharePoint-Designer in einem 2010er Workflow noch keine möglichkeit gefunden ein Datum automatisiert in die richtige Zeitzone zu konvertieren. Lediglich ein paar Drittanbieter-Actions habe ich gesehen die das scheinbar können.

Wenn du also im Code/Workflow mit Datum arbeitest, vergesse nicht, in UTC zu konvertieren bzw. sicherzustellen, dass alle Eingaben und Vergleichsdaten in UTC vorliegen.!

public string ToXml()
{
   //Ohne XML-Doc-Deklaration
   var settings = new XmlWriterSettings() {
                   Indent = false, OmitXmlDeclaration = true };
 
   var stream = new MemoryStream();
   using (XmlWriter xw = XmlWriter.Create(stream, settings))
   {
      //Leere Namespace-Deklaration
      var ns = new XmlSerializerNamespaces(
                         new[] { XmlQualifiedName.Empty });
      var x = new XmlSerializer(GetType(), "");
      x.Serialize(xw, this, ns);
   }
 
   return Encoding.UTF8.GetString(stream.ToArray()); 
}

Du erhälst eine Live-Vorschau des Cue-Wertes im Designer, lokalisiert auf die Spracheigenschaft des Formulars.

using System;
using System.ComponentModel;
using System.Windows.Forms;
using System.Runtime.InteropServices;

class CueTextBox : TextBox {
    [Localizable(true)]
    public string Cue {
        get { return mCue; }
        set { mCue = value; updateCue(); }
    }

    private void updateCue() {
        if (this.IsHandleCreated && mCue != null) {
            SendMessage(this.Handle, 0x1501, (IntPtr)1, mCue);
        }
    }

    protected override void OnHandleCreated(EventArgs e) {
        base.OnHandleCreated(e);
        updateCue();
    }

    private string mCue;

    // PInvoke
    [DllImport("user32.dll", CharSet = CharSet.Unicode)]
    private static extern IntPtr SendMessage(IntPtr hWnd, int msg, IntPtr wp, string lp);
}

Unwissenheit und Faulheit brachte mich dazu das Session-Objekt der aktuellen Sitzung als Caching-Mechanismus zu missbrauchen. Der Plan: Das Ergebnis sich oft wiederholender und statischer Datenbankabfragen zwischen zu speichern um dadurch die Anzahl der Zugriffe zu minimieren und die schlussendlich die Performance zu verbessern. Das Problem: Eine Anfrage an eine .NET-Webanwendung führt zu einem Session-Lock der erst nach Auslieferung der Antwort wieder gelöst wird. IIS arbeitet Anfragen die das Session-Objekt nutzen also nicht parallel sondern nacheinander ab.

Um zu dieser Erkenntnis zu kommen musste ich das Thema Caching jedoch erst einmal verstehen.

Die Session

Eine Session ist definiert durch eine bestimmte Zeit die zwischen einer Web-Anwendung und dem Benutzer geteilt wird.Jeder Benutzer einer Web-Anwendung hat eine eigene Session. In einer Session können Elemente/Objekte gespeichert werden die sich dann als diese für den Nutzer definiert. Zugriff auf die gespeicherten Werte erfolgt durch einen eindeutigen Schlüssel ähnlich einer Hash-Tabelle. Gelöscht wird eine Session durch die Anwendung selbst oder einem definierbaren TimeOut.

Session["key"] = value;

Das Session-Objekt sollte nur in Bezug auf den aktuellen Benutzer verwendet werden. Es speichert Informationen auf der Server-Seite. Der Unterschied zum Cache ist, dass der Cache auf globaler bzw. Anwendungsebene verfügbar ist. Jede Anfrage verwendet also den Selben Cache, unabhängig vom Benutzer. Es können zwar beliebig große Objekte in einem Session-Objekt gespeichert werden, jedoch belastet, besonders bei einem hohen Benutzer-Aufkommen extrem den Speicher, da jeder Benutzer eine eigene Kopie im Speicher vorhällt und außerdem wie eingangs bereits erwähnt, bei jeder Anfrage ein Session-Lock auftritt. Dieser kann nur umgangen werden, wenn man mittels Anfrage nur lesend auf die Session zugreift.

Ein möglicher Workaround wäre also den SessionState auf ReadOnly zu setzen.

<% @Page EnableSessionState="ReadOnly" %>

Dies funktioniert jedoch nur, wenn die Anfrage niemals schreibenden Zugriff auf das Session-Objekt benötigt. Darauf wollte ich mich nicht verlassen, also ging ich auf die Suche nach einer anderen, besseren Lösung um komplexe Datenstrukturen richtig zwischen zu speichern.

Der ViewState

Der ViewState ist ein verstecktes Formularfeld innerhalb einer .NET-Seite. Änderungen werden mittels Postback mitgeteilt. Alle Server-Steuerelemente haben einen eigenen ViewState der mittels EnableViewState-Eigenschaft gesteuert werden kann.

Befinden sich viele Daten im ViewState, büst eine Website an Performance ein, da bei jedem PostBack der gesamte ViewState zurück an den Server geschickt wird. Beliebige Daten können im ViewState gespeichert werden, jedoch gilt zu beachten das der ViewState nur bis zum Ende des LifeCycles der Seite bestand hat.

ViewState["key"] = value;

Der Cache

Den Cache kann man sich als Erinnerung der Anwendung vorstellen. Aus ihm kommt der gesamte Quellcode und in Ihm können beliebige Daten gespeichert werden die jederzeit und global wiederverwendet werden könne. Die perfekte Stelle also um das Ergebnis von komplexen Berechnungen zwischen zu speichern, vor allem wenn deren Datenbasis sich selten ändert. Ein Cache-Objekt wird entweder durch die Anwendung oder durch ein definierbares Ablaufdatum gelöscht und Daten können direkt aus dem Cache gebunden werden.

public void AddItemToCache(string key, object value)
{
if (Cache[key] == null){
Cache.Add(key,
value,
null,
DateTime.Now.AddSeconds(60),
TimeSpan.Zero,
CacheItemPriority.High,
null);
}
}

public void RemoveItemFromCache(string key)
{
if(Cache[key] != null)
Cache.Remove(key);
}

Fazit

Für meine Anforderung, nämlich Daten aus Performancegründen zwischen zu speichern, kommt eigentlich nur der Cache in Frage. Einmal hinterlegte Daten können Benutzerunabhängig geladen werden und beschleunigen so die Anwendung extrem. Es muss nur darauf geachtet werden das die Objekte im Cache bei einer Änderung in der Anwendung auch aktualisiert/entfernt/hinzugefügt werden, damit der Cache immer auf aktuellem Stand ist.