Determines whether the Magic xpi Server should invoke the flow at startup. The choices are Yes or No.

If you have a flow that does not have a trigger or scheduler, you would set this property to Yes, otherwise there would be no way to start the flow. Another example of when you would set this property to Yes is when you have a functionality that you want to occur every time the project loads, such as cleaning the log or table initialization.

When you mark a flow as Auto start, the Auto Start icon (as shown on the left) will appear above the Trigger area.

Enter the maximum number of flow instances the Server should invoke. The Server will check the number of flows currently running when the flow is invoked. If the number of currently running flows exceeds the Max instances value, an error message is displayed.

For example, a flow with an HTTP trigger can be called many times and you would have many instances of the same flow, unless you limit it with this property.

This should not be confused with the MaxConcurrentRequests configuration file flag, which is related to the license.

This property determines the flow’s standard recovery policy when an error occurs.

The recovery mechanism is initiated when the Server crashes and is restarted. In this situation, the behavior of a flow determines whether the flow is ignored (None), Restarted, Aborted or started from the last Save Point.

In all cases, except None, if you defined a Cleanup recovery flow in the flow's properties, a clean-up process (including a user clean up) will be executed before executing or aborting the flow. The server will save the recovery information of the clean-up process. When no save-point data is available, the Save Point option will behave as Restart.

For the None policy, since the flow recovery clean-up information is not saved to a disk, the changes described above must use the saved clean-up information from the memory.

If you change a flow's recovery policy to Abort, Restart, or Save Point, a message dialog box invites you to check that the server recovery setting matches the selected recovery policy.

Timeout policy

This property lets you define how long the flow can run before Magic xpi will end it.

It is recommended to set a timeout for the flow in cases where you connect to external systems, such as IBM i and command line, to prevent the flow from waiting indefinitely for an answer.

You can define what will happen once the timeout is reached. The options for the Timeout policy are: Abort, Restart, or None.

When setting a timeout for your flow, you should first check how long it takes the flow to run. Note that the Flow Timeout operates only on unbounded flows (flows not called from other flows). This means that if the calling flow and the called flow have a timeout defined, only the calling flow’s timeout will be enforced.

Note:

The flow timeout is executed at the first possible point that it can be executed. If a step is in the middle of a transaction or in an external thread, the timeout will apply only after this transaction is finished.

Flow timeout will kill a thread after a grace period of five minutes. If the flow includes a restart option and a trigger waiting for response (for example, in HTTP and Web Service), the response to the trigger will be a Timeout error, and the flow will restart in a new thread. If the flow is a main flow or does not include a trigger that is waiting for response, the flow will restart in a new thread.

When a flow has parallel branches, the linear part of the flow does not end until all the parallel branches have finished the execution. The linear thread will only wait for the parallel branches. Stand alone branches can still run after the linear part of the flow (and with it all the flow) has ended.

DB transaction

Select Yes or No from the drop-down list. The default is No. If you select Yes, the Database Resources dialog box opens. Here, you can select one or more database resources, up to a maximum of 5, that will be part of the Flow Database Transaction.

Here, you need to define all the DB resources that take part in this flow, including call flows.

Warning:

If you use a flow transaction and do not define the database resources that take part in the flow (or any subflow) in advance, you should expect unpredictable behavior in cases of rollback or commit. Therefore, you must select all the databases in advance.

If you select Yes, when the flow starts to execute, a transaction will be opened for all defined databases, and will close when the flow terminates.

The DB Transaction mode in a Mapper step will only be performed for Database resources that are not part of the Flow Database Transaction. Databases that are defined in the Flow Database Transaction will behave as part of the flow transaction.

Call Flow and Invoke Flow (synchronous) will be part of the transaction.

Note:

Magic xpi does not support nested transactions.

External

Setting

Description

Error flow

To Indicate which flow is used to handle error codes, click to open the Flow List, select a flow and then click Select.

When you assign a specific flow to handle error codes, the Error Flow icon (as shown on the left) will appear above the Trigger area.

To subscribe the flow to an event that can invoke the flow, click to open the PSS Topic List and select an event, and then click OK.

Subscribe once

You can decide whether the event your flow is subscribed to should only invoke the flow once or on any occasion when the event occurs. The options are: No or Yes.

Activation right

Click to open the Rights List. Select the rights for this flow and then click OK. This allows you to determine which users can make changes or activate the flow. You set rights using your security method and enter users, groups, and rights in the corresponding repositories.

This is available only if your project has an Authentication System selected in the Project Properties.

Secure called flows

Indicate whether flows called by this flow are also secured by the same Activation rights selected for this flow.

Enablement

Setting

Description

Flow Enabler Settings

Activation Type

When the Magic xpi Server starts, it checks the Flow Enabler settings before activating the flow. Here, you should define when you want the flow to be activated. Select one of the following from the drop-down list:

Always (default): The flow is always enabled.

Weekly: You can define on which days of the week and at which times this flow will be enabled.

Monthly: You can define in which months and which days of the month this flow will be activated. For example, you can define that the flow will only run on the 7th of January, April, July and October.

Select Days: This is only available when you select Weekly from the Activation Type drop-down list (above). Check the box next to the day(s) that you want to activate the flow.

Click next to the Flow Enablement Times field. This opens the Select Execution Time Ranges dialog box. Here, you should enter the required time ranges for the execution of the flow.

Select Months: This is only available when you select Monthly from the Activation Type drop-down list (above). Check the box next to the month(s) that you want to activate the flow.

Click next to the Flow Enablement Dates field. This opens the Select Dates dialog box. Here, you should select the date(s) that you want to execute the flow.

Then, click next to the Flow Enablement Times field. This opens the Select Execution Time Ranges dialog box. Here, you should enter the required time ranges for the execution of the flow.

The following buttons are available in the Flow Properties dialog box:

Button

Description

OK

Click to save your entries and close the dialog box.

Cancel

Click to close the dialog box without saving your changes.

Note:

Every component returns the following two parameters to the Magic xpi Server:

Error Code – for error handling

Status Code – for logic

When an error is returned (error code > 0):

The Error flow from the Flow Properties dialog box (if one exists) is executed to handle the return code. During this process, you may change the actual number of the error.

After the Error flow is completed, the internal error handling is executed (according to the Error Policy column in the Flow Errors repository) for the same error code (if the error code was not changed).