Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Thomas Rümmler
Thomas Rümmler arbeitet als Managing Consultant und Projektleiter bei AIT und ist von Microsoft als Most Valuable Professional (MVP) für Visual Studio & Development Technologies ausgezeichnet worden. Sein Arbeitsschwerpunkt liegt auf Application Lifecycle Management und DevOps. Thomas hilft Unternehmen ihren Entwicklungsprozess ganzheitlich zu verbessern. Seine Erfahrung gibt er als Autor des TFS-Blogs und Sprecher im Microsoft DevOps Umfeld weiter.

Thomas Rümmler

Von Microsoft Access zu einer skalierbaren Lösung – Microsoft SQL Azure und Lightswitch

Montag, 25. Juli 2011

Haben Sie auch noch die ein oder andere Microsoft Access Lösung im Einsatz, jedoch keine Exit-Strategie, um auf eine zukunftsfähige, stabile und skalierbare Plattform umzusteigen?
Dieser Artikel zeigt an einem Fallbeispiel, wie man mit Hilfe von SQL Azure bestehende Microsoft Access-Lösungen ohne großen Programmieraufwand in die Cloud bringen kann. Als Basis dient eine frei zugängliche MS Access Datenbank aus den Microsoft Beispielen unter http://office.microsoft.com/en-us/templates/CT010375249.aspx#ai:TC101114817|. Es wird eine zweistufige Lösung vorgestellt, bei der im ersten Schritt die Daten von Microsoft Access in eine Microsoft SQL Azure Datenbank übernommen werden. Dabei bleiben die bewährten Microsoft Access Eingabemasken zunächst erhalten. Im einem weiteren Schritt wird mittels LightSwitch ein UI nachgebildet, um Microsoft Access vollständig zu ersetzen.

In vielen vielen Unternehmen trifft man MS Access Anwendungen zur Lösung unterschiedlicher Probleme an. Meist in den Fachabteilungen, wird Access immer wieder für kleine (und große) Lösungen verwendet, die meist sehr kurzfristig umgesetzt werden müssen. MS Access blickt somit auf eine Erfolgsgeschichte zurück, die das Produkt seit Anfang der 90er Jahre zur am meisten verbreiteten „Datenbank“ gemacht hat. Der Grund dafür liegt auf der Hand: Access schließt die Lücke zwischen Excel und professionellen, relationalen Datenbanken. Während man zur Verwendung zuletzt genannter professionelles IT Know-How benötigt, kommt man bei Access schon mit geringerem IT-Wissen zu Erfolgen. Dabei arbeitet man jedoch „datenbankorientierter“ als mit Excel. Man kommt also mit kleinem Invest zum Erfolg. Access wird hierbei unterschiedlich eingesetzt. Teilweise als hybride Lösung nur als Backend oder ausschließlich als Frontend. Häufig wird aber auch die komplette Anwendung in Access umgesetzt unter Verwendung der Masken, Reports, Tabellen und Co.

Kurzfristiger Bedarf der Fachabteilung vs. Überbelastung der IT
Arbeiten Sie selbst in dem Bereich der internen IT-Dienstleistungen im Unternehmen? Dann kennen Sie vermutlich die Situation, dass der Fachbereich eine Anforderung hat, welche minimal dokumentiert, jedoch mit einem fixen Fertigstellungstermin versehen ist: Gestern!
Sind Sie hingegen im Fachbereich tätig, haben Sie wahrscheinlich eine andere Sicht auf die gleiche Situation. Sie stehen vor einem Problem und benötigen Unterstützung von der IT – natürlich schnell, denn Ihr Problem ist dringend. Nach einer Anfrage per E-Mail oder Telefon stellen Sie Gelächter unter den IT-Kollegen fest. Sie werden mit der Aussage vertröstet, dass die IT zur Zeit völlig überlastet sei, Aufträge „von ganz oben“ erfüllen muss und außerdem stünden aktuell die Updates der eigens gehosteten Serverlandschaft auf dem Programm.
So – oder so ähnlich – findet man das Verhältnis zwischen IT und Fachbereich immer wieder in Unternehmen. Die Konsequenz daraus ist vielseitig. Häufig wird entweder ein externer IT-Dienstleister eingeschaltet, der eine Lösung im Auftrag der Fachabteilung liefert – schnell und günstig. Auf der anderen Seite haben viele Fachbereiche ihre „Access-Experten“, die für solche Fälle das Rettungsboot in den stürmischen Unternehmensgewässern sind.
Das Problem an der ersten Variante ist, dass die extern erzeugte Lösung schon mal an den internen IT-Standards vorbeientwickelt sein kann, aber nach der Fertigstellung von der internen IT integriert und gewartet werden muss. Somit hat die IT wieder weniger Zeit auf die kurzfristigen Anforderungen des Fachbereichs zu reagieren – einTeufelskreis. Die zweite Variante hingegen funktioniert sehr gut, solange sich der Scope der Anwendung nicht maßgeblich erweitert oder die Lösung auf andere Abteilungen adaptiert werden muss. Denn hier zeigen sich die Grenzen des Datei-basierten Access. Wenn sich eine Access-Anwendung zu einer komplexen Plattform weiterentwickelt, können die Themen
– Skalierbarkeit,
– Verfügbarkeit und
– Datenintegrität
zu schwer überwindbaren Hürden heranwachsen. Typische Ursachen für solch ein Szenario sind:
– Änderung der Umwelt / des Unternehmens
– der Datenbestand (oder Teile davon) werden als kritisch eingestuft und müssen besonders geschützt werden
– die Datenmenge wird zu groß

