Archiv für den Monat: April 2015

PowerShell und OData (Teil 2)

Im ersten Teil der dreiteiligen Serie ging es um einen ersten Überblick über OData und seine Möglichkeiten. In diesem zweiten Teil zeige ich, wie CRUD-Operationen (Create, Read, Update und Delete) mit einem OData-Webservice durchgeführt werden.

Das Invoke-RestMethod-Cmdlet


Im Mittelpunkt steht das Invoke-RestMethod-Cmdlet, das bereits seit der Version 3.0 dabei ist.

Das Abrufen von Daten per Invoke-RestMethod-Cmdlet ist sehr einfach. Hier ein einfaches Beispiel, das alle Datensätzen der Employees-Tabelle aus der Northwind-Datenbank abruft:

Wie im ersten Teil gezeigt, sind auch „richtige“ Abfragen möglich, die z.B. Filter verwenden:

Die Filter-Angaben werden über ein Schlüsselwort festgelegt, wie z.B. $filter oder $select. Per $format wird das Format ausgewählt.

Tipp: In einem PowerShell-Skript muss das $-Zeichen eventuell escaped werden.

Für das Aktualisieren von Daten ist etwas mehr Aufwand erforderlich. Die zu aktualisierenden Daten werden als JSON-Objekt im Rahmen einer POST-Aktion übergeben.

Auch hier ein Beispiel, das sich auf einen von mir erstellten OData Webservice bezieht. Der folgende Aufruf soll einen Dienst anhalten:

Im dritten Teil zeige ich, wie sich per Management OData Cmdlets und Functions aus einem Modul über einen Webservice ausführen lassen. Das ist vor allem für mobile Geräte interessant, auf denen weder eine PowerShell noch ein OMI-Client zur Verfügung steht und sich nur HTTP-Aufrufe durchführen lassen (etwa ein Raspberry Pi;)

PowerShell und OData (Teil 1)

In einer dreiteiligen Serie werde ich das Zusammenspiel der PowerShell mit OData beleuchten. OData ist ein von Microsoft vor einigen Jahren initiierter Standard, der eine universelle Webschnittstelle für den Zugriff auf beliebige Daten ermöglicht, die über einen (REST-basierten) Webservice zur Verfügung gestellt werden. Über URLs werden Abfragen im Stile von SQL-Abfragen durchgeführt. Auch das Aktualisieren von Daten ist per OData möglich. Die zur Verfügung stehenden Daten werden durch ein Entitätsmodell beschrieben, so dass Abfragen auch Beziehungen zwischen den Entitäten (Tabellen) berücksichtigen können.

Teil 1 – OData im Überblick
Teil 2 – OData-Webservices per PowerShell benutzen
Teil 3 – Management OData – Cmdlets über URLs ausführen

OData ist eine Spezifikation für das Abrufen und Aktualisieren von strukturierten Daten über das Web. OData wurde 2007 von Microsoft erfunden – es entstand aus dem Projekt Astoria, aus dem später die ADO.NET Data Services wurden, die aktuell WCF Data Services heißen. OData ist der zugrundeliegende Standard der WCF Data Services.

Die Idee war es, eine universelle Datenschnittstelle für das Web zu schaffen – ein „ODBC für das Web“.

OData-Clients gibt es für alle Plattformen.

Mit der aktuellen Version 4.0 hat Microsoft die OData-Spezifikation an die OASIS-Gruppe übergeben, die als nicht kommerziell orientierte Organisation zahlreiche Standards betreut, u.a. das Open Document Format, das Konkurrenzformat zu Open XML von Microsoft. Damit ist OData ein offener Standard vergleichbar mit AtomPub (Atom Publishing Protocol) oder XML. Informationen rund um OData gibt es unter www.odata.org. Hier findet man nicht nur die offizielle Spezifikation (dies ist relativ leichte Kost und anschaulich geschrieben), sondern auch Beispielprogramme und Demo-Dienste, anhand derer sich OData-Webaufrufe ausprobieren lassen.

Einen OData-Webservice kennenlernen


Hier eine kleine Übung zum warm werden. Gib in den Browser die folgende URL ein:

http://services.odata.org/V3/Northwind/Northwind.svc/

Du rufst damit einen Demo-OData-Datendienst auf, der die Daten der Northwind-Daten zur Verfügung stellt. Das Ergebnis relativ viel Text, der alle Ressourcen aufzählt, die abrufbar sind.

Die folgende URL ruft alle Datensätze der Employees-Tabelle ab:


http://services.odata.org/V3/Northwind/Northwind.svc/Employees

Noch mehr Text. Jetzt kommt etwas OData ins Spiel, in dem von allen Datensätzen nur die Felder FirstName, LastName und City übertragen werden sollen:


http://services.odata.org/V3/Northwind/Northwind.svc/Employees?$select=FirstName,LastName,City

Wichtig: Es kommt auf die Groß-/Kleinschreibung an.

Etwas besser. Noch besser wird es, wenn die Daten im JSON-Format zurückgegeben werden:


http://services.odata.org/V4/Northwind/Northwind.svc/Employees?$select=FirstName,LastName,City&format=JSON

Damit das ganze auch wirklich funktioniert, habe ich eine subtile Änderung in der URL durchgeführt. Anstelle der Version V3 rufe ich die Version auf, die bereits auf OData Version 4 basiert, da erst hier die JSON-Unterstützung dabei ist. Ein V3-OData-Service kann mit einem „format=JSON“ nichts anfangen.

Dass mit OData „richtige“ Abfragen im Stile von SQL möglich sind, macht das nächste Beispiel deutlich, dass die ersten 10 Bestellungen des Angestellten mit der ID 1 sortiert nach der Kundennummer zurückgibt:


http://services.odata.org/V4/Northwind/Northwind.svc/Employees(1)/Orders?$select=OrderID,OrderDate,CustomerID&$orderby=CustomerID&$top=20&format=JSON

Eine Übersicht über den Aufbau einer OData-URL gibt es hier:

http://www.odata.org/documentation/odata-version-2-0/uri-conventions/

Webdaten per Powershell verarbeiten


PowerShell ist nicht nur ein Werkzeug für administrative Zwecke, sondern auch für das Abrufen von Weiterverarbeiten von Daten aus dem Web sehr gut geeignet.

Hier ein Beispiel in Gestalt einer Function, das nichts mit OData zu tun hat. Die Functions durchsucht die RSS-Feeds verschiedener Microsoft-Blogs nach einem Suchwort, das beim Aufruf der Function übergeben wird:

Das Durchsuchen der RSS-Feeds geschieht wie folgt:

Search-RSS -Keyword "DSC"

Eine solche Abfrage wäre mit anderen Skript- und Programmiersprachen bei weitem nicht so einfach und vor allem konsistent umsetzbar. Die PowerShell ist damit für das Abrufen, Aggregieren, Durchsuchen und Formatieren von Daten sehr gut geeignet.

Bei dem Beispiel geht es aber nur um das Abrufen von Daten. Mehr ist mit dieser Technik nicht möglich. Mit OData geht es einen wichtigen Schritt weiter.

Bei OData geht es um CRUD-Operationen: Create, Read, Update und Delete. Diese Operationen werden über HTTP-Verben ausgeführt.

OData-Webservices sind REST basierende Webservices, die zusätzliche Möglichkeiten bieten:

>Filter

>Auswahloptionen (z.B. Top 3)

>Einbeziehen von Beziehungen zwischen „Entititäten“ (z.B. „gib alle VMs zurück, die auf einem Server gehostet werden“)

Die Daten werden auf Wunsch im XML- oder JSON-Format zurückgegeben.

OData-Webservices sind damit REST-Webservices mit mehr Komfort.

Die Vorträge des PowerShell Summity 2015 auf YouTube

Zeitgleich zur PowerShell Community Konferenz in Essen fand in den USA (dies Mal in Charlotte/NC) der PowerShell Summit North America statt (einen PowerShell Summit Europe wird es im September in Stockholm geben). Die Vorträge stehen inzwischen auf YouTube zur Verfügung:

https://www.youtube.com/playlist?list=PLfeA8kIs7CochwcgX9zOWxh4IL3GoG05P

Besonders interessant war für mich der OData-Vortrag von Richard Siddaway. Auch hier stellte sich bereits zu Beginn des Vortrags heraus, dass kaum jemand OData geschweige denn Management OData kennt.

Es ist wieder PowerShell-Community-Konferenz-Zeit

Mein Bericht von der PowerShell Community-Konferenz 2015

