Archiv des Autors: Urs Wanner

Über Urs Wanner

MatchPoint (Teil 3): hybris – Beispiel einer Anbindung eines Drittsystems für das dynamische Metadatenmodell

Veröffentlicht am von , Kommentar hinterlassen

Links

MatchPoint (Teil 2): Funktionen und Stärken in der Lösungsentwicklung
MatchPoint (Teil 1): Entwicklung komplexer SharePoint-Lösungen
One world-Der Hybris Connector
One world Einführung

Einleitung
In diesem Beitrag wollen wir aufzeigen, wie wir Metadaten für MatchPoint (die sogenannten Tags) über unseren Connector von Hybris importieren können. Dabei verweisen wir auch auf die Artikel der Serie One Wold. Dort wird die Implementierung des Hybris Connector Service besprochen.
Stellen wir uns die folgende Aufgabenstellung vor: Ein Kunde hat seinen Artikelstamm in Hybris hinterlegt (pim). Er möchte nun die Katalogstruktur von Hybris auch in seinem Intranet abbilden. Dabei möchte er für jeden Katalog, jede Kategorie und jedes Produkt einen Workspace anlegen. Dort sollen schliesslich diverse Zusatzinformationen (in Form von Dokumenten) abgelegt werden.
Die Idee
Die Katalogstruktur soll mit MatchPoint Tags automatisch nachgebildet werden. Dazu sollen die entsprechenden Daten aus Hybris abgegriffen- und über einen Tagimport in MatchPoint verfügbar gemacht werden.

2997-MetadataImport_Hybris_Connector_Overview.jpg

Wir werden dazu einen MatchPoint Importjob programmieren. Dieser kann als MatchPoint Konfiguration verwaltet werden. Er erscheint als zusätzliche Timerjob-Variante in der Administration der Timerjobs:

2998-TimerJobsConfiguration.jpg

In der obigen Abbildung sehen wir einerseits die zusätzlich verfügbare Konfiguration ‚CatalogImporterConfiguration’ und schliesslich zwei Timer Job Konfigurationen. Die ‚Namics.Hybris.Demo.Roottags’ Konfiguration legt nur den statischen ersten Tag ‚Catalogs’ an, unter dem der Importer ‚Namics.Hybris.CatalogImporter schliesslich alle weiteren Tags anlegt.
Der Importer stellt den folgenden Konfigurationsscreen bereit:

2999-ConfigTimerJob.jpg

Wir sehen, dass in der Liste ‚CatalogNames’ die Namen der Kataloge angegeben werden können, die der Importer schliesslich importieren soll. Weiter kann man wie bei allen Scheduled Timerjobs in MatchPoint angeben, wann der Timerjob automatisch ausgeführt werden soll. Somit können die Metadaten in gewissen Grenzen automatisch aktualisiert werden.
Nachdem unsere beiden Jobs durchgelaufen sind erhalten wir in der Tag-Selektion die beiden importierten Kataloge (Clothing und Computer hardware) mit ihren Kategorien und Produkten zur Auswahl.

3000-TagTree.jpg

Nun können beispielsweise mit dem Workspace-Provisioning von MatchPoint die gewünschten Workspaces angelegt und direkt mit den entsprechenden Tags versehen. Da MatchPoint auf Wunsch diese Tags automatisch auf alle Elemente in einem Workspace vererbt, erhalten wir eine korrekte Vertagung der Dokumente, sobald man diese in ihrem Workspace ablegt.

3001-Example.jpg

In der obigen Abbildung kann man diese Vertagung nachvollziehen. In eine Doclib im Workspace ‚EIZO L578-K 17 LCD Monitor (silver)’ wurde ein Dokument hochgeladen. Dieses erhält automatisch den aus Hybris importierten Produkte-Tag des Workspace.

One world-Der Hybris Connector

Veröffentlicht am von , Kommentar hinterlassen

