Configuration Parameter 🆕

Flows for APEX Configuration Parameter Options

Configuration parameters can be changed from the Flows for APEX application using the Configuration menu.

Configuring Event Logging

Event logging is currently designed to be configurable, so that an installation can capture more or less event data depending upon business ad security needs.

Logging is configured using Flows for APEX configuration parameters, which are stored in the FLOW_CONFIGURATION table.

parameter	possible values	behavior	default
logging_level	off	logging is disabled
	standard	logs instance and step events	yes
	secure	logs model, instance and step events
	full	logs model, instance, step and process variable events
logging_hide_userid	true	does not capture user information about the step
	false	captures userid of the process step as known to the Flow Engine	yes
logging_language	en	error messages generated in the Flows for APEX engine will be placed in the Instance Event Log in this language. If the message is not available in the required language, it will appear in English (en). Note that this parameter does not change the language that a user sees on their screen - that is determined by their browser and login settings. This setting determines the language used for error messages that are placed into the logging tables – so this should be the language used by your system administrators.	yes
	fr	event log messages in French (fr)
	other supported languages	etc.
logging_retain_logs_after_prcs_completion_days	1 - n	delete log information n days after the process instance completed or was terminated.	60 days
logging_received_message_flow	true	logs all received MessageFlow messages into the flow_message_received_log table	true
	false	disables MessageFlow logging
logging_retain_message_flow_days	n	Number of Days that received MessageFlow messages are retained	5
logging_bpmn_location	see section below	Controls the location used to archive copies of the BPMN Process Model whenever a model (diagram) becomes the production model, and whenever the model is changed. The location can be either a database table, or in OCI Object Storage using an API Key or Pre-Authorization. The storage location is specified using a JSON snippet, which can be editted in the Flows for APEX application. ` Note:` This storage parameter is for archiving of BPMN Diagrams. A similar parameter exists in the Archiving section to define the storage location of Instance Archive files.

Configuring Instance Archiving

Instance archiving creates a summary document in JSON format containing all logged information about a completed process instance. This is created daily after the process instance is completed. The document will contain everything that was captured by the logging about that instance (so the archive contents are dependant upon your settings for logging_level.) The archive documents can be stored in a database table or in OCI Object Storage (using an API key or by PreAuthorization). If you use OCI Object Storage, you can set document retrieval, retention and purging policies in the OCI Object Storage bucket to manage archive life, retrieval times, and storage cost. For example, you might want to keep all archive documents for 5 years, but have the documents moved to a lower-cost storage tier after 2 years.

parameter	possible values	behavior	default
logging_archive_location	see section below	Controls the location used to store the process instance archive documents (a JSON file). The location can be either a database table, or in OCI Object Storage using an API Key or Pre-Authorization. The storage location is specified using a JSON snippet, which can be editted in the Flows for APEX application. ` Note:` This storage parameter is for archiving of instance archive summaries. A similar parameter exists in the Logging section to define the storage location of changed BPMN diagrams.

Configuring Engine Settings - Diagram Versioning

parameter	possible values	behavior	default
engine_app_mode	production	versioning controls are strictly enforced. released models cannot be edited and resaved, except by creating a new version.	yes
	development	versioning controls are not strictly enforced. diagrams in released status can be edited and re-saved.

General Engine Configuration

parameter	possible values	behavior	default
duplicate_step_prevention	strict	requires step keys to be provided on all step operations, thus preventing multiple users from attempting to make the same step transition but instead moving the process forward multiple steps	yes (new installations)
	legacy	allows null step keys. Incorrect step keys will still cause an error. Only use this until you migrate your v21 and earlier apps to use Step Keys	only for migrated systems
version_initial_installed		records the version first installed (do not change)
version_now_installed		records the current version installed, after any migrations have occured
default_workspace		should be set to your default APEX workspace used for Flows for APEX. This is used as a last-resort for scriptTasks and serviceTasks when creating an APEX session or looking for mail templates
default_email_sender		should be set to your default email sender, in case outbound mail serviceTasks do not have a sender defined

