We are almost at the end of our Forms migration to 10g on IBM AIX. I received some emails regarding the points to watch out for. As you can imagine by reading the previous posts, the migration as the forms module are concerned should not take that long especially if you use JDAPI. Somme annoyances here are mostly with WEBUTIL functionnalities that you need to implement (replacing host, file transfer, image treatment etc.)
However, before even starting the project, you need to do a THOROUGH assessment of your current application and how it is being used. Please be as thourough as you can get in this phase. Otherwise you might have big surprises later on. We have had some really nasty surprises during our journey and that was mainly due to printing on AIX among other things.
First thing to consider is the application server and the platform you selected for hosting it. If it is Windows, then no major hurdles here. If you move to a LINUX/UNIX/AIX platform, then you will be dealing with the PRINTING problem. Direct printing is no longer available in 10g and the alternatives are not worth looking at (direct print PJC and orarrpt). I am talking here about mission-critical applications.
Second problem is the font problem. Expect major headaches here since your developers will be working on Windows machines and your reports are deployed on a LINUX/UNIX/AIX machine. Fonts are not the same and you will have to work on getting the same fonts on LINUX/UNIX/AIX. Not an easy task.
If you have some special printing requirements like we do and I mention here specifically printing on special papers, special paper sizes, automatic printing on designated printers and duplex printing, then you are in for a surprise and a big one I might add. Those are not possible straight out of the box and you will have to do some really nast setups on your report server.
I have spent about 3 days trying to find solutions on those simple requirements. I am still puzzled that there are almost no mentions about those issues on the OTN forums or anywhere else. Either people are not using IAS on LINUX/UNIX/AIX or I am missing something here. At any rate, I thoroughly searched Metalink for answers and came up almost empty handed.
I managed to work out solutions for those problems but it has been tough. I will document the solutions we implemented in an upcoming post.
Finally, the other major problem deals with all the tweaking you have to perform on the forms and reports server. There are so many small things to watch out for and which will take hours to fix. Now, if you get a firewall in the loop and most likely you will have one, then expect some further tweaking to get everything working.
Anyway, a lot of fun if you move to a LINUX/UNIX/AIX platform.
Based on all of the hassles we went through, I am tempted to say that LINUX/UNIX/AIX is not really a good option if you have some real printing to do through your application. Better to stick with windows 2003 or 2008. At least Microsoft has put in place a platform that works.
Where to get help: OTN, Metalink and double check whenever you suspect that litlle looking parameter in that configuration file ....
P.S: Did I mention that all our reports are in French and that characters with accents are replaced with greek characters when printing using Postscript straight to the printer. What a waste of time just to get that one line somewhere stating that you can't get those accents unless you convert your postscript output to PDF and then print it using the PDFPrint plugin.
Forms migration on UNIX- almost the end!
There is a migration tool, PITSS.CON, that can help you with a lot of issues you face with a migration to 10g. For instance, when moving to Unix you also run into case sensitivity issues. PITSS tool can fix all case sensitivity issues in minutes across all your forms in you application. If you need to make a single change in many, many places you can do this automatically with the tool.
Oh yeah, you can fix almost all of the Report issues that comes with going to 3-Tier Web Forms too. You can change the font on all of your Reports to one that is supported in Unix with extreme ease.
A lot of what is covered in Metalink, OTN, etc is incorporated in the tool. So you can get on with the things that are not so mundane. In other words, let the tool get your application running in 10g, then you can test and work out the few remaining issues.
The best part is that the tool is supported by people who have been migrating forms for years. They already ran into your problem, so they know what you need.
I think you should have gone at least through this post and the other ones on degenio.com before plugging in the pitts tool.
I have already the tool that did the migration and it is called MouliForms and it is free.
As far as the problem I reported with reports on UNIX I do not believe they can be fixed by a migration tool. They are too specific to the UNIX platform used for deploying the Application server.
So, anybody going for a migration should expect a lot of hand coding and tweaking.
As far as the migration itself, with JDAPI, it should not take that long.
However, for those that have the money for a migration tool and consulting expenses, then I don’t see any problem with a commercial tool.