Mobile und Internet der Dinge

News

Nr. 2 | Mai 2014 | ISSN 09 36-0360 | www.doag.org

Im Interview

Mobile

Internet der Dinge

Günther Stürner zu In Memory

• Apex-Applikationen für Tablets

• Lufthansa Realtime Tracking

• ADF Mobile in der Praxis

• Industrielle Revolution 4.0

DOAG 2014 Development 4. Juni 2014 in Düsseldorf

Frühbuche

rr

25.April 2abatt 014

development.doag.org Logistik auf dem Weg zur Industrie 4.0 Geschäftswissen für die Logistik

DOAG 2014 Logistik + IT Community-Konferenz Logistik 4.0 7. Mai 2014 | Fraunhofer IML Dortmund

http://logistik.doag.org

Editorial

Liebe Mitglieder, liebe Leserinnen und Leser,

Robert Szilinski Leiter der Development Community

glaubt man aktuellen Prognosen, wird im Jahr 2017 das historische Ereignis eintreten, dass es erstmals mehr mobile Endgeräte als Menschen auf der Erde gibt. Damit dürfte klar sein, warum das InternetProtokoll IPv4 mit rund 3,7 Milliarden nutzbaren Adressen durch IPv6 ersetzt werden musste, um das Internet vor dem Kollaps zu bewahren. Doch nicht nur die rasant wachsende Anzahl mobiler Endgeräte ist es, die unser Leben massiv verändert. Um zu verstehen, was derzeit passiert, lohnt sich ein Blick zurück. Anfang der 1990er Jahre hatte James Gosling mit seinem Team eine geniale Idee: Er wollte eine neue Programmiersprache entwerfen, die plattformunabhängig ist und damit auf jedem Gerät verwendet werden kann. Herausgekommen ist damals Oak. Wir kennen es heute als Java und als elementaren Bestandteil des Oracle-Technologiestacks. Damals wie heute gibt es Ansätze, alle denkbaren Haushaltsgeräte miteinander zu verbinden, das Internet verstärkt zur Kommunikation zu nutzen und in völlig neue Dimensionen der Vernetzung vorzustoßen. Inzwischen ist das Internet allgegenwärtig und die Vision ist zur Realität geworden – willkommen beim Internet der Dinge. Egal ob Autos, Kühlschränke oder Schuhe: Wir erleben hautnah, wie immer mehr Gegenstände unseres Alltags vernetzt werden. Google kauft zum Beispiel für viele Milliarden Dollar die Firma Nest mit der Intention, das Smart Home zu kontrollieren. Kleidung ist neuerdings intelligent und sogenannte „Wearables“ melden den Puls zur Kontrolle ans Handy. Und das ist erst der Anfang. Höchste Zeit für uns, die beiden Themen „Mobile“ und „Internet of Things“ gründlich zu beleuchten und aufzuzeigen, welches Potenzial eigentlich darin steckt. Vorwegnehmen möchte ich nur eines: Verfügbare Internetadressen wird es auch die kommenden Jahre ausreichend geben: IPv6 hat Raum für 340 Sextillionen Geräte. In diesem Sinne wünsche ich viel Spaß beim Lesen dieser Ausgabe. Ihr

„ Von Backup bis Business Intelligence: Halten Sie Ihre Daten in Bewegung! “ LIZENZBERATUNG & -VERTRIEB

HOCHVERFÜGBARKEITSLÖSUNGEN & PERFORMANCE TUNING

DATA WAREHOUSING & BUSINESS INTELLIGENCE LÖSUNGEN

Oracle Golden Gate: So schnell, dass Sie es gar nicht merken Daten wandern, Systeme stehen – das war einmal. Mit Oracle Golden Gate sind Datenreplikation, Migration und Upgrade eine Sache von Minuten, und Ihr IT-Betrieb läuft einfach weiter. Oracle Golden Gate fühlt sich nicht nur mit Oracle-Datenbanken wohl. Sie können Ihre Daten auch im heterogenen Datenbankumfeld bequem synchronisieren. Das Tool harmoniert perfekt mit Oracle Data Integrator Enterprise Edition und sorgt dafür, dass Data Warehouses und ReportingSysteme immer in Echtzeit mit dem aktuellsten Datenstand versorgt werden. Informieren Sie sich jetzt bei uns – wir beraten Sie gerne! Hauptsitz Karlsruhe Bannwaldallee 32, 76185 Karlsruhe Tel. 0721-490 16-0, Fax 0721-490 16-29

Geschäftsstelle Bodensee Fritz-Reichle-Ring 6a, 78315 Radolfzell Tel. 07732-939 14-00, Fax 07732-939 14-04

ORACLE APPLIANCES

AUF EINEN BLICK „ Echtzeit-Replikation zwischen Oracle und Non-Oracle Databases „ Zero-Downtime Migration mit Oracle Golden Gate „ Entlastung von Produktionsdatenbanken bei rechenintensiven BI-Reporting- und ETL-Vorgängen „ Schnelle Datenbank-Synchronisation zwischen Remote-Standorten

[email protected], www.hunkler.de

DOAG News 02-2014

3

Inhalt

28

37

50

Industrie 4.0

Exadata und Exalogic X4-2

Oberflächenentwicklung mit Oracle ADF

Einleitung

Mobile

Internet der Dinge

3 Editorial

9

Finger weg von meinem Telefon! Steffo Weber

5 Spotlight 6

„Die Data Warehouse/BI-Nutzer werden diese Technologie lieben …“ Interview mit Günther Stürner, Vice President Sales Consulting, ORACLE Deutschland B.V. & Co. KG.

14 Apex-Applikationen für Tablet-Devices Kai Donato 18 Energie-Unternehmen nutzt ADF Mobile für Wartungseinsätze Stephan La Rocca

24 Internet der Dinge als Treiber für Inte­ grationsprojekte und Mobile Mario Herb 28 Industrie 4.0 Björn Anderseck 32 Lufthansa Realtime Tracking Niko Hossain

22 Neue Oracle Product Suites für mobile Anwendungen Dr. Jürgen Menge

34 Schneller reagieren: Neue IT-Unterstützung von Unternehmensprozessen Dominik Bial

Entwicklung

Best Practice

DOAG intern

42 Liquibase – Database Deployment in agilen Projekten Frank Winter

46 Reference Partitioning in der Praxis Dr. Frank Haney

63 Aus dem Verein

Aktuell 37 Exadata und Exalogic X4-2 Herbert Rossgoderer und Matthias Fuchs 40 Die neue Community-Plattform auf My Oracle Support Karl-Heinz Urban

50 Industrialisierte Oberflächenentwicklung mit Oracle ADF Ralf Ernst und Andreas Koop 60 Oracle Hidden Secrets: DNFS Cloning Sebastian Solbach

4

www.doag.org

56 SAP nach dem Ausfall: Best Practices zum Wiederanlauf komplexer Systeme Franz Diegruber

63 Neue Mitglieder 66 Impressum 66 Termine 66 Inserentenverzeichnis

Rückblick





Spotlight

Donnerstag, 9. Januar 2014

Mittwoch, 19. Februar 2014

Das Team der DOAG-Geschäftsstelle trifft sich zum Kick-off-Meeting, um sich auf die anstehenden Projekte im Jahr 2014 einzustimmen.

Die Oracle-Experten Tom Kyte, Graham Wood und Andrew Holdsworth treten im Rahmen ihrer Real World Performance Tour in München vor mehr als 100 Teilnehmern aus Deutschland, Österreich und der Schweiz auf. Sie stellen in einer kurzweiligen Bühnenshow interessante Performance-Aspekte vor.

Freitag, 10. Januar 2014

Donnerstag, 20. Februar 2014

Das erste Event im neuen Jahr, ein Webinar zur Multitenant-Option der neuen Datenbank 12c, verzeichnet überraschend viele Teilnehmer.

Fried Saacke, DOAG-Vorstand und Geschäftsführer, und Dr. Frank Schönthaler, Leiter der DOAG Business Solutions Community, treffen sich mit Hakan Yüksel, Oracle Software Applications Lead für Deutschland, und Thomas Fricke, Oracle Sales Consulting Application Technology. Sie vereinbaren eine enge Zusammenarbeit bei der Ausrichtung der DOAG 2014 Applications.

Donnerstag, 16. Januar 2014

Freitag, 14. März 2014

Die DOAG Business Solutions Community legt in einer Telefonkonferenz die Eckdaten für die DOAG-Applications-Konferenz fest. Die Veranstaltung wird vom 21. bis 23. Oktober 2014 in Berlin stattfinden. Im Jahr 2015 geht es dann im zweiten Quartal nach Darmstadt.

Die Delegiertenversammlung der DOAG diskutiert ausführlich die Initiative zur Themen-orientierten Ausrichtung des Vereins und nimmt sie einstimmig an (siehe Seite 63). Damit sind die Weichen gestellt, um die DOAG-Mitglieder gezielter anzusprechen.

Donnerstag, 6. Februar 2014

Dienstag, 25. März 2014

Das Organisationsteam der JavaLand 2014 trifft sich im Phantasialand Brühl zur Feinplanung für die erste große Java-Konferenz, die von der DOAG Dienstleistungen GmbH ausgerichtet, gemeinsam mit dem Heise Zeitschriften Verlag präsentiert und zusammen mit den mittlerweile 21 unter dem Dach des Interessenverbunds der Java User Groups e.V. (iJUG) vertretenen Java User Groups gestaltet wird.

Mehr als 800 Teilnehmer aus 18 Ländern nehmen an der JavaLand 2014 im Phantasialand Brühl teil. Damit zählt die neue Veranstaltung auf Anhieb zu den größten Java-Konferenzen in Europa. Die Begeisterung wurde in die ganze Welt getwittert.

Dienstag, 11. Februar 2014

Mittwoch, 26. März 2014

Eine Arbeitsgruppe des DOAG-Vorstands arbeitet ein Konzept aus, um die Zielgruppen des Vereins noch stärker Themen- und Technologie-orientiert ansprechen zu können.

Joel Kallman, Product Manager Oracle Application Express, präsentiert auf dem Regionaltreffen NRW Neuigkeiten rund um Apex 5.0 und stellt sich anschließend den Fragen der Anwender. Die Veranstaltung wird gleichzeitig als DOAG-Webinar live übertragen.

Freitag, 14. Februar 2014

Mittwoch, 2. April 2014

Der DOAG-Vorstand nimmt den Vorschlag der Arbeitsgruppe vom 11. Februar einstimmig an und wird ihn der Delegiertenversammlung zum Beschluss vorlegen. Weitere Themen der Vorstandssitzung sind die beiden Hauptkonferenzen DOAG 2014 Konferenz + Ausstellung und DOAG 2014 Applications.

Die SUSE Linux GmbH bucht zum ersten Mal einen Ausstellerstand zur DOAG 2014 Konferenz + Ausstellung. Friedhelm Uli Ullrich, DOAG-Ansprechpartner für den Ausstellungsvertrieb, kündigt weitere neue Aussteller an.

DOAG News 02-2014

5

Interview

Fotos: Wolfgang Taschner

„Die Data Warehouse/BI-Nutzer werden diese Technologie lieben …“ In Kürze bringt Oracle die In-Memory-Datenbank-Option auf den Markt. Wolfgang Taschner, Chefredakteur der DOAG News, sprach darüber mit Günther Stürner, Vice President Sales Consulting und Leiter der Business Unit Server Technologies bei der ORACLE Deutschland B.V. & Co. KG.

Welche Motivation hatte Oracle für die Entwicklung der neuen In-Memory-Datenbank-Option? Stürner: Ich habe manchmal den Eindruck, dass die Idee der Spalten-orientierten Verarbeitung erst in den letzten drei Jahren erfunden wurde. Dies ist jedoch absolut nicht der Fall. Bereits Anfang der 1970er Jahre wurde heftig diskutiert, welche der beiden Varianten − die Satzorientierte oder die Spalten-orientierte Speicherung von Daten − die bessere ist. Die meisten relationalen Systeme haben sich die Satz-orientierte Speicherung zu eigen gemacht, einige wenige haben die Spalten-orientierte Linie verfolgt. Beide Arten haben ihre Vor- und Nachteile. Die Idee bei der Entwicklung der In-MemoryDatenbank-Option (IMDB) war nun, ein System zu schaffen, das die jeweiligen Vorteile nutzt, ohne dass die Nachteile der Satz- beziehungsweise Spalten-orientierten Technik zum Tragen kommen. Das Ziel war also nicht weniger als die Überwindung des „Row Column“-Dilemmas.

Welche Rolle spielte dabei SAP HANA? Stürner: Wir arbeiten schon seit etlichen Jahren an diesem Projekt. Der Auftritt von SAP HANA hat jedoch die Anstrengungen massiv beschleunigt. SAP HANA hat allerdings nicht nur die interne Priorität des Projekts erhöht, sondern unsere DatenbankEntwickler besonders motiviert, die beste Lösung in diesem Umfeld zu schaffen. SAP hat durch eine massive Marketing-Kampagne die Themen „Columnar“ und „In Memory“ einer breiten Öffentlichkeit bekanntgemacht. Diese Vorarbeit nutzen wir gerne.

Was sind die grundsätzlichen Unterschiede zwischen Oracle-In-Memory und SAP HANA?

6

www.doag.org

Interview

Stürner: Die Grundidee der Systeme ist gleich. Beide nutzen die Vorteile der Spalten-orientierten Speicherung, um bei bestimmten Operationen kurze Antwortzeiten zu erreichen. Der gravierendste Unterschied zwischen beiden Lösungen ist, dass wir eine weitere Technologie in unsere Enterprise-Datenbank integrieren, während SAP mit HANA eine Technologie bereitstellt, um die eine Enterprise-Datenbank noch gebaut werden muss. Hier hat SAP eine Menge Arbeit vor sich und wird noch viel „Blut und Tränen“ vergießen müssen, bis aus HANA eine EnterpriseDatenbank geworden ist. Unser Ziel ist es, die beste In-Memory-Columnar-Technologie anzubieten, die von allen Anwendungen − bestehende wie neu zu entwickelnde − unmittelbar ohne weiteren Aufwand genutzt werden kann. Wir werden diese Technologie mit neuen Algorithmen und der heutigen Hardware-Technologie so verknüpfen, dass völlig neue Möglichkeiten der Verarbeitung von Daten möglich sind.

Stürner: Eine Oracle-Tabelle wird als „In-Memory“ definiert und dann als Spalten-orientierte Repräsentation in einem Bereich der System Global Area im Hauptspeicher abgelegt. Die Zeilen-orientierte Repräsentation auf den Platten und im Hauptspeicher – wir sprechen hier vom Row-Cache − bleibt davon unberührt. Eine als In-Memory definierte Tabelle hat also gleichzeitig beide Eigenschaften – Zeilen- und Spalten-Orientierung. Der SQL-Optimizer ist dafür verantwortlich, welche Datenstruktur bei den jeweiligen Operationen zum Einsatz kommen soll. Bei Transaktionslast wird also der Row-Cache eine wichtige Rolle spielen und bei Lese- und Auswerte-Operationen kommt der Column-Store der jeweiligen Tabellen verstärkt zum Zuge. Dieser duale Ansatz ist einzigartig am Markt. Nicht „entweder/oder“, sondern „sowohl/als auch“ ist die Philosophie, die sich hinter dieser Implementierung verbirgt.

Wie unterscheidet sich die neue In-MemoryDatenbank-Option von Oracle Times Ten?

Stürner: Zum einen werden gemischte OLTP-, Analytic/Reporting-Systeme enorm von dieser Technologie profitieren. Wir gehen hier von verbesserten Transaktionsraten bei gleichzeitiger Beschleunigung der Reports aus. Zum zweiten werden die Data Warehouse/BI-Nutzer aller Analytic/ Reporting-Systeme diese Technologie lieben. Ich möchte an dieser Stelle noch einen Punkt zum Unterschied zwischen der Oracle­In-Memory-Datenbank-Option und SAP HANA erwähnen. Bei unserer Implementierung kann eine komplette Datenbank − also alle Objekte einer Datenbank − als In-Memory definiert werden. Bei SAP HANA müssen zwangsläufig alle Daten einer Datenbank im Hauptspeicher sein, egal ob sie genutzt werden oder nicht. „Alles oder nichts“ lautet bei HANA die Devise. Der Unterschied liegt in den Wörtern „kann“ und „muss“ – ein kleiner Unterschied, aber eine große Wirkung.

Stürner: Times Ten ist vom Design her eine In-Memory-Datenbank für den High-End OLTP-Betrieb. Man spricht hier auch häufig vom Near-Realtime OLTP-Betrieb. Times Ten findet man immer dort, wo extrem viele kurze Transaktionen extrem schnell bearbeitet werden müssen. Wir sehen Times Ten in drei Einsatzszenarien: als Stand-Alone System im High-End-Transaktionsbereich, als Front-End Datenbank-Cache für eine Oracle-Datenbank (Cache Connect Option) und als In-Memory-Datenbank innerhalb unseres Exalytics-Systems. Dies wird sich auch durch die neue In-MemoryDatenbank-Option nicht ändern.

Gibt es die Möglichkeit, zwischen den beiden In-Memory-Datenbanken zu migrieren? Stürner: Hier gibt es keinerlei Unterschiede zu den bisherigen Vorgehensweisen. Auch die Kombination von beispielsweise Oracle-Datenbank mit aktivierter In-Memory-Option in Kombination mit einem Times-Ten-Memory-Cache ist denkbar und in bestimmten Fällen absolut sinnvoll.

Nach welchem Grundprinzip arbeitet die neue In-Memory-Datenbank-Option?

Für welche Anwendungen macht die neue In-Memory-Datenbank-Option Sinn?

die zu lizenzieren ist. Dann können beliebig viele Tabellen, Partitionen von Tabellen, einzelne Spalten von Tabellen oder auch Materialized Views als In-MemoryObjekte definiert werden. Diese Objekte sind dann als Spalten-orientierte Repräsentation innerhalb der SGA in einer hochkomprimierten und spezialisierten Form vorgehalten. Die so definierten Objekte – das geschieht übrigens mit einem einzigen Befehl − können mit beliebigen Operationen (wie insert, update, delete) bearbeitet werden. Die transparente Nutzung aller Datenbank-Funktionen ist garantiert.

Wird für die Nutzung der In-Memory-Datenbank-Option mehr Hauptspeicher benötigt? Stürner: Um die Vorteile der In-MemoryTechnologie nutzen zu können, muss man dem System entsprechend mehr Hauptspeicher zur Verfügung stellen. Wie viel das im Einzelfall ist, hängt davon ab, wie viele Objekte als In-Memory definiert sind. Wichtig bei der Abschätzung ist auch die Kompressionsrate, bei der ein Faktor zwischen drei und zehn möglich ist.

Wie verhalten sich Datenbank-Optionen wie RAC, Verschlüsselung, Data Guard etc. beim Einsatz der In-Memory-Datenbank-Option? Stürner: Eines der Hauptziele bei der Entwicklung der IMDB-Technologie war die tiefe und optimale Integration in das Oracle-Datenbank-Ecosystem. Alle bekannten Funktionen müssen ohne Einschränkungen und völlig transparent funk-

Welche Voraussetzungen müssen erfüllt sein, um die In-Memory-Datenbank-Option zu nutzen? Stürner: Die IMDB-Technologie wird als Option der Enterprise Edition angeboten,

Günther Stürner demonstriert die Skalierbarkeit der In-Memory-Datenbank

DOAG News 02-2014

7

Interview

In-Memory-Option − wie bisher − in den bekannten Oracle-StorageFormaten gehalten. Diese sind die Basis für alle möglichen Varianten des Backups oder eines eventuell notwendigen Recovery. Die In-Memory-Datenbank-Option schränkt die Nutzung und die Prozesse im Bereich „Backup“ in keiner Weise ein. Wichtig ist die Abschätzung der Kompressionsrate

Gibt es Möglichkeiten, die In-Memory-Datenbank-Option wieder rückgängig zu machen?

tionieren. Oracle 12.1.0.2. als Ergebnis ist eine Enterprise-Datenbank mit einer der besten In-Memory-Columnar-Technologien. Es ist keine isolierte und einschränkende Technologie und vor allem kein Balkon, um den in den nächsten Jahren erst das Haus gebaut werden muss. So kann die In-Memory-Datenbank-Option eine RACUmgebung optimal nutzen, indem ein InMemory-Objekt in allen SGAs der entsprechenden RAC-Knoten als Kopie abgelegt ist. Bei sehr großen Objekten kann ein solches Objekt über eine gesamte RAC-Farm verteilt/segmentiert sein. Das ist Scaleout-Architektur vom Feinsten. Auch die Verschlüsselung der Daten mit ASO und In-Memory ist kein Problem, der Einsatz von Data Guard ist mit allen Varianten ohne Einschränkungen möglich. Genauso steht diese Option für alle Oracle-EnterpriseEdition-Plattformen zur Verfügung.

Stürner: Wie bereits erwähnt, können eine Tabelle, Partitionen einer Tabelle, einzelne Spalten einer Tabelle oder eine Materialized View als In-Memory-Objekt definiert sein. Dabei sind die Daten eines solchen Objekts Spalten-orientiert im Hauptspeicher abgelegt, was mit dem Befehl „alter table xyz inmemory“ geschieht. Dies lässt sich jederzeit und ohne Probleme durch den Befehl „alter table xyz no inmemory“ wieder rückgängig machen. Die Spalten-orientierte Repräsentation im Hauptspeicher wird für dieses Objekt unmittelbar gelöscht, während die Daten dieses Objekts weiterhin als Zeilen-Repräsentation im Row-Cache beziehungsweise auf den Platten vorliegen. Es ist keine Konvertierung, kein Umspeichern von Formaten, kein Entladen oder Neuladen erforderlich. Hier tritt das duale Konzept in seiner vollen Schönheit zu Tage.

Wie skalierbar ist eine In-Memory-Datenbank?

Kann eine mit der In-Memory-Option eingerichtete Tabelle auch auf eine Datenbank ohne In-Memory-Option übertragen werden?

Stürner: Eine Oracle-Datenbank mit InMemory-Option hat die gleichen Eigenschaften in Bezug auf Skalierbarkeit wie eine bisherige Oracle-Datenbank. Die Nutzung von mehr CPUs, mehr Hauptspeicher oder mehr Knoten innerhalb einer RAC-Umgebung ist vollständig gegeben. Ich muss mich wiederholen: Die In-Memory-Datenbank-Option ist in das Oracle Ecosystem tief integriert. Was bisher ging, geht auch dann, wenn man mit der In-Memory-Option arbeitet.

Stürner: Kein Problem! Wie gesagt, jedes Objekt, das als In-Memory-Objekt definiert ist, behält seine Zeilen-orientierte Eigenschaften innerhalb der Datenbank und auf den Platten und kann somit mit allen bekannten Möglichkeiten bearbeitet werden. Auch hier gilt, wie bereits mehrfach ausgeführt: Alles, was man heute ohne In-Memory-Option machen kann, ist auch mit dieser Option durchführbar.

Wie sichert man persistente Daten beim Einsatz der In-Memory-Option?

In welche Richtung wird sich die In-Memory-Datenbank-Option weiterentwickeln?

Stürner: Die Daten auf den Speichermedien werden auch bei der Nutzung der

Stürner: Mit Verfügbarkeit der In-MemoryOption im zweiten Halbjahr 2014 werden

8

www.doag.org

wir eine Vielzahl von wichtigen und inte­ ressanten Funktionen bereitstellen. Nicht nur die Speicherung der Daten in Spaltenorientierter Form im Hauptspeicher macht den Unterschied, sondern auch die Algorithmen für die Komprimierung, für die Join- und Gruppierungs-Operationen etc. sind entscheidend für die optimale Verarbeitung. Selbst die Integration dieser Datenstrukturen und Algorithmen mit den Hardware-Systemen und deren spezifischen Fähigkeiten ist bereits weit fortgeschritten, aber bei Weitem noch nicht vollständig ausgereizt. Man kann erwarten, dass dieser ersten Version noch viele weitere Entwicklungs-Iterationen folgen werden.

Steht die In-Memory-Datenbank-Option auch im SAP-Umfeld zur Verfügung? Stürner: Wir arbeiten seit vielen Jahren mit SAP sehr eng und vertrauensvoll zusammen. Bei jeder neuen Datenbank-Version entwickelt ein kleines Team bestehend aus Entwicklern und Verantwortlichen von

Zur Person: Günther Stürner Günther Stürner arbeitet bereits seit September 1985 für Oracle; sein beruflicher Werdegang begann als Sales Consultant Deutschland. Von 1987 bis 1993 widmete er sich dem Aufbau der Abteilung „Strategisch Technische Unterstützung“ (STU) und war anschließend sechs Jahre lang Leiter des Oracle SAP Competence Centers sowie des Oracle SAP Entwicklungszentrums. Er ist heute Vice President Server Technologies und Sales Consulting. Günther Stürner hat mehrere Fachbücher zur Oracle-Datenbank und zu SQL geschrieben sowie zahlreiche Fachartikel veröffentlicht.

Interview

SAP und Oracle einen Plan, welche neuen Funktionen und Technologien in das neue Oracle-Datenbank-Produktpaket für SAP eingebaut werden sollen. Die In-Memory-Datenbank-Option ist für viele SAPKunden sehr interessant und wichtig. Aus diesem Grund ist davon auszugehen, dass die In-Memory-Datenbank-Option unmittelbar nach Verfügbarkeit von Oracle 12.1.0.2 dem Zertifizierungsprozess zugeführt wird. Dass der SAP-Oracle-Kundenkreis sehr an einer Lösung interessiert ist,

die einen signifikanten Schritt hinsichtlich höherer Performance erlaubt, ohne eine bestehende Umgebung vollständig „abreißen“ und neu aufbauen zu müssen − mit all den bekannten technischen und finanziellen Risiken −, zeigen die vielen Gespräche, die wir bisher zu diesem Thema geführt haben.

Wie können DOAG-Mitglieder, die sich für diese Option interessieren, die Technologie intensiv und umfassend erlernen?

Stürner: Wenn die DOAG für ihre Mitglieder ein besonderes Seminar oder einen Workshop über dieses Produkt organisieren möchte, sind wir jederzeit bereit, die notwendigen Schritte einzuleiten. Wir können auch sogenannte „Test-Drives“ durchführen; gerne auch als exklusive DOAG- Veranstaltung. Dieses spannende Thema wird uns die nächsten Jahre auf Trab halten und uns noch viel Freude bereiten.

Finger weg von meinem Telefon! Steffo Weber, ORACLE Deutschland B.V. & Co. KG

Der Grund dafür, dass die meisten Unternehmen eine sehr restriktive Desktop-Richtlinie, aber keine klare Strategie für mobile Geräte haben, ist, dass iPhones, iPads & Co. genau das sind, was PCs niemals waren: persönlich und benutzerfreundlich. Die Standardstrategien im Umgang mit mobilen Geräten (VPN, Verbot mobiler Geräte, MDM etc.) machen diese Geräte unpersönlich oder die Bedienweise unfreundlich. Wesentlich effektiver ist es, nicht das Gerät zu managen, sondern die unternehmensbezogenen Daten und Dienste, auf die zugegriffen wird.

Aktuell konkurrieren verschiedene Ansätze (Mobile Application Management, Mobile Device Management, Containerization/Virtualization, Data Leakage Prevention, Mobile Access Management) zum Schutz von – ja, was denn eigentlich? – mobilen Geräten, mobilen Daten und Diensten für mobile Geräte untereinander. Sie werden hitzig diskutiert. Einer der interessantesten Kommentare hierzu lautet „I just came across another interesting statistic. According to a Juniper survey, the average mobile user owns 3 internet-connected devices. (…). But, and get this, 18% own 5! Can you imagine what it would be like for IT to manage these? To me, it‘s clear that IT should focus on managing THEIR data, and not any device.“ Mobile Geräte sind – und das ist entscheidend – eben nicht lediglich ein neuer

Gerätetyp, sondern benötigen ihre eigene, angepasste Infrastruktur. Sie repräsentieren einen Kulturwechsel, der sich schon seit Jahren vollzieht und zu einer immer stärkeren Ästhetisierung und Individualisierung führt. Dies betrifft auch die lange Zeit ästhetisch entkernten Bereiche wie Ökonomie und Bürowelt: Rein zweckorientierte beige PCs weichen smarten Tablets und die Software-Ergonomie ist Teil dieses Wechsels. Diese Entwicklung verlangt von Unternehmen ein grundsätzliches Umdenken im Hinblick auf folgende Aspekte:

ten von über zwei Sekunden oder ein dreimaliger Absturz einer Anwendung führen bereits dazu, dass der Nutzer die App wieder löscht [1, 2] • Zugriff auf Business-Infrastruktur Die Netz-Infrastruktur der meisten Unternehmen geht davon aus, dass das Unternehmen vollständige Kontrolle (Administratorrechte etc.) über das zugreifende Gerät hat. Das ist bei einem Smartphone nicht der Fall. Das Mantra lautet eben „bring your own device” und nicht „bring our own device”.

Geändertes Nutzerverhalten und neue Nutzeransprüche Nutzer zeigen bei mobilen Anwendungen weniger Bereitschaft, sich in die Tücken einer App einzuarbeiten, als bei Desktop-Anwendungen: Ladezei-

Zwei Dinge sollte man genauer unter die Lupe nehmen: Welche unterschiedlichen Nutzertypen (intern, extern, Partner) greifen auf meine Daten zu und wo müssen die Daten geschützt werden – auf dem mobilen Gerät oder im Data Center?

•

DOAG News 02-2014

9

Mobile

Für Mitarbeiter und Partner: Sichere iOS-/Android-Container Mitarbeiter und Partner verwenden typischerweise Apps (E-Mail, SharePoint etc.), die vom Unternehmen zwar bereitgestellt, aber nicht entwickelt werden. Dies ist ein Unterschied zu den Apps, die ein Unternehmen für Endkunden in Eigenregie entwickelt und hierbei alle SicherheitsFeatures wie Datenverschlüsselung unter Kontrolle hat. Wie kann man also Daten, die von nicht selbst entwickelten Apps verarbeitet werden, so schützen, dass die mobile User Experience weiterhin gewährleistet ist? Wenn der Privatheits-Charakter eines mobilen Geräts (mit dem wir Fotos und Memos aufnehmen, persönliche Nachrichten speichern) gewährleistet werden soll, greifen klassische Mobile-Device-Management-Lösungen (MDM) zu kurz. Sie sorgen lediglich dafür, dass Dritte das Gerät mit einer Managementsoftware verwalten. Hierbei spricht man nicht mehr von „bring your own device” (BYOD), sondern von „company owned, personally enabled“ (COPE). COPE ist aufgrund von rechtlichen Grauzonen wie dem Löschen von persönlichen Fotos beim Geräte-Management umstritten. Eine Container-Lösung, bei der der Nutzer weiterhin voll-

ständige Kontrolle über das Gerät hat, kann ein brauchbarer Kompromiss zwischen dem „Y“ (your device) und den Sicherheitsinteressen eines Unternehmens sein: Die zu schützenden Unternehmensanwendungen (SAP-Clients, SharePointApps, Mail-Client) werden hier in einem isolierten Container installiert. Daten (E-Mails, SharePoint-Dokumente) können diesen Container zumindest nicht unverschlüsselt verlassen. • Eine Fernwartung wie das Löschen von Dokumenten ist problemlos möglich. Auf Daten außerhalb des Containers (wie Fotos, Musik) kann per Fernwartung nicht zugegriffen werden. Daten, die dem Unternehmen gehören und sich im Container befinden, lassen sich also durch das Unternehmen auf Knopfdruck löschen – private Fotos etc. nicht. • Der Netz-Zugriff von Container-Apps erfolgt ausschließlich über die Protokolle Transport Layer Security (TLS) und Secure Sockets Layer (SSL). Der SSL-Endpunkt steht hierbei im Unternehmensnetz. Mit anderen Worten: Sämtliche Kommunikation läuft über ein Unternehmens-VPN (TLS-basiert). •

Kerberos

Personal applications. Safari, Mail, Keynote, Photos.

