BCS auf SharePoint Online

Business Connectivity Services (BCS) sind ein sehr mächtiges Werkzeug der SharePoint Produktfamilie. Seit der Version 2010 lassen sich sowohl in der großen (SharePoint Server) als auch in der kleinen Version (SharePoint Foundation) komfortabel Verbindungen zu externen Datenquellen herstellen. Auch in den aktuellen SharePoint Online Angeboten stehen BCS zur Verfügung. Folgende Seite vergleicht die Features der SharePoint 2013 Versionen (online und herkömmlich)

Man sieht, dass für die BCS auf SharePoint Online derzeit der „Plan 2“ für € 5,70 (Stand Juli 2013) pro Benutzer und Monat erforderlich ist. Insbesondere um vor einer großangelegten Einführung die Möglichkeiten dieses Szenarios zu evaluieren, ist ein solches Angebot extrem hilfreich. Es lassen sich mit sehr kleiner Investition Lösungsansätze testen und ggf. sukzessive ‚upscalen‘.

Unsere ersten praktischen Tests bei einem in der Entwicklung befindlichen Produkt sind vielversprechend und werden als Lösungsvorschlag sicherlich vielfach Anwendung finden.

Folgender Link führt zu einer Anleitung zur Konfiguration von BCS und einer SQL Azure Datenbank.

Das Vorgehen unterscheidet sich nicht wesentlich von der Erstellung einer BCS Verknüpfung mit einer lokalen SharePoint Installation. Der einzige Stolperstein dem wir erlegen sind und den wir Ihnen gerne aus dem Weg räumen möchten, ist die Konfiguration der erlaubten IP Adresse Ihres SharePoint Online Systems. Wenn die IP Adresse ihres SharePoint Online Systems nicht bei Azure SQL als erlaubt eingetragen ist, geht die Konfiguration des BCS Services problemlos vonstatten. Erst, wenn Sie den Service über Ihren Browser aufrufen, sehen Sie die nicht sehr aufschlussreiche Fehlermeldung, dass es ein Problem beim Rendern der BCS Liste gab.

Wir hoffen, Ihnen mit diesem kurzen Artikel eine Anregung gegeben haben, SharePoint Online und BCS Services auszuprobieren und stehen Ihnen mit spezifischen Antworten und weiteren Infos natürlich gerne zur Verfügung.

SharePoint Server 2013 Trial als virtuelle Maschine auf Azure verfügbar

Vor kurzem wurde angekündigt, dass es als vorkonfiguriertes ‚virtual machine image‘ (VMI) auf Azure bald einen SharePoint Server 2013 geben wird. Nun ist es soweit und ein SharePoint Server ‚Trial‘ ist als VMI verfügbar. Die Trial Phase endet am 16. Oktober 2013  – bietet also ausreichend Zeit zum Testen.

Wir werden in diesem (und ggf. folgenden) Artikel(n) beschreiben, wie das Erstellen einer Serverinstanz, deren Konfiguration und Nutzung von statten läuft.

Auf jeden Fall sind wir selbst sehr gespannt, ob der Komfort, an den wir uns bei der Arbeit mit Webanwendungen, SQL Server Instanzen, mobilen- und storage Diensten so schnell gewöhnt haben auch bei einem virtuellen SharePoint Server in der Azure Cloud wiederkehren wird.

Diese Anleitung von Keith Maier (in englisch) beschreibt in 6 Schritten, wie eine Basisinstallation von statten geht. Die beschriebene Konfiguration umfasst:

• Windows Azure Virtuelle Maschine mit SQL Server 2012
• Windows Azure Virtuelle Maschine mit SharePoint Server 2013
• Windows Server Active Directory in einer Virtuelle Maschine
• DNS Server Service in Windows Azure
• Virtual Network in Windows Azure
• Zuletzt die Powershell Scripte um die erstellten Maschinen importieren und exportieren zu können

Insgesamt werden drei virtuelle Server erzeugt. Die empfohlenen Serverinstanzen sind: AD Server: Small (1 core, 1.75GB Memory); SQL Server: Medium (2 cores, 3.5GB Memory); SharePoint Server: Large (4 cores, 7GB Memory). Der letzte Schritt in der Anleitung ist sehr sinnvoll, da er beschreibt, wie die erzeugten Konfigurationen und ServerImages auf Azure gespeichert werden können und die Maschinen gestoppt und gelöscht werden. Das ist in einem Testszenario wichtig, da die virtuellen Maschinen auch im ausgeschalteten Zustand Kosten verursachen können.

Leider ist bisher kein Image einer kleinen SharePoint 2013 Foundation Lösung erhältlich. Dies wäre für ein noch schnelleres Hineinschnuppern in die SharePoint-Welt hilfreich. Wir geben aber natürlich bescheid, sobald ein solches Virtual Machine Template auftaucht.

WordPress Artikel auf anderen Webseiten

WordPress ist die wahrscheinlich meistgenutzte Blog Plattform im Internet. Seit einiger Zeit gibt es die Möglichkeit über eine REST API die Inhalte von WordPress Blogs auch automatisiert auszulesen und in anderen Kontexten zu nutzen. Dies können andere Webanwendungen oder auch mobile Apps sein. Für uns kam die Anforderung, diese Schnittstelle auszuprobieren aus einem eigenen Bedarf heraus. Wir wollten bestehende Inhalte unseres Blogs auf WordPress auch in die neu gestaltete Webseite einbinden. Zum Einen um die Inhalte nicht neu schreiben bzw. exportieren und importieren zu müssen, zum anderen sollen die Artikel auf dem WordPress Blog weiterhin gelesen werden. Zudem bietet dieser Ansatz, die Vorteile, das komfortable und vertraute Erstellen der Inhalte unverändert fortzuführen. Da unsere Webseite mit C# in .NET und dem MVC Framework umgesetzt ist, zeigen wir hier, wie von einer .NET Web Anwendung auf die beschriebenen Inhalte zugegriffen werden kann.
Die komplette Beschreibung der API von WordPress finden Sie hier: http://developer.wordpress.com/docs/api/
Auf sämtliche Inhalte lässt sich über http Aufrufe zugreifen. Neben lesenden Zugriffen lassen sich auch Inhalte erstellen oder ändern. Für unsere Anforderungen reicht allerdings das Auslesen der Blogeinträge.
Als Einstiegspunkt benötigen wir die Basis-URL der WordPress API. Diese lautet: https://public-api.wordpress.com/rest/v1/
An diese URL wird /sites/#BLOGID#/posts/ angehängt, wobei #BLOGID# ein ganzzahliger Wert ist, der die gewünschte Blogseite identifiziert oder alternativ die URL der Blogseite z.B. „intuisoft.wordpress.com“. Die vollständige Basis-URL zum Zugriff auf die Blog-Inhalte lautet somit:
https://public-api.wordpress.com/rest/v1/sites/intuisoft.wordpress.com/posts/
Das Ergebnis wird im JSON Format zurückgegeben. Dieses Ergebnis können wir in unserer Webanwendung auslesen. In diesem Beispiel zeigen wir wie dies von C# aus geht:
Zunächst muss die Bibliothek System.Net.Http eingebunden werden:

using System.Net.Http; using System.Net.Http.Headers;

Danach wird die oben erläuterte URL spezifiziert und ein HttpClient instanziiert:

Public static string wpAPIuri = „https://public-api.wordpress.com/rest/v1/ „; Public string wpPath = „sites/intuisoft.wordpress.com/posts/?pretty=false“; HttpClient client = new HttpClient();

Nun wird die Basisadresse übergeben und dem Client mitgeteilt, dass wir ein Ergebnis im JSON Format erwarten:

client.BaseAddress = new Uri(wpAPIuri); client.DefaultRequestHeaders.Accept.Add(new MediaTypeWithQualityHeaderValue(„application/json“));

Es wird ein Aufruf an die WordPress Adresse gesendet und mittels GetAsync() mit der Fortführung gewartet bis das Ergebnis vorliegt. Die zurückgegebene Antwort liegt als HttpResponseMessage vor. Die beiden Klassen WParticles und WPpost definieren die notwendige Datenstruktur um die gewünschten Artikel von WordPress entgegenzunehmen und die Attribute, die wir weiterverarbeiten möchten aufzunehmen. Über eine Auswahl der möglichen Felder in WPpost lassen sich die Attribute von Interesse verwerten. Der Umfang an Feldern pro Blogeintrag ist größer als hier angegeben. Ein Blick in die Dokumentation zeigt zusätzliche Felder, die möglicherweise für Sie interessant sind.

HttpResponseMessage response = client.GetAsync(wpPath).Result; WParticles myRoot = new WPaticles(); if (response.IsSuccessStatusCode) { myRoot = (WParticles)response.Content.ReadAsAsync(myRoot.GetType()).Result; WPpost[] Ergebnis = myRoot.posts; } class WParticles { int found { get; set; } WPpost[] posts { get; set; } } class WPpost { int ID { get; set; } string date { get; set; } string title { get; set; } string content { get; set; } string excerpt { get; set; } string featured_image { get; set; } string URL { get; set; } }

Ein Array vom Typ WPpost nimmt das Ergebnis entgegen. Damit können die empfangenen WordPress Artikel in einem anderen Kontext eingebunden werden.

Um nicht alle Artikel zu laden, lassen sich bestimmt Anfrageparameter angeben. Wird beispielsweise „&category=sharepoint“ an den String wpPath angehängt, werden nur die einer bestimmten Kategorie zugehörigen Artikel abgefragt. Es kann auch nach Tags gefiltert werden. Die Ergebnisse lassen sich unterschiedlich sortieren oder zeitlich einschränken. Für die vollständige Liste der Möglichkeiten schauen Sie sich bitte die Dokumentation auf WordPress an.

Dieser Artikel hat gezeigt, wie sich automatisch Inhalte von WordPress Blogs auslesen lassen. Webanwendungen oder Apps können so elegant und universell auf eigene Artikel oder auf Artikel von anderen Blogs zugreifen. Äquivalent lässt sich diese API auch nutzen um Artikel zu posten oder Inhalte zu ändern. Wenn Sie noch genauere Informationen brauchen oder spezifische Fragen haben, zögern Sie nicht, Kontakt mit uns aufzunehmen.

Neuer Look

DriveCool die Windows Phone App zum Benzinsparen hat einen neuen Look bekommen:

  

Vielen Dank an Funs Kurstjens und www.sugarforall.org für die leckere Gestaltung!

driveCool Version 1.3 in den Marktplatz eingereicht

Bei diesem Update geht es um Statistik. Eine neue Panoramaseite zeigt die rot, gelb, grüne Verteilung für Beschleunigung und Geschwindigket. In den drei derzeit verfügbaren Sprachen sieht das so aus:

Link zum Marketplace

Wissen wo die Kunden sind

Die Windows Phone App ‚DriveCool‘ ist seit ca. 3 Wochen im Marketplace verfügbar. Derzeit in den zwei Sprachen Englisch und Deutsch. Im sogenannten APP HUB in dem der Ersteller eine App verwalten kann, lassen sich Statistiken zu den Downloads einsehen. Sehr interessant ist die Verteilung über die verschiedenen Länder, die bisher wie folgt aussieht:

Die russischsprachigen Länder machen fast die Hälfte aller Downloads aus. Damit steht fest, welche Sprache wir beim nächsten Update unterstützen werden.

Ankündigung DriveCool

intuisoft hat die nächste Windows Phone App gelauncht: DriveCool – Benzin sparen mit Windows Phone 7

Wenn es um die steigenden Benzinpreise geht, hört man immer wieder “Durch sparsames Fahren, kannst Du 10% weniger Sprit verbrauchen”. Wenn man sich die Fahrweise in der “freien Wildbahn” anschaut, scheinen aber nur wenige Verkehrsteilnehmer dieses Potetial erkannt zu haben.

Neben den vielen guten Tipps gibt es nun eine Smartphone App, die ein ganz konkretes Werkzeug zum sparsamen Fahren bietet: “Drive Cool” zeigt im Auto die akuelle Beschleunigung und Geschwindigkeit in zwei übersichtlichen Diagrammen an. Man kann nun direkt sehen und trainieren, wie sich durch vorausschauendes Fahren mit einer gleichbleibenden Geschwindigkeit der Verbrauch reduzieren lässt.

Geodaten in SQL Server Reporting Services – Teil 2: Die Karten – Reporting Services Map Control

Miniserie zu Geodaten in SQL Server Reporting Services

• Intro
• Teil 1 befasst sich mit der Verarbeitung von Geodaten im Microsoft SQL Server 2008.
• Teil 2 zeigt die Visualisierung dieser Daten auf Karten innerhalb der Reporting Services.

Zum Erzeugen eines Reports lassen sich wahlweise das Business Intelligence Development  Studio oder der Report Builder 3.0 verwenden. Bei der folgenden Beschreibung setzen wir voraus, dass ein grundlegendes Verständnis über die Arbeit mit SQL Server Reports vorhanden ist.

Wir benötigen in unserem Report eine Data Source und ein Dataset, die alle Spalten aus unserer Tabelle mit einem GeoDatentyp enthalten.

Mit einem Rechtsklick in den Report und ‚Insert‘ -> ‚Map‘ fügen wir ein neues Kartenelement in den Report ein. Das Kontextmenu der Karte erlaubt, die Layer der Karte zu definieren. Wir fügen einen neuen ‚Point Layer‘ sowie einen ‚Tile Layer‘ ein. Über das Kontextmenu der Layer lassen sich die jeweiligen Eigenschaften festlegen. Im Tile Layer lässt sich z.B. festlegen, ob Straßenkarten oder Satellitenansicht gezeigt werden soll. Interessanter sind allerdings die Einstellungen, die wir an dem Point Layer vornehmen müssen.

Zuvor müssen wir aber die Daten aus dem Dataset für unseren Zweck aufbereiten. Dazu machen wir einen Rechtsklick auf das Dataset und wählen ‚Query‘. Der Querydesigner erlaubt uns komfortabel die Daten auszuwählen, die wir auf der Karte anzeigen wollen. Wir wählen sämtliche Spalten der Tabelle und fügen einen Filter auf die ‚trackID‘ hinzu, den wir auch als Parameter des Reports ausweisen. Auf diese Weise bekommen wir sämtliche Punkte eines Tracks zu einer gegebenen trackID.

Danach gehen wir wieder in das Menu der Karte. Im Kontextmenu des Point Layer klicken wir auf ‚Layer Data‘. Im Tab ‚General‘ wählen wir aus, dass unsere Geodaten aus einem ‚spatial field‘ in einem Dataset stammen. Dataset und Spaltenname lassen sich auswählen.

Nun sind wir bereit, den Kartenreport zum ersten Mal auszuführen. Das Ergebnis ist noch nicht hübsch, aber es läuft schon mal.

Als letzten Schritt werden wir nun die Farbe der Punkte in Abhängigkeit eines Wertes aus der Datenbank setzen. In unserem Beispiel bietet sich dazu die Höhe über Normal Null an, deren Wert zu jedem Punkt im Feld ‚ele‘ steht. Dazu gehen wir wieder in das Kontextmenu des Point Layer und wählen dort ‚Point Color Rule…‘. Dort im Reiter ‚General‘ -> ‚Change color rules for Points‘ wählen wir ‚Visualize data by using color ranges‘, dann aus der Dropdown Box ‚Data field‘ das Feld ‚#ele‘. Die Werte für Start, Middle und End color lassen wir auf grün gelb und rot. Im nächsten Reiter ‚Distribution‘ setzen wir das Feld ‚Change distribution options to divide data into subranges‘ auf ‚Optimal‘; die ‚Number of subranges‘ auf 5; ‚Range start‘ auf 0 und ‚Range end‘ auf 1000.

Danach sieht der Report mit Karte wie folgt aus und visualisiert das Höhenprofil der Strecken in fünf Farbverlaufsbereichen von grün bis rot.

Credo

Diese Artikelserie zeigt praktisch, wie sich Geodaten in Microsoft SQL Server einfügen lassen um sie daraufhin in den Reporting Services grafisch anzuzeigen. Ein Punkt, der bei diesem (und ähnlichen) Lösungsszenarien nicht ausser Acht gelassen werden sollte, ist die Frage der Nutzungsrechte für die Online Karten. Als Fausregel gilt, dass die Benutzung der Karten dann kostenlos ist, wenn die Darstellung öffentlich im Internet erfolgt. Wenn die Nutzung in einem geschlossenen Benutzerkreis vorbehalten ist, werden in der Regel Lizenzgebühren fällig.

Wir hoffen, dass der vorgestellte Lösungsansatzt auf Interesse stößt und zur Umsetzung eigener Ideen anregt. Bei weitergehenden Fragen zögern Sie nicht, uns direkt anzusprechen oder einen Komentar in zu diesem Artikel zu posten.

Geodaten in SQL Server Reporting Services – Teil 1: Geodaten erfassen und in den SQL Server einfügen

Miniserie zu Geodaten in SQL Server Reporting Services

• Intro
• Teil 1 befasst sich mit der Verarbeitung von Geodaten im Microsoft SQL Server 2008.
• Teil 2 zeigt die Visualisierung dieser Daten auf Karten innerhalb der Reporting Services.

Woher kommen Geodaten und wie müssen diese aufbereitet werden, um sie in den SQL Server einzufügen? Beliebt ist der Satz: Sie alle benutzen doch schon Geodaten in Ihrer Datenbank nämlich in Form von Adressinformationen z.B. von Kunden. Adressdaten müssen bevor sie als Geodaten in der Datenbank noch in den einfachsten Geodatentyp – einen Punkt als Längengrad/Breitengrad umgewandelt werden. Diesen Vorgang nennt man Geocodierung. Er wird z.B. von den gängigen APIs der Onlinekartendienste Google oder Bing unterstützt.

Es gibt sowohl viele frei verfügbare als auch kommerzielle Geodaten im Internet. Viele Beispiele verwenden die ‚Mondial‘ Datenbank der Uni Göttingen, von der auch SQL Skripte für den MS SQL Server existieren.

In diesem Beispiel möchten wir die Geodaten allerdings selber erzeugen – auch um zu demonstrieren, wie sich eigene Geodaten verarbeiten lassen. Es existieren unzählige mobile Anwendungen auf allen gängigen Plattformen, um die eigene Position mittels GPS aufzuzeichnen. Ein gängiges Austauschformat für Geodaten ist das XML basierte .gpx Format. Auf der Routenwebseite für Sportler http://connect.garmin.com beispielsweise lassen sich GPS Strecken als .gpx Datei herunterladen.
Der Inhalt einer solchen Datei enthält folgende XML Elemente, die uns interessieren:

<trk>

<name>Kloster Lluc</name>
<trkseg>
<trkpt lon=„3.1172070745378733“ lat=„39.808602472767234„>

<ele>36.400001525878906</ele>
<time>2011-10-27T08:03:15.000Z</time>

</trkpt>
<trkpt lon=„3.11720154248178“ lat=„39.80860289186239„>

<ele>36.400001525878906</ele>
<time>2011-10-27T08:03:16.000Z</time>

</trkpt>
…

Leicht lässt sich hier die hierarchische Datenstruktur erkennen: Ein Track (<trk>) enthält einen Namen (<name>) und Tracksegmente (<trkseg>). Ein Tracksegment enthält mehrere Trackpunkte (<trkpt>) und ein Trackpunkt besitzt die Eigenschaften longitude und latitude (lon,lat) sowie die Elemente Elevation (<ele>) und Time (<time>).

Ein kleines Windows Forms Programm liest eine gegebene .gpx Datei ein und erzeugt daraus die SQL Kommandos, welche dann auf der Datenbank ausgeführt werden und diese mit den entsprechenden ‚geography‘ Werten befüllt. Interessenten stellen wir das Programm incl. Code gerne auf Anfrage zur Verfügung.

Der erzeugte SQL Code sieht folgendermaßen aus:

INSERT INTO [intuiGeoDB].[dbo].[trackpoints] ([trackID],[ptID],[trkpt],[ele],[time])
VALUES(1,0, geography::STGeomFromText( ‚POINT(3.1172070745378733 39.808602472767234)‘, 4326), 36.400001525878906, ‚2011-10-27T08:03:15.000Z‘)

Die Tabelle ‘trackpoints’ der Datenbank ‘intuiGeoDB’ enthält eine Spalte ‘trkpt’ vom Geodatentyp geography:

Der obige SQL Befehl füllt die Werte trackID und ptID des GPS Punktes sowie die eigentliche Koordinate mittels der Funktion geography::STGeomFromText()in die Datenbank. Die Werte für den Längen- und den Breitengrad werden im Textformat übergeben. Der numerische Wert ‚ele‘ entspricht der Höheninformation über dem Meeresspiegel und kommt wie auch der Zeitstempel ‚time‘ aus den XML Elementen.

Nachdem nun die Geodaten im SQL Server gespeichert sind, zeigen wir im zweiten Teil, wie diese Daten mittels der SQL Server Reporting Services grafisch auf einer Karte angezeigt werden können.

Grafische Kartendarstellung von ortsbezogenen Daten in den Microsoft SQL Server™ Reporting Services

Miniserie zu Geodaten in SQL Server Reporting Services

• Intro
• Teil 1 befasst sich mit der Verarbeitung von Geodaten im Microsoft SQL Server 2008.
• Teil 2 zeigt die Visualisierung dieser Daten auf Karten innerhalb der Reporting Services.

 

Seit der Version 2008 unterstützt der SQL Server von Microsoft Geodaten (auch: räumliche Daten, spatial data) als nativen Datentyp. Damit ergeben sich neue spannende Möglichkeiten der Anwendungsentwicklung. Einfache räumliche Daten existieren bereits in vielen Datenbanken in Form von Adressen oder Ländercodes. Immer mehr mobile Geräte sind mit GPS Sensorik ausgestattet. Dadurch erhalten diese Daten eine immer größere Verbreitung und laden ein, interessante Anwendungen mit ihnen zu erstellen. Viele Webanwendungen integrieren Geodaten in Form von interaktiven Anwendungen, die auf Online Kartendiensten wie Bing- oder Google-Maps dargestellt werden.

In einer kleinen Artikelserie möchten wir hier eine alternative Art zeigen, Geodaten auf Onlinekarten anzuzeigen und zwar mittels SQL Server™ Reporting Services. Die Reporting Services sind ein Modul des SQL Servers um Berichte zu erstellen und zu veröffentlichen. Nähere Infos zu Reporting Services finden sich hier. Informationen zu den Geodatentypen (spatial datatypes) des SQL Server finden sich hier.

Besonderer Dank gilt der BLUESITE GmbH, für die freundliche Unterstützung dieses Artikels.