|
|
|
|
 General
|
|
Name
|
The flow's name. The name can contain up to 30 characters. The name cannot contain special characters, including: / ? : & \ * " < > | # %.
|
|
Description
|
Enter a description of the flow.
|
|
Path
|
A read-only parameter showing the location of the flow file.
|
|
ID
|
An internal identifier number. This is determined automatically by the system. These identifiers are used by the Magic xpi Servers during deployment to identify each object within the project.
|
|
Auto Repeat
|
Determines whether the Server should invoke the flow again when the last flow component is completed. This can create a loop effect. The options are Yes or No.
When you mark a flow as Auto repeat, the Auto Repeat icon (as shown on the left) will appear to the left of the Trigger area.
See this How To topic for further information on creating loops in Magic xpi.
|
|
Auto Start
|
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 to the left of the Trigger area.
For information about the start.xml configuration file's AutoStart load= entry, click here.
|
|
DB Transaction
|
Select Yes or No from the drop-down list. The default is No. If you select Yes, the Database Resources List opens. Here, you can select one or more database resources, up to a maximum of five, 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.
|
|
|
Enable
|
Select Yes or No to enable or disable the flow.
When you disable a flow, the flow is not executed when the project is deployed. You can enable a flow during runtime either by using the Enable Flow utility or from the Monitor.
|
|
Active
|
Select Yes or No to activate or deactivate the flow.
You can improve the Checker's performance by marking a flow inactive. The flow is then omitted from the Checker process, and also from the deployment process.
|
|
Max Instances
|
Limits the number of parallel instances a flow can have.
Enter the maximum number of flow instances that a project can invoke. A worker trying to run a flow will first check the Space for the Max instances value for this specific flow, and the flow will only run if this value is not exceeded. 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 ReservedLicenseThreads configuration file flag, which is related to the license.
|
|
Recovery Policy
|
This property determines the flow’s standard recovery policy when an error occurs. The recovery policy only applies to the main linear flow.
The recovery mechanism is initiated when a flow crashes. 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. When no save-point data is available, the Save Point option will behave as Restart.
Click here for more information about the recovery mechanism.
|
|
Timeout Policy
|
This property lets you define what will happen once the timeout is reached. The options for the Timeout policy are: Abort, Restart, or None.
|
|
Timeout Value (Unlimited)
|
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.
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.
-
If you are using multiple Magic xpi Servers, make sure that all the machines' clocks are synchronized.
|
Flow timeout will kill a thread after a user-defined grace period. 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.
Click here for more information about Flow Timeout, and here for more information about the recovery mechanism.
|
|
Comments
|
This read-only property displays text that was added using the Text Area tool in migrated projects. Since version: 4.5
|
|
Enablement
|
|
Enablement Service
|
To indicate when you want the flow to be enabled, select one of the following from the drop-down list:
-
Always: The flow will always be enabled.
-
New: Opens a new Flow Enablement service ready for configuration in the Settings dialog box's Services section.
-
<Flow Enablement service name> (default): The flow will be enabled according to the parameters that you defined in the selected Flow Enablement service.
|
|
External
|
|
Cleanup Recovery Flow
|
To indicate which flow is used to handle cleanup data as part of the recovery process, click  to open the Flow List, select a flow and then click Select.
|
|
Error Handling 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 to the left of the Trigger area.
|
|
Logic Flow
|
To indicate which flow is used to handle flow logic, click to open the Flow List, select a flow and then click Select.
If you select a flow here, you also have to set the Call Logic Flow component property to Yes.
The logic flow will run after the step has finished, regardless of whether the step has finished successfully or not.
If you have an error flow along with the logic flow, then if you have an error in the component, the logic flow will not run.
|
|
Subscribe Name
|
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.
|
