Donnerstag, 27. Januar 2011

Der MSDN Tour Bus kommt nach Hamburg und besucht die SQL Server Community PASS!

Hier schon mal die ersten Infos zum MSDN Tour Bus Stopp in Hamburg.

Wie ja schon einige von Euch mitbekommen haben, ist es uns gelungen genau an unserem Community Abend, dem 10.02.2011, den MSDN Tour Bus in unsere schöne Stadt zu bekommen! Vielen Dank dafür an all die Community Feen und Elfen bei Microsoft und den Agenturen! Wir führen den Stopp in Kooperation mit der wiedererwachten .net Usergroup in Hamburg durch! Super Jungs (und Mädels?), dass Ihr wieder aktiver seit!

Der Bus wird laut der aktuellen Planung gegenüber der Microsoft Niederlassung in Hamburg stehen. Also sehr gut mit allen Verkehrsmitteln zu erreichen. Die SQL Server Community PASS Deutschland e.V. Hamburg hat den Bus exklusiv von 17 Uhr bis 19 Uhr.

Hier der offizielle Text von MS dazu:

MSDN, das Microsoft Developer Network, geht mit hochwertigen Vorträgen zu aktuellstem Entwicklerwissen im technikbeladenen, komfortablen MSDN-Bus auf Deutschland-Tour und macht auch in Ihrer Nähe Halt.

Nutzen Sie als Entwickler die Möglichkeit, im MSDN-Bus direkt von Microsoft-Referenten das Neueste aus der Softwareentwicklung zu erfahren und aktuelle Technik hautnah erleben zu können. Sei es Visual Studio 2010, Web-Entwicklung und Internet Explorer 9, Cloud-Dienste wie Windows Azure, das Schreiben von sicherem Code oder eines vieler weiterer Themen, etwa Windows Phone 7 oder Open Source & Standards bei Microsoft.

Im Umfeld zahlreicher Demos, How-To-Anleitungen und Sourcecodes können Sie mit Microsofts Experten und Gleichgesinnten fachsimpeln und netzwerken. Außerdem zeigen wir Ihnen, welche Services und Programmatiken MSDN für Sie anbietet.

Bitte beachtet, dass es sich um eine Geschlossene Veranstaltung handeln wird. Daher dieses Mal besonders auf die Einladung vom Rolf achten und sich registrieren, da wir verhindern wollen, dass jemand bei dem Wetter draußen stehen muss.

Wir werden Euch über die weiteren Details wie Themen und MS Speaker auf dem Laufenden halten!

Hier findet Ihr erste Infos, Karte und Bilder: http://www.msdn-on-tour.de/Details1002.aspx

Mittwoch, 26. Januar 2011

SQL Server asynchrone Trigger & Service Broker im Repository

Da schreibe ich über unsere Repositories und schon gibst Schimpfe aus der Community! Sascha hat gesagt, dass er Trigger einsetzt… geht ja man mal gar nicht! So von wegen schlechtes Vorbild und so! Trigger sind doch so was von bööööööööse…… kommen gleich nach Cursorn! :-)

Recht habt Ihr! Grundsätzlich in einer LOB / OLTP Umgebung bin ich sehr selten ein Fan von Triggern. Wobei ich diese Diskussion immer wieder mit ISVs führen muss. Daher hier jetzt mal ein paar Worte dazu…

Warum sind Trigger eigentlich böse? Sind doch ne coole Sache, oder?
Ja, Trigger sind von der Idee her sogar äußerst praktisch. Logik wird ausgelöst durch ein DML oder DDL Statement. Es muss nicht extra eine Prozedur gestartet werden. Das unerfreulich an einem Trigger ist die Tatsache, dass er out-of-the-box immer synchron ist. Das geht leider ganz gewaltig zu Kosten der Gesamtperformance eines Systems, wenn da ein wenig mehr Last drauf kommt. Damit ist gemeint, dass die Aktion, welche der Trigger startet, immer GENAU in dem Moment “passiert”, in welchem der Trigger aufgerufen wird. Das macht in einigen Bereichen durchaus Sinn, aber in den meisten Fällen ist diese 100% Synchronität nicht notwendig. Zum Beispiel in fast all meinen Repository Beispielen. Daher verwenden wir so genannte asynchrone Trigger!