Lösungsansatz
MS Access bietet selbst bereits einige Möglichkeiten, zumindest die Dateninhalte zu migrieren. So kann man z.B. Daten in SharePoint Listen auslagern, was auch gleich die Möglichkeit mit sich bringt, auf diese Daten über ein – wenn auch einfaches – Web-Interface zuzugreifen. Des Weiteren besteht die Möglichkeit Daten in eine MS SQL Server Datenbank oder eine SQL Azure Datenbank auszulagern. Die SQL Azure Datenbank ist eine relationale Datenbank in der Microsoft Cloud Windows Azure. Es handelt sich dabei um ein Derivat des MS SQL Server 2008 R2 mit reduziertem Funktionsumfang, der jedoch vollständig als Service von Microsoft abgerufen werden kann – also eine relationale Datenbank as a Service. Wenn man von Migration einer Access-Lösung spricht, muss man auch die Oberfläche betrachten. Hier wird es noch schwieriger mit Automatismen vorwärts zu kommen. In der Regel blieb bislang nichts anderes übrig, als das UI neu zu entwickeln, z.B. als ASP.NET Webanwendung.

Automatische Migration – das soll es sein. Wenn möglich, sollte man manuelle Tätigkeiten vermeiden – das schont die Nerven sowie das Budget. Um den Datenbestand einer Access-Datenbank in eine professionelle, relationale Datenbank zu übertragen, kann man z.B. das Tool „SQL Server Migration Assistant“ (kurz: SSMA) verwenden. Dieses Werkzeug gibt es für verschiedene Quelldatenbanken, darunter MySQL, Oracle, Access und weitere. Alle Zieldatenbanken erfordern jedoch, dass sie im Unternehmen existieren. Sie müssen also beschafft, angelegt und verwaltet werden. Das erzeugt wieder Aufwand. An dieser Stelle kommt SQL Azure ins Spiel.

Die relationale Datenbank lässt sich – eine Azure Subscription, also eine Zugang zu Windows Azure, vorausgesetzt – mit wenigen Klicks und in Windeseile erzeugen. Der Clou: auf diese Datenbank greift man genauso zu, wie auf eine lokale MS SQL Server Datenbank. Man muss eben nur den Connectionstring auf die entfernte Datenbank einstellen.

Folgende Schritte sind nötig:
Teil 1 – Datenmigration
– Anlegen einer SQL Azure Datenbank über die Windows Azure Platform (siehe Abbildung 1)


Abbildung 1: Windows Azure Platform – Bereich Database

– Um den Zugriff von einem Rechner außerhalb von Microsoft’s Rechenzentren zu ermöglichen, muss die Firewall angepasst werden. Diese Aufgabe erfordert in Windows Azure nur minimale Kenntnisse (siehe Abbildung 2). Man muss also kein Netzwerkadministrator sein, um diese Firewall-Regel anzulegen.


Abbildung 2: Verwalten von Firewall Regeln für die SQL Azure Datenbank

Ob die Datenbank und die Firewall Regel erfolgreich angelegt wurden kann man leicht prüfen. Mit dem SQL Server Management Studio kann man sich mit der Datenbank wie mit einem lokalen SQL Server verbinden (siehe Abbildungen 3 und 4).


