How can Oracle Forms (or other legacy) applications be modernized to fit in a contemporary IT architecture? Trends, concepts and technologies are discussed.

1. Oracle Forms
Modernization Roadmap
A discussion
Kai-Uwe Moeller, November 2018

2. About the Author
● Technical consultant
• at Oracle Consulting Germany
• self employed since 2008
● Expert for
• Oracle Database
• Fusion Middleware, ADF, eBusiness Suite
• Oracle Forms modernization and migration
• Oracle Reports and BI Publisher

3. Agenda
• Stating the challenge
• Migration roadmap
• Analyze existing architecture
• Forms modernization
• Forms alternatives – (not so) new technologies
• Design service and presentation layer
• Target Architecture Scenario

4. Common Questions
• For how long will I be able to operate my Forms applications?
• Commitment by Oracle indefinite?
• Forms developers retire
• One main competitor runs his software at lower cost and reacts
very agile on new business requirements. How can we get there?
• Our field sales representatives need some of our application data
on their mobile devices.
• Controlling is not happy with the old fashioned and static
presentation of the revenue numbers.
The following slides are a starting point to find adequate answers.

5. Assumption
• IT of the last decades was highly focused on manual data entry
Reason: Humans were primary data source and recipient
• New technologies have gained importance:
• Mobile devices
• Internet of things
• Deep learning
• RFID and others
• Consequence is evolving human interaction (‘human tasks’)
• Classic desktop applications will loose importance
• Interaction of multiple services becomes more relevant

6. Evolution of Human Interfaces
• Mass data query and
entry screens
• Desktop oriented
• Static forms
• User driven
• Data evaluation, data mining
• Decision support
• Interactive dynamic dashboards
• Desktop and mobile
• Event driven, real time

7. Transition from Desktop oriented to
Service Oriented Architecture

8. Transition Roadmap
Analyze Existing Architecture
Examine Target Technologies
Define Modernization Scope
Design the Services
Design the Presentation Layer

9. Analyze Existing Architecture
1. Locate the business logic:
Database, Forms modules, Java programs
2. Identify unused and deprecated components:
Dead code, obsolete Forms modules and database objects
3. Identify components
• to be exposed as a service
• to be replaced by an external service
4. Examine peripheral/supporting components:
Interfaces, batch jobs, reporting, security

10. Transition Roadmap
Analyze Existing Architecture
Examine Target Technologies
Define Modernization Scope
Design the Services
Design the Presentation Layer

11. Examine Target Technologies
Full Stack (Oracle)
• Forms (modernization)
• ADF (ADF Faces with Task Flows and ADF Business Components)
• Application Express (APEX)
Services
• Oracle REST Data Services (ORDS)
• Service based on Java frameworks (Spring REST, …)
• SOA Suite
User Interface
• JavaScript / Typescript based frameworks
• JSF

12. Forms Modernization – Chances and Risks
✅ Currently: Oracle commits to
forms for ‘indefinite” time
✅ Saves the investments taken
✅ Skill set for maintenance is
available
✅ Still a fast and reliable way to
enter mass transactional data
on a desktop
✅ Forms 12c features and third
party tool kits enable
modernization
❗ Forms runtime client can get
incompatible with desktop
Java Runtime (JRE)
❗ Major browser vendors had
discontinued Java applets
❗ Running Java applications on
desktop computers is more
and more considered as a
security risk and causes
unwanted maintenance by IT
desktop support

13. Partial Migration – Pros and Cons
✅ Smaller project(s), agile
approach possible
✅ Tailored applications for each
target audience:
• Responsive dashboards for
controlling and management
• Mobile device apps for field
service and sales reps
• Fast and reliable data entry forms
for back office desktops
✅ Gradual migration to a modern
cloud based architecture
❌ Increased effort in operations
and maintenance possible
❌ Diverse technology stack
❌ Manual switching between
multiple applications can
degrade user experience
A complete Migration from Forms
creates a huge project and may
not generate the desired results.
Let’s consider doing it partially
and gradually.

14. Tool Supported Migration
• Differences in legacy and target architectures are huge,
not limited to the programming languages
• Legacy code usually grew over years collecting many add-ons and
workarounds, has obsolete portions1), etc.
• Such a real world legacy application automatically transformed,
will it be
- Lean, contain maintainable and performant code?
- Future ready for cloud oriented architectures?
1) There are software tools that can identify obsolete (unused) code,
even unused portions of the UI

15. ADF – Faces, Task Flows
and Business Components
✅ Advanced and powerful features
(Task flows, ADF Business
Components, ...)
✅ Moves focus of development
from technology to business
requirements
✅ Follows industry standards like JEE
and JSF
✅ Support by large software vendor
❌ Partially proprietary
(Binding layer, ADF BC,...)
❌ JSF Technology stack aged
❌ Heavy weight,
performance issues possible
❌ License costs
❌ Lack of proficient ADF developers
❓ Commitment by Oracle?
When the learning curve has been consumed,
building Applications with ADF can be very efficient.
But this comes with a price tag and the future of the
framework is uncertain.

16. JavaScript based
� Is JSF still relevant? Read this opinion: https://www.javabullets.com/is-jsf-still-relevant
❗ The JavaScript framework scene
is fast moving
Considerations
❓ Learning curve
❓ Creates maintainable code
even for large projects
❓ Component library contained
or available
❓ Performance
❓ (Projected) Market share
❓ Support and Community

