Business Data List Connector

Dirk Weinert Als Antwort am 26 Mai 2014 12:05

Hallo,

eine mögliche Lösung könnte ein PowerShell Skript sein.
Für Deinen konkreten Fall habe ich allerdings keines zur Hand.
So etwas hat man nicht einfach irgendwo herumliegen. ;-)

Für unsere Umgebung habe ich ein kleines PowerShell Skript
geschrieben, dass folgende Funktion hat:

Es existiert eine Liste, in der unsere Clients mit verschiedenen
Informationen zur Hard- und Software gespeichert werden.
Eine dieser Informationen ist das Datum, wann ein Client den
End of LifeCycle erreicht.
Mein Skript durchläuft die Liste (ca. 500 Einträge) und prüft anhand
des Datums, wie viel Clients den End of LifeCycle erreicht haben.
Es wird also durch Aufaddierung die konkrete Anzahl ermittelt.
Anschließend erzeuge ich eine XML-Datei und schicke die Infos
in eine separate SQL-Datenbank, die bestimmte KPIs enthält.

Ob Du auf Versionsverläufe per PowerShell zugreifen kannst, weiß
ich nicht 100%ig, da ich das noch nicht gemacht habe.
Könnte mir aber vorstellen, dass das geht. ;-)

Gruß
DW

Frank Daske Als Antwort am 26 Mai 2014 12:27

Der Layer2 Business Data List Connector dient zur Integration und Synchronisation nahezu beliebiger externer Datenquellen mit SharePoint Listen:

Er greift dabei - wenn Versionierung angeschalten ist - stets auf die aktuelle Version von Listenelementen zu. Geschäftslogik kann über Listen-Workflows bzw. auch Programmierung bei Datenänderung wie in SharePoint üblich angebaut werden. Dabei per SQL direkt auf die SharePoint Datenbank loszugehen ist zwar möglich, wird aber i.A. eher nicht empfohlen.

Llorente Als Antwort am 26 Mai 2014 13:21

[quote user="Dirk Weinert"]

Mein Skript durchläuft die Liste (ca. 500 Einträge) und prüft anhand
des Datums, wie viel Clients den End of LifeCycle erreicht haben.
Es wird also durch Aufaddierung die konkrete Anzahl ermittelt.
Anschließend erzeuge ich eine XML-Datei und schicke die Infos
in eine separate SQL-Datenbank, die bestimmte KPIs enthält.

[/quote]

Leider habe ich mit PowerShell Skripten nur wenig Erfahrung... und vor allem nicht diese mit einer SP Liste zu verknüpfen. Vielleicht habe ich mein Problem auch nicht richtig formuliert, denn ich möchte nicht dass die Aufaddierung oder ein Mittelwert in eine andere DB geschickt wird. Es geht vordergründig darum, dass ich z.B. schauen kann wie lang ein Problem von "erstellen" bis zum lösen im Schnitt dauert. Und dies kann dann wie auch immer dargestellt werden.... es muss nicht in eine SQL-DB gespeichert werden o.Ä. Es muss ur für meine Vorgesetzten ein wenig informativ werden; egal auf welchem Weg. Gibt es da keine einfachere Lösung? Darum dachte ich ja an irgendwelche Select Befehle um so etwas zu tun... aber einen Plan habe ich da eben nicht.

[quote user="Frank Daske"]

Der Layer2 Business Data List Connector dient zur Integration und Synchronisation nahezu beliebiger externer Datenquellen mit SharePoint Listen:

[/quote]

Ich benötige dies aber nicht für eine externe Datenquelle, sondern einfach nur für meine Liste im SharePoint....

[quote user="Frank Daske"]

Dabei per SQL direkt auf die SharePoint Datenbank loszugehen ist zwar möglich, wird aber i.A. eher nicht empfohlen.

 [/quote]

Ich glaube, dass ich aber nur so genau die Abfragen hinbekommen würde wie ich es will oder?

Andi Fandrich Als Antwort am 26 Mai 2014 14:06

Du willst ja letztlich per Abfrage auf die Versionsgeschichte zugreifen und das geht leider nicht so einfach - auch nicht per direktem Datenbankzugriff, der aber eh nicht unterstützt wird.

Sowas muß man programmieren, wie Dirk schon schrieb z.B. mit PowerShell.

Llorente Als Antwort am 26 Mai 2014 14:23

[quote user="Andi Fandrich"]Sowas muß man programmieren, wie Dirk schon schrieb z.B. mit PowerShell.[/quote]

