50
<Insert Picture Here> Guidelines for moving from Oracle Forms to Oracle ADF and SOA Steven Davelaar Oracle Consulting

Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

<Insert Picture Here>

Guidelines for moving from Oracle Forms to Oracle

ADF and SOA

Steven Davelaar

Oracle Consulting

Page 2: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Agenda

• Some quotes and pitfalls

• Defining a modernization strategy

• Forms modernization tools

• Case studies

Page 3: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Some Customer Quotes

• “I have 800 forms, how long will it take to migrate

them to ADF?”

• “Other migration tools migrate PL/SQL Logic,

JHeadstart doesn’t???”

• “Forms is dead, we need to migrate now”

• “No, we don’t need consulting, we have the

knowledge in house“

• “We want to evaluate JHeadstart Forms2ADF

Generator before we choose ADF and JHeadstart”

Page 4: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Some Pitfalls

• Lack of strategic thinking

• Lack of understanding target architecture

• No thinking in services

• No thinking in layers

• Ignoring importance of decoupling

• Lack of understanding Web 2.0 / SOA-based

development

• ADF UI capabilities unknown or underestimated

• Human workflow capabilities unknown

• Risk of rebuilding monolitic, data-oriented forms app into

monolitic data-oriented ADF app

Page 5: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Some More Pitfalls

• Migration tool seems more important than new

development platform

• Modernization effort underestimated

• There is no magic bullet

• ADF learning curve underestimated

• ADF is by far the most feature-rich and productive framework

in the market, but ….

• Best-practice use of ADF has steep learning curve, is different

from Forms development, and requires advanced ADF skills

• People are forgotten, they are more important than

tools!

Page 6: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

<Insert Picture Here>

Defining Modernization

Strategy

Page 7: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Defining a Forms Modernization

Strategy

• Where are we now?

• Analyze current situation

• Where do we want to go?

• Identify top business drivers / business benefits

• How do we want to go?

• Identify and choose modernization options

• What do we need to do when and with whom?

• Define modernization approach/timeline/project plan

Page 8: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Where Are We Now - Analyze current

System and Situation

• Technical architecture

• Functionality

• Data model

• User interface

• Documentation

• End user community

• Supporting IT staff

Page 9: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Current technical architecture

• Forms and DB version? Web or Client/Server?

• Business logic coded in Forms, Libraries or in DB?

• Generated using Oracle Designer?

• How is Forms product used?

• Standard: table blocks, query mode, CRUD operations, LOV’s

• Creative: form driven by custom PL/SQL

• What generic, reusable utilities/components exist?

• How do they map to ADF concepts?

• Desktop integration?

• Depends on interfaces with other systems?

• Which other systems depend on this system?

Page 10: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Current functionality

• Consists of logical subsystems?

• What functionality is obsolete?

• What functionality is duplicated in other systems?

• What functionality could be replaced with COTS

software?

• Batch functionality?

• Reporting functionality?

Page 11: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Current data model

• Based on sound relation design?

• To what level is data integrity enforced in DB

• Can the datamodel be split up in logical parts: data

services?

• Can new products/services easily be supported

=> How future-proof is the datamodel?

Page 12: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Current user interface

• Considered clunky, old-fashioned?

• “Window on data” or task-oriented screens?

• Support for human workflow?

• Intuitive, productive?

• Amount of data on one screen?

Page 13: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Current documentation

• State and completeness technical documentation?

• State and completeness functional documentation?

• Does system provide online help?

• Stored in CASE tool (like Designer)?

Page 14: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Current end user community

• Frequent, expert users?

• Infrequent, self-service users?

• Massive, keyboard-only data entry?

• Data entry paper driven?

• Geographically dispersed?

• What other systems are used to complete tasks?

• Are they productive (enough)?

• Happy or unhappy? Why?

Page 15: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Current IT Staff

• Afraid for or eager to learn new technologies?

• Outsourced, now or in future?

• Experience with Java, JEE, SOA?

• Experience with application servers, weblogic?

• Experience with version control tools, testing tools,