Abbildung 3: Verbinden mit dem SQL Server Management Studio


Abbildung 4: Object Explorer des SQL Server Management Studios

– Als nächstes muss mittels SSMA die Datenmigration durchgeführt werden. Der Assistent des Tools führt den Benutzer durch alle erforderlichen Schritte (siehe Abbildung 5)


Abbildung 5: SSMA Migration Wizard

Die Maske „Link Tables“ des Assistenten bietet einen entscheidenden Schalter an. Man kann nämlich durch den SSMA die Datenquellen in der Access-Quelldatenbank verändern lassen. Dabei werden die bestehenden Tabellen in der Access Datenbank gesichert und externe Datenquellen unter den ursprünglichen Namen der Tabellen erzeugt (siehe Abbildung 6).


Abbildung 6: Checkbox zum Anpassen der Datenquelle

Nachdem die Schritte des Assistenten durchgeführt worden sind, ist die ursprüngliche Access-Datenbank mit der SQL Azure Datenbank verbunden. Dies lässt sich ganz leicht verifizieren, indem man z.B. mit dem SQL Server Management Studio einen Datensatz verändert und diesen dann in der Access-Anwendung betrachtet.

Bei der Migration sind einige Punkte zu beachten. Beispielsweise kann es bei der Namensgebung zu Konflikten kommen, da die Access-Datenbank Objektnamen zulässt, denen sich der SQL Server verweigert. Auch bei Datentypen können Fehler auftreten. Ein Beispiel dafür ist der unter Access existierende Datentyp „Attachment“. Dafür gibt es keinen Migrationsautomatismus. Queries mit benutzerdefinierten Funktionen werden ebenfalls nicht übersetzt. Diese müssen manuell in Form von Stored Procedures oder Funktionen neu geschrieben werden. Auch können plötzlich Performanceprobleme auftreten. Dies klingt paradox, hat man doch gerade von Access auf eine relationale Datenbank migriert. Da in den Access-Anwendungen alles lokal abläuft, findet man mitunter Formulare und Reports, die zu viele Daten anlesen und diese erst im User Interface filtern. Dieses Design führt bei entfernten Datenbanken zu unnötig Traffic, der sich in schlechter Performance widerspiegelt.

Teil 2 – User Interface

Nachdem die Daten umgesiedelt wurden und sich mit ihrer neuen Heimat in den Wolken der Microsoft Rechenzentren anfreunden, benötigt man zur Ablösung von Access noch ein neues User Interface. Hierfür hat Microsoft sein Angebot in der .NET Anwendungsentwicklung um eine RAD (Rapid Application Development) Plattform erweitert. Das Kind trägt den Namen Lightswitch, befindet sich gerade im Betastadium (Releasedatum: 26.07.2011) und integriert sich vollständig in Visual Studio – der gewohnten .NET Entwicklungsumgebung (siehe Abbildung 7).


Abbildung 7: Lightswitch im New Project Dialog in Visual Studio 2010