Okay, aber leider ist das die wichtigste Anforderung in meinem Praxissemester und ich habe nur eine "Mini-Erfahrung" durch die Uni in Sachen PowerShell.... Ich tippe es ist wohl unmöglich sich das in ein paar Wochen anzueignen oder? Denn so lange bin ich nicht mehr in der Firma :(

Andi Fandrich Als Antwort am 26 Mai 2014 14:52

PowerShell ist an sich relativ einfach und ähnlich C#. Man kann also irgendwelchen Code, den man im Web findet, sehr leicht für PowerShell umschreiben. Und für diese Aufgabe brauchst Du nicht besonders viel vom SharePoint-Objektmodell. Je nach Deinen Vorkenntnissen, könntest Du es also lernen. Das schwierigste an der Aufgabe ist es, aus dem Versionsverlauf das richtige herauszufinden, d.h. es muß ein geeigneter Algorithmus entwickelt werden.

PowerShell verwendet hier dieselben Objekte wie serverseitiger C#-Code, so daß Du als Referenz immer die MSDN benutzen kannst. Die Klassennamen fangen immer mit SP an, so daß eine kleine Google-Suche mit dem Klassennamen in der Regel als erstes Ergebnis die MSDN-Referenz liefert. Beispiel SPWeb: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spweb.aspx Diese Referenz muß man natürlich möglichst schnell lesen können, um das Richtige zu finden. Auch da kenne ich Deine Vorbelastung nicht, aber MSDN ist immer gleich aufgebaut, also egal ob es um C# pur, um SharePoint, Exchange oder sonstwas geht.

Du brauchst folgende Objekte: SPWeb (eine Website), SPList (eine Liste oder Bibliothek) und SPListItem (ein Element einer Liste. SPListItem hat eine Eigenschaft "Versions" und die kann man mit foreach durchgehen. An den Wert einer Spalte kommst Du über SPLIstItem["Spaltenname"]

Damit kannst Du anfangen:

$web = Get-SPWeb http://sharepoint/site1
$list = $web.Lists["Listenname"]
$listItem = $list.GetItemByID(1)

Statt $list.GetItemByID gibt es noch viele andere Möglichkeiten an die Elemente einer Liste zu kommen. $list.Items liefert alle.

Llorente Als Antwort am 26 Mai 2014 16:20

Vielen Dank für die Bemühungen "Andi Fandrich" !!! Ich muss mir jetzt erstmal nen kleinen Überblick verschaffen und wenn ich Fragen habe, werde ich mich nochmal in diesem Thread melden!

Llorente Als Antwort am 27 Mai 2014 09:58

Mal ein ganz anderer Ansatz: ich habe eben mal eine Pivot-Tabelle erstellt und einige Auswertungen sind ja auch mit dieser möglich. Nur soweit ich dass sehe, denke ich dass es damit nicht möglich ist auf den Versionsverlauf zuzugreifen umso die Durchlaufzeit eines Problems zu ermitteln. Dazu müsste ich ja die Uhrzeit "rausziehen" wo dass Problem erstellt wurde und die Zeit wo das Problem den Status "gelöst" bekommt. Und genau das geht wohl nicht denke ich. Denn bei einer Pivot Tabelle kann man ja nur z.B. die Änderungszeit nehmen aber nicht auf was es geändert wurde oder?

Frank Daske Als Antwort am 27 Mai 2014 10:16

Ich würde den nachträglichen Zugriff auf die Versionierung zur Auswertung vermeiden (da dies offenbar Probleme bereitet) und das Erstellungsdatum bei der Erstanlage des Datensatzes per Workflow in eine eigene Spalte übertragen. Diese wird dann immer mitgeführt und steht für Berechnungen (wie z.B. Dauer des Supportfalls) in berechneten Spalten stets zur Verfügung.

Llorente Als Antwort am 27 Mai 2014 10:41

[quote user="Frank Daske"]

Ich würde den nachträglichen Zugriff auf die Versionierung zur Auswertung vermeiden (da dies offenbar Probleme bereitet) und das Erstellungsdatum bei der Erstanlage des Datensatzes per Workflow in eine eigene Spalte übertragen. Diese wird dann immer mitgeführt und steht für Berechnungen (wie z.B. Dauer des Supportfalls) in berechneten Spalten stets zur Verfügung.

Oha das hört sich nach einer super Idee an... daran habe ich gar nicht gedacht! Ich könnte ja eigentlich immer eine extra Spalte erstellen in der ich bei einer Änderung den Zeitpunkt und die Art der Änderung eintrage oder? So kann ich dies ganz einfach um bequem in einer Pivottabelle auswerten! Danke!