17. Application Express (APEX)
• Part of the Oracle Database
• Highly declarative web application development
Pros:
✅ Supports agile development
✅ Delivers fast results, contains many standard patterns
(menus, forms, master/detail data views, security)
✅ No additional license costs on top of Oracle database license
Cons:
❌ Highly proprietary
❌ Strictly dependent on Oracle Database (vendor lock)
❌ Lack of scalability and layer/API based architectural approach
❌ Security considerations
It is amazing, how quite powerful
applications can be built with APEX in
between short time even with small
knowledge of coding. But finally
everything comes with a price.

18. Transition Roadmap
Analyze Existing Architecture
Examine Target Technologies
Define Modernization Scope
Design the Services
Design the Presentation Layer

19. Define Modernization Scope
● Identify screens and modules required
for migration
• Functionality not available in
Forms (i.e. for mobile devices)
• Strategic
• Other
● Identify related modules building a
business process
• Technically by code references
• Logically by user navigation
(navigation flow)
● Migrate identified modules to
target architecture
● Build supporting new interfaces and
workflows based on requirements
New
interfaces and
workflows

20. Transition Roadmap
Analyze Existing Architecture
Examine Target Technologies
Define Modernization Scope
Design the Services
Design the Presentation Layer

21. Design the Services
Service Categories
• Administrative (authentication, authorization, …)
• CRUD operations – data retrieval, entry and change
• Validation
• Invoke other systems as services (reporting, interfaces, …)
Implementation
• PL/SQL procedure
• ADF Business Component
• Web Service (can be based on PL/SQL, ADF BC, Java)
A unified service layer would be ideal, but not all
frontends will be compatible. Forms or JSF can
be bound to REST only with high effort, a vendor
interface may accept a specific XML format ... So
the services will remain a mix of different
technologies based on the consumer’s
requirements.

22. Extracting Business Logic
• Extract PL/SQL from Forms into database stored
procedures if they act like services.
• Criteria for an ideal extracted stored procedure:
- Can its purpose be described like a use case?
Examples: 'Get contract details' 'Update stock amount' 'Create new warehouse’
- Does it represent or encapsulate a database transaction, or is it strictly read only?
- Is it reusable across screens or applications?
- Can given input and expected output be documented across scenarios?
- Can it be (automatically) tested with a set of defined test cases?
• Most questions answered with
- Yes? Great candidate for a database driven service!
- No? Consider refactoring with extraction. Why should you keep and maintain
components in your architecture when you don't know exactly what they do?
There are tools capable of automatic
Forms PL/SQL extraction to the database.
They can speed up extraction but have to
be used with caution as they will do it
one-to-one.

23. Thinking about Transactions (1)

24. Thinking about Transactions (2)
● The Forms database centric architecture uses
transactions and guarantees data consistency out of
the box
● ADF Business components can emulate the
transaction based approach
● The standard REST approach maps http methods
(GET, PUT, …) one on one to CRUD/DML database
operations (UPDATE …)
● Scenarios where a use case contains more than one
CRUD/DML operation in one transaction need a more
customized service implementation,
● Alternative Approach: Abandon full data consistency

25. Authentication and Authorization
Legacy
• Named database users and assigned database roles
are common in Forms applications
Modernization Strategies
• Make database users and roles available to services
• Migrate users and roles to a new access control service
• PL/SQL Code with references needs rework if it contains references to
USER or database roles or
• Consider connection via named proxy user

26. Transition Roadmap
Analyze Existing Architecture
Examine Target Technologies
Define Modernization Scope
Design the Services
Design the Presentation Layer

27. Design the Presentation Layer
• Design for Desktop and/or Mobile devices
• Unified or separate?
• UI frame organization:
• Menu
• Tabs
• Or: New approach optimized for mobile devices
• Navigation and navigation rules between views
• View design

28. Reporting
• Replace deprecated Oracle Reports
• BI Publisher, Jasper Reports, …
• Check for obsolete reports
• Align with current business requirements
• Reports still required as static paper/PDF output?
• Consider alternative and contemporary ways of presentation
i.e. interactive dashboards
• Design integration with target architecture
• If static (PDF) output is still required:
• Asynchronous generation – notify recipient of result like success or failure
• Delivery method to the recipient
Reporting is easily underestimated in
implementation and modernization projects. Quite
surprising as the efforts can be significant. This
slide is just a starting point.

29. Target Architecture Scenario
● Choose (or keep) the technologies
that meet your needs
● No new developments in
technologies you mark as
deprecated for your organization
● Web Services (REST) are the glue for
modern architectures
● Gradually evolve to a
Cloud / PaaS / SaaS ready
architecture

30. Related Topics Down The Road
• Forms modernization
• Oracle Application Express (APEX)
• Interaction between Oracle Forms
and web applications
• Security

31. Summary
• Forms (12c) applications can comfortably exist
in a current IT landscape.
• A gradual migration is possible and recommended.
• This is just the beginning.
Continuous learning is part of the game.
Please share your opinion and experience!
mail@kaimoeller.net LinkedIn: Kai-Uwe Möller