Order T-Mobile

Transcription

1 Order T-Mobile Dr. Thomas Dupré, T-Mobile Deutschland GmbH November 2009 Master-Untertitelformat bearbeiten

2 Agenda Motivation for Order Management Key concepts of OMS/OE A closer look towards OMS A closer look towards OE Lessons Learned Demo 2

3 The Basis: SOA Infrastructure 2006: Renewal of ESB Project SOA Backplane (SBP) Harmonization of SOA-Infrastructure across all T-Mobile national companies Technology: Tibco EMS, Web Services (WS Gateway as Common Access Layer) additional value adding functionality (central logging, monitoring, routing, service repository, ) Idea 2007: central order management and order fulfillment based on SBP Project Order Management / Orchestration Engine (OMS/OE) Technology: BPEL, Web Services, XML connection to other IT Systems via SBP Order Management consists of (multi-channel) Order Capture Order Repository OMS/OE Order Fulfillment (Execution) 3

4 Strategic Objectives Consolidate different order repository and order fulfillment functionalities into a central Order Management System cost reduction through reuse and centralization of business logic Portal Call Center Back Office rule readwrite rule readwrite Frontend rule readwrite Backend domains better time2market because redundant implementations are avoided Portal Provide integrated, consistent interface and automated fulfillment of orders for all channels / front-end systems Frontend Maximize availability due to separation of order capture and order repository (OMS) from order execution (OE) Business Process / Order Back Office OMS/OE Local Workflow central order tracking central business process monitoring Call Center rule readwrite rule readwrite rule readwrite Backend domains 4

5 Logical Target Architecture 5

6 Key concepts of OMS/OE Motivation for Order Management Key concepts of OMS/OE A closer look towards OMS A closer look towards OE Lessons Learned Demo 6

7 Main requirements OMS: order based view (order repository & management) OE: process instance based view (order fulfillment / execution) enable creation, update, cancellation, execution and retrieval (query) of orders from multiple channels structural validation of incoming orders maintain order status and results / order lifecycle management cope with concurrent orders at the same time (order blocking) dynamic order throttling operate on a high level process description (BPEL) persist ongoing process executions (for recovery purposes) order decomposition data mapping: transform inbound request XML data to outbound service calls towards back-end systems communicate with back-end systems via SBP (web services, ESB) out of scope: guided order capture, (semantic) order validation out of scope: transaction security across back-end systems 7 7

8 What do we need for OMS/OE? What can we buy on the market? BPEL engine (or other workflow systems) for orchestration evaluation and decision: Oracle BPEL Process Manager x BAM, Rules Engines etc. for order fulfillment (if necessary) BPM tools for integration with business processes on business side (if necessary) What is still missing out-of-the-box? (gap analysis) implementation of specific order fulfillment business logic advanced operational features (e.g. order throttling) any order oriented view (instead of a purely process instance oriented view), e.g. order repository functionalities: how to store, retrieve and track orders according to non-technical criteria? OMS link to business analysts: how to model the offered services and order types? MDSD: Generator ( from UML to XSD / WSDL ) 8

9 OMS/OE Technology Technology stack OMS: Technology stack OE: Oracle 10g R2 RDBMS Oracle 10g R2 RDBMS, OAS, BPEL Process Manager , Advanced Queuing Apache tomcat, Spring, JEE XML, XMLBeans, XFire, XQuery Saxon-SA, a schema-aware XSLT / XQuery processor Generator framework 9

10 High level system architecture 10

11 A closer look towards OMS Motivation for Order Management Key concepts of OMS/OE A closer look towards OMS A closer look towards OE Lessons Learned Demo 11

12 OMS interface modeling: It s all about Orders (1) CCDM (Common Customer Data Model) Definition: A customer order is a business transaction between customers and DTAG, which is connected to the creation or change of a contract or customer data. Suborders are the smallest orderable units (atomic) can be aggregated flexibly into orders Hardw are deliver y Tariff e chang Invoice online bi om d C ar C An order ( shopping basket ) can be an offer based sales order (e.g. contract renewal) a non-offer based sales order (e.g. tariff change) a service order (e.g. address change) Contract renewal or a mixture of all t trac n o l C ewa ren ption Tariff o e chang Channels tag an order with a business process type. 12

13 OMS interface modeling: It s all about Orders (2) More technically: Orders are XML documents and comply to a specific structure defined by an XML schema. The XML schema definition is generated out of a UML syntax of order definition. OMS offers web services e.g. for creation, update, cancellation, execution and retrieval (query) of orders. OMS services are document-centric, expect orders as parameters, e.g. Create (Order), Execute (Order), no such services as ChangeTariff, UpdateAddress etc. Reason: flexibility concerning the aggregation of suborders without interface changes the variance of business processes is modelled in the orders & suborders (polymorphic), not in the services 13