Ok, was sind denn jetzt bitte asynchrone Trigger?
Mit asynchronen Triggern meinen wir in der Regel einen Trigger, welcher einen Service Broker Service (Service ist immer wichtig…) nutzt! Service Broker führt leider in sehr vielen Umgebungen ein Schattendasein, obwohl es jedem, wirklich JEDEM, SQL Server seit 2005 “beiliegt”. (Ok, von kleinen Einschränkungen mal abgesehen.) Und Trigger sind, neben vielen anderen, ein sehr gutes Beispiel für den produktiven und überhaupt nicht esoterischen Einsatz von Service Brokern!

Und was ist dieser “Service Broker”? Und brauche ich dafür eine Enterprise Edition?
Hier kommt ein wenig Text aus der BOL:Service Brokerunterstützt Datenbankentwickler beim Erstellen zuverlässiger und skalierbarer Anwendungen. Da Service Broker Teil von Database Engine (Datenbankmodul) ist, ist auch die Verwaltung dieser Anwendungen Teil der routinemäßigen Verwaltung der Datenbank.

Service Broker stellt für SQL Server Queuing und zuverlässiges Messaging bereit. Service Broker wird für Anwendungen verwendet, die eine einzige Instanz von SQL Server verwenden, sowie für Anwendungen, die Arbeit über mehrere Instanzen verteilen.

Innerhalb einer SQL Server-Instanz stellt Service Broker ein leistungsfähiges asynchrones Programmierungsmodell bereit. Datenbankanwendungen verwenden normalerweise asynchrone Programmierung, um die interaktive Antwortzeit zu verkürzen und den Anwendungsdurchsatz allgemein zu erhöhen.

Außerdem bietet Service Broker zuverlässiges Messaging zwischen SQL Server-Instanzen. Service Broker unterstützt Entwickler beim Konzipieren von Anwendungen aus unabhängigen, eigenständigen Komponenten, den so genannten Diensten. Anwendungen, die die über diese Dienste bereitgestellte Funktionalität benötigen, verwenden für die Interaktion mit den Diensten Nachrichten. Service Broker verwendet TCP/IP für den Austausch von Nachrichten zwischen Instanzen. Service Broker enthält Features, die den nicht autorisierten Zugriff über das Netzwerk verhindern helfen und über das Netzwerk gesendete Nachricht verschlüsseln.”

Das liest sich für viele Entwickler äußerst spannend, aber leider häufig auch ein wenig weit weg von ihren täglichen Herausforderungen! Dem ist aber gar nicht so! Daher, gebt dem Service Broker eine Chance! Bald wollt Ihr nicht mehr ohne! –> “Service Broker” gefällt mir!

Montag, 24. Januar 2011

Wieder einmal das Repository… oder auch Repository driven BI / everything in SQL Server FAQ…

Auf Repositorys und Meta Daten komme ich ja immer wieder gerne zu sprechen. :^)

Zuletzt hatte ich die Gelegenheit meine Ideen von Repository getriebenen Architekturen einer Community in Nürnberg, in der PASS Regionalgruppe Franken, vorzustellen. Vielen Dank an den Klaus Oberdalhoff für die Organisation dieses Events und vielen Dank an die Raumsponsoren! Kommt gar nicht so häufig vor, dass ich bei einem RG Treffen vor mehr als 40 Teilnehmern spreche. Kam fast ein wenig Konferenzstimmung auf. Des Weiteren war die Session schön interaktiv und es wurden einige sehr gute Fragen gestellt.

Ein paar dieser Fragen und natürlich die Antworten hier nun für den Online Teil der Community. Fragen folgen in Fett.

Ein wesentlicher Teil der Fragen zielte darauf ab, was denn nun so ein Repository ausmache bzw. ob das nichts anderes ist als eine Konfiguration?