Vom 22. bis 23.4.2015 fand in Essen die dritte PowerShell-Community Konferenz statt, die von PowerShell MVP Tobias Weltner und Holger Schwichtenberg/IT-Visions organisiert wurde. Als Ort hatten sich die Veranstalter den Konferenzsaal der Philharmonie in Essen ausgesucht. Ein schönes Gebäude in direkter Nachbarschaft zum Hotel, in dem das Abendessen stattfand, und an einem schönen Stadtpark gelegen, in dem am Mittag des zweiten Tages das obligatorische Gruppenfoto entstand. Essen ist nicht nur per Zug (trotz des Bahnstreiks kam die überwiegende Mehrheit der Teilnehmer, die mit dem Zug angereist waren, offenbar pünktlich an – mein Zug fuhr am Dienstagvormittag beinahe auf die Minute pünktlich in Stuttgart ab und kam mit lediglich ein paar Minuten Verspätung in Essen an). Vom Bahnhof zum Veranstaltungsort sind es nur ca. 500 Meter (was für einige unter Umständen bereits eine größere Distanz darstellt) oder eine Station mit der U-Bahn.

Insgesamt hatten knapp 90 PowerShell-User den Weg nach Essen gefunden, eine erfreuliche Steigerung gegenüber dem Vorjahr. Wenn man bedenkt, dass die Veranstalter kaum Möglichkeiten hatten für die Veranstaltung zu werben, muss es wohl in erster Linie an der Mund-zu-Mund-Proganda der Teilnehmer aus beiden Vorjahren gelegen haben.

Auch wenn mir die Namen der Teilnehmer nicht vorliegen (es wäre schön, wenn man auf der Webseite sehen könnte, wer teilgenommen hat) hatte ich das Gefühl, das viele neue
Gesichter zu sehen waren. Gleichzeitig habe ich auch ein paar Bekannte wiedergetroffen, die bei den letzten Konferenzen dabei waren.

Die Vorträge an den beiden Tagen waren eine gute Mischung aus Grundlagenthemen, „Experten-Themen“ und Spezialthemen. Die Referenten waren in erster Linie MVPs  („Most Valuable Professionals“) aus verschiedenen europäischen Ländern, PowerShell-Experten und Buchautoren aus Deutschland. Teilnehmer aus Österreich und der Schweiz waren, soweit ich es überblicken kann, wie in den letzten Jahren nicht vertreten. An der Anreise kann es nicht gelegen haben, denn der Konferenzort ist über den Flughafen Düsseldorf sehr gut erreichbar.

Der „Stargast“ der Konferenz war natürlich Bruce Payette aus dem PowerShell-Entwicklerteam in Redmond. Bruce ist der Kopf hinter der PowerShell-Skriptsprache und der Architekt (das „Brain“) der Desired State Configuration (DSC). In seinem Vortrag, den ich leider verpasst hatte, da ich zu dieser Zeit noch im Zug saß, ging er auf die Neuerungen der Version 5.0 ein, die mit Windows 10 am 29. Juli offiziell werden wird. Das Bemerkenswerte Detail in diesem Zusammenhang ist, dass es das WMF 5.0 auch für Windows Server 2008 R2 und Windows 7 geben wird. Dies ist eine sehr gute Entscheidung. Zum einen wäre eine weitere „Fragmentierung“ sehr ungünstig. Zum anderen enthält die neue Version so viele wichtige Verbesserungen, dass kein künstlicher Grund geschaffen werden sollte sie nicht zu installieren.

Ein weiteres thematisches Highlight war der Vortrag von Aleksandar Nicolic zum Thema JEA (Just Enough Admin) – oder wie man eingeschränkte Remoting-Runspaces einrichtet, damit Anwender, die keine Administroren sind, im Rahmen ihrer Remoting-Session nur die Befehle nutzen können, die sie nutzen sollen und nicht mehr. Dass es dabei durchaus auf die Feinheiten ankommt machte Aleksandar an einem Beispiel eindrucksvoll deutlich. Belässt man die Einstellung „LanguageMode“ (etwa beim New-PSSessionConfigurationFile-Cmdlet) auf der Einstellung „FullLanguage“, können über einen Scriptblock nach wie vor sämtliche Cmdlets ausgeführt werden. So wird es trotz guter Absichten leicht, Sicherheitslücken einzubauen. Das JEA-Toolkit, das bereits WMF 5.0 voraussetzt, soll das Einrichten sicherer Endpunkte narrensicher machen. Es ist bemerkenswert, dass es abgesehen von dem Umstand, dass es per DSC verteilt wird, auf Techniken aufbaut, die bereits seit der Version 3.0 dabei sind. Ich bezweifle allerdings, dass es im großen Stil eingesetzt wird. Zum einen ist PowerShell Remoting in den Unternehmen und Behörden hierzulande aus meiner Erfahrung selber noch ein Nischenthema, zum anderen können solche Maßnahmen nicht von einzelnen Admins umgesetzt werden. Solche Initiativen müssen durch den IT-Leiter des Unternehmens oder der Abteilung vorgegegeben werden, damit sie zur Standardvorgehensweise werden. Und daran dürfte es dann wieder scheitern und dazu führen, dass das JEA-Toolkit dann doch eher als „Bastellösung“ betrachtet wird.

