APEX : Keeping up to date is so easy…

Over the years I’ve extolled the virtues of Oracle Application Express (APEX) because of the ease of development. I think low code tools are a massive boon to productivity. Of course there are some tasks that need alternative tools, but for many scenarios low code tools are awesome.

Something else I find really appealing about APEX is the ease of upgrades. I’m not talking about how easy it is to apply the upgrade itself, because updating Java and Tomcat versions on a server is really easy too. I mean how simple it is from a wider perspective.

I was the first person in my company to use APEX. I used it to write some utility type applications, when it was still “forbidden”. Some of these applications were written over a decade ago, and they are still working fine. In that time we’ve had regular APEX upgrades, and they’ve just kept going. No refactoring. No drama.

Of course, they aren’t using all of the new features that were added in subsequent releases, but the important thing is all that development investment was not impacted by staying on the latest APEX release and patch set. In comparison, updating some of our other platforms and frameworks is a nightmare, requiring substantial development effort and testing.

So it’s not just about improving productivity during the development phase. It’s also about the reduction in the total cost of ownership (from a development perspective) over the lifespan of the application.

Just thought I would share that thought, as I upgrade & patch some production systems… 🙂

Cheers

Tim…

My APEX History #JoelKallmanDay

For my entry in the Joel Kallman Day (#JoelKallmanDay) I thought I would run through my history of using Oracle Application Express (APEX).

I was aware of Web DB, but I never used it. I have this vague memory of taking a look at it, but that was all.

I remember Tom Kyte mentioning Flows and later Project Marvel, and being a Tom Kyte fanboy it sparked my interest. At that point the tool felt kind-of awkward to use, and since I had no pressing need for it, it got relegated to an idle curiosity for me. I would have a play, then ignore it for months. I kept my eye on it during the HTML DB and early APEX days, but it was still not something I used regularly. Typically what would happen is I would need to do something, I would “re-learn” APEX to do it, finish that task, then forget about it for months. The next time I needed APEX, it would often be a new version, so I would “re-learn” it again…

In 2009 I went to ODTUG in Monterey, and there was an APEX symposium as part of the conference, so I made it my mission to pick APEX sessions as much as possible. It was good to connect with some of the folks in the APEX community. Even back then it was one of the most dynamic Oracle communities. I knew a few of the folks already through meeting at other conferences, but it was fun to immerse myself in APEX for a while.

After that conference I slipped back into the habit of re-learn it, forget it, relearn it. I was constantly aware of it, and able to do relatively simple developments, but I never focused on it long enough to get good. Remember, my job didn’t involve that type of development, so it was hard to spend too much time on it.

Since joining my current company in 2012 I’ve used APEX a lot more. It started off with me writing little PL/SQL utilities for people and giving them a front end using APEX. Things like reports on interface staging tables, screens to manage database users and some simple CRUD apps. At that point APEX was kind-of underground in the company. There was only really me using it. As time went on I kept pushing it and gradually it started to pick up some momentum. We now have a few people that do APEX development as part of their role. At this point I’m relegated to managing the infrastructure behind it, and problem solving when people hit an issue. I’ve seen and heard so much over the years that it’s often easier for me to solve certain problems. Also, I know a lot of good people who can help. 🙂

I have this joke that I’ve got more than 15 years “experience” of APEX, but I’m the worlds worst APEX developer. Despite that, I know enough to know APEX is probably the most productive way to develop applications against an Oracle database. The “Low Code” nature of it is great for people with less experience of database development, but it’s also a great way to make skilled developers super productive!

I’ve written a small number of articles about APEX over the years, as well as some surrounding technologues.

So there you have it. My life as the worlds worst APEX developer on the planet. 🙂

Cheers

Tim…

Video : APEXExport : Export APEX Applications and Workspaces From the Command Line

In today’s video we’ll give a quick demonstration of using the APEX command-line export utility.

The video is based on this article, which includes more examples, and Windows-based examples also.

The star of today’s video is my daughter Heli “Hell-Squirel” Helskyaho. Make sure you check out the cloud forming a Pikachu tail above her head! 🙂

Cheers

Tim…

Video : SQLCL and Liquibase : Deploying Oracle Application Express (APEX) Applications

In today’s video we’ll give a quick demonstration of deploying an APEX application using the SQLcl implementation of Liquibase.

I Know what you’re thinking. Didn’t I do this video two weeks ago? The answer is yes and no. This video is very similar to the Liquibase video I did two weeks ago, but that was using the Liquibase Pro client. This video uses the SQLcl implementation of Liquibase, and more specifically the runOracleScript tag to achieve the same thing.

The video is based on this article, which has an example of deploying an APEX workspace and an APEX application.

If you are new to Liquibase and SQLcl, you might find it easier to start with these.

The stars of today’s video are the offspring of Jeff Smith. I had been annoying Jeff on Twitter DMs while he was meant to be on holiday, so I agreed to pay him back by turning his children into international megastars. I take no responsibility for how they handle the fame! 😉

Cheers

Tim…

Video : Liquibase : Deploying Oracle Application Express (APEX) Applications

Today’s video is a quick demonstration of deploying an Oracle Application Express (APEX) application using Liquibase.

The video is based on a new article of the same name, which covers the deployment of both APEX workspaces and APEX applications using Liquibase.

Here’s some other content you might find useful.

The star of today’s video is Jorge Rimblas, making a welcome return to the channel, along with some serious reverb. 🙂 Last time we saw Jorge was in a boxing gym, and his daughters have also taken the spotlight for one video.

Cheers

Tim…

Oracle Application Express (APEX) 18.2 : Upgrades Complete

A few days ago Joel Kallman announced the release of Oracle Application Express (APEX) 18.2.

In a previous post I mentioned the updates to my Vagrant builds to include this version, as well as updates of Tomcat and Java. I’ve subsequently done the updates for APEX 18.2 on Docker too. If you are interested you can see them here.

In addition to this we’ve rolled APEX 18.2 out at work. We already had some installations of APEX 18.1, but many were stuck on version 5.1.4 because of time constraints. Now everything is up to APEX 18.2. We still have a range of database versions (11.2, 12.1, 12.2 and soon to be 18c) at work, and it’s worked fine on all of them.

I spied a couple of people asking about the upgrade process. There’s no difference to previous versions. In the past, if one of the first two numbers change you do a regular install. If it’s not one of those major version changes you download the patch from MOS and apply it. Since this is a major version number change, I installed it in the normal way and everything was fine. I’m not sure how this will work going forward, as I suspect all releases will start to use the new version format, so does that mean every release from now on will be an “install”, not a “patch”? (see update) Someone has probably discussed this already and I missed it. 🙂

I only have one little gripe about the upgrades, which is I have to run an ORDS Validate once it’s complete to make sure ORDS is working fine. It would be really nice if APEX could fix whatever gets broken in ORDS, so I don’t have to do it. It’s just one less step to do… 🙂

Happy upgrading…

Cheers

Tim…

Update: The subject of install vs. patch was raised at OpenWorld 2018. I sounds like the current plan is to get rid of patches and take the install approach each time. The APEX team are working on reducing the downtime associated with the upgrades…

Hey DBA, install/update APEX!

I recently got a question about APEX, which in itself is kind-of funny as it’s a case of the blind leading the blind, but as a result of that question it became apparent the poster was running a very old version of APEX. My first reaction was “Dude, you really need to upgrade!”. It was at that point I was hit with a line I’ve heard a lot over the years.

“Our DBA(s) won’t install/upgrade APEX!”

This gets on my nerves for a few reasons.

  • APEX is a free (no cost option?) tool. Why would you not take advantage of it if it fits your purpose?
  • Even if you don’t want to use APEX directly, it comes with some useful code. I use the APEX_JSON, APEX_WEB_SERVICE, APEX_DATA_PARSER, APEX_ZIP and APEX_MAIL packages all the time from PL/SQL. Why would you hinder your PL/SQL developers by not giving them access to useful stuff?
  • If you already have APEX installed, why would you possibly think it is good to run an old version? Like any other piece of software the upgrades include bug fixes, not just new functionality. Are you really happy about running with un-patched functionality?
  • Of course the newer versions have improved functionality, which is just nice to have. 🙂

I guess I can kind-of understand companies/people who don’t want to install an extra product into the database as it’s another thing to manage, but I really don’t understand people running old versions. I see nothing but disadvantages in that…

So back to the title of this post, “Hey DBA, install/upgrade APEX!”

Cheers

Tim…

Oracle Application Express (APEX) 5.1.1 : Live on Production Systems

I wrote a post a couple of weeks ago about our roll-out of APEX 5.1.1 to our Dev and Test systems. In that post I said we would probably go live pretty quickly. I intended to write a quick post to say when it happened, then promptly forgot… 🙂

Just a quick note to say there were no issues found in our Dev and Test systems, so we quickly moved it out to production. I think it was less than a week from start to finish.

As always I feel the need to point out that our usage of APEX is quite basic. We don’t have loads of applications and the ones we have aren’t super complex, so it’s pretty easy for us to quickly get some confidence in a new release. I’m not suggesting heavy APEX users should be quite as rapid as us. That said, I think it’s nice to let people know that this stuff does do what it’s meant to. 🙂

We now have 5.1.1 in all our production systems. Happy days!

Cheers

Tim…

APEX 5.1 Installations and Upgrades

APEX 5.1 was released for download a few days ago. I tried doing an upgrade against an installation on a VM at home and it worked fine, which was hardly surprising. 🙂

Officially I’m on holiday, but I figured I would upgrade all our Dev/Test installations while everything is quiet. Major version upgrades, changes in either of the first two numbers, require a full installation. There was no major difference between this and what I was doing for the 5.0 installations, so I just edited the existing article and altered the title.

Since all the apps at work use AD authentication, I tested that out against 5.1 too and it worked fine.

So it was really smooth sailing.

As I’ve mentioned previously, we’re a small scale user of APEX, so it’s relatively easy for me to upgrade and test our systems.

We’ll kick the tyres some more in the new year, then upgrade the live systems pretty soon.

Cheers

Tim…