Zwar bauen meine Ansätze immer auf einem Repository auf, welches die beschreibenden Daten für die eigentliche Zielplattform hält, aber es handelt sich dabei nicht nur um eine andere Organisationsform einer Konfigurationsdatei für eine existierende Technologieplattform!

Ich vergleiche das gerne mit einem Navigationsgerät. Technologie ist klar, das gute Stück kann sich super orientieren und mit ein wenig Kartenzauber und Routenfindung äußerst praktisch. Nur wie verwenden wir es? Wir geben in der Regel die Route nicht im Detail vor, also jede Straße, jede Kreuzung usw. Wir kommunizieren über eine Metaebene mit der eigentlichen Logik, welche eine für uns plausible Information abfragt: Eine Zieladresse. Die restliche Magie findet auf sehr wahrscheinlich mehreren Ebenen darunter statt. Der letzte Level kennt den aktuellen Standort und kommuniziert wiederum mit dem Routenplaner eine Etage über ihm, usw. Also ist das Adressbuch eine Metaebene (-> Repository) und auch das Kartenmaterial (noch eine Ebene).

Daher ist ein wesentlicher Aspekt des Ansatz, dass es mir NICHT allein um das an-codieren der SQL Server Funktionen geht, sei es nun SMO oder AMO. Die eigentliche Magie spielt sich meiner Meinung nach in den Ebenen darüber ab. Denn in diesen Ebenen werden erweiterte Funktionalitäten hinzugefügt. Ein bei mir sehr beliebtes Muster (ich sage mal absichtlich nicht Pattern, das führt nur zu Missverständnissen) ist das Hinzufügen der Möglichkeit Objekte zu Gruppen zusammenzufassen, was in der Regel auf der Zielplattform nicht möglich bzw. nicht “Solution” übergreifend anwendbar ist.

Beispiele für Ziel- bzw. Technologieplattformen können sein: SQL Server Analysis Services (SSAS), SQL Server Integration Services (SSIS), SQL Server Replikation, Trigger, Service Broker, Extended Events oder auch SharePoint.

Und Beispiele für Gruppen können damit sein:

- Attribute in SSAS Projekten, aber über mehrere Dimension und auch Solutions hinweg.
- Steuerung von Triggern bzw. asynchronen Triggern, welche auch noch mit Service Broker Diensten verbunden sind.
- Abonnenten innerhalb einer Replikationsstruktur können sehr gut zu Gruppen zusammengefasst werden, um diese mittels eines Eintrags im Repository an einen anderen Verteiler “zu hängen”. Glaubt mir, sowas macht in schön großen Replikationsstrukturen (>200 Abonnenten) und 1-2 mehr Servern richtig Spaß!
- Listen und was alles damit zusammenhängt (hehe…) innerhalb von SharePoint. Damit lassen sich auch schöne Projekte realisieren, aber sprengt gerade den Rahmen hier.

Wie steuere ich das dann alles von oben? In der Regel durch eine domänenspezifische Sprache, wobei ich gerne noch weiter gehen möchte und das einfach mal projektspezifische Sprache (PSL) nenne. Also hier drin steckt meiner Meinung nach die eigentliche Magie (ich mag das Wort in dem Zusammenhang) in den Projekten.

Wie komme ich auf sowas? Schon sehr früh, noch zu Zeiten als ich mit Clipper (und es war Sommer 87…*flöt*) und MUMPS unterwegs war, habe ich mir Codegeneratoren entwickelt, welche zum Beispiel das damalige Clipper (vor dem CA Zeug) um die Möglichkeit von eigenen Klassen erweitert haben. Sowas prägt fürs ganze IT-Leben! by the way, Dank an den Jan Welker für den Tipp mit T4! Äußerst spannend!  

Wie speichere ich das Repository? Schwieriges Thema… gerne als einfache relationale Struktur. Dann kann mittels SQL DML Befehlen direkt darauf eingewirkt werden und auch evtl. notwendige GUIs brauchen “nur” SQL DML beherrschen. Damit auch mal was passiert in den Strukturen kommen da dann ausnahmsweise Trigger dazu, welche auf Veränderungen reagieren. Die Daten im Repository bildet dann die Strukturen auf der jeweiligen Zielplattform ab.

So, damit sind die wohl häufigsten Fragen persistiert worden. Bei weiteren Fragen einfach auf mich zukommen!

Für Alle, die die Session Repository Driven Business Intelligence aka The Developer Side of MS BI bisher nicht gesehen haben, die gibt es als englischen Cast auch noch auf den SQLBits Seiten!

Montag, 10. Januar 2011

Repository driven SQL Server Business Intelligence Vortrag in der Region Franken ( Nürnberg / Fürth )

In der nächsten Woche am 18.01.2011 halte ich in der Community PASS Deutschland e.V. Regionalgruppe Franken in Nürnberg meinen “Einsteiger" Vortrag zum Thema Repository driven Business Intelligence mit dem SQL Server:

Developer Side of Microsoft Business Intelligence

Der Microsoft SQL Server bietet eine ganze Reihe von äußerst mächtigen Diensten und Werkzeugen für die Erstellung von Business Intelligence Lösungen. Warum sollte sich dann überhaupt ein BI Berater mit den Möglichkeiten der Programmierbarkeit des SQL Servers beschäftigen? Weicht er damit nicht vom Standard ab? Und warum sollte sich ein Programmierer mit BI befassen? Sind die BI relevanten Dienste vom SQL Server etwa nicht fertig?

Die Wahrheit ist, dass eine wesentliche Stärke des SQL Servers, neben den bekannten Werkzeugen, die Verfügbarkeit von diversen sehr gut dokumentierten APIs ist. Diese APIs können sehr gut im Rahmen von BI Projekten genutzt werden und die Integrationsfähigkeit einer BI Lösung um ein vielfaches erhöhen. Alle in diesem Workshop vorgestellten Schnittstellen sind offiziell von Microsoft beschrieben worden und werden in zukünftigen Versionen unterstützt werden.

Vor dem Einsatz von Technologie kommt aber immer die zielgerichtete Konzeption der Lösung. Es wird gezeigt, wann und wie sich der Einsatz von Programmierung in BI Projekten tatsächlich rechnet und welche Voraussetzungen dafür erfüllt sein müssen.

Ein ganz wesentlicher Punkt aus der Erfahrung heraus ist die Nutzung der Abstraktion der Anforderungen und der Technologie als Architekturansatz im Design von Business Intelligence Lösungen.

Es werden sowohl Analysis Services, Integration Services als auch die relationale Engine untersucht und entsprechend mit einem Repository angesteuert und genutzt.

Details zum Treffen findet Ihr hier:

http://www.sqlpass.de/Regionen/Deutschland/Franken/tabid/71/Default.aspx

https://www.xing.com/events/developer-side-of-microsoft-business-intelligence-665284

Würde mich freuen möglichst viele von Euch dort aus der Community kennenzulernen!

Sonntag, 2. Januar 2011

Frohes neues Jahr 2011 !

Wow, es ist schon 2011! Wie die Zeit doch vergeht. Hoffe Ihr seit alle gut reingekommen!

Die letzten Monate des Jahres waren wieder sehr arbeitsreich und so geht es auch gleich weiter… aber ich habe diverses organisiert bekommen in Sachen Community Arbeit! Daher bin ich mir recht sicher, dass es 2011 einiges Neues für die Community auf diesem Kanal geben wird!

Aber erst mal zu den akutellesten Terminplanungen für 2011. Ist zwar noch früh, aber die ersten Termine stehen schon:

Bereits am 18.1.2011 bin ich als Redner zu Gast in der SQL PASS Regionalgruppe Franken (Nürnberg)

und am 16.5.2011 bin ich als Redner in der SQL PASS Regionalgruppe Köln/Bonn dabei.

Des Weiteren findet vom 7. bis zum 9.4.2011 die SQL Server Konferenz SQLBits 8 in Brighton, UK statt. Immer für einen Besuch gut! Und wo wir gerade bei den SQLBits sind, mittlerweile sind die Sessions der SQLBits 7 online gegangen. Hier gehst zum Video meiner Session >The Developer Side of the Microsoft Business Intelligence stack<.

IveSubmmitted[1]