I have been tasked with replacing a legacy system written in Oracle Forms & Reports and with an Oracle Database. The system contains around 100 tables and about 200 screens and reports. There can be 3-4 developers maintaining the system at any given time.
From what I’ve seen with CUBA, it looks very promising. However, most of the tutorials that I’ve seen with CUBA Studio illustrates going from nothing to something. In other words, it goes through entity creation and database creation, adding business logic and screens all in the same project. I don’t see how this could work when there can be multiple developers working on the same application, but different screens/reports, at the same time. I would guess from my limited research that application components would come into play here because in most of our screens/reports, it uses the employee table/entity.
So I’m a little confused on whether CUBA would be able to fit my needs. If so, how would one go about structuring projects so that multiple developers can work on different aspects of the system? Can one project be one screen whereby the underlying tables it uses would be application components? Am I making any sense here?
I don’t think this should be a problem with Cuba. I would probably slice the functionality vertically: have a single developer working on a particular function (database tables, services and screens), rather than having one developer doing screens, another one doing tables, another one doing services etc.
Cuba projects are Spring/Vaadin based, so you can just put the whole thing under version control (there’s nothing special about the way Cuba works here), without having to worry about binary files etc.
Yes, you can replace Oracle Forms & Reports application with CUBA. The amount of work may vary depending on the complexity of your existing application. I don’t have enough details about your business domain, screens complexity, etc., so it’s hard to estimate migration time. The set of the UI components in CUBA and Oracle Forms are very similar, so there should not be any issues with migrating screens.
The high-level plan may look like this:
Replicate the data model of the existing application in the project. You can use CUBA -> Advanced -> Generate Model menu in CUBA Studio to create an initial entity class hierarchy. Usually, these classes will need some fine-tuning to represent your data model properly.
Create Services over existing PL/SQL packages in the database.
Create CRUD forms for the basic operations with data
Migrate security roles and access groups
Reimplement screens using CUBA and services.
Reimplement reports.
Potential risks:
The application’s business logic is implemented in Oracle Forms triggers - you’ll need to reimplement it in Java.
You rely on Oracle Forms specific things heavily. For instance, you use a lot of stack canvases in the UI or your users prefer Forms Query mode and use complex predicates using :param functionality.
Your Forms application runs on client’s machines (if you use 6i, for instance) and you need access to the machine resources (e.g. local USB port).
As for your question regarding collaborative work:
it is not a big problem if you use a version control system (VCS). We prefer Git as the VCS, but you can use whichever you prefer (SVN, Mercurial). And Ray is right: try to assign a full piece of functionality to one developer - from backend to UI. It is Java all through and though anyway.
The legacy system was built before any version control system was available. We’re talking a system that has been running, and subsequently upgraded through the various iterations of Oracle forms, for a couple of decades. Not sure why we didn’t use version control later but I guess if the existing process works then we just kept going with it.
Your high level plan mirrored what I had in mind. The risks you mentioned are really only #1 that applies to us and we have Java experience. Initially, I will be the one that is doing most of everything just to get started. It would be a learning experience that I will be able to pass to the other developers and then I would think the separation of duties would apply then.
We currently have our source code on one machine, the database and application server on another machine. Each of our local development machines have oracle forms & reports developer installed and sqldeveloper for database specific tasks. No local databases used. We check out the form or report to our local machine, make the changes to the form/report and compile against the remote database. Then copy the compiled binary to the application server directory, launch the application and test. That’s pretty much our process for development.
That said, I have a question on the organization of the system in CUBA. I generally would not want all 200 screens, business logic, and entities all in one monolithic CUBA studio project. So in CUBA, how would the development workflow happen? Would everything be done in CUBA studio or is it a combination of editing individual files outside of Studio? I guess what I’m trying to figure out is how much of the system can be divided up into separate CUBA projects? And can each project use a remote database instead of a local one? Is there flexibility here?
A CUBA application, just like any other application, will benefit from architectural boundaries between bounded contexts. Those boundaries can be achieved by splitting a monolithic application into different sub parts.
CUBA provides a encapsulation mechanism called application-components which basically put different sub parts of the overall program into different CUBA projects that can be developed and maintained independently.
I would support Mario’s suggestions. Only one thing I came across when developing (even larger application) to manage common master data say Customers, Account number from Accounting module etc. as examples which are literally be used in all or most of the modules. In the app Component scenario, how can we manage this, any thought may help.
Yes, it is possible to split CUBA application to a smaller components as Mario mentioned. But to do it properly, you need to decompose the existing application and figure out base functionality. After implementing this, you will start creating add-ons on top of it. And then you can either build a big monolithic application by composing all the add-ons into one app or create smaller applications for different business roles, but they will still share the same database.
If you decide to decompose your application, you should not keep all the code base in one CUBA Studio project. Every developer will be able to work on their add-on independently.
As for the database, I just don’t understand what you want to achieve. You can install local database for development, you can use remote - CUBA is pretty flexible here.
What I wanted to point out in regards to the confusion about the database is that none of our developer machines have any databases installed. The database our developers connect to reside on a remote server. I point this out because the tutorials I’ve seen uses a database installed on the local machine - to keep it simple I guess. But since you pointed out that a remote database can be used, then that is great.
Yep, exactly. In our demos, we usually use a local in-memory database just to keep things simple. You can use local or remote database, there is no difference.
Thank you for all your replies. I’m sure I will have more questions as I get more into this project, but first, I need to get a test environment setup.
I have been thinking about this solution for a while now and I would like to run it by you experts to see if this is possible.
Each screen will be a separate CUBA project. They will be deployed to a tomcat server as a different WAR files. As I understand it, each WAR file is accessed by a URL.
Then I will create an Electron app where it’s sole purpose is to access those URL’s. So for example, when the user launches the Electron app, it will fetch the login screen from the server, then when logged in and roles are fetched from the database, the window is replaced with a menu. The menu is a tree hierarchy of different screens they can go into and is built depending on what the user has access to. Then as the user launches items in the menu, a new window pops up and fetches that screen from the server via a URL.
This closely mimics the Oracle Forms application that it is replacing. The only difference is that it is no longer running in a Java applet in Internet Explorer.
Yes, you can open multiple windows and switch between them using tabs. In CUBA it is the default behavior. I guess using Electron will be an overcomplicated solution.
Could you share some typical UI from your Oracle Forms application, please? I just want to see what you’re going to achieve. I used to work with Forms from 5 to 9i and I’m pretty sure you can replace almost any Oracle Forms screen with CUBA unless you have very complex custom Java components in the UI.
The screens are pretty simple but the users are pretty clear that they need to be able to see a couple of screens at the same time. One screen could be a schedule while another screen can be some performance data. I can think of one scenario where a screen would need to communicate with the other screen so that is why I went with the Electron route with their IPC mechanism. Anyway, screens opening up in tabs, while I don’t mind, I have a feeling that it would be inconvenient for the users to drag the tab to a different area on the desktop to get a new window, then resize the window to fit the screen. Not all screens are the same size. Some are quite large while others are small.
having multiple tabs open in different parts of the application could probably be solved by using dialogs heavily and all with the setting modal=false. See Dialogs - CUBA Platform. Developer’s Manual
Generally, I would probably try to rely on the browsers capabilities and just use browser tabs. I see that you have the situation to update a system and still take the users with that change. But in this case, you could argue that normally people are pretty aware of the concept of tabs in browsers.
Mario is right, you can play with dialog mode to see several windows in the same workarea.
But if users want to see two sets of data on the same screen, you can try to implement a dashboard for them. We have a tutorial on youtube: Dashboards Add-on Video Tutorial - YouTube