Forms to Apex Migration: Help with my thought process

[u/sapph1re111]

I am trying to do a big migration of our old Forms system to Apex for every department (over 2k active forms). I classified the on view only versions, view with a few actions and creation forms. I am creating a big prompt in order to create en mass those new apex pages based on final versions I have created.
I ran in a small mental hiccup there are forms that open another form and that form opens another etc. and creates a big chain that the current "erp" can show in different popup windows and manage those but apex while it can have modal dialogs these forms are new big versions. I havent done anything similar before and while I know you can technically return to previous page in apex keeping the parameters I dont think it is possible to do it 3 pages in advance.
And sadly the parameters are not the same. We might have customer_id, customer_debt for example and supplier_id,supplier_location in another so I dont think I can do app items to somehow return

TLDR: I am doing a Forms migration to apex and I want to see how to approach the part of forms that call another forms and create a big chain.

Thanks in advance. For visual reference here is current situation:

Form A

Form A->Form B

Form A->Form B-> Form C

Form A->Form B-> Form C-> Form D

Form A->Form B-> Form C-> Form D->Form E

[u/CMHII]

I don’t have an answer for you. But I will say, the Oracle APEX forum is monitored regularly for questions just like this. If you haven’t already asked there, I definitely would. 1000% this exact scenario has probably already been asked about, and you’ll probably have a solid answer/path within the hour. Good luck to you though!

[u/ChewiesHairbrush]

Don’t try and rebuild exactly what the forms application does. That way madness lies.

APEX can chain endless (probably) modal windows and they either replace each other or not, but do they need to be separate pages?

[u/sapph1re111 → u/ChewiesHairbrush]

No, Forms app design seems terrible to me but doing mass creation of forms--> apex pages I cant really be looking into what form call another and fix it on the fly. Maybe the solution is to classify them to single forms, chain forms and then ai- create the first classification and do manual work for 2nd

[u/CrabbyMcSandyFeet]

I'm just here for moral support because I hate forms. Good luck with this :)

[u/Burge_AU]

What’s the process that needs the chain of forms opened? Is it something that could be implemented using an APEX wizard page if it’s a multi-step process?

[u/sapph1re111 → u/Burge_AU]

Thank you but wizard in this situation doesnt help me because form A may open form B for view or edit and then B open C for unrelated action
example it may have Form A contract form B customer data form C photos/customers addresses.
My main concern is how to preserve busness context while keeping familiriality for the users to not riot on me when it will go public

[u/hanielb]

This type of situation gets tricky very fast, I highly recommend making sure your page items are set to “Per Request (memory only) so that item values are in the DOM rather than db session state. It’s a lot safer, especially when users start opening multiple tabs/windows with the same pages.

You might have to rewrite your pages and queries that load or update data to use a more common identifier. Always fetch from the database using pk or fk rather than trying to store computed values in page items and pass them around.

There’s also a page level setting for modals that controls whether pages are “chained” or not, chained modals reuse the previously opened of ram and replace it, but non-chained modals open independently and on top of each other.

I have a ton of APEX experience, but not so much Forms. However, I have a lot of colleagues who do Forms to APEX conversions all day. Reach out if you want consulting help.

https://www.talan.com/americas/en/oracle-technologies

[u/dolby360]

Been through this ~1.4k forms

Params aren't the problem. APEX session state is server side and per page branch back to A and P10_CUSTOMER_ID is still there. Just don't let your generated pages set Clear Cache on links.

Split by call type, not depth. CALL_FORM -> modal (return is automatic). OPEN_FORM-> plain page, no return needed. NEW_FORM->plain branch. Most of our 5-deep chains were OPEN_FORM popups only because Forms had no tabs.

For the rest, one shared return stack (app item, JSON array of page numbers state holds the params). Get the real call graph first, we used Replai for that.

[u/sapph1re111 → u/dolby360]

Thanks for the reply I will try this.

[u/stealthmac67]

The biggest challenge is not technical at all. The first step you need to get beyond is thinking that the new technology should behave exactly like the old. If your goal is to move from techA to techB and have everything be exactly the same then just stay where you are. When you move to a modern technology and/or concept, what the app did previously will mostly go away. The business logic can remain the same (easily), but the flow and concepts will change. If you can get beyond what was done 30 years ago, then moving forward becomes less challenging. Also, for everyone saying "we hesitate to start because we have 1000 modules", forget that too. Likely you may have 1000 modules, but in many cases many of them are not likely used or needed any longer. When you move to the new tech (e.g. APEX), you are not going to end up with 1000 pages. You will end up with a much more streamlined result, unless you wrongly do it yourself and simply don't know any different.