INTEGRATION IN DER CLOUD - OHNE INTEGRATIONSSERVER QUIBIS INTERNET SERVICE BUS WHITEPAPER

Transkript

1 INTEGRATION IN DER CLOUD - OHNE INTEGRATIONSSERVER QUIBIS INTERNET SERVICE BUS WHITEPAPER

2 QUIBIS INTERNET SERVICE BUS QUIBIS ISB bringt Integration in die Cloud... 1 Integration von Inhouse-Systemen mit Diensten in der Cloud... 1 Cloud-Dienste als (effizienteres) Werkzeug für Integrationsaufgaben... 1 QUIBIS ISB: cloud-basierte Integration ohne Integrationsserver... 1 Einfach... 1 Funktional vollständig... 1 Integration as a Service... 2 QUIBIS ISB Architektur... 2 QUIBIS ISB Plugs... 3 Relay Service... 3 Windows Service... 4 QUBIS ISB Engine... 5 QUIBIS ISB Portal... 6 Nachrichtenverarbeitungsprozesse... 9 Tracking und Archivierung in SQL Azure Sicherheit Webanwendung (Konfiguration) Service Bus (Messaging) Kostenabschätzung Azure Grundkosten Azure Verarbeitungskosten QUIBIS ISB Lizenzierung Skalierungsbeispiel Vorteile der Integration mit QUIBIS ISB FAQ Rechtliche Hinweise: QUIBIS, die QUIBIQ Business Integration Suite auf Basis von Microsoft Technologie, ist ein Produkt der QUIBIQ GmbH. QUIBIQ hat an QUIBIS die alleinigen Urheberrechte und schließt jegliche Nutzung von QUIBIS auch in allen Spezialausprägungen sowie einzelner Komponenten durch Dritte aus; es sei denn auf Basis eines schriftlichen Lizenzvertrages. Microsoft, Windows, BizTalk Server,.Net, Silverlight, Azure, AppFabric sind entweder Marken oder eingetragene Marken der Microsoft Corporation. Andere in diesen Unterlagen aufgeführte Produkt- und Firmennamen sind möglicherweise Marken der jeweiligen Eigentümer. Die in diesem Dokument enthaltenen Informationen zu QUIBIS und allen ihren Ausprägungen stellen die behandelten Themen aus Sicht von QUIBIQ zum Zeitpunkt der Veröffentlichung dar. QUIBIQ kann für die Richtigkeit der hier dargelegten Informationen nach dem Zeitpunkt der Veröffentlichung nicht garantieren. QUIBIQ schließt daher für dieses Dokument jede Gewährleistung aus, sei sie ausdrücklich oder konkludent. QUIBIQ sichert mit diesem Dokument insbesondere keinerlei Eigenschaften seiner Produkte zu, es sei denn diese werden explizit als garantiert bezeichnet. Besitzer dieses Dokuments sind verpflichtet, sich an geltende Urheberrechtsgesetze zu halten. Unabhängig von deren Anwendbarkeit darf ohne ausdrückliche schriftliche Erlaubnis von QUIBIQ kein Teil dieses Dokumentes für irgendwelche Zwecke vervielfältigt oder elektronisch an Dritte verteilt werden. Dieses Dokument ist ausschließlich für den internen Gebrauch bestimmt und darf weder vervielfältigt noch an andere Unternehmen oder externe Personen weitergegeben werden.

3 QUIBIS ISB BRINGT INTEGRATION IN DIE CLOUD Die Akzeptanz von Cloud-Diensten wächst zunehmend. Auf dem Gartner-Hype-Cycle sind daher längst viele Lösungen von der Wellenspitze auf das Plateau of Production gewandert. Cloud-Anwendungen, wie z.b. CRM online, sind zu einem wichtigen Standard in ihrem jeweiligen Bereich geworden. Damit ist auch der Bedarf an Integration - dem Austausch von Daten zwischen und mit diesen Systemen - in zweifacher Hinsicht gestiegen: INTEGRATION VON INHOUSE-SYSTEMEN MIT DIENSTEN IN DER CLOUD Artikel- und Preisinformationen in dem schnell und einfach installierten CRM online sollen laufend mit denen im SAP übereinstimmen ohne manuelle Nachpflege. Kunden, die sich in einer App registrieren, sollen automatisch im lokalen CRM angelegt werden. Die Cloud ist also ein neuer Endpunkt für Integration geworden. Welche Möglichkeiten zur effizienten Anbindung gibt es dafür? CLOUD-DIENSTE ALS (EFFIZIENTERES) WERKZEUG FÜR INTEGRATIONSAUFGABEN Mit dem Betrieb klassischer Systeme, wie z.b. SAP, in der Cloud lassen sich zum Teil hohe Einsparungen realisieren. Gilt dies auch für Integrationslösungen? Können Systeme on premise effizienter über die Cloud miteinander verbunden werden als über einen lokalen Integrationsserver? Und wenn ja, in welchen Szenarien? QUIBIS ISB: CLOUD-BASIERTE INTEGRATION OHNE INTEGRATIONSSERVER Der QUIBIS Internet Service Bus (QUIBIS ISB) ist eine Antwort auf beide Frage- bzw. Aufgabenstellungen. QUIBIS ISB ist eine vollständig cloud-basierte Integrationslösung. Der Dienst erweitert Windows Azure um zentrale Integrationsfunktionen, die man sich von einem voll-umfänglichen ESB (enterprise service bus) in der Cloud erwartet und bindet gleichzeitig lokale Anwendungen nahtlos über Plugs an. QUIBIS ISB ist damit Integration as a Service: einfach, funktional vollständig und cloud-basiert. EINFACH QUIBIS ISB ist eine vollständig vorbereite Integrationsplattform in der Cloud. Integration über QUIBIS ISB wird konfiguriert und nicht entwickelt. Über eine moderne Web-Oberfläche wird die Installation durchgeführt, die systemspezifischen Parameter konfiguriert und der laufende Betrieb überwacht. FUNKTIONAL VOLLSTÄNDIG Herausforderungen im Rahmen der Integration mit der Cloud wie Connectivity nach außerhalb des Firmennetzwerks (Web-Service-Kommunikation durch Firewalls, Namensauflösung, IP-Adressierung), Sicherheit (Authentifizierung und Autorisierung von Usern außerhalb der eigenen Organisation), Exponierung von nicht web-service-fähigen Systemen etc. sind in QUIBIS ISB vorgedacht und im Standard gelöst. Typische Prozessschritte im Rahmen der Integration von Systemen wie Read, Write, Map, Look-Up sind als Bausteine vorgefertigt und können zu einem vollumfänglichen Integrationsprozess zusammengeklickt werden. 1

4 INTEGRATION AS A SERVICE Für die Integration über QUIBIS ISB ist kein Integrationsserver wie z.b. Seeburger BIS oder Microsoft BizTalk-Server nötig. Die Aufwände für Lizenzen, Betrieb und den Aufbau von Spezial-Know-how entfallen. Dagegen kann man alle Vorteile von Microsoft Azure nun auch im Bereich der Integration nutzen: Pay-as-you-go, garantierte Verfügbarkeit, Skalierbarkeit on demand. QUIBIS ISB ARCHITEKTUR QUIBIS ISB ist das jüngste Produkt innerhalb der QUIBIS: der QUIBIQ Business Integration Suite, in der das Know-how aus über 400 Integrationsprojekten auf Basis von Microsoft-Technologien gebündelt ist. QUIBIS ISB nutzt die Service-Bus-Funktionen von Windows Azure sowie die Datenbankdienste von SQL Azure, um den Datenaustausch zwischen verschiedenen Anwendungen (z.b. SAP, Dynamics NAV, AX, CRM - on premise sowie online) sicher, leistungsfähig und effizient zu bewältigen. Während lokale Anwendungen über die QUIBIS ISB Plugs in Form von WCF-Diensten (Windows Communication Foundation) gekapselt und mit den zugehörigen Sicherheitsmechanismen angebunden sind, erfüllt die Cloud-Komponente QUIBIS ISB Engine alle klassischen Funktionen eines Enterprise Service Bus. Der Nachrichtenaustausch zwischen den verschiedenen Systemen eines Unternehmens, die Prozesse und die Administration liegen damit komplett in der Cloud, lediglich die Plugs für die effiziente Anbindung der Applikationen sind lokal installiert. Abb. 1: Gesamt-Architektur von QUIBIS ISB 2

5 Eine QUIBIS ISB Implementierung besteht damit aus je einem QUIBIS ISB Plug pro angebundener Applikation und der QUIBIS ISB Engine als zentralem Azure Cloud Dienst für die Nachrichtenverarbeitung (Messaging), die System-Konfiguration und das Monitoring. Die Bearbeitung und Weiterleitung von Nachrichten innerhalb der QUIBIS ISB Engine wird durch Prozesse vorgenommen. Ein Prozess kann z.b. eine Nachricht aus einem SAP System so aufbereiten und umwandeln, dass diese Nachricht anschließend an ein CRM System übertragen werden kann. QUIBIS ISB PLUGS Lokale Systeme (on premise) werden über QUIBIS ISB Plugs an die QUIBIS ISB Engine angebunden. Darüber werden die klassischen Herausforderungen der Verbindung von Systemen nach außerhalb des Firmennetzwerks adressiert: Lokale Systeme liegen meist hinter einer Reihe von Firewalls im Intranet. Evtl. ist Kommunikation von innen nach außen zugelassen, aber typischerweise aus Sicherheitsgründen nicht umgekehrt. Lokale Systeme sind nicht immer cloud-aware, d.h. sie bieten keine Möglichkeit, ihre Dienste in der Cloud (als Web Service) zu veröffentlichen. RELAY SERVICE Über ein QUIBIS ISB Plug wird eine sichere Verbindung zur QUIBIS ISB Engine hergestellt. Dazu wird der Relay-Mechanismus von Windows Azure verwendet. Ausgehend vom Plug wird darüber ein sicherer Kanal zur QUIBIS ISB Engine hergestellt. Dafür wird im Standard der Port 443 für https-kommunikation nach außen verwendet, der üblicherweise in Firewalls freigegeben ist oder bedenkenlos freigegeben werden kann. Über diesen sicheren Kanal kann das Plug nun Nachrichten, die es von einer Applikation, z.b. SAP, entgegen nimmt als SOAP Nachricht zum Service Bus in der Microsoft Azure Cloud weiterleiten als auch auf dem umgekehrten Weg, Anforderungen aus der Microsoft Azure Cloud als Nachricht entgegen nehmen und an eine lokale Applikation, z.b. CRM, weiterleiten. Während also zur Einrichtung des sicheren Kanals nur eine ausgehende https-verbindung benötigt wird, kann ein QUIBIS ISB Plug über den Relay-Mechanismus gleichzeitig sowohl als Empfänger als auch als Sender fungieren. RelayBinding Client QUIBIS ISB Plug Abb. 2: Sichere Verbindung des QUIBIS ISB Plug in die Cloud über Azure Relay-Services 3

6 Die gesamte Kommunikation findet sicher verschlüsselt statt. Der Zugriff wird über shared secret tokens autorisiert (siehe Kapitel Sicherheit). Da im Bedarfsfall über den bereits bestehenden Kanal kommuniziert wird, ist kein dedizierter Verbindungsaufbau pro Web-Service-Aufruf erforderlich. Das bringt einen deutlichen Performanzgewinn und verringert Latenzzeiten signifikant. QUIBIS ISB Service Bus Azure Cloud QUBIS ISB PLUG SAP QUIBIS ISB PLUG CRM Abb. 3: Kommunikation zwischen Plug und der Cloud WINDOWS SERVICE Der QUIBIS ISB Plug wird als einfacher Windows Service auf einem Windows Rechner im Netzwerk des Ziel- bzw. Quellsystems installiert. Der Plug selbst bezieht seine Konfigurationsinformationen (wo und wie er sein Zielsystem erreicht) aus der Cloud. Diese werden in der QUIBIS ISB Engine für diesen hinterlegt und dynamisch abgefragt (siehe nächstes Kapitel: QUIBIS ISB Engine). Plugs sind somit lose an die QUIBIS ISB Engine gekoppelt und nicht hart verdrahtet. Die angebundenen Systeme werden über die Plugs vollständig gekapselt. Änderungen und Erweiterungen können darin flexibel vorgenommen werden. Die Administration erfolgt von zentraler Stelle. Da der QUIBIS ISB Plug als Windows Service ausgeführt wird, bringt er alle Vorteile eines solchen Services mit: z.b. kann der QUIBIS ISB Plug mit einem eigenen Domänen Account ausgeführt werden. Bei einem Absturz des Rechners steht der QUIBIS ISB Plug automatisch wieder zur Verfügung, wenn der Rechner hochgefahren wird. Hierzu muss die Startoption für den Windows Service nur entsprechend auf automatisch eingestellt sein. Der Plug kann dann wieder seine Tätigkeit aufnehmen, ohne dass ein Administrator eingreifen muss. 4

7 Ein weiteres wichtiges Feature ist die standardmäßige Möglichkeit zur Lastverteilung über Plugs. Im Falle einer Skalierung des ISB (auf mehrere Maschinen in der Cloud) wird die Last der Nachrichtenübermittlung automatisch gleichmäßig auf diese durch das Plug verteilt. Tab. 1: Factsheet QUIBIS ISB Plug QUIBIS ISB Plug (Factsheet) Bindet lokale Systeme an die QUIBIS ISB Engine in der Cloud an Leichtgewichtiger Windows-Dienst: einfach zu installieren, benötigt keinen dedizierten Server und nur minimale System-Ressourcen Auch nicht-cloud- bzw. web-service-fähige Systeme (wie z.b. Datenbanken) können darüber bi-direktional angebunden werden Sichere Kommunikation über Firewall durch Relay-Binding Sicherheit durch Verschlüsselung und sichere Autorisierungsmechanismen Lastverteilung bei Skalierung gewährleistet QUBIS ISB ENGINE Das Herzstück von QUIBIS ISB ist die Nachrichtenverarbeitung in der QUIBIS ISB Engine. Hier werden die Nachrichten analysiert, aufbereitet, für das Zielsystem konvertiert und angepasst sowie schließlich weitergeleitet. Die gezielte Verarbeitung der Nachrichten in der QUIBIS ISB Engine (Messaging) wird durch bereits vorgefertigte und im Standard enthaltene Tasks (Prozessschritte) abgebildet. In diesen Tasks sind die typischen Aufgaben im Rahmen der Nachrichtenverarbeitung bereits gebündelt und vorgefertigt: Die eine Gruppe der im Standard ausgelieferten Tasks umfassen allgemeine Aufgaben, die unabhängig von den angebundenen Systemen durchgeführt werden können bzw. müssen. Ein Beispiel hierfür wäre der Prozessschritt Mapping, der es ermöglicht, eine (z.b. von SAP) hereinkommende Nachricht (über XSLT) so zu transformieren, dass ein Zielsystem, z.b. NAV, diese Nachricht lesen und übernehmen kann. Andere Tasks sind systemspezifisch vorgefertigt und erlauben es, bestimmte Aufgaben in dem jeweiligen System auszuführen, z.b. der Read SAP Task, welcher aktiv im SAP nach bestimmten Nachrichten fragt. 5

8 Die Bedienungs-Oberfläche für QUIBIS ISB stellt eine Silverlight Anwendung dar: das QUIBIS ISB Portal. Über dieses können alle notwendigen Konfigurationen der Engine sowie der Plugs an zentraler Stelle durch den Administrator vorgenommen und auch überwacht werden: Registrierte Plugs werden darüber konfiguriert Neue Prozesse werden über die Oberfläche erstellt bzw. bestehende geändert, indem die vorgefertigten Tasks zusammen konfiguriert werden und als Nachrichtenverarbeitungsprozess abgespeichert werden Des Weiteren können hier bereits verarbeitete Nachrichten eingesehen werden Der Zustand des QUIBIS ISB Systems in der Cloud kann überwacht werden. Zudem kann auch festgestellt werden, ob die einzelnen Plugs noch am Leben sind. Im Folgenden wird die Funktionsweise des QUIBIS ISB Engine anhand der Verwaltungsmöglichkeiten im QUIBIS ISB Portal näher erläutert. QUIBIS ISB PORTAL Das QUIBIS ISB Portal ermöglich die Überwachung des Systems und das Erstellen und Bearbeiten von Nachrichtenverarbeitungsprozessen aus Tasks. BEREICH OVERVIEW Im Bereich Overview kann QUIBIS ISB auf die Schnelle überwacht werden. Alle relevanten Informationen sind hier auf einen Blick verfügbar. Abb. 4: Überblick: Überwachung auf die Schnelle 6

9 Die erste Spalte enthält allgemeine Information über das QUIBIS ISB System: Total processes: zeigt die Anzahl der von Ihnen angelegten Prozesse an Total endpoints: zeigt die verbunden Systeme an Total tasks: zeigt die zur Zeit in QUIBIS ISB zur Verfügung stehen Tasks an. Ein Prozess besteht aus einem oder mehreren Tasks. Total plugs: zeigt die installierten und registrierten Plugs an. Die zweite Spalte zeigt die für die Nachrichtenverarbeitung spezifischen Informationen an: Finished processes: gibt die Anzahl der erfolgreich bearbeiteten Nachrichten an Running processes: gibt die Anzahl der gerade laufenden Nachrichtenprozesse an Failed processes: gibt die Anzahl der fehlgeschlagen Nachrichtenverarbeitungsprozesse an Messages received in the last x days: gibt die Anzahl der Tage an, in denen Nachrichten verarbeitet wurden (seit dem letzten Reset). BEREICH RUNTIME Im Bereich Runtime wird ein genauer Überblick über alle verarbeiten Nachrichten geboten. Es kann explizit nach einer Nachricht gesucht werden. Die Nachrichten werden dazu auch nach Prozessen gruppiert. Unter Details können die Original-Nachrichten im Detail angesehen werden um z.b. bei einer fehlgeschlagen Verarbeitung die Ursache zu finden. Abb. 5: Detaillierte Überwachung der Nachrichtenverarbeitung 7

10 BEREICH PLUGS Unter Plugs finden sich alle installierten und registrierten Plugs. Zusätzlich kann hier der Zustand der Plugs überwacht werden. Abb. 6: Überwachung der Plugs BEREICH CONFIGURATION Unter Configuration können die Nachrichtenverarbeitungsprozesse angelegt bzw. angepasst werden. Diese werden aus den vorgefertigten Tasks konfiguriert und mit den entsprechenden Konfigurationsinformationen versorgt. Abb. 7: Konfigurieren eines Prozesses 8

11 NACHRICHTENVERARBEITUNGSPROZESSE Der verlässliche Austausch von Nachrichten zwischen Systemen ist häufig komplexer als Fire and Forget. In QUIBIS ISB sind typische Aufgabenstellungen, die im Rahmen der Systemintegration regelmäßig vorkommen, in vorgefertigten Tasks abgebildet. Derzeit gibt es sechs verschiedene Kategorien solcher Tasks. Aus diesen können auch komplexe Messaging Prozesse, wie sie in der Synchronisation von Systemen häufig erforderlich sind, einfach durch Konfiguration abgebildet werden. Im Folgenden sind die aktuell im Standard verfügbaren Tasks, aus denen Messagingprozesse konfiguriert werden können, kurz beschrieben. TASK XSLT MAPPING Durch den XSLT Mapping Task, kann eine Nachricht in eine andere Nachricht konvertiert werden. Damit kann eine Nachricht vom Quellsystem an das Nachrichtenformat des Zielsystems angepasst werden. Für die Konvertierung wird XSLT, ein W3C Standard, eingesetzt. Das XSLT kann individuell erstellt werden und einfach in die Konfiguration des Tasks hochgeladen werden. TASK LOOKUP REFERENCES Der Task Lookup References ermöglicht das Nachschlagen eines Wertes in einem System. Dies löst eine der häufigsten Anforderungen im Rahmen der Synchronisation von Systemen. Liefert z.b. das Quellsystem nur die ID zu bspw. einer Person, während das Zielsystem aber zusätzlich den Namen als Mussfeld benötigt, so kann dieser Wert durch den Task Lookup References eingelesen und die Anforderung erfüllt werden. TASK WRITE Eine Nachricht wird durch den Task Write an ein Zielsystem (z.b. Microsoft Dynamics CRM) übermittelt. TASK READ Durch den Read Task können Nachrichten aus einem Quellsystem (z.b. Microsoft Dynamics NAV) gelesen werden und an weitere Tasks innerhalb des Prozesses weitergeleitet werden. TASK START SUB PROCESS Der Task Start Sub Process ermöglicht es, zeitgesteuert Prozesse zu starten. Dazu wird zunächst der zu steuernde Prozess eingerichtet. Dann wird ein zweiter Prozess eingerichtet, welcher den Task Start Sub Process als Prozessschritt enthält. Diesem wird per Konfiguration mitgeteilt, wann und wie er den ersten Prozess starten soll. TASK LOOKUP OPTION SETS Der Task Lookup Options Sets ermöglich das Nachschlagen der möglichen Auswahlmöglichkeiten für einen Zielwert; also z.b. die Auswahloptionen in einer Pickliste für die Kundenkategorie (A/B/C), welche dem Wert mitgegeben werden müssen. Dieser Task wird konfiguriert. 9

12 TRACKING UND ARCHIVIERUNG IN SQL AZURE QUIBIS ISB arbeitet zur Datenhaltung und Archivierung mit der SQL Azure Datenbank. In SQL Azure werden im Standard alle eingehenden Nachrichten gespeichert. Dazu werden Fehler allgemeiner Art sowie der Zustand eines QUIBIS ISB Plugs protokoliert. Über das QUIBIS ISB Portal können diese Informationen abgefragt und eingesehen werden. SQL Azure QUIBIS ISB Speichern und lesen der Daten Abb. 8: QUIBIS ISB arbeitet mit SQL Azure zusammen SICHERHEIT Ein zentraler Punkt in der heutigen Softwareentwicklung und Bereitstellung für und in der Cloud ist das Thema Sicherheit. QUBIS ISB adressiert dieses voll-umfänglich, indem es die fortgeschrittenen Sicherheitsmechanismen von Azure konsequent und durchgehend ein- und umsetzt. WEBANWENDUNG (KONFIGURATION) Für die Webanwendung gibt es ein differenziertes Rollen- und Rechtekonzept. Es unterscheidet zunächst den Administrator, der Systemkonfigurationen vornehmen kann, vom Sachbearbeiter, der Informationen zu bestimmten Nachrichten und ihrer Verarbeitung einsehen möchte. Die Anmeldung am System erfolgt über eine Windows Live ID. Nach erfolgreicher Autorisierung des Zugriffs wird überprüft, welche Rolle der Zugreifende besitzt und welche Berechtigungen ihm entsprechend zustehen. Die gesamte Kommunikation mit der Web-Anwendung findet über https sicher verschlüsselt statt. Abb. 9: Anmeldung mit einer Windows Live ID bei QUIBIS ISB 10

13 SERVICE BUS (MESSAGING) Für die Kommunikation zwischen QUIBIS ISB Plug und QUIBIS ISB Engine werden die Azure Service Relay Mechanismen verwendet. Diese stellen spezielle, abgesicherte Bindings zur Web Service- Kommunikation mit Azure zur Verfügung. Diese Bindings verhalten sich wie Standard WCF Bindings (nettcprelaybinding, basichttpbinding, wshttpbinding etc.) fügen diesen jedoch die Fähigkeit hinzu, via ausgehende Kommunikation einen sicheren Kanal aufzubauen (Relay), über den dann im Einzelfall einund ausgehend kommuniziert werden kann. Die Security Mechanismen dieser Relay Bindings entsprechen vollständig den Standard WCF Bindings und erweitern diese in die Cloud. Die gesamte Kommunikation ist darüber auf Transportebene verschlüsselt. Die Authentifizierung erfolgt über die Sicherheitsmechanismen der Access Control Services (ACS) von Microsoft Azure (Shared Secret Token). Diese Shared Secret Tokens werden bei der Konfiguration des Servicebus ACS Namespaces erstellt. Nur mittels dieses Shared Secret Tokens kann mit dem ISB kommuniziert werden. KOSTENABSCHÄTZUNG Die Preisgestaltung von QUIBIS ISB erfolgt auf der Grundlage des nutzungsabhängigen Preismodells von Windows Azure. Die Gesamtkosten für den Betrieb eines QUIBIS ISB teilen sich wie folgt auf: Azure Grundkosten: Diese entstehen, wenn man die Anwendung in der Cloud installiert und somit Rechnerleistung dafür in Azure nutzt. Entsprechend der Skalierung der Ressourcen (Anzahl Rechner, Speicherplatz etc.) werden diese monatlich von Microsoft abgerechnet. Azure Verarbeitungskosten: Sobald Nachrichten ausgetauscht werden, fallen verbrauchsabhängig weitere Kosten dafür an die Azure Verarbeitungskosten. QUIBIQ Lizenzkosten. Diese fallen für die Nutzung von QUIBIS ISB an. Die folgenden Preise entsprechen der jeweiligen Preisliste gültig zum Zeitpunkt Juli 2012 und wurden in Bezug auf Windows Azure mit Hilfe des Windows Azure Pricing Calculators ( ermittelt. Die genannten Preise sind daher unverbindlich und können jederzeit durch Microsoft oder QUIBIQ geändert werden bzw. worden sein. AZURE GRUNDKOSTEN Für den Betrieb von QUIBIS ISB wird ein Windows Azure-Account benötigt. Sofern noch kein Konto vorhanden ist, muss dieses unter angelegt werden. Nach der Installation von QUIBIS ISB wird dieser im Windows Azure Portal, das unter erreichbar ist, als Dienst angezeigt. Mit dieser Installation fallen die Azure-Grundkosten an und werden von Microsoft direkt über den Azure-Account abgerechnet. 11

14 Preisbeispiel: Die Grundkosten für die kleinste, sinnvolle Konfiguration (Installation aller QUIBIS ISB Engine Komponenten auf einer virtuellen Windows Azure Maschine in der Größe S (mögliche Auswahl XS, S, M, L, XL) mit insgesamt 100GB-Storage und einer SQL Azure DB mit 5GB Speicherplatz) belaufen sich auf ungefähr 66 /Monat. Eine Skalierung ist bei Bedarf über das Zuschalten weiterer Maschinen jederzeit möglich siehe Unterpunkt Skalierung AZURE VERARBEITUNGSKOSTEN Werden Nachrichten mit dem QUIBIS ISB ausgetauscht, z. B. zwischen SAP und MS CRM, dann fallen Azure Verarbeitungskosten dafür an: einmal für das Relaying, den bzw. die eingerichteten Kommunikationskanäle, zwischen der QUIBIS ISB Engine und den QUIBIS ISB Plugs sowie für das Messaging, die Nachrichtenverarbeitung innerhalb des Service Bus. Mit 7,5 pro Relay-Stunden und 0,07 pro Nachrichten (à 64 Kb) fallen diese jedoch kaum ins Gewicht. Rechenbeispiel: Ein 24 x 7 Betrieb mit zwei Endpunkten entspricht 2 x 720 Relay-Stunden pro Monat (= 1,08 für das Relaying). Die Verarbeitung von Nachrichten à 1 MB im Monat verursacht zusätzlich Azure- Verarbeitungskosten in Höhe von 5 x 0,07 x (1 MB / 64 KB) = 0,35 x 16 = 5,60 QUIBIS ISB LIZENZIERUNG Analog Azure werden die Lizenzkosten für die Nutzung von QUIBIS ISB monatlich in Abhängigkeit von der tatsächlichen Nutzung abgerechnet. Der Preis beträgt monatlich 5 pro Endpunkt: ein Endpunkt entspricht einem angebundenem System 30 pro Prozess: ein Prozess leistet die Nachrichtenübertragung von einem Endpunkt zu einem anderen (in eine Richtung also z.b. Kontakte von SAP nach CRM) Die Mindestkonfiguration gemäß der QUIBIQ Lizenzbedingungen beträgt 2 Endpunkte (à 5 ) und 4 Prozesse (à 30 ) - entspricht 130 pro Monat. Rechenbeispiel: Die Übertragung von Angeboten und Aufträgen von CRM nach SAP, von Rechnungen von SAP nach CRM und der bi-direktionale Austausch von Kunden (Debitoren) kostet 10 für die zwei Endpunkte (SAP und CRM) und 5 x 30 für die Prozesse (3 unidirektionale und ein bi-direktionaler), also 160 / Monat. Kommt z.b. eine lokale DB für einen einfachen Lookup hinzu (z.b. Ergänzung eines länderspezifischen Nummernkreises in der Nachricht für SAP), so erhöht sich der Preis um einen Endpunkt à 5 auf 165 pro Monat. 12

15 SKALIERUNGSBEISPIEL In der Basiskonstellation mit einer S-Maschine (zum Preis von rd. 66 pro Monat - siehe Unterpunkt Azure Grundkosten) wurde im Echtbetrieb mit einem einfachen, unidirektionalen Prozess ein Durchsatz von 4 Nachrichten pro Sekunde erreicht (entspricht Nachrichten in knapp 7 Stunden). Durch Online-Zuschalten einer zweiten S-Maschine mit Zusatzkosten in Höhe von 0,06 /h konnte der Durchsatz in Echtzeit linear auf 8 Nachrichten pro Sekunde erhöht werden. Für höhere Anforderungen an den Durchsatz aber auch z.b. für eine einmalige, performante Synchronisierung von Massendaten (z.b. bei Erstbefüllung des Systems bzw. bei Voll-Updates zum Quartalsbeginn) kann so bedarfsgerecht linear skaliert werden und nach Abschluss wieder in den Normalbetrieb zurückgeschaltet werden. VORTEILE DER INTEGRATION MIT QUIBIS ISB Mit dem QUIBIS Internet Service Bus bringt QUIBIQ Integration in die Cloud. In dazu passenden Szenarien ergeben sich damit klare Vorteile für Integrationsprojekte: Integration ohne IT-Footprint: Keine lokale Installation eines Integrationsservers wie z.b. BizTalk Server erforderlich. Folglich keine Lizenz- und Hardwarekosten für die Anschaffung, kein Aufbau von Spezial-know-how für Einrichtung und Administration und keine Kosten für die Sicherstellung des performanten und hochverfügbaren Serverbetriebs. Durchgehend nutzungsbasierte Abrechnung: Windows Azure und QUIBIS ISB werden nach Verbrauch abgerechnet und sind monatlich kündbar. Volle Konnektivität zu Anwendung on premise: Systemspezifische Plugs zu SAP, NAV, AX und CRM sowie allgemeine Plugs für Web Service, File (XML) und SQL sind vorhanden und im Standard enthalten. Für weitere Plugs zu weiteren Backend-Systemen sowie für weitere, allgemeine Plugs z.b. für Flatfile-Schnittstellen gibt es eine klare Roadmap. Flexibilität: Abbildung individueller Prozesse für die Verarbeitung von Nachrichten in der Cloud. Cloud-basiertes Archiv für Zugriff auf Originalnachrichten. Zentrale Administrationskonsole zur Steuerung und Überwachung des Nachrichtenflusses. Zentrales Fehlerhandling. Durchgehende Transaktionalität. Skalierbarkeit: Rechenkapazität für performante Abarbeitung auch hoher Datenvolumina wird dynamisch bereitgestellt. 13

16 FAQ Kann QUIBIS ISB auch lokal eingesetzt werden? QUIBIS ISB ist komplett unter Windows Azure entwickelt und kann, sobald der Azure Service Bus auch on premise verfügbar ist (vss. Q1/2013), auch lokal installiert und verwendet werden. Kann QUIBIS ISB nur 1:1 Verarbeitung zwischen einem Quell- und einem Zielsystem abbilden? QUIBIS ISB ist ein vollwertiger Service Bus und kann somit n:m Systeme miteinander vernetzen. Splitten, Duplizieren und Zusammenfassen von Nachrichten während der Verarbeitung ist möglich. Wie komplex können die Prozessschritte innerhalb von QUIBIS ISB werden? Im Standard sind fertige Prozessschritte enthalten, die für die Synchronisation von ERP-Systemen und Microsoft CRM vorbereitet sind. Eigene Prozessschritte können QUIBIS ISB hinzugefügt werden und da diese innerhalb des.net-frameworks entwickelt werden, sind keine Grenzen bzgl. Komplexität oder Funktionalität gesetzt. Wie können IF/ELSE Verknüpfungen zwischen Feldern abgedeckt werden? QUIBIS ISB verwendet gleich wie BizTalk intern XSLT zur Transformation von Nachrichten. Hier können IF/ELSE Verknüpfungen einfach abgebildet werden. Wie sieht die Entwicklung von Schemata und Mappings ohne BizTalk Tools (z.b. Mapper) aus? Die BizTalk Developer Edition ist kostenlos und kann zur Entwicklung herangezogen werden. Maps und Schemas können schnell und einfach in VisualStudio mit den BizTalk Werkzeugen Schema- Editor und Intelligent-Mapper erstellt werden und dann als XSD oder XSLT in QUIBIS ISB eingesetzt werden. Alternativ bieten sich Werkzeuge wie XMLSpy o.ä. für die Bearbeitung an. Wie sicher sind die Verbindungen zu den Plugs? Für die Kommunikation mit dem ISB werden spezielle Azure Relay Bindings verwendet. Diese verhalten sich wie Standard WCF Bindings fügen jedoch die Fähigkeit hinzu, via Azure Servicebus zu kommunizieren. Die Security Mechanismen dieser Relay Bindings entsprechen vollständig den Standard WCF Bindings. Für die Kommunikation zwischen Plugs und ISB wird das nettcprelaybinding mit SecurityMode Transport verwendet, d.h. die Kommunikation ist auf Transportebene verschlüsselt. Authentifizierung erfolgt über Shared Secret Tokens, die bei der Konfiguration des Servicebus Namespaces erstellt werden. Nur mittels dieser kann mit dem ISB kommuniziert werden. Worauf ist bei Firewall Konfiguration zu achten? Für die Kommunikation zwischen Plug und ISB müssen für die Maschinen, auf welchen die Plugs ausgeführt werden, mindestens die Ports 80 und 443 für ausgehende Kommunikation geöffnet werden. Sollen auch noch effizientere TCP Verbindungen für die Kommunikation verwendet werden, so kann dies über die Öffnung der Ports 9350 bis 9354 für ausgehende Kommunikation erreicht werden. Ein Web Proxy ist gegebenenfalls zu deaktivieren. Wie skaliert QUIBIS ISB in der Windows Azure Cloud? QUIBIS ISB wird auf einem vom Kunden definierten Sizing innerhalb der Windows Azure Cloud ausgeführt. Das Sizing (XS, S, M, L, XL) und die Anzahl der Maschinen bestimmen die maximal zur Verfügung stehenden Ressourcen. Diese können auf einfache Art und Weise bei Bedarf im Azure- Abonnement verändert und angepasst werden. Ist z.b. eine Initialverarbeitung von mehreren Millionen Datensätzen in sehr kurzer Zeit erforderlich, so kann das Abonnement kurzfristig auf mehrere S-Maschinen eingestellt werden (mit Zusatzkosten von 0,06 / h und Maschine) und im Anschluss wieder verringert werden. 14

17 Ansprechpartner für QUIBIS ISB bei QUIBIQ: Michael Bäuerle Geschäftsführer QUIBIQ GmbH Heßbrühlstr Stuttgart Tel michael.baeuerle@quibiq.de 15