Rhenus Netherlands Uses Formspider

A short demo of the Rhenus Application built with Formspider

Who are we?
Rhenus ICT Services Netherlands is part of Rhenus Logistics, a large worldwide logistics company. We provide ICT services for the Rhenus Companies in the Netherlands.

We have created a substantial central Logistics ERP system in Oracle Forms 10g (over 1100 100% Designer generated forms / 350 Oracle Reports / 500 users).

For web applications, like Online booking and Track&Trace applications, but also for some internal web based applications, we use Oracle Apex 4.

We have a development team of 7 developers responsible for developing and maintaining all our in house built applications. All 7 developers can develop Oracle Forms, two currently can develop in Oracle Apex.

Screenshot of our Oracle Forms Application

Screenshot of our Apex application

Why not stay with Oracle Forms / Apex?
There are several reasons why we believe we need to start thinking about how to migrate our Oracle Forms application to another technology:

  • We are an Oracle Designer (Headstart / CDM Ruleframe) shop, but Oracle Designer is proclaimed dead by Oracle themselves (and so are Headstart and CDM Ruleframe). Designer is no longer included in version 11g and higher, so we are stuck on version 10.
  • Oracle Forms developers will be harder and harder to get.
  • We get more and more requests to build new web applications. Very soon web development will require more resources than the resources needed for Oracle Forms developments.
  • We would like to have a single development environment to build all our applications. This will make our small team more flexible. It is not an ideal situation for a small team having to maintain two development environments.

How does the Roadmap for Oracle Forms applications look like according to Oracle?
In short:

  • upgrade to latest version 11g / Weblogic (but what about the Designer shops??)
  • integrate / embed in new technology (like web services)
  • new development in JDeveloper/ADF or Apex

What are they saying here? Just keep Forms running and rebuild in JDeveloper/ADF or Apex later? Will we be waiting for the silver bullet? Oracle will not create a migration ‘silver bullet’ from Oracle Forms to jDeveloper/ADF or Apex, and it is for a good reason. Due to structural architectural differences, a (automated) migration from Forms to jDeveloper or Apex without rearchitecture is simply a bad idea, if technically possible at all.

Some documents about above statements:
- Article by Grant Ronald, Oracle Forms product manager.
- Oracle Statement of Direction for Oracle Forms/Reports/Designer

Embedding Oracle Forms in new technology could be a quick solution for some requirements short term, but in the long run I think it will only make your environment more complex and will make it harder to get away from Forms when you want to.

What about moving to JDeveloper/ADF?
We did a pilot several years ago with Oracle JDeveloper to see if this would be the solution we needed for developing the web applications we needed at the time.

We experienced a huge learning curve for Oracle Forms developers to make the transition from procedural / data oriented way of building applications to the Java / object oriented way of development in JDeveloper/ADF.

After several months of extensive training by JDeveloper experts and building a (simple) pilot application we never got the feeling we were in control.

At the same time, we started looking into Apex. After following a tutorial for 2 days, we rebuilt the JDeveloper pilot application that took several months to build in a couple of weeks. So we left JDeveloper for what it was, started using Apex and never looked back.

I did keep an eye on JDeveloper since then, and although it improved a lot and moved from UIX/Struts to ADF, I still think it has a huge learning curve for Forms developers, is a very complex environment and probably will not give the productivity we experience now with Forms.

Also, for a small development team, it will be very hard to learn and master JDeveloper/ADF/Java and also maintain and enhance the Oracle Forms environment. This is a very big issue in my opinion. Not only will it be very expensive, but also have a very big impact on the productivity of the development team for a long period of time during the redevelopment project.

So, what about moving your Forms application to Apex?
We don’t think migration of our Forms application to Apex is a viable option.
There are several reasons for this:

  • Apex (as JDeveloper) works in another paradigm, the web page paradigm. Creating a web-page based application in my experience takes another mindset then developing an Oracle Forms application. You will have to redesign your application completely.
  • In our experience, when Apex applications get more complex, it gets more and more difficult to maintain, enhance and refactor the application. The type of systems we build are not fully designed up front. They will grow as you go. In our experience, building an Apex application requires a lot more upfront design as opposed to an Oracle Forms application, because redesigning an Apex application (screen design and application structure) is not that easy and will take a lot of time.
  • Often you will have to work around the Apex default functionality to get things done, for example to get around intermittent page submits when working with complex wizard style pages. This working around Oracle Apex standard features to get things done requires extensive knowledge about JavaScript, HTML, CSS and Ajax. Of course you can learn this, as we have, but it complicates things quite a lot. Also you will be responsible for these workarounds to work correctly from the moment you build them (cross browser support for example) instead of relying on the Oracle Apex framework features.