Abbildung 1 zeigt die Funktionsweise einer Containerlösung (hier am Beispiel von Oracles Secure Container). Die Container-App (roter Block auf dem Smartphone) stellt für Unternehmens-Apps eine gesicherte Umgebung bereit. Die von den Apps auf dem Smartphone abgespeicherten Daten werden verschlüsselt, Copy & Paste in Anwendungen außerhalb des Containers ist nicht möglich. Drucken kann ebenfalls unterbunden werden. Der Container stellt eine Umgebung für Apps zur Verfügung, die sämtliche von der App gespeicherten Daten verschlüsselt • Copy & Paste an Nicht-Container-Apps verhindert (auch nicht mit dem Share Button, über den ein an einer E-Mail hängendes PDF-Dokument an Dropbox weitergeleitet werden kann). An welche anderen Apps-Dokumente weitergeleitet werden kann, lässt sich in der Oracle-Lösung konfigurieren: Dropbox kann verboten, Ignyte beispielsweise erlaubt sein. •

Damit eine App innerhalb des Containers laufen kann und die Mechanismen (Copy/ Paste-Schutz etc.) des Containers wirksam werden, muss die App modifiziert sein. Dies kann automatisch erfolgen, die App

Kerberos DC Oracle Mobile Security Admin Console (LDAP Integration) MS Exchange Server

Tunneled HTTP(S)

SAP Client. Oracle mobile security container.

Mobile Device iOS/Android

Abbildung 1: Funktionsweise einer Containerlösung

10

www.doag.org

Untrusted Network (Internet)

Oracle API Gateway

Oracle Mobile File Mger

Containerized E-Mail client. Browser (inside or outside conatiner).

LDAP (AD or OUD)

HTTPS

Oracle Mobile Access Server

Sharepoint Client.

Corporate DMZ

Web Applications WebSevices REST APIs Legacy Applications

Corporate Network

Oracle Mobile Security Notification Server HTTPS

Mobile

muss hierzu nicht im Quellcode vorliegen. Einzige Voraussetzung ist, dass die App unsigniert ist. Dies bedeutet zunächst, dass die aus dem Apple AppStore oder Google Playstore geladenen Apps nicht im Container lauffähig sind. BusinessApps hingegen (wie SAP Fiori Suite, Oracle Apps) können ohne Probleme eingesetzt werden, da viele Firmen (Colligo, Oracle, Nitrodesk, SAP etc.) ihren Kunden diese Apps unsigniert zur Verfügung stellen. Tabelle 1 zeigt eine Gegenüberstellung von klassischen Mobile-Device-Management- und Container-Lösungen. Der Haupt­ unterschied: Es kann nur eine MDM- auf dem Gerät geben, aber mehrere Container-Lösungen. Mit anderen Worten: MDM ist ein Vendor Lock, Container hingegen nicht. * Hier kann man sich im Produkteinzelfall darüber streiten, ob MDMLösungen auch DLP-Lösungen sind. Ich finde in diesem Zusammenhang folgenden Kommentar (eines DLP-Herstellers) bemerkenswert: „Sixty-plus MDM vendors have hijacked the term “data loss prevention”-DLP- because data loss is a big problem for their customers. Customers want DLP solutions. No matter how often MDM vendors say they are, MDM isn’t DLP”. – Quelle: http://www.spydrsafe.com/why-mobile-device-managementdoesnt-matter/#sthash.l5CBmESi.dpuf Tabelle 2 zeigt die drei Typen von Anwendungen, die unterschieden werden können. Abgesehen von der Frage: „Laufen die für mein Unternehmen wichtigen Anwendungen im Container?”, sind auch allgemeinere Aspekte zu klären, darunter: Kommunikationspfade Ein Container muss die HintergrundDienste (Mail, SharePoint, Fusion Apps, SAP etc.) für die im Container laufenden Apps erreichbar machen. Hierzu wird typischerweise ein verschlüsselter Kanal (IPSEC, TLS/SSL) aufgebaut. Bei manchen Lösungen führt dieser Kanal immer über Cloud Services des Container-Herstellers, was bei der Oracle-Lösung nicht der Fall ist. • Unterstützte Betriebssysteme Fast alle Hersteller unterstützen zurzeit iOS und Android, Windows Phone oder Blackberry haben eher Nischen-Charakter. Wichtig ist, den Enterprise- und •

MDM

Container

Schutz von privaten Daten (Fotos, Kontakte etc.)

N

J

Verschlüsselung von Geschäftsdaten

N

J

unklar

J

Lösung für Mitarbeiter und Kunden geeignet

N

J

App kann aus Apples Appstore oder Playstore übernommen werden

J

N

Digital Leakage Prevention, DLP

N*

J

Es können mehrere Lösungen auf einem Smartphone installiert sein (Vendor Lock)

N

J

Einführung rechtlich unbedenklich in DE

Tabelle 1: Gegenüberstellung von MDM- und Container-Lösungen

nicht den Consumer-Markt zu berücksichtigen. • Einheitliches Identitätsmanagement Kann die Identität des mobilen Nutzers so weit in das Unternehmensnetz propagiert werden, dass ein echtes Single Sign-on (in Windows-Umgebungen per Kerberos oder in Web-Umgebungen per SAML) möglich ist? • Silo-Lösung vs. integriert in die Unternehmensplattform Beherrscht das Produkt einheitliches Enterprise Access Management oder ist es lediglich eine Remote-Access-Lösung?

Access Management sorgt für bessere User Experience, erhöhte Sicherheit und smartes Marketing Die große Änderung, die die mobile Welt mit sich bringt, ist, dass sich der klassische Präsentations-Layer einer „n-Tier“Architektur auf dem Smartphone befindet: Die App ist der Präsentations-Layer. Dies bedeutet, dass Maßnahmen wie Authentisierung das Vertrauensverhältnis

zwischen Smartphone-Präsentations-Layer und Businesslogik (Service Layer) sicherstellen müssen (siehe Abbildung 2). Wird von einem per MDM verwalteten Gerät oder einer Container-App auf einen Dienst zugegriffen, so kann man das Vertrauensverhältnis als hergestellt betrachten. Was aber, wenn beliebige Nutzer − insbesondere solche, denen man keine MDM- oder Container-Lösung vorschreiben kann, − auf die Dienste zugreifen? In diesem Fall muss sich der Nutzer am Dienst authentisieren. Unternehmen geben jedoch nicht nur eine App heraus, sondern oftmals mehrere. Für Mitarbeiter können das Apps wie „Reisekosten“, „Zeiterfassung“ oder „Urlaubsantrag“ sein, für Endkunden eines Zeitschriftenverlags die unterschiedlichen Zeitschriften-Apps. Selbst Baumärkte haben mehrere Apps im Angebot. Um den Nutzer beim Aufruf der verschiedenen Apps nicht immer mit einem Anmelde­ dialog zu konfrontieren, bietet Oracle eine SSO-Lösung für Apps an. Hierbei handelt es sich um ein echtes SSO-Protokoll und

Signiert/Unsigniert

Wo erworben?

Container-fähig

Typische Nutzer

Signiert

Appstore / Play­store

N

Beliebig

Unsigniert

Direkt vom Hersteller

J

Partner, Mitarbeiter

Unsigniert

Eigenentwicklung

J

Partner, Mitarbeiter, Endkunde

Tabelle 2: Klassifikation von Apps

DOAG News 02-2014

11

Mobile

HTML Präsentation

Präsentation

Business Logik

Daten

Business Logik

Daten

Abbildung 2: Geänderte Sicherheitslage gegenüber einer klassischen „3-Tier“-Architektur

nicht nur um das automatische Ausfüllen von Passwortfeldern. Die Vorteile einer SSO-Lösung für Apps sind: Hintergrund-Dienste sind wirksam geschützt Neben der Nutzer-Authentisierung kann auch die Geräte-Integrität (Jailbreak) überprüft werden. Geräte mit Jailbreak dürfen – je nach Richtlinie – nicht auf den Service-Layer (BusinessLogik) zugreifen. Darüber hinaus ist eine Plausibilitätsprüfung beim Zugriff möglich: Erfolgt um 10:00 Uhr ein Zugriff mit Geolokation Hamburg und um 10:20 ein Zugriff aus Rom, so führt das System zusätzliche Sicherheitsabfragen (etwa Mädchenname der Mutter) durch. • Einfache Benutzung, gute User Experience Die Design-Richtlinien von Apple empfehlen, dass Passwort-Abfragen möglichst selten (und möglichst spät) erfolgen. Beim SSO geschieht das nur einmal beim ersten relevanten Service. • Smartes Marketing Der Herausgeber von sicherheitsunkritischen und kostenlos verteilten Apps kann von SSO profitieren: Die Baumarktkette bietet verschiedene Apps an, unter anderem eine App zur Ermittlung verschiedener Farbharmonien (ähnlich zu „kuler.adobe.com“ oder •

12

www.doag.org

WebSSO Access Management (WAM)

Mobile Access Management

iOS built-in Kerberos/mobile VPN

enterprise access management

silo vs. unified Unified Access Management

Abbildung 3: Access Management mit Identity Silos

Mobile

PROMATIS Appliances Prozessoptimierung & Simulation

Datenklasse

Eigner

Schutz von

Mechanismus

Nutzergruppe

Dienst (REST WS)

Mobile Access Management

Beliebig (Kunden, Mitarbeiter) Beliebig (Kunden, Mitarbeiter) Partner & Mitarbeiter

Öffentlich

*

Vertraulich

Smartphone Nutzer

Dienst (REST WS)

Mobile Access Management

Vertraulich

Unternehmen

Dienst & Daten

Container

Oracle Applications

Oracle BI Suite

Usability

Enterprise 2.0

Enterprise Content Management Accelerate-Mittelstandslösungen

Fusion Applications Business Intelligence Applications

Tabelle 3: Klassifikation von mobilen Zugriffen

Managed Services „colourlovers.com“) und eine andere zur Tapetenauswahl. Daten-Korrela­ tionen der Art „Welcher FarbharmonieTyp wählt welche Tapete” können aus Marketingsicht aufschlussreich sein. Der Schlüssel hierfür ist die (anonymisierte) App-übergreifende Nutzer-Identifikation. Die nähere Funktionsweise eines Appund Browser-übergreifenden SSO ist in [3] beschrieben. Single Sign-on bietet also insbesondere bei mobilen Anwendungen neben der reinen Sicherheit auch Vorteile wie bessere User Experience und übergreifende Nutzer-Identifikation, die auch zu Marketingzwecken verwendet werden kann. User Experience und gerichtetes Marketing sind zudem aktuell stärkere Treiber als reine Sicherheitslösungen.

Fazit Nutzer wollen Bequemlichkeit, Unternehmen ihre Daten schützen. Beides ist möglich, wenn man weiß, für welchen Nutzertypus die Lösung angeboten werden soll und wo die zu schützenden Daten liegen. Die architekturelle und produktspezifische Herausforderung wird darin bestehen, die unterschiedlichen Zugriffswege (VPN, Desktop Access, Mobile Access, Mobile Container) so zu vereinheitlichen, dass der Nutzer sich genau mit einer (und nur mit einer) Identität im (internen) Netz bewegt und seine Nutzungsmöglichkeiten größtenteils unabhängig vom verwendeten Gerät oder Kanal sind. Dies erst macht das Verwalten von Zugriffsregeln handhabbar (siehe Abbildung 3). The Register [4] fasst dies in einem Artikel über den Mobile World Congress wie folgt zusammen: „This isn’t just Mobile Device Management (MDM), this is Enterprise Mobility Management (EMM)“.