Lightswitch wird auf der Produktseite wie folgt beschrieben: „A SIMPLER WAY TO CREATE HIGH-QUALITY BUSINESS APPLICATIONS FOR THE DESKTOP AND THE CLOUD” (http://www.microsoft.com/visualstudio/en-us/lightswitch)
Was ist hinter dem Slogan genau zu verstehen? Lightswitch adressiert einfach zu erzeugende Lösungen. Den Teil „[…] for the Desktop and the Cloud” kann man u.a. wie folgt interpretieren:
– Mit Lightswitch lassen sich Anwendungen für den Client als auch für den Browser auf Basis von Silverlight erstellen.
– Lightswitch kann als Datenquelle einen on-premise Datenspeicher als auch eine Cloud-Datenbank verwenden
– Bei Verwendung einer Webanwendung, kann der Webserver auf jedem lokalen IIS als auch in Windows Azure betrieben werden
– Die Variante der Client-Applikation kann lokal jedoch auch über Windows Azure verteilt werden

Tom Wendel hat in seinem Blog eine treffende Aussage getroffen. Er schreibt über Lightswitch, es sei “[…] kein Access, wobei es durchaus Parallelen zur Grundidee gibt […]“
(http://blogs.msdn.com/b/twendel/archive/2010/08/03/lightswitch.aspx)

Lightswitch ist dabei kein Access-Ersatz, bietet aber die Möglichkeiten der einfachen Lösungserstellung in der .NET Plattform für eine ähnliche Zielgruppe. Es werden Fach- oder kleine IT-Bereich adressiert. Lightswitch dient nicht als Plattform komplexer Anwendungsentwicklung in großen Teams. Es handelt sich dabei um eine datengetriebene Entwicklung mit konkretem Bezug zu Business Cases. Dies zeigt sich schon daran, dass der erste Dialog der Lightswitch-Entwicklung in Visual Studio die Wahl der Datenquelle fokussiert (siehe Abbildung 8).


Abbildung 8: Start-Sreen eines Visual Studio Lightswitch Projektes

Man kann neue Tabellen designen oder auf eine bestehende Datenquelle zugreifen.
Im hier dargestellten Beispiel wird die vorher erstellte SQL Azure Datenbank als Datenquelle verwendet. Sie dient als Basis, Screens von Lightswitch erzeugen zu lassen. Nachdem man die Datenquelle hinzugefügt hat, kann man aus einem Set an Screenvorlagen wählen, welche die gewähnlichen CRUD-Operationen (Create, Read, Update, Delete) abdecken (siehe Abbildung 9).


Abbildung 9: Hinzufügen eines neuen Screens

Dabei wählt man die Datenquelle, also die zugrunde liegende Tabelle oder den View aus, entscheidet sich für eine Vorlage und vergibt einen Namen. Später kann die Maske durch Anpassungen individualisiert werden.

Auf diese Art kann man die erforderlichen Screens erstellen lassen und noch den eigenen Bedürfnissen anpassen. Hat man den kompletten Use Case abgebildet, kann man die ursprängliche Access-Datenbank abschalten und hat eine neue, zukunftsfähige und skalierbare Lösung geschaffen.

Grenzen
In der vorher beschriebenen Vorgehensweise ausgeblendet sind Fehler, die das Migrationstool SSMA während der Migration ausgibt. Sei es durch Datentypen, die es in der Zieldatenbank nicht gibt, durch Constraints, die nicht angelegt werden können oder andere Fehler. All diese Fehler erfordern manuelle Nacharbeit.
Desweiteren gestaltet sich die Lightswitch-Entwicklung im Team – zumindest die gemeinsame Modifikation der Oberfläche – als schwierig, weil dann mehrere Teammitglieder die gleiche Datei bearbeiten müssen.
Auch der Versuch, den automatischen Buildprozess über den Team Foundation Server zu verwenden, bringt einige Stolperfallen in Bezug auf User Accounts und 64bit mit sich. Beibt abzuwarten, welche der Probleme sich als Beta-Probleme herausstellen.
Abschließend soll hier auch noch einmal auf evtl. Performanceprobleme hingewiesen werden, die bei der Weiterverwendung des Access-UI entstehen können, wenn zu viele Daten gelesen werden.

Fazit
SQL Azure ist eine hervorragende Lösung als relationale Datenbank in der Cloud. Sie bietet die Möglichkeit ein professionelles Datenbanksystem zu verwenden ohne langwierige interne Prozesse durchlaufen zu müssen.
Lightswitch ist ein sehr gutes Werkzeug zur schnellen, datengetriebenen Anwendungsentwicklung unter Verwendung der bewährten Microsoft .NET Plattform als Basistechnologie.
Beide Teile, die SQL Azure Datenbank wie auch die Lightswitch Entwicklungsumgebung, ermöglichen eine Lösung, ohne eigene Infrastruktur bereitzustellen. Dadurch ergeben sich durch deren Kombination maximale Synergieeffekte. Das Ergebnis ist eine professionelle, skalierbare Lösung, die nach der Fertigstellung von der IT-Abteilung übernommen und weiter betreut werden kann und auch bei sich ändernden Anforderungen gut skaliert.

Links
– Use the upsizing Wizard: http://office.microsoft.com/en-us/access-help/use-the-upsizing-wizard-HP005273009.aspx
– Microsoft SQL Server Migration Assistant for Access: http://go.microsoft.com/fwlink/?LinkID=188675
– Visual Studio Lightswitch: http://www.microsoft.com/visualstudio/en-us/lightswitch
– Windows Azure – Die Cloud Services-Plattform von Microsoft: http://www.microsoft.com/de-de/azure/default.aspx
– Cloud Database: http://www.microsoft.com/windowsazure/sqlazure/

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , ,

Hinterlasse eine Antwort