Inspired by Stack Overflows annual development survey, in December of last year, we ran a survey of 25 questions to better understand the state of APEX development in the community. A big thank you goes out to all the 318 participants for taking the time to contribute. From the survey results we have compiled the following report which you can download by clicking the image below:
Stack Overflow 2018 Developer Survey Results
The old issues of cross browser support and browser limitations are long behind us now paving the way for this meteoric rise. There is now an ever growing demand for more sophisticated and complex web applications to replace desktop applications or modernize legacy web applications. The building of these sophisticated applications introduced a new design approach, namely Single Page Applications (SPA).
Stack Overflow 2018 Developer Survey Results, both Angular & React are SPA Frameworks
Isn’t it great to be a web developer?
Well “Yes” and “No”, due to an explosion of frameworks/tools/libraries, it makes choosing the right tools for your project(s) really hard. Many frameworks have come and gone whilst others have undergone complete rewrites. The reason is that web development is hard, and the job of making it easier is still being figured out, so everything is constantly evolving. We all use frameworks/tools/libraries as we want to make our jobs as easy as possible whilst giving our users the best possible application we can, within the budget and time constraints enforced on us. Low code and rapid application development frameworks are (becoming) more favourable, we just want one that will have longevity and be flexible enough to meet our current and future requirements that we’re not currently aware of. When building data centric applications, we personally think Oracle APEX fits that bill and we will explain why….
Web Application Design Patterns
Before we talk about APEX, first, let’s talk about web application design patterns in more detail. What are the web design approaches available to us? Well, there three main application design patterns that you can follow:
Multi-Page applications (MPA)
Single Page Applications (SPA)
Hybrid Approach that is a multi page variation of single page applications (MSPA)
MPA development is the traditional style of development that has existed since the birth of the internet, HTML pages are rendered via a browser GET request and the Saving form data is done via submitting the page using a POST request and then the browser re-rendering the page again. This type of application is noticeably different to how a desktop application behaves. Could you imagine reloading your desktop application every time you made a change? The reason for this distinct difference is that the web was not designed for application development, application development was adapted to the design of the web. Applications following the MPA design pattern, their HTML/Pages are traditionally generated on the server. Think ASP, PHP, JSP, or our personal favourite Oracle APEX.
Multi Page Application Design
Single Page Application Design
The hybrid approach is basically an application made up of multiple single page applications which are more likened to business modules. All interaction is done via AJAX, you just might switch your main viewing page to another when visiting a different part of the application. This helps reduce complexity and the footprint in the Browser/DOM. Could you imagine how much HTML would be rendered if E-Business suite was in one HTML document?
Client Vs Server
Did you know? The overhead of the APEX engine generating an APEX page is less than .02 of a second. There have been many discussions on the scalability of APEX, none better than the usage of Oracle itself mentioned here by Joel Kallman.
So what type of framework is APEX?
APEX was first designed in 1999, and by design is a multi page application (MPA) framework, since this was the only design pattern at the time. APEX is now almost 20 years old and has constantly evolved. It is a great low code development tool that allows us to create many types of web applications or websites declaratively. APEX, over the years, has included more and more feature rich functionality and adopted more and more AJAX capability i.e. partial page refresh which is the cornerstone of an SPA design but this capability is only limited to refreshing/filtering/saving reports or charts, or executing PLSQL Code. DML Forms require a page submit.
To explain the concept behind APEX in a bit more detail, the applications we build with Oracle APEX are a set of HTML “Pages” which we navigate between to view data or submit to save the data. We design our applications with the concept of shared components that we define once to show up on each page so that it appears like a regular application. e.g. navigation menu, top toolbar etc. Pages have to reload every time a user performs a submit action to save a FORM, or when navigating to other another page. The following is a demo showing this multi-page concept and how disruptive it can be for the end user when switching between pages.
There are many types of applications or websites that APEX is suited for, but building a sophisticated Single Page Application is not possible “out of the box”, and thus limits you to building an MPA style application. The reason is that it was simply never designed for this purpose.
What are the main SPA frameworks?
Why would I want to build a Single Page Application in APEX?
APEX has many unique characteristics that you won’t find in any other framework. The following 6 characteristics sets it apart from every other development framework.
No.1: it runs within the Oracle Database, it’s at the same level of your data negating the need for a middle tier (Java need not apply). It’s perfect for data centric applications. You have full access to all database capability, and as of 18c the Oracle database packs a very long comprehensive set of features.
No.2: it’s meta data driven. Using SQL you can query everything that is designed on your page, or in your application, and you can do this at the point of page rendering or in every AJAX callback. You can even generate applications/pages/regions etc. using the same API’s the APEX builder uses to create your applications. The power and solution capability this gives you as a developer is not widely publicised and in our opinion is really underrated. There is no other development framework out there that has this design, APEX is truly unique!
No.4: we can build visual appealing applications really fast with APEX, and they are super easy to deploy and maintain.Thanks to the universal theme and Theme Roller you can achieve a modern look and feel whilst adhering to corporate colour conventions. APEX has an extensive and mature PLSQL API, and also built-in REST support thanks to ORDS (Oracle REST Data Services). As shown in the earlier infographic, APEX is continually evolving and adding more and more features.
No.5: the low code design makes it easy for beginners to become productive, whilst it provides full control for experts. Comparing this to a SPA framework, it caters for a much broader range of developer skillsets, even business power users can learn APEX! Think of the cost savings in training and development.
No.6: licensing cost, yes Oracle is expensive especially when compared to the many open source databases and development tools out there, but if you don’t have a data foot print above 12G you can use 18c XE, ORDS, and APEX for free. You can also deploy this on cloud providers that can charge as little as $5 a month for hosting. So for people not using Oracle yet there is no entry barrier for adopting APEX. You could even use REST to access data in remote databases if your data requirement exceeds 12G. There are solutions to keeping costs to a minimum for small businesses. For everyone else already using the Oracle database it makes sense to use APEX, it’s really crazy if you don’t.
Lastly there’s also productivity apps that come with it like Quick SQL which is a markdown editor that can quickly build your data model and also generate a dummy dataset. You can also quickly build prototypes using APEX, comparable in time to using a wireframe tool. The difference being you have a functional application to preview, making the choice to use APEX that much easier.
What is a SPA user experience like?
If you are still wrapping your head around a single page application design style, let’s consider the APEX Page Designer introduced in 5.0. Whilst the APEX builder is not a single page application the Page Designer is modelled on a single page design style. Prior to APEX 5.0 there used to be a set of pages that were used to edit pages, regions, items, buttons etc. and you would find yourself navigating from page to page to page. This requires many clicks and page reloads to make your changes.
With the new page designer you can do everything on one page without interruption including saving Form data without reloading the page and keeping your screen context. It makes you somewhere along the lines of 5x more productive and in some cases like the multi-selection/editing capability of items/regions you can be 20x more productive. This is the type of performance benefit end users get from a SPA application over an MPA application. It’s this type of user experience and productivity benefits we want our customers to have in the applications we build. How much more efficiency can be gained and time and money saved when both developers and the application users are more productive using an SPA design over an MPA design? It can be quite a lot!
Can I build a single page application in APEX?
Using out of the box components you can build a single page application in APEX but everything would need to be created on one page. It literally is a single page application (minus the login page). You could argue that you can use dialogs to edit report content defined on this one page but from a technical point of view they are separate pages opened within an iframe within the dialog so they still mimic a single page design but are still using the MPA model since a page with a form is still POSTed back to the server. It’s a very limited design choice and is only really applicable for very small and simple SPA applications. If you start expanding on this iframe approach you will still end up hand crafting a lot of code (just look at the APEX dialog code).
If you are wanting to use APEX to build a sophisticated application, you are going to have to make some design trade-offs following the MPA design. These tradeoffs have an impact on end user productivity. You can however reduce theses trade-offs by implementing your own customizations, but your low code app starts to become a high code app that will take longer to build and maintain, which results in much higher costs. This results in the SPA frameworks looking like the better choice.
So what if you wanted to build a real SPA application in the same way you would a regular MPA application in APEX without losing productivity? Is it possible? The answer is: Yes you can!
Ok, so how can I build a complex Single Page Application in APEX?
Real customer quote today:
“We also produce more quality app dev output than any other team I’ve met in less time, with lower budget and fewer people – I have to be diplomatic when I point this out, lest any feathers be ruffled. The opportunities for us with #orclapex are vast.”
In summary if we look at the features for the design patterns available to us, it makes sense that we choose tools that are flexible and supports both our needs now and for the future. APEX, combined with FOEX ticks this box!
A great feature that has been introduced with Oracle APEX 5.1 is a new way to install / upgrade an existing APEX instance to a new version.
Previously installing a new version of APEX meant shutting down access to that server for your end users for the entire duration of this installation.
Now it is possible to reduce downtime to a short part of that installation.
Here is how this works
Instead of using the script apexins.sql to install APEX into the database, there are 3 scripts to initiate each phase of the installation process. For sake of similarity, all scripts take the same arguments as the original apexins.sql
@apexins1.sql – creates the new APEX schema (ie. APEX_180200) with all tables, views, packages, but no data. In this phase the old APEX version is still active and can be used without limitations.
@apexins2.sql – now all application metadata is migrated from the old APEX schema to the new one. The old APEX version is still active, but in a readonly mode. No applications can be modified, but everything can still be used. In terms of a production system all apps continue to work and all end users are happy
@apexins3.sql – is the final phase and needs the usual webserver shutdown. Now the new APEX schema is being activated and the old one retired. Some leftover metadata (like the activity log) is migrated from old to new schema.
A rather common challenge we keep hearing about at conferences, meetups or in 1-on-1 discussions with other Oracle database professionals: How do I convince my company’s management (or even some of my fellow developers) to try / start developing with Oracle APEX?
While the typical myths surrounding Oracle APEX have been debunked in various articles which you can easily find online, how to you get the buy-in from your management (and fellow developers) remains an open-ended question.
Here are 5 key points that you can use to inform, educate and get the internal buy-in about using Oracle APEX as a development tool:
1. It comes with the Oracle database, at no additional cost
This one’s a bit iffy:
1. If your company is already using the Oracle database, then APEX comes pre-installed and ready to use. You essentially have access to a powerful development tool at no additional cost. Why not take advantage and get the most bang for your buck?
2. If your company doesn’t use the Oracle database – worry not: you can still get the Oracle Database Express Edition (XE). It is a free, small footprint version of the Oracle database that has been around since 2006.
Although it is limited to 11GB of user data, 1GB of memory and using no more than 1 CPU on the host machine, it’s a good starting point to begin developing your first app(s) with APEX. The Oracle Technology Network has plenty of articles on how to set up Oracle XE in different environments.
Note: we do not explicitly endorse one or the other option. Ultimately, it is up to you & your organisation to decide what setup fits your requirements best.
2. Build a prototype
Speaking of developing your first APEX application. One of the best ways you can introduce APEX internally is to build a prototype. Either start from scratch or simply use one of the packaged apps and tweak it to your organisation’s internal needs.
In addition to getting familiar to the key concepts of developing with Oracle APEX, you’ll be able to produce useful applications much more faster than you could with using other development tools.
3. Leverage your skill set
If you’re working with the Oracle database you already know how to work with SQL and PL/SQL. These skills will give you a big head start when in comes to building applications with Oracle APEX.
So, why should management care?
Think of it like this: it could save your company valuable time and money with (re)training the development team if they decide to change development technologies – especially if your company has a team of Oracle Forms developers.
4. Its functionality can be easily extended with plugins
One of the great things about using Oracle APEX is that you can extend its functionality with: either free plugins like those provided by the community on apex.world, or commercial plugins such as our own solution – FOEX Plugin Framework or the APEX SmartPivot Plug-in if they meet your requirements better.
Should your users’ requirements evolve and become more complex, using plugins is a great way to provide extra features without needing to write & maintain the functionality yourself.
5. The APEX community
This one’s probably a no-brainer, but seriously, check out the community that is being built around Oracle APEX. In addition to the official Oracle page here are some other resources to get you started:
Twitter – use #orclapex when asking an APEX-related question and chances are that you’ll get an answer pretty quick
apex.world – there you’ll find a wealth of info & resources: slack channels, job postings, conferences, meetups, trainings, free plugins and much more
BuiltWithAPEX – a community-powered website showcasing apps developed with Oracle APEX, that are being used around the world
Conferences – throughout the year you can attend different events where the APEX community gathers to share their knowledge. Although this is not a comprehensive list, check out at least one of the following events: APEX World, APEX Connect, APEX Alpe Adria, Kscope, DOAG, UKOUG and take the pulse of how APEX as a development technology continues to improve.
Blogs& Books – there’s plenty of technical APEX know-how shared by the community. If you face an issue while developing an APEX app, chances are there’s a book chapter or blog article out there providing the answer. Either that, or go on Twitter and ask your question!
Why should management care?
A well supported tool and an active community are key to getting as little headaches as possible when developing new applications, especially if you are transitioning from other technologies.
We’d love to hear from you and how you’ve introduced APEX to your organisation. Let us know what worked in your case in the comments below.
That Oracle APEX is an amazing tool and rocks low-code development is public knowledge, still we often encounter developers which waste a lot of time and don’t use APEX to its full potential.
You will be amazed how easy it is, try to follow these 10 points:
1. Use the wizards
In APEX you can build up pages manually or by using the Create Page wizard. Usually the wizard is way faster and will build all pages in the same fashion. This helps in achieving a consistent look and feel of your application. It also does some extra work by adding a page to the menu, creating breadcrumbs, and so on.
Sometimes it is also faster to delete an existing page and rebuild it through the wizard, rather than adding new fields manually, ie. when the underlying table has changed.
2. Stick to the standard Oracle APEX functionality
By using APEX wizards you automatically use standard functionality. As such this will have the highest probability to work flawless also in future versions of APEX. Once you deviate from the “APEX way” of doing things, you will slowly drift into a potentially unstable application.
Wow, that sounds cryptic, right?
Here is an example: when you create a form page in APEX, you end up with a default Automatic Row Fetch process on process point Before Header. You now could decide that process point “After Header” is so much nicer and move the process over there.
With a bit of luck your application still works, but might break at some point in the future because Oracle APEX adapts its behavior and decides that this Automatic Row Fetch process has to run “Before Header”.
3. Use settings
Let’s take the “Server-side Condition” as an example. It exists for almost all component types and decides, whether a component is being available/processed, or not. As condition type you can choose a myriad of different options like “Item = Value” or “Request = Value” or “PL/SQL Expression”, where PL/SQL Expression should always be the last resort, as all other declarative options are actually faster processed.
Using a setting rather than coding around it has the advantage of being stable. If a future Oracle APEX version introduces some changes, those declarative settings will be adapted to continue to work.
4. Avoid custom code
As with the settings, custom code should always be avoided, where possible. Why is that? Every single line of code has a certain cost associated to it: you need time to write this code, to fix this code, test this code, and to maintain the code in the future (APEX/DB/… upgrades).
5. Use plugins
Plugins are a great way to extend Oracle APEX and teach it new tricks. Need a new chart type? A dropzone file upload functionality? Extending the Interactive Grid toolbar? A multi-column LOV? These and many more plugins can be found on apex.world or with commercial providers like our FOEX Plugin Framework, or the APEX SmartPivot Plug-in.
In APEX almost everything can be extended as a plugin, which is also a great way of modularization to re-use code. Writing plugins isn’t too hard and there are many great examples among all those open-source plugins on apex.world. So it is absolutely possible for everyone to look at an existing plugin and change it to fulfill your needs.
6. Leave UI fidgeting to the end
Especially for beginners who often try to accomplish a certain look: don’t get hung up on that and leave it be until everything else is done. Then ask yourself if it is really vital to achieve what you have in mind.
The APEX Universal Theme is pretty awesome and provides an up-to-date and modern web look. It also gets updated with each release of APEX and introduces additional features. That means the feature you are looking for might be introduced in the next version. It can also mean your handcrafted workaround (custom CSS) might not work anymore in the next version.
In case you don’t know what’s already possible, take a look at the “Sample Universal Theme” Packaged Application, which can also be accessed via apex.oracle.com/ut
7. Stay lean
This is more a general advise, rather than APEX-specific. You might be confronted with lots of requirements and you try to (over-)achieve. Take a step back and start with a minimum viable version of your application. Show it to others, customer, business unit, and take their feedback. It might already be doing what they want. And this way you can avoid to implement too many pages and features.
8. Reduce complexity
You know this one: let’s say there is a requirement for a form. And another one for a very similar form, with just a few changes. And maybe a third similar form with some additional unique behavior. Which way do you go? One form to rule them all? Or three very similar forms?
This is a tough nut to crack. In retrospect, after being caught in this trap myself quite a few times, I’d say go for the multiple pages/copies route. It seems to be a waste and duplication, but it also allows for very simple duplicates. Once a single case changes, you only have to adapt this one, not the entire (huge and complex) form.
9. Forget your past
Have you just started with Oracle APEX? Are you coming from some other background than web apps on top of databases? Chances are, that your existing experience and expectations influence what you want to achieve now with APEX. Don’t try to replicate Forms, don’t think of Excel, don’t mimic Notes, Foxpro or whatever.
Clean slate, new start. Use the right tool, but also use the tool right!
“Use the right tool, but also use the tool right” – How to develop faster with Oracle APEX Click To Tweet
10. Question requirements
Business units or customers often wish for things they actually can’t comprehend. They don’t know if what they want is feasible, easy to achieve, within the technology limits, or even simply physically possible. Maybe they don’t know yet, that the old client-server days are over and we can now offer different solutions.
Go back and ask them about the requirement(s) and show them some APEX beauty. They might like what they see and forget about old stuff.
How to set up a Grid to Grid master detail in FOEX is part of the FOEX beginner tutorials series – an introduction guide for developers with no or limited experience in building apps using Oracle APEX and the FOEX Plugin Framework.
The end result will be a screen that displays two vertically stacked grids with the top one (an editable grid) showing a list of customers and their contact details and the bottom one (a read-only grid) displaying customer orders.
Here’s how it will look like:
Step 1: Copy the FOEX Template Application
The first thing that we’ll do after logging in to our trial workspace is to make a copy of the FOEX Template Application – Theme 42. We’ll rename the new app as My First FOEX App and assign it a new application ID (in this case: 112233)
Step 2: Create a new page in your application
If you have the FDA (FOEX Developer Addon) installed you’ll notice the new Create FOEX Page button that is now visible within the App Builder.
Go ahead and create a new FOEX page!
Step 3: Create the Customers region
You’ll notice that the new page you just created has a Viewport and Center Pane region set up by default. Select the Center Pane, then use right click to select Create FOEX Sub Region.
Our first grid will display customer info, so let’s name it Customers and select Grid as the component that we’ll use.
Since we want to edit the customer data we’ll change the Allowed Operations field to Create, Update, Delete , instead of Read Only.
In the Table/View Name field add: DEMO_CUSTOMERS . As you click out of that field, you’ll notice that the Primary Key Item and the Select Statement get automatically filled in for you (pretty neat, right?).
Now click Create and your editable grid is all set up.
Note: By default this editable grid is set to Row Editing mode. FOEX provides you with the option to switch to a cell editing mode in your grid, should that suit your users better.
To make this change:
In the App Builder from the left side panel select Attributes, under the Customers region;
from the right side panel, under Settings, find the Edit Mode field and change it to Cell Editing
Step 4: Create the Orders region
To set up your Orders grid simply repeat the process from step 3 (select the Center Pane, then right click and select Create FOEX Sub Region) and make the following changes:
The name of your region should be: Orders
Leave the Allowed Operation field set on Read Only
For the Table/View Name use: DEMO_ORDERS
Step 5: Stack your regions vertically
At the start of this article we mentioned that we’d like to stack the two grids vertically, therefore we need to change the Layout settings for our Center Pane.
Note: If you run the page at this point your Customers and Orders grids will get displayed in separate tabs (as seen below)
To get them displayed on top of each other select the Attributes section for the Center Pane and change the Layout field to Vertically Stack Regions (vbox).
Step 6: Setting up the Grid to Grid master detail
Up until now we just created two regions Customers and Orders – but there is not connection set between them. Our Orders grid displays all records, independent of which customer is selected in the Customers region.
Let’s change that and make sure that when we click on a row in the Customers grid, our Orders grid displays only the information associated with that particular record. To achieve this we will create a Master-Detail relation between our Customers and Orders regions.
In the App Builder right click on the Customers region and select Create Master-Detail Relation.
Note: In a regular APEX development environment, where the FOEX Plugin Framework is not installed, this Master-Detail wizard is not be available.
We have now created a new dynamic action, named by default Customers – Master Detail Relation. All we have to do now is to go on the right side of the screen and find the Affected Elements section, where we’ll set the Region field to Orders (FOEX Grid [Plug-In]).
Because we also want to make a distinction between these two regions, let’s change the UI settings for the Customers grid.
To do this:
select Attributes under the Customers region;
on your right side panel, scroll down and click the FOEX Config button;
change the UI field value from None to Success;
click Ok and run the page
Your end result should now look like this:
You now have a functional grid to grid master detail relation between Customers and Orders!
Try selecting some of the records in the Customers region and see how your selection influences the results that get displayed in the Orders region.
Although this is a fairly simple example, it serves as a good reference point from which you can start exploring the development flexibility and additional functionality that the FOEX Plugin Framework brings to Oracle APEX.
There are many more types of master detail relations that you can set up by using FOEX components and we’ll explore them in future articles.
We are happy to announce the release of FOEX 4.0.1 which is now officially compatible with the latest version of Oracle Application Express: APEX 18.1. This patch set release is a minor release that contains primarily bug fixes and the following enhancement:
You can now choose to ignore grid column filters and sorting from state saving by adding the following additional JSON config settings to your grids:
We’re now busily focusing on v4.1.0 of FOEX and looking to introduce new features like:
Drag & Drop between multiple grids and trees
Drag & Drop re-ordering of grid rows
A new screen capture dynamic action
New color picker item plugin
New toggle switch button
New signature region plugin
Next page scrolling pagination for grids and LOVs
Finally we’re also doing some R&D on whether we can load JET charts into the current page i.e. Single Page Application mode. If we can, this will be a big step in terms of complex dashboard capability with optimal performance.
APEXIA is an Australian IT company specialised in using Oracle technologies. They have been using the FOEX Plugin Framework to build complex business applications for some years now.
We had the opportunity to speak with Raymond Allo, Principal Consultant at APEXIA, and got to know more about his business and about how his team uses FOEX to meet customer requirements and deliver complex business applications with significant time and cost savings.
Q: Hi Raymond! Can you tell us a bit about APEXIA?
Absolutely! APEXIA is an Australian-based IT company with over 25 years of Oracle experience. We specialise in developing business solutions using Oracle APEX and offer a broad range of other services in the areas of Oracle Database, Middleware, eBusiness Suite and Hosting.
Q: You are using FOEX for some years now. How did it all start?
Let me start by giving you a bit of background: our customers have been traditionally larger organisations who have used Oracle Forms / Reports over the years. As these companies began their transition to the Web, things started to change and since Oracle Forms was not suited for creating web applications many of them started to look for alternatives and began developing new applications with Java or .NET .
From our perspective, we felt that building applications with Java or .NET was not playing to our strengths, nor did it make sense since Oracle was providing us with an already great tool: Oracle Application Express (APEX), previously known as HTMLDB.
We used it on a number of projects with great success, including one where we replaced an Oracle Portal project. But realistically HTMLDB/APEX was not very well suited to replace the more complex applications what could be built in Oracle Forms.
We had a good tool to cover our basic development needs, all that was missing were the plugins that would add the custom functionality requested by our customers.
In our research we stumbled across the FOEX Plugin Framework. The functionality you offered was just what we were looking for but at that time the licensing model wasn’t the right one for us, so we went with another tool which was pretty much PL/SQL based and gave us the ability to write complex transactional applications. Similar to FOEX, it was also using Ext JS in its framework.
Q: What made you re-evaluate the FOEX Plugin Framework?
Our productivity wasn’t as good as we’d initially hoped for with this PL/SQL based tool, even after using it for more than 1 year. Furthermore, we noticed that the vendor had no plans to upgrade the Ext JS version used by their product, so we ran the risk of missing on the functionality that later versions of Ext JS would introduce.
Fast forward 15 months later, we touched base with FOEX again and found out that the licensing model had changed. It made an interesting proposition, since we liked the product and could see how much time & money we could save for our customers.
We reached out to the FOEX team and after a detailed discussion I decided to give myself one week to evaluate FOEX and make a decision. At the end of the evaluation I was hooked.
I could go back to using APEX, and with FOEX I could build the complex transactional applications required by ourselves and our clients.
Still we were facing the daunting task or rewriting the application we began building with the previous development tool. It took us 12 months to develop it and now we had to redo all of that – it was not an ideal situation for us. Surprisingly, it took us about 5 months to rewrite the whole application by using APEX and FOEX.
It was the best decision we could have made!
Q: What about your customers? Weren’t they expecting to use the app already?
Of course they did. On our side the decision was easy, but before switching technologies we also had to discuss and get the OK from our customers.
I presented them with a POC of the application that we built with FOEX and told them they could keep on using the already developed application until we caught up, and only then switch over to the new APEX / FOEX app. They liked our POC and agreed with making the change once the functionality was built.
We managed to rewrite 80% of the application in about 3 months’ time.
The added benefit of going with FOEX was that it gave us a much richer UI and had the flexibility to redesign parts of the application in order to take full advantage of that.
Q: Tell us a bit about the app you have developed?
Well, there are actually two applications which we developed. A multi-level marketing application that integrates with a web shop, accounting software, has apps for web sign-ups, sales consultants and for the head office. It integrates with MySQL, SQL Server and Oracle.
The other app, the one that I’ll talk about in a bit more detail, is a SaaS application that will be publicly available in the near future. Currently it is still being developed using FOEX 2.x, but we plan to upgrade to FOEX 4.0 soon. This also allows us to implement a number of nice new features which are on our to-do list.
To describe it: this SaaS application is focused on small/medium businesses which handle repairs. The concept was born out of the requirement of a computer repair company specialising in repairing and refurbishing Apple equipment. We found that we could make the application more generic so that it can be used by other repair and service companies.
APEXIA’s SaaS application built with Oracle APEX and the FOEX Plugin Framework
Since switching to APEX and FOEX we created pre-built templates for a number of different vertical markets, like computer repair, bike shops and small manufacturing. We also developed a special module which is optimised for the car service industry where more specific details for service and repair management are required.
It also handles all sides of a repair and service business: scheduling, inventory, purchasing, sales, invoicing, job and time management. The app has interfaces to a number of cloud based accounting software solutions (XERO, MYOB, SAGE) and to desktop versions of Quick Books and MYOB through simple CSV files.
The system also has interfaces to a number of spare parts supply companies for the car industry for ordering part on business accounts.
At the moment we are still in a closed beta trial with several dozen companies across different industries as our early adopters. One of these companies is a large franchise with 180+ shops across Australia.
Q: What FOEX components were most helpful for building these apps?
The FOEX Form and FOEX Grid were among the most heavily used components, but the FOEX Content Loader was the plugin which provided the most value to our applications.
We found that one of the most loved features of our application is that a user can open up multiple sales orders at the time. This is such an incredible time saver in sales and invoicing.
Let me give you an example: a sales consultant is working on a sales order and gets a phone inquiry from a customer about other order. In most web applications you will have to save the order you were working on, open the sales order that the customer inquires about and when finished, bring back the initial sales order to continue to work on it.
With FOEX we can open multiple sales orders in tabs and work individually on them.
Q: How did you get up to speed with how to build apps using FOEX?
We certainly had some challenges to overcome initially, but the FOEX forum provided us with incredible support during our development – and, of course, it still is one of our first points of contact with the FOEX development team.
Q: What advice would you give to anyone new to FOEX?
In the beginning we needed some help getting our head around some of the FOEX components and how they work in combination with APEX.
We also found that some of the apps that we need to develop now with FOEX require less coding, as more and more can be handled declaratively by the FOEX Plugin Framework.
Q: What about results? How do you measure the success of your projects?
There are many moving parts in each of our projects, so obviously you cannot point the finger and say ‘that one thing alone made me more productive’.
What I can say though is that FOEX allowed us to build applications with a main focus on increased flexibility and a user interface that provides measurable time savings for our customers. One of our customers told us that the average time to service a client has decreased from 10 minutes to 5 minutes since working with the app we developed with APEX and FOEX.
That is a great time reduction for their business as it takes the pressure off the sales consultant and customers waiting in a queue get the support they need much quicker.
FOEX allows us to actually focus on the business solution instead of having to spend time on the technical side of things.
In addition to this SaaS solution we have used this tool to develop a number of applications for external organisations. One of the things that our clients like is that the FOEX Plugin Framework is a commercial product.
For a number of large clients this is extremely important.
We’d like to thank Raymond for taking the time to speak with us and share an insider’s view of how to successfully develop business applications with Forms-like functionality using the combination of APEX and FOEX.
This is yet another example of the flexibility and additional functionality that the FOEX Plugin Framework brings to Oracle APEX, transforming it into a powerful tool with results comparable to other, better established development frameworks.
We are thrilled to know that APEXIA considers FOEX a vital cog of their booming business and encourage anyone who is currently developing, or takes into consideration to develop complex business applications with Oracle APEX, to sign up for a FOEX free trial and take it for a spin.