build and deployment tools?

Page 16: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Where Do We Want to Go - Common

Business Drivers

• User Interface

• RIA, self-service, task-oriented, web 2.0, mobile,

PDA/Smartphone

• Customization and Personalization

• Organisation unit, user group or marketing label

• Software-as-a-Service (SAAS) Model

• Time-to-market

• New products not held back by IT constraints

• Business process improvement

• Internal, B2B, B2C

• Human workflow

Page 17: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

How do we want to go - Common

Modernization Options

• Move logic from Forms to database

• Upgrade and integrate

• Add (self service) extensions

• Migrate functionality

• Redesign and rebuild functionality

Page 18: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Move Business Logic to Database

• Create separate business logic layer in db

• PL/SQL packages per table, or per logical entity

• Each package contains rules

• Optionally integrate with Designer-generated Table API

• Options to call out to business logic layer:

• Database triggers

• View with instead-of triggers

• Prevent direct dml on tables, go through PL/SQL API

Page 19: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

PL/SQL Business Logic Layer

Data

Layer

Tables

Pres.

Layer

Forms APEXADF

JDeveloper

PL/SQL

SQL*Plus

BusinessLogic Layer

Access

Business View APIwith Instead Of triggers

Rule Layer Table API

ins upd del

Tapi Business Rules

Web

Services

Page 20: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Move Business Logic to Database

• Why

• Decoupling! Minimizes the impact of changes in your IT

environment

• Can be done with current skills, can be started today!

• Database is very powerful programming environment!

• Remove dead/obsolete code

• Logic can be exposed through web services to other systems

• Forms migration or replacement will be easier, faster and

cheaper

Page 21: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Oracle Forms – upgrade and integrate

• “…There are no plans to desupport Oracle Forms and

Reports…” – Oracle Tools Statement of Direction

• http://www.oracle.com/technetwork/issue-

archive/2010/toolssod-3-129969.pdf

• Clear statement of direction

• Upgrade

• Integrate

• Oracle Forms 11g in Oracle FMW 11g

• Many new features

Page 22: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Forms 11: Major New Features

• External events

• Allow Forms to react to events in outside world

• BPEL integration, JMS Queue

• JavaScript integration

• JavaScript to raise Forms event

• Call JavaScript from Forms

• Database proxy users

• Centralized user store, authentication through OID/LDAP

• Increased security: Forms users cannot connect to DB

• PL/SQL Tracing

Page 23: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Legacy Systems

Batches

Packaged Apps

Web Apps

BPEL

Process

Orchestration

Rules

Engine

results

facts

Policy evaluation

Business

Activity

Monitoring

Monitoring

SOA Integration

Forms

Tables

PL/SQL

AQ

DB

Human interaction

Human Workflow

ServiceAssign Task

TaskComplete

Web Services

Page 24: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Upgrade and Integrate

• Why Upgrade to WebForms 11

• Runs on WebLogic 11, ensures ongoing support from Oracle

• WebLogic 11 can be reused for ADF-based solutions

• New features ease SOA-based integration

• Why Integrate

• Improve operational excellence through workflow extension

• Reduce cost through chain integration with suppliers and

customers

• Reduce cost through reuse: share services

Page 25: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Add Extensions

Self service users via

online Java Web

application

Self service users via

wireless devices

Back office users

via Forms

Application

Other systems via

a Web Service

Page 26: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Add Extensions

• Reduce cost, increase efficiency:• Transform old paper-driven back office tasks into web-based self-service tasks

• Increase competitiveness• Provide self-service extensions to customers and suppliers

• Provide mobile and PDA/Smartphone access

• Allows IT Staff to gain experience with web-based solutions

Page 27: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Migrate functionality

• Increase end user productivity

• Leverage UI features not available or hard to build in Forms

• Consolidate on single future-proof JEE-based

development platform

• New IT Staff skilled in JEE, not in Forms.

• Tools might be of help

• Prepare for next steps to SOA

Page 28: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Forms Migration – Remember the

Pitfalls

• Investment hard to justify without real BUSINESSbenefits

• Forms apps are typically data-oriented, not process/task-oriented

• Keyboard-only data entry hard to do with web apps

• How future-proof is the data model?

• Migrate monolitic Forms app into monolitic web app

Page 29: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Redesign and re-implement

functionality

• Put the business in the driving seat:• Which processes satisfy business goals in most optimal way

• Ability to resolve biggest bottlenecks in current businessoperation

• Identify reusable services in existing systems

• Identify new services

• Build composite, task-oriented user interfaces to access the services

Page 30: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Composite User Interface

Page 31: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

<Insert Picture Here>

Oracle Forms

Modernization Tools

Page 32: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Forms Modernization Tools

• JHeadstart Forms2ADF Generator

• PITSS – PITSS.CON Tool

• OraFormsFaces

----------------------------------------------------------------

• CipherSoft - Exodus Migration Tool

• VGO Software - EVO Forms-to-Java Tool

• Imex Systems – Ormit Java/ADF Tool

• Qualogy – QAFE

Page 33: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

JHeadstart Forms2ADF Generator

• Auto-created ADF Business Components, including model-based LOV’s and UI Hints

• Migrates Forms user interface to metadata, not application code!• Easy to redesign into task-oriented web 2.0 user interface.

• Generates best-practice ADF application

• JFG provides most savings for forms with• Standard data blocks based on table or view

• Complex user interface: many (stacked) canvasses, tabs, LOV’s, and other display types

• PL/SQL logic mostly limited to user interface dynamics

• Best Practice ADF architecture

Page 34: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Oracle Forms Screen

Page 35: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

JHeadstart Generated ADF/JSF Page

Page 36: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

PITSS – PITSS.CON Tool

• Repository driven application analysis

• Business logic assistant to move logic to DB

• Web service assistant to create web services from

DB logic

• Forms2ADF Assistant creates ADF Business

Components and ADF ViewController layer

• Good Forms2ADF white paper on PITSS.CON site

Page 37: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

OraFormsFaces

• Third party product supplied by Commit Consulting

• Allows reuse of existing Forms as full featured JSF

components

• Two-way communication between Forms and ADF

Faces web pages

• Allows for incremental migration to ADF/SOA world

Page 38: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

OraFormsFaces

Page 39: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

CipherSoft - Exodus Migration Tool

• Exodus-ADF is an innovative conversion product that

automates the migration of Oracle Forms to Oracle

ADF, including Oracle Menus, Libraries, Triggers and

all semantic content

• Exodus is benchmarked to be 90% faster then

manually converting Oracle Forms and PL/SQL and

provides as much as an 80% cost reduction for the

client. In addition, Exodus provides an application that

is portable, maintainable, web-enabled, and supports

a multi-tier architecture.

Page 40: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

VGO Software - EVO Forms-to-Java

Tool

• Evo is certified by Oracle Corporation as 1 of only 2

third-party solutions in the world to conduct Oracle

Forms to Java modernizations.

• Evo preserves a customer’s investments by retaining

existing business logic and re-architecting a system

into a standards-compliant Java application, with the

option of modernizing your Forms to ADF 11g or

MyFaces JSF.

• Oracle developers who want to move to ADF can use

Evo to convert their Forms and use JDevelopers

intuitive wizards to work with the code that Evo

generates.

Page 41: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Imex Systems – Ormit Java/ADF Tool

• ORMIT Java-ADF is the most comprehensive tool available

today that can easily and quickly migrate Oracle Forms

applications to 100% Java-ADF

• ORMIT Java-ADF achieves high levels of automated PL/SQL

conversion process using a language parser to map the

inheritances and relationships of the business logic framework,

decompose the client-server code into object-oriented code and

by separating the business logic into multi-tiered enterprise Java

code.

• ORMIT Java-ADF reduces the time required to perform the

migration of Oracle Forms applications by up to 90%. The

process minimizes the need for manual inspection of legacy

code.

Page 42: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Qualogy – QAFE