Besides the above points, there are several other issues with the Oracle Apex product itself that in our opinion makes Apex not the replacement development environment for our Oracle Forms application:

  • No transaction layer. Page navigation causes submits. For example you will have to create workarounds in order to be able to span a transaction over multiple pages.
  • Refactoring is hard. In Apex there is no separation between the data model, UI layout and screen behaviour (Apex lacks a model layer). All is in the same page definition. No impact analysis whatsoever when you for example want to change an application item name. You will have to look for it everywhere.
  • Debugging can be a real pain. Working with Apex session state can be very frustrating. Also very hard to get a good understanding of the sequence of things that execute when debugging (application processes/page processes/dynamic actions etc).
  • Limitation in layout. In Apex you simply do not have the flexibility in UI design you would like to have.
  • The inflexibility in layout and not having a separation between data model and UI layout and behaviour makes prototyping screens a lot harder then we would like it to be when developing a system.
  • Web-page paradigm does limit the things you can do while working in an application. For example it is not possible to work on an input screen, pause what you are doing, do something else in the application (commit that), and then continue to work on the input screen. With Apex you must open another browser window, and log in to a second session.

These are some of the things we experience while working with Apex. It might be that we are just lousy developers, or we just don’t get Apex or use it in a wrong way, but again, this is what we are and have been experiencing while working with Apex for several years now.

What were you looking for in a new development environment?
Ideally we were looking for a development environment which allowed us to:

  • use as much of our current database PL/SQL code as possible
  • use our developers expert knowledge in PL/SQL
  • use a single development environment to create internal use applications as well as customer facing web applications so all our developers can be assigned to any development project
  • should be easy to learn for our Forms developers
  • should be easy to set up and maintain
  • would allow for a controlled gradual migration of our Oracle Forms applications

Looking at several options we found Formspider almost a year ago.
I downloaded Formspider in February 2012 and started exploring it. After a while we decided to properly test Formspider by building an Application Framework like we have built in Oracle Forms.

When building an Application Framework you touch most of the aspects that your applications will need, like authentication, authorization, look&feel, navigation structure, error handling etc.

It all worked out very well. We were able to develop the framework we needed. Sure there are options you would like to have that are currently not available, but we did not encounter any showstoppers. The Formspider team builds features once they are needed by their customers, and i am convinced that the features we would like to have can be built into the Formspider framework in due time.

We found Formspider easy to use. We never got any training from Formspider, only used the demo’s and tutorials on the Formspider website to teach ourselves.
I have trained two Oracle Forms developers until now, and they also had no problem learning Formspider. Building a Formspider application is very similar to building an Oracle Forms application. They both use the Application paradigm and the Formspider Event – Condition – Action architecture is similar to the Oracle Forms architecture.

Learning Formspider for a Forms developer is in our experience much easier than learning Apex, and much much (repeat 10 times) easier than learning JDeveloper/ADF.

Screenshot of our Formspider Framework application

Right after the evaluation project, we received the request to build a new web application. Instead of creating it in Apex, we decided to develop this new system using Formspider and the application framework we created during evaluation. This application is planned to go live in the second quarter of this year.

If this project is successful we will rebuild all our web applications wıth Formspider, so we will have a single web development framework.

After that we will start looking at migrating our Oracle Forms application.

A longer demo of the Rhenus Application

I think Formspider can offer a very good migration path for Oracle Forms applications.
In short the migration could look like this:

  • deliver new functionality in Formspider
  • stepwise migration of current Forms functionality to Formspider and keep current Oracle Forms applications working on same code base

It will be relatively easy keeping both application’s functionality in sync for the development team. Both applications use the same PL/SQL code, you have only the screens to keep in sync (if you need to have two way access to the functionality).

As with all projects, there will be challenges, but my experience with what Formspider can do already, and looking at the Formspider road map, I am confident that Formspider can deliver.

Repository based development has big advantages and makes Formspider applications future proof. I am happy to leave the client side coding to the Formspider Team.

Our small development team needs to concentrate on business logic and delivering the functionality our business needs as quickly as possible, either via the Internet to our customers or internally to our employees, and I think Formspider can help us do exactly that.

Michiel Arentsen
Manager of Application Development
Rhenus Netherlands

  • mcfs

    Wow, very good page on Oracle Forms and it’s future. I am an Oracle Forms developer from Sri Lanka. We are of course stuck here and do not have the options of you guys have in Holland. Never heard of FormSpider though.

  • http://www.gerger.co Yalim K. Gerger

    Now you have. :-)