Embed Size (px)
DESCRIPTION
Beispiel wie Oracle Fusion Middleware als Basis für Integrationsprojekte genutzt werden kann
Citation preview
2012 © Trivadis
BASEL BERN LAUSANNE ZÜRICH DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MÜNCHEN STUTTGART WIEN
Integration Architecture
Oracle Fusion Middleware als Best ofBreed Basis
Daniel Liebhart und Matthias Furrer
BDS
TechEvent September 2012
September 2012
1
2012 © Trivadis
Introduction
2
• Matthias Furrer� Long-standing experience in SOA and ERP Area
� Architect, Consultant, Lead-Developer and Project Manager
� SOA Certified Professional
� Oracle SOA Blackbelt Consultant
� Trainer with Trivadis Oracle Middleware und SOA
� Reviewer of Technical Publications
� More than 20 years of software development experience
� Contact: [email protected]
September 2012
2012 © Trivadis
Agenda
� Teil I: Die Konzeption� Die Ausganglage & Vorgehen� Beispiele (leicht abgeändert ☺)� IT-Landscaping: Vom Prozess zur Architektur� Die Middleware als Basis
� Teil II: Die Umsetzung� SOA 2.0 und die Varianten� Anwendungs-Integration über Messaging� SOA Integration Blueprint� Mapping und Einsatz von FMW Komponenten
3
September 2012
3
2012 © Trivadis
Ausgangslage: Typische Situationen beim Kunden
4
� Beispiele aus der Praxis:
� Beispiel 1: Die IT-Landschaft ist nicht für neue Geschäftsfelder vernünftig aufgestellt
� Beispiel 2: Drei unterschiedliche Fullfillment Plattformen dreier Firmen sollen zu einem funktionierenden Ganzen zusammengefügt werden
� Beispiel 3: Die Anforderungen des Business an das wichtigste System können nicht in gewünschter Zeit umgesetzt werden
� Gründe: Veraltete Systeme, neue Geschäftsmodelle, Redundante Systeme
� Die Fragestellung des Kunden: Was tun?
September 2012
4
2012 © Trivadis
Vorgehen: Was in einer ersten Phase zu tun ist
5
� Ordnung schaffen, Lösungsvarianten als Enscheidungs grundlage liefern!
� 1. IST Situation analysieren: Bestehende Prozesse, Systemlandschaft und Informationsflüsse analysieren und dokumentieren
� 2. SOLL Vorgaben erfassen: Soll Prozesse und zentrale Geschäftsobjekte erfassen
� 3. Lösungsvarianten erarbeiten: Big Picture Umsetzungsvarianten erarbeiten
� Grundsatz: Alle Beteiligten müssen ein klares Verständnis er IST Situation, der SOLL Vorgaben und der zur Verfügung stehenden Lösungsvarianten haben.
September 2012
5
2012 © Trivadis
Beispiele: IST Situation analysieren - Systemlandschaft
6
ERP Archiv Network Management GIS
Billing System Rollout Management Service Management
Data Exchange HUB
Enterprise Integration System
Gebäude, Besitzer
VerträgeNetzwerk Layer 1
Netzwerk Layer 0
Incidents,Cases
Order Management & Fulfillment
Netzwerk Layer 2
Rechnungen
CRM
Kunden
Network (Element) Managment
Gebäude,Ausbau-Status
Data Exchange
September 2012
6
2012 © Trivadis
Beispiele: IST Situation analysieren - Systemlandschaft
7
EInträge
Produktion Weisse Seiten
RedaktionssystemDB
Files Eingänge
Online Spezialauskünfte
Auskunfsystem
DB
Generierung Aufkunftsdaten
Online DB
Produktion Finanzen / Human Ressources
Behörden System Online SystemeBackoffice Systeme
Adressverkauf
September 2012
7
2012 © Trivadis
Beispiele: IST Situation analysieren - Systemlandschaft
8
Kundenkarten, Rubriken, Orte
Produktion Gelbe Seiten
RedaktionssystemMakuscript
Lichtsatzdaten
Mobiles Salessystem
Services
DB
ArchivingFinanzen / Human
RessourcesWeb Portale Online Systeme
Externe Produktions-
SystemeGIS Client
September 2012
8
2012 © Trivadis
Beispiele: IST Situation analysieren - Schnittstellen
9
Firma 1
Einträge
Produkte
Firma 2Firma 3
Medien Inhalte
Binary URL
Targeting Ads
Stammdaten GEO Daten
Kundenkarten
Ad ID
Platzierung
# ProdukteInteraktion Prod.Interaktion KundeSchaltdatenContext Ads
Data LoaderLieferungen
September 2012
9
2012 © Trivadis
Beispiele: SOLL Vorgaben erfassen - Prozesse
10
Geschäfts-Prozesse
Marketing- und Sales-Prozesse
Unterstützungs-Prozesse
Management-Prozesse
Organisations-entwicklung
StrategiedefinitionFinanz-
managementPortfolio-
managementProjektportfolio-
management
Produkt-management
ChannelManagement
MarketingAquisition Wholesale
and EnterpriseAquisition
ServiceproviderCustomer Relationship
Management
BillingVertrags-
managementEntwicklung ICT
Knowledge-management
Beschaffung
RollOut Fulfillment Projektgeschäft Assurance
September 2012
10
2012 © Trivadis
Beispiele: Lösungsvarianten erarbeiten – One Size fits all!
11
Ein einziges Gesamtsystem
Fulfillment Services
Finanz-Management
Services
Beschaffung Services
Aquisition Services
Billing Services
Projektgeschäft Services
Produkt-Management
ServicesRollOut Services
Vertrags-Management
Services
Management-Services
Marketing ServicesChannel
Management Services
Zentrale Entitäten(Kunde /
Rechnung / etc.)
Andere Entitäten
Datenaustausch
September 2012
11
2012 © Trivadis
Beispiele: Lösungsvarianten erarbeiten – Individual!
12
Datenaustausch
Fulfillment ServicesFinanz-
Management Services
Beschaffung Services
ChannelManagement
Services
Billing ServicesProjektgeschäft
Services
Produkt-Management
ServicesRollOut Services
Vertrags-Management
ServicesAquisition ServicesMarketing Services
Management-Services
Zentrale Entitäten(Kunde /
Rechnung / etc.)
AutomatisierteProzesse
Geschäftsregeln Sicherheit
Andere Entitäten
September 2012
12
2012 © Trivadis
Beispiele: Lösungsvarianten erarbeiten – Best of Breed!
13
COTS Produkt 2
COTS Produkt 1
Datenaustausch
Fulfillment ServicesFinanz-
Management Services
Beschaffung Services
ChannelManagement
Services
Billing ServicesProjektgeschäft
Services
Produkt-Management
ServicesRollOut Services
Vertrags-Management
ServicesAquisition ServicesMarketing Services
Management-Services
Zentrale Entitäten(Kunde /
Rechnung / etc.)
AutomatisierteProzesse
Geschäftsregeln Sicherheit
Andere Entitäten
DatenProzesse
Datenaustausch-Prozesse
DatenProzesse
September 2012
13
2012 © Trivadis
IT-Landscaping: Die Grundidee
14
� Die Basis: Der Zuordnung von IT-Systemen oder IT-Funktionen zu den zentralen Geschäftsobjekten und zu den wichtigen Geschäftsprozessen
� Die Elemente:
� Erfassung und allgemeine Beschreibung der zentralen Geschäftsobjekte wie beispielsweise der Kunde, der Auftrag, das Produkt oder auch die Rechnung und die Organisationseinheit
� Abbildung der Geschäftsobjekte auf die verschiedenen IT-System e mit einer CRUD-Matrix
� Erfassung Geschäftsprozesse auf oberster Ebene
� Abbildung der unterstützenden Systeme als Sammlung von Services für den jeweiligen Geschäftsprozess
September 2012
14
2012 © Trivadis
IT-Landscaping: Vom Prozess zur Architektur
15
IT-Funktionen zur Unterstützung derSupportprozesse
IT-Funktionen zur Unterstützung des
Zentralen Kundenprozesses
RollOut Services Beschaffung Services
Management-Services
Aquisition Services
Billing Services
Produkt-Management
Services
Projektgeschäft ServicesFulfillment Services
Vertrags-Management
Services
Finanz-Management
Services
Marketing Services
ChannelManagement
Services
Übergreifende IT-Funktionen (Basis-System)
Zentrale Entitäten(Kunde /
Rechnung / etc.)
AutomatisierteProzesse
Geschäftsregeln
Datenaustausch
Sicherheit
Andere Entitäten
Supportprozesse
Hauptprozesse
RollOut Beschaffung
Management
Aquisition
Billing
Produkt-Management
Projektgeschäft Fulfillment Vertrags-Management
Finanz-Management
Marketing
ChannelManagement
Prozesse
Unterstützende IT-Services (als IT-
Funktionen)
Basis Service
Basis Service
Basis Service
Basis Service
September 2012
15
2012 © Trivadis
IT-Landscaping: Von der Anforderung zur Umsetzung
16
IT-Funktionen zur Unterstützung der Haupt- und Supp ort-Prozesse
Übergreifende IT-Funktionen (Basis-System)
RollOut Services
Beschaffung Services
Management-Services
ChannelManagement
Services
Finanz-Management
Services
Projektgeschäft Services
Produkt-Management
ServicesFulfillment Services
Billing Services
Vertrags-Management
Services
Marketing Services
Aquisition Services
Zentrale Entitäten(Kunde /
Rechnung / etc.)
AutomatisierteProzesse
Geschäftsregeln
Datenaustausch
Sicherheit
Andere Entitäten
Basis Service Basis ServiceBasis Service Basis Service
Architektur
Requirements&
User StoriesZuordnung Bau
September 2012
16
2012 © Trivadis
Die Middleware als Basis: Geschäftsobjekte zentral
17
� Die gemeinsame Basis einer Anwendungslandschaft sin d die systemübergreifend auszutauschenden Informationsobje kte
� Ob individuell entwickelte Services oder Standardpr odukte – alle verwendet diese Basis – die Daten werde über eine Mi ddleware ausgetauscht
� Und ausserdem:
� Abteilungsübergreifende Geschäftsprozesse und Geschä ftsregeln werden über die Middleware realisiert
September 2012
17
2011 © Trivadis
Definitionen
• EDA – Event Driven Architecture : «An event driven architecture is extremely loosely coupled and well distributed. The event Itself doesn’t know about the consequences of its cause»Quelle: Wikipedia
• SOA – Service Oriented Architecture : «SOA represents an open, agile, extensible, federated, composable architecture comprised of autonomous, QoS-capable, vendor diverse, interoperable, discoverable, and potentially reusable services. SOA can provide an abstraction of business logic and technology.»Quelle: Erl, Thomas, About the Principles.
SOA 2.0
• Event Driven SOA : «Event-driven SOA is a form of service-oriented architecture (SOA), combining the intelligence and proactiveness of event-driven architecture with the organizational capabilities found in service offerings.SOA 2.0 evolves the implications SOA and EDA architectures provide to a richer, more robust level by leveraging previously unknown causal relationships to form a new event pattern»Quelle: Wikipedia
SOA 2.0 EDA und SOA – Ein Widerspruch ?
September 2012safd
18
2011 © Trivadis
Point-To-Point vs. MessagingAb wann entsteht ein Nutzen ?
Anzahl notwendiger Interfaces
• Point-To-Point : n * (n-1)
• Bus-Architektur oder Hub-Spoke: n * 2
App 1 App 2
App 3
App 4
App 1 App 2
App 3
Messa
gin
gApp 4
Point-To-Point : Messaging :
September 2012safd
19
2011 © Trivadis
IntegrationsarchitekturHigh Level View – Schematische Sicht
• Komplette Entkoppelung zwischen Sender und Empfänger der Ereignisse
• Asynchrones Messaging für geschäftskritische Transaktionen (publish/subscribe) zur zuverlässigen Zustellung der Nachrichten
September 2012safd
20
2011 © Trivadis
Anwendungs-Integration über MessagingDesign Grundsätze und Nutzen
Funktionen / Building Blocks
• Jede Anwendung (CRM, Legacy, Konfigurator) hat je einen Outbound-Adapter und einen InboundAdapter. Alternativ kann es auch je einen Adapter pro jeweilige Business-Entität geben.
• Die Kommunikationen findet ausschliesslich über ein gemeinsames (kanonisches Format statt)
• Abhängig vom Typ der zu verarbeitenden Entität und Ziel der Nachricht, können beim Inbound-Adapter auch Human Workflow Komponenten – zum Beispiel Vervollständigung der Informationen oder Approval-Prozesse) involviert sein.
Gründe für Design Entscheid
� Vermeidung von redundanten Entwicklungen – «Wiederverwendbare Schnittstellen».
� Dynamische Integration und Reaktionsfähigkeit (Agilität)
� Garantierte Zustellung und Verarbeitung über Queues und Middleware
� Weitgehende Unabhängigkeit von Integrationsfähigkeit der Sender- und Empfängerapplikationen durch Einsatz von Middleware mit entsprechenden Technologieadaptern
September 2012safd
21
2011 © Trivadis
High Level Integration ViewInteraktion zwischen Inbound und Outbound Adaptern
• Entkoppelung der Inbound und Outbound-Adapter ermöglicht Wiederverwendung der Adapter und Nachrichtenzustellung an ggf. mehrere Consumer, bzw. Verarbeitung von Nachrichten von unterschiedlichen Producern
September 2012safd
22
2011 © Trivadis
Adapter AnatomyBeispiel: Inbound / Outbound Adapter mit OSB und BPEL
• Wiederverwendbare Adapter und Datenmappings durch Einsatz von kanonischem Schema
• Abstrahierung des Entitätenmodells der beteiligten Systeme
September 2012safd
23
2011 © Trivadis
Anwendungsübergreifender Datenaustausch als Prozess oder via Messaging ?
Messaging
� Erweiterbarkeit um neue Systeme ohne Auswirkungen auf bestehende Integrationen durch komplette Entkoppelung
� Keine Wechselwirkungen bei Ausfall eines Empfängersystems
− Asynchrones Pattern: Feedback an Nachrichten-Ersteller nicht unmittelbar – oder nur mit grösserem Aufwand - möglich
− Abhängigkeiten bei der Zustellung und übergreifende Transaktionen können nicht über alle Event Channels abgebildet werden
Prozess
� Synchrone Steuerung: Reihenfolge der Zustellung, Abhängigkeiten und anwendungsübergreifende Transaktionen können abgebildet werden
� BPM: Modellierung und Nachvollziehbarkeit über Tracking/Monitoring möglich
− Erweiterungen oder Modifikationen mit Auswirkungen auf den gesamten Ablauf
− Störungen bei der Zustellung haben Auswirkungen auf nachfolgenden Prozessschritte
App 1 App 2
App 3
Messa
ge B
roker
App 4
App 1
App 2
App 3
September 2012safd
24
2011 © Trivadis
SOA Integration BlueprintMapping Komponenten zu Oracle FMW Produkten
September 2012safd
25
2011 © Trivadis
Key-Überlegungen in einem SOA ProjektSOA Reference Architecture und SOA Governance
Source: Oracle
• «Right-Sizing» SOA ist ein kritischer Erfolgsfaktor für den Erfolg
• SOA ist eine mittelfristig ausgerichtete Strategie, die immer durch die Definition von konkreten Geschäftszielen motiviert und definiert sein sollte
September 2012safd
26
2012 © Trivadis
BASEL BERN LAUSANNE ZÜRICH DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. HAMBURG MÜNCHEN STUTTGART WIEN
Thank you.Trivadis AG
Daniel Liebhart & Matthias Furrer
Europa-Strasse 5CH-8152 Glattbrugg
www.trivadis.com
September 2012
27
