Modernizing Forms Apps with ADF and JHeadstart
•
5 gostaram•954 visualizações
This document discusses modernizing Oracle Forms applications to Oracle ADF. It describes using JHeadstart Forms2ADF to automate parts of the modernization and manually modernizing more complex forms. Lessons learned include thinking about architecture first and not trying to copy all Forms functionality. Standards, guidelines and tools help with the modernization process.
Recomendados
Mais conteúdo relacionado
Mais procurados
Semelhante a Modernizing Forms Apps with ADF and JHeadstart
Semelhante a Modernizing Forms Apps with ADF and JHeadstart (20)
Mais de Luc Bors
Mais de Luc Bors (20)
Último
Último (20)
Modernizing Forms Apps with ADF and JHeadstart
- 1. … And thus your forms “automagically” disappear ODTUG Kaleidoscope 2011 – Long Beach, California Luc Bors, AMIS, The Netherlands
- 2. Overview The Business Case The Modernization Project Manual Modernization The PL/SQL Challenge (No, not that one … ) Automated Modernization Lessons Learned
- 3. Business Drivers Single Sign-On & uniform UI for all internal applications Add new/extend incomplete UI functionality Add reporting (No Oracle Reports !) Add adequate authorisation (even the temps have full access) Support of business process flow (instead table data), so untrained users can perform application functions Eliminate Direct Database Access by Business (external requirement)
- 4. IT Drivers End-of-Life of the existing applications Oracle SoD: Designer exit! 2 applications with 2 coding-styles No authorization, no architecture Forms supported our data model instead of the business processes Missing functionality, more back-end applications to come Cultural difference Java vs. Oracle
- 5. Migration or Modernization ? Migration indicates an automated process Migration indicates a one one result Lets call it Modernization and add Business Value !
- 7. Pilot dedicated to JHeadstart and ADF (8 weeks)
- 10. 1st Project Goal & Starting point Rebuild 1 Forms App without functional changes Web Forms 50+ forms Simple Complex Build new task oriented functionality
- 11. What are the Options ? Use Forms2ADF for all Forms Use no Forms2ADF ( = manual modernization) Meet in the middle
- 12. No Forms2ADF Complex Forms do not implement business processes in the best way Usually represent database instead of process Many many items on a Form, using stacked and tabbed canvasses. For layout conservation JHeadstart gave some very good Hooks
- 13. Forms and ADF are not that Different See the similarities between Forms and ADF Application building blocks based on tables Non base table (Post-Query) lookups UI labels, tooltips and format masks Validation List of values Calculated fields Common Forms triggers Form/Page navigation UI controls
- 14. How similar are Forms and ADF
- 15. How similar are Forms and ADF
- 16. How similar are Forms and ADF
- 17. Manual Forms Modernization Isolate / Identify UI Components Define Functionality Re-design ? Translate Building Blocks
- 19. Building the layout Know the ADF Layout components PanelSplitter PanelStretchLayout PanelTabbed Nest them if necessary
- 20. The Result
- 21. The PL/SQL Challenge Forms Built-ins are not available in ADF and PL/SQL is not Java. Your options: Whenever possible transfer to DB Whenever lucky Use a declarative or zero code ADF Alternative Otherwise Code Java Alternative
- 22. Transfer to Database It is easy to call PL/SQL in Forms ADF supports PL/SQL calls in an almost similar way “When Button Pressed Trigger” ocm_blocked_orders_module.proceed_order(arg1, arg2, arg3); public void proceedOrder(String p_order_id, String p_old_status, String p_new_status) { String statement = "ocm_blocked_orders_module.proceed_order(?,?,?)"; DbUtils.callStoredProcedure(statement, new Object[] { p_order_id, p_old_status, p_new_status }, getDBTransaction(), true); // commit }
- 23. (Near) Zero Code Alternatives Forms code for: Buttons Canvasses Navigation ADF code for: None of the above
- 24. Rebuild in ADF / Java Code Can be (extremely) time consuming Try to define functionality of PL/SQL code Do not try to copy ! Re implement ! Know your options ! Example Implementing search
- 26. Search FormQuick Query Query Custom Parameter form
- 27. The Most Flexible Implementation public void adjustAndApplyViewCriteria( String pOption ,Boolean pEntireDatabase ,String pAction ,String pLdrId ,etcetera ,……… ,String pTop){ 1 if(pStockAvailable.equalsIgnoreCase("S")){ vo.applyViewCriteria(getViewCriteria("stockAvailable_S_vc"),true); } 2 if(pListId.equalsIgnoreCase("WORK_ID")){ ViewCriteriaworkIdVc = getViewCriteria("workId_vc"); workIdVc.resetCriteria(); VariableValueManagerworkIdVvm = workIdVc.ensureVariableManager(); workIdVvm.setVariableValue("b_workId", pIdentifier); vo.applyViewCriteria(workIdVc,true); } 3 if(pOption.equalsIgnoreCase(QueryUtils.getCn_top_sales_short())){ String pTopSalesMax = QueryUtils.getTopSalesMax(trans); addFragmentToWhereClause(" pos <= to_number(nvl("+pTop +","+ pTopSalesMax +" )) and "); } 4
- 28. So What About Architecture ? Application Architecture In the Beginning Taskflow with page fragment and per Taskflow 1 page with 1 static region All in one big workspace After a While Taskflow with page fragment and per Application 1 page with 1 dynamic region Use separate workspaces Much Better Not So Good
- 29. Taskflows and Regions Use ADF Taskflows Create ADF Taskflow libraries Use ADF Dynamic Regions Render regions based on context and menu action
- 30. The Menu
- 31. What is JHeadstart ? Jheadstart is a Jdeveloper Extension JHeadstart consists of three main components: JHeadstart Runtime Library Reusable components that extend Oracle ADF JHeadstart Application Generator (JAG) Generator of the Controller (JSF/ADFcconfig files), View (ADF Faces pages/fragments), and Model components (ADF data controls and databindings).
- 32. What is JHeadstart ? JHeadstart consists of three main components: JHeadstart Forms2ADF Generator (JFG) The Forms .fmb files are read, and based on the Forms elements defined in the form, the JFG creates ADF Business Componenets, as well as the XML meta-data (Service Definition) required by the JHeadstart Application Generator
- 33. Jheadstart Forms2ADF Use Forms2ADF for Simple and Intermediate Forms Because….. Simple Forms like Domain Maintenance are unlikely to change and do not support complex processes
- 34. Example forms
- 35. JDEVeloper and Jheadstart New Fusion WebApplication Enable JHeadstart Invoke Jheadstart Forms2ADF Wizard Wizard Creates Business Components Wizard Creates Jheadstart App. Definition Files Generate Jheadstart Application
- 37. Select modules & finish wizard
- 39. Jheadstart Forms2adf DEMO DEMONSTRATION
- 40. Lessons Learned (1) (Re-) Think the architecture Architecture is the foundation for a stable and robust Application Don’t try to copy forms functionality Know your ADF Faces Components
- 41. Lessons Learned (2) Start talking with users before you start re-building the application They don’t always use the forms application the way you expect Automated migration is not easy. You can run into issues that an automated tool cannot handle You still need to re-code forms triggers (PL/SQL)
- 42. Additional deliverables It’s not only about (re-) building the app It’s a whole new profession It’s a new way of life Write it down Use the tools
- 43. Standards and Guidelines The AMIS / CUSTOMER.COM cookbook Architectural issues Development How to‘s Standards and Guidelines Tips and Tricks Code Templates Setting up Unit tests
- 44. Software Factory Versioning using Subversion ADF BC Unit testing using Junit ADF RC Unit testing using Selenium JIRA for issue tracking Continuous Integration using Hudson Maven
- 45. Conclusion Forms Modernization can be Difficult 100% Automated Modernization Doesn’t Exist If Possible Use Tools (JHeadstart) to Help you Modernize Modernization goes Beyond Building Software
- 46. Need to Know More ? Check out Steven Davelaars’ Session on JHeadstart SESSION 13 Wednesday 11:15 AM to 12:15 PM Check out Sten Vesterli ‘s New Book
- 47. ....and Thus Your Forms 'Automagically' Disappeared ODTUG Kaleidoscope 2011 – Long Beach, California Please Fill Out Your Evaluations Luc Bors, AMIS, The Netherlands Luc.Bors@amis.nl LucBors@gmail.com Follow me on Twitter : @lucb_
Notas do Editor
- Process
- This session is A Forms Modernization Story Featuring JHeadstart Forms2ADF. It talks about considerations to make when you are about to decide whether or not to leave Forms and go for ADF. You will see the process of conversion step by step starting with the business case and ending at the new ADF application. You will hear about issues you run into when using Forms2ADF for automated conversion and you will get hints on how to use Forms2ADF and how to modernize your forms app.
- So a decision was needed: what to do with our aging app’s? Our business had a number of business-needs which were taken into consideration: The choice was made to rewrite our GUI and ADF was chosen for a number of reasons: New enterprise critical applications have an expected live span of about 10 years at least. Forms, however supported by Oracle, and without an End Of Live notice, will probably not be around as a vital technology anymore in 2020. So Forms was not an option. Furthermore, ADF ‘understands’ the database, something which cannot be said of all Java Frameworks. Also the guaranteed support from Oracle played a major role. By choosing the ADF technology stack we also wanted to make the technology switch for our developers as easy as possible. Although the choice to redesign our UI with ADF was made in 2007, we really started end-2009. In the meantime some of the original business drivers had become obsolete. The more technical drivers remained and became even more important.Four highly motivated old school Oracle developers where selected to become our first ADF-developers. These people all started in the first half of 2009 with either an extensive JAVA-curriculum at the Dutch Open University or with SCJP-certification (now: OCP, J).In October 2009 was the real start of our Forms2ADF project BTW: if you are interested in this card-set– ”drivers of change” deals with the driving forces in our future and is on sale at bol.com
- Lets start with the context of our project – what was our starting point, or to put it this way – “Where do we come from” ?two Local(Dutch) applications, created using Forms/Designer technology. In the early years functionality was needed fast, very fast. Luckily, Oracle Forms, was (and is) and extremely productive way of doing this.So our developers did a tremendous job in providing us with Forms to ‘maintain’ the data in the database tables. It was the wild west era of development. Authorisation was something to be added later, when necessary. Architecture was for the big cities, not for the wild west... Back then, an handful of employees had to have all access to all functionality. Luckily Forms requires you to log on. Otherwise this feature would also have been skipped.Our two main applications were developed using Forms Designer, by two teams. Each one using their own distinct coding standards, resulting not only in two distinct type of GUI’s but also in the in-exchangeability of developers between these two groups.So, we ended up with basically two distinctively different applications, made by two different lead developers, with their own vision on how to develop an application. Both applications where not designed to support business processes instead they were formed around the database tables, to maintain their data. The Oracle Developers were not interchangeable between both applications.I bet this never happens to you. ;-)----Furthermore, with the success of there was an increasing need for additional functionality, both within the existing applications as in new applications. The question arose what to do with our aging applications: redesign, refactor? And using what technology?-----Due to the increasing number of employees differences in culture arose between the Webshop(Java)-developers and Backoffice(Oracle)-developers.A decision was needed: what to do with our aging app’s? Redesign using the same technology was out of the question due to the End-of-Life Message Oracle had given.
- So: How did we take off on this ADF-adventure?All four selected developers received ADF11g- and JHeadstart–courses taught by our technology partner AMIS. The qualified professors in this course were Luc Bors and Lucas Jellema (one of the Oracle ACEs for ADF and SOA).After this initial course we started with an Proof of Concept. The aim of this PoC was to acquire some experience in order to be able to make sound architectural decisions after the PoC. And as in every PoC we did not throw everything we built away but started to uses them as building blocks in our ‘regular’ application. I’m sure you wouldn’t make such a mistake. During the realisation of the project a lot of these early ‘building stones’ were replaced by better and refactored functionality. In order to provide the business with the added value of the ADF-technology a decision was made to start with the realisation of new functionality. Furthermore, we planned a quick transition to production so that the results of all the investments, both in time and money, would be visible for all.
- After this training the team set out to do a PoC.In this PoC we wanted to investigate several things.1st : Is ADF Flexible2nd : Can we use JHeadstart3rd : Can we use Jheadstart forms2 ADF generatorThe answers where quit promising.We used Jheadstart to implement our authentication/authorization mechanismAnd also to use Forms2ADF Generator which is a feature of Jheadstart to automatically transfer forms modules to ADF.This approach prooved to be a good one. Jheadstart was not able to interpret the most complicated forms.We decided to use Forms2ADF Generator for the simple formsWe used it to get an idea of what Jheadstart makes of it and use these examples to build our own implementation.With the results of this PoC, we were ready to set of for the real modernization project.
- The starting point was an Oracle Forms application which had to be modernized.There are some very simple forms in there, but also more complex ones like the one ‘you see here’.Later on I will show you how we took on this challenge and what the result of this form looks like in ADF
- Timing : 2 minutesThis is one of the more complex forms that was modernized. We started with isolating the different layout components on the form. 1 Animate:Search Area2 Animate:Master Result Block Table3 Animate:Master Result Block Form4 Animate:Tabbed Panel5Animate:Detail Result Block (Form and Table)6 Animate:Extra Detail Result Block7 Animate: Show totals.8 Animate: the menu which was already covered in the previous partThe problem for this particular form is not the master detail part and the data that it is displaying. ADF offers masterdetail ‘out of the box’ and as a developer there is not much that needs to be done. We were able to use pretty straightforward ADF Business Components to get the data from the database and to display it in the application.More complex however is implementing layout containers, the functional search implementation and the PL/SQL functionality backing the buttons. Lets start with layout containers.
- When building the layout you need to know the ADF Layout Components.PanelSplitter and PanelStretchLayout components are typical components that we had to use in order to create the pagelyaout we needed. The panelTabbed component is a perfect alternative for the many tabbed containers that we had in the Oracle Forms Application.
- Timing :1 minuteSo the end result looks pretty similar to the original Forms Module.Animate: You can recognize all partsAnd only the search area is implemented a little different. This is mainly because we used dropdown boxes instead of a radiogroup.Notice the panel splitters that are used. Users can adjust the amount of space for their ‘functional content’.
- Migration of PL/SQL code is not possibleTry to put the PL/SQL code into the database whenever it’s possible.PL/SQL calls are supported in the ADF Framework.We used it extensively to convert existing Database Calls and to implement new ones.If you can’t transfer it to the database, then re-implement it in ADF.I’ll give you an example and explain this based on the implementation of search functionality.
- Like : WizardsAnd More
- ADF offers three (or actually four) ways of searching.ADF Query (and Quick Query) Components.ADF Search FormADF Parameter FormWe used all of these in our project. When to use which implementation depends on needs you have. ADF Query components is a very rich component and can be implemented very quickly (drag and drop). It however offers little flexibility, so if you need customization, you will get stuck in the end.The Search Form is less Rich but can also be implemented very quickly (drag and drop). The latter are all more or less zero code ADF Alternatives for searching.The ADF Search form even offers a zero code alternative for Enter Query / Execute Query (in form layout).The ADF parameter form is from an implementation point of view more difficult, but it offers you full flexibility. This is the component we used for the Search Area in the modernized form. We implemented a java method accepting all values that can be searched on. In this method the actual query where clause is created and applied. By taking this approach it is much easier to create conditional where clauses and to apply view criteria based on the parameters received by the method. In this way we could exactly reproduce the functionality use in the original forms application.
- We started with one big workspace.There are several disadvantages to this approach.First of all, you can end up with a very large workspace that takes forever to open in JDeveloper.Besides that, you will have multiple developers editing the same files and projects.After phase one we decide to split the application into multiple small applications.Advantages of this approach are:re-use if it is neededSmaller workspaces and there for faster workspacesEasier to work in parallel on multiple parts of the application.
- Timing : 1 minuteUsing these ADF taskflow libraries can compose your application from many small Workspaces containing just one taskflow.We used taskflows that render their content in pagefragments.These taskflows were deployed as ADF Taskflow libraries.And all these libraries come together in a big, lets call it, container app that knows when to render the correct taskflow.ADF Taskflow Libraries are jar files and can be used by an ADF Application.You simply add a reference to your application and you can use the taskflow.We used a dropdown menu to invoke all navigation in the application.In the menubar component there are menu components (the toplevel of the menu), and within these we have commandMenuItems.The commandMenuItems have an action attribute referencing our DynamicRegionManager (just a name, you can pick any name you like) that sets the taskflow Id. The region component is refreshed (ppr via PartialTrigger attribute) and renders the new functionallity.
- Timing : < 1 minuteYou see the Dashboard, which is the default region and is displayed as an entry point for all users at startup.From there we use the dropdown menu for navigation.
- JDeveloper, which enables rapid component based development of Java EE applications.It provides you with 4GL-like productivity without jeopardizing the flexibility andopenness of the Java EE architecture.JHeadstart consists of three main components:• JHeadstart Runtime LibraryThe JHeadstart runtime contains reusable components that extend Oracle ADF.These reusable components implement Oracle ADF best practices that weredeveloped during custom development projects of Oracle Consulting.• JHeadstart Application Generator (JAG)Apart from the runtime components, JHeadstart provides significant design-timesupport. The JHeadstart Application Generator (JAG) is a powerful generator thatautomates the development of the Controller (JSF/ADFcconfig files), View (ADFFaces pages/fragments), and Model components (ADF data controls and databindings). The JAG is driven by XML meta-data that you create using JDeveloper(plug-in) wizards and JHeadstart property editors, providing you with adeclarative, 4GL-like experience in building Java EE applications. To help you toget started with the meta data, JHeadstart generates a first cut of the meta databased on your ADF Business Components, which can be retrieved from a UMLclass model or database tables.
- JHeadstart Forms2ADF Generator (JFG)In addition, JHeadstart offers you assistance in moving from the Oracle Formsworld to the Java/J2EE world. Using the JHeadstart Forms2ADF Generator, theForms .fmb files are read, and based on the Forms elements defined in the form,the JFG creates ADF Business Componenets, as well as the XML meta-data(Service Definition) required by the JHeadstart Application Generator. Afterrunning the JFG, you can then run the JAG to create a fully functional ADF webapplication, based on the definitions in the Oracle Form.
- After a while, actually after the PoC, we found that the way we architectured the application was not very flexible. We could have continued in that way, but we did not. We decided to take a different approach. All functionality developed after the PoC was build using the new architecture. The PoC functionality was recently refactored to also meet this new architecture.One to one Rebuild is weird. Not only can it be very difficult, but it doesn’t always make a lot of sense.First of all it is difficult and you will need to if put a lot of work in implementing functionality that was ‘easy’ to build in forms, but is more difficult in ADF. Don’t be afraid to discuss possible layout changes and minor functional changes. It can save a lot of time.The implementation of search behavior that I described earlier is a typical example.Second of all, if you do 1 on 1 rebuild, you don’t use any of the new web 2.0 components and functionality.If you know the ADF Components you can really build flexible and dynamic layouts with typical web 2.0 functionality.
- What functionality do users actually use in the forms application.Is there need to rebuild it all, or can we leave out certain features.Example: Searching a book on part of the title takes for ever in the backoffice database.Users know this. The way they work is: Surf to Website, Search on the website, copy ISBN, Search in backoffice via (Indexed) ISBN.Automated migration) for implementation like simple table or form functionality this can be true, but for more complex forms you need to find the best of both breeds. Partially re implement, partially automated but also
- Besides Architecture, Standards and Guidelines are essential when building an ADF application.Because ADF offers you zillions of possibilities it is important to document how certain features are implemented.Questions likeWhere do I put my buttonsHow do we implement SearchWhat alternative do I use for Forms Functionality a, and what for bHow many records do I show in a table.How is the layout of my tableHow many record can I select in a tableDo I use filters in a tableWhen can I edit records in a tableThese may look like simple questions, and the actually are, but if you do not set standards for this, your application will soon become a swamp for users, because every developer implemented it in his/her own way.During the project we documented lot’s of how to’s and best practices and guidelines in an ADF Cookbook.We can use this in future projects, and is also used as a reference and as technical documentation.
- There is a lot that cannot be fit into the timeslot we have here.I however have to mention the Software Factory. Usually you will not wait till the end of the projects for implementing this.Versioning, Unittesting and Continuous Integration need to be in place at the start of the project. We had unittesting and versioning setup at the start. Continuous integration was setup at a later stage because there was not a build server available.
- Process