Selvom jeg principielt er modstander af brugen af sharepoint lister til at holde på forretningskritiske data, kan man ikke komme udenom det faktum, at man kan udstille en sharepoint liste som en ganske almindelig service. Indlægget kommer til at omhandle, hvordan denne service kan konsumeres af andre applikationer. Man skal dog rent arkitektur mæssigt forholde sig særligt kritisk overfor dette mønster, da sharepoint lige pludselig fungerer som backend, hvilket kan utydeliggøre en en klar skillelinje mellem backend systemer og frontend portaler. Det kan hurtigt blive et virvar af lagdelinger, der overlapper hinanden, istedet for at have klare afgrænsede ansvarsområder. Det overholder selv ikke principperne bag onion arkitektur, så hellere klare afgrænsede snitflader frem for en blanding af lagene.

Bliver en sharepoint liste derimod populeret med data fra en database, er problemet nok ikke så stort, men i Sharepoint 2007 findes der stadigvæk ikke mulighed for at implementere relationer fuldt ud. Det hele bliver nogle logiske relationer i form af lookup tabeller her og der uden referentiel integritet. Dette skulle være taget hånd om i Sharepoint 2010. Dog retfærdiggør dette stadigvæk ikke placering af forretningskritiske data i en Sharepoint liste, men Sharepoint 2010 giver derimod en mere sikker og renere repræsentation af relationel datastruktur.

Har man en intern kaffeklub eller andet i en liste, der skaber værdi i interne arbejdsprocesser i en organisation, og man gerne vil udstille denne liste som en service, så kan det opnås på følgende måde:

List Data Retrieval Service
http://<server-url>/_vti_bin/dspsts.asmx

Har man allerede en liste oprettet med noget data, så åbnes Visual Studio og man tilføjer ganske enkelt referencen: 'http://<server-url>/_vti_bin/dspsts.asmx'.

En sharepoint liste er beskyttet af rettigheder, og derfor skal der sættes credentials op for at tilgå listen med tilstrækkelige rettigheder. I dette eksempel tilgås listen med Network Credentials. Dvs. listen tilgås med den bruger, der er logget på netværket.

var stsAd = new StsAdapter();
stsAd.Credentials = CredentialCache.DefaultNetworkCredentials;

//Resten af kode snippet ser således ud:
string[] vArray = new string[1];
vArray[0] = "1.0";
var ver = new Versions();
ver.version = vArray;

stsAd.versions = ver;
var reqHeader = new RequestHeader();
reqHeader.document = DocumentType.content;
reqHeader.method = MethodType.query;

stsAd.request = reqHeader;

//Listen refereres ved hjælp af GUID.
//Find GUID på listen under instillingerne for listen.
const string listGuid = "{08D53A6B-947E-406F-B3C0-74534FC6BE07}";

var req = new QueryRequest();

var xpq = "/list[@id='" + listGuid + "']";
var sQuery = new DSQuery();
sQuery.select = xpq;
req.dsQuery = sQuery;

var spQuery = new DspQuery();
req.dsQuery.Query = spQuery;

XmlNode myNode = stsAd.Query(req);


Xmlnoden 'myNode' holder på listen, og skal herefter pakkes ud.

Er der behov for at filtrere svaret, kan man benytte sig af CAML. Fremadrettet vil / kan LINQ blive brugt til dette. Her er et eksempel på, hvordan man sender CAML med i et request.

var xmlDoc = new XmlDocument();
var eqQuery = xmlDoc.CreateElement("Eq");
eqQuery.InnerXml = "<FieldRef Name='Vaerdi'/><Value Type='Text'>fisk</Value>";

var spQuery = new DspQuery();
spQuery.Where = eqQuery;
req.dsQuery.Query = spQuery;

XmlNode myNode = stsAd.Query(req);


Find yderligere informationer ved brug af 'List Data Retrieval Web Service' her.