Bartosz Bielawski zeigte, wie sich per PowerShell WMI und DSC nicht nur Linux Server, sondern auch Switches von Arista (und Cisco) administrieren lassen. Das Bemerkenswerte an der Demo war, dass Bartosz auf seinem Notebook einen virtuellen Avista-Router verwendete, der in Gestalt eines fertigen Images auf der Webseite des Herstellers zur Verfügung steht. Er hat das in einem Artikel für das PowerShell Magazine sehr schön beschrieben:

http://www.powershellmagazine.com/2014/09/02/omi-and-networkswitch-module/

Die Nennung der drei „PowerShell-Gurus“ soll auf keinen Fall die Vorträge der anderen (PowerShell) -Experten Ulrich Boddenberg, Thorsten Butz, Peter Kriegel, Holger Schwichtenberg, Holger Voges und Jeff Wouters in den Schatten stellen, die ausnahmslos alle sehr gut waren (ich war allerdings nicht bei allen Vorträgen dabei). Tobias führte zwischendurch eine neue Version seines ISE Steorids vor, die ebenfalls beeindruckend war. Und anderen können Dialogfelder mit WPF in Visual Studio designt und der resultierende XAML-Code direkt in die ISE übernommen werden.

Eine vollständige Übersicht über alle Vortragsthemen gibt es unter der folgenden Adresse:

http://www.powershell.de/powershell/konferenz/Agenda.aspx

Eine wichtige Zutat eine jeder Konferenz ist der Erfahrungsaustausch. Dazu gab es zum einen während der Pausen zwischen den Vorträgen, vor allem aber am Abend
viele Gelegenheiten. Das Abendprogramm bestand dieses Mal aus einem gemeinsamen Abendessen im benachbarten Hotel (die Veranstalter hatten sich mit der Currywurst, die ja ideologisch eher dem Ruhrgebiet zugeordnet wird, auch wenn sie bekanntlich in Berlin erfunden wurde, auf den kleinsten gemeinsamen Nenner der deutschen Küche beschränkt. Für mich als Vegetarier blieben eine reichhaltige Salatbar und die als Beilage gedachten Folienkartoffeln;).

Nach dem Abendessen ging es ab 21 Uhr in einem kleinen Nachbarraum des Restaurants weiter. Zunächst mit einer Verlosung. Danach beantworte Bruce im Stehen geduldig alle Fragen, die an ihn gerichtet wurden. Dabei erfuhren wir unter anderem wie es zu der Variable $_ gekommen war. Bruce sprach: Das Zeichen _ soll eine „drunken pipe“ symbolisieren, also ein umgekipptes Pipeline-Symbol.

Ich habe die kleine „Offenbarung“ der PowerShell-Gemeinde auf einem Video festgehalten. Um halb elf war Schluss, wer Lust und Ausdauer hatte, konnte im Restaurant
Platz nehmen und den Abend mit alkoholischen Getränken ausklingen lassen.

Mein Vortrag am zweiten Tag ging um das Thema „Management OData“. Es ging konkret um die Frage, wie sich beliebige Cmdlets und Functions über OData-Webservices und damit über eine URL ausführen und die zurückgegebenen Daten weiterverarbeiten lassen. Solche Aufrufe werden nicht im Allgemeinen nicht Browser oder per PowerShell durchgeführt, sondern von einem mobilen Gerät aus, auf dem keine PowerShell läuft, etwa ein SmartPhone mit Android als Betriebssystem oder ein Rasberry Pi, auf dem Linux äuft. Solange sich auf dem Gerät Http-Aufrufe absetzen und Rückgabewerte im XML- oder JSON-Format auswerten lassen, können von diesem Gerät beliebige PowerShell-Cmdlets und -Functions auf einem Server ausgeführt werden.