14 OMS Design Process OMS model XMI Export Designer UML Profile Developer OMS/OE Generator Eclipse TMF: Xpand Xtend OML persistence module service definitions DB-schema type system OMS-Query definitions OMS model OMS/OE Generator Xpand Xtend generated artifacts <html/> interface specification <wsdl/> service definition SQL database definitions.java source code 14

15 A closer look towards OE Motivation for Order Management Key concepts of OMS/OE A closer look towards OMS A closer look towards OE Lessons Learned Demo 15

16 Order Fulfillment within OE Order fulfillment follows the steps below: order decomposition instantiate dispatcher process for the order, initialize order processes instantiate sub-processes (basically one process instance per suborder) data mapping: transform the data contained in the input order to the different backend service interfaces call services towards backend services via SBP according to BPEL workflow for each sub-process receive callbacks from partner systems (in the asynchronous case) update OMS according to order status changes, order results and business events 16 16

17 Orders and Order Processes OE view on order processes OMS view on order CSD (Customer Service Desktop) view on order processes: To Do list of process automation 17

18 Error Handling (1): Basics During the fulfillment of orders, different errors can occur. Error handling mechanisms within OE depend on the error type. Technical Errors e.g. Connection problems, Technical Exceptions from partner systems, handling via an automated retry mechanism: Configurable number and frequency, retry mechanism can be interrupted corresponding BPEL code is generated into workflow design at build time resp. Error Policies are used Idempotence pattern is important Programming Errors e.g. Unexpected Errors within OE delivered to Error Hospital Business Errors are routed to a manual operator workplace for manual correction or compensation dito for unsuccessful retries or business processes which are to be fulfilled manually 18

19 Error Handling (2): Pushing to manual user Business errors or unsuccessful retries are routed to Oracle s Worklist accessible by IT internal support group (see below) and back-office desktop (pushed work-items via routing platform, see next slide) OE 19

20 Error Handling (3): Passing back to OE Customer Service Desktop (CSD) displays history and future steps of order as well as erroneous step with error message OE offers several actions for the continuation of processes: try again close order process (set current process to completed, continue) close order (set remaining processes to completed ) abort order process (set remaining processes and whole order to failed ) remind Order process results can be captured and used in further processing 20

21 Lessons Learned & Outlook Motivation for Order Management Key concepts of OMS/OE A closer look towards OMS A closer look towards OE Lessons Learned Demo 21

22 Lessons Learned Development Process / Architecture start small think big : prototyping, iterative development process process modeling: sequential order of steps (parallel fulfillment induces complex error handling) do not rely on BPEL only; use also Java, XQuery, PL/SQL consequently use BPEL scopes otherwise your workflow will become very unclear very soon MDSD approach proved to be of value error handling is an important topic continually improve in performance optimizations Tools (Oracle BPEL Process Manager) defensive upgrades to new versions of Java, Oracle BPEL etc. some enhancements of out-of-the-box Oracle BPEL Engine necessary (schema-aware XQuery Engine, GUIs for manual order processing) weaknesses in multithreading architecture, lacking debugger (< ) tricky versioning of process instances necessary Co-working / Communication with Oracle Service Requests not answered promptly, several loops necessary 22 22

23 Outlook intended merge of T-Home and T-Mobile in 2010 merge of some IT systems (CRM, Order Management etc.) probably new system landscape and architecture incorporation of BAM evaluation of Oracle Fusion Middleware 11g evaluation of Oracle Fusion DOO (Distributed Order Orchestration) 23 23

24 A Sandbox Demonstration Motivation for Order Management Key concepts of OMS/OE A closer look towards OMS A closer look towards OE Lessons Learned Demo 24

25 A short Demonstration modeling services / orders in UML generating WSDL / XSD for OMS generic Test GUI that creates orders based on this WSDL order repository (OMS) fulfillment, audit trail (OE) order tracking (OMS) Simulator of Backend Systems monitoring with Operator GUI, BPEL Console (OMS, OE) 25 25

26 Thank you for your attention! -- Q&A -Backup 26

27 Main components of SBP Infrastructure 27

28 Order Lifecycle Management sample lifecycle of an order OMS offers services for order lifecycle mgmt: Create and park an order in OMS Update payload of parked order Send order to fulfillment (new or parked order) Correct a failed order (becomes a parked order again) Force throttled orders into fulfillment (bulk) Create and park Revocation/Replacement for an order Send Revocation/Replacement to fulfillment Automatic lifecycle management: Maintain business history of an order Update OrderResult and state change events from OE Throttling Archiving parked executable in_process failed in_manual_ process parked executable in_process completed Revocation parked Revocation executable revocation in_process revoked OMS OE 28 28