Northgate Revenues and Benefits Forms migration to APEX

1. Northgate Revenues and Benefits Forms migration to APEX 22nd March 2011

2. Introductions • Tony Andrews – Independent Apex Developer • Nigel Blair – Product Director – Northgate Public Services

3. Why we did it Nigel Blair

4. Internal Focus Groups Guide Site Project “Unpopular Front End” Version 6 Integrated Workflow Performance Management Late 2004…… Results….

5. .......how we got there

6. Ambitions - Technology • Move from Oracle Forms in Browser to pure HTML Front End • Fully Transactional Web Site • Same model as Amazon, eBay, Tesco • Builds on iWorld Project • Improvements in Accessibility • W3C Level 1 (possibly level 2) • Any Browser Features • Skinnable / Style Sheets • Colors / Large Print / Proportional Resizing/ Text Only • Light / Quick • Can run alongside existing UI during phased migration

7. Ambitions – Presentation (Enquiry) • Faster Enquiries • User Friendly • Technical Jargon Free • Business Focussed • User Driven • Liaise / Consult with End Users • Learn from previous roll-outs • Look at weak areas • Flatter Presentation of Data • Quicker Access to Data • Quicker Link to Update

8. Ambitions – Performance (Update) • Quicker • Speed of Response • Less Clicks • Multiple Update of data • Enquire / Create / Update • Multi Row • Benchmark Existing Application • Address Weak Areas • More Organic Approach • Improved Service / Productivity • Improved Quality • Integrated Workflow / Scheduler

9. Timeline October 2005 Launch Of Prototype at IRRV Conference November 2005 V6 Prototype Installed On Customer Portal December 2005 Management Board Sanctions Version 6 V6 Development Commences Jan - May 2006 Development Continues Consultation Continues User Group Executive Approve Roll-out

10. Timeline May – July 2006 Recruitment Of 6 Beta Sites Beta Programme Commences V6 Beta Release – July 2006 December 2006 First Production Release of V6 December 2008 All forms and processes available in V6 Announced De-support of V5 from December 2009 December 2009 First All-V6 Release All customers live on Version 6 Only

11. Version 6 – today! ACTIONS Gives quick access to the actions (updates etc.) associated with the current page. LINKS User-defined links to other applications, internal and external web sites (e.g. DWP) KEY DETAILS Shows the user the main details and current status of the item in context (Account, Property, Claim etc etc) CONTEXT BLOCK Holds the main details of the item in context (Applicant, Task) TABS Quick Access to all main work Areas through use of Tabs REGIONS Breaks information down into clearly defined regions

12. Outcomes.......

13. Outcomes....... Central Government Opportunities Improved Performance International Opportunities

14. How to migrate 1500 Forms to Apex Tony Andrews

15. Tony Andrews • UK-based Oracle developer for 20+ years • User of Apex since Project Marvel • Developer at Northgate 2002-2010 • Active on: • tonyandrews.blogspot.com • stackoverflow.com • forums.oracle.com

16. Aims • Update of 1500-module Forms application • Preserve large existing database • Preserve large existing code base • Preserve large existing body of role-based security and navigation metadata • Use 20+ developers who know Forms, PL/SQL and the application (but don't know HTML, CSS, Javascript)

17. Concerns • Will Apex scale? • Is Apex robust enough for a serious product? • Is Apex good for developers? • Why not Java?!

18. Challenges • Migrate 1500 forms quickly, consistently and correctly • Some Apex built-in features not useful: • Form region • Tabular form region • Tabs • Validations • Requirements for “Rich UI” • Management of large Apex project

19. Rich UI • Reports with “overflow” area • Tabular forms over APIs • Dynamic hide/show, enable/disable, validation and population of items • In other words, Dynamic Actions! • Configurable item, region and report column labels

20. Report with Overflow

21. Report with Overflow

22. Report with Overflow

23. Tabular Form

24. Tabular Form

25. Tabular Form

26. Tabular Form

27. Tabular Form

28. Tabular Form

29. “Dynamic Actions” Defined via data in tables Applied automatically via page 0 region (no developer code)

30. Rich UI • Report overflows, tabular forms, “dynamic actions” etc. all defined declaratively via data • This data needs to be maintained by the developer, and deployed via version control • Creating all this data via SQL Plus scripts or Toad (or SQL Developer) is tiresome Q: What can we do to make the developer's life easier?

31. Rich UI A: Give them an Apex application to maintain the data, with a facility to download all data for a page as a SQL script ready for deployment.

32. Reuse Legacy • Forms module definitions in Oracle Designer • Generate first-cut Apex pages and our “metadata” from these • Security/navigation data • Render navigation tabs from this • Base page authorisation scheme on this • Business Logic APIs • Generate first-cut code to map Apex page to API

33. Apex Page Generator

34. Consistency (Quality) • Build Standards • Generator • Skeleton pages to copy • Reports to check Apex pages for adherence to standards

35. Manageability • Many small applications • One per logical business area • Between 5 and 50 pages per app • Assign applications to development teams • Version control export files (app or page) • Version control our metadata • Master Application • Common Components, published to other apps: • Templates, Authorisation and authentication schemes • Shortcuts, Application processes

36. Apex Resources • Apex on OTN • Apex Forum • Apex Blogs • Apex Development Team

37. Outcome • Successful replacement system • Satisfied customers • Productive and satisfied developers* • A foundation for developing future applications * well, mostly!

38. Conclusions • Can Apex be used for large projects? • Is it a good idea? • Would we do it again?

39. Conclusions • Can Apex be used for large projects? Yes • Is it a good idea? Yes • Would we do it again? Yes – and we have