Flows for APEX…you've heard of it before, but what exactly is it? And, beyond that, where should it be used and why? In this blog, I will establish the premise behind Flows for APEX, the facts, where it might be heading next, and how all this informs our decision to use it as Oracle APEX developers. And let's not forget that today is #JoelKallmanDay, so visit Remembering Joel to leave a memory if you have one.
BPMN is the acronym of the day. Business Process Model and Notation, or BPMN for short, is an ISO (19510) ratified standard for graphically documenting business processes. Think of it as Visio on steroids, where every shape and symbol has a specific meaning. Perfect for developers, modelling a process in BPMN means you've removed ambiguity and documented a chunk of your specification in a highly explanatory way without ever opening Word.
Given that BPMN is standardised, wouldn't it be great if we could 'run' our newly created process model, couple it to some UI and PL/SQL APIs and be done? Well, I'm happy to report that's exactly what Flows for APEX aims to do!
In a world where low code is well on its way to becoming the de facto approach to internal software development (and more), utilising standard approaches to common problems wherever possible is how we, as developers help Oracle APEX keep its edge and market our expertise.
The earliest available version of Flows for APEX was released in August 2020. Since then, there have been regular updates of increasing content and fixes, with the new 22.2 update just around the corner to coincide with Oracle APEX release 22.2.
Notably, for May 2022, the tent-pole feature of Oracle APEX release 22.1 was the 'Approvals and Unified Task List'. This was a direct response to developer-driven requirements for APEX to provide a declarative approach to managing business process tasks. The most common examples are manager approvals for expense claims, annual leave or pay increases.
This is evidence of the value Oracle sees in developing APEX in this direction and is committing resources accordingly. Richard Allen, a long-time contributor to Flows for APEX, has recently returned to Oracle employment but continues to develop the open-source project while simultaneously supporting the Unified Task List feature from within Oracle.
Flows for APEX picks up where Unified Task List leaves off in terms of managing the evolution of complex business processes. Still, there is plenty of synergy behind the two approaches, and the 22.2 release for Flows for APEX will deepen that synergy by allowing direct coupling to the Unified Task List.
All of that to say, Flows for APEX is here to stay. It's well developed, well supported, and has the longevity and direct, tangible backing of Oracle. If 2021 saw Flows for APEX making a splash in the Oracle APEX community, 2022 and beyond is undoubtedly feeling the subsequent ripples. So now is the time to seriously consider adding Flows for APEX to your box of tools.
We've established what Flows for APEX is and that now is the time to get hands-on. But what are we considering when deciding where to use it?
This is where we must be our most critical. Despite its many benefits (discussed in the next section), Flows for APEX and how it relates to general APEX development cannot be mastered in one afternoon.
Excellent documentation and example applications are provided, and you can pull your proof of concept together in short order. But, like anything, you get out what you put in. So expect to invest serious time into understanding how Flows for APEX hangs together before attempting to use it within a serious development project (or at the very least incorporate that upskilling time into your estimations).
Whether Flows for APEX should be used on a project at all comes down to the combination of a few factors. These are the size of the business and the value derived from the features available, the development of a new or existing system, how complex the requirements are and customer engagement.
Small businesses with simple requirements and limited interest beyond what's in scope will almost certainly never be a suitable proposition, despite how well-future-proofed they'd be.
Where you are only required to enhance the functionality of an existing application, there will likely be opposition to what could be seen as feature creep and any additional investment required, no matter the long-term benefits.
If it's a new project and the customer engagement is there, Flows for APEX can be enthusiastically recommended for almost any requirement, especially those where the processes are complex or long-term, development is expected.
In conclusion, like any development decision, it comes down to cost vs benefit. If the users aren't likely to engage in the benefits provided by Flows for APEX, then it'll likely not be worth incorporating. That is, unless you're starting a new project (where the effort to incorporate is minimal) and the complexity of the business processes means getting ahead of future requirements justifies its use.
Now for the meat and potatoes…'The Why'. As mentioned earlier, Flows for APEX turns what is fundamentally business process documentation into living, breathing application logic. This one point alone can lead to many benefits:
In addition to the core diagramming concept of Flows for APEX, there is also the following to consider:
From version 22.2, Flows for APEX will directly integrate with APEX's Unified Task List, allowing centralised development/management of the user interaction or tasks generated by Flows for APEX.
Interrogation of recorded process flow steps allows time analysis on entire processes and/or sub-processes. This can then be used to investigate time sinks and bottlenecks to inform future business process updates.
Perhaps counter-intuitively, I ended this post with why you would use Flows for APEX. Before that, we'd considered what fundamentals Flows for APEX is based on, when the project matured into a low-risk proposition and where we should consider using it, if at all.
It was written this way because while it would be easy to conclude that Flows for APEX belongs everywhere, there are definite implementation costs and user engagement thresholds that need to be met (especially on existing projects). But, once those thresholds are met, you get some serious benefits.
All things considered, Flows for APEX is an impressive piece of packaged software that the contributing team should be immensely proud of. I look forward to seeing how Flows for APEX evolves and how it and Oracle APEX grow together.
Click here to start your journey with Flows for APEX.
If you would like to speak to one of our Oracle APEX experts, get in touch through enquiries@dsp.co.uk or book a meeting...