cool IT Team-Blog

SharePoint 2013 CSOM mit Nintex Workflow 2013

CSOM steht für Client Side Object Model und erlaubt den client-seitigen Zugriff auf einen Großteil der SharePoint API. Weitere Möglichkeiten des client-seitigen Zugriffs sind die SharePoint Web Services und REST, die aber nicht den Funktionsumfang von CSOM erreichen.

In einem meiner SharePoint Projekte hatte ich die Aufgabe, in einer vom "Nintex Workflow 2013" angelegten Subsite eine bestimmte SharePoint Gruppe als Default Mitglieder Gruppe einzurichten. Dies sollte ebenfalls der Nitex Wokflow bewerkstelligen.

Nintex Workflow 2013 bietet zwar out-of-the-box eine Aktion zum Aufrufen eines SharePoint Webservices, jedoch bieten die SharePoint Webservices keine Möglichkeit zum Setzen einer Default Gruppe in einer SharePoint Site.

Fündig geworden bin ich zunächst in einem Blog, welcher zeigt, wie man diese Aufgabe mit einem in Microsoft Visual Studio implementierten Workflow löst.

Ich habe also die in obigen Blog beschriebenen Web POST Requests mit Nintex Workflow Actions nachgebaut. Ich konnte damit auch die benötigten Site- und Web-GUIDS, sowie die Gruppen-ID von SharePoint abfragen, jedoch lieferte mir der Aufruf zum Setzen der Default Mitglieder Gruppe immer einen „FORBIDDEN“-Fehler zurück, obwohl der Aufruf mit einem Site Collection Administrator Account erfolgte.

Dann habe ich versucht, per JavaScript-CSOM die Default Gruppe zu setzen, was auf Anhieb ohne Probleme klappte. Dies zeigte mir, dass es nicht an den SharePoint-Einstellungen oder an fehlenden Berechtigungen liegen kann.

Ich habe dann mit Telerik Fiddler den HTTP Traffic des JavaScripts protokolliert und gesehen, dass das übertragene Request XML im wesentlichen mit dem XML aus obigen Blog übereinstimmt. Aufgefallen ist mir jedoch, dass im Request-Header ein Request Digest mitgegeben wurde. Mir war vorerst nicht klar, wie ich zu diesem Request Digest komme.

Nach weiteren Rechergen bin ich dann auf folgenden Eintrag im Nintex Forum gestoßen:
https://community.nintex.com/community/build-your-own/blog/2015/04/24/how-to-execute-a-rest-api-request-with-nintex-workflow

Dieser Eintrag zeigt, wie man den für den POST Request benötigten Request Digest von SharePoint anfordern kann und voilà  – damit klappte dann endlich das Setzen der Default Mitglieder Gruppe in meinem Nintex Workflow!

Die wesentlichen Schritte im meinem Nintex Workflow hier nochmals zusammengefasst:

1. Ermitteln der Gruppen-ID mittels einer XML-Abfrage Aktion

image001.png

Der REST Call „_api/web/sitegroups/getbyname(‘<Gruppenbezeichnung>‘)” erlaubt das Abfragen von Gruppen-Informationen, darunter auch die Gruppen-ID, welche mit der XPath –Query "//d:Id" aus dem Ergebnis-XML ermittelt wird.

Die so ermittelte Gruppen-ID speichern wir in der Nintex-Variable „GroupID“.

2. Abfrage der Site-GUID mittels einer XML-Abfrage Aktion

image003.png

Die Site-GUID lässt sich über den REST-Call „_api/site“ analog zum Ermitteln der Gruppen-ID abfragen. Das Ergebnis speichern wir in der Nintex Variable „SPSiteID“.

3. Abfrage der Web-GUID mittels einer XML-Abfrage Aktion

image005-(1).png
Die Web-GUID lässt sich über den REST-Call „_api/web“ analog zum Ermitteln der Site-ID abfragen. Das Ergebnis speichern wir in der Nintex Variable „SPWebID“. Wichtig ist hier, dass der Aufruf in der betreffenden Subsite gemacht wird.

4. Anfordern des Request Digest

image007.png

Über den POST Request “_api/contextinfo” bekommen wir den SharePoint Kontext geliefert, welcher auch den benötigten Request Digest enthält. Das Ergebnis-XML des Aufrufs speichern wir in der Nintex Variable „WebRequestResult“
 
Anschließend können wir mit einer XML-Abfrage den Request Digest aus dem Ergebnis-XML per XPath-Query "//*[local-name()='FormDigestValue']" ermitteln:image011.png

5. Setzen der Default Mitglieder Gruppe

Wir haben nun alle benötigten Informationen für den eigentlichen CSOM Aufruf und können den Web Request zum Setzen der Default Mitglieder Grupp mit einer Nintex Webanforderungs Aktion definieren.
 
image013.png

Die URL zum Absetzen des CSOM POST Requests lautet:

Website-URL/CreatedSiteURL/_vti_bin/client.svc/ProcessQuery

Im Header übergeben wir den ermittelten Request-Digest:

X-RequestDigest: RequestDigest

Das zu postende XML setzt sich wie folgt zusammen:

<Request AddExpandoFieldTypeSuffix="true" SchemaVersion="15.0.0.0"
 LibraryVersion="15.0.0.0" ApplicationName=".NET Library"
 xmlns="http://schemas.microsoft.com/sharepoint/clientquery/2009">
   <Actions>
      <SetProperty Id="1" ObjectPathId="2" Name="AssociatedMemberGroup">
         <Parameter ObjectPathId="3" />
      </SetProperty>
      <Method Name="Update" Id="4" ObjectPathId="2" />
   </Actions>
   <ObjectPaths>
      <Identity Id="2" Name="{WorkflowVariable:SPObjectFactoryID}:site:{WorkflowVariable:SPSiteID}:web:{WorkflowVariable:SPWebID}" />
      <Identity Id="3" Name="{WorkflowVariable:SPObjectFactoryID}:site:{WorkflowVariable:SPSiteID}:g:{WorkflowVariable:GroupID}" />
   </ObjectPaths>
</Request>

Die „SPObjectFactoryID“ ist laut den zu Beginn genannten Blog eine Konstante mit dem Wert „740c6a0b-85e2-48a0-a494-e0f1759d4aa7“. Ich habe dafür eine Nintex Variable angelegt und dort diesen Wert als Default zugewiesen.

Damit funktioniert nun das Setzen einer SharePoint-Default-Gruppe per Nintex Workflow.

Ist doch cool, oder?
Verfasst: 09.06.2017 13:15:10 von Roland Koller
Tags: AssociatedMemberGroup, CSOM, Nintex, SharePoint, Workflow

1


Kommentare
Für diesen Blogbeitrag liegen zurzeit keine Kommentare vor.
Einen Kommentar schreiben



 Security code

Sparen Sie jetzt mit unserer BonusCard!

cool IT Consulting Bonuscard

Falls Sie bereits Bonuscard-Kunde sind, können Sie sich hier direkt anmelden!