Default APEX Session Configuration for Asynchronous Calls

Many features of Flows for APEX require the Flows for APEX engine to be running in an APEX session. For most operations the engine is run from inside the user’s APEX application – so inside an existing APEX session. HOwever, some situations, such as where the process is run from in incoming REST call or from the DBMS Scheduler (after a timer fires), there is no existing APEX Session and Flows for APEX needs to create one.

Default parameters are used if session configuration has not been provided in either process variables (on a timer), or in the Process Diagram. The values provided in the system configuraton will be used if no other sets of session config data is found. Administrators of high security systems may want to leave these default configuration parameters unset, so that specific values have to be provided at call or diagram level. Any calls made without call level or diagram level parameters will then raise an error – which might be what you want rather than relying on system-level dafault parameters.

parameter	possible values	default
default_application	the application ID of one of your APEX apps	none
default_pageID	the page ID of one of your apps that will be provided to create a session	none
default_username	the username to be user on the APEX session to create a session if no other username is provided	none

Timer Configuration

parameter	possible values	behavior	default
timers_enabled	true	Timers are currently enabled. Timers are implemented by the Oracle database DBMS Scheduler feature. On production and active development systems, timers should be enabled and running. On in-active systems, such as personal training sandbox installations you should consider turning timers off if you are not actively using the system. This is particularly important on shared tes / demo systems like apex.oracle.com.	false
timer_repeat_interval	valid DBMS Scheduler expression (e.g., ‘FREQ=MINUTELY;INTERVAL=10’ for personal test systems, ‘FREQ=SECONDLY;INTERVAL=10’ for production systems).	Frequency of DBMS Scheduler wake-ups. Each Scheduler wake up then queries for Flows for APEX Timers that have fired, and services them in time order. The frequency setting controls how fine-grained your timer schedules are. For a production or active development systems with many timers, you should have the interval no more frequent than every 10 seconds. For personal test systems and demo systems, especially on shared use systems like apex.oracle.com, you should keep the frequency to every 5 to 10 minutes to prevent excessive unnecessary database workload.	5 Minutes
timer_max_cycles	1 - n	Controls the maximum number of times a repeating timer fires when it is defined with no fixed number of repeats. This prevents infinite repeat cycles.	1000

Statistics Configuration

The Statistics processes create summary information about instance and step execution, including frequency, execution times, and waiting times for user tasks and process instances. Summary statistics are collected each day by an APEX Automation task, which creates a daily summary and a Month-To_date summary every day it runs. In addition, daily information is used to create a Monthly Summary and a Quarterly Summary after the end o a month or quarter. These configuration parameters control how long these statistics summaries are retained for. As the summaries, particularly the monthly and quarterly summaries, do not require large storage volumes, we would recommend retaining monthly summaries for at least a year, and quarterly summaries for several years so that you can see information about process performance and utilization changes over longer periods.

This is a new feature in Flows for APEX v23.1, which we expect to develop further as customers get experience of generating and using these statistics. Unless storage is a problem, we would recommend that production users collect and retain statistics for at least the default periods as we further develop and enhance the statistics features over future releases…

parameter	possible values	behavior	default
stats_retain_daily_summaries_days	d days	Retention period in days for daily summary data.	180 days
stats_retain_monthly_summaries_months	m months	Retention period for the monthly summary data, in months	9 months
stats_retain_quarterly_summaries_months	n months	Retention period for the quarterly summary data, in months	36 months

REST Configuration

parameter	possible values	behavior	default
rest-base	-	Base URL for REST
logging_rest_incoming_calls	Y	Incoming REST call contents are logged to flow_rest_event_log table	Y
logging_rest_incoming_calls_retain_days	n days	Retention period for the incoming REST call data, in days	60