APEX 3.2 won't include much changes in the development tool itself, but there will be a killer feature added: the Forms Migration tool.
A lot of people are looking into other directions to replace their Oracle Forms/Reports or Designer environment. Till a few months ago Oracle themselves pushed you towards JDeveloper. A lot of people I spoke to were not that java minded and even started to look after other solutions (non-Oracle). With a Forms to Apex migration possibility I think a real solution is waiting for you.
The main reasons I believe such a tool has a big change to succeed:
- You want to keep your Oracle investments. APEX is living in the Oracle database so 100% ok.
- You want to reuse your Oracle knowledge. Forms developers know SQL and PL/SQL very good, which is exactly the knowledge you need for APEX.
- You want your migration be so streamlined as possible. Hopefully the Forms2APEX migration tool provides you with that. I don't believe a tool doing the migration for 100% automatically exists, but you should be able to reuse a lot and get a head start.
- You want your Forms environment in a Web 2.0 way, which APEX is providing you.
You can see to the full presentation of Marc here (in German).
14 comments:
Lot of work waiting after the import. But that's a start.
It is a start... Seeing this viewlet the tool only creates very default forms and reports, disregarding the layout defined in the forms definitions. That will be a hard job, because APEX uses the HTML table structure and with Forms you can put items anywhere on you're page.
BTW I can't find the presentation you're referencing...
Cheers
Roel
Remember, this is not a finished migration tool yet. It's just a preview of a tool in development. The APEX Dev Team is redoing some screens (if I read that correctly on David Peake's blog).
However I think it's good that some parts are not put directly in APEX, but that database packages are proposed.
Some things are very clear: data blocks in forms become regions in APEX, LOV's will be 100% migrated, how they will do with form triggers and other logic is not very clear yet.
Roel: the reference to the presentation only works in IE... I know, it's a pain... I even don't have IE on my Mac ;-) For a bizar reason the Oracle online conferences don't work in FF or Safari.
Dimitri
Dimitri, I think ANYONE who knows anything about Oracle Forms will know that what is being shown here is a VERY small step on a VERY long road and to think its a solution to anything other than your most basic Forms is possibly doing a bit of a diservice.
What the Apex team have done is take the XML output from Forms and "transposed" it to the target systems metadata. Loads of people have been doing that for years but thats the easy bit. Here is where it starts getting challenging. Sure you can stick your select statements (but what if they reference Forms side variables)
What do you do with the bulk of your code? Lets face it, emp and dept and some sample stuff will allows look good - especially with some great music behind it! What about the hundreds of Forms triggers - where do they go? Forms Next-Record, validation or navigation trigger? Well its both? So where does it go in your "new" application, UI or system side? What happens with Forms built ins:CALL_FORM, OPEN_FORM, GO_BLOCK, - well with bit of work I could see that stuff maybe mapping but how about DDE, OLE - and lets now forget all the Get_Block, Get_Item built ins and any Forms side variables.
By all means look at this stuff (and I've been meeting with the APEX team to discuss it) but please understand how much of a solution it really is.
Also, please understand that we have always remained committed to Forms and told any Forms customers that if the tools fits for you, then stick with it.
Any considering any of their options forward should consider those two main points.
Regards
Grant
Hi,
Thanks for the update. I was just wondering about one thing:
"Till a few months ago Oracle themselves pushed you towards JDeveloper."
Does this mean they are not anymore?
Regards,
Haavard
Nice post Dimitri.
Although Grant is probably right about "the real value" of this feature, it is still a nice feature. Especially in (sales) presentations these kind of features are always nice to demo ;-)
Regards,
Peter
Grant, thank you for your feedback and insights.
Haavard, Oracle is still pushing to ADF/SOA, but now there's also an alternative.
Peter, yes sure Grant is right, but it's a start. And I still believe an Oracle Forms person will like APEX as it allows him to reuse his knowledge more than any other alternative.
Dimitri
Hi Dimitri
I think the Apex corner is far over selling this feature, some consideration of the challenges it faces would give healthy debate too rather than raising expectations.
And here's the key to the Forms->Apex converter being a dud in your own words (note my bolded emphasis):
"Some things are very clear: data blocks in forms become regions in APEX, LOV's will be 100% migrated, how they will do with form triggers and other logic is not very clear yet"
My personal opinion, the Apex crew will hit the same walls all those Forms->ADF converters did, including Oracle's own staff. As Grant says, converting the PL/SQL logic is a huge issue and not a simple one. Just because Apex talks in PL/SQL like Forms, doesn't mean it can deal with the complete set of Forms PL/SQL APIs. Let's not forget it has to deal with the mess of stacked canvases, JavaBeans, corporate level PLL libraries and so on. And I'm nearly willing to put my money on that in each legacy Forms install, it will be the main large Forms that are used that will cause the most conversion issues. Without a clean conversion of these key Forms, where will this leave the overall conversion process?
So lets wait and see how well the Oracle Apex crew here does and give a critical eye to the solution to let people out there know that there may be no holly grail conversion, they've actually got to knuckle down and do some real work.
CM.
Chris,
Of course I am also interested in what the Apex team manages to put in the converter. On the other hand I don't expect too much from it, for the same reasons you mentioned.
But before you start a (complex) conversion project, I think it would be better to ask yourself the questions :
Why do I want to convert my Forms to Apex?
Should my Apex application be identical to the Forms application? (do I really need 100% conversion?)
Personally I think a conversion project should contain a significant part of redesign, if only to include the Apex specific features.
I know business people and managers do not always share this idea.
Peter
Peter and Chris, I think you make very good and relevant points.
Peter, 100% right,a "typical" Forms application is NOT a typical APEX application, and come to that, neither is a Java/JSF application. They are all different and to aim for a like for like conversion either means you started out with the wrong technology in the first place, or, you are going to end up squeezing a round Forms app in to a sqaure Apex (or Java) hole. (or it could mean you don't understand the technology you are coming from or going to!)
I don't think thats good for anyone.
Chris, I agree, the Apex guys do a wonderful job of evangelism in the true sense of the world but i can't help feeling that the real benefit from blogs and input from community experts would come from "ripping stuff apart and telling it how it really is". After all, we can rely on Oracle marketing to give us all the glossy "isn't it great" stuff ;o)
Anyway, I'd like to see this as a tool to the Oracle developers armoury, which can provide some aid IF its required. But lets all go in with open eyes, especially the following points:
You are not being pushed off of Forms
There are many options including Java, ADF and APEX (and Forms).
Your applications can infact be a mix of technologies/tools
Pick what is right for YOU and your business.
See through the hype (and I'm guilt y of a bit of hype myself).
If we all bear this in mind, we mind find the options are much clearer.
Regards all
Grant
But Forms is not central to Oracle's Development any more, it's a good moneymaker; this annoyed most of our customer base when they went Java and stopped developing Designer.
Personally any time I heard the ADF stuff I switched off.
Now we see a possiblity finally of a decent migration path. Grant R. seems to imply that it won't be that in-depth. However, APEX can do AJAX - so triggers and the like - why not ? If you're going to do something do it right. Otherwise people are going to be out there searching for an alternative.
I don't think anyone is pretending that this is going to be a 'click and forget' exercise.
This tool is going to be a great help to get up and running with a migration project where no help existed before (specifically for Apex I mean).
Peter hit the nail on the head, in any conversion project it is a great time to re-evaluate the current system and to see which pieces of functionality need to be migrating/removed/amended/added etc.
Remember, this is a tool that makes things just that bit easier for people who are already investigating migrating away from Forms. It should not be seen as a 'threat' to forms.
I'm sure there are many happy Forms customers out there, Oracle isn't trying to steals its own customers, it is simply trying to make it easier to retain them if they are thinking of moving away.
John.
Just as a followup, when I said "migration project where no help existed before" I was referring specifically to Forms migration, not the facilities that SQLDeveloper and the Migration Workbench provide (I already had someone email me about those!).
John.
You guys could always look at Lotus Forms if you want to check out an alternative. http://www-01.ibm.com/software/lotus/forms/
Cheers
Chris
(IBM)
Post a Comment