Flows for APEX #JoelKallmanDay

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.

The What

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 When

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.

The Where

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.

The Why

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:

1. Documentation does not fall out of sync with development or could never be considered out of date.
   
   
2. A saved history of diagrams allows for easy auditing.
   
   
3. Seamlessly updating and exporting/importing diagrams (even those live and in situ) means even complex logic changes can be led by the business instead of IT.
   
   
4. Running/historical process instances are animated using the same diagram allowing for top-down interrogation of process status or routing analysis.
   
   
5. Decision-making logic is almost completely abstracted away from both the application and any supporting packages you may have, meaning your code can concentrate on doing one thing at a time and doing it well – without worrying about when and how it might be invoked.

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.

Conclusion

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.

Additional Points of Interest

• Process flows can be called sub-diagrams from other diagrams, removing duplication.
• Individual tasks can be mapped to roles using the swim lanes from the BPMN diagrams (future versions to improve interoperability here with the Unified Task List).
• Process engine not tied to user or session or time-limited.
• Task definitions defined in the APEX app builder are available to Flows for APEX when building diagrams.
• Plugins communicate flow progress from APEX pages to Flows for APEX.
• Flows for APEX uses commits liberally, so ensure all other processing is done first (future versions to reduce/eliminate said commits).
• Flows for APEX variables can be used within processes, scoped either to the entire process or one of its sub-processes.
• Live today are implementations that have racked up millions of runs against huge models.

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...