Bei meinen Recherchen hatte ich den Eindruck, dass das Thema Management OData bei Microsoft inzwischen wieder „tot“ ist. Als ich Bruce am Ende meines Vortrags
direkt danach fragte erhielt ich als Antwort, dass Management OData in Zukunft sehr wichtig werden wird. Wenn ich ihn oder er mich (möglicherweise hatte er nur OData verstanden, das durch die Export-ODataEndpointProxy-Function tatsächlich deutlich aufgewertet wird) nicht falsch verstanden habe, ist das eine gute Nachricht, da in dem Thema sehr viel Potential steckt.

Nachdem mein Vortrag kurz vor 18 Uhr zu Ende war, war damit auch die die dritte PowerShell Community-Konferenz zu Ende, die allen Beteiligten wieder sehr viel „Stoff“
für die nächsten Monate verabreicht hat. Insgesamt war es eine überaus gelungene Konferenz.

Mit an Sicherheit grenzender Wahrscheinlickeit wird es 2016 wieder eine PowerShell-Konferenz geben. Der Termin dürfte Anfang 2016 auf www.powershell.de und www.pauaschell.de bekannt gegeben werden.

Hier sind ein Fotos von mir:
[Best_Wordpress_Gallery id=“1″ gal_title=“PS Community Konferenz 2015″]

Etwas bessere Fotos gibt es, inklusive des offiziellen Gruppenfotos, unter www.pauaschell.de.

Parametervalidierung per Script

Parametervalidierung ist eine sehr praktische Angelegenheit, denn sie bewirkt mit wenig Aufwand, dass ein Skript oder eine Function nicht mit unpassenden Parameterwerten aufgerufen werden kann. Die Validierung findet beim Aufruf statt, so dass if-Abfragen überflüssig werden und der Fehler bei einem unpassenden Parameterwert nicht „verschleppt“ wird und dadurch verzögert während der Ausführung des Skripts oder der Function auftritt.

Auch wenn die Schreibweise bedingt durch die ins Spiel kommenden Attribute (ein Attribut ist ein in eckige Klammern gesetzter Name, der z.B. einen Parameter um zusätzliche Informationen ergänzt) etwas „kompliziert“ wirken mag, ist der Umgang mit den Validierungsattributen sehr einfach, so dass ich diese Technik auch jenen PowerShell-Anwendern empfehle, für die Functions noch „Neuland“ sind.

Ein Validierungsattribut ist zunächst ein Name, der in eckige Klammern gesetzt wird, z.B. [ValidateRange].

Mit diesem Attribut würde überprüft werden, ob der Wert für den folgenden Parameter im angegebenen Bereich liegt. Der Bereich folgt in runde Klammern:

Mit dieser Angabe wird sichergestellt, dass der Wert des Parameters $Anzahl größer oder gleich 1 und kleiner oder gleich 10 ist. Wenn nicht, führt de Aufruf des Skripts oder Function zu einem Fehler.

In der Hilfe werden die Validierungsattribute unter „about_Functions_Advanced_Parameters“ beschrieben. Das Thema wird auch bei Durchsuchen der Hilfe per Platzhalter „ausgespuckt“:

Es gibt in der ISE auch eine Auswahlliste, die wie üblich per [String]+[Leertaste] geöffnet wird.

Auch für Parameterattribute gibt es eine Auswahlliste

Auch für Parameterattribute gibt es eine Auswahlliste

Parametervalidierung per Skript

Das folgende Beispiel zeigt eine Function mit den Parametern $StartDate und $EndDate. Durch Parametervalidierung soll sichergestellt werden, dass der Wert für $StartDate nicht in der Vergangeheit liegt und der Wert für $EndDate größer ist als der Wert für $StartDate. Das Beispiel zeigt damit auch, wie in die Parametervalidierung eines Parameters der Wert eines anderen Parameters angesprochen wird.

Klammern sparen bei ScriptBlock-Parametern

Wird einer Methode ein Scriptblock als Parameter übergeben, muss dieser nicht in runde Klammern gesetzt werden. Wie PowerShell-Entwickler Bruce Payette auf der PowerShell Community-Konferenz 2015 verriet, wies in sein Chef an dafür sorgen, dass Anweneder auf diese überflüssige Klammer verzichten können. Methodenaufrufe mit Scriptblock-Parametern werden damit etwas einfacher: