Smartphones and their descendants are a milestone in the megatrend “internet of things” and the impact on people’s lives is still growing (“The One Chart You Need To See To Understand Mobile”).

While networks and software also have evolved dramatically and are contributing to this development, people just love their “Smart”-Phone, the gadget they are used to taking with them everytime, everywhere– but which is now enabling users to do tasks you would otherwise need a computer for. See the latest sales news where smartphones are outperforming computer sales including tablets/pads.

To use this mobile communication, networking and data-sharing channel can be promising for organizations too, having transactions as well as decisions happen in a mobile world. Not surprisingly the # 1 topic for CIOs in 2012 is supposed to be “Mobile” – even before “BI” in second place. (Gartner)

After the mobile BI market had already got noticable attention last year and most of the big platform vendors had their tool/app in place back then, the positioning of Microsoft in the market of mobile BI was long awaited. Chris Web summarized it with the question “What is Microsoft’s mobile BI strategy?”

The answer was first found in form of a powerpoint slide roadmap presenting 3 steps:

1. Web based solutions run across all platforms (first half 2012)
2. Touch-based data exploration and visualization (second half 2012)
3. Immersive experience of the Microsoft BI platform on Windows 8 slates

A small glimpse of the future’s touch & feel regarding the 2. roadmap-bulletpoint (“Touch-based data exploration and visualization”), named PowerView, could be found at the Microsoft SQL PASS Summit in last October.

Even though the question regarding mobile BI was addressed and the outlook with PowerView looks interesting, there are still some unanswered questions (“So little?”, “So late?”, “No iPhone-App?”, “Silverlight on iPad?”) and having nothing in place for customers ready for mobile BI right now seems unsatisfying.

But is there really a lack of mobile in the current Microsoft BI Stack?

While reading the press it seemed so: Progress on roadmap-bulletpoint 1 (“Web based solutions run across all platforms") appears to be related only to Excel Services or PowerPoint Services on the iPad and Microsoft directs current requests for mobile BI to partner solutions. By the way, feel free to check out our Microsoft mobile BI Partner Solution BI.mobile on Microsoft PinPoint or with some pictures at ORAYLIS.

But actually while developing BI and mobile BI solutions based on the Microsoft BI stack you’ll find another answer. For example that Reporting Services can be tweaked to generate nice mobile BI experiences or can be a powerful middleware for mobile apps like in the case of  the partner solution ORAYLIS BI.mobile:

Both approaches can be used in conjunction. They are enabling companies where BI stacks are based on Microsoft, to go mobile right away, without having to implement a parallel stack just for mobile delivery.

Yes – there is a lack of mobile in the current Microsoft BI Stack – but more in means of communication.

The Microsoft BI stack is offering all the components to build mobile (BI) solutions. The resulting architecture can be wrapped in a framework for easier and faster adaption. ORAYLIS BI.mobile is built that way too.

So Microsoft’s mobile BI strategy bullet point 1 (“Web based solutions run across all platforms") is probably not communicated well. By using the in place Microsoft BI components like Reporting Services and Analysis Services, Microsoft’s general BI strategy “BI for the masses” can already be  deduced to “mobile BI for the masses”.

With that in mind, Microsoft’s decision not to develop a “one-fits-all” iPhone/Android app like other big platform vendors have released, is not that bad. Mobile frontends have to adapt to business as quickly as other frontends do and the shift from “by” to “make” is already happening in the mobile enterprise world. Being able to use the tools and technologies that are already known to a company for a new mobile channel is thrilling, fast implementation and adaption rates as well as the flexibility to meet companies individual demands is a big advantage.

The time for Mobile is now and this is definitely also true for the growing number of Microsoft customers following the strategy “BI for the masses”.

Um eigene Assemblies (z.B. Webparts, Web Controls oder User Controls) im SharePoint verwenden zu können, müssen diese als sogenanntes “SafeControl” registriert werden. Die Registrierung des SafeControl muss in der web.config Datei der Webapplikation erfolgen, in welcher die Assembly verwendet werden soll.

Der Eintrag in der web.config setzt sich mindestens wie folgt zusammen:

<configuration>
   <SharePoint>
     <SafeControls>
       <SafeControl Assembly="[Assembly Name]" Namespace="[Namespace]" TypeName="*" Safe="True" />
     </SafeControls>
   </SharePoint>
</configuration>

Assembly: Name der Assembly, in welcher die eigentliche Funktionalität implementiert ist. Es wird empfohlen, an dieser Stelle den “$SharePoint.Project.AssemblyFullName$”-Parameter zu verwenden. Dies ist ein ersetzbarer Parameter, welcher den “strong Name” der Assemby darstellt. Mehr Informationen zu ersetzbaren Parametern können der MSDN entnommen werden: http://msdn.microsoft.com/de-de/library/ee231545.aspx.

Namespace: Der Namespace, in welchem sich die Controls oder der Webpart befindet. Sollten sich die eigenen Controls in mehreren Namespaces befinden, so muss pro Namespace ein SafeControl Eintrag erstellt werden.

TypeName: Der Name des Controls, welchem es erlaubt werden soll im SharePoint ausgeführt zu werden. Sollten in einem Namespace mehrere Controls vorhanden sein, so muss nicht für jedes Control ein SafeControl registriert werden. Stattdessen kann als TypeName ein Sternchen (*) verwendet werden, um die gesamte DLL zu registrieren.

Safe: Boolean-Wert, welcher angibt, ob das Control sicher (true) oder nicht sicher (false) ist.

Um ein SafeControl zu registrieren gibt es verschiedene Möglichkeiten:

• Manuelles Hinzufügen des SafeControls zur web.config Datei (schlecht, dieses Vorgehen sollte nur zu Entwicklungs- und Testzwecken verwendet werden und niemals in einem Produktivsystem zum Einsatz kommen)
• Hinzufügen des SafeControls via Code (besser)
• Veröffentlichen einer Assembly als Solution Package (.wsp Datei) (empfohlen)

Manuelles Hinzufügen des SafeControls

Das manuelle Hinzufügen eines SafeControls zur web.config Datei erscheint auf den ersten Blick als einfachster und schnellster Weg. Es ist jedoch ausdrücklich nicht zu empfehlen, die web.config Datei selbst anzupassen.

Warum ist dieses Vorgehen nicht empfehlenswert? Was zu Beginn als einfach und schnell umzusetzen erscheint verursacht schnell einen enormen Pflege- und Administrationsaufwand. Solange man sich auf einem einzelnen SharePoint Server bewegt muss man den SafeControl Eintrag nur in die web.config Datei der gewünschten Applikation eintragen. Befindet man sich nun jedoch in einer kleinen Server Farm mit zwei Servern und möchte seine Assembly für fünf verschiedene Applikationen zur Verfügung stellen, so muss man bereits zehn web.config Dateien anpassen. Wenn nun noch ein weiterer Server zur Farm hinzugefügt wird, dann muss daran gedacht werden, die Änderung der web.config auch auf dem neuen Server durchzuführen.

Unterm Strich ist dies die aufwändigste und vor allem fehleranfälligste Variante. Sie eignet sich nur zu Entwicklungs- und Testzwecken.

Hinzufügen des SafeControls via Code

Das SharePoint Objekt Modell stellt die Klasse “SPWebConfigModification” zur Verfügung. Mit Hilfe dieser Klasse können aus dem Code heraus Änderungen an der web.config Datei einer Applikation vorgenommen werden.

Die so vorgenommenen Änderungen werden auf allen Servern der Farm ausgeführt und wirken sich auch auf neu hinzugefügte Server aus.

Um den Code zu verwenden kann z.B. die Methode “FeatureActivated” überschrieben werden. Dazu ist es jedoch erforderlich, dass die eigene Assembly über ein Feature deployed wird.

Folgender Code kann zur Anpassung der web.config Datei verwendet werden:

SPWebApplication webApp = site.WebApplication;

// Erweiterung der web.config definieren
SPWebConfigModification configMod = new SPWebConfigModification(
  "SafeControl[@Assembly=\"MyAssembly\"][@Namespace=\"My.Namespace\"]"
  + "[@TypeName=\"*\"][@Safe=\"True\"], "/configuration/SharePoint/SafeControls"
); 

// Die Aenderung der ModificationCollection hinzufuegen
webApp.WebConfigModifications.Add(configMod); 

// Die Aenderung anwenden
webApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();

Veröffentlichen einer Assembly als Solution Package

Die empfohlene Vorgehensweise, um eigene Webparts, Features, Assemblies etc. zu veröffentlichen ist die Erstellung eines Solution Packages (.wsp Datei). Gerade mit SharePoint 2010 sollte dies der einzigste noch verwendete Weg sein, da nun auch SharePoint selbst alle Features als wsp zur Verfügung stellt. Selbst über die Oberfläche gespeicherte List- oder Sitetemplates werden nun als .wsp Datei zur Verfügung gestellt.

Während früher für die Registrierung des SafeControls noch die Manifest Datei des Solution Packages angepasst werden musste, bietet Visual Studio 2010 heute eine einfache Oberfläche für diese Aufgabe. In den meisten Fällen wird diese Aufgabe sogar automatisch von Visual Studio 2010 durchgeführt (z.B. wenn ein Webpart zu einem SharePoint Projekt hinzugefügt wird).

Sollte Visual Studio die Einstellung nicht automatisch vorgenommen haben (dies passiert z.B. beim Erstellen einer Custom Action, welche zusammen mit einem User Control verwendet wird), so kann diese mit wenigen Klicks nachgeholt werden:

1. Im Visual Studio die gewünschte Datei (z.B. das Modul, in welchem die eigene Assembly liegt) markieren und im Properties Fenster den Eintrag “Safe Controls Entries” öffnen.

   

2. Es wird ein neues Fenster geöffnet, in welchem die erforderlichen SafeControl Einträge gesetzt werden können. Visual Studio 2010 füllt diese Maske bereits mit Standardwerten und verweist dabei auf die Assembly des aktuellen Projektes. Wenn diese Maske wieder geschlossen wird, werden die vorgenommenen Änderungen automatisch in das Solution Manifest eingetragen, mehr muss nicht getan werden.

   

Die auf diese Weise registrierten SafeControls werden beim Deployment des Solution Packages automatisch allen Servern hinzugefügt und gelten auch für alle zukünftig hinzugefügten Server.

Für die Excel Services auf den SharePoint Server 2010 werden Enterprise CAL’s benötigt.
Leider bietet der SharePoint Server 2010 aktuell nur die Möglichkeit, Enterprise Features FARM weit zu aktivieren. Aus technologischer Sicht ist es für den SharePoint Server 2010 irrelevant, ob für alle Benutzer Enterprise CAL’s zur Verfügung stehen da jeder User bspw. Excel Services nutzen kann.

Sobald eine Service Application für den Excel Service angelegt wurde, versucht der SharePoint 2010 alle Excel Dateien (ab Excel 2007 aufwärts) im Browser zu öffnen. Für den SharePoint 2010 ist es irrelevant, ob die Enterprise Features für eine SiteCollention aktiviert oder deaktiviert sind. Falls die Features jedoch nicht aktiviert sind, bekommt der Benutzer eine Fehlermeldung.

Dieses Verhalten ist in einigen Szenarien hinderlich, wenn z.B. der SharePoint als Fileserver genutzt wird und es jedoch nur eine begrenze Anzahl an Enterprise Lizenzen für ausgewählte Benutzer gibt.

In diesem Fall muss der SharePoint Server 2010 daran gehindert werden, die „normalen“ Excel Dateien im Browser zu öffnen, indem die Websitesammlungs-Feature „Dokumente standardmäßig in Clientanwendungen öffnen“, aktiviert wird.

Sobald diese aktiv ist, werden alle Dokumente nur noch mit den lokal installieren Anwendungen geöffnet, z.B. Excel 2010 oder Word 2010.

Um dem ausgewählten Benutzer-Kreis dennoch das Öffnen von Excel Dateien über Excel Service im Browser zu ermöglichen, muss eine Dokumenten Bibliothek angelegt werden. In dieser Bibliothek werden nun die „speziellen“ Excel Dateien gespeichert. Die Berechtigung für diese Dokumenten Bibliothek sollte so eingestellt werden, dass nur Benutzer mit einer Enterprise CAL Zugriff haben.
Letztendlich muss in den erweiterten Einstellungen dieser Dokumenten Bibliothek noch die Funktion „Dokumente im Browser öffnen“ aktiviert werden.

Nachfolgend die detaillierte Beschreibung für beide Einstellungen:

Webseiten Einstellungen

1. Klickt in der SharePoint-Zentraladministration auf Websiteaktionen und anschließend auf Websiteeinstellungen.

2. Klickt auf der Seite Websiteeinstellungen im Abschnitt Websitesammlungsverwaltung auf Websitesammlungs-Features.

3. Klickt auf der Seite Features für das Feature Dokumente standardmäßig in Clientanwendungen öffnen auf Aktivieren (OpenInClient-Feature ist aktiviert), um Dokumente in der Clientanwendung zu öffnen. Klickt auf Deaktivieren (OpenInClient-Feature ist deaktiviert), um Dokumente im Browser zu öffnen.

Dokumenten Bibliothek

1. Klickt auf der Bibliothekssymbolleiste auf Bibliothekseinstellungen.

2. Klickt auf der Seite Dokumentbibliothekseinstellungen auf Erweiterte Einstellungen.

3. Wählt nun auf der Seite Erweiterte Einstellungen unter Öffnen von Dokumenten im Browser eine der folgenden Optionen aus:

In der Clientanwendung öffnen: Klickt ein Benutzer auf ein Dokument in dieser Bibliothek, wird das Dokument in der entsprechenden Clientanwendung geöffnet (sofern verfügbar).

Im Browser öffnen: Klickt ein Benutzer auf ein Dokument in dieser Bibliothek, wird das Dokument in der Webbrowserwebanwendung für diesen Dokumenttyp geöffnet. Wenn das Dokument in der Webanwendung geöffnet wird, kann der Benutzer auswählen, ob das das Dokument in der Clientanwendung geöffnet werden soll.

Serverstandardeinstellung verwenden: Klickt ein Benutzer auf ein Dokument in dieser Bibliothek, wird das Dokument gemäß dem Standardöffnungsverhalten geöffnet, welches für den Server vorgesehen ist, auf dem die SharePoint 2010-Produkte installiert sind.