Falls die üblichen Anmeldungspunkte wie VPN, Active Directory, Web Access Management (inkl. SAML) und App-Authentisierung (inkl. OAuth) die Nutzer-Identität nicht weiterleiten, muss sich der Nutzer mehrfach anmelden. Auch ein einheitliches LDAP-Verzeichnis löst dieses Problem nicht, Identitäten werden nicht propagiert (dazu gehört beispielsweise ein Weiterleiten der Art „Hier ist mein Kerberos-Ticket, bitte gibt mit ein SAML-Token dafür” oder „Hier ist ein SAML-Token, ich benötige ein OAuth Token”. Tabelle 3 grenzt die oben beschriebenen Mechanismen (Container, Mobile Access Management) bei der Verwendung von Services/ Apps voneinander ab.

Referenzen

[1] Mobile Apps. What Consumers really want, offers2.compuware.com/rs/compuware/images/ Mobile_App_Survey_Report.pdf [2] mobilestatistics.com/mobile-news/the-rise-ofthe-enterprise-tablet.aspx [3] Weber, Steffo: Access Management 11g R2 für iOS und Cloud, DOAG News Nr. 1, 2013. [4] http://www.theregister.co.uk/2014/02/24/mobile_world_congress_its_not_about_the_handsets_anymore

Oracle Infrastruktur

Oracle E-Business Suite

Oracle BPM Suite Application Integration Architecture Social BPM

Oracle CRM On Demand

Hier sind wir zuhause Unser Alleinstellungsmerkmal: Intelligente Geschäftsprozesse und beste Oracle Applikations- und Technologiekompetenz aus einer Hand. Als Oracle Pionier und Platinum Partner bieten wir seit fast 20 Jahren erfolgreiche Projektarbeit im gehobenen Mittelstand und in global tätigen Großunternehmen.

Unsere Vorgehensweise orientiert sich an den Geschäftsprozessen unserer Kunden. Nicht Technologieinnovationen sind unser Ziel, sondern Prozess- und Serviceinnovationen, die unseren Kunden den Vorsprung im Markt sichern. Über Jahre gereifte Vorgehensmodelle, leistungsfähige Softwarewerkzeuge und ausgefeilte Best Practice-Lösungen garantieren Wirtschaftlichkeit und effektives Risikomanagement.

Steffo Weber [email protected]

PROMATIS software GmbH Tel.: +49 7243 2179-0 Fax: +49 7243 2179-99 . [email protected] www.promatis.de DOAG News 02-2014 13 Ettlingen/Baden . Hamburg . Berlin

Mobile

Apex-Applikationen für Tablet-Devices Kai Donato, MT AG

Die Grundlage für mobile Applikationen mit Oracle Application Express wurde mit der Version 4.2 implementiert und stellt schon jetzt die nötigen Werkzeuge zur Entwicklung von mobilen Applikationen bereit. Der Artikel zeigt, inwiefern sich diese Werkzeuge für die Entwicklung von Tablet-Applikationen nutzen lassen und beschreibt ein Beispiel aus der Praxis über den Umgang mit diesen Endgeräten, wenn eine Apex-Anwendung darauf laufen sollte.

Zum Erstellen von Apex-Applikationen gibt es seit der Apex-Version 4.2 ein gesondertes Theme, das wiederum für mobile Applikationen angepasste Elemente bereitstellt. Standard-Elemente wie Regions oder Forms-Elemente sind mit dem zugrunde liegenden jQuery-MobileFramework für die Darstellung auf mobilen Endgeräten optimiert. Mit der Auswahl des User Interface „jQuery Smartphone“ (Theme 50) wird die Apex-Entwicklungsumgebung insofern angepasst, als nicht für mobile Endgeräte kompatible „PageItems“ versteckt werden und der Entwickler somit an der Verwendung inkompatibler Elemente gehindert wird. Darüber hinaus sieht das User-Interface vor, eine mobile Applikation visuell so nah wie möglich an native Apps anzupassen, sodass der Anwender die App intuitiv mit der Hand bedienen und sämtliche Inhalte trotz der mangelnden Darstellungsfläche erfassen kann. Hauptbestandteil des genannten Theme ist zum einen der sogenannte „Header“, der sich ganz nach jQuery-Mobile-Methode aus- und einblenden lässt, und zum anderen der „Footer“, der sich ebenfalls vor dem Inhalt befindet und wahlweise aus- beziehungsweise eingeblendet werden kann. Das bereitgestellte Interface „jQuery Mobile Smartphone“ lässt sich bei dem Erstellen einer neuen Applikation auswählen (siehe Abbildung 1). Wie der Name dieses User Interface schon verrät, ist es zur Verwendung für Smartphones vorgesehen – doch wie verhält es sich gegenüber Tablets (siehe Abbildung 2)? Zu erkennen ist das angepasste Layout, aber wie zu erwarten war haben sich die

14

www.doag.org

Elemente der mobilen Website an die Breite des Tablets angepasst und gegenüber dem Smartphone eine ganze Menge Darstellungsfläche in Anspruch genommen. Die Anpassung an die Bildschirmgröße wirkt hierbei eher unvorteilhaft.

Layout Grids Für den Konferenzplaner war es aufgrund der oben genannten Problematik nötig, eine weitere Unterteilung der angezeigten Seite vorzunehmen. Für diesen Zweck ermöglicht Apex dem Entwickler, die Strukturierung seiner Applikation anhand von Regionen und des sogenannten „Grid“ vorzunehmen. Für jedes Element, das angelegt wird, kann bestimmt werden, ob es

eine neue Spalte, eine neue Reihe oder gar ein neues Grid innerhalb des vorhandenen Grid einnehmen soll. Dieses Grid beziehungsweise dessen Verhalten wird von dem zugrunde liegenden Theme vorgeschrieben und beeinflusst die Darstellung der Applikation abhängig von der Bildschirmgröße und der Größe der anzuzeigenden Elemente. An dieser Stelle sei auf das Theme 25 (für das User-Interface „Desktop“) verwiesen, das verschiedene Display-Größen berücksichtigt und sich der Anzeigefläche anpasst (responsive Webdesign). Apex 4.2 greift bei der Erstellung einer mobilen Applikation auf die von jQuery Mobile bereitgestellten Layout-Grids zurück.

Abbildung 1: Auswahl des User Interface beim Erstellen einer neuen Applikation

Mobile

Abbildung 2: Vergleich einer jQuery-Mobile-Applikation auf dem Apple iPad und dem iPhone

Die Definition dieses Grid übernimmt Apex für uns, erstellt das passende UI-Grid und fügt wahlweise Spalten hinzu (siehe Listing 1). Die Breite der einzelnen Spalten wird nach dem Standard von jQuery Mobile prozentual gleichmäßig verteilt. Die individuelle Anpassung des Grid kann nur begrenzt vorgenommen und muss je nach Anwendungsfall per CSS geändert werden. Sobald eine Reihe oder Spalte des Grid manuell festgelegt ist, werden die anderen Spalten/Reihen nicht nach der übrigen Breite skaliert, sondern nach wie vor auf die gesamte Höhe/Breite des Anzeigebereichs. Abhilfe schafft an dieser Stelle nur eine pixelgenaue Vorgabe für jeden Teil des Grid.

rungen für die Tablet-App umsetzen zu können. Der Prototyp besitzt im Grunde genommen drei Teile, die vertikal angeordnet sind (siehe Abbildung 4). Hervorgehoben erkennt man den Header, der die Navigation und die Benachrichtigungen (News) beinhaltet, den Content-Bereich, der im mittleren Bereich

angesiedelt ist, und den Footer, der das Logo der MT AG beinhaltet. Im mittleren Teil befindet sich eine weitere Einteilung in drei Bereiche, die horizontal angeordnet sind (siehe Abbildung 5). Ein sehr wichtiger Bereich des Prototyps ist das personenbezogene Tagesprogramm, das auf der linken Seite angezeigt

Eine Apex-App für Tablets in der Praxis Für einen Veranstalter sollte eine Applikation entwickelt werden, die den Besuchern einer Veranstaltung als Ersatz für ein Booklet dienen soll. Mit den Standard­ elementen konnte nach relativ kurzer Zeit ein Prototyp entwickelt werden, der sämtliche Informationen einer Papierbroschüre auf den Tablets der Besucher anzeigt (siehe Abbildung 3). Aufgrund der genannten Layout-Einschränkungen war es notwendig, einige Änderungen an den Standard-Apex-Elementen vorzunehmen, um die Anforde-

Abbildung 3: Layout des Prototyps für den Veranstaltungsorganisator

DOAG News 02-2014

15

Mobile

Block A Block B Listing 1: Standard-Grid aus zwei Spalten ohne feste Breite

ist. Änderungen im Tagesprogramm werden an dieser Stelle zeitnah angezeigt. Dies spricht deutlich für die Flexibilität, die eine Broschüre in digitaler Form mit sich bringt. In Abbildung 5 ist der zentrale Anzeigebereich hervorgehoben, der in dieser Applikation die Liste der Teilnehmer und die Agenda anzeigt. Am rechten Bildrand ist der Detailbereich, der bei ausgewähltem Datensatz ausgeklappt wird und detaillierte Informationen bereitstellt. Bezogen auf die Abbildung 5 wurde bei diesem Prototyp darauf geachtet, die volle Breite des Tablets auszunutzen und eine unnötige Streckung des Inhalts zu vermeiden.

Umgang mit Pop-ups auf Tablets

Abbildung 4: Einteilung der Applikation in drei vertikal angeordnete Bereiche

Gerade in einer mobilen Applikation ist es häufig sinnvoll, Pop-ups oder modale Dialoge zu verwenden. Auch für diesen Prototyp war es angedacht, Pop-ups zu nutzen, um beispielsweise Benachrichtigungen oder Sicherheitsabfragen hervorgehoben darzustellen. Leider ist es in Apex 4.2.4 noch nicht möglich, eine sinnvolle Implementation vorzunehmen, da Apex dazu neigt, ein Pop-up auf einer neuen Browserseite zu öffnen. Es besteht an dieser Stelle zwar ein minimaler Einfluss auf die Darstellung der geöffneten Seite, jedoch entspricht dies nicht mehr einem Overlay, das dem Benutzer temporär und ohne die aktuelle Seite zu verlassen, angezeigt wird. Übrigens soll Apex 5.0 sogenannte „Modale Dialoge“ nativ unterstützen und damit diese Maßnahme überflüssig machen.

Scrolling auf iOS-Geräten

Abbildung 5: Drei-Spalten-Grid im mittleren Teil der Seite

16

www.doag.org

Da die Applikation von ihrem Aufbau und der Funktion her an eine native App angelehnt ist, war der Autor mit einer Problematik konfrontiert, die die Bedienung des Konferenzplaners beeinträchtig hat. Apple hat in seiner nativen Browser-Engine ein Scrolling eingebaut, um das Scrol­ len über die Grenzen der eigentlichen Website hinaus zu ermöglichen. Wenn man mit dem iOS-Browser zum Ende einer Website scrollt, führt ein weiteres „Wischen“ in die gleiche Richtung dazu, dass der Bereich, in dem die eigentliche Website angezeigt wird, zur Seite geschoben wird und man quasi hinter die Web-

Mobile

site sehen kann. Dies führt dazu, dass die Bedienung von Web-Applikationen mit mehreren scrollbaren Bereichen unangenehm beeinflusst wird. In diesem mobilen Prototyp existiert genau dieses Problem und beeinträchtigt die Usability deutlich. Recherchen haben ergeben, dass man die Möglichkeit hat, das sogenannte „touchOverflow“-Verhalten von Elementen zu verhindern. Dieses vollständig zu deaktivieren, hat jedoch zur Folge, dass jegliche Wischgesten in der Applikation unterbunden sind und somit auch keinerlei Scrolling mehr möglich ist. Es gibt Lösungsansätze, die sich mit dieser Problematik befassen, jedoch sind diese nicht ohne weitere Probleme zu implementieren. Im Grunde funktionieren diese Lösungen, indem sie das Scrollen unterbinden, sobald man das untere beziehungsweise obere Ende des scrollbaren Elements erreicht hat. Da man bei einer mobilen Applikation aber in der Lage ist, auf jeder beliebigen Stelle zu scrollen, ist es notwendig, jedes dargestellte Element einer mobilen Applikation mit gesonderten Regeln (CSS-Klassen) zu versehen. Wird dies manuell vorgenommen, erschwert es die Erweiterung der Applikation und wirkt sich ebenfalls auf die Kompatibilität zu neueren Apex-Versionen aus.

Abbildung 6: Der Themeroller zur Erstellung eigener Stylesheets

te, kann diese ebenfalls in den „Shared Components“ in Apex hinterlegen. Möchte man also JavaScript-Bibliotheken integrieren, kann man diese über das Page-Template in den Kopf der HTML-Seite einbinden und wie gewohnt in der Applikation verwenden. Der Prototyp des Konferenzplaners konnte anhand eines erstellten Theme an die Farbgebung des Kunden angepasst werden.

„Look & Feel“ mittels Theme­ roller anpassen

Fazit

Um die jQuery-Mobile-Applikation nach seinen eigenen Vorstellungen zu gestalten, gibt es ein sehr hilfreiches Tool, das die jQuery-Entwickler ebenfalls kostenlos zur Verfügung gestellt haben. Der Themeroller, den man bequem von der Herstellerseite von jQuery-Mobile erreichen kann, ermöglicht es, für sämtliche Versionen von jQuery-Mobile Themes zu erstellen (siehe Abbildung 6). Das erstellte Theme lässt sich nach der Erstellung benennen und herunterladen. Eine Einbindung in den Apex-Workspace ist über die „Shared Components“ möglich, nachdem man die sich im Stylesheet befindenden Icon-Verknüpfungen auf die der Apex-Umgebung geändert hat. Wer seine Mobile-App mit weiteren JavaScript-Funktionalitäten erweitern möch-

Die Entwicklung des Konferenzplaners im Apex-Umfeld war bereits mit Apex 4.2.4 komfortabel. Wer in seiner Applikation auf Daten aus der Oracle-Datenbank setzt, ist mit den Bordmitteln von Apex gut bedient und in der Lage, selbst in kurzer Zeit gute Ergebnisse zu erzielen. Mit Kenntnissen im Bereich „CSS und jQuery“ kann man über die Grenzen hinaus Features einbinden und seine Applikationen mit erweiterten Funktionalitäten beleben. Sowohl die neue jQuery-Version als auch die Unterstützung von modalen Dia­ logen und Pop-ups ist für die kommende Apex-Version 5.0 angekündigt. Darüber hinaus soll mit der Version 5.1 ein weiteres Mobile Theme gezielt für Tablet-Applikationen kommen, was den Aufwand für das Customizing weiter reduzieren dürfte.

Weiterführende Links

1. Apex Showcase Portal: https://apex.mt-ag.com 2. http://www.oracle-and-apex.com/improve-theapex-mobile-theme-part-4/ 3. http://themeroller.jquerymobile.com 4. http://www.kylejlarson.com/blog/2011/fixed-elements-and-scrolling-divs-in-ios-5 5. Apex 5.0 Early Adopter 1: https://apexea.oracle. com/i/index.html

Kai Donato [email protected]

DOAG News 02-2014

17

Mobile

Energie-Unternehmen nutzt ADF Mobile für Wartungseinsätze Stephan La Rocca, PITSS GmbH

ADF Mobile auf iPads konnte die Qualität der Inspektionen des Energie-Unternehmens Power South in Alabama USA revolutionieren. In einem Zeitraum von weniger als drei Monaten wurden Teile der bestehenden Forms-Applikation unter der Verwendung mobiler Zugriffe restrukturiert und eine innovative, intuitive und performante Applikation auf Basis von Oracle ADF Mobile zur Verfügung gestellt.

Power South Energy Cooperative mit Sitz in Andalusia, Alabama ist ein Energie-Erzeuger und -Lieferant für 20 kommunale und genossenschaftliche Tochterfirmen in Alabama und dem Nordwesten Floridas. Die Inspekteure haben die Aufgabe, Leitungen und Anlagen in regelmäßigen Abständen und akut nach Unwetterschäden zu warten. Im Backoffice existiert dazu eine Forms-basierte Applikation, in der die Ergebnisse aller Inspekteure zusammengefasst werden. Daraus können Maßnahmen abgeleitet, Arbeitsaufträge erstellt und nachfolgend relevante Con­ trolling-Informationen gewonnen werden. Ein Versuch von Power South, Teile dieser Applikation weiterhin basierend auf Oracle Forms mit Windows-mobile Geräten zur Verfügung zu stellen, scheiterte. Schlussendlich erfolgte die Datenerfassung auf Papier, zumal einige Bereiche, in denen sich die Anlagen und Leitungen befanden, keine ausreichende Netzversorgung aufwiesen. Neben der lästigen Aufgabe, die erfassten Berichte dann erneut im Office auf dem Rechner nachzuarbeiten, waren die Berichte in Bezug auf die Führung des Inspekteurs in keiner Weise geeignet. Unterschiedliche Anlagen benötigen unterschiedliche Wartungsarbeiten, die Daten in verschiedenen Werten und Prüfungen erfassen lassen. In Abhängigkeit von den erfassten Informationen sind vielleicht weitere Kenngrößen zu ermitteln. Dieses Wissen erforderte einen hohen Schulungsaufwand und neue Anlagen führten immer wieder zur Aktualisierung aller Berichte.

18

www.doag.org

Lösungsansatz mit ADF Mobile Nach der Veröffentlichung der neuen Version 1.1 von ADF Mobile im Juni des vergangenen Jahres äußerte Power South den Wunsch, die Datenerfassung durch die Inspekteure komplett zu überarbeiten. Neben einer besseren Führung des Anwenders durch den Wartungskatalog sollte die Möglichkeit geschaffen werden, in einem Gerät auch gleichzeitig die GPSDaten des Schadensortes sowie Fotos des Schadens aufnehmen zu können. Die Auflösung des Gerätes und die verfügbaren Features sprachen schnell für die Verwendung eines iPads. Die Geräte wurden mit einem Hardcover und einer speziellen Anti-Blend-Folie ausgestattet, sodass sie für den Außeneinsatz gewappnet waren. Da die Arbeiten in der Regel in hellem Sonnenlicht erfolgen, galt es darüber hinaus, eine leicht bedienbare und kontrastreiche Oberfläche zu erstellen. Ebenfalls musste dafür Sorge getragen werden, dass sowohl eine Online- als auch eine OfflineNutzung der Applikation möglich ist. Mit der Erfüllung dieser Anforderungen wäre es möglich, dass die Inspekteure ihre Wartungsarbeiten ohne weitere Hilfsmittel für die Datenerfassung erledigen könnten. PITSS startete damit, die Datenstrukturen und Oberflächen-Elemente der bestehenden Back-Office-Applikation zu analysieren, und schlug daraufhin in verschiedenen Mockups mögliche Szenarien für eine Benutzerführung vor. Schritt für Schritt wurden diese Wireframes mit dem Kunden abgestimmt, bis schließlich für die Inspekteure

eine optimale Führung und Nutzung durch den Wartungskatalog zur Verfügung stand. Sicherlich ist die User-Experience bei Tablets gezeichnet von den vielen Apps, die die Anwender im privaten Umfeld bereits auf mobilen Endgeräten nutzen, aber auch der effiziente Umgang mit lesenden und schreibenden Daten und die Ausnutzung der zur Verfügung stehenden Auflösung und der Device-Funktionalitäten führt zu dem, was Oracle in der Projektvorgehensweise der SoftwareEntwicklung neuerdings gerne mit dem Schlagwort „Mobile First“ bezeichnet. Die Architektur und die Prozessabläufe sind optimiert für mobile Verfügbarkeit. Das führte, wie Sie später lesen können, dazu, dass auch andere Bereiche der Forms-Applikation nach dem Muster der mobilen Applikation „reenginiert“ wurden. Die Wireframes wurden mit dem Tool WireframePro des Anbieters MockFlow (siehe „http://mockflow.com/apps/wireframepro“) erstellt. Damit konnten die Szenarien sehr leicht als HTML5-Dateien exportiert und so offline besprochen werden. Spezielle Templates für eine TabletImplementierung erleichtern den Start und erlauben, sich auf den eigentlichen Entwurf der Anwendung zu konzentrieren (siehe Abbildung 1).

Wahl der Architektur Parallel zur Entwicklung des UI galt es, eine performante und tragfähige Architektur für die Mobile-Applikation im Zusammenspiel mit der Oracle-Forms-Anwendung zu

Mobile

Abbildung 1: Mockup der Applikation mit WireframePro

kreieren. Da das Einsatzgebiet der Anwendung weitere Bereiche des Bundesstaats Alabama umschloss, war nicht immer sichergestellt, dass eine ausreichende Netzverbindung zur Verfügung stand. Die Architektur musste so gewählt werden, dass die Anwendung auch offline genutzt werden konnte. Dazu bietet das ADF-MobileFramework die Verwendung einer Embedded SQLite-Datenbank an. Abbildung 2 zeigt den Aufbau der als optimal eingestuften Architektur. Zunächst wurden alle notwendigen Tabellen des bereits für die Forms-Applikation bestehenden Datenmodells in ein ADFModel-Projekt überführt. Analog zu einer normalen ADF-Web-Applikation beinhaltete das Projekt alle relevanten Entity- und View-Objekte. Statt eines View-ControllerProjekts wurden jedoch anschließend darauf SOAP Services exponiert. Da der WebLogic-Server bereits vorhanden war, um die Forms-Applikation bereitzuhalten, wurden die SOAP Services auf dem WLS zur Verfügung gestellt. Aus Sicht des iPads war der WebLogicServer im VPN-Netzwerk des Kunden zu erreichen. Dazu lässt sich ein gängiger VPN-Client aus dem App-Store nutzen. Der Zugriff von ADF Mobile auf die DeviceServices des iPads konnte innerhalb der Applikationen zu jedem Zeitpunkt feststel-

len, ob ein Online-Zugriff auf den Web­ Logic-Server möglich war. In diesem Fall war ein Hintergrundprozess dazu eingerichtet, alle aktuellen Daten über die Webservices in die SQLite-Datenbank zu überführen.

Innerhalb des Projekts bot es sich allerdings an, zwei verschiedene Synchronisationsmechanismen zu ermöglichen. Für den aktuellen Arbeitsauftrag des Tages war es hilfreich, die SQLite-Datenbank nur mit den Daten zu befüllen, die für die bevorstehenden Aufgaben notwendig waren. Es fand ein kompletter Synchronisationsprozess statt, der die lokale Datenbank entleerte und mit den aktuellen Daten befüllte. Der Inspekteur konnte somit zurückliegende Ergebnisse der Wartungsarbeiten von Anlagen, die er an diesem Tag warten wollte, vor Ort einsehen und mit den aktuellen Daten vergleichen. Sollte zwischenzeitlich die Notwendigkeit bestehen, geänderte Daten auf den Server zu übertragen oder aktuelle Daten auf das iPad zu überführen, gab es einen „leichten“ Synchronisationsprozess, der nur die geänderten Daten überführt. Die Auswahl der Synchronisation wurde dem Anwender in der Applikation angeboten. Der Use Case, der gekennzeichnet war durch eine strikte Aufteilung der Anlagen auf die verschiedenen Inspekteure an einem Tag und die Tatsache, dass durch die Wartungsarbeiten in der Regel nur neue

Abbildung 2: Die Architektur

DOAG News 02-2014

19

Mobile

Daten erfasst wurden, erlaubte weitestgehend, auf eine Konfliktbehandlung bei der Synchronisation zu verzichten. Der Fall, dass offline an zwei unterschiedlichen mobilen Endgeräten der gleiche Datensatz geändert wurde oder dass diese Daten zwischenzeitlich auf dem Server verändert wurden, konnte durch die Modellierung des Prozesses ausgeschlossen werden. Dennoch wurden die Daten des mobilen Endgerätes zunächst ungesehen in eine „App2Sync“-Tabelle geschrieben, um die gesamte Logik der Synchronisation und somit der potenziellen Konfliktbehandlung in PL/SQL auf dem Server implementieren zu können. Aus Sicht des Endgerätes galt es, nur die Daten mit den neuesten Timestamps zurück auf den Server zu schreiben. Für die Synchronisation vom Server auf das iPad galt zu berücksichtigen, dass neben den Tabellen, in denen die Berichtsdaten erfasst wurden, auch Tabellen für die Konfiguration der Applikation eingeschlossen werden mussten. Bei der Erfassung neuer Anlagen, der Definition weiterer Prüfungen oder bei Änderungen an der Einstufung der Schwellwerte waren diese

Daten betroffen. Für den Anwender war es aus der Sicht der Applikation ein Synchronisationsprozess, den er startete, allerdings waren insgesamt im Hintergrund fünf unterschiedliche Prozesse aktiv: • • •

• •

Neue Wartungsdaten vom iPad auf den Server übertragen Neue Arbeitsaufträge vom Server an das iPad weitergeben Vorhandene Daten zu den Anlagen aus den Arbeitsaufträgen vom Server an das iPad senden App2Sync-Tabellen in die Produktion überführen Konfigurationsdaten auf das iPad überführen

Die Reihenfolge und die Abhängigkeiten innerhalb dieser Prozesse wurden auf dem Server orchestriert.

Implementierungs-Entschei­dungen Neben den Entscheidungen, welche Architektur zum Einsatz kommen sollte und wie mit den Komponenten aus SOAP Webservices, ADF Mobile und SQLite-Datenbank umzugehen ist, boten sich in dem Projekt

Abbildung 3: Screen für den Inspekteur aus der fertigen Applikation

20 www.doag.org

weitere Implementierungsentscheidungen an. Die Zugriffe auf die Webservices und die Überführung der Daten in die lokale, verschlüsselte Datenbank erfolgten mit den zur Verfügung gestellten AdfmfJava­ Utilities. Mit dem so erstellten Interface war es für den UI-Entwickler möglich, beim Design der AMX-Page-Views auf Java-Backing­ Beans-Data-Controls zuzugreifen. Es wurden eigene Framework-Extensions etabliert, die nach und nach die Möglichkeit schaffen, eigene Funktionalitäten in das StandardVerhalten von ADF Mobile zu etablieren. Der Aufbau des umzusetzenden Use Case erforderte, dass in Abhängigkeit von den Antworten der Inspekteure oder den zu wartenden Anlagenelementen sehr dynamisch verschiedene Page-Elemente auf dem iPad darzustellen sind. Diese Informationen werden in der Regel in Stammdaten zu den Anlagen und den zu prüfenden Werten erfasst. PITSS entwickelte dabei eine sehr innovative Lösung, die es erlaubt, sehr dynamisch Komponenten auf der Seite anzuzeigen. Das betrifft sowohl die Nutzung der diversen List-Elemente als auch weitere Controls auf der AMX-Page. Kontextsensitiv können diese ein- oder ausgeblendet und mit verschiedenen Properties versehen werden. Damit ist der Kunde in der Lage, neue Anlagen mit neuen Prüfverfahren und Werten einzupflegen, ohne dass Anpassungen in der Oberfläche notwendig werden. Außerdem galt es, sich Gedanken über den Umgang mit den Fotos zu machen. Die Inspekteure hatten die Möglichkeit, bei den Wartungsarbeiten vor Ort im Falle eines Schadens direkt ein Foto von dem Schaden zu erfassen. Damit konnte eine völlig neue Qualität in die Erfassung der Wartungsarbeiten eingeführt werden. Die Aufgabenstellung bestand allerdings darin, bei der mobilen Applikation die Größe des Fotos adäquat berücksichtigen zu können. Mit der hochauflösenden Kamera des iPads entstanden so Bilder in der Größe mehrerer MBs. Werden sie als Dateien verwaltet, ist die Synchronisation mit den Serverdaten recht aufwändig, werden sie hingegen als Base64-String konvertiert, ist die Anzeige auf dem iPad sehr rechenintensiv. Um dieses Problem zu umgehen, entwickelte die PITSS GmbH eine eigene Photo­ Util-Klasse, die zunächst das normale ADF-

Mobile

Mobile-PhoneGap-Gateway nutzte, um auf die Foto-Services des Endgeräts zugreifen zu können. Die lokal erstellten Bild-Dateien wurden vor der Synchronisation mit dem Server in ein Base64-String transferiert und so über den Webservice übermittelt. Fotos, die im Synchronisationsprozess vom Server auf das mobile Endgerät übertragen wurden, konnten mit dieser Java-Klasse aus dem Base64-String zurück in eine lokale Datei konvertiert werden. Somit vereint die Implementierung die Vorteile beider Varianten – die performante Anzeige eines Bildes aus einer lokalen Datei und den Verzicht auf die Synchronisation eines Bild-Attachments. In einem Zeitraum von ca. acht Wochen für die Implementierung und den Architekturaufbau entstand so mit insgesamt sechs Entwicklern eine Applikation, die maßgebend für die weiteren Prozesse bei Power South als Vorlage diente (siehe Abbildung 3).

Verbesserungen im Prozess Neben der Möglichkeit, Bilder von den Schäden zu erfassen, gibt es durch die Ver-

wendung der Device-Services weitere Verbesserungen im Prozess, die aufgrund der zuvor eingesetzten Technologie gar nicht möglich waren. So ist der Inspekteur bei der Erfassung seines Schadens in der Lage, gleichzeitig die GPS-Koordinaten über das iPad zu erfassen. Diese Informationen sind in ADF Mobile durch das Phone­ Gap-Interface direkt aus dem Java-Code von ADF Mobile verfügbar. GPS-Koordinaten können ausgelesen und zum aktuellen Schadensdatensatz gespeichert werden. Am Ende entstand eine Softwarelösung für den Kunden, die die Arbeit der Inspekteure bei den Wartungsarbeiten der Anlagen revolutionierte. In einem Zitat des ITLeiters des Kunden heißt es von Kenneth Jones, Power South Business Applications Supervisor: „Leveraging Oracle ADF Mobile, we were able to transition our employees to use new mobile devices (iOS) leveraging the latest device capabilities and allowing for offline work.“ Ergänzend dazu PITSS-Projektleiter Ross Smith: „The mobile application interface is so intuiti-

ve that our users don’t need any training. Thanks go to Oracle ADF Mobile’s great components, which let us quickly turn our design plans into reality.” Der Kunde ist bereits jetzt in der Planung, weitere Komponenten der OracleForms- Applikation zu extrahieren und über Mobile Devices zur Verfügung zu stellen. Eine Präsentation der Applikation ist auf YouTube zu sehen.

Stephan La Rocca [email protected]

Kompetent – Unabhängig – Erfolgsbasiert

OrACle-SOftwAre iSt jeden Cent wert! Unsere Mandanten zahlen trotzdem weniger. Sprechen Sie mit uns! Wir sind nur unseren Mandanten verpflichtet.

> Compliance sichern > Audit vermeiden > Kosten senken

ProLicense GmbH Friedrichstraße 191 | 10117 Berlin Tel: +49 (0)30 60 98 19 230 | www.prolicense.com

DOAG News 02-2014

21

Mobile

Neue Oracle Product Suites für mobile Anwendungen Dr. Jürgen Menge, ORACLE Deutschland B.V. & Co. KG

Seit Anfang des Jahres bietet Oracle einige neue Produkte an, die das Thema „Mobile Anwendungen“ adressieren. Dabei handelt es sich sowohl um bereits bekannte Produkte, die zu neuen Suites wie der Oracle Mobile Suite zusammengefasst wurden, als auch um neue, die aus jüngsten Aquisitionen (Bitzer Mobile) stammen oder von Oracle als OEM-Produkte vertrieben werden. Die neuen Product Suites fallen in die Kategorien „Backend- Integration“ und „Identity Management“.

Die neue Oracle Mobile Suite besteht aus folgenden Komponenten: Oracle Service Bus Applikations-Adapter (Oracle-Applikationen, SAP etc.) • Technologie-Adapter (Datenbanken, Files, Messaging etc.) • •

Die Lizenzierung erfolgt auf CPU-Basis und setzt die Lizenzierung der WebLogic Suite sowie der Mobile Client Runtime (siehe unten) voraus. Die Mobile Suite ist für Kunden gedacht, die Unternehmensapplikationen und Services der IT mobil zur Verfügung stellen wollen, und repräsentiert den Server-seitigen Teil der Architektur. Weitere Produkte wie das API Gateway werden für einen mobilen Einsatz empfohlen, sind aber nicht in der Suite enthalten. Für die Entwicklung mobiler Clients kann das Oracle Application Development Framework Mobile (ADF Mobile) eingesetzt werden. Es ermöglicht die Entwicklung hybrider Applikationen, die auf mobilen Endgeräten mit iOS und Android lauffähig sind. Die Benutzeroberfläche basiert auf HTML5, die Geschäftslogik lässt sich in Java implementieren. Die Lizenzierung von Oracle ADF Mobile ist in den folgenden zwei Varianten möglich: •

Mobile Client Runtime Kann sowohl auf Basis der Benutzer (Inhouse) als auch auf Basis der entwickelten Applikationen (extern) lizen-

22

www.doag.org

•

ziert werden und setzt die Lizenzierung der Oracle Mobile Suite voraus.

wird sie auch in Zukunft den Marktgegebenheiten anpassen.

Application Development Framework Mobile (ADF Mobile) Kann unabhängig von der Oracle Mobile Suite, also mit beliebigen Middleware-Komponenten von Oracle oder anderer Hersteller eingesetzt werden. Eine Lizenzierung ist ebenfalls auf Basis der Benutzer oder der entwickelten Applikationen möglich.

Identity Management Products Die neue Mobile Security Suite besteht aus folgenden Komponenten: • • • • • •

Abbildung 1 zeigt mögliche Kombinationen von Oracle-Produkten und Komponenten anderer Hersteller. Mit dieser neuen Produktlinie adressiert Oracle die steigenden Anforderungen im Bereich „Mobility“ und

Abbildung 1: Kombination der Produkte

•

Mobile Security Container Mobile Security Application Wrapping Tool Mobile Access Server Mobile Security File Manager Mobile Security Notification Server Mobile Security Administrative Console Oracle Access Management Suite Plus (Restricted Use)

Die Lizenzierung ist auf Basis der internen (Employee) oder der externen Benutzer

Mobile

(Non-Employee) möglich. Die Mobile Security Suite ist neben weiteren Produkten auch in der Enterprise Identity Services Suite enthalten, die auf Basis von CPU oder von Benutzern lizenziert werden kann. Anstelle eines Geräte-zentrischen Ansatzes, der von den Benutzern getrennte Geräte für den beruflichen und privaten Einsatz erfordern würde, wählt Oracle im Bereich der Absicherung einen Applikations-zentrischen Ansatz. Die Apps für den beruflichen Einsatz werden in einem separaten Container auf dem Gerät verwaltet, der sich über einen abgesicherten Tunnel mit dem Backend im Unternehmen verbindet. Die notwendige Technologie wurde mit der Akquisition von Bitzer Mobile erworben. Der Secure Mobile Mail Manager wird als OEM-Produkt (Nitrodesk) separat angeboten und sichert die Vertraulichkeit von Mails ab, die über mobile Endgeräte gelesen werden. Die Lizenzierung der Mobile Security Suite wird vorausgesetzt.

Externe Links Oracle Mobile (OTN): http://www.oracle.com/us/corporate/features/mobile/index.html

Oracle ADF Mobile (OTN): http://www.oracle.com/technetwork/developer-tools/adf-mobile/overview/index.html Oracle Identity Management (OTN): http://www.oracle.com/technetwork/ middleware/id-mgmt/overview/index.html Introduction in ADF Mobile: http://www.youtube.com/ watch?v=kn6HZaYxBCM

Mobile Demo Applications Download: https://stbeehive.oracle.com/content/ dav/st/Tools%20PM%20Team/Public%20 Documents/SalesKit#sl Internes FAQ: https://stbeehive.oracle.com/content/ dav/st/Mobile%20Suite%20-%20On%20 premise/Public%20Documents/FAQ%20 for%20Field%20Orgs-ADF%20Mobile%20 SKU.pdf

Tutorial ADF Mobile: http://docs.oracle.com/cd/E18941_01/tutorials/buildmobileappscontent/adfmobiletutorial_1.html

Interne Links ADF Mobile Field Readiness & Sales Kit: http://aseng-wiki.us.oracle.com/asengwiki/display/ASDevJDeveloper/ADF+Mobile+ Field+Readiness+and+Sales+Kit Folien: https://stbeehive.oracle.com/content/ dav/st/Tools%20PM%20Team/Public%20 Documents/SalesKit#sl

Dr. Jürgen Menge [email protected]

Oracle bittet Anwender für Replikationswerkzeuge erneut zur Kasse Seit Erscheinen der Datenbank 12c besitzen die zwei Replikationslösungen „Streams“ und „Advanced Replication“ den Status „deprecated“. Das bedeutet, dass Oracle deren Weiterentwicklung eingestellt hat und sie nur noch mit dem eingefrorenen Funktionsumfang der Version 11g R2 ausliefert. Obwohl Oracle die Replikationslösungen offiziell noch nicht abgekündigt hat, ist man sich einig, dass es nur eine Frage der Zeit ist, bis die nächste und letzte Stufe („desupported“) ausgesprochen wird und die beiden Lösungen von der Oracle-Landkarte verschwinden. Der Hersteller hat bereits im November 2012 in einem Statement of Direction zu GoldenGate darauf aufmerksam gemacht, dass Streams und Advanced Replication neue Features und Erweiterungen

sowie neue Datenformate der DatenbankVersion 12c nicht mehr unterstützen. Der Premier Support für die Datenbank 11g R2 endet im Januar 2015, der Extended Support im Januar 2018. Als Ersatz für die beiden Replikationslösungen sieht Oracle den Einsatz von GoldenGate vor, ein Produkt, das deutlich mehr kann, aber im Gegensatz zu den Vorgängern auch extra Lizenzkosten erfordert – und zwar nicht wenig: Laut Listenpreis 17.500 US-Dollar pro Prozessor plus 3.850 Dollar für Updates und Support in einer homogenen OracleUmgebung. Wer die beiden Replikationslösungen über die Datenbank-Edition schon einmal bezahlt hat, wird also jetzt noch mal zur Kasse gebeten. Viele Anwender würden sofort nach GoldenGate migrieren, sofern

Oracle eine abgespeckte, kostenfreie Version des Werkzeugs anbietet. Über die Konsequenzen einer abzusehenden Abkündigung von Streams und Advanced Replication im deutschsprachigen Raum soll eine anonyme Online-Umfrage Klarheit schaffen. Zum ersten Mal beteiligen sich neben der DOAG auch die Schweizerische (SOUG) und die Österreichische (AOUG) Anwendergruppe. Anhand der Ergebnisse hoffen die Interessensvertreter, im Gespräch mit dem Hersteller eine kundenfreundliche Lösung erzielen zu können. Insofern sind diese auf eine rege Teilnahme der Anwender angewiesen. Hier geht es zur Umfrage: http://www.doag.org/ index.php?id=1673

DOAG News 02-2014

23

Internet der Dinge

Internet der Dinge als Treiber für Integrationsprojekte und Mobile Mario Herb, esentri AG

Das Internet of Things (IoT) wird in Zukunft alles durch an das Internet angeschlossene Sensoren verbinden: Kühlschränke, Waschmaschinen, Autos, Schuhe, Blutdruckmesser, Menschen. Es entstehen neue Geschäftsmodelle, neue Herausforderungen für Unternehmen kommen damit auf. Fehlende Standards machen es schwierig, alle diese Datenquellen miteinander zu integrieren, darauf basierende Geschäftsprozesse auszulösen und mobil anzubieten. Ein Durchbruch für IoT kann demnach nur gelingen, wenn die richtige Integrationsstrategie vorliegt.

Möglicherweise haben wir bereits das Gefühl, in einer vernetzten Welt zu leben. Die Allgegenwärtigkeit von Smartphones und Tablets führt dazu, dass die Menschen ständigen Zugriff auf Technologien haben und mit nur einem Klick auf ihrem Mobilgerät nahezu jede beliebige Aktion ausführen können. Tatsächlich aber leben wir noch nicht annähernd in einer tatsächlich vernetzten Welt. Die nächste Welle der Vernetzung ist gerade dabei, in unseren Alltag zu schwappen. Mit dem Internet der Dinge erhalten nun auch Alltagsgegenstände Einzug in die vernetzte Welt. Möglich machen dies Sensoren, die entweder direkt oder über Datenaggregierende Gateways ihre Messwerte (etwa aktuelle Temperatur) oder das Eintreten eines Ereignisses (etwa TemperaturÜberschreitung) über das Internet melden können. Dabei kann ein Ziel sein, direkt weitere technische Devices im Rahmen der „Machine2Machine“-Kommunikation (M2M) zu informieren oder aber auch Daten zentral in eine IoT-Infrastruktur-Plattform zur weiteren Verarbeitung zu schicken. In der Infrastruktur-Plattform können Rohdaten der Devices analysiert und aufbereitet werden, um im nächsten Schritt konkrete Aktionen abzuleiten. Dabei besteht die Möglichkeit, die Daten im Rahmen der Infrastruktur auch für weitere Auswertungen zu speichern (Big Data) und somit ein umfangreiches Reporting oder auch Vorhersagen (Predictions) zu ermög-

24 www.doag.org

lichen. Gleichzeitig kann die Infrastruktur durch intelligente Middleware-Komponenten relevante Daten und Ereignisse identifizieren, auf deren Basis Unternehmen völlig neue Geschäftsmodelle und (automatisierte) Dienstleistungen entwickeln können. Mögliche Anwendungsfälle betreffen dabei sowohl den B2B- als auch den B2C-Bereich. Unter einer B2BBetrachtung liegt ein Schwerpunkt auf der Anbindung von Informationen aus Fahrzeugen, Maschinen und weiteren Betriebsmitteln. Der B2C-Sektor bietet fast unbegrenzt Anwendungsfälle, in denen Geräte, Kunden und Anbieter von Dienstleistungen in einer neuen Qualität miteinander vernetzt werden. Dabei können auch bereits vorhandene On-Premise- oder in der Cloud verfügbare Applikationen prozessual eingebunden und somit ein enormer Mehrwert erzeugt werden.

Herausforderungen in der Praxis In der Theorie klingt das alles recht simpel, tatsächlich sind aber verschiedenste Herausforderungen im Rahmen solcher Integrationsszenarien zu lösen. Derzeit sind vor allem folgende Punkte als Komplexitätstreiber zu sehen, die auch den Aufbau einer geeigneten Infrastruktur erschweren. •

Standards Im Kontext von IoT-Anwendungen und gerade bei der Anbindung von Ma-

schinen oder Sensoren werden oft proprietäre Sprachen und Protokolle verwendet, die in bestehende Anwendungslandschaften zu integrieren sind. • Patterns, Fast Data und Data Compression Durch die Auswertung von Sensordaten, Steuergeräten und maschinenspezifischen Bus-Systemen entsteht eine Vielzahl an Nachrichten, die in der mobilen Nutzung über den Flaschenhals mobiler Netze transportiert und im Anschluss nahezu in Echtzeit analysiert werden müssen. • Sicherheit Durch den Zugriff einer Vielzahl von Geräten unterschiedlichster Gattungen muss eine zentrale Security sichergestellt werden, die auf der einen Seite ein schnelles und unkompliziertes Onboarding neuer Services und Data Supplier ermöglicht, andererseits aber auch eine zentrale Verwaltung der Identitäten und Rollen bietet sowie im mobilen Kontext auch Themen wie die Unterstützung unterschiedlicher Security- und Authentifizierungsstufen ermöglicht. Um diese Herausforderungen zu lösen, bedarf es einer leistungsfähigen und flexiblen Integrations-Plattform. Eine Plattform, die diese Bedürfnisse erfüllt, stellt standardisierte Prozesse zur Verfügung, die unabhängig von den angeschlossenen Devices ausgeführt werden können.

Internet der Dinge

Abbildung 1: Bestandteile einer IoT-Infrastruktur mit zentralem Event-Processing

Zur Anbindung bietet sie Adaptoren an, die die Vielzahl der angeschlossenen proprietären Systeme in eine einheitliche, interne Nachrichtenverarbeitung überführt. Wie im Folgenden aufgezeigt wird, kann eine solche Integrationsplattform bereits heute problemlos auf Basis der Oracle Middleware und Infrastruktur-Komponenten (wie Oracle WebLogic, Coherence und Exa*-Systeme) aufgebaut werden (siehe Abbildung 1). Beim Aufbau einer Plattform, die gezielt auf die Auswertung und Verarbeitung von Machine2Machine-Kommunikation (M2M) ausgelegt ist, sind grundsätzlich zwei Schichten zu unterscheiden: In der externen Sicht betrachtet man die Architektur der Geräte selbst und vor allem deren Anbindung über ein – teilweise bereits im Gerät selbst integriertes – Gateway. Hinter der Firewall bildet ein zentrales Device und Identity Management die Bereiche des Zugangs- und Identitätsmanagements für alle Benutzer und Geräte ab, bevor eine zentrale Weiterleitung und Verarbeitung der Daten über einen zentralen Service-Bus initiiert wird.

Der Oracle-Service-Bus als Drehscheibe Eine zentrale Rolle bei der Integration spielt der Oracle-Service-Bus, mit dem sich IoT-Services virtualisieren lassen. Dadurch wird eine Entkopplung der Daten von den zugehörigen Konsumenten erreicht. Gleichzeitig ist es mit dem ServiceBus möglich, zwischen den unterschiedlichsten Protokollen und Formaten Daten hin und her zu konvertieren, sodass alle angeschlossenen Systeme und Applikationen die Daten weiterverarbeiten können. Der Service-Bus profitiert dabei von Daten aus bereits integrierten CachingMechanismen und skaliert auch bei sehr großen Datenmengen. Wann immer jedoch mit Datenströmen gearbeitet werden muss, ist der Einsatz von Oracle Event Processing zu empfehlen, mit dem Muster in Daten nahezu in Echtzeit ausgewertet werden können. Ein Beispiel aus der Praxis stellt die Analyse von Daten aus Steuergeräten in PKWs dar, die pro Sekunde eine Vielzahl an Events und Messages generieren. Die anfallenden Nachrichten können zum

Zweck der Erprobung neuer Fahrzeuge oder ganzer Flotten in Echtzeit über normale Mobilfunkverbindungen in Richtung einer zentralen Auswertungsplattform übertragen werden. Gerade in der Entwicklungsphase ist es jedoch nicht möglich, vordefinierte Nachrichten-Kombinationen in bekannte Prozesse zu überführen, die auf Basis von Business Rules weitere Aktionen auslösen. Vielmehr gilt es, auf Grundlage von Mustern aus einer Vielzahl auflaufender Events die wirklich relevanten Nachrichten zu erkennen und diese in Form von Real-Time-Analytics auszugeben oder weiterzuverarbeiten. Diese Herausforderung kann durch die Kombination des Event-Processing der Oracle SOA Suite und einem Exalogic-Node bewältigt werden, da in Summe rund eine Million Events pro Sekunde verarbeitet und analysiert werden können. So ist es möglich, irrelevante Daten auszufiltern (etwa Werte ohne Veränderungen) und nur die wirklich relevanten Ereignisse im Rahmen von Integrationsszenarien zu verarbeiten (Fast Data). Dabei können als Ergebnis Events ausgelöst oder Service-

DOAG News 02-2014

25

Internet der Dinge

Aufrufe realisiert werden. Durch den Einsatz von SOA-Konzepten ist die technische Architektur lose gekoppelt und erlaubt größtmögliche Flexibilität bei der Reaktion auf die Ereignisse. Denkbar ist beispielsweise, dass auf Basis der Oracle SOA und BPM Suite Prozesse ausgeführt werden, deren Stimulator die Daten aus den vernetzten Geräten sind. So lassen sich EnterpriseApplikationen wie ERP-Systeme genauso integrieren wie individuelle BPMN- oder BPEL-Prozesse, mit denen ganz neue Geschäftskonzepte umsetzbar sind. Vor allem die proaktive Unterstützung von Wartungsprozessen wird mithilfe dieser Methoden bereits heute umgesetzt. Dabei dienen die Nachrichten von Sensoren, die über standardisierte Schnittstellen in eine SOA-Umgebung einfließen, als Auslöser von Geschäftsprozessen. Im ersten Schritt werden die vorher definierten und als relevant eingestuften Nachrichten durch den Einsatz von Business Rules weiter klassifiziert. Diese sind, je nach einer durch die Regeln ermittelten Kritikalität der Nachrichten, Auslöser für dedizierte Wartungsprozesse, die nicht mehr nach starren Regeln wie Betriebsstunden definiert sind, sondern auf Basis der tatsächlichen Daten aus den Geräten dynamisch angestoßen werden.

Durch den Einsatz der Oracle Fusion Middleware als zentrale IntegrationsPlattform ist es darüber hinaus möglich, auch das Identity Management zwischen den Devices und den zu integrierenden Applikationen und Services zu zentralisieren. Oracle hat dazu in den letzten Monaten die Funktionen der Identity-Management-Produkte um wichtige Bestandteile aus dem Bereich der Anbindung mobiler und/oder dezentraler Devices erweitert und kann neben den klassischen Funktionen zum Access und Identity Management auch die Anbindung mobiler Geräte sicherstellen. Durch die nahtlose Integration in die Fusion Middleware können somit seit Kurzem auch Bereiche wie Mobile Application Management und die Absicherung der Verbindung zwischen mobiler Anwendung und dem Backend in einer zentralen Umgebung als Ergänzung der klassischen Identity-Management-Funktionen für Architekturen berücksichtigt werden. Mit Produkten wie dem Oracle-APIGateway ist es zudem möglich, veröffentlichte Services aus dem Unternehmen auch für Cloud-Anwendungen oder andere Devices sicher im Internet anzubieten. Zum Einsatz dieser Szenarien kommen dabei häufig RESTful-Services, deren

Abbildung 2: Typische Schichten einer IoT-Plattform mit möglichen Anwendungsszenarien

26 www.doag.org

Datenstruktur schlank ist und die sich als Standard etabliert haben. Dies ist vor allem für die Anzeige von Informationen beim Endanwender interessant, da IoTKonzepte vorwiegend auf Datenebene eine Rolle spielen und die Visualisierung über bisherige Technologien realisiert werden kann (siehe Abbildung 2).

Mobile first − Daten in Informationen umwandeln Was im Kontext von IoT oft nur am Rande berücksichtigt wird, aber für die Anwendung in Business-Szenarien als elementar zu betrachten ist: Wie werden die gewonnenen Informationen, Analysen, Ergebnisse und die daraus folgenden Prozesse visualisiert und durch die Anwender genutzt? Hier hat in vielen Unternehmen zwischenzeitlich ein Umdenken stattgefunden hin zu einem „Mobile first“-Ansatz, da viele Prozesse effektiver mit einer mobilen Unterstützung abgewickelt werden können. Dabei geht es weniger um die Auswertungen und Analysen, die im Management auch auf dem iPad zur Verfügung stehen, als vielmehr um Geschäftsprozesse, die nur durch den Einsatz mobiler Devices überhaupt praktikabel werden. Die beste Plattform zur Auswertung einer Vielzahl von Daten kann nur dann einen wirklichen

Internet der Dinge

Mehrwert bieten, wenn die angestoßenen Maßnahmen auch in kürzester Zeit den Empfänger erreichen und dort direkt weiter genutzt werden können. So könnte im Beispiel der automatisierten Maintenance ein als kritisch eingestufter Fall einen zugeordneten Service-Mitarbeiter automatisch mittels „Push Service“ direkt auf seinem Smartphone benachrichtigen und in diesem Zuge auch alle relevanten Informationen für das mobile Endgerät zusammenstellen. Des Weiteren gilt es, die auf mobile Endgeräte übertragenen Daten und Anwendungen abzusichern und von privaten Daten zu trennen. Gerade durch das Verschwimmen der Grenzen zwischen privater und geschäftlicher Nutzung von mobilen Geräten ein immer drängenderes Thema in Unternehmen. Oracle begegnet dieser Herausforderung mit der neuen Oracle Mobile Security Suite, die es erlaubt, geschäftliche Anwendungen und Daten in einem sicheren Container auf den Geräten zu kapseln sowie eine sichere, auf

SSL basierende Verbindung zum Backend herzustellen, die keine in der Usability eingeschränkte VPN-Connection voraussetzt. Zur Erstellung der zugehörigen Anwendungen bietet sich im Oracle Stack ADF Mobile an, das als hybrides Framework eine vom Endgerät unabhängige und auf Java-Standards basierende Entwicklung der mobilen Anwendungen zulässt.

Die nötigen Technologien sind keine Zukunftsmusik mehr, sondern liegen in Form der aktuellen Fusion-MiddlewareKomponenten bereits vor beziehungsweise werden im Rahmen von 12c ergänzt. Unternehmen können damit durch intelligente Architekturen und eine weitsichtige Integrationsstrategie schon heute den Weg zur individuellen IoT-Strategie ebnen.

Fazit Mit dem Oracle-Middleware-Stack lässt sich eine perfekt integrierte IoT-Plattform aufbauen, die sowohl eine nahtlose Integration von Sensoren und Maschinen erlaubt und die Weiterverarbeitung aller Nachrichten mit hoher Performance ermöglicht als auch die Business-Seite durch mobile Geschäftsprozesse und Anwendungen unterstützt. Im Ergebnis sprechen wir aber von weit mehr als einer technischen Plattform, vielmehr wird die IoT-Plattform immer mehr zum Kern der zukünftigen Geschäftsprozesse.

Mario Herb [email protected]

Hinweis Morgens und unterwegs schon gut informiert sein! Lassen Sie sich von uns zeigen, wie man mit APEX die wichtigsten Informationen individuell und kompakt auf Ihr Tablet bringt.

www.muniqsoft.de/mobile

DOAG News 02-2014

27

Industrie 4.0 Björn Anderseck, Fraunhofer IML

Der Begriff „Industrie 4.0“ prägt die derzeitige technische Entwicklung im Umfeld der Logistik. Der Artikel zeigt anhand von Praxisbeispielen, was genau unter der vierten industriellen Revolution zu verstehen ist und welche Rolle die Logistik darin einnimmt.

Industrie 4.0 beschreibt eine derzeit stattfindende industrielle Revolution – und zwar die vierte. Nach der Dampfmaschine, der Massenproduktion und der Digitalisierung werden heute Objekte intelligent und kommunizieren miteinander. Dies ist die Umsetzung der Idee des Internets der

Abbildung 1: Der Wandel zu Industrie 4.0

28 www.doag.org

Dinge. Speziell für industrielle Abläufe bedeutet dies, dass Maschinen, Werkzeuge, Sensoren und vieles mehr mit einer Intelligenz ausgestattet werden, die es ermöglicht, autonom Informationen auszutauschen, zu agieren, Zustände zu erfassen und Umweltdaten zu messen. Diese Revo-

lution ist durch unterschiedliche Treiber erheblich beschleunigt: Zum einen werden die benötigten Hardware-Komponenten immer günstiger und wesentlich kleiner, zum anderen sorgen Cloud-basierte IT-Landschaften dafür, dass Hardware einfacher einzubinden ist. Ein weiterer Aspekt ist die Interpretation der gesamten Prozesswelt in der Industrie 4.0. Was bedeutet es, wenn physische Objekte sich untereinander austauschen und auch Entscheidungen treffen können? Letztlich löst es die hierarchische Prozessdefinition ab. Ein Prozess wird in Form einer Zielvorgabe definiert und in verschiedene Missionen heruntergebrochen. Letztendlich erfüllen die sogenannten „Cyber-physischen Systeme“ die Missionen anhand definierter Vorgaben wie Zeit und Qualität. Welches Cyber-physi-

Internet der Dinge

sche System die Mission auf welche Art und Weise durchführt, ist für die normative Ebene irrelevant. Abbildung 1 zeigt, wie sich der Wandel zu Industrie 4.0 vollzieht. Dabei ist festzustellen, dass dieser stetig ist und sich auf unterschiedlichen Ebenen vollzieht. Auf der organisatorischen Ebene ist eine Transformation hin zum Internet der Dienste vor allem durch Cloud-basierte Anwendungen geprägt. Auf der operativen Ebene werden sich immer mehr Cyber-physische Systeme entwickeln, die nach dem Prinzip des Internets der Dinge handeln – man kann dies auch als Migration der Cyber-physischen Systeme bezeichnen.

Die Logistik als Treiber

Abbildung 2: Das Standard-Device der Logistik in Industrie 4.0, der Coaster

Die Logistik hat in den letzten Jahren drastisch an Bedeutung gewonnen. Sie entwickelt sich von einer rein reaktiven Disziplin zu einem integralen Bestandteil von Wertschöpfungsketten. Viele Beispiele zeigen, dass Logistik ein entscheidender Wettbewerbsvorteil sein kann, wenn man sie aktiv gestaltet. Für die Logistik ist Industrie 4.0 deshalb von besonderer Bedeutung, weil sie eine Schnittstellenfunktion darstellt und aus diesem Grund schon immer die Vernetzung von einzelnen Objekten, von Prozessen und vor allem von Unternehmen in einer Supply Chain als Aufgabe hat. Ein gutes Beispiel an dieser Stelle sind die Anstrengungen im Bereich der RadioFrequenz-Identifikation (RFID). Diese Technologie wurde als Lösung gesehen, um alle notwendigen Informationen in Echtzeit unternehmensübergreifend zur Verfügung zu stellen. Mit vielen Piloten wurden Waren mit Transpondern versehen und an den Toren der Unternehmen erfasst. Aus technischer Sicht ein Meilenstein in der Identifikations-Technologie. Was in vielen Fällen allerdings sehr wenig Beachtung gefunden hat, ist die Frage nach der Informationsverarbeitung, nach den verfügbaren Standards sowie den verarbeitenden Systemen. So können noch heute viele IT-Systeme mit der Welt des Internets der Dinge nicht umgehen, also mit dem Fakt, dass jedes physische Objekt individuell identifizierbar ist und damit auch systemseitig gehandhabt werden können muss. Industrie 4.0 greift genau diesen Punkt auf und rückt ihn in den Mit-

telpunkt. Es sollte nicht das Ziel sein, massenhaft Daten zu erzeugen, zu speichern und dann zu überlegen, was man damit macht. Im Gegenteil, dies ist aufgrund der Menge der Daten gar nicht möglich. Vielmehr gilt es, diese vor Ort am Objekt in Echtzeit zu verarbeiten und dann relevante Informationen in die Cloud zu geben. Mit diesem Paradigma wird konsequent das Internet der Dinge umgesetzt. Die Vorreiterrolle bei der Entwicklung des Internets der Dinge in der Logistik macht das Fraunhofer IML zum starken Entwicklungspartner für Anwendungen in Industrie 4.0. Daher postuliert das IML die hervorgehobene Rolle der Logistik in dieser Entwicklung. Aus vielen Projekten mit an Industrie 4.0 angelehnten Fragestellungen zeigt sich zudem deutlich, dass die IT mittlerweile ein integraler Bestandteil der Logistik ist. Die Aufgaben der IT sind dabei vielseitig und in diesem Artikel mit einigen Beispielen belegt. Anhand der Logistics Mall lässt sich heute zeigen, dass es für IT-Unternehmen mittlerweile sehr einfach ist, logistische Dienste zu entwickeln und anzubieten. Unterschätzt wird dabei jedoch oft das notwendige Anwendungswissen in der Logistik. Gerade für die Entwicklung Cloud-basierter Anwendungen im Bereich Industrie 4.0 bieten sich Kooperationen zwischen Industrie und angewandter Forschung an, wie viele erfolgreiche Projekte zeigen.

Der Mensch als Cyber-physisches System Seit jeher stellt sich die Frage, welche Rolle der Mensch in der digitalisierten Welt einnimmt. In den letzten Jahren wurde an vielen Stellen postuliert, dass möglichst alle Cyber-physischen Systeme in der Lage sein müssen, in geeigneter Art mit dem Menschen zu interagieren − einfach und ergonomisch. Man kann sicherlich bezweifeln, ob diese Anforderung jemals hinreichend erfüllt werden kann. Ein möglicher Ansatz ist die Einbindung des Menschen in Form eines Avatars. Der Begriff beschreibt die digitale Repräsentation des Menschen in einem Industrie-4.0System und ist dabei ein universelles Hardware-Device, das in beliebigen Prozessen anwendbar und in der Lage ist, mit Industrie-4.0-Systemen zu kommunizieren. Durch dieses Prinzip ist die Mensch-MaschineSchnittstelle stets dieselbe, bei gleichzeitiger Einsatzfähigkeit in beliebigen Anwendungen. Um zu zeigen, wie ein solches Device funktioniert, präsentierte das Fraunhofer IML zur Logimat 2014 erstmals den „Coaster“ (siehe Abbildung 2). Nach dem Motto „Alles Wichtige passt auf einen Bierdeckel“ soll dieses industriefähige Gerät das Standard-Device für die Logistik darstellen. Der Coaster übernimmt die Funktion des Avatars und ist für beliebige Zwecke in der Logistik einsetzbar. Welche Funktion er ausführt, entscheidet die App, die auf dem Coaster läuft. Nach dem bekannten App-

DOAG News 02-2014

29

Internet der Dinge

Abbildung 3: Der DyCoNet ULD

Store-Prinzip sollen hoch individualisierbare Anwendungen entstehen, die den Coaster in Industrie-4.0-Abläufe integrieren.

Umsetzungen von Industrie-4.0Anwendungen Nachfolgend sind zwei innovative Forschungsprojekte vorgestellt, die unterschiedliche Ansätze von Industrie-4.0Lösungen aufzeigen. Im Mittelpunkt des Projekts „Dynamisches Container-Netzwerk“ (DyCoNet) stehen intelligente Luftfracht-Container, die sich selbst nach dem „Internet-der-Dinge“-Prinzip steuern und koordinieren. Es handelt sich dabei um ein vom Bundesministerium für Wirtschaft und Technologie (BMWi) gefördertes Projekt im Technologieprogramm „AUTONOMIK“. Ziel ist die Entwicklung von autonomen Luftfracht-Containern, die ohne betriebliche Infrastruktur mit dezentralen, energieautarken Funkknoten ausgestattet sind und mit einem übergreifenden, informationsverarbeitenden Netz interagieren können. Somit wird die Umsetzung einer Geschäftsprozessapplikation des Internets der Dinge ermöglicht. Die Container erkennen mithilfe von RFID, welche Fracht sie enthalten, mittels Sensorik, welche äußerlichen Umgebungszustände herrschen (Temperatur, Erschütterungen oder Licht), und anhand von GPS ihren aktuellen Standort (siehe Abbildung 3). Sie sind in der Lage, sich gegenseitig zu identifizieren und Status-Informationen aktueller Sensorwerte von benachbarten

30 www.doag.org

Containern abzufragen. Im Umfeld des Containers gesammelte Informationen können mithilfe eines global verfügbaren Mobilfunknetzes an überlagerte Verwaltungssysteme, die bereits heute zur Steuerung des Materialflusses zuständig sind, weitergeleitet werden. DyCoNet zeigt, wie sich logistische Objekte wie der LuftfrachtContainer selbstständig durch ein Netzwerk routen und dabei vielerlei Informationen sammeln und dezentral verarbeiten. Die darüber liegende IT-Schicht bekommt bereits vorgefilterte Informationen und zwar genau jene, die auf der organisatorischen Ebene benötigt werden. Das Bundesministerium für Wirtschaft und Energie (BMWi) fördert darüber hinaus im Rahmen des Technologieprogramms „AUTONOMIK für Industrie 4.0“ das Forschungsprojekt „InventAIRy“. Es verfolgt die Entwicklung eines autonomen Flugroboter-Systems nach dem Prinzip des Internets der Dinge. Das System wird durch die verwendete Sensorik in die Lage versetzt, die Umgebung selbstständig wahrzunehmen und zu analysieren, um darauf basierend durch ein Lager zu navigieren, logistische Objekte zu erfassen und eine Inventur durchzuführen (siehe Abbildung 4). Zudem werden die gesammelten Informationen über Schnittstellen und Dienste an Drittsysteme (wie Warehouse-Management-Systeme) übertragen. Dies ermöglicht die unmittelbare

Weitergabe ausgewählter und kontextbezogener Informationen. Die größte Herausforderung des Projekts liegt in der Entwicklung eines autonomen Flugrobotersystems mit kognitiven Fähigkeiten, das sich selbst steuert und dabei mit anderen Objekten und Softwaresystemen kommunizieren kann. Der Flugroboter agiert als intelligentes, mobiles Objekt und bezieht seine kognitiven Fähigkeiten über die applizierten Sensoren, mit denen er in die Lage versetzt wird, eine ganzheitliche dynamische Umgebungserfassung durchzuführen. Die Erfassung der Umgebung erfolgt auf zwei Ebenen. Auf der einen steht die physikalische Erfassung des Lageraufbaus, anhand derer sich der Roboter im Raum orientieren kann. Dazu kommen sowohl Bewegungs- und Kamera- als auch GPSSensoren zum Einsatz, die eine exakte Positionsbestimmung im Outdoor-Bereich ermöglichen. Auf der anderen Ebene steht die inhaltliche Erfassung der Objekte innerhalb eines Lagers. Es betrifft typische logistische Objekte wie Ladungsträger, die mit Identifikatoren ausgestattet sind und von dem Flugroboter erkannt werden sollen. Neben der Erfassung der Umgebung besteht ein weiteres Ziel in der Skalierbarkeit des Systems. So wird in Abhängigkeit vom Gesamtsystem die Grundlage geschaffen, um die Anzahl der eingesetzten Roboter zu vergrößern oder zu reduzieren. Über in-

Abbildung 4: Einsatz von autonomen Flugrobotern in der Logistik

Internet der Dinge

telligente Dienste und Netzwerke werden die Roboter in die Lage versetzt, über einen Leitstand miteinander zu kommunizieren und das Lager selbstständig nach dem Prinzip des verteilten Arbeitens zu strukturieren. Durch die permanente Inventur bekommt der Anwender die Möglichkeit, seine Bestandskontrolle zu optimieren und im Falle von Fehllagerung ereignisgesteuerte Suchaufträge zu erteilen, um die entsprechenden Artikel aufzufinden. Die damit verbundene Erhöhung der intralogistischen Transparenz ermöglicht schnellere Prozessabläufe, die Reduktion von Fehlerkosten und somit Kostenpotenziale für die Unternehmen. Das Projekt startete im Januar 2014 und dauert drei Jahre.

allen technischen Lösungen muss jeweils die IT als integraler Bestandteil Schnittstellen bieten, mit denen Daten in hinreichender Qualität und Geschwindigkeit zur Verfügung gestellt werden können. Als Querschnittsfunktion bietet die Logistik immens breite Innovationsfelder, die noch bei Weitem nicht erschlossen sind. Das Thema „Industrie 4.0“ wird die Logistikforschung entscheidend prägen.

DOAG 2014 Logistik + IT Die DOAG veranstaltet am 7. Mai im Fraunhofer Institut für Materialfluss & Logistik in Dortmund die Community-Konferenz Logistik 4.0

• •

Fazit Die beiden Projekte zeigen, inwieweit innovative Ansätze in die Logistiklandschaft integriert werden können. Sie verdeutlichen aber auch, welche Breite die technischen Lösungsansätze haben können. Bei

Björn Anderseck [email protected]

Logistik auf dem Weg zur Industrie 4.0 Geschäftswissen für die Logistik

http://logistik.doag.org

Als Versicherungsgruppe sind wir erfolgreich. Unsere Entwicklung verläuft sehr dynamisch. Zur Verstärkung unseres Teams am Standort Stuttgart suchen wir zum nächstmöglichen Zeitpunkt einen

Linux- und Datenbankadministrator (m/w) (Oracle) Ihr Tätigkeitsfeld: In dieser Position kümmern Sie sich um die Administration von Linux-Systemen (Red Hat Enterprise Linux) und Oracle-Datenbanken. Sie erarbeiten Konzepte für Backup/Recovery mit Hilfe von HP Data Protector und Oracle RMAN, übernehmen das Patch-Management für Linux/ Oracle und sorgen selbstständig für die Planung und Durchführung von Migrationen und Upgrades. Des Weiteren betreiben Sie Troubleshooting und Performance Tuning über Systemgrenzen (Infrastruktur/Applikation) hinweg und verantworten die Implementierung und Weiterentwicklung von IT-Security-Richtlinien. Darüber hinaus fallen Erstellung, Test und Optimierung von HA-Konzepten sowie die Automatisierung wiederkehrender Abläufe mit Hilfe von Shellskripten in Ihren Aufgabenbereich. Sie helfen bei Infrastrukturplanung, Hardware-Sizing und Konfiguration von HP-x86-Servern im SAN-Verbund mit und übernehmen die Dokumentation von technischen Abläufen sowie die Erstellung von Betriebskonzepten. Installation, Fehlersuche und Betrieb runden Ihr Aufgabenfeld ab. Ihr Profil: Sie verfügen über ein abgeschlossenes Informatik-/Mathematikstudium oder eine vergleichbare Qualifikation und besitzen bereits mehrjährige Erfahrung im Betrieb von Linux-Systemen. Darüber hinaus haben Sie hervorragende Shell-Skripting-Fähigkeiten (inbesondere Bash) und vertieftes Knowhow sowie praktische Erfahrung in der Oracle-Datenbank-Administration. Sie besitzen ein gutes Verständnis für IT-Infrastrukturfragen zu Storage, SAN, Netzwerk, Mehrschichtenarchitektur, Cluster und Hochverfügbarkeit sowie gute analytische Fähigkeiten für das Lösen komplexer Probleme. Ihre Persönlichkeit: Sie arbeiten strukturiert und selbstständig, haben ein hohes Verantwortungsbewusstsein und überzeugende kommunikative Fähigkeiten. Sie zeichnen sich durch Freude an der Lösung herausfordernder Aufgaben im Team sowie hohe Belastbarkeit und Einsatzbereitschaft aus. Wir bieten Ihnen eine leistungsgerechte Vergütung, umfangreiche Sozialleistungen sowie einen modernen und sicheren Arbeitsplatz. Nutzen Sie Ihre Chance, in einem innovativen, erfolgreichen und zukunftsorientierten Unternehmen mitzuarbeiten! Senden Sie bitte Ihre vollständigen Bewerbungsunterlagen unter Angabe Ihrer Gehaltsvorstellung und des möglichen Eintrittstermins an unsere Personalabteilung. Für telefonische Vorabinformationen steht Ihnen Herr Jörg Märkle, Telefon 0711 1695-6042, E-Mail: [email protected], gerne zur Verfügung.

Gemeinsam auf dem Weg zum Erfolg. Wir freuen uns auf Ihre Bewerbung! Württembergische Gemeinde-Versicherung a.G. | Tübinger Straße 55 | 70178 Stuttgart | www.wgv.de

DOAG News 02-2014

31

Internet der Dinge

Lufthansa Realtime Tracking Niko Hossain, Lufthansa Cargo AG

Wo befindet sich in genau diesem Moment meine Luftfrachtsendung? Der Artikel zeigt die ersten Footprints des „Internets der Dinge“ (siehe http://www.internet-der-dinge.de) auf dem Plateau des Lifecyle Hypes (siehe http://www.gartner.com/technology/research/methodologies/hype-cycle.jsp).

Auf Fragen wie „Wo sind meine Automobilteile für das Werk nahe Shanghai gerade?“ oder „Haben die Turnierpferde aus Argentinien ihre Flugreise nach Deutschland hinter sich und sind jetzt wie geplant im Spezial-Lkw auf der Autobahn unterwegs?“ erhalten Kunden ab sofort schon mit wenigen Mausklicks auf dem Webportal www.lufthansa-cargo.de/realtime eine präzise Antwort. Realtime Tracking heißt der neue Service, der in Echtzeit die Position von Shipments berechnet – treffsicher bis auf wenige hundert Meter, fast überall auf der Welt. Der Ortungsservice erstreckt sich über die gesamte Lieferkette, also auch über die Vor- und Nachlauf-Logistik. Insbesondere bei Sendungen mit zeitkritischer und wertvoller Fracht kann er nützliche Informationen liefern. Die industrielle Revolution in der vierten Generation, auf Neudeutsch „Cyber Physical Systems“ (siehe www.vdi.de/uploads/ media/Stellungnahme_Cyber-Physical_Systems.pdf), wurde vor rund dreißig Jahren von Mark Weiser in seinem Artikel „Ubiquitous computing called ‚The Computer for the 21st Century‘“ als das Internet der Dinge postuliert. Prof. Dr. Michael ten Hompel, Inhaber des Lehrstuhls für Förder- und Lagerwesen an der Universität Dortmund und geschäftsführender Institutsleiter am Fraunhofer-Institut für Materialfluss und Logistik IML, und Elgar Fleisch, Direktor am Institut für Technologiemanagement der Universität St. Gallen und Inhaber des Lehrstuhls für Informationsmanagement an der ETH Zürich, waren einige der wenigen, die den Gedanken weiterführten und ihn auf industrielle sowie vor allem unternehmenslogistische Anwendungen übertrugen. Wie bei vielen technischen Innovationen zeigt sich allerdings bis zum heutigen

32 www.doag.org

Tage, dass die Adaptionsaffinität im privaten Konsumentenbereich wesentlich agiler und marktrelevanter als im Umfeld industrieller Applikationen vonstatten geht. Ein Versatz von fünf bis fünfzehn Jahren ist dabei im Bereich technischer Innovationen nicht als untypisch zu erachten (zum Beispiel E-Mail, Diensthandy, Apps). Im Jahr 2014 werden die ersten konkreten Innovationen mit Marktrelevanz allerdings auch im Dienstleistungssektor sichtbar. Ein aktuelles Beispiel stellt der weltweite Realtime Tracking Service der Lufthansa Cargo AG dar.

Problemstellungen In der Luftfracht sind die verschiedenen land- und luftgebundenen Transportnetze für Passagiere und Luftfracht logistisch miteinander verknüpft. Sie verbinden die Produktionsstandorte und Verbrauchermärkte weltweit und spielen in der Transportkette für hochwertige und eilige Transporte eine entscheidende Rolle. In der Luftfracht-Transportkette gibt es eine Vielzahl beteiligter Unternehmen, die ihre Prozesse an den Flughäfen unabhängig voneinander planen und durchführen. Dadurch entstehen allerdings auch viele Systembrüche und eine hohe Intransparenz für den Versender und Empfänger an den beiden Enden der Kette in Bezug auf den aktuellen Status der Luftfrachtsendung. Vor allem für Sendungen mit kritischem Ressourcen-Bedarf (Produktionslogistik) oder gar im Offshore-Anlagenbau hängen oftmals die Personalplanung und dementsprechend hohe Kosten von dem konkreten Zustellzeitpunkt ab. Diese Problemstellung kann durch die komplexe Vielschichtigkeit der Wertschöpfungskette derzeit kurzfristig nur mit einer geeigne-

ten Tracking-Lösung an der Sendung realisiert werden, die unabhängig von Ort, Unternehmen, Infrastruktur und manuellen Prozessen aktuelle Statusmeldungen abgibt. Die Lufthansa Cargo AG ist seit November 2013 in der Lage, allen Kunden weltweit einen solchen Service anzubieten.

Roadblocks Die größten Schwierigkeiten für die Nutzung herkömmlich bekannter elektronischer Enabler zur Verknüpfung von Material- und Informationsfluss stellen in der zivilen Luftfahrt die Regularien der Luftfahrtbehörden zur Flugsicherheit dar. Jedes Objekt, das in der Lage ist, elektromagnetische Interferenzen mit den sensiblen Systemen eines Flugzeugs herzustellen, muss aufwändigen Tests unterzogen werden, um von den Behörden und dem entsprechenden Flugbetrieb akzeptiert zu werden. Darüber hinaus ist die Organisation der Logistik von entsprechenden SmartDevices ein wichtiger Faktor für die Wirtschaftlichkeit. Sprechen wir von offenen

Abbildung 1: Der Umschlag wird an der Sendung angebracht

Internet der Dinge

Systemen, also keinem logistischen internen Kreislauf beim Materialfluss, so muss sichergestellt sein, dass die Technologie zum Start der Transportkette gelangt und auch von deren Ende wieder an eine zentrale Stelle zurückkommt. In der Luftfracht sind die Transportströme klassischerweise unpaarig, was bedeutet, dass die Fracht nicht mehr denselben Weg der Transportkette zurück zum Ursprung durchläuft. Dies führt zu einem erhöhten Aufwand im weltweiten Asset Management. Durch die Anforderungen der Elektronik an sich entstehen außerdem Wartungsbedarfe, um die entsprechende Elektronik mehrfach verwenden zu können und somit die Stückkosten zu senken und der Nachhaltigkeit gerecht zu werden. Batterien müssen gewechselt werden, damit ein Gerät zu jeder Zeit immer voll funktionstüchtig in der Transportkette funktioniert. Für die tatsächliche Anwendung spielen außerdem Größe, Gewicht und die Anbringung eine entscheidende Rolle. Die Geometrie determiniert in machen Fällen gar die generelle Einsatzbarkeit, bei der die Relation von Shipment und Gerät in einem entsprechenden Verhältnis stehen sollte. Schaut man sich manche Lösungen am Markt an, so wird schnell klar, dass diese nur für Container oder komplette Paletten einsetzbar erscheinen. Die Usability ist zum Schluss ein entscheidender Faktor für den Erfolg einer verteilten Lösung mit menschlicher Wechselwirkung. Hier kann nur statuiert werden, dass die Lösung so einfach wie möglich gestaltet sein muss. Als Fazit zu diesem Thema könnte man etwas süffisant mit der Aussage zusammenfassen „Ein Knopf ist immer noch zu viel“.

Anwendung und Lösung Realtime Tracking von Lufthansa Cargo bleibt einer Sendung ab dem Moment der Aufgabe auf der Spur. Der Kunde ist über die gesamte Transportkette hinweg immer genauestens darüber informiert, wo sich seine Sendung gerade befindet. Im Service enthalten sind die Vor- und NachlaufLogistik sowie der Zugang zu den übertragenen Daten auf dem Tracking-Portal. Der Kunde kann das System nutzen, ohne Geräte oder Software kaufen zu müssen. Er muss sich nur einmal für den Dienst registrieren. Dann kann er die Tracking-Gerä-

Abbildung 2: Der Weg der Sendung

te mit einer Mindestabnahmemenge von zwanzig Stück auf Mietbasis ordern. Aktiviert wird das Echtzeit-Tracking, indem der Nutzer einen Knopf auf dem gepolsterten Umschlag drückt (siehe Abbildung 1). Von diesem Moment an sendet das Gerät Signale, die über Mobilfunkmasten geortet werden. Am Empfangsort wird das Tracking mit demselben Button wieder deaktiviert. Der Nutzer muss den bereits frankierten und mit einer Adresse versehenen Umschlag dann nur noch in einen Briefkasten werfen und das Mietgerät geht zurück an den Hersteller. Dort wird es bei Bedarf auch gewartet. In Sachen Handling punktet das Sendungsverfolgungsgerät ebenfalls; es ist sehr robust und wird auch dann nicht beschädigt, wenn man es versehentlich auf einen harten Boden fallen lässt. Das Trackingportal ist als Applikation im Internet einsatzbereit und muss nicht installiert werden. Es ist überall und mit jedem Rechner nutzbar. Jeder Kunde bekommt einen eigenen Account, mit dem er den Status seiner Sendungen abrufen kann (siehe Abbildung 2). Künftig soll der Service zusätzliche Funktionalitäten erhalten. So sollen zusätzliche Sensoren auch die Umgebungsbedingungen der Sendungen erfassen. Zudem wird der Kunde durch automatisch generierte Statusmeldungen informiert, sobald eine Sendung ihr Zielgebiet erreicht hat. Hierzu kommt die sogenannte „Geofencing-Technologie“ zum Einsatz.

Fazit Die Realtime-Tracking-Lösung der Lufthansa Cargo AG ist eine weltweit einzigartige Lösung im Bereich Logistik, Nutzung und Technologie. In Anbetracht vieler Lösungen auf dem Markt für verschiedenste Anwendungsszenarien entsteht der Eindruck, dass die Lösung gedanklich der Idee des Internets der Dinge am nächsten kommt, da eine völlige Flexibilität in Bezug auf Kosten und Nutzung besteht und weltweit keine Infrastruktur zum Einsatz benötigt wird. Zudem ist die Lösung klein und leicht. Das weltweite Kundenfeedback ist sehr positiv und die Lufthansa Cargo AG wird zukünftig weiterhin neue Servicelösungen für ihre Kunden im Bereich der Zusatzinformationen (eCargo Programm der Lufthansa Cargo Strategie) und Services anbieten, in dem Sinne „All concepts are metaphors – release your seat belts, there is so much going on!”

Niko Hossain [email protected]

DOAG News 02-2014

33

Internet der Dinge

Schneller reagieren: Neue IT-Unterstützung von Unternehmensprozessen Dominik Bial, OPITZ CONSULTING GmbH

Integration und Automatisierung sind besondere Herausforderungen, wenn Unternehmen mobile Szenarien oder Szenarien aus dem Bereich des Internets der Dinge einführen.

Das Angebot neuer Services, die Integration weiterer Anwendungen und das Datenaufkommen steigen erheblich. Gleichzeitig wächst die Komplexität einer Unternehmens-Architektur. Existiert bereits eine serviceorientierte Architektur, stimmen die Voraussetzungen, um Unternehmensprozessen Daten aus dem Internet der Dinge und von mobilen Geräten hinzuzufügen. Dies erlaubt Unternehmen, Prozesse anhand aktueller Gegebenheiten anzupassen und so schneller zu reagieren. Serviceorientierte Architekturen (SOA) sind mittlerweile in der Realität angekommen. Ihre Vor- und Nachteile sind bekannt und an vielen Stellen erprobt. In der Praxis zeigt sich, dass eine SOA heute insbesondere in der Integration und Automatisierung eine grundlegende Rolle spielt. Eine SOA ist essenziell, um die Potenziale des Internets der Dinge und des Mobile Computing

voll auszuschöpfen. Sie bietet Unternehmen die Möglichkeit, auf wechselnde Geräte und Dienste schnell zu reagieren, neue Funktionen den Unternehmensanwendungen als Service zur Verfügung zu stellen und diese in Unternehmensprozessen zu nutzen. Die SOA ist technische Grundlage für neue Geschäftsmodelle. Sie hilft dabei, neue Herausforderungen zu meistern und auf die immer schneller werdenden Innovationszyklen zu reagieren. Der Erfolg einer SOA liegt in der losen Kopplung begründet, die mit sogenannten „Services“ realisiert wird. Diese realisieren Funktionen, die von verschiedenen Unternehmensanwendungen aufgerufen werden können. Mittels Orchestrierungsoder Prozessbeschreibungs-Sprachen wie der Business Process Execution Language (BPEL) oder der Business Process Model and Notation (BPMN) sind Abhängigkei-

ten zwischen einzelnen Serviceaufrufen realisier- und visualisierbar. Typischerweise besteht eine SOA aus mehreren Schichten. Auf eine Integrationsschicht folgt im Normalfall eine Serviceschicht, die wiederum von der Prozess- und Orchestrierungsebene verwendet wird. In den letzten Jahren sind weitere Technologien entstanden, die SOA ergänzen. Für mobile Szenarien und das Internet der Dinge sind das insbesondere Complex Event Processing (CEP) und Business Activity Monitoring (BAM). CEP ermöglicht es, mit vordefinierten Regeln Datenströme in nahezu Echtzeit zu analysieren und somit Abweichungen in Unternehmensprozessen zu erkennen. BAM baut auf CEP auf und bietet sich an, um Echtzeit-Dashboards und Reports zu generieren. Interessant ist dabei insbesondere die Chance, proaktiv in Prozesse einschreiten zu können. Mit der Entwicklung des Internets der Dinge und des mobilen Umfelds erhalten SOA und ergänzende Technologien eine höhere Relevanz. Das Internet der Dinge und Mobile verändern Strukturen und Daten in Unternehmen dahingehend, dass diese zunehmend operativer Natur werden. Zuvor waren SOA-Lösungen eher im Bereich von statischen Unternehmensprozessen zu finden.

Die Lücke in der Feld-Ebene

Abbildung 1: Der Wert einer Information in Relation zu der Zeit, angelehnt an Hackathorn [1]

34 www.doag.org

Das Internet der Dinge und Mobile Computing stellen Unternehmen Informationen in nahezu Echtzeit zur Verfügung. Während in den letzten Jahren hauptsächlich Lösungen entstanden, die die Kommunikation und die Verarbeitung von Informationen unterstützen, verkürzen das Internet der Dinge

Internet der Dinge

und der Einsatz von mobilen Geräten die Erkennungs- und Analyse-Phase (siehe Abbildung 1). Dies verspricht insbesondere für Unternehmen, die ihr Kerngeschäft im operativen Bereich haben, einen Mehrwert. Werden beispielsweise Güter von einem Logistik-Unternehmen verschifft, Patienten mobil durch einen Pflegedienst versorgt oder Geräte wie Snack-Automaten aufgestellt, so lassen sich durch eine Anbindung an das Unternehmen direkt Angaben zum aktuellen Status, zum Verbrauch oder zu neuen Gegebenheiten übermitteln. Diese Übermittlung verkürzt enorm die Zeit, die bis zur weiteren Reaktion benötigt wird, da Informationen direkt zur Verfügung stehen und nicht umständlich von Papier übertragen werden müssen. Kommen zusätzlich Technologien wie BAM oder CEP zum Einsatz, lassen sich die Datenströme sogar gezielt überwachen und analysieren. Wenn entsprechende Geräte eine Anbindung an das Internet besitzen, lassen sie sich in zweierlei Richtung nutzen. Sie stellen nicht nur Informationen zur Verfügung, sie können auch gesteuert werden. Das kann beispielsweise eine automatisierte Anpassung von Routen eines Logistikunternehmens je nach Nachfrage in einzelnen Supermärkten bedeuten. An Snackautomaten sind spontane Preisanpassungen denkbar, falls ein Produkt an anderen Automaten gerade besonders gefragt ist. Im Pflegedienst könnten Verbrauchsgüter bei Bedarf automatisch nachbestellt werden. Eine SOA unterstützt diese Prozesse in mehreren Punkten: Mobile Geräte und Geräte des Internets der Dinge sind äußerst schnelllebig und werden häufiger ausgetauscht als Desktop-Computer. Eine SOA hilft bei der Integration und Nutzung von notwendigen Schnittstellen. Die Dynamik und Anpassbarkeit der Unternehmensarchitektur, die hier notwendig ist, lässt sich direkt mit Konzepten und Werkzeuge aus dem SOA-Bereich adressieren. Daten, die durch das Internet der Dinge und mobile Geräte gewonnen werden, sind ebenfalls schnelllebiger als andere Unternehmensdaten. Sie veralten schneller oder werden einfach irrelevant. Mittels Automatisierung von Prozessen und weiterer Technologien wie CEP und BAM lassen sich diese Daten in nahezu Echtzeit

Abbildung 2: Einsatz von SOA im Mobile Business und im Internet der Dinge

analysieren und verarbeiten, sodass Prozesse direkt beeinflusst und angepasst werden können. Sofern die passenden Schnittstellen zur Verfügung stehen, lassen sich Geräte mithilfe von Orchestrierungssprachen adressieren und steuern. Falls nötig, können Prozesse dann warten, bis eine bestimmte Gegebenheit in der Feldebene existiert oder sich ein Gerät bei einem Prozess zurückgemeldet hat. Der Einsatz von BPMN hat den Vorteil, dass der in der Feldebene stattfindende Prozess auch gleich dokumentiert wird. In der operativen Ebene, die in den letzten Jahren vernachlässigt wurde oder in der eine IT-Unterstützung bislang nicht möglich war, setzt die gezielte Analyse von Unternehmensprozessen ein enormes Potenzial zur Automatisierung und weiteren IT-Unterstützung frei.

Die Unternehmens-Architektur Abbildung 2 zeigt, wie SOA den Mehrwert von Mobile Computing und dem Internet der Dinge aufgreift. Über eine Integrationsschicht, die Unternehmensanwendungen über Adapter mit verschiedenen Diensten versieht, werden die Datenvielfalt und damit die Einsicht in Prozesse enorm gesteigert. Mit diesen Informationen lassen sich Services ergänzen und neue Services realisieren.

Oracle hat eine Reihe von Produkten für den Einsatz in SOA konzipiert. Mit dem Oracle Service Bus (OSB) ist zum Beispiel eine erste, technische Integration von Services und damit auch von verschiedenen Gerätetypen möglich. Der OSB wird zur Vorfilterung und für erste Daten-Transformationen eingesetzt. Im zweiten Schritt bieten sich Oracle SOA Suite beziehungsweise Oracle BPM Suite an, mit denen sich fachlich motivierte Services und Prozesse realisieren lassen. Gerade der Einsatz von Mediatoren und Events unterstützt die Kommunikation zwischen einzelnen Prozessen und Geräten. Die Suites können Oracle BAM und Oracle CEP integrieren. Im Zusammenspiel mit Oracle BAM werden Prozesse und deren Ausführung überwacht. Oracle Event Processing erlaubt eine Analyse der Daten innerhalb einer SOA in nahezu Echtzeit und eine darauf basierende Reaktion. Mittels Oracle Business Analytics lassen sich gewonnene Daten später noch analysieren und damit zum Beispiel Referenzwerte für Regeln gewinnen, die innerhalb einer SOA zum Einsatz kommen. Da diese Technologien von dem gleichen Anbieter stammen, sind Support, Werkzeugunterstützung sowie Integration gut aufeinander abgestimmt. Die Analyse von nahezu Echtzeitdaten und die Kommunikation, die SOA im mo-

DOAG News 02-2014

35

Internet der Dinge

bilen Bereich und im Internet der Dinge ermöglicht, verkürzt erheblich die Zeit, die bis zu einer Reaktion innerhalb des Unternehmens benötigt wird. Gerade Firmen, deren Wertschöpfung im operativen Bereich liegt, können sich auf diese Weise von Mitbewerbern abheben.

Architektur in der Feldebene In Abbildung 2 finden sich sowohl Cloud Service Provider als auch lokale Gateways wieder, die als Alternative zur direkten Kommunikation mit der Softwarelandschaft zum Einsatz kommen können. Während Informationen direkt von CloudPlattformen bezogen und auch als Teil der Architektur genutzt werden können (zum Beispiel Xively [2]), bieten sich Minicomputer an, um eine räumliche oder organisatorische Trennung von mobilen Geräten zu ermöglichen. Mit dem Einsatz eines Minicomputers wird ein Knotenpunkt geschaffen, der einerseits Informationen aus der SOA bezieht und zu dieser sendet und andererseits direkt durch Mitarbeiter vor Ort beeinflusst wird (siehe Abbildung 3). Ein lokaler Gateway verwaltet dabei Sensoren und Aktuatoren, die sich in seinem Bereich befinden. Dieser Ansatz hat den Vorteil, dass Befugnisse und Rechte an Mitarbeiter vergeben werden, die sich vor Ort befinden und damit auch einen Überblick über die laufenden Prozesse haben. Diese Mitarbeiter können die Prozesse dann direkt beeinflussen und werden damit zu lokalen Entscheidungsträgern und Prozess-Koordinatoren. Gleichzeitig findet eine Vorfilterung und damit eine Verteilung von Last statt. Die Logik der Unternehmens-IT wird in die Feldebene verlagert. Für entsprechende Szenarien hat Oracle das Produkt Oracle Event Processing for Java Embedded im Einsatz, das sich beispielsweise auf dem Rasperry Pi ausführen lässt [3, 4]. Mittels leichtgewichtiger Kommunikationsstandards wie REST lassen sich problemlos Kommunikationsstrukturen zwischen den Geräten, dem Unternehmen und den Benutzern vor Ort erschaffen.

Fazit SOA hat sich in den letzten Jahren etabliert. In einer Vielzahl von Projekten zeigt

36 www.doag.org

Abbildung 3: Einsatz lokaler Gateways

sich, dass sie Unternehmen die folgenden Vorteile bringen kann: • • • • • •

Schnelle Anpassbarkeit von Prozessen Schnelle Erreichbarkeit der Marktreife neuer Dienste Erhöhte Qualität bei verringerten Kosten Niedrigere Projektkosten bei Umsetzung neuer Business-Anforderungen Hohe Zukunftssicherheit Vereinfachte Integration

Die technischen Grundlagen, die eine SOA hier bietet, sind insbesondere essenziell bei der Integration des Internets der Dinge und mobiler Geräte in Unternehmen. Oracle bietet hier eine Reihe von Produkten, um entsprechende Szenarien umzusetzen. Betrachtet man die Vorteile einer SOA, wird deutlich, dass diese eine ideale Ergänzung zum Internet der Dinge und Mobile darstellt. Unternehmen, die in den letzten Jahren in eine SOA investiert haben, haben gute Voraussetzungen, um die Potenziale von mobilen Geräten und des Internets der Dinge für ihr Unternehmen zu erschließen und ihre Architektur daran auszurichten. SOA ermöglicht den Unternehmen

die Nutzung eines neuen Spektrums an Daten, auf das sie ihre Unternehmensprozesse abstimmen können. Damit wird es ihnen möglich, schneller auf Vorkommnisse in Prozessen zu reagieren und diese zeitnah anzupassen.

Literatur

[1] R. Hackathorn, The BI Watch, Real-Time to RealValue, DM Review, Januar 2004: http://www. bolder.com/pubs/DMR200401-Real-Time%20 to%20Real-Value.pdf [2] Xively: https://xively.com [3] Rasperry PI: http://www.raspberrypi.org [4] Oracle and Rasperry PI: http://www.oracle.com/ technetwork/articles/java/raspberrypi-1704896. html

Dominik Bial [email protected]

Exadata und Exalogic X4-2 Herbert Rossgoderer und Matthias Fuchs, ISE Information Systems Engineering GmbH

Dieser Artikel beschreibt die Entwicklung der Oracle Engineered Systems Exadata und Exalogic bis zum heutigen Tag und stellt die neuen Funktionen der X4-2-Generation vor. Zudem wird auf Aspekte wie Leistung, Installation, Kosten und Betrieb der Systeme eingegangen.

Die Exadata Database Machine, das Flaggschiff der Oracle Engineered Systems, ist bereits im Jahr 2008 als erstes System dieser Produktfamilie unter dem Namen „Exadata V1“, damals noch mit HewlettPackard-Hardware, auf den Markt gekommen. Ab dem Jahr 2009 waren diese Systeme dann als Exadata V2 mit SunHardware ausgestattet, was bei allen Nachfolgemodellen beibehalten wurde. Das System ist als optimale Plattform für die Oracle-Enterprise-Datenbank konzipiert, insbesondere für skalierbare Parallelverarbeitung im Real Application Cluster (RAC), bei dem I/O- und ProzessorLeistung im Einklang stehen. Man spricht deshalb auch von einem optimal ausgewogenen System (well balanced system). Als Betriebssystem stehen Oracle Linux und Solaris x86 zur Wahl. Die Exadata Database Machine wurde wie auch die spätere Exalogic von Anfang an in einem 19-Zoll-Schrank (Rack) als Gesamtsystem ausgeliefert. Man kann diese Racks komplett (Full Rack), als Halb-,

Viertel- und seit der Version X3-2 auch als Achtel-Rack erwerben. Die Systeme sind voll redundant ausgelegt und können problemlos auf die nächste Größe erweitert werden. Außerdem lassen sich mehrere Schränke via InfiniBand zusammenschalten, die dann wiederum als ein integriertes System fungieren. InfiniBand kam von Beginn an als Netzwerk-Technologie zwischen den Datenbank-Knoten und den Exadata-Storage-Servern (auch Exadata Cell Server) zum Einsatz.

Die aktuell in der Version X4-2 verwendeten InfiniBand-QDR-Verbindungen (40 Gbit/s) sind aktiv-aktiv gekoppelt und haben demnach eine Übertragungsrate von 80 Gigabit pro Sekunde pro Pfad. Um die OLTP-Performance zu verbessern, wurden die mechanischen Platten durch Flash-Speicher ergänzt und von Generation zu Generation in ihrer Kapazität erhöht. Im Zuge der Weiterentwicklungen stiegen die Anzahl der CPU-Cores sowie die Festplattenkapazität ebenfalls deutlich an. In Kombination von

V1

V2

X2

X3

X4

2008

2009

2010

2012

2013

Cores

64

64

96

128

192

Memory (GB)

256

576

1152

2048

4096

Storage (TB)

168

336

504

504

673

Flash (TB)

0

5,3

5,3

22,4

44,8

Connectivity (Gb/s)

8

24

184

400

400

Release-Jahr

Tabelle 1: Full Rack Exadata von V1 bis X4-2

DOAG News 02-2014

37

Aktuell

Software- und Hardware-Verbesserungen konnte so der Datendurchsatz von 8 Gigabit pro Sekunde (V1) auf 400 Gigabit pro Sekunde (X4-2) um den Faktor 50 gesteigert werden (siehe Tabelle 1).

Exadata Software X4-2 Das für die extreme I/O-Leistungsfähigkeit entscheidende Innovationsmerkmal der Exadata Database Machine ist ein intelligenter Storage, der nur möglich ist, weil Datenbank und Storage sich gegenseitig kennen und die gleiche Sprache sprechen. Das Hauptziel des intelligenten Storage ist, den Datentransfer zwischen Speicher und Datenbank zu reduzieren. Die Verarbeitung von SQL-Statements soll weitestgehend im Storage erfolgen. Nur das Ergebnis der Abfragen wird zur Weiterverarbeitung an die Datenbank übermittelt (Smart Scan beziehungsweise Offloading). Das Ziel, den I/O erst gar nicht entstehen zu lassen, ist über einen Storage-Index realisiert. Der weiteren I/O-Leistungssteigerung dienen die Flash-Karten in den Storage-Servern (Cell Flash Cache), die zur Lese-Optimierung (Smart Flash Cache), zur Verbesserung der Redo-Performance (Smart Flash Log) sowie als Write-BehindCache (Smart Flash Cache Write-Back) konfiguriert werden können. Zur weiteren Optimierung der I/O-Leistung und der Speicherkapazität wird ein spaltenorientiertes Komprimierungsverfahren für Tabellen angeboten, die sogenannte „Hybrid Columnar Compression“ (HCC), mit der sich Tabellen-Inhalte in günstigen Konstellationen um bis zu einem Faktor von 50 reduzieren lassen. Um bei der Konsolidierung vieler Datenbanken auf eine Database Machine die enorme I/O-Leistungsfähigkeit weiterhin für die kritischsten Datenbanken zu gewährleisten, kann man mit dem I/O Resource Manager eine entsprechende Priorisierung dieser Datenbanken definieren. Zusätzlich sorgt das in der X4-Generation neu hinzugekommene Network Resource Management für niedrige Antwortzeiten bei zeitkritischen Datenbank-Operationen, selbst wenn parallel dazu Reports, Batchläufe oder Backups durchgeführt werden.

Exadata und In-Memory Die neuen X4-2-Datenbank-Knoten haben standardmäßig 256 GB Hauptspeicher,

38 www.doag.org

X2-2

X3-2

X4-2

Cores

48

64

96

Memory (GB)

384

1024

1024

Storage TB

40

60

80

Storage SSD Read TB

2

4

6,4

Local SSD Raid 1

80

100

400

Tabelle 2: Achtel-Exalogic von X2-2 bis X4-2

der auf 512 GB erweitert werden kann. Somit ist es bereits beim kleinsten System (Achtel-Rack) möglich, auf 1 TB Hauptspeicher zurückzugreifen. Die Achtel- und Viertel-Racks bestehen jeweils aus zwei Datenbank-Knoten und drei Storage-Servern. Dies ist die Mindestausstattung, um Redundanz und damit Ausfallsicherheit zu gewährleisten. Beim Achtel-Rack ist jedoch die Hälfte der Prozessoren und Platten deaktiviert, wohingegen der Hauptspeicher voll vorhanden ist. Somit bildet bereits die Achtel-Lösung eine ideale Plattform für die zukünftige In-MemoryOption der Datenbank 12c (12.1.0.2). Für hoch performante OLTP-Anwendungen steht damit selbst bei einem Achtel-Rack 1 TB Hauptspeicher (DRAM) zur Verfügung und für Echtzeit-Analysen kann auf den fast 5 TB großen Cell-FlashCache zurückgegriffen werden, der sich durch Hardware-Komprimierung effektiv auf das bis zu Fünffache erweitern lässt. Durch das massiv parallele Storage-Grid skaliert der I/O-Durchsatz linear über alle mechanischen Platten und Flash-Module beim Ausbau auf ein Viertel-, Halb- oder Full-Rack.

Exalogic von X2-2 bis X4-2 Die Exalogic ist nach Exadata das zweite System im Rahmen der Engineered-Systems-Familie; später kamen Exalytics und Big Data Appliance hinzu. Exalogic ist optimiert für die Verwendung von Middleware-Applikationen. Dabei können OracleApplikationsserver wie WebLogic oder Tuxedo zum Einsatz kommen. Als BasisBetriebssystem dienen Oracle Linux oder Solaris X86 – somit sind alle Arten von Anwendungen möglich, die unter diesem Betriebssystem zertifiziert sind. So entsteht ein breites Einsatzgebiet für dieses Engineered System.

Im Jahr 2011 wurde die erste Version (X2-2) der Exalogic ausgeliefert, 2013 folgte die Version X3-2, dieses Jahr die Version X 4-2. Es wurde jeweils auf die aktuelle Prozessorfamilie gewechselt (Intel Xeon). Die Anzahl der Cores pro Prozessor ist von 6 über 8 auf 12 gestiegen. Tabelle 2 zeigt ein Achtel-Rack im Überblick. In der aktuellen Version X 4-2 kommen auf einen Core gut 10 GB Hauptspeicher. Ein Core besteht dabei aus zwei Threads. Somit ist für jeden Thread ein Speicher von 4 GB vorhanden. Das entspricht in etwa der Größe einer Standard Java VM. Die Exalogic kann in drei verschiedenen Ausprägungen betrieben werden: Bare Metal Virtualisierung • Mixed Bare Metal virtualisiert (neu) • •

In der Bare-Metal-Variante ist Oracle Linux oder Solaris X86 direkt auf den Servern installiert. Bei der Virtualisierung kommt Oracle VM zum Einsatz. Diese Variante ist optimiert für den InfiniBand Stack. Die virtuellen Maschinen (vServer) können nur mit Oracle Linux betrieben werden. Bei der Installation im Mixed Mode werden virtuelle Server mit Bare-Metal-Servern innerhalb einer Exalogic kombiniert. Somit kann man für den jeweiligen Einsatzzweck immer die beste Variante wählen. Im Rahmen des letzten virtuellen Software-Release wird der Oracle Assembly Builder unterstützt. Somit lässt sich das gesamte System, zum Beispiel bestehend aus einem WebLogic Server, einer SOA Suite und einem Service Bus, im Rahmen eines Assembly auf der Exalogic innerhalb weniger Minuten in einem Schritt installieren. Darüber hinaus wurde die Größe des Exalogic-Control-Stacks von fünf virtuellen Maschinen auf drei reduziert. Die

Aktuell

Die Key-Indikatoren Zeit und Kosten

Bild 1: Memory- und Storage-Verhältnisse Achtel-Exadata X4-2 High Capacity Disks

Templates der virtuellen Maschinen wurden durch OSWatcher-Skripte erweitert; die Verwendung von Logical Volume Manager ist jetzt Standard. Die bekannten Oversub-Skripte der virtuellen CPUs, also mehr CPUs als vorhanden zuzuweisen, bleibt erhalten und der OVM-Stack ist auf die aktuelle Version 3.2 angehoben.

Exalogic-Performance Bei den Engineered Systems spielt der Exabus eine herausragende Rolle. Er beruht auf InfiniBand-Technologie. Diese wird im QDR-Modus eingesetzt, der eine Bandbreite in der X4-2 im active-active Mode (Exadata) von 80 GBit und deutlich niedrigere Latenzzeiten als 10 GBit Ethernet ermöglicht. Die Geschwindigkeit wird nicht nur innerhalb der einzelnen Knoten erreicht, sondern auch zwischen verschiedenen Engineered Systemen, etwa beim Zugriff auf eine Exadata. Zusätzlich zur schnellen Netzwerk-Verbindung werden speziell optimierte Treiber für den InfiniBand-Stack und die Server-Hardware verwendet, was die Performance der schnellen Exabus-Infrastruktur nochmals steigert. Hierzu zählen die Optimierungen für WebLogic, Tuxedo oder Coherence. Neben den herausragenden HardwareKomponenten gibt es Software, die nur im Rahmen der Exalogic verwendet werden

darf (gegebenenfalls auch auf der Database Appliance). Dazu zählt der Traffic Director, ein hochverfügbarer Software-Loadbalancer. Er kann neben den Standardprotokollen für Web-Applikationen (http/https) auch WebLogic-Protokolle wie „t3s“ oder jede TCP/IP-Connection verteilen. In Kombination mit der Möglichkeit, Daten zwischenzuspeichern und über den InfiniBand-Stack zu verteilen, ist das die ideale Ergänzung, um eine Exalogic einfach im EnterpriseNetzwerk zu integrieren. Es kann jeder Connect auf die Exalogic über den Traffic Director erfolgen. Alle weiteren Netzwerke, die nur intern verwendet werden, müssen im Firmennetzwerk nicht bekannt sein. Ein entscheidender Vorteil eines Engineered Systems ist die komplette Integration in Cloud Control Enterprise Manager. Dadurch hat man alle Komponenten des Systems vom Switch über die Server und den Storage bis hin zum Software-Stack in einem Tool integriert. In Kombination mit dem Oracle Platinum Support werden die Systeme im Rahmen eines Supportvertrags kostenlos gepatcht. Im Falle eines Hardware-Defekts können automatisch Service Requests per ASR erzeugt werden. Patches werden immer über das ganze System getestet. Die Abhängigkeiten zwischen Storage, Servern und Switches ist somit immer gewährleistet.

Die Kosten für die Hardware einer Exa­data oder Exalogic übersteigen leicht die Kosten für in etwa vergleichbare Standardserver. Die Einsparungen ergeben sich durch den schnelleren Aufbau einer kompletten Umgebung. Das Gesamtsystem ist etwa zwei Tage nach der Lieferung verfügbar, das heißt, die Hardware läuft und das Betriebssystem beziehungsweise die Datenbanksoftware sind installiert. Nach erfolgter Integration in Oracle Cloud Control, die je nach Kundenumgebung in einem halben Tag erledigt ist, kann mit dem Provisionieren der Software oder dem Aufsetzen der Datenbanken begonnen werden. Die Installation von Oracle-Middleware-Software wie SOA Suite oder WebCenter kann auf Basis von Templates oder Assemblies erfolgen, die Oracle zur Verfügung stellt. Hält man sich an den Enterprise Deployment Guide für Oracle Fusion Middleware, ist die Installation mit Cloud-Control-Automatisierung in wenigen Stunden erledigt.

Das ISE Oracle Technology Center Die Firma ISE Information Systems Engineering GmbH mit Firmensitz in Gräfenberg und Niederlassungen in Nürnberg und München betreibt das einzige Oracle-Exa-Stack-Test-Center mit Exadata, Exalogic und Exalytics in Deutschland. Es ist im modernsten 5-Sterne-Rechenzentrum Europas bei der noris network AG in Nürnberg untergebracht. Dort können Kunden die neuesten Oracle-Technologien, bestehend aus Hardware und Software, für ihre Einsatzzwecke evaluieren und die professionelle Beratung durch die ISEExa-Experten erfahren. Die Firma ISE wurde am 20. Januar 2014 mit dem renommierten Oracle Excellence Award Germany für das Jahr 2013 in der Kategorie „Engineered Systems“ ausgezeichnet. Dies ist bereits die zweite Auszeichnung innerhalb von drei Jahren; bereits im Jahr 2011 hat ISE den Oracle Exellence Award Germany in der Kategorie „Exadata“ erhalten.

DOAG News 02-2014

39

Aktuell

Der Enterprise Deployment Guide gibt vor, wie eine hochverfügbare Installation von Oracle Middleware Software erfolgen sollte. Voraussetzung ist, dass die Software Library des Cloud Control gefüllt ist. Somit kann man eine Woche nach Lieferung der Hardware mit den ersten Applikations-Deployments oder ersten Datenbank-Migrationstests starten. Das Lizenzmodell von Oracle-FusionMiddleware-Produkten für Exalogic basiert auf Trusted Partition. Dies bedeutet, es können Teile eines Servers lizenziert werden. In einer virtuellen Umgebung basiert der Core-Faktor auf virtuellen CPUs. Zwei virtuelle CPUs entsprechen einem physikalischen Core. Es muss maximal die Anzahl aller physikalischen Cores lizenziert werden.

Fazit Exadata und Exalogic X4-2 bieten viele größere und kleinere Neuerungen. Durch

die Erhöhung von Memory- und FlashSpeicher in der Exadata ist Oracle auf dem Weg zur In-Memory-Datenbank. Durch die zu erwartenden neuen In-MemoryFeatures der Version 12.1.0.3 und der X42-Hardware ist eine nochmalige deutliche Steigerung der Performance möglich. Die Virtualisierung der Exalogic ist mit der neuen Hardware und den neuen Features in Version 2.0.6 eine echte Alternative. Die Performance der Bare-Metal-Installation und der Virtualisierung durch die konsequente Verwendung des InfiniBand Stacks ist ohnehin konkurrenzlos. Die betrieblichen Möglichkeiten durch die Verwendung von Assemblies und erweiterten Installations-Features über Cloud Control sind im Rahmen von Oracle-Produkten ein weiteres Alleinstellungsmerkmal. Die DOAG veranstaltet am 14. Mai 2014 im ISE Oracle Technology Center den DOAG Exaday 2014, www.doag.org/go/exaday

Herbert Rossgoderer [email protected]

Matthias Fuchs [email protected]

Die neue Community-Plattform auf My Oracle Support Karl-Heinz Urban, ORACLE Deutschland B.V. und Co. KG

Am 31. Januar 2014 wurde die neue My-Oracle-Support-Community-Plattform für alle Benutzer freigegeben. Die durchgeführten Änderungen betreffen sowohl bereits existierende als auch neue Nutzer, die über die Community mit anderen interagieren. In den Communities ist es alternativ zum Öffnen eines Service Request möglich, seine Fragen zu stellen sowie auch auf gestellte Fragen zu antworten.

Der generelle Zugriff auf die Community hat sich nicht geändert. Er erfolgt wie gewohnt über den Tabulator „Community“ im My-Oracle-Support-Portal oder direkt über die URL „communities.oracle.com“. Basierend auf dem Feedback der Kunden und den Gemeinsamkeiten zwischen dem Oracle Technical Network (OTN) und der My-Oracle-Support-Community wurde die bestehende Plattform erweitert, um eine Koexistenz beider Communities in einer

40 www.doag.org

Oberfläche zu ermöglichen. Damit sind die Benutzer der My-Oracle-Community in der Lage, beide Communities in einer Oberfläche zu nutzen. Kunden ohne Wartungsvertrag steht dabei nur die OTNCommunity zur Verfügung. Die neue Community besteht aus zwei Kernelementen:

„Kommunikation“, „Aktionen“ und „Durchsuchen“ • Community Spaces Immer im unteren Teil der Seite mit den Tabulatoren „Übersicht“, „Inhalte“, „Personen“, „Unterbereiche“ und „Projekte“

Banner Information Immer oben auf der Seite mit den Tabulatoren „Startseite“, „Aktivität“,

Die Banner Information ist farblich anders, um ein leichtes Erkennen der Community zu ermöglichen. Die My-Oracle-

•

Aktuell

Abbildung 1: Die My-Oracle-Support-Community

Support-Community ist am blauen (siehe Abbildung 1) und die OTN-Community am roten Farbton (siehe Abbildung 2) zu erkennen. Über das „GO DIRECTLY TO“-DropDown-Feld in der rechten oberen Ecke der Seite kann man jederzeit zwischen den einzelnen Communities wechseln. Mit der Umstellung haben sich einige der bestehenden Begriffe wie folgt geändert: •

„Category” wurde umbenannt in „Spaces”

„Community” wurde umbenannt in „Sub-spaces” • „Subscribe” wurde umbenannt in „Follow” • „Thumbs Up” wurde umbenannt in „Like” •

Die Namen der „Spaces“ und „Sub-Spaces“ wurden beibehalten und sind die gleichen wie in der alten Oberfläche. Ein wichtiges Detail für alle Benutzer, die bereits in der My-Oracle-Support-Community aktiv sind:

Es wurden nur die bestehenden Abonnements zu einzelnen Themen und Dokumenten migriert. Die jeweiligen Spaces oder Sub-Spaces muss jeder Nutzer erneut suchen und durch Klicken auf den Button „Follow“ neu abonnieren. Der Begriff „Oracle Community“ ist ein generischer Begriff, um die Gemeinsamkeiten der My-Oracle-Support- und der OTN-Community zu identifizieren. In naher Zukunft wird sich der Titel in „Oracle Community“ ändern, da die einzelnen Ta-

Abbildung 2: Die OTN-Community

DOAG News 02-2014

41

Entwicklung

bulatoren wie „Startseite“, „Kommunikation“ und „Benachrichtigungen“ die gleichen Inhalte haben. Wichtig ist, dass die OTN-Community ein öffentliches Forum ist. Um einen Kontakt mit einem Support-Mitarbeiter über die Community herzustellen, ist darauf zu achten, dass der korrekte Space oder Sub-

Space in der My-Oracle-Support-Community ausgewählt ist. Der beste Weg, um die neue My-Oracle-Support-Community-Plattform kennenzulernen, liegt in seiner Benutzung. Bei Problemen in der Community empfiehlt sich der bekannte Weg, einen nicht-technischen Service Request zu eröffnen.

Karl-Heinz Urban [email protected]

Liquibase – Database Deployment in agilen Projekten Frank Winter, ORBIT Gesellschaft für Applikations- und Informationssysteme mbH

Moderne und agile Softwareentwicklungs-Projekte zeichnen sich unter anderem durch ein hochfrequentes Deployment aktualisierter Softwarestände auf Entwicklungs-, Test- und Produktivsysteme aus. Während es vergleichsweise unproblematisch ist, neue Versionen einer Software zu paketieren und auszuliefern, ist dies bei Datenbank-Änderungen deutlich schwieriger. Der Artikel zeigt die dabei auftretenden Herausforderungen sowie die passenden Lösungsansätze, die das Open-Source-Tool „Liquibase“ bietet.

Beim regelmäßigem Deployment von Datenbank-Änderungen (DDL und DML) stellen sich in den meisten Entwicklungsprojekten folgende Herausforderungen: Es sollen mit jeder Auslieferung nur Änderungen zu dem jeweils letzten Release eingespielt werden. Separate Installationsskripte sind bei kurzen Auslieferungszyklen jedoch aufwändig und fehleranfällig. • Wenn in verschiedenen Entwicklungssträngen parallel gearbeitet wird, ist die Version eines Datenbank-Schemas nicht immer eindeutig identifizierbar und es ist schwer, parallel entstandene Schema-Änderungen zusammenzuführen. • Datenbank-Änderungen werden oft gänzlich unabhängig von Code-Änderungen eingespielt. Das ist aber gefährlich. Code- und Datenbank-Änderungen gehören insbesondere bei einer •

42 www.doag.org

Continuous Delivery in eine gemeinsame Auslieferung. • Änderungen von Daten und Strukturen lassen sich nicht ohne Weiteres rückgängig machen. Wie geht man beispielsweise mit einem umfangreichen Änderungsskript um, das mittendrin abbricht? Welchen Zustand hat das Datenbank-Schema? Diese Herausforderungen lassen sich weitgehend mit der Open-Source-Library Liquibase in den Griff bekommen. Es handelt sich um ein datenbankunabhängiges Database-Change-Management-Tool und dient der Durchführung und Verwaltung aller Arten von Datenbank-Änderungen (DML und DDL). Änderungen, die über LiquibaseSkripte durchgeführt werden, lassen sich einfach verwalten und bei Bedarf weitgehend rückgängig machen. Liquibase benötigt in der aktuellen Version nur eine Java-

Laufzeitumgebung ab Version 1.6. Es eignet sich hervorragend für den Einsatz in agilen Projekten, da es sich sehr gut in eine Umgebung mit Continuous Integration beziehungsweise Continuous Delivery integriert. Liquibase baut über JDBC eine Verbindung zu einem bestimmten DatenbankSchema auf und führt dort eine beliebige Anzahl von Liquibase-Skripten (sogenannte „ChangeLogs“) aus (siehe Abbildung 1). Diese rufen entweder weitere ChangeLogs auf oder enthalten eine oder mehrere logisch in sich abgeschlossene DatenbankÄnderungen (sogenannte „ChangeSets“). Diese wiederum enthalten zumeist Datenoder Struktur-Änderungen, die entweder in einer Liquibase-spezifischen, datenbankunabhängigen Syntax (siehe unten) oder in datenbankspezifischem Code (wie PL/ SQL-Blöcke) formuliert sind. Sämtliche bereits durchgeführten Änderungen werden in dem betroffenen

Entwicklung

verwendeten XML-Format werden YAML, JSON und SQL unterstützt. Ein LiquibaseSkript besteht üblicherweise aus folgenden Bestandteilen: ChangeLog Der gesamte Inhalt des LiquibaseSkripts • ChangeSet Ein Satz logisch zusammenhängender Statements. ChangeSets werden nach der Ausführung in die Tabelle „DATABASECHANGELOG“ eingetragen (kombinierter Primärschlüssel aus „ID“, „AUTHOR“ und „FILENAME“). Ein ChangeSet kann seinerseits aus mehreren Changes bestehen. • Precondition Vorbedingung, die entweder für den ChangeLog oder ein ChangeSet gilt •

Abbildung 1: Zugriff von Liquibase auf Skripte und ein Datenbankschema

Spalte

Beschreibung

ID

Frei definierbare ID des ChangeSet. Muss gemeinsam mit den Feldern „AUTHOR“ und „FILENAME“ eindeutig sein

AUTHOR

Autor des Skripts

FILENAME

Pfad und Name des Skripts

DATEEXECUTED

Zeitpunkt der Ausführung

ORDEREXECUTED

Zähler für die Ausführungen

EXECTYPE

Ausführungstyp; meist „EXECUTED“ oder „RERAN“

MD5SUM

MD5-Hash je ChangeSet

DESCRIPTION

Automatisch generierte Beschreibung des ChangeSet, wie „Custom SQL“, „Create View“ oder „Add Column“ 

COMMENTS

Kommentar des Entwicklers zum ChangeSet

TAG

Optionale Markierung, etwa für ein bestimmtes Release; kann im Rollback verwendet werden

LIQUIBASE

Verwendete Liquibase-Version

Tabelle 1: Spalten der Tabelle DATABASECHANGELOG

Datenbankschema in der Tabelle 1 „DATABASECHANGELOG“ festgehalten, die zu jedem ChangeSet einen separaten Datensatz enthält. Damit ist Liquibase bekannt, welche Änderung erfolgreich durchgeführt wurde. Im Normalfall wird ein ChangeSet nur einmal ausgeführt. Es kann jedoch definiert werden, dass ein bestimmtes ChangeSet bei jeder Ausführung von Liqui­base neu gestartet wird (beispielsweise für die Durchführung von Grants zu neuen Datenbank-Objekten) oder dass es bei einer inhaltlichen Änderung erneut auszuführen ist (sinnvoll etwa bei Views oder Stored Procedures).

Die Liquibase-Skripte ChangeLogs lassen sich in verschiedenen Formaten definieren. Neben dem meist

Listing 1 zeigt ein einfaches Beispiel dazu. Es verwendet die Liquibase-spezifische Syntax für die Anlage einer neuen Spalte in einer Tabelle. Bei deren Verwendung kann Liquibase in vielen Fällen bei Bedarf automatisch das passende Rollback-Statement generieren (in diesem Falle also ein „DROP COLUMN“), um die Änderung wieder rückgängig zu machen. Liquibase bietet eine Vielzahl von Tags für die Durchführung von Datenbank-Änderungen. Die Dokumentation auf „www.liquibase.org“ ist gut verständlich und bietet zahlreiche Syntax-Beispiele. Listing 2 zeigt

Hinzufuegen der Spalte ORT in Tabelle DUMMY1 Listing 1

DOAG News 02-2014

43

Entwicklung

ein aus nur einem ChangeSet bestehendes Beispiel, in dem Oracle-spezifischer Code ausgeführt wird. Das Beispiel enthält zudem die Verwendung einer Precondition. Die Precondition prüft in diesem sehr einfachen Beispiel, ob es einen bestimmten Datensatz schon gibt. Ist dies der Fall, wird der ChangeSet nicht ausgeführt, aber als erfolgreich gelaufen markiert (onFail = „MARK_RAN“). Es wäre natürlich ebenso leicht möglich gewesen, das Skript kontrolliert abzubrechen (onFail = „HALT“). Bei der Verwendung von SQL-Tags () reicht Liquibase die enthaltenen SQL-Statements an die Datenbank durch und kann daher automatisch kein Rollback der Änderung generieren. Da die Verfügbarkeit eines Rollbacks dringend zu empfehlen ist, muss ein solches bei der Verwendung von SQL-Tags, wie im obigen Beispiel, explizit angegeben werden. Nur zur Klarstellung: Das Rollback (ob nun automatisch generiert oder manuell programmiert) ist nicht Bestandteil einer Fehlerbehandlung und der Abbruch eines Skripts bewirkt nicht das Ausführen des Rollback-Teils. Ein Rollback dient dem nachträglichen Zurückrollen aller Änderungen eines ChangeSets, um das Datenbank-Schema wieder auf einen älteren Stand zurückzusetzen.

Aufruf der Liquibase-Skripte Liquibase-Skripte lassen sich beliebig kaskadierend aufrufen. Wird Liquibase über die Kommandozeile gestartet, muss ein ChangeLogFile angegeben werden (etwa „update.xml“). Es handelt sich hierbei um einen gewöhnlichen ChangeLog, nur dass dieses meist keine ChangeSets enthält, sondern den Aufruf weiterer ChangeLogFiles. Listing 3 zeigt ein einfaches Beispiel für den Aufruf weiterer Liquibase-Skripte aus dem zentralen ChangeLogFile. Man kann sich die Arbeit erleichtern, indem man eine Datei namens „liquibase.properties“ (keine XML-Datei) anlegt, die alle für die JDBC-Connection notwendigen Attribute enthält (siehe Listing 4). Im einfachsten Fall kann man Liquibase nun über die Kommandozeile „liquibase --changeLogFile=update.xml update“ aufrufen. Es ist genau ein ChangeLogFile angegeben, das seinerseits kaskadierend beliebig weitere ChangeLogs aufruft. Li-

44 www.doag.org

select count(*) from DUMMY2 where UUID = 123 neuer Eintrag in Tabelle Dummy2 INSERT INTO DUMMY2(UUID) VALUES(123) delete from DUMMY2 where UUID = 123 Listing 2

… … Listing 3

#liquibase.properties driver: oracle.jdbc.OracleDriver classpath: /u01/app/oracle/product/11.2.0.3/dbhome_1/jdbc/lib/ ojdbc6.jar url: jdbc:oracle:thin:@myhost.acme.de:1521:oradb username: MYUSER password: geheimesPasswort Listing 4

Listing 5

quibase überprüft nun anhand der Einträge in der Tabelle „DATABASECHANGE­ LOG“, welche Änderungen aus den

gegebenenfalls zahlreichen ChangeLogs noch anstehen und führt nur diese aus. Tabelle 2 zeigt die wichtigsten Komman-

Entwicklung

Kommando

Beschreibung

Update

Führt eine Aktualisierung des Datenbank-Schemas durch.

updateSQL

Schreibt die SQL-Statements zur Aktualisierung des Datenbank-Schemas nach „STDOUT“. Diese SQLStatements werden nicht direkt ausgeführt, sollten aber in eine Datei umgeleitet und später angewandt werden.

updateTestingRollback

Führt eine Aktualisierung des Datenbank-Schemas durch, rollt diese Änderungen zurück, um sie dann wieder erneut auszuführen. Gut geeignet für den Test von Update und Rollback im Rahmen der Entwicklung.

rollback

Führt ein Rollback aller Änderungen durch, die neuer sind als das ChangeSet mit einem bestimmten Tag (siehe Attribut „Tag“ in Tabelle „DATABASE­CHANGE­LOG“).

rollbackToDate

Führt ein Rollback aller nach einem bestimmten Zeitpunkt durchgeführten Änderungen durch.

rollbackCount

Führt ein Rollback der letzten x ChangeSets durch.

clearCheckSums

Entfernt die Checksummen aus dem Feld „MD5SUM“ aus der Tabelle „DATABASE­CHANGE­LOG“.

diff \[diff parameters\]

Erzeugt einen Report über die Differenzen zwischen zwei Datenbank-Schemata.

diffChangeLog \[diff parameters\]

Erzeugt ein ChangeLogFile, dessen Ausführung die Differenzen zwischen zwei Datenbank-Schemata ausgleicht.

generateChangeLog

Generiert ein initiales ChangeLog aus einem bereits mit Datenbank-Objekten gefüllten DatenbankSchema.

Tabelle 2: Auswahl der wichtigsten Liquibase-Kommandos

dos, die sich über die Kommandozeile absetzen lassen (siehe „www.liquibase.org/ documentation/command_line“).

Verwendung von Variablen Interessant und in der Praxis meist auch notwendig ist der Einsatz von Variablen, die umgebungsspezifisch gesetzt sind. Diese werden meist in einer zentralen Datei definiert (zum Beispiel in einem ChangeLog-File namens „my_variables.xml“). Listing 5 zeigt die Definition von Variablen in einer solchen Datei. Einmal − möglichst in einer zentralen Datei − bekanntgegeben, werden solche Variablen nach dem Aufruf dieser Datei in allen weiteren LiquibaseSkripten mit der Schreibweise „${variablenname}“ referenziert. Dieses Feature ist besonders wichtig im Rahmen einer Continuous Delivery, da diese Variablen über Tools wie Puppet (siehe „http://puppetlabs.com“) je nach Umgebung automatisch unterschiedlich gesetzt werden können, ohne dass hier weiteres manuelles Eingreifen notwendig ist.

Weitere Liquibase-Features Liquibase kann noch mehr. Für die Generierung eines initialen ChangeLogs aus

einem bereits mit Datenbank-Objekten gefüllten Datenbank-Schema bietet Liquibase beispielsweise die Option „generateChangeLog“. Das damit generierte ChangeLog enthält die Definitionen eines Großteils der bestehenden Datenbank-Objekte (leider sind nicht alle Objekt-Typen unterstützt). Interessant ist unter anderem auch die Generierung von Diff-Skripten oder Diff-Reports, die den Unterschied zwischen zwei DatenbankSchemata beheben beziehungsweise dokumentieren.

dings gewisse Einschränkungen; zum Beispiel ist ein „DROP COLUMN“ nicht einfach durch ein „ADD COLUMN“ rückgängig zu machen. Im Oracle-Umfeld sollte man daher zusätzlich über die Verwendung sogenannter „Restore Points“ nachdenken.

Fazit Durch die eigenständige Protokollierung und Verwaltung, welche Datenbank-Änderungen im Rahmen einer Auslieferung bereits gelaufen sind und welche noch laufen müssen, ist Liquibase ein sehr nützliches Tool in agilen Projekten, bei denen häufige Auslieferungen stattfinden. Gerade in Entwicklungs- und TestUmgebungen spielen darüber hinaus die Rollback-Möglichkeiten eine wichtige Rolle, da auf diese Weise auch der datenbankseitige Teil einer Applikation wieder in ein älteres Release zurückversetzt werden kann. Hierbei gibt es aller-

Frank Winter [email protected]

DOAG News 02-2014

45

Datenbank

Reference Partitioning in der Praxis Dr. Frank Haney, Haney IT

Oracle führt mit jedem Release neue Features ein. Der Anwender muss diese auf Sinn und Praktikabilität testen. Der Artikel beschreibt das für die mit der Version 11g eingeführte Funktion „Reference Partitioning“.

Die Partitionierung gehört zur physischen Datenbank-Implementierung und ermöglicht eine für die Applikationen völlig transparente Aufteilung der Daten auf getrennte Bereiche, die bei Bedarf wiederum verschiedenen Tablespaces und damit Datendateien und Laufwerken zugeordnet werden können. Daraus ergeben sich vor allem bei großen Tabellen zwei wesentliche Vorteile, die so bekannt sein sollten, dass sie hier noch nicht einmal im Detail erklärt werden müssen: Performance-Gewinn durch Partition Pruning Bei einer Datenbankabfrage muss in Abhängigkeit vom Prädikat nicht mehr die ganze (große) Tabelle, sondern nur noch ein Teil, nämlich eine bestimmte Anzahl von Partitionen gelesen werden. Bei Joins ermöglicht die Partitionierung der beteiligten Tabellen anhand des Join-Attributs partitionsweise Joins. • Erleichterte Pflege Die Verwaltung großer Tabellen mit DML macht häufig Schwierigkeiten, weil dabei große Mengen an Redo und Undo generiert werden, was wiederum die Performance beeinträchtigt. Partitionierte Tabellen können mit DDL-Befehlen verwaltet werden (Hinzufügen, Löschen, Zu•

sammenführen und Splitten von Partitionen). Das ist wesentlich effektiver. Oracle hat im Laufe der Zeit drei grundsätzlich unterschiedliche Partitionierungsmöglichkeiten eingeführt:

Intervall-Partitionierung Dies ist eine Form der Range-Partitionierung, bei der sich der Administrator nicht mehr um das rechtzeitige Anlegen neuer Partitionen kümmern muss. Wenn zum Beispiel im neuen Monat der erste Datensatz eingefügt wird, legt das System automatisch eine neue Partition an. • Virtuelle Spalten Diese können als Partitionierungsschlüssel verwendet werden. • Reference-Partitionierung Gegenstand der folgenden Ausführungen. •

Range-Partitionierung (seit Version 8) Die Daten werden entsprechend bestimmter aufeinanderfolgender Bereiche, zum Beispiel bezüglich des Datums, also nach Tagen, Wochen, Monaten oder Jahren, aufgeteilt. Diese Form der Partitionierung ergibt aber nur Sinn, wenn die Aufteilung der Daten auf die Bereiche möglichst gleichmäßig erfolgt. • Hash-Partitionierung (seit Version 8i) Wenn sich die Daten nicht gleichmäßig auf Bereiche aufteilen lassen, dann ist eventuell eine Aufteilung auf HashPartitionen sinnvoll. Das erfolgt, indem auf den Partitionierungsschlüssel eine Hash-Funktion angewendet wird. Das ist für die Abfrageperformance jedoch nur sinnvoll, wenn die Daten mit Gleichheitsprädikat abgefragt werden. • List-Partitionierung (seit Version 9i) Der vorgesehene Partitionierungsschlüssel verteilt sich einigermaßen gleichmäßig auf eine überschaubare Menge von Werten. •

Abbildung 1: Das Datenmodell schematisch am Beispiel

46 www.doag.org

Dazu gibt es diverse Erweiterungen wie die Index-Partitionierung und die Möglichkeit diverser Kombinationen von SubPartitionierung. Mit Version 11g sind drei wichtige Ergänzungen eingeführt worden:

Ausgangssituation im Projekt Eine Datenbank dient der Messwerterfassung bei der Produktion von Solarmodulen. Mithilfe selbstgeschriebener Skripte wurden dort bestimmte Tabellen Range-partitioniert und diese Partitionierung verwaltet. Das ganze Verfahren war ziemlich inkonsistent und fehlerträchtig. Das zeigte sich insbesondere bei Erweiterungen des Datenmodells. Dieses muss man sich in etwa

Datenbank

so vorstellen: Neben wenigen unabhängigen Tabellen gibt es eine Master-Tabelle, die gewissermaßen sternförmig von ca. 90 anderen Tabellen referenziert wird. Dabei handelt es sich sowohl um 1:n- als auch um 1:1-Beziehungen. Die Master-Tabelle enthält eine ContextID für den einzelnen Messpunkt und dazu einen Zeitstempel. Von den abhängigen Tabellen werden dieser ContextID Messwerte zugeordnet, die im Verlauf des Produktionsprozesses entstehen. Die Referenz erfolgt also über die ContextID und nicht über den Zeitstempel. Es wurde eine Range-Partitionierung nach ContextID vorgenommen, allerdings wurde das nicht konsequent für alle abhängigen Tabellen reproduziert, was die Verwaltung nicht gerade vereinfacht hat. Entweder musste man vor dem Löschen von Partitionen in der Master-Tabelle in den nichtpartitionierten Detail-Tabellen abhängige Datensätze mit DELETE entfernen oder auf Fremdschlüssel-Constraints verzichten, was eventuell die Integrität der Daten beeinträchtigen konnte. Außerdem mussten Partitionen auf Vorrat angelegt werden, da nur ungefähr bekannt war, wie viele ContextID-Einträge pro Zeiteinheit generiert werden. Es gab auch kein Partition Pruning für zeitbasierte Abfragen. Die Idee war nun, die Verwaltung des ganzen Konstrukts durch eine Reference-Partitionierung zu vereinfachen, wobei sich der Zeitstempel als Partitionierungsschlüssel anbot.

Reference-Partitionierung Kurz gesagt, handelt es sich bei Reference-Partitionierung um die Partitionierung entlang von Fremdschlüsselbeziehungen. Die abhängigen Tabellen werden nach dem gleichen Kriterium wie die Master-Tabelle partitioniert, ohne dass sie den Partitionierungsschlüssel explizit enthalten müssen. Im vorliegenden Beispiel bedeutet das eine Partitionierung nach der Reporttime und nicht nach der ContextID. Die Vorteile dieser neuen Möglichkeit, Tabellen zu partitionieren, sind: •

Tabellen mit Master-Detail-Beziehungen können gleich partitioniert werden, ohne dass der Partitionierungsschlüssel in der abhängigen Tabelle dupliziert werden muss.

Wartungsmaßnahmen an der Partitionierung der Master-Tabelle werden automatisch in die abhängigen Tabellen kaskadiert, was die Wartung sehr vereinfacht und Erweiterungen des Datenmodells konsistenter und weniger fehleranfällig macht. • Partitionsweise Joins funktionieren auch, wenn das Join-Attribut nicht der Partitionierungsschlüssel ist. • Reference-Partitionierung ist auch sinnvoll für die Partitionierung von Nested Tables. •

Zunächst wird die Master-Tabelle wie üblich angelegt (siehe Listing 1), dann die abhängigen Tabellen (Beispiel: Listing 2). Dabei ist Folgendes zu beachten: Die Fremdschlüsselspalten dürfen keine „NULL“ enthalten und müssen daher explizit als „NOT NULL“ deklariert sein. • Damit man die Reference-Partitionierung in der Detail-Tabelle deklarieren kann, muss man die FremdschlüsselConstraints benennen. •

Diese Fremdschlüssel dürfen nicht ausgeschaltet („disable“) sein. • Darüber hinaus dürfen diese Constraints nicht auf transaktionsbezogene Prüfung („DEFERRABLE“) gestellt sein. • Eine abhängige Tabelle kann Referenzen in mehrere Master-Tabellen besitzen. Für die Reference-Partitionierung kann allerdings nur immer eine verwendet werden. • Eine kaskadierende Reference-Partitionierung ist möglich. •

Im Projekt waren folgende Fragen zu beantworten: Gibt es in den abhängigen Tabellen Datensätze, die „NULL“ in der Fremdschlüsselspalte enthalten? Das war der Fall. Es zeigte sich aber, dass das wenige Datensätze aus einer Teststellung waren, die gelöscht werden konnten. • Sind alle Fremdschlüsselspalten „NOT NULL“ deklariert? Das war nicht der Fall und musste nachgeholt werden. •

CREATE TABLE master ( contextid NUMBER(*,0) NOT NULL, reporttime TIMESTAMP (6) NOT NULL, CONSTRAINT master_pk PRIMARY KEY (contextid)) partition by range (REPORTTIME) ( partition dez2013 values less than ( to_date( '1.1.2014', 'dd. mm.yyyy') ), partition jan2014 values less than ( to_date( '1.2.2014', 'dd. mm.yyyy') ), partition maxpart values less than (maxvalue)); Listing 1

CREATE TABLE detail ( contextid NUMBER(*,0) NOT NULL, materialid NUMBER(*,0) NOT NULL, , CONSTRAINT detail_context_fk FOREIGN KEY (contextid) REFERENCES master (contextid)) PARTITION BY REFERENCE (detail_context_fk); Listing 2

DOAG News 02-2014

47

Datenbank

Waren Fremdschlüssel-Constraints auf „DEFERRABLE“ gestellt? Nein, es musste also kein Eingriff in die Applikationslogik vorgenommen werden. • Waren die Fremdschlüssel-Constraints benannt? Das war nicht der Fall. Abgesehen davon, dass es gute Praxis ist, Constraints zu benennen, ergibt sich sonst ein unlösbarer Widerspruch: Für die Reference-Partitionierung benötigt man den Namen des Constraint. Den erfährt man jedoch vom Dictionary erst nach Anlegen der Tabelle, falls man ihn nicht selber explizit vergeben hat. • Auf welchem Wege konnten das Datenmodell und die Daten in die neue Struktur migriert werden? Dazu im folgenden Abschnitt mehr. •

•

•

•

• •

•

•

Ansonsten war das Datenmodell durch seine flache Hierarchie und die nahezu ausschließliche Referenz auf eine MasterTabelle gut für die Reference-Partitionierung geeignet.

• • •

Migration des Datenmodells und der Daten Grundsätzlich gibt es zwei Migrations-Methoden. Erstens online mithilfe des Package „DBMS_REDEFINITION“. Dies war leider im vorliegenden Fall nicht möglich, weil es sich um das Datenbank-Release 11.2.0.3.0 handelt. Bei diesem gibt es jedoch infolge des Fixes für Bug 9777229 den Bug 13572659, in dessen Konsequenz während der Redefinition die Fremdschlüssel ausgeschaltet werden; das widerspricht einer der Voraussetzungen für die Reference-Partitionierung. Der Bug ist in 11.2.0.3.4 und natürlich in 12.1.0.1 gefixt. Der Ablauf ist in etwa folgender:

Anlegen einer Interimstabelle für die Master-Tabelle (gleiche Struktur, aber neuer Name) ohne Constraints, aber mit der neuen Partitionierung nach dem Zeitstempel Abschalten aller Fremdschlüssel-Constraints, die auf die Master-Tabelle zeigen Überprüfen, ob die Online-Redefini­tion möglich ist mit „Dbms_Redefinition. Can_Redef_Table“ Start der Redefinition mittels „DBMS_ REDEFINITION.start_redef_table“ Transfer der Constraints auf die Interimstabelle mit „dbms_redefinition. copy_table_dependents“ Eventuelle Synchronisation der beiden Tabellen über „dbms_redefinition. sync_interim_table“ Statistiken für die neue Tabelle sammeln Beenden der Redefinition mit „dbms_ redefinition.finish_redef_table“ Löschen der alten Tabelle, die jetzt den Namen der Interimstabelle hat Dieser Vorgang wird für die abhängigen Tabellen wiederholt, wobei hier die Interimstabellen mit Reference-Parti­ tioning angelegt werden

Noch ein Hinweis: Wenn die abhängigen Tabellen keinen Primärschlüssel haben, was beim gegebenen Datenmodell teilweise der Fall war, dann muss die Redefinition mit der „ROWID“-Methode erfolgen. Die zweite Möglichkeit der Migration ist offline durch Neuanlegen des Datenmodells mit Reference-Partitionierung und anschließendem Import der Daten aus einem aktuellen Dump. Dem kam im Projekt entgegen, dass ohnehin eine größere Produktions-Downtime geplant war. Beim Import

waren die Abhängigkeiten zu berücksichtigen. Er wurde im Modus „DATA_ONLY“ und in mehreren Schritten durchgeführt.

Wartung der Partitionierung Durch die Reference-Partitionierung erleichtert sich die Verwaltung der Tabellen enorm. Alle Wartungsmaßnahmen werden allein an der Master-Tabelle durchgeführt, weil beispielsweise „SPLIT PARTITION“ und „DROP PARTITION“ direkt an die abhängigen Tabellen propagiert werden. An der Master-Tabelle müssen diese Befehle manuell oder durch ein Skript ausgeführt werden. Im Projekt wird das durch einen Job realisiert, der regelmäßig läuft, die MaxPartition splittet und für den kommenden Monat eine neue Partition anlegt. Durch die Reference-Partitionierung muss das jeweils nur für die Master-Tabelle gemacht werden. Zum Löschen alter Partitionen gibt es derzeit noch keine konkreten Vorstellungen. Das ist allerdings genauso einfach. So viel zum Stand in der Version 11g R2. Dort war es noch nicht möglich, Reference-Partitionierung mit Intervall-Partitionierung zu kombinieren, was jetzt in 12c geht. Dazu braucht man in dem Code-Beispiel nur die RANGE-Partitionierung durch die Spezialform Intervall-Partitionierung ersetzen (siehe Listing 3). An der Definition der abhängigen Tabellen ändert sich nichts. Zunächst werden entsprechend dem Partitionierungsschlüssel Datensätze in die vordefinierten „RANGE“-Partitionen eingefügt. Wenn dieser Bereich überschritten wird, kommt die Intervall-Partitionierung ins Spiel. Immer wenn ein Datensatz eingefügt wird, der in das nächste Intervall fällt, wird automatisch vom System eine neue Partition angelegt; das wird dann in die abhängi-

CREATE TABLE master ( contextid NUMBER(*,0) NOT NULL, reporttime TIMESTAMP (6) NOT NULL, CONSTRAINT master_pk PRIMARY KEY (contextid)) partition by range (reporttime) INTERVAL (NUMTOYMINTERVAL(1,'month')) (Partition dez2013 values less than ( to_date( '1.1.2014', 'dd.mm.yyyy')), partition jan2014 values less than ( to_date( '1.2.2014', 'dd.mm.yyyy'))); Listing 3

48 www.doag.org

Datenbank

gen Tabellen propagiert. Es gibt folgende Überlegungen zur Performance: Wartungsmaßnahmen wie „SPLIT PARTITION“ sollten möglichst präventiv ohne vorhandene Daten durchgeführt werden. Speziell im vorliegenden Fall, bei mehr als 90 abhängigen Tabellen in der Reference-Partitionierung, führt das sonst zu erheblichen Blockierungen (Ereignis „enq: TM – contention“). In Oracle 12c lässt sich das natürlich durch die Kombination mit IntervallPartitionierung lösen. Da diese Möglichkeit in 11g noch nicht verfügbar ist, wurde das mit einem Job realisiert. • Alle Operationen, die zur Bewegung von Zeilen führen, sind mit allergrößter Vorsicht und nach entsprechenden Tests zu verwenden. Das betrifft insbesondere Updates von Partitionierungsschlüsseln in der Master-Tabelle, die zu massenhaften Updates der abhängigen Tabellen führen – ungeachtet der •

Tatsache, dass man dazu „ROW MOVEMENT“ einschalten muss, wenn sich dadurch die Partition ändert. Solche Updates sind auch mit der Gefahr von Deadlocks verbunden. • Das Entfernen alter Daten durch „DELETE“ sollte möglichst vermieden werden. Dafür sollten konsequent die DDLBefehle der Partitionierung („DROP PARTITION“) genutzt werden. • Die Fremdschlüsselspalten, über die die Reference-Partitionierung realisiert wird, sollten indiziert werden. Darüber hinaus ist die Indizierung der abhängigen Tabellen mit Bedacht vorzunehmen.

Tabellen auf eine Master-Tabelle referenziert. Dazu sind einige Voraussetzungen wie die Deklaration der Fremdschlüsselspalten als „NOT NULL“ zu erfüllen. Mit der Version 12c vereinfacht sich das Ganze noch einmal, weil es möglich wird, Reference-Partitionierung mit Intervall-Partitionierung zu kombinieren. Ergänzt sei noch, dass Reference-Partitionierung auch mit Hash- oder List-Partitionierung kombinierbar ist.

Fazit Mit der Reference-Partitionierung hat Oracle eine Möglichkeit eröffnet, in bestimmten Situationen die Einrichtung und Wartung der Partitionierung deutlich zu vereinfachen. Allerdings sollte das Datenmodell nicht beliebig komplex sein. Günstig ist, wenn sich die Vielzahl der abhängigen

Frank Haney [email protected]

DOAG News 02-2014

49

Industrialisierte Oberflächenentwicklung mit Oracle ADF Ralf Ernst, Bundesagentur für Arbeit, und Andreas Koop, enpit consulting OHG

Während sich in den letzten Jahren im Bereich des Backend eine immer effizientere und industrialisierte Entwicklung von Komponenten auf Basis diverser etablierter Frameworks wie Spring, EJB3, JPA oder WebServices etabliert hat, folgt die Entwicklung von graphischen Benutzeroberflächen (GUIs) immer noch vielfach einem eher individuellen „Arts and Craft“-Anspruch. Eine Industrialisierung der Entwicklung von GUIs ist aber ebenso notwendig wie machbar.

Voraussetzung für die Industrialisierung der Entwicklung von GUIs sind weitgehend die Standardisierung der Benutzeroberfläche, eine verbindliche Referenzarchitektur und die Automatisierung wiederkehrender Gestaltungsaufgaben. Dieser Artikel beschreibt Motivation, Voraussetzungen und Vorgehen für die Einführung einer industrialisierten Oberflächenentwicklung bei der Bundesagentur für Arbeit (BA) auf Basis von Oracle ADF. Das IT-Systemhaus der BA betreibt eine der größten IT-Systemlandschaften Deutschlands. Neben Standardsoftware für Client-zentrierte Office-Funktionalitäten, einem ERP-System für Auszahlungen und Verwaltung sowie einer Business- Intelligence-Plattform für statistische Auswertungen zählen hierzu rund 100 zentralisierte Applikationen mit zusammen mehr als 10.000 Masken auf Basis von

50 www.doag.org

Java EE beziehungsweise C++/Corba, die die spezielle Geschäftslogik der BA und somit ihr eigentliches Kerngeschäft implementieren. Die mehr als 100.000 Benutzer müssen zur Erledigung ihrer Geschäftsprozesse oft eine Vielzahl von Anwendungen nutzen. Neben der Neuentwicklung sogenannter „Rollen-basierter Oberflächen“ für spezielle Geschäftsprozesse in ServiceCentern und Eingangszonen mussten verschiedene geschäftskritische ältere Verfahren auf Basis von C++/Corba und Java EE modernisiert und aktuelle Anforderungen der Fachseite mit Neuentwicklungen realisiert werden. Eine Analyse der bestehenden GUI-Architekturen und Entwicklungsprozesse ergab folgende Ergebnisse: •

Auch durch den Einsatz heterogener Technologien und Frameworks (C++,

Swing, JSP, JSF) bedingt, existierten weder ein einheitliches „Look & Feel“ noch einheitliche Bedienmuster der BA-Anwendungen. Dies erschwerte den Benutzern die Aufgabenerledigung erheblich und forderte von ihnen einen teilweise erheblichen Einarbeitungsaufwand. • Auf Entwicklungsseite existierte im Gegensatz zum Backend für die Entwicklung von GUIs weder eine gültige Referenz-Architektur noch ein definierter Entwicklungsprozess. Entwickler von webbasierten GUIs mussten oft eine Vielzahl von Technologien und Frameworks beherrschen und integrieren (wie Struts, JSP, JavaScript, CSS, HTML). • Die Ziel-Architektur aktueller WebFrameworks unterscheidet sich in hohem Maße voneinander. Vergleicht man die Architektur von beispielswei-

Entwicklung

se JavaScript-basiertem HTML5, JavaFX oder JSF, findet man kaum Gemeinsamkeiten. Im Gegensatz zu tieferen Applikationsschichten hat sich auch noch kein definierter Industriestandard entwickelt, was schon die schier unüberblickbare Vielfalt von GUI-Frameworks und Technologien verdeutlicht. Daher fehlen vielfach auch Entwicklungsmuster und Best Practices zu Themen wie Data-Binding, State-Handling oder Event-Processing.

Erwartungen an Benutzeroberflächen und GUI-Technologien Die Erwartungen von Benutzern, IT-Architekten und dem Management an Benutzeroberflächen und deren Technologien sind sehr unterschiedlich. Benutzer vergleichen heutzutage die Oberfläche ihrer Unternehmensanwendung mit Anwendungen, die sie tagtäglich im Internet benutzen. Im Zuge dieser „Consumerization of Information Technology“ definiert das Internet also mittlerweile, wie eine moderne Benutzeroberfläche auszusehen hat. Ein populäres Beispiel hierfür ist die

einfache Google-Suche und deren AutoVervollständigungsmechanismus. Ein weiterer Begriff, der in diesem Zusammenhang gebraucht wird, ist „joy of use“. Platt ausgedrückt soll der Anwender bei der Bedienung einer Benutzeroberfläche Freude haben. Die Bedienung einer Anwendung soll also intuitiv und vorhersehbar sein. Anstelle spezieller Lösungen und Tricks sind eine Beschränkung der Anzahl möglicher Bedienmuster (Master-Detail, Autocomplete, etc.) auf das unbedingt Notwendige und eine leicht durchschaubare einheitliche Navigationsstruktur, die sich konsistent in allen Anwendungen wiederfindet, ein Schlüssel für benutzerfreundliche Oberflächen. Schließlich muss eine GUI in der BA den aktuellen Erfordernissen und Gesetzen zur Barrierefreiheit genügen, also auch von (seh-)behinderten Benutzern problemlos bedienbar sein. IT-Architekten erwarten auch von der GUI-Technologie ein hohes Maß an Wiederverwendbarkeit im Kontext einer ansonsten serviceorientierten Architektur. Dies beinhaltet die Integration mit bestehenden Architekturen ebenso wie die

Unterstützung künftig mehr prozessorientierter Applikationen. Eine zukunftsorientierte GUI-Technologie muss im Intranet wie im Internetportal auf verschiedensten Endgeräten lauffähig sein. Eine saubere Trennung und damit Entkopplung der einzelnen Schichten einer Applikation („separation of concerns“) sowie ein komponentenorientierter Ansatz sind hierfür Voraussetzungen. Aus Sicht des Managements bemisst sich der Geschäftswert einer Applika­tion sehr stark an der Benutzeroberfläche. Aufgrund der in der BA üblichen langen Produktlebenszyklen (ca. 10 Jahre) muss eine GUI-Technologie zukunftssicher und über diesen langen Produktzyklus unterstützbar sein. In dieser Zeit müssen Provisionierung der Anwendung sowie Weiterentwicklung und Wartung kostengünstig möglich sein.

Ein industrialisierter Ansatz für die Oberflächenentwicklung Industrialisierung bedeutet in der IT nichts anderes als die möglichst weitgehende Standardisierung von Lösungen und die

Abbildung 1: Standardisierte Seitenbereiche des BA-Design-Guides

DOAG News 02-2014

51

Entwicklung

Abbildung 2: Vom Photoshop Screendesign zur ADF-Anwendung

Automatisierung wiederkehrender Aufgaben. Im Kontext der UI-Entwicklung erfolgte die Standardisierung durch die Definition eines sowohl für die IT als auch den Bedarfsträger verbindlichen Design-Guides, der das Aussehen, den Aufbau, die Navigationsstruktur und die möglichen Interaktionselemente festlegte. Daneben erfolgte die Definition einer Referenzarchitektur für UIs und die Produktauswahl des zukünftig einzigen Frameworks für die Implementierung – Oracle ADF. Um sicherzustellen, dass die entsprechenden Design-Vorgaben auch umgesetzt und nicht im Zuge der Entwicklung neuer Applikationen konterkariert würden, wurden Anreize in Form eines zentralen BA-Skins geschaffen, zentrale Vorlagen und vorgefertigte UI-Komponenten für wiederkehrende Gestaltungsmuster der Masken bereitgestellt. Diese Maßnahmen sollten ein „Baukasten-ADF“ (BADF) und eine Referenzarchitektur schaffen, um eine Standardisierung grundlegender Aufgabenstellungen wie Data-Binding, State-Handling und Event-Processing über verschiedene IT-Projekte hinweg zu ermöglichen. Darüber hinaus war ein einheitliches Tooling zu entwickeln, das Deployment, Staging und automatisierte GUI-Tests unterstützt.

52 www.doag.org

Der BA-Design-Guide Der BA-Design-Guide wurde unter Führung des Bedarfsträgers, also der Fachabteilung der Zentrale der BA, entwickelt. Die Fachabteilung definierte, wie die zukünftigen Benutzeroberflächen – bereitgestellt durch das IT-Systemhaus – aussehen und was diese leisten. Insoweit fungiert der BA-Design-Guide auch als wichtiges Kommunikationsmedium zwischen IT und Fachabteilung für künftige Anwendungen, da er die möglichen

UI-Elemente und Interaktionsmuster aller BA-Anwendungen enthält und von der Fachabteilung quasi als Katalog für künftige Anwendungen genutzt werden kann, was die Formulierung von Fachkonzepten und Anforderungen an die IT wesentlich vereinfacht. Das Team zur Definition des BA-DesignGuides setzte sich neben einem UX-Experten größtenteils aus fachlichen Analysten und Anwendern zusammen. Ziel war die Definition eines allgemein verwendeten

Abbildung 3: Mapping der Seiten-Fragmente auf korrespondierende, wiederverwendbare Templates

Entwicklung

Abbildung 4: POJO-Binding

Anwendungsrahmens und einer generischen Navigationsstruktur sowie die Reduktion möglicher Interaktionsmuster auf das unbedingt notwendige Maß (siehe Abbildung 1). Begleitet wurde das Team von zwei technischen Experten, die zur generellen technischen Machbarkeit der Vorschläge und Entwürfe Stellung nahmen. Neben allgemeinen Regelungen zur Ergonomie und Barrierefreiheit definiert der BA-Design-Guide nunmehr einen standardisierten Seitenaufbau in Header, Kontext-Navigation, Kontext-Information, Navigationsbereich und Inhaltsbereich sowie ein einheitliches Navigationskonzept.

Abbildung 5: Bestandteile des BADF-Toolkits

Die Standardisierung des Inhaltsbereichs erfolgte durch sogenannte „Gestaltungsmuster“, die die gewünschte Funktionalität optimal unterstützen. Ziel hierbei war wiederum, so wenige Gestaltungsmuster wie möglich zu verwenden, um für den Anwender konsistente, wiedererkennbare Oberflächen auch über verschiedene Anwendungen hinweg zu garantieren. Gestaltungsmuster definieren die verschiedenen Formulare und Tabellen-Ansichten (wie Master-Detail, Command-Link, 2-spaltiges Formular etc.) innerhalb des Inhaltsbereichs einer Seite. Darüber hinaus wurden Aussehen und Verhalten von Interaktionskomponenten

(input-fields, lists, enumerations, choices, texts, buttons etc.) modifiziert, um die gewünschte Funktionalität zu unterstützen, und zuletzt die gewünschte Darstellung von Meldungs- und Fehlerdialogen zu spezifizieren. Die in Photoshop entworfenen Maskenfragmente wurden dann in korrespondierende ADF-Templates übernommen. Mittels ADF-Skinning war das gewünschte „Look & Feel“ exakt realisierbar (siehe Abbildung 2).

Die Produktauswahl Als GUI-Framework für die Implementierung des BA-Design-Guides wurde Oracle ADF ausgewählt. Für diese Lösung sprach insbesondere, dass mit Technologien wie wiederverwendbaren und zentral mittels ADF Library provisionierbaren Templates in Verbindung mit Skinning die Vorgaben des Design-Guides nahezu „1:1“ umsetzbar waren. Daneben konnte mit dem Konzept der Dynamic-Tabs die Forderung der Fachseite erfüllt werden, verschiedene Kontexte (mehrere Kundendaten, Prozesse etc.) in verschiedenen Bereichen der Anwendung zugleich laufen zu lassen (siehe Abbildung 3). Daneben war aus Sicht der gewünschten Standardisierung wichtig, dass ADF eines der wenigen GUI-Frameworks am Markt ist, dass in sich komplett und vollständig ist, also ohne zusätzliche Erwei-

DOAG News 02-2014

53

Entwicklung

Abbildung 6: Screenshot eines Entwicklungsprojekts mit BADF in einer sehr frühen Phase

terungen, Funktionalitäten wie Ajax, Server-Push und ein mit nativen Clients vergleichbares Dialog-Framework bietet. Es wird kein zusätzlicher, manuell zu implementierender JavaScript-Code für diese Funktionalitäten benötigt. Von den in ADF enthaltenen JavaScript-Funktionalitäten wird vollständig abstrahiert. Ein modularer Aufbau der GUI wird durch wiederverwendbare Controller mit integrierter Zustandsverwaltung und definierten Schnittstellen und den sogenannten „Contextual-Events“ zur losen Kopplung einzelner Seitenregionen ermöglicht. Vorteilhaft war auch die native Integration von ADF Taskflows in das WebCenter-Portal, auf dessen Basis der Internetauftritt der BA (siehe „http://arbeitsagentur.de“) realisiert ist. Die Zukunftsfähigkeit von Oracle ADF ist durch die JSF-Renderer gegeben, da ausgehend vom selben Sourcecode völlig unterschiedliche Codes je nach Endgerät und Browser erzeugt werden können. So wird mittlerweile – ohne Änderung des Quellcodes – bei Zugriff von einem Tablet HTML5 gerendert, wo vor wenigen Jahren noch Flash-Artefakte erzeugt wurden. Außerdem existieren spezielle

54 www.doag.org

Renderer zur Unterstützung von Tools für Sehbehinderte wie Lunar und Jaws. Wichtiges Kriterium für die BA war auch die Tatsache, dass Oracle-Produkte wie der Enterprise Manager oder die Fusion Apps vom Hersteller selbst in ADF implementiert werden, da sich die BA hiervon eine kontinuierliche Weiterentwicklung und Langzeit-Support verspricht. Die zwischenzeitlich erfolgte Vorstellung von ADF Mobile bestätigt diese Annahme. Zuletzt steht mit dem JDeveloper auch eine IDE zur Verfügung, die eine WYSIWYG-Entwicklung in Verbindung mit den zentral bereitgestellten Komponenten erlaubt.

Die Referenz-Architektur Das Framework Oracle ADF implementiert den JSF-Standard und basiert auf dem etablierten MVC-Pattern für GUIs. Die ModelSchicht innerhalb von ADF, die von den darunterliegenden Daten-Services abstrahiert, wird von Oracle auf die Zusammenarbeit mit dem proprietären, objektrelationalen Mapping-Framework ADF Business Components optimiert. Da in der BA jedoch standardmäßig POJOs als DTOs vom EJBoder WebService-Backend zur GUI-Schicht

verwendet werden, wurde das Binding entsprechend angepasst (siehe Abbildung 4). Alle Oberflächenabläufe werden als Bounded Taskflow auf Basis von JSFPage-Fragmenten implementiert. Jeder Taskflow – mit definierten Ein- und Ausgabe-Parametern – ist dabei für die potenzielle Wiederverwendung in anderen Applikationen per ADF Library einsetzbar. Wiederverwendbare Teile einzelner Seitenfragmente werden wiederum als deklarative Komponenten implementiert. Soweit notwendig, werden Referenzen auf UI-Komponenten im View-, Request- oder BackingBean-Scope zu ihren Backing-Beans gebunden. Der eigentliche UI-State wird je nach Anwendungsfall mittels Managed Beans im PageFlowoder Session-Scope gehalten. Ein weiterer wichtiger Grundsatz ist, kein HTML-Markup in den JSF-Seiten zu verwenden, da ansonsten die durch den jeweiligen JSFRenderer gegebene Plattform-Unabhängigkeit verloren gehen kann.

BADF Das Baukasten-ADF (BADF) implementiert den BA-Design-Guide auf Basis der Refe-

Entwicklung

renz-Architektur. Motivation für dieses Toolkit war, die Umsetzung der DesignVorgaben zu vereinfachen und deren Implementierung zu vereinheitlichen. Grundfunktionalitäten wie die Navigation (Reiter/Baum-Navigation) und auch der grundlegende Seitenaufbau werden durch JSF-Templates und deklarative UI-Komponenten geliefert. Das Exception-Handling wiederum wird durch sogenannte „Taskflow-Templates“ zentral sichergestellt. Sämtliche Templates, deklarative UI-Komponenten und Skins sind zentral mit ADF-Libraries bereitgestellt und stehen den Entwicklern im JDeveloper sofort zur Verfügung. Es gibt zwei Skins für interne BA-Anwendungen, einschließlich optimierter Ausgabe für Sehbehinderte (insbesondere im Hinblick auf Farbkontraste und Schriftgröße). BADF implementiert die Referenz-Architektur bezüglich Binding und Zustandsverwaltung von Java POJOs, EJBs und Web-Services, liefert Supportklassen für Contextual Events und enthält Basisklassen für immer wiederkehrende Fälle wie z.B. Exception Handling oder spezielle Konverter beziehungsweise Validatoren. Ferner existiert eine Security-Integration mit einem eigenen OPSS-Provider, basierend auf JAAS und einer Security-Bean für den komfortablen Zugriff per EL-Ausdrücken in JSF-Seiten. Abbildung 5 zeigt einen Überblick über die wesentlichen Bestandteile des BADF-Toolkits. Zuletzt wurde eine Werkzeugstraße für den zentralen Integrationsprozess auf Basis von Hudson, ojdeploy, Sonar und automatisierte Tests bis hin zum Deployment auf WebLogic Servern implementiert. Bei Bedarf kann eine textuelle DSL verwendet werden, um GUI-Masken zu spezifizieren. Der generierte Code nutzt die BADF-Artefakte, um Design-Guide-konforme Oberflächen zu erzeugen.

Fazit Mittlerweile sind drei Projekte mithilfe des Design-Guides und BADF erfolgreich realisiert und in Produktion. Einige weitere Projekte sind aktuell kurz vor dem „GoLive“. Oracle ADF „als Enabler“ hierfür hat in den letzten beiden Jahren erheblich an Reife gewonnen und die Benutzerakzeptanz ist gut. Die Vereinheitlichung der Benutzeroberflächen unterschiedlicher Verfahren mit dem Design-Guide und BADF hat sich bewährt. Änderungen am Design-Guide können zentral durch Anpassungen der Page-Templates und des Skins vorgenommen werden und gelten für alle Produkte und Projekte, die BADF nutzen. Die gewählte Referenz-Architektur unterstützt dabei sowohl prozessunterstützende Anwendungen sowie traditionelle CRUD-Anwendungen. Schon zu Beginn der Entwicklung ist das spätere Zieldesign klar erkennbar, wie Abbildung 6 verdeutlicht. Zusammenfassend bleibt festzuhalten, dass eine industrialisierte GUI-Entwicklung durchaus möglich ist. Voraussetzungen hierfür sind eine größtmögliche Standardisierung der Benutzeroberfläche, die Einhaltung einer strikten Referenzarchitektur und die weitgehende Automatisierung der Implementierung von wiederkehrenden Gestaltungsmustern. Der gewünschte Standardisierungsgrad kann nur zusammen mit der die IT beauftragenden Fachabteilung gelingen, da hierdurch natürlich die Gestaltungsmöglichkeiten einer Anwendung – gewollt – eingeschränkt werden. Dies nahm die Fachabteilung der BA angesichts der Vorteile wie massiver Kostenersparnis in der Entwicklung und einer durch die Vereinheitlichung optimierten Benutzerfreundlichkeit (intuitiv, sauber, leicht erlernbar) in Kauf. Die IT erreicht außer einer signifikanten Verringerung des Entwicklungs-

aufwands bei der Entwicklung von GUIs auch die Vereinfachung von Test und Betrieb sowie verbesserte Supportmöglichkeiten im Fehlerfall und erheblich verringerte Aufwände bei Weiterentwicklung und Pflege im zukünftigen ApplikationsLifecycle. Oracle ADF fungierte bei diesem Vorgehen als Enabler, die Konzepte des BADesign-Guides waren hiermit vollständig und exakt umsetzbar. Eine Übertragbarkeit des in der BA gewählten Ansatzes hängt allerdings insbesondere von der Kundenbasis und der Anzahl und Größe der zu unterstützenden Applikationen ab und sollte keinesfalls als allgemeingültig verstanden werden.

Ralf Ernst [email protected]

Dipl.-Inf. Andreas Koop [email protected]

Bring your own Device soll mit neuer Oracle Mobile Security Suite sicherer werden Oracle hat auf dem Mobile World Congress in Barcelona seine neue Oracle Mobile Security Suite vorgestellt. Damit können Organisationen dem Trend „Bring you own Device“ (BYOD) nachgehen, ohne Zugeständnisse bei der Sicherheit machen zu müssen. Die Oracle Mobile Security Suite ermöglicht den sicheren Zugriff auf sensible Unternehmens-

anwendungen und Daten auf gängigen mobilen Endgeräten und bietet eine integrierte Plattform, von der aus Organisationen die Zugriffsverwaltung von allen Endgeräten, darunter Laptops, Desktop-Rechner und andere mobile Geräte, auf alle Anwendungen vornehmen können. Darüber hinaus stellt der Arbeitsbereich eine komplette Lösung

für die mobile Anwendung bereit. Darin sind Single Sign-on, eigenes Netzwerk-Tunneling für jede Anwendung, Verschlüsselung der gespeicherten Daten, native Integration mit Microsoft Active Directory für eine gemeinsame Nutzung, ein Katalog mit Unternehmensanwendungen und ein Transformations-Tool enthalten. DOAG News 02-2014 55

Oracle & SAP

SAP nach dem Ausfall: Best Practices zum Wiederanlauf komplexer Systeme Franz Diegruber, Libelle AG

Um die Verfügbarkeit heutiger SAP-Systeme sicherstellen zu können, reicht es nicht mehr aus, Datenbanken und Datenbankinhalte verfügbar und sicher zu machen. SAP-Systemumgebungen bestehen mittlerweile aus einem komplexen Konglomerat von Komponenten, die in verschiedenen Abhängigkeiten zueinander stehen.

Insbesondere mit der Nutzung der SAPNetWeaver-Funktionalität, die aus dem J2EE-Stack resultiert, wird die Komplexität durch eine Zunahme an Abhängigkeiten und Komponenten weiter vergrößert. Ein zusätzlicher Treiber der Komplexität ist, dass mittlerweile die Geschäftsprozesse verteilt über verschiedene Systeme ablaufen und somit insbesondere ein Wiederanlauf der Systeme Fragen über deren Konsistenz und auch deren Wiederanlaufszenarien aufwirft. Klassische Übernahmeverfahren und Methoden zur Sicherstellung der Betriebsvitalität funktionieren hierbei nicht mehr oder nur noch eingeschränkt.

RPO, RTO und RCO Klassisch bemisst sich die Qualität von Wiederanlauf- beziehungsweise DisasterRecovery-Szenarien mit den Größen der Recovery Point Objective (RPO), also wie viel Datenverlust im Fehlerfall tolerierbar ist, sowie mit der Recovery Time Objective (RTO), also wie lange der Wiederanlauf dauert. Diese Kriterien werden dabei allerdings auf der Basis einzelner Systeme und nicht nach dem Verlauf der Geschäftsprozesse definiert. Die Verteilung der Daten und deren Datenentität über eine Vielzahl von Systemen in Kombination mit einer ganzheitlichen Betrachtung der Daten über die Geschäftsprozesse stellt die IT vor die Herausforderung, Daten systemübergreifend konsistent wiederherstellbar zu machen. Das Prinzip der Logical Units of Work (LUWs) funktioniert originär jedoch

56 www.doag.org

nur innerhalb abgeschlossener Datenumfelder wie der jeweiligen Datenbanken. Schnittstellendaten sowie Daten in Filesystemen besitzen größtenteils keinen transaktionalen Konsistenz-Algorithmus. Die Erzeugung einer GesamtsystemKonsistenz ist somit unter ganzheitlicher Betrachtung von Datenbanken, Filesystemen und Schnittstellen besonders schwierig. Konsistenz muss quantifizierbar und überprüfbar hinterlegt und umgesetzt werden. Eine Angabe über Recovery Time Objective (RTO) und Recovery Point Objective (RPO), die auf der Basis einzelner Systeme definiert und errechnet werden, ist aus Sicht der Geschäftsprozesse nicht ausreichend. Eine Cross-System-Datenintegrität muss definiert und umgesetzt sein. Hierzu definiert die Recovery Consistency Objective (RCO) über alle Systeme hinweg die benötigten Konsistenz-Anforderungen (siehe Abbildung 1). Im Detail beschreibt die RCO die erlaubte Abweichung wiederhergestellter Datenbestände nach einem Systemvorfall. Sie gibt somit an, wie groß der Unterschied der Geschäftsdaten-Basis verteilt über die beteiligten Systeme sein darf, sowohl qualitativ als auch quantitativ. Dabei sind für alle an einem Geschäftsprozess beteiligten Systeme sowohl die durch LUWs abgesicherten Daten in einer Datenbank als auch die Daten in Filesystemen und Schnittstellen zu berücksichtigen. Insbesondere bei externen Schnittstellen wie etwa in Logistik-Systemen ist eine solche systemübergreifende Datenkonsis-

tenz von entscheidender Bedeutung. Ist die RCO für die Logistikprozesse wesentlich kleiner als 100 Prozent, entspricht die Wahrnehmung im System nicht mehr der Wirklichkeit. Das bedeutet, dass sowohl quantitative (wie aktuelle Lagerbestände) als auch qualitative Informationen (wie aktueller Standort der Ware) aufwändig nachgearbeitet werden müssten. In gleichem Zusammenhang verwendete unkritische Daten (wie Telefonnummer eines Kunden) können mit einem wesentlich geringeren RCO auskommen, da diese in Relation einfacher nachpflegbar sind und der Verlust bzw. eine Inkonsistenz keinen wesentlichen geschäftlichen Schaden verursacht. Besonders wichtig ist es, im Verlauf der Requirement-Analyse für die Katastrophenvorsorge die richtigen Anforderungen für RPO, RTO und RCO zu definieren. Fragt man den Geschäftsbereich nach der RPO für den Katastrophenfall, bekommt man im ersten Moment immer die Aussage, dass kein Datenverlust tolerierbar sei. Unter diesen Bedingungen ist zu beachten, dass eine solche Anforderung für einen tatsächlichen Katastrophenfall sich zum größten Teil eher im Bereich von 10 bis 30 Minuten bewegt. Bei einer tatsächlichen Katastrophe, wir sprechen hier vom Brand eines Datacenters, Explosionen, Flugzeugunglücken ist ein Datenverlust von 30 Minuten meist das kleinere Problem. Der Wiederanlauf des Geschäfts, Zugang für Mitarbeiter zu den Daten, Arbeitsplätze für Mitarbeiter und insbesondere der Wiederanlauf der Geschäfts- und

Oracle & SAP

Abbildung 1: RPO, RTO und RCO

IT-Prozesse sind wesentliche und weitere kritische Bestandteile eines Wiederanlaufs von ganzen Rechenzentren.

Evolutionäre Entwicklung einer Katastrophenvorsorge Um Geschäftsprozesse in der heutigen Zeit richtig abzusichern, ist es notwendig, dass die Vorsorgelösung sich zyklisch an die sich ändernden Bedürfnisse anpasst. Von entscheidender Bedeutung ist schon in der Phase der Identifizierung der kritischen Geschäftsprozesse und Systeme eine Klassifizierung und Gruppierung dieser nach den Verfügbarkeits- und Konsistenzkriterien. Eine typische Klassifizierung in diesem Rahmen kann durch folgende Klassen beschrieben werden: (D) Vitale Business-Daten (wie SAP ERP) (I) Interfaces und Schnittstellen-Systeme (wie SAP PI) • (B) Business-Unterstützungs-Systeme (wie BOBJ) • (S) Support-/Infrastruktur-Systeme (wie SAP SolMan) • (E) End User (wie SAP EP) • •

In der Requirement- und Solution-DesignPhase wird die Lösung vom generischen Ansatz bis hin zu Systemen und deren Ab-

hängigkeiten runtergebrochen; auf der Basis wird dann die Infrastruktur-Architektur für die Katastrophenvorsorge erstellt. Die Business-Continuity-Prozesse und die Infrastruktur werden zu einer integrierten Lösung verbunden, um im Wiederherstellungsfall die Qualität der Prozesse, Abläufe und Technologie sicherzustellen (siehe Abbildung 2). Die Implementierung rollt das Design für die Systeme aus, während in der RunPhase die Systeme betrieben werden. Ein wichtiger Bestandteil in der Run-Phase sind zyklische Tests der Lösung. Diese sollten mindestens einmal jährlich durchgeführt werden, um die eingesetzte Technologie, Dokumentation und Prozesse zu prüfen. Die Verifikation der Lösung sollte in einem Zyklus von drei bis fünf Jahren erfolgen. Der Scope dieser Verifikation ist es, die Implementation erneut gegen die Geschäftsprozesse zu mappen. Sobald die Lösung den Anforderungen der Geschäftsprozesse nicht mehr gerecht wird, muss die Lösung den Zyklus erneut durchschreiten.

SAP ganz klassisch Die klassische Implementierung eines SAP-Systems umfasst die Installation ei-

ner Datenbank, einer SAP Central Instance und optionaler SAP Application Server. Dieses Konzept basiert auf der SAP ABAP Engine, die alle Daten und Funktionen in der korrespondierenden Datenbank ablegt. Soll eine solche SAP-Umgebung verfügbar gemacht werden und in der Lage sein, sowohl logischen als auch physikalischen Fehlern entgegenzuwirken, ist es notwendig, die zentrale Komponente – die SAP-Datenbank – abzusichern. Eine solche Absicherung kann etwa mit der DBShadow-Technologie erfolgen. Bei einer solchen Absicherung sind alle Single Points of Failure (SPOFs) in Abhängigkeit ihrer Priorität und ihres Einflusses auf die Verfügbarkeit des SAP-Systems mit einer farblichen Markierung versehen, wobei die roten Markierungen die zentrale Vitalität des SAP-Systems im Fall der Übernahme darstellen. Ist nur die Datenbank in einer SAP-Umgebung gespiegelt, werden noch nicht alle wesentlichen SPOFs des SAP-Systems nachhaltig gesichert. Weitere SPOFs wie die SAP Central Instance mit Abhängigkeiten an eine IPAdresse beziehungsweise an einen Hostnamen und auch das Filesystem, das unter anderem die Profile und Parameter, die Job Logs sowie die Executables des SAP-Systems enthält und typischerweise

DOAG News 02-2014

57

Oracle & SAP

durch ein NFS-Share allen untergeordneten Application-Servern zur Verfügung gestellt wird, sind in dieses Übernahme- und Verfügbarkeits-Verfahren nicht integriert. Eine vollständige Absicherung der SAPUmgebung erfolgt somit ausschließlich dann, wenn die folgenden Elemente im Übernahmeszenario berücksichtigt sind: SAP-Datenbank SAP ABAP Central Services (Bestandteil der Central Instance wie ENQ, MSG etc.) • SAP-Filesystem und dazugehöriger NFS-Share • IP-Adresse für SAP ABAP Central Services • •

Typischerweise ist die Änderungsrate im klassischen Filesystem der SAP nicht groß, auch das Starten und Stoppen der SAP Central Instance inklusive der Übernahme der IP-Adresse und Hostnamen ist von der Durchführungskomplexität im Prinzip gering. Deswegen erfolgen in einigen Installationen eine Übernahme des Filesystems und der IP-Adresse sowie das Starten der SAP Central Instance manuell. Diese Lösung ist allerdings nicht empfehlenswert, wenn sich mehrere Systeme in einem Ver-

Abbildung 2: Die Projektphasen

58 www.doag.org

bund befinden oder ein komplexes Übernahmeszenario existiert. Aus diesem Grund sollte die SAP-Umgebung in ein Szenario überführt werden, das sowohl die Komponenten zur Spiegelung der Datenbank enthält als auch solche, die für die Absicherung des Filesystems und der SAP Central Services sorgen. Eine Absicherung des Filesystems für SAP kann beispielsweise mittels FSShadow erfolgen und hiermit analog zur zeitversetzten Spiegelung der Datenbank. Dabei wird der entsprechend für die Datenbank definierte Zeitversatz auch auf das Filesystem angewendet, um eine zeitliche Konsistenz für Datenbank und Filesystem, insbesondere für die Job-Logs, zu erzeugen. Eine Umschaltintegration der VIP und des virtuellen Hostnamen zum Beispiel mittels SwitchApplication gewährleistet ein problemfreies Management und Umschaltverfahren sowohl bei Ausfällen als auch bei der Systemwartung auf den entsprechenden Knoten. Dies garantiert eine durchweg hohe Verfügbarkeit des SAP-Systems.

SAP mit J2EE Eine neue Herausforderung stellt die Implementierung eines SAP-Systems auf Basis der aktuellen SAP-NetWeaver-Pro-

duktlinie dar. Der J2EE-Stack, auch JavaStack genannt, fügt nicht nur einen neuen Stack an Komponenten in die Umgebung ein. Damit wird auch die bisher bekannte Vorgehensweise, alle für die Anwendung benötigten Programme und Daten innerhalb der Datenbank vorzuhalten, aufgebrochen. Für die Ausführung des SAP-Systems benötigte Logik wird ab sofort mit dem J2EE-Stack auch im Filesystem vorgehalten. Dies weist dem Filesystem von nun an eine zentrale Rolle beim Erhalt der Vitalität der SAP-Systemumgebung zu. Zusätzlich zu den klassischen Systemkomponenten gilt es somit, die folgenden Bestandteile des J2EE-Stacks entsprechend in die Verfahren der Hochverfügbarkeit und Disaster-Vorsorge zu integrieren: SAP J2EE Central Services (Bestandteil der Central Instance wie ENQ, MSG etc.) • SAP J2EE Filesystem für JAR Files und dazugehöriger NFS-Share • IP-Adresse für SAP J2EE Central Services •

Bei der Absicherung der J2EE-Komponenten kommt das gleiche Verfahren zum Einsatz, das auch schon bei der vollständigen Absicherung des ABAP-Stacks genutzt

Oracle & SAP

wird. Die Architektur einer Verfügbarkeitsumgebung, die sowohl ABAP- als auch J2EE-Stack integriert, sichert das zentrale Filesystem mittels FSShadow analog der Datenbank mit Zeitversatz auf die sekundäre Seite ab. Insbesondere beim J2EEStack ist die zeitliche Gleichschaltung der Datenbank und des Filesystems von Bedeutung, da sich vitale und sich ändernde Bestandteile im Filesystem befinden. Manuelles Kopieren oder ein Kopieren ohne Zeitversatz sind hierbei nur die zweitbeste Lösung, die im Fall einer Übernahme zu gravierenden Komplikationen beim Start und Betrieb des Notfallsystems führen kann. Eine integrierte Umschaltung und Übernahme der IP-Adressen und Hostnamen erfolgt analog zur ABAP-Umgebung, etwa mittels SwitchApplication. Zusätzlich zu den hier gezeigten Komponenten ist eine Absicherung des SAP Web Dispatcher, sofern dieser zum Einsatz kommt, sowie des Software Deployment Manager (SDM) erforderlich. Diese Integration des Web Dispatcher kann ebenfalls durch SwitchApplication erfolgen. Ob eine Absicherung des SDM erfolgen muss oder dieser ausschließlich über „Cold Standby“Lösungen abgesichert wird, hängt vom Änderungsvolumen und der Dringlichkeit der entsprechenden Änderungen für den Betrieb der SAP-Systeme ab. Weiterführend gehören gegebenenfalls genutzte zusätzliche Komponenten von SAP-Landschaften in ein ganzheitliches Konzept für Verfügbarkeit und Katastrophenvorsorge. Unter anderem sind in bestimmten Installationen TREX (Suche), das System Landscape Directory (SLD), das Enterprise Portal (EP) und die Process Integration (PI), um nur einige zu nennen, von elementarer Bedeutung. Generell gilt jedoch, dass die gezeigten Verfahren für diese Komponenten mit leichter Abwandlung angewandt werden können.

Failover ORA Activation • SAP Start • Final Switch • Verification • •

Der Ablauf integriert eine Notification für alle betroffenen Beteiligten nach einem Disaster. Die Umschaltung wird durch Pre-Check vorbereitet und stellt sicher, dass alle benötigten Komponenten erreichbar sind. Der Failover erfolgt durch die Libelle für alle Systeme. Ist eine RCO über unterschiedliche Systeme notwendig, muss an dieser Stelle der Konsistenzpunkt über alle Systeme definiert werden. Nach der Umschaltung sollte die OracleDatenbank auf deren Vitalität überprüft werden, um anschließend SAP zu starten. IP-Adressen und Hostnamen werden dabei mit übernommen. Anschließend ist das SAP-System zu verifizieren und an die User freizugeben. Falls möglich, sollte ein Backup eingeplant werden, um eine Wiederaufsetzbarkeit der Systeme zu gewährleisten.

Fazit Eine Absicherung von SAP-Systemen für den Katastrophenfall kann generell durch unterschiedliche Technologien gewährleistet werden. Um die Umsetzung den Anforderungen der SAP-Systeme gerecht werden zu lassen, ist ein entscheidendes Kriterium, dass man einen ganzheitlichen Ansatz für die Katastrophenvorsorge wählt. Die Schritte einer Umschaltung sollten dabei auf einer DIN-A4-Seite zusammenfassbar sein, um die Möglichkeit des Auftretens einer Fehlbedienung in solchen Fällen so klein wie möglich zu halten.

Best Practices: ÜbernahmeWorkflow eines SAP-Systems Die Übernahme eines SAP-Systems im Katastrophenfall sollte nach einer streng definierten Methode erfolgen. Als Best Practices hat sich folgender Workflow bewährt: • •

Notification Preparation

Franz Diegruber [email protected]

DOAG News 02-2014

59

Hidden Secrets

Oracle Hidden Secret: DNFS Cloning Sebastian Solbach, ORACLE Deutschland B.V. & Co. KG

Es ist weitestgehend bekannt, dass Oracle seit der Datenbank-Version 11g einen NFS-3-Client in die Binärdateien implementiert hat. Dagegen schon eher ein Hidden Secret ist, dass diese NFS-Implementation eine Snapshot-Funktionalität besitzt, die optimal geeignet ist, um die Datenbank zu Testzwecken zu klonen, auch wenn das darunterliegende NAS-System Snapshots nicht unterstützt.

Diese Snapshot-Funktionalität hat beim 11g-Launch keine große Beachtung erfahren. Mit der Version 12c rückt diese Technologie aber wieder in den Fokus, da es in Verbindung mit Pluggable Databases durchaus um effiziente Cloning-Mechanismen geht und damit dem DNFS Clone auch wieder mehr Bedeutung zukommt. Aber auch mit existierenden 11g-Umgebungen hat diese Funktion viele Anwendungsfelder.

Direct NFS (DNFS) Direct-NFS- beziehungsweise DNFS-Funktionalität ist die optimale Anbindung für Network Attached Storage (NAS) wie einer ZFS-Appliance, die per NFS angebunden ist. DNFS ersetzt für die Binärdateien den betriebssystemeigenen NFS-Client oder ergänzt, wie im Falle von Windows, das Betriebssystem um einen zertifizierten NFS-Client für die Oracle-Datenbank. DNFS bietet dabei erhebliche Performance-Verbesserungen: Diese werden einerseits durch die Eliminierung des Be-

60 www.doag.org

triebssystem-NFS-Layers bei einem Datenbank-Storage-Zugriff erreicht, andererseits wird eine bessere Performance dadurch erzielt, da der Storage nun über bis zu vier Pfade angesprochen werden kann (bei betriebssystemeigenen NFS-Clients nur zwei). Beim Einsatz von NFS-Storage und einer 11g-Datenbank empfiehlt es sich also, in jedem Fall DNFS einzusetzen. Neben den Performance-Vorteilen bietet DNFS, wie schon erwähnt, noch eine weitere wichtige Funktion: DNFS Clone − die Möglichkeit, eine Datenbank zu Testzwecken zu klonen. Hierbei wird nicht, wie bei einem „RMAN DUPLICATE“, die komplette Datenbank kopiert, sondern es kommt die „Copy on Write“-Technologie zum Einsatz, um lediglich geänderte Blöcke festzuhalten. Damit ist ein DNFS Clone nicht nur schnell erzeugt, sondern nimmt auch relativ wenig Plattenplatz ein. Schaut man sich die Implementation näher an, stellt man fest, dass diese Funktionalität auch zur Verfügung steht, wenn die Produktiv-Datenbank selbst nicht auf NFS liegt.

Einrichtung DNFS unter 11g Grundsätzlich können die Dateien einer Datenbank lokal im Filesystem, in ASM oder auf einem NFS-Filer liegen. Liegen sie auf NFS, wird normalerweise dieses Filesystem über den betriebssystemeigenen NFS-Client gemountet und erlaubt somit den Zugriff auf Datendateien, als ob es sich um ein lokales Dateisystem handelt. Direct NFS erlaubt es nun, dass das Oracle Executable ohne den Umweg über den NFS-Client des Betriebssystems selbst direkt auf dieses NFS-Filesystem zugreifen kann. Hierzu muss der notwendige NFS-Client-Code im Oracle Executable aktiviert sein. Wenn alle Voraussetzungen erfüllt sind, reichen der Standard-NFS-Eintrag für Oracle-Datenbank-Dateien in der Datei „/etc/fstab“ und ein „make -f ins_ rdbms.mk dnfs_on“ aus (siehe Listing 1). Unter 12c ist dieser Schritt nicht mehr notwendig, da hier der Default „dnfs_on“ ist. Anmerkung: Neu bei 12c ist auch, dass nun externe Tabellen mit DNFS angespro-

Hidden Secrets

chen werden können. Davon profitiert auch der SQL Loader. Wie die Anbindung eines NFS-Filers mit DNFS im Detail funktioniert, steht in der MOS Note DNFS: „Example About How To Setup DNFS (Direct NFS) On Oracle Release 11.2 [ID 1452614.1]“. Die Einsatzmöglichkeiten und Vorteile von DNFS sind im Whitepaper „Oracle Direct NFS Client with Oracle Database 11g Release 1“ beschrieben. Zum Testen von DNFS und Ausprobieren des DNFS Clone ist allerdings kein

NAS-Storage notwendig, es kann auch ein normaler Linux Server/Openfiler oder ein anderer Software-NFS-Server verwendet werden. Dies ist von Oracle zwar für den produktiven Einsatz nicht unterstützt, zum Testen reicht es aber. Zum Einrichten eines NFS-Servers stehen im Internet viele Anleitungen, auch Oracle hat eine simple Beschreibung im Zusammenhang mit DNFS: „Step by Step − Configure Direct NFS Client (DNFS) on Linux (11g) [ID 762374.1]“.

$ cd $ORACLE_HOME/rdbms/lib $ make -f ins_rdbms.mk dnfs_on rm -f /opt/oracle/product/11.2.0.3/db/lib/libodm11.so; cp /opt/oracle/product/11.2.0.3/db/lib/libnfsodm11.so /opt/oracle/ product/11.2.0.3/db/lib/libodm11.so Listing 1

rman target sys/oracle@orcl RMAN> BACKUP AS COPY DATABASE FORMAT ′/opt/oracle/backup/%U′; Listing 2

sqlplus sys/oracle@orcl SQL> ALTER DATABASE BACKUP CONTROLFILE to TRACE;

Direct NFS Clone − ein Backup als Grundlage Basis für ein DNFS Clone ist immer ein Backup, also ein RMAN-Backup oder ein Snapshot eines Storage-Systems. Dieses Backup muss über NFS erreichbar sein und erklärt auch, warum die ProduktivDatenbank nicht auf NFS liegen muss. Für DNFS Clone muss kein eigenes Backup angelegt sein, es kann jedes vollständige Backup via Image-Kopie herangezogen werden. Ein Cold-Backup ist ebenso als Grundlage möglich wie ein Hot-Backup einer Datenbank im Archivelog-Modus. Möchte man explizit ein Backup für DNFS Clone via RMAN anlegen, so könnte dies über den Befehl „BACKUP AS COPY DATABASE FORMAT“ erfolgen (siehe Listing 2). Dabei entsteht auf „/opt/oracle/backup“ eine Image-Kopie. Es wird davon ausgegangen, dass „/opt/oracle/backup“ ein Verzeichnis eines NFS-Filers ist, das auf dem Testserver unter „/nfsmount“ gemountet wird. Zum Testen würde es auch reichen, dieses Verzeichnis mithilfe eines NFS-Shares zu exportieren, also dafür zu sorgen, dass es von einem NFS-Client gemountet werden kann. Es muss aber hier explizit erwähnt werden, dass dies nicht von Oracle unterstützt wird. Damit die Test-Datenbank erzeugt werden kann, muss sie ein Controlfile besitzen. Dieses

Listing 3

$ cp /opt/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_2413.trc createclonecontrolfile.sql $ vi createclonecontrolfile.sql STARTUP NOMOUNT CREATE CONTROLFILE REUSE SET DATABASE “CLONE“ RESETLOGS ARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 292 LOGFILE GROUP 1 ′/nfsmount/backup/clone/redo01.log′ SIZE 50M BLOCKSIZE 512, GROUP 2 ′/nfsmount/backup/clone/redo02.log′ SIZE 50M BLOCKSIZE 512 DATAFILE ′/nfsmount/backup/data_D-ORCL_I-1340774340_TS-SYSTEM_FNO-1_04o7cn44′, ′/nfsmount/backup/data_D-ORCL_I-1340774340_TS-SYSAUX_FNO-2_03o7cn3a′, ′/nfsmount/backup/data_D-ORCL_I-1340774340_TS-UNDOTBS1_FNO-3_05o7cn4t′, ′/nfsmount/backup/data_D-ORCL_I-1340774340_TS-USERS_FNO-5_07o7cn5d′ CHARACTER SET AL32UTF8 ; Listing 4

DOAG News 02-2014

61

Entwicklung

Controlfile wird aus der Primär-Datenbank erzeugt (siehe Listing 3). Der Befehl liefert ein SQL-Skript zum Erzeugen der Controlfiles für die Clone-Datenbank. Das erzeugte Trace sieht man im „alert.log“ der Datenbank und findet sich unter „$ADR_BASE/ rdbms///trace/“. Das darin stehende SQL sollte nun für die Backup-Datenbank angepasst werden: Der Datenbankname wird geändert, die Datendateien sollten auf die Backupdateien verweisen und für die Redologs ein neues Verzeichnis verwendet werden (siehe Listing 4). Das Keyword „SET“ ist dabei zusätzlich hinzuzufügen und wichtig, weil sonst dieses Kommando fehlschlägt, da der Datenbankname nicht zum Header der Datendateien passt. Damit die Datenbank gestartet werden kann, kopiert man am einfachsten das SPFile der Primär-Datenbank und ändert entsprechende Parameter. Hierzu gehören insbesondere die Parameter „Audit_file_dest, db_recovery_file_dest“, „diagnostic_dest“ und „control_files“. Neu ist auch der „init.ora“-Parameter „CLONEDB“, der auf „TRUE“ gesetzt sein sollte, da ansonsten der Klon mit einem „ORA-01511“ und „ORA-01141“ fehlschlägt. Listing 5 zeigt das Beispiel einer „initclone.ora“; die wichtigsten Änderungen sind rot markiert. Danach kann die Datenbank mit dieser „initclone.ora“ gestartet und das Create Controlfile ausgeführt werden (siehe Listing 6). Anschließend kommt der eigentliche Teil, den DNFS Clone zu aktivieren. Hierzu wird für jede einzelne Datendatei ein Klon erzeugt (siehe Listing 7). Dieser Befehl erzeugt nun die „Copy on Write“-Snapshot-Dateien. Sie müssen sich explizit ebenfalls in einem Verzeichnis befinden, das über DNFS angesprochen wird. Lokale Dateien sind nicht möglich. Dass diese Dateien kaum Platz brauchen, erkennt man nur mithilfe des Linux-Befehls „du“. Die Dateien werden erst dann größer, wenn sich etwas an den Datendateien ändert. Hat es sich beim Backup um ein HOTBackup gehandelt, sind für die geklonten Datendateien ein Recovery und ein „open resetlogs“ notwendig. Da jedoch im neu erstellten Controlfile keine Informationen zu den Backups von Archivelogs enthalten

62 www.doag.org

db_name=′CLONE′ memory_target=512M processes = 150 audit_file_dest=′/opt/oracle/admin/clone/adump′ audit_trail =′db′ db_block_size=8192 db_domain=′′ db_recovery_file_dest=′/opt/oracle/fast_recovery_area′ db_recovery_file_dest_size=2G diagnostic_dest=′/opt/oracle′ dispatchers=′(PROTOCOL=TCP) (SERVICE=ORCLXDB)′ open_cursors=300 remote_login_passwordfile=′EXCLUSIVE′ undo_tablespace=′UNDOTBS1′ control_files = (/nfsmount/backup/clone/clone.ctl) compatible =′11.2.0′ clonedb = TRUE Listing 5

sind, wird der „RECOVER“-Befehl nach den entsprechenden Archivelogs fragen (siehe Listing 8). Ab nun steht die Test-Datenbank zur Verfügung und man kann mit dieser arbeiten. Dabei werden nur Änderungen an den Datenfiles in den geklonten Files gespeichert und die Original-Backup-Dateien bleiben bestehen. Dies lässt sich gut anhand der Zeitstempel beziehungsweise der Dateigrößen beobachten. Selbstverständlich erlaubt dieses Feature auch das Anlegen mehrerer Test-Datenbanken auf denselben Dateien. Wenn man die Test-Datenbank nicht mehr benötigt, löscht man einfach deren Files. Dies hat keine Auswirkungen auf die Produktion oder das Backup der Produktion. Das Backup hingegen sollte nicht gelöscht werden, da sonst die Test-Datenbanken nicht mehr funktionieren. In der MOS Note „Clone your dNFS Production Database for Testing [ID 1210656.1]“ ist zusätzlich zu einem weiteren Beispiel auch ein Perl-Skript enthalten, das den Clone-Prozess automatisiert und das Umbenennen der Dateien damit vereinfacht. Die Funktionalität des DNFS Clone bietet eine schnelle, platzsparende und günstige Variante, Testdatenbanken aufzusetzen.

Links und Referenzen

[1] Oracle Direct NFS Client with Oracle Database 11g Release 1: http://www.oracle.com/technetwork/articles/directnfsclient-11gr1-twp-129785.pdf

[2] Note ID 1210656.1: Clone your dNFS Production Database for Testing [3] Note ID 1452614.1: DNFS: Example About How To Setup DNFS (Direct NFS) On Oracle Release 11.2 [4] Note ID 762374.1: Step by Step - Configure Direct NFS Client (DNFS) on Linux (11g) [5] DBA Community Tipp: Direct NFS Clone − Klonen der Oracle Datenbank zum Testen, http://tinyurl.com/dba_community

Sebastian Solbach [email protected]

Alle weiteren Listings finden Sie online unter: http://www.doag.org/index. php?id=1719

Aus dem Verein

Aus dem Verein

Dr. Dietmar Neugebauer Vorstandsvorsitzender der DOAG

DOAG-Delegiertenversammlung entlastet den Vorstand und beschließt stärker themenorientierte Ausrichtung des Vereins Am 14. März 2014 fand die zweite DOAG-Delegiertenversammlung in Düsseldorf statt. 47 Delegierte nahmen zunächst die Jahresberichte des DOAG-Vorstandsvorsitzenden Dr. Dietmar Neugebauer sowie der Community-Leiter Dr. Frank Schönthaler (Business Solutions), Christian Trieb (Datenbank), Robert Szilinski (Development & BI) und Björn Bröhl (Infrastruktur & Middleware) entgegen. Daraufhin berichtete Dr. Dietmar Neugebauer in Vertretung des verhinderten stellv. Vorsitzenden Michael Paege über

die Aktivitäten der Querschnittsgruppen. Den Abschluss des Vormittags bildete der Bericht des Vorstands für Finanzen, Urban Lankes. Die DOAG konnte auch 2013 einen positiven Abschluss von 19.000 Euro vorweisen. Nach dem Bericht des Kassenprüfers Wolfgang Scherrer stimmte die Delegiertenversammlung seinem Antrag auf Entlastung des Vorstands ohne Gegenstimme zu. Am Nachmittag nahm zunächst die Präsentation des Status der Zielvorgaben aus der letztjährigen Delegiertenversammlung einen breiten Raum ein. Mit großem Engagement diskutierten die Delegierten an allen Tischen die bereits umgesetzten Maßnahmen und entwickelten weitere Ideen für die Umsetzung der Ziele. Anschließend folgte die Vorstellung des Budgets für die Jahre 2014 und 2015. Die Delegiertenversammlung stimmte auch hier ohne Gegenstimme für den Vorschlag des Vorstands. Zum Abschluss der Veranstaltungen stellte Björn Bröhl die Initiative des Vorstands zur stärker themenorientierten Ausrichtung der DOAG vor. Der Vorstand schloss sich hier einem Vorschlag der Development Community an, der darauf ausgerichtet ist, die Zielgruppen der DOAG besser anzusprechen und zu erreichen. Die Delegiertenversammlung diskutierte ausführlich die Initiative und nahm sie ohne Gegenstimmen mit wenigen Enthaltungen an. Dr. Dietmar Neugebauer bedankte sich am Ende des Tages bei allen Delegierten für ihr großes Engagement. Mit dem Hin-

weis auf die nächste Wahl der Delegiertenversammlung im Dezember 2014 und die darauf folgende Delegiertenversammlung am 20. März 2015 beendete er die diesjährige Versammlung.

International Oracle User Group Leaders Community Summit Traditionell fand auch in diesem Jahr in der letzten Januarwoche wieder in den Oracle Headquarters nahe bei San Francisco das Treffen der International Oracle User Group Leaders Community (IOUC) statt. 105 Teilnehmer vertraten 75 Usergruppen aus allen Kontinenten. Aus Deutschland nahm für die DOAG deren Vorstandsvorsitzender Dr. Dietmar Neugebauer teil, die deutschen Java-Usergruppen wurden durch Markus Eisele repräsentiert. Hauptthemen dieses dreitägigen Events waren der Erfahrungsaustausch der Anwendergruppen und die Präsentation der aktuellsten Oracle-Strategie aus erster Hand. Die strategischen Punkte waren vor allem die Weiterentwicklung der Datenbank-Technologie und Engineered Systems, die Vorgehensweise bei Big Data und Oracle Cloud sowie die Positionierung der Oracle-Applications-Themen. So wird im Datenbank-Bereich im ersten Quartal 2014 auch in Deutschland mit den Betatests zu den Features „In Memory“ und

Wir begrüßen unsere neuen Mitglieder Persönliche Mitglieder Andreas Buschka Nadine Schöne Henrik Nietschke Sebastian Lechte Fabio Spiekermann Tim Hellhake Lisa Weigert Sevil Lillyan Regina Orth Hendrik Jalink Moritz Schlaucher

Firmenmitglieder Catrin Brabant Uwe Embshoff Tobias Fritz Daniel Schnelle Quoc Dung Chau Rene Schreinemacher Dominik Schöner Arta Thaqi David Weiß Mehmet Simsek Matthias Haber

Demag Cranes AG, Andreas Rogge metafinanz GmbH, Dominika Rantasa dbi services Basel Area, Yann Neuhaus Commerz Systems GmbH, Bernhard Klein OSL GmbH, Gerhard Welte, Thomas Matthes Schwäbisch Hall Kreditservice AG, Martin Kudala inforsacom Informationssysteme GmbH, Dirk Franke ITGAIN Consulting Gesellschaft für IT-Beratung mbH, Robert Baric Information und Technik Nordrhein-Westfalen, Felix Gatzemeier

DOAG News 02-2014

63

„JSON-Objekte“ (JavaScript Object Notation) begonnen. Im ersten 12er Patchset 12.1.0.2 werden diese Features dann voraussichtlich im dritten Quartal produktiv zur Verfügung stehen. In diesem Zeitraum ist auch mit der Freigabe der Oracle Database Backup Logging Recovery Appliance zu rechnen. Die Veranstalter haben aber neben diesen strategischen Themen viel Zeit für den Austausch der Usergruppen untereinander eingeplant. Diese Best-Practice-Sessions zeigten, wie wichtig es ist, dass die Usergruppen untereinander ihre Erfahrungen über das Arbeiten mit ihren Mitgliedern und mit der Organisation ihrer Veranstaltungen weitergeben konnten. Dabei präsentierten vor allem die Vertreter der Java User Groups, wie sie die Möglichkeiten der Social Media zur Online-Vernetzung ihrer Mitglieder und zur Gewinnung von Content bereits intensiv nutzen. Es wurde deutlich, dass in Zukunft eine verstärkte internationale Zusammenarbeit beim Austausch von Referenten und beim Wissenstransfer von großem Vorteil für alle sein wird.

Datenbank, die durch sehr kompetente Referenten und deren Präsentationen ausgesprochen gut angenommen worden ist. Diese Konferenz wird einen festen Platz im DOAG-Kalender bekommen und findet in diesem Jahr am Dienstag, 3. Juni 2014, wieder in Düsseldorf statt. Ebenfalls eine feste Größe ist die DOAG Konferenz + Ausstellung, die im vergangenen Jahr mit dem Oak-Table- und dem Einsteiger-Stream eine sehr gute Bereicherung im Datenbank-Bereich erfahren hat. Dieses Konzept wird in diesem Jahr fortgeführt. Die SIG-Veranstaltungen sind zwar inhaltlich nach wie vor sehr gut, wie die Rückmeldungen der Teilnehmer belegen, die Teilnehmerzahlen sind allerdings rückläufig. Es wird auch im Jahr 2014 SIG-Veranstaltungen der Datenbank Community geben, aber es werden auch Konzepte für neue Veranstaltungsformate erarbeitet. Die DOAG Berliner Expertenseminare und Webinare der DOAG Datenbank Community werden hingegen in bewährter Art und Weise fortgeführt. Christian Trieb dankt allen, die sich in der Datenbank Community engagieren. Es war ein sehr konstruktives Community-Treffen, das Lust auf mehr macht. Feedback und Fragen an [email protected].

vor allem bei Prof. Knolle und Prof. Mandl für ihren Einsatz. Um die Hochschularbeit weiter zu forcieren, wurden für dieses Jahr zwei wesentliche Dinge geplant. Zum einen unterstützt die DOAG Hochschulen dabei, praxisnahe Fachvorträge in ihre Vorlesungen einzubauen. Dazu wurden die Referenten der DOAG Konferenz angefragt, ihren Vortrag auch an einer Hochschule zu halten. Die mehr als 70 positiven Antworten wurden den Professoren und Assistenten der unterschiedlichsten Hochschulen angeboten, was ein sehr positives Feedback hervorrief. Die DOAG sponsert die Vorträge insofern, als für die ersten zehn Vorträge die Reisekosten übernommen werden. Wer der DOAG weitere Kontakte zu Hochschulen vermitteln oder einen interessanten Beitrag halten möchte, kann sich per E-Mail an [email protected] melden. Als zweiter Punkt ist eine Überarbeitung des Konferenzangebots für Studierende geplant. Dem Feedback mehrerer Professoren zufolge sind die Reise- und die Übernachtungskosten Hauptprobleme für die Studierenden. Es wird jetzt eine Art Sponsorship von Partnerfirmen angestrebt, wobei die Kostenübernahme pro Student ca. 200 Euro beträgt. Wer als Sponsor Interesse hat, kann sich gerne bereits jetzt ebenfalls per E-Mail an [email protected] melden.

Christian Trieb Leiter Datenbank Community

Neues von der Datenbank Community Anfang Februar 2014 traf sich das Team der Datenbank Community zum jährlichen Treffen. Diesmal ging es darum, das vergangene Jahr zu reflektieren, das neue zu planen und die bisherigen Veranstaltungsformate zu überprüfen. So wurden die Inhalte, der Verlauf und die Teilnehmerzahlen der im Jahr 2013 stattgefundenen Veranstaltungen bewertet. Höhepunkt war die überaus erfolgreiche DOAG 2013

64 www.doag.org

Urban Lankes Stellv. Vorstandsvorsitzender

Die DOAG ist als Wissensvermittler bekannt und an Hochschulen präsent An der DOAG 2014 Konferenz + Ausstellung nahmen zum ersten Mal mehr als 80 Studierende teil. Die DOAG bedankt sich hier

Dr. Frank Schönthaler Leiter der Business Solutions Community

DOAG 2014 Business Solutions Konferenz − der Treffpunkt für die Anwender Oracle-basierten Unternehmensapplikationen

Aus dem Verein

Mit dem verbesserten Veranstaltungskonzept wartet die DOAG Business Solutions Community im Rahmen ihrer Jahreskonferenz und dem angeschlossenen Schulungstag vom 21. bis 23. Oktober 2014 in Berlin auf. Hochwertige Anwenderberichte, sofort umsetzbares Expertenwissen, Brandaktuelles direkt aus der OracleProduktentwicklung und noch mehr Wissensaustausch in den Anwender-Communities sind Bestandteile der diesjährigen Business-Solutions-Konferenz. Im Fokus liegen auch Strategien, Geschäftsprozesse, Applikationen und die zugrunde liegenden Oracle-Technologien. Aus Management-, Anwender- und ITSicht werden aktuelle Fragen behandelt, Konzepte diskutiert und Praxislösungen vorgestellt. Die intensive Einbindung des Herstellers Oracle, der globalen Kooperationspartner OAUG und Quest sowie von weiteren europäischen Anwendergruppen garantiert zudem ein umfangreiches

Portfolio des Vortrags- und Ausstellungsangebots. Mit dem Estrel Convention Center, einer Top-Location in Berlin, schafft die DOAG BSC einen Veranstaltungsrahmen, der eine produktive und innovative Arbeitsatmosphäre mit Hauptstadtflair verbindet. Neu ist das Preismodell, das vor allem echte Anwender anspricht: gegenüber den Vorjahren sind die Konferenzpreise für diese Besuchergruppe drastisch gesenkt worden. Der erste Veranstaltungstag ist geprägt durch Oracle Roadmaps einschließlich der Highlights von der Oracle OpenWorld, die Vorstellung von Produktneuerungen und produktbezogene Anwenderberichte. Am zweiten Konferenztag liegt der Schwerpunkt auf den Anwendervorträgen aus den Communities. Diese praxisorientierten und durchaus auch kritischen Beiträge der Anwender eröffnen immer eine ganz besonders hilfreiche und spezielle

Sicht auf die Produkte. Die Qualität wird durch den bereits eröffneten Call for Presentations mit anschließender professioneller Begutachtung der Beiträge sichergestellt. Seien Sie Teil dieser einmaligen und zukunftsweisenden Konferenz und bringen sich mit ihrem Wissen und Knowhow ein, denn genau von diesem konkreten Anwenderwissen profitieren Sie und die teilnehmenden Anwender. Im Anschluss an die zweitägige Konferenz bietet ein berufsqualifizierendes Schulungs- und Workshop-Programm mit der Möglichkeit, entsprechende Zertifikate zu erlangen, Raum für Aus- und Weiterbildungsangebote sowie für die Treffen von Special Interest Groups (SIGs). Unser Tipp: Die begleitende Ausstellung zeigt innovative Technologien live am System, Experten erklären Konzepte und Nutzungsoptionen und vor allem tauschen sich Anwender untereinander aus. Weitere Informationen unter www.bs.doag.org

DOAG News 02-2014

65

Termine

13.05.2014

Regionaltreffen München/Südbayern

April

Franz Hüll, Andreas Ströbel [email protected] 14.05.2014

DOAG 2014 Exaday DOAG Geschäftsstelle [email protected] 29.04.2014

Regionaltreffen NRW (APEX Community) Stefan Kinnen, Andreas Stephan [email protected]

14.05.2014

Regionaltreffen Stuttgart Jens-Uwe Petersen [email protected] 15.05.2014

29.04.2014

Regio Freiburg Volker Deringer [email protected]

Regionaltreffen Rhein-Neckar Frank Stöcker [email protected] 15.05.2014

29./30.04.2014

Berliner Expertenseminar mit Chris Antognini zum Thema Oracle Database Query Optimizer Cornel Albert [email protected]

Regionaltreffen Nürnberg/Franken André Sept, Martin Klier [email protected] 19.05.2014

Regionaltreffen Halle/Leipzig Matthias Reimann [email protected] 20./21.05.2014

8. Primavera Community Day

Mai

Alexander Neumann, Sebastian Hunke [email protected] 20./21.05.2014

07.05.2014

DOAG 2014 Logistik + IT Mit viel beachteten Zukunftsprojekten zur Industrie 4. 0 unterstreicht die heimische Wirtschaft im Verbund mit renommierten Forschungsinstituten die Bedeutung von Deutschland als einem der weltweit wichtigsten Innovationsstandorte.

Berliner Expertenseminar mit Lutz Fröhlich zum Thema Oracle 12c SQL Power Tuning Cornel Albert [email protected]

Verlag: DOAG Dienstleistungen GmbH Fried Saacke, Geschäftsführer [email protected] Chefredakteur (ViSdP): Wolfgang Taschner, [email protected] Redaktion: Fried Saacke, Carmen Al-Youssef, Mylène Diacquenod, Dr. Frank Schönthaler, Dr. Dietmar Neugebauer, Robert Szlilinski, Urban Lankes, Christian Trieb Titel, Gestaltung und Satz: Alexander Kermas, DOAG Dienstleistungen GmbH Titelfoto: © tovovan / 123rf.com Foto S. 28: © strixcode / Fotolia.com Foto S. 37: © ORACLE / oracle.com Foto S. 50: © darkovujic / Fotolia.com Anzeigen: Simone Fischer, [email protected] DOAG Dienstleistungen GmbH Mediadaten und Preise finden Sie unter: www.doag.org/go/mediadaten Druck: Druckerei Rindt GmbH & Co. KG www.rindt-druck.de

Inserentenverzeichnis S. 49

DOAG e.V. www.doag.org

U 2, S. 65

Hunkler GmbH & Co. KG www.hunkler.de

S. 3

ORACLE Deutschland B.V. & Co. KG www.oracle.com

U3

Libelle AG www.libelle.com

S. 59

MuniQsoft GmbH www.muniqsoft.de

S. 27

Regionaltreffen NRW (Vorabend DB Fachkonf.)

ProLicense GmbH www.prolicense.com

S. 21

Stefan Kinnen, Andreas Stephan [email protected]

PROMATIS software GmbH www.promatis.de

S. 13

Trivadis GmbH www.trivadis.com

U4

WGV Württembergische Gemeinde Versicherung a.G. http://www.wgv.de/

S. 31

Juni

09.05.2014

DOAG Webinar: SQL Plan Management: Changing the Way You Think About SQL Tuning 02.06.2014

Aktuelle Termine und weitere Informationen finden Sie unter www.doag.org/termine/calendar.php

66 www.doag.org

Herausgeber: DOAG Deutsche ORACLE-Anwendergruppe e.V. Tempelhofer Weg 64, 12347 Berlin Tel.: 0700 11 36 24 38 www.doag.org

DBConcepts www.dbconcepts.at

Dr. Frank Schönthaler [email protected]

Johannes Ahrends, Christian Trieb [email protected]

Impressum

Oracle Cloud Applications, Platform, Infrastructure

Oracle Cloud

Oracle Managed Private Cloud

and

Our Data Center

Your Data Center

Run some of your applications in the Oracle Cloud and others in your Private Cloud. You Choose.

oracle.com/cloud or call 0800 1 81 01 11 Copyright © 2012, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates.

Die Welt wird mobiler. Und Ihre Anwendungen?

Mobile Enterprise bietet Ihnen grosses Potenzial zu Prozessoptimierungen und Kosteneinsparungen. Ob Sie Ihren Aussendienst und Service mit mobilen Geschäftsanwendungen unterstützen möchten oder Ihre Managementprozesse ortsunabhängiger gestaltet wollen – wir entwickeln die Lösungen dafür. Trivadis ist führend bei der IT-Beratung, der Systemintegration, dem Solution-Engineering und bei den IT-Services mit Fokussierung auf Oracle- und Microsoft-Technologien im D-A-CH-Raum. Sprechen Sie mit uns. www.trivadis.com | [email protected]

ZÜRICH BASEL BERN BRUGG LAUSANNE DÜSSELDORF FREIBURG I.BR. HAMBURG MÜNCHEN STUTTGART WIEN

FRANKFURT A.M.