...and thus your forms automagically disappeared

Editor's Notes

• #2: Process
• #3: 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.
• #4: 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
• #5: 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.
• #7: 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.
• #8: 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.
• #9: 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
• #17: 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.
• #18: 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.
• #19: 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’.
• #20: 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.
• #22: Like : WizardsAnd More
• #24: 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.
• #26: 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.
• #27: 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.
• #28: 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.
• #29: 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.
• #30: 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.
• #39: 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.
• #40: 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
• #42: 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.
• #43: 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.
• #46: Process