• QAFE converts the Forms application to QAML (QAFE’s markup language) format The only remaining step is to add some code to incorporate the Forms application’s business logic and complete theconversion process. Doing so, with QAFE, you can accomplish theentire conversion process in a fraction of the usual time needed. Which– obviously – provides you with ENORMOUS cost savings incomparison to other conversion tools.

• QAFE is a framework to create Web 2.0 applications with a ServiceOriented Architecture. ADF is an extension on the Java Server Facesand is mainly concerned with the presentation and navigation

• QAFE is a lot easier to learn and a lot more productive compared toOracle Forms (and Servoy). In order to answer the question exactly how many times faster than JDeveloper, you'll have to see QAFE inaction.

Page 43: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

<Insert Picture Here>

Forms2ADF/SOA Case

Studies

Page 44: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Finland - Financial Institution

• Why• Performance problems with Forms over WAN

• Problems with Java applet due to different Java versions inbrowser

• Architecture Forms App• Simple user interface

• Complex data retrieval: DB procs populate temp tables orrecord groups

• Complex data manipulation through DB procs

• Complex mexhanism to call reports through DBMS_PIPE with polling mechanism

• Added Value JHeadstart Forms2ADF Generator• None

Page 45: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Finland - Financial Institution

• Customer Impressed with Added Value ADF and

JHeadstart

• ADF Business Components well suited to reuse existing SQL

statements

• Reuse capabilities of ADF task flows

• Clean MVC architecture

• Dynamic form rebuilt in ADF in three hours with much cleaner

architecture

• Polling requirement: 15 minutes work with standard ADF

Faces components

• Customer strongly considers to move to ADF and

JHeadstart, has to do strategic thinking first!

Page 46: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Netherlands – ISV in Education Market

• Why• Wants to add self service capabilities to core app

• Wants modern user interface

• Architecture Forms App• Complex user interface, many tabs, many items on canvas

• Standard data retrieval and manipulation

• Most business logic in database

• Added Value JHeadstart Forms2ADF Generator• Business Components auto-created based on forms definitions (1 form resulted in 162 business components)

• Migrated metadata strongly modified to generate new redesigned user interface

Page 47: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Netherlands – Government IT

Department

• Why

• Forms 4.5 and DB 8.1.7 no longer supported

• System integration difficult because of old/obsolete technology

• Character-based user interface, end users complain

• High maintenance cost

• Hard to find resources skilled with older Forms versions

• Architecture Forms App

• Character-based 24*80 screens

• Standard data retrieval and manipulation

• Most business logic in forms

• Added Value JHeadstart Forms2ADF Generator

• Business Components auto-created based on forms definitions,inclusing UI labels derived from boilerplate text

• Migrated screens generated with minor changes to metadata

• Amount of UI redesign to be decided

Page 48: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Netherlands – Government IT

Department

• Migrated ADF 11 prototype used to create

enthousiasm and gain credibility in organisation

• Existing Forms developers keen to learn ADF

• JHeadstart Migration Estimating Utility generates

excel sheet with estimates based on forms

characteristics

• Used to provide insight in total migration effort

• Will start in Jan’ 2011 with migration first app (60

forms)

Page 49: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Denmark- ISV in Insurance Market

• Why• Loosing sales because of old user interface

• Need better SOA-based integration points

• Architecture Forms App• Standard data retrieval and manipulation

• Simple to moderate user interface

• All business logic in database

• Added Value JHeadstart Forms2ADF Generator• Proof of concept showed about 20-50% savings per form

• Now deciding to move on with JHeadstart

Page 50: Guidelines for moving from Oracle Forms to Oracle ADF and SOA

Summary – avoiding the pitfalls

• Think strategic and big - Start small

• Do thorough analysis of current system and

environment

• Define key business drivers for this transition

• Make Lasagna and Ravioli rather than Spaghetti

• Understand capabilities ADF, JHeadstart and SOA

Suite

• Invest heavily in training and coaching on the job

• Do trial migrations / assessment

• Asses added value migration tools

• Get better insight in migration effort