<< Einführung in die Serie one world

Einleitung
In diesem Artikel soll aufgezeigt werden, wie ein custom Service durch die Vererbung einiger Basisklassen des SAF (Service Application Framework) in die SharePoint 2010 Serviceinfrastruktur integriert werden kann. Wie auch bereits in der Einleitung geschehen, wollen wir uns dabei am Beispeil des Hybris connector Service orientieren. Dieses Mal werden wir aber vermehrt auf die technische Umsetzung des Service eingehen und insbesondere aufzeigen, wie sich der Service mit dem SAF verbindet.

Der Aufbau des Service
Das Design eines custom SAF Service wird grundsätzlich durch die zu vererbenden Basisklassen des Frameworks bestimmt. Diese werden in den folgenden Darstellungen kurz besprochen. Die vererbten Klassen des SAF sind in den Abbildungen jeweils blau interlegt. Gelb hinterlegt sind die Klassen des connector Service.

2961-HybrisService.jpg

Die Klasse HybrisService steht für den Service selber und vererbt von SPIisWebService. Somit beinhaltet er eine Liste aller Service Applikationen und aller Service Application Proxies., die für diesen Service angelegt worden sind. Der Service selber kann sich in der Services-Liste der Farm ein- oder auch wieder austragen. Dazu kennt die Klasse einen Link für den ‚Create Service’ Dialog. Weiter können durch die Implementierung von IServiceAdministration neue Applikationen und Proxies anlegen.

2976-HybrisServiceInstance.jpg

Die Klasse HybrisServiceInstance steht für eine Instanz des Service, die auf einem bestimmten Server in der Farm läuft.

2979-HybrisServiceProxy.jpg

Die Klasse HybrisServiceProxy etabliert die Verbindung zwischen dem Service und den ServiceApplicationProxies.

2964-HybrisServiceApplication.jpg

Die Klasse HybrisServiceApplication ist die eigentliche Service Applikation. In unserem Beispiel wird die Konfiguration des Service durch diese Klasse gespeichert und gelesen. Dadurch erreichen wir, dass der HybrisConnector-Service mehrfach in einer Farm laufen kann und sich dabei die jeweiligen Konfiguration unterscheiden können. Diese Klasse implementiert auch IHybrisWCFService, unseren Service Kontrakt.

2970-HybrisServiceApplicationProxy.jpg

Die Klasse HybrisServiceApplicationProxy wird für den Zugriff auf HybrisServiceApplication verwendet. Diese Klasse wird benützt, um im client code auf den Service zuzugreifen.

2960-HybrisServicApplicationHost.jpg

Die Klasse HybrisServicApplicationHost wird für das hosting des Service im IIS verwendet

2967-HybrisServiceApplicationHostFactory.jpg

Die Klasse HybrisServiceApplicationHostFactory wird für das Erstellen der s Servicehost verwendet.

2973-HybrisServiceImplementation.jpg

Schliesslich wollen wir noch einen kurzen Einblick in die Logik unseres Service geben. Die von den REST Services ausgelieferten Datenstrukturen werden jeweils durch eine einfach gehaltene Datacontainer-Klasse abgebildet. Wir wollen hier an einem Beispiel aufzeigen, wir die Daten von Hybris geladen werden: Die Klasse Catalogs beinhaltet eine Liste von Katalogen. Wie alle Datencontainer implementiert sie das Interface IDataItem, dass die properties URL und ID erzwingt. Da es sich bei Catalogs um den Einstiegspunkt in die Hybris Catalog-Struktur handelt, muss an dieser Stelle die Url gesetzt werden. Sie wird aus der Konfiguration des Service entnommen. Die Logik des Hybris-Aufrufs und die Verarbeitung des Xml-Streams wird in der Klasse XmlDataElement implementiert. Diese verlangt die Angabe eines generischen Typs T (hier Catalogs). Dieser Typ entspricht dem zu ladenden Datacontainer. Die Hilfsklasse HtmlBase schliesslich übernimmt die Kommunikation mit den REST Services. Der response stream wird geparsed und in die DataContainer Klasse abgefüllt. Im Falle der Catalogs handelt es sich dabei um eine Liste von weiteren REST Urls, die für den Bezug der Detailinformationen zu den einzelnen Katalogen aufgerufen werden können. Dazu wird für jeden Katalog ein XmlDataElement vom Typ Catalog erstellt und die REST Urls der einzelnen Kataloge werden übernommen. Die Katalogdaten können nun geladen werden.

Schlussfolgerung
Durch den Hybris Connector Service können wir von SharePoint-Customcode aus sehr einfach auf Hybris lesend zugreifen. Wir erhalten Instanzen von .Net Klassen zurück und brauchen uns weder um den Aufruf von Hybris noch um das Parsen des ausgelieferten xml zu kümmern. Weiter kann der Service auch business Logik implementieren. So können zum Beispiel durch eine Service-Methode gleich die Daten eines ganzen Katalogs mit allen Kategorien und Produkten zusammengesucht werden. Natürlich würde eine solche Service Methode bald mit Performance-Problemen zu kämpfen haben, weil dazu eine Vielzahl Hybris REST calls nötig sind. Man kann sich aber auch gut vorstellen, dass der Hybris Connector Service eine cache-Struktur aufbaut, um eine ausreichend schnelle Ausleiferung der Daten zu gewährleisten.

Links

Step by Step SharePoint Service Applications
EInführung in Application Services von Daniel Larson. Sehr hilfreich!

One world Einführung

Veröffentlicht am von , 1 Kommentar

Stellt man SharePoint 2007 und SharePoint 2010 einander gegenüber, dann wird man viele Dinge finden, die sich nicht grundlegend verändert haben. Allerdings gibt es einen sehr interessanten, grundlegenden Wandel der klar zu Tage tritt: SharePoint 2010 ist viel serviceorientierter geworden. Viele SharePoint Features sind neu als Services implementiert. Mit dabei sind zentrale Funktionen wie die Profilverwaltung oder die Suche. Dies ist aber noch nicht alles! SharePoint 2010 bietet auch ein sehr flexibles Framework um unsere Custom Services in eine SharePoint Farm nahtlos zu integrieren. Dabei muss es sich bei einem Service nicht zwingend um einen ‚echten’ Webservice oder WCF Service handeln. Vielmehr kann SharePoint 2010 auch zentrale Funktionen, die auf allen Frontend Servern verfügbar sein sollen als Service behandeln. Durch das Service Application Framework (SAF) können wir diese entsprechend einbinden.

In diesem Artikel wollen wir nicht die Möglichkeiten und Features diskutieren, die das SAF zur Verfügung stellt. Vielmehr wollen wir eine ‚top down’ Übersicht darüber geben, wie das SAF und SharePoint 2010 unser Denken über die Integration von SharePoint Applikationen in einer Enterprise Umgebung verändern können.

Um dabei nicht zu theoretisch zu werden, wollen wir an einem Beispiel aufzeigen, wie Daten von einem Hybris Server (Produktinformationssystem) durch einen Service gelesen- und in SharePoint WebPart angezeigt werden können. Dabei soll das WebPart nicht direkt die Hybris Rest Services aufrufen, sondern wir wollen einen generischeren Hybris Connector als SharePoint Application Service anbieten. In unserem Beispiel soll dieser Service ein ‚echter’ wcf-Service sein, der im IIS gehosted wird. Dabei erfolgt das Deployment des Service über eine SharePoint Solution und die Konfiguration wird in der SharePoint Central Administration vorgenommen. Weiter bindet SharePoint unseren custom Service in die Farmtopologie ein und kann den Zugriff auf den Service sowie Loadbalancing und Disasterrecovery für unseren Service mit anbieten.

Das Beispiel

2941-BeispielHConnector.jpg
  1. Ein Hybris Server wird als Datensenke benützt. Er stellt Rest-Services für den externen Zugriff bereit. Au der Hybris Seite sind keinerlei Änderungen nötig.
  2. Der Hybris Connector Service kann auf einem oder mehreren Servern in der Farm betrieben werden. Er wird über SharePoint Deployment Mechanismen verteilt und in der Central Administration konfiguriert. Der Service ruft die Rest Services von Hybris auf und erhält Daten im xml Format. Der Service parsed diesen xml-Stream und befüllt einfache .Net Datenobjekte, die über wcf an den Client zurückgegeben werden.
  3. Der Client kann über eine ServiceApplicationProxy Instanz auf den Service zugreifen. Dieser wird als Teil des Connector Service implementiert und von der SharePoint Farm zur Verfügung gestellt wird.

Schlussfolgerung

Was sind die Vorteile des hier vorgestellten Ansatzes? Warum wollen wir die Hybris Rest Services nicht direkt im Code behind des WebParts aufrufen? Die Antwort ist: Bessere Wiederverwendbarkeit, bessere Skalierbarkeit und bessere Isolation des Service Codes.
Wir wollen uns vorstellen, dass der Kunde sehr glücklich war, über das WebPart, das im Intranet direkt Produktdaten aus Hybris anzeigen kann. Weiter hat er sich dazu entschlossen, auch sein Internet neu zu lancieren. Unter anderem möchte er dabei einen Produkt-Teaser haben, der die Produktinformationen aus Hybris anzieht. Gut gemacht! Wir können ihm für dieses Feature einen sehr interessanten Preis offerieren, weil unser Hybris-Connector Service wiederverwendet werden kann. Nach dem Relaunch des Internet stellt sich nun heraus, dass die neue Website des Kunden zur beliebtesten Website des Jahres avanciert. Um die zunehmende Last abzufangen stellt der Kunde einige zusätzliche Frontend Server in seine Farm. Wie wird dabei unser Service skalieren? Der SharePoint Administrator erstellt auf den neuen Servern einfach zusätzliche Service Instanzen und SharePoint übernimmt automatisch das load balancing für den Service.
Natürlich ist die Implementierung des Hybris-Connector Codes in einem Application Service etwas aufwendiger als wenn man Hybris direkt vom WebPart aus aufrufen würde. Allerdings können wir leicht einsehen, dass der Zusatzaufwand sich in vielen Fällen leicht rechtfertigen lässt.
Zu guter Letzt wollen wir noch auf einen weiteren Aspekt der Service orientated Architecture (SOA) eingehen: In einem Unternehmen wird man niemals gewillt oder dazu in der Lage sein, den gesamten custom code als einen monolithischen Block in einem Aufwasch neu zu implementieren. Die Risiken und die Kosten sowie die internen Vorbehalte gegenüber einem solchen Unterfangen wären einfach zu gross. Gelingt es aber, einzelnen Anforderungen durch Services nach und nach abzudecken, dann können wir die notwendigen Modernisierungen und Veränderungen viel besser portionieren und schrittweise umsetzen.

Ausblick

Dieser Artikel soll der erste der Serie ‚One world’ sein. Wir wollen an dieser Stelle mehre blog posts anbieten, die sich alle mit den Themen Services, Service Architektur und dem SAF befassen. Ein spannendes Gebiet, das zudem einen grossen Einfluss darauf haben kann, wie wir für SharePoint 2010 zukünftig Applikationen entwickeln können.

TechEd 2008, Barcelona, Tag4

Veröffentlicht am von , Kommentar hinterlassen

Urs Wanner: TechEd Dairy
Donnerstag 13.11.2008

Put your Big Ideas onto Tiny Devices using .NET
Rob Miles (http://www.robmiles.com/welcome/)

In dieser Präsentation ging es um das .Net Micro Framework. Ich habe nicht mal gewusst, dass es so was gibt und habe mehr aus Lust als aus Pflichtgefühl diesen Vortrag besucht. Das .Net Micro Framework erlaut es, für sehr kleine devices embedded code in C# zu schreiben. Dabei handelt es sich um den code, der zum Beispiel in Messfühlern oder Kugelschreibern läuft. Rob Miles hat einige Beispielanwendungen vorgeführt: Da war unter anderem eine bunte Lichterkette für Weihnachtsbäume, die immer wenn Rob was in seinen Blog schreibt automatisch alle Lampen auf rot umschaltet. Dazu abonniert die Steuerung der Lichterkette den rss-feed des blogs, findet jeweils das Datum der letzten Änderung heraus und kann so entscheiden, ob ein Neuer Eintrag vorliegt.

Da möchte man doch sofort mitbasteln. Ich habe mir die SDK jedenfalls schon runtergeladen!
http://msdn.microsoft.com/en-us/embedded/bb267253.aspx

Security Architecture for Heterogenous Enviroments in the Real World – The Identity Meta System and Federated Identity applied to a Real-World-Scenarios
Mario Szpuszta (http://blogs.msdn.com/mszcool/default.aspx)

Hier geht es um eine Security Architektur, die mit dem neuen Framwork (Codename Zermatt oder Geneva) umgesetzt werden kann. Hier die Idee: Ein Security Token Service stellt aufgrund einer Authentifizierung ein Token aus. Dieses Token kann beliebige Claims enthalten. Diese stellen Informationen über den authentifizierten Benutzer dar (zum Beispiel könnten das die AD-Gruppenzugehöhrigeiten sein). Ein Service erwartet nun dieses Token und kann aufgrund der vorgefundenen Claims die Autorisierung vornehmen. Das Interessante dabei ist, dass die Service Security nicht selber Authentifiziert sondern die benötigten Informationen über den User im Token erhält. Dies kann auch plattformübergreifend und (im Gegensatz zu SSO mit Kerberos) unabhängig von einem AD funktionieren.

Gruss aus Barco
Urs

TechEd 2008, Barcelona, Tag3

Veröffentlicht am von , Kommentar hinterlassen

Urs Wanner: TechEd Dairy
Mittwoch 12.11.2008

Internationalizing WPF And Silverlight Applications
Guy Smith-Ferrier, Internationalisation Consultant (Capella Software Ltd.)

Zunächst etwas Theorie: Globalisation ist alles rund um länderspezifische Formatierung (Datumsformate ect.) Mit Internationalisierung ist das Übersetzen der Ressourcen einer Applikation gemeint. Gloalisierung ist in im .Net Framework traditionellerweise sehr gut unterstützt. Mit der Internationalisierung tut man sich leider etwas schwerer.

Microsoft schlägt vor, dass für die Globalisierungs-Settings die CurrentCulture des Threads verwendet wird. Für die Interanationalisierung soll die CurrenUICulture des Threads verwendet werden. Dieser Ansatz erlaubt es, zum Beispiel deutsche Nummernformate zu verwenden und trotzdem die Applikation in Englisch darzustellen. Das Problem dabei ist, dass es Controls gibt, die ihre Ressourcen aufgrund der CurrentCulter (und nicht der CurrentUICulture) bestimmen. Dies kann daher zu mehrsprachiger Darstellung von Inhalten auf einer Seite führen.

WPF (und auch Silverlight) unterstützen Internationalisierung mit resx Dateien. Dies ist ein bereits bekannter Ansatz mit bekannten Vor- und Nachteilen:
Vorteil: Unterstützung von Language-Fallback auf item Level.
Vorteil: Verschiedene Tools erhältlich für den Umgang mit .resx Files.
Nachteil: Die Ressourcen müssen im xaml an die UI-Elemente gebunden werden.
Nachteil: Es können nur dependency properties gesetzt werden.
In Silverlight ist die Verwendung von .resx Fies zwar möglich. Mann muss dabei im Moment aber noch etwas tricksen. So muss ein spezieller Codegenerator für die Generierung der Resource-Wrapper-Klasse verwendet werden, damit die Ressourcen in xaml gebunden werden können.

Ich konnte mich nicht ganz dem Eindruck erwehren, dass es eventuell besser ist, die Ressourcen in einer Service-Schicht bereitstellen und mit Databinding an die UI-Elemente binden. Auf diese Weise ist es auch problemlos möglich, nach dem Release der Applikation ‚OnSite‘ weiter Ressourcen und sogar weitere Sprachen hinzuzufügen. Die vorgestellte Lösung greift nach meinem Geschmack einfach etwas zu kurz.

Nerdvana Annihilation: Improving Silverlight User Experiance (UX) without out-of-the-box controls
Miguel Jiménez, UX Advisor@Bla Bla Labs

In dieser Präsentation wurde (für einmal) mehr von der Designer-Perspektive aus auf Silverlight eingegangen. Die vielfältigen Designer Tools kann ich selber nicht wirklich beurteilen, da ich von der Entwickler-Seite her komme. Was mir aber sehr gefallen hat ist der Theoretische Einstieg in die Design-Geschichte:
Miguel Jiménez hat auf oftmals sehr witzige Weise darauf aufmerksam gemacht, dass wir nicht zwingen auf althergebrachte Weise über Silverlight UI’s nachdenken müssen. Es sei doch irgendwie unglücklich, eine Waschmaschine nur dafür zu benutzen, dass alte Waschbrett darauf abzustützen! Er hat auch auf den Unterschied zwischen User Experience (UX) und Design hingewiesen. Die UX muss von Anfang an mit bei allen Überlegungen zum UI-Design mit berücksichtigt werden. Dabei kann die Analyse von mental models (wie wir denken, dass etwas funktionieren soll) und embeded knowledge (Funktionen in der Form: Zum Beispiel eignen sich die arabischen Zahlen besser zum Rechnen als die römischen) helfen.

Ein Kredo für mehr Mut zum Neuen!

An Introduction to Microsoft Silverlight Controls Framework
Kathy Kam, Lead Program Mamager for Silverlight

Ich kann mich noch daran erinnern, als Silverlight 1.1 released worden war. Laut Ankündigung sollte damals die Frontend Entwicklung für Web Applikationen revolutionieren werden: Der Geneigte Programmierer hatte einen Texblock und ein Multimedia-Element zur Verfügung! Bei Silverlight 2 ist doch schon einiges mehr dabei.

http://silverlight.net/samples/sl2/silverlightcontrols/run/default.html

Damit noch nicht genug ist vor zwei Wochen ein Control Toolkit released worden, in dem weitere hight-level controls enthalten sind.

http://silverlight.net/samples/sl2/toolkitcontrolsamples/run/default.html
Dieser Toolkit wird mit Sourcecode und unittests ausgeliefert. Die enthaltenen Controls sind in unterschiedlichen Entwicklungsstadien und die EntnwicklerInnen können Feedback dazu geben.

Im zweiten Teil der Präsentation ging es um Styles und Templates. Ein gut
gebautes Silverlight Control (ich meine das nicht zweideutig) kann entweder über den Style verändert werden (setzen einzelner Properties in einer Style Definition) oder wir können durch ein eigenes Control Template die Erscheinung des Controls selber bestimmen. Alles nach dem Motto ‚feel free‘!

Die Entwicklung der Silverlight Control Libraries schreitet rasant voran. Ich gebe aber auch dem Miguel Jiménez Recht, wenn er davor warnt, einfach nur die bekannten Controls einzusetzen und dabei das Neue aus den Augen zu verlieren.

In diesem Sinne
Gruss aus Barco
Urs

Seite 1 von 3123