Marktübersicht Yammer

Rob Koplowitz, Collaboration-Spezialist bei Forrester, liefert mit seinem neuen Report eine aktuelle Marktübersicht über die führenden Plattformen für Enterprise Social Collaboration. Verglichen mit den Bewertungen der letzten Jahre hat Microsoft stark aufgeholt und liegt nun fast gleichauf mit IBM, Jive und Salesforce.com. Doch für Interessenten der SharePoint-Plattform lohnt ein genauer Blick: So wurde zum Beispiel Yammer separat (ohne Office 365) bewertet und liegt hier leicht hinter den Alternativen Sitrion (früher NewsGator) und Neudesic.

Personen-Feldern verarbeiten mit Nintex

Wenn man innerhalb von Nintex den Inhalt von Personen-Feldern verarbeiten möchte, ist das erst mal unproblematisch, solange das jeweilige Listenfeld keine Mehrfachauswahl zulässt…man nimmt einfach eine Nintex-Workflow-Variable vom Typ „Person“. Anders sieht es aus, wenn man eine „User defined Action“ (UDA) baut… hier gibt’s diesen Variablen-Typ nämlich nicht. Ebenso problematisch wird es, wenn das Personenfeld für eine Mehrfachauswahl konfiguriert ist… In beiden Fällen bleibt einem nur, auf eine Workflowvariable vom Typ „Text“ zurückzugreifen.
Soweit, so gut… spannend wird’s, wenn man die darin enthaltenen Personen innerhalb der Nintex-Logik weiterverarbeiten und z.B. als Empfänger für eine Benachrichtigung verwenden will. Im einfachsten Fall wird so eine Textvariable eins zu eins als Email-Empfänger genutzt. Doch was tun, wenn im Rahmen des Email-Versands eine Fehlermeldung auftaucht, die besagt, dass die Email-Adresse des Benutzers mit ID „1337“ nicht gefunden werden kann… in so einem Fall neigt man unweigerlich dazu, das Benutzerprofil als Übeltäter auszumachen… aber weit gefehlt…

Schaut man sich dann den Inhalt einer aus einem Personenfeld gefüllten Workflow-Textvariable an, kann das für 2 Personen so aussehen:

„[ID]#;[LoginName]#; [ID]#;[LoginName]“

oder auch:

„[LoginName];[LoginName]“

Im ersten Fall kommt es zu o.g. Fehlermeldung, im letzteren funktioniert alles wie erwartet.

Grundsätzlich wendet Nintex hier eine Standardformatierung an…wann allerdings welche Formatierung zieht, wovon das genau abhängig ist, haben wir noch nicht abschließend analysiert. Gefunden haben wir beide Varianten… Nintex selbst bietet allerdings in der Action zum Setzen einer Variable an, eine feste Formatierung vorzugeben (bei Daten, die aus Personenfeldern stammen z.B. „Login-Namen durch Semikolon getrennt“). Genau diese Einstellungsmöglichkeit sollte man nutzen, um sicher zu sein, jederzeit das gleiche Format zur Weiterverarbeitung vorzufinden.

Einen Haken hat das Ganze allerdings dann immer noch… denn diese fest vorgegebene Formatierung führt intern gnadenlos eine Typkonvertierung durch, die nicht mit NULL-Werten umgehen kann (ist also das Personenfeld in der jeweiligen Liste leer, kommt es innerhalb von Nintex zu einem Koersionsfehler!). Das Auslesen eines Personenfeldes innerhalb von Nintex mit einer vorgegebenen Formatierung darf also nur dann erfolgen, wenn sichergestellt ist, das das Feld nicht leer ist…ansonsten „Hand in Hand gegen die Wand“ 🙂 .

Für „BigData“ ist SharePoint nicht wirklich geeignet – Critical Unknown SQL Exception 515 occurred

Folgender Fall… Eine Liste mit sehr vielen Spalten (Grenzwerte für die max. Anzahl von Spalten je Datentyp werden eingehalten; ebenso der Grenzwert für die Anzahl zulässiger Lookup-Spalten). Soweit so gut… Jetzt kommt man irgendwann auf die Idee, die Spalten-Anzahl innerhalb der Liste zu reduzieren und entfernt diverse Felder. Lesende Zugriffe funktionieren nach wie vor… ebenso auch das Update von vorhandenen Listeneinträgen. Wenn man allerdings einen neuen Listeneintrag hinzufügen will, krachts und man findet in etwa folgende Einträge im Log:

Critical Unknown SQL Exception 515 occurred. Additional error information from SQL Server is included below. Der Wert NULL kann in die tp_DocId-Spalte, dbo.AllUserData-Tabelle nicht eingefügt werden. Die Spalte lässt NULL-Werte nicht zu. Fehler bei INSERT. Die Anweisung wurde beendet.
System.Runtime.InteropServices.COMException: Exception from HRESULT: 0x80131904 at Microsoft.SharePoint.Library.SPRequestInternalClass.AddOrUpdateItem…

In den meisten Fällen verweist der Error-Code „0x80131904“ auf Speicherknappheit innerhalb der Content-Datenbank. Ganz so einfach ist das Ganze dann hier allerdings nicht…
Entscheidend ist der vorangegangene Fehler innerhalb des SQL-Servers („Der Wert NULL kann in die tp_DocId-Spalte, dbo.AllUserData-Tabelle nicht eingefügt werden.“).
In SharePoint werden die Inhalte aller Listen innerhalb der gleichen Tabelle in der Content-DB („AllUserData“) speichert. Bei einer Liste, die sehr viele Spalten enthält wird ein einzelner Listeneintrag allerdings auf mehrere Zeilen innerhalb dieser Content-DB-Tabelle verteilt. Welche Listenspalte dabei in welche Zeile in der Content-DB-Tabelle geschrieben wird, entscheidet der Parameter „RowOrdinal“ (standardmäßig „0“) der jeweiligen Listenspalte. Entscheidend hierbei ist, das innerhalb der Listendefinition die erste Spalte immer einen „RowOrdinal=0″ haben muss. Ist dies nicht der Fall, kommt es zu o.g. Fehlermeldung. So eine Konstellation kann leider entstehen, wenn aus einer Liste mit einer hohen Anzahl von Spalten (d.h. es sind Spalten mit RowOrdinal>0 enthalten) mehrere Spalten wieder gelöscht werden und dadurch die erste Spalte in der Listendefinition einen RowOrdinal>0 behält. Nachzuvollziehen ist das Ganze entweder über den SharePoint-Manager (dieser kann allerdings nur auf einem der Farm-Server genutzt werden), oder aber indem man die Liste als Vorlage speichert, das dadurch erzeugte „.stp“-File aus dem Listenvorlagen-Katalog herunter lädt, in „.cab“ umbenennt und sich die Manifest.xml anschaut.
Hier hilft nur, die Spaltenreihenfolge innerhalb der Listen-Konfiguration anzupassen, sodass die erste Spalte unbedingt einen RowOrdinal-Value von „0“ hat oder aber die „führenden“ Spalten mit RowOrdinal>0 zu entfernen und neu anzulegen. Was sagt uns das? Für „BigData“ ist SharePoint nicht wirklich geeignet… das gilt sowohl für die Listenbreite als auch für die Anzahl der Listeneinträge.