Same as already done with flow_subflows_vw.
This could be enhanced to

1. flow_viewer_progress_vw (View to just click into Viewer Plugin)
2. anything else we find viable

Please comment for any objects you find useful.

This also relates to the plugin as it will make providing an entry level example easier.

This project is simply put the missing part that Oracle APEX needed to be on the same level as Mendix or Outsystems.
Good job to all contributors! Keep it up! This is project is incredible.

I recommend you add Flows for APEX to the curated list on: awesome-bpm
And there are others.. I think you need to do a little bit more advertisement of this amazing product and you will get more traction.

thank you all for this project.

Additional package to collect "helper" methods for developers to more easily integrate with Flows for APEX.
e.g.

1. PTF for getting subflows overview.

Builds o the existing parallelGateway and eXclusive Gateway support already done in the sub flows feature.

Should be included for V4.0

Some packages might need to run code not accessible by the flows-schema, but only by currently connected user.
Verify which ones are candidates and split packages into separate parts if needed.

hi guys , and thank again for your awesome works.
are DMN and CMMN in your plan for future update?

Question：
ORA-29900: operator binding does not exist
ORA-06540: PL/SQL: compilation error
ORA-06553: PLS-907: cannot load library unit SYS.XQSEQUENCEFROMXMLTYPE (referenced by SYS.XQSEQUENCE)

Location：
package FLOW_BPMN_PARSER_PKG
procedure parse_collaboration line: 818

for rec in (
select colab_id
, colab_name
, colab_type
, colab_src_ref
, colab_tgt_ref
from xmltable
(
xmlnamespaces ('http://www.omg.org/spec/BPMN/20100524/MODEL' as "bpmn")
, '/bpmn:definitions/bpmn:collaboration/*' passing pi_xml
columns
colab_id varchar2(50 char) path '@id'
, colab_name varchar2(200 char) path '@name'
, colab_type varchar2(50 char) path 'name()'
, colab_src_ref varchar2(50 char) path '@sourceRef'
, colab_tgt_ref varchar2(50 char) path '@targetRef'
) colab
) loop

select * from v$version
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production 0
PL/SQL Release 12.1.0.2.0 - Production 0
CORE 12.1.0.2.0 Production 0
TNS for 64-bit Windows: Version 12.1.0.2.0 - Production 0
NLSRTL Version 12.1.0.2.0 - Production 0

How to fix it?

flow_subflows needs to always be joined to flow_processes and afterwards joined to flow_objects using bpmn_id and dgrm_id

Trying to import FLOWSFORAPEX_EN_APEX201_984339_UTF8_V5.0.1.sql

• add package.json, that lists all dependencies
• configure rules in dependabot.yml in GitHub repository

non-interrupting boundary events attached to a subflow are not cleaned up properly.
The created subflow for that specific timer is not removed after the sub flow it is attached to ends.

Would be nice to be able to mouseover a completed object on the process viewer, bringing up history of who, when, etc., the activity was completed.

This would probably require some work on the logging and audit task to be completed first.

Test after Parsing is done.

When there is a parallel gateway and on all paths there are no tasks the engine would wait on only the "first" path is processed.

Diagram Example for Bug

Hi. I have a question about the administration of flows. I installed the Apex module and played around with it. It looks amazing and is almost 100% what I am looking for. We have been using Oracle Workflow for 20 years. The front end is Oracle Forms and the backend is Oracle Workflow. Oracle Workflow was deprecated standalone in 2003 but as it is PL/SQL based it still works fine. We are busy migrating the Forms front end from Forms to Apex and still used the Workflow backend. In the monitor module of Workflow you are able to view the process the same way as you can. But you are also able to expedite the flow from a certain point again. Let's say you have a very long-running process, at some point, it has to take a certain path and follow a transition based on some data, for whatever reason the data was wrong at that point and the process took the wrong path, we are able to fix the data and then let the process execute from a point that we select again. I do not see that function in Flows. Do you have to reset the full process? Some of our processes run for days and we won't be able to reset the full process.

Hi,

thx for this fantastic app, love it.

When i use the application helper functions i didn't get the excpected result.

At this point the functions always say 'single-step' or next_multistep_exists => false.
I took the SBFL_ID and SBFL_PRCS_ID from the view FLOW_TASK_INBOX_VW.

happy new year, Mark

The way installation is set up right now doesn't allow full installation using SQL-Plus because of those path things related to starting directory of SQL-Plus.

If you create a workflow with loops, the current object is not displayed (in color) if you have been there before.
Two pictures for comparison are attached. It is probably just a "problem" for the demo application or maybe the plugin.

The current object is "1".
Wrong behaviour:

Correct behaviour

• Update Contribution information with new installation method.
• Update header and remove outdated things.
• Put link to documentation in front.

Hello everybody

When a timer boundary event is followed by a script or service task the scheduler job throw an Error #1002.
The PL/SQL Code for the script task is just "null;".
When i switch back to a user task after the timer event all runs right.
Same error for Interrupting Timer Boundary Event, too.

Greetings Mark

Error Message from the Scheduler Job

ORA-01002: FETCH auf ungültigen oder geschlossenen Cursor. 
ORA-06512: in "F4A.FLOW_TIMERS_PKG", Zeile 102
ORA-06512: in "F4A.FLOW_TIMERS_PKG", Zeile 102

I used for demonstration Tutorial AA7

In 5.0, there are still deprecated V4 calls in flow_api_pkg that need sorting out or removing.

flow_next_step, in 5.0, calls flow_step_complete. Should be marked as deprecated. remove in V6
flow_next_branch in V5.0 gives an error (no longer supported). remove in v6.

next_multistep_exists - should return an error, be marked as deprecated, and removed in v6.
next_multistep_exists_yn - likewise
next_step_type - likewise
0nce these 3 procedures are removed, the 3 package constants can also be removed :
gc_step constant varchar2(50 char) := 'simple-step';
gc_single_choice constant varchar2(50 char) := 'single-choice';
gc_multi_choice constant varchar2(50 char) := 'multi-choice';

They were all only left in V5.0 in case they broke our F4A app or Demo app during V5 dev.

• Some procedures are not needed, at least not in the spec.
• Merge flow_next_step with flow_next_branch
• "Helper" procedures should be moved to api_util_pkg.
• We need to separate the internal from the external API.
• A subflow_id as IN parameter should be sufficient to get the process_id, so there is no need to supply this parameter.

1. Reduce the pagination on all reports to reserve enough space for the viewer plugin.
2. Default sorting to last updated process first

The modeller creates diagrams with pools and lanes. The created bpmn looks fairly simple (objects are associated with pools and lanes).

If we can parse these out and add pool & lane to the object definition table at parse time.

At run time, we can add pool & lane to the sub flows table so that you can track who needs to do the next steps (or what next steps are there for me / my pool/lane).

I think this is fairly simple and would add a lot of value for 4.0.0

The Timer Type 'Date' allows you to specify a hard date /time for a timer to fire. Baking a hard date into a model is not a very common use case. However, if we allowed a process variable substitution into the date definition, Date Timers would become much more useful. High Return / Tiny Effort enhancement.

Proposal would be to allow &F4A$<process_variable_of _type_date> to be specified in UI.

This then requires a trivial change in flow_timers.set_timer to test for a &F4A token & if so, substitute the get_Date_var(timer variable).

Can we squeeze into 5.0.1?

Process Inbox style apps are easily built using the V5 functionality. However, if more than one user is servicing a lane there is a problem that the process inbox shows all of the not-yet-completed tasks to everyone in the lane. This would include a task that another user is currently working on -- which will result in multiple users picking up the same task to work on.

So we need to distinguish between a) current tasks that no one is currently working on ("available current task") , and b) current tasks that somebody is working on / has committed to work on ("assigned current task").

I can see several mechanisms for solving this problem:

1. Add a sbfl_assigned_to column to flow_subflows. Null allowed -- use of this whole mechanism should be optional.
2. create procedure flow_api_pkg.flow_assignment(pi_prcs_id, pi_sbfl_id, pi_user) that sets sbfl_assigned_to. This would be called in an application when a user starts working on a task to say that "Hey, I'm working on this one!".
3. We could split the subflow status 'running' into 2 separate statuses (stati?) - essentially 'running-available' and 'running-assigned' or leave it as it is.
4. Adjust the existing views, etc.

FFA should work as it currently does if you choose to not use this mechanism -- you would only use if you have a process inbox style app & you have a pool (>1) of users servicing a single lane. You would only need to use it on the steps done in multi-user lanes.

I think we should do 1, 2 & 4.

I think we need this / i can do this for V5.

Current GPL V3 is not permitting commercial use without disclosing own source code.
Probably a more permissive one like MIT is more appropriate.

Create Views which make it easier for others to pull information from the data model.

• Process Instances
• Running Subflows
• Processes incl. Diagram

Pattern to check for:

          from flow_objects objt
          join flow_subflows sbfl 
            on sbfl.sbfl_current = objt.objt_attached_to

Missing

          join flow_processes prcs
            on prcs.prcs_id = sbfl.sbfl_prcs_id
           and prcs.prcs_dgrm_id = objt.objt_dgrm_id

Expected

          from flow_objects objt
          join flow_subflows sbfl 
            on sbfl.sbfl_current = objt.objt_attached_to
          join flow_processes prcs
            on prcs.prcs_id = sbfl.sbfl_prcs_id
           and prcs.prcs_dgrm_id = objt.objt_dgrm_id

The Terminate Event is a special type of bpmn:endEvent. Once any part of the process encounters a Terminate event, the complete process is terminated.

BPMN Parsing:

The Terminate event appears to use the standard bpmn:endEvent tag type. Terminate events include an additional attribute <bpmn:terminateEventDefinition id="TerminateEventDefinition_xxxxxx" /> inside the bpmn:EndEvent tag. Here is an example of a standard and a terminate endEvent:

<bpmn:endEvent id="Event_0nfyg0c" name="F End">
  <bpmn:incoming>Flow_1orua2z</bpmn:incoming>
</bpmn:endEvent>

<bpmn:endEvent id="Event_1gho93w" name="S End">
  <bpmn:incoming>Flow_1p5ajzb</bpmn:incoming>
  <bpmn:terminateEventDefinition id="TerminateEventDefinition_002zoj1" />
</bpmn:endEvent>

As there are several similar "modifiers" to standard object tags, maybe we should add a column(s) to objects to store these extra attributes?

Run Time:
Change flow_next_step section handling an endEvent.
If detect a terminate event, then step through all sub flows, calling subflow_complete.
Set process status to completed. (or terminated?)

Impact:
An extra feature. Nice to Have, Fairly common in a process.

Engineering Impact / Cost to Implement:
Simple

On Gateways parse the attribute for default connection.
Enhance connections table with flag for default.

flow_objects.objt_type was created to contain 'PROCESS' or 'SUBPROCESS' when the BPMN is parsed in V3 to allow 1 level of sub processes..

For V4, we allowed an arbitrary depth of sub-process nesting, and stopped using flow_objects.objt_type in the engine.

In V5.0, I have (already) removed all references to flow_objects.objt_type in flow_engine. So please could we remove references to this in flow_parser, and once that is complete, remove the column from flow_objects.

Good job to all contributors! Keep it up! This is project is incredible.
this is a awesome project .
but one question ...
in work with timer object ,is this better to work with one job and check FLOW TIMERS table every 10 seconds or create one job per timers and check its work on exact time ?

Support for multiple subprocesses including nested ones.

Support for expanding a subprocess during runtime.

Code blocks like setting a sub flow to e.g. running and updating current object are repeated on many places in flow_engine package.
Modularise those blocks into separate procedures for better maintainability.

Many business implementations of this package are going to want to record details of process instance and their associated subflows and steps to track who has performed these tasks, when, status, etc.

The approach so far is to keep this information out of the run time, operational tables in order to maintain performance and to stop long term accumulation of audit trail data in with the run time operational data.

The requirement to track visited notes in the diagram viewer means that we have added basic runtime logging as a process steps through a diagram. These are currently cleaned up (i.e., deleted) when a process is reset or deleted.

We should add a small sub-system to capture these log records, enhance, and move into longer term audit trail.

For bonus marks, we could add some basic analytics on these tables showing, for example,

• frequency & recency of process (diagram) runs
• end to end process run times (min, max, typical)
• step wait times
• step failure frequency, etc.
  fairly simple stand alone sub-project for somebody who wants to get involved, once the core is designed.

If we don't do it, I think many projects will keep building & re-building this.

We should look at requirements in this for error messages / status, logging & debug for tasks, inc scripttasks and service tasks. When these are run from a timer, they run outside of an APEX session, and so APEX debug, etc. aren't available.

Enhance the Flow Monitor page with additional method of setting a process variable.
Specific to those use by gateways.

if a model has > 1 nested parallel sections, you can get a situation where the process is left with 1 orphan subflow of status 'split' that doesn't get cleared up by flow_subflow_complete.
Model would have a parallel section starting at PG1 that is not closed / re-merged. Each branch of the parallel section then opens up its own parallel sections PG2, PG3, which themselves are not closed / merged (each path runs to its own end event).
This is similar to apex.oracle.com Tutorial 3 - Parallel Gateways.

Workaround is to add one forward path from PG1 having its own end event. (as in Tutorial 3!). Or to collapse PG2 and PG3 into PG1.

I think the scenario is fairly uncommon & so leaving this for 5.1 or later.

Currently the parser stops at "step" level.
Some elements have additional information below that level.
E.g. Terminating End Event can only be derived from looking below endEvent.
In addition timer details ar available at that level.

Adapt parser to also parse out those parts.
Put known elements onto sub_tag_name if needed.
Everything else goes to the new flow_object_attributes table.

Using PKG as suffix is overhead and confuses, especially as it is not done in a consistent way.
Suffix PKG should be removed from all packages and all references need to be updated.

Packages to update name on

• FLOW_API_PKG
• FLOW_BPMN_PARSER_PKG
• FLOW_CONSTANTS_PKG
• FLOW_NOTIF_PKG
• FLOW_PLSQL_RUNNER_PKG
• FLOW_TIMERS_PKG
• FLOW_TYPES_PKG
• FLOW_USERTASK_PKG

Additional Work to be done to enable backwards compatibility:

• Script to create synonyms mapping from old to new name

Update the Substitution Procedures to work case insensitive on all parts of the substitution variable.
Currently only the variable name is taken case insensitive.
The prefix F4A$ needs to be all uppercase in version 5.
Verify how to lift this restriction without breaking existing logic.

Currently the package only supports using APEX_EXEC.
This always needs an APEX session which might not be available.
Implement an additional "plain" PL/SQL runner.
This should be steered by the configuration from the XML.

Create configurable script to build needed supporting objects files.
Those can then be simply uploaded to application just before release.
In the future maybe even using GitHub actions to fully automate.

Currently the script simply tries to drop what we have currently.
When changing object names or removing unused objects in certain releases we can't really include those drops.
We probably need to keep track of everything we ever created and run a "drop-if-exists" on those old objects.

Literals are used everywhere in the packages to reference certain BPMN elements.
The package FLOW_CONSTANTS should work as a dictionary for all know elements.

• Add all literals to FLOW_CONSTANTS
• Replace literal code references with constants