SharePoint-Wetter-Web-App: Die erste SharePoint 2013 App von adesso

Erfahrungen aus Entwickler-Sicht

10. Oktober 2013Merlin Brohl

Ein Dienstagmorgen Ende 2012: Mein Handy piept und zeigt eine vielversprechende E-Mail an:

Betreff: „Weather Web Part“
„Hi Merlin, mach das Wetter-Web-Part bitte SharePoint 2013 kompatibel. Wir machen daraus eine SharePoint App und laden sie in den Microsoft Store;-)“
(Mail von meinem Competence Center Leiter Marcus Peters)

Das Los hatte also mich getroffen. Mein SharePoint-Wetter-Web-Part wird zur ersten adesso-App im SharePoint Store.

Über SharePoint 2013 und das App-Konzept hatten wir intern natürlich schon ausgiebig gesprochen. In der Theorie war das also nichts Neues. Nur die Praxis sollte mir noch ein paar Probleme bereiten.

Eine SharePoint 2013 App ist im Prinzip nichts anderes als eine Webseite, die per REST mit SharePoint kommunizieren kann. Dabei kann man wählen, ob man sie in der Azure-Cloud, auf einem eigenen Server oder direkt in SharePoint hostet. Wenn die App in einem IFrame innerhalb einer SharePoint-Seite angezeigt werden soll, spricht man von einem App Part.

Für meine App kam hier nur eine SharePoint hosted App mit App Part in Frage. Das Problem bei der Sache: In diesem Fall ist man beschränkt auf ASP.Net-Seiten ohne CodeBehind. Die ganze Logik des Web Parts lag allerdings im CodeBehind. Das bedeutete für mich: Ich musste alles in JavaScript übersetzen. Dazu kam weiterhin, dass die Einhaltung der Bedingungen der eingesetzten Wetter-API so nicht garantiert werden konnte. Also musste ich mich auch nach einer anderen API umsehen.

Die Wahl fiel auf die Open Weather Maps API. Diese liefert per REST-Aufruf ein JSON-Objekt mit den gewünschten Daten. Die Aufrufe an diese API müssen über einen SharePoint WebProxy erfolgen, da somit kein Cross Domain Call erfolgt. Der SharePoint Server holt also im Namen der App die Wetterdaten von der API und gibt sie an die App weiter – praktisch.

Als nächstes stellte sich mir die Frage: Wie soll die App denn eigentlich aussehen? Die Schwierigkeit besteht darin, dass die App zusammen mit anderen Apps auf einer Seite angezeigt wird. Der Nutzer sollte daher die Möglichkeit haben, diese gut in das visuelle Gesamtbild seiner SharePoint-Umgebung einzufügen. Ich habe mich daher dazu entschieden, die Oberfläche als SVG-Grafik zu gestalten, so dass sie problemlos skaliert werden kann. Eine SVG-Grafik ist eine XML-Datei, die mithilfe von JavaScript angepasst werden kann –  dadurch entsteht sozusagen ein dynamisches Bild mit den aktuellen Wetterdaten.

Generell sollte man sich in der App-Entwicklung gut mit JavaScript auskennen. Damit die JavaScript-Entwicklung in keinem Spaghetti-Code endet, habe ich in Zusammenarbeit mit Thomas Deutsch die App-Logik auf Basis von AngularJS entworfen. Dadurch ergeben sich gute Möglichkeiten, den Code modular und testbar zu gestalten. Mit AngularJS fällt es leichter, bestehende „Best Practices“ zu nutzen, um die Architektur schnell und gezielt zu definieren. Dann ging es an die Entwicklung.

Nach ein wenig Tastaturgeklapper und einigen Tests hatten wir eine Vorläuferversion der App, noch ohne App Part. Das sah gut aus, also konnte ich mich an das App Part machen.

Dazu noch ein wenig Theorie: Wie gesagt ist ein App Part ein IFrame in einer SharePoint-Seite. Man definiert es, indem man einen ClientWebPart anlegt, das die App in einen IFrame einbettet. Dabei kann man wie bei jedem Web Part sogenannte Web (bzw. App) Part Properties definieren, die entweder jeder Benutzer oder nur der Administrator verändern kann. Bei einem App Part werden sie mit der URL Query übergeben.

Die Definition sieht (gekürzt) etwa so aus:


<?xml version="1.0" encoding="utf-8"?>

<Elements xmlns=“http://schemas.microsoft.com/sharepoint/“>

<ClientWebPart Name=“WeatherAppPart“ Title=“adesso Weather“ Description=“Displays the current weather and a forecast for the next two days.“ DefaultWidth=“184″ DefaultHeight=“168″ >

<Content Type=“html“ Src=“~appWebUrl/Pages/Weather.aspx?{StandardTokens}&amp;woeid=_woeid_&amp;Units=_Units_&amp;editmode=_editMode_“ />

 

<Properties>

<Property Name=“woeid“ (…) WebDisplayName=“WOEID“ />

<Property Name=“Units“ (…) WebDisplayName=“Units“>

<EnumItems>

<EnumItem Value=“c“ WebDisplayName=“Metric“/>

<EnumItem Value=“f“ WebDisplayName=“US customary“/>

</EnumItems>

</Property>

</Properties>

 

</ClientWebPart>

</Elements>

 

Wer sich mit Web Parts auskennt, wird sich damit schnell zurechtfinden. Die Properties werden dort genau so definiert. Aber ein kleines Detail hat mir hier Kopfschmerzen bereitet, denn der Content-Knoten sieht ursprünglich folgendermaßen aus und den hatte ich nicht verändert, weil ich die entsprechende Zeile in der Dokumentation übersehen hatte:


<Content Type="html" Src="~appWebUrl/Pages/Weather.aspx?{StandardTokens}/>

 

Die Properties werden nicht automatisch an die URL angehängt. Man kann den URL-Parametern beliebige Namen geben. Wichtig ist hier nur, dass hinter dem Gleichheitszeichen der Name der Property zwischen zwei Unterstrichen steht. Übrigens, _editMode_ ist genau dann 1, wenn die App-Part-Eigenschaften geöffnet sind. So unterscheide ich in der App zwischen der Ortssuche und der Wetteranzeige.

Nachdem ich auch diese Hürde genommen hatte, war die App bereit zum Upload in den SharePoint Store. Nach ein paar Verbesserungswünschen von Microsoft sowie zwischenzeitlich geänderter Qualitätsmerkmale steht die adesso-Wetter-App jetzt im SharePoint Store zum freien Download zur Verfügung.

Haben Sie bereits eine App für SharePoint entwickelt? Wie sind Ihre Erfahrungen und welche Tipps haben Sie? Teilen Sie uns gerne Ihre Meinung mit oder stellen Sie weitere Fragen zum Thema.

Merlin Brohl Merlin Brohl ist seit 7 Jahren in der Softwareentwicklung tätig. Bei adesso arbeitet er als Software Engineer und ist seit zwei Jahren im SharePoint-Umfeld unterwegs.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentar hinzufügen:

Ihr Kommentar: