Server tab: BPEL process editor
This topic includes a description of each of the fields on the Server tab of the Properties view.
Process and most activities
- Enable persistence and queries of business-relevant data
- When this check box is enabled, the details and history of the
processing of this activity are stored in the runtime environment
for later reference, which increases the amount of data stored for
each process instance. However, without this data you might not be
able to carry out additional tasks such as reconstructing the point
in time this particular activity was navigated. If this information
is not needed, such as for auxiliary steps, clear the check box to
improve performance.When it is clear, then the data of this activity is kept only if it is needed by the runtime environment across transactional boundaries. Such situations might arise when an error occurs during the navigation of this activity or when the navigation of this activity spans multiple transactions.Note: Updates to variables are always stored in the runtime environment, independent of the option selected for the check box.
Invoke, snippet, data map, and human task activities
- Transactional Behavior
- This field describes how invoke, visual snippet, or human task
activities will run in a long-running process. There are four choices:
- Commit before
- Use this setting if the transactions that precede it must be fully committed before it can begin. This activity will still tolerate being in a transaction with other activities that follow it.
- Commit after
- Use this setting if your activity must be committed immediately after it has completed. This activity will still tolerate being in a transaction with other activities that precede it.
- Participates
- Use this setting if this activity does not require a commit to occur either before or after it, and where it can coexist within a transaction where one or more other activities will be invoked.
- Requires own
- Use this setting when this activity must be isolated within its own transaction.
Note: IBM® Process Server might override the transactional settings that you specify or introduce additional transaction boundaries in special situations. Therefore, your process design must not rely on these boundaries. Additional information is found in the IBM Process Server topic Transactional behavior of BPEL processes.If you need guaranteed transaction boundaries, it is a good practice to factor out the business logic that needs to be executed in a single transaction into a microflow and invoke it as a subprocess. The logic of a microflow is always run in a single transaction.
- Continue processing upon unhandled faults
- This setting specifies how a process should proceed when an fault
is not caught on the enclosing scope. There are three choices:
- Same as Process
- Select this to match the Continue processing upon unhandled faults setting for this activity to that of the BPEL process. This default setting can be configured in the Defaults tab for the process as a whole. If you set this activity to match this default setting, then it will change should the default setting change. This is especially useful in programming situations when the Continue processing upon unhandled faults setting may need to be changed, and you don't want to have to manually modify it for each individual activity.
- No
- When No is chosen, and there is no fault handler defined on the enclosing scope, then the activity is put into the stopped state, and a work item for the process administrators is created so that the problem can be repaired. Potentially, this option allows you to simply pause the process to have the problem fixed. This is especially useful in a process that has been running for a long time. This setting overrides the default setting.
- Yes
- When Yes is selected, then in the event of a fault during process execution, the fault is sent to the fault handler of the activity's enclosing scope. If this is insufficient to deal with the fault, then it is rethrown to the next enclosing scope. If the fault reaches the outermost scope, the process terminates. This setting overrides the default setting.
Tip: The Continue processing upon unhandled faults setting is identified differently in different environments. In the modeling environment, this setting is called Continue processing upon unhandled. In the runtime environment, this setting is called Continue on Error. - Enable persistence and queries of business-relevant data
- When this check box is enabled, the details and history of the
processing of this activity are stored in the runtime environment
for later reference, which increases the amount of data stored for
each process instance. However, without this data you might not be
able to carry out additional tasks. For example, you need the historical
data to determine how and when an activity was processed. If this
information is not needed, such as for auxiliary steps, clear the
check box to improve performance.When it is clear, then the data of this activity is kept only if it is needed by the runtime environment across transactional boundaries. Such situations might arise when an error occurs during the navigation of this activity or when the navigation of this activity spans multiple transactions.Note: Updates to variables are always stored in the runtime environment, independent of the option selected for the check box.
Receive and receive choice activities
The contents of the Server tab depend on whether you have the Create a new process instance if one does not already exist check box selected on the Details tab.
- Transactional Behavior
- Note: The transactional behavior settings are only displayed if the Create a new process instance if one does not already exist check box is selected on the Details tab.This field describes how receive and receive choice activities that can create a new process instance will run in a long-running process. There are two choices:
- Commit After
- Use this setting if the new process instance must be committed immediately after the receive activity or the receive case of the receive choice activity has completed. This setting is appropriate if you invoke the process instance using a synchronous API call.
- Participates
- Use this setting if new process instance does not require a commit after the receive activity or the receive case of the receive choice activity has completed. This setting is required if you want to invoke the process instance using the API initiateAndClaimFirst() which allows you to create a new process instance and immediately claim the first human task. .
Note: If your process invokes another BPEL process ensure that the corresponding invoke activity is not part of the process creating transaction. You can achieve this by either setting the Transactional Behavior attribute of the process creating receive or receive choice activity/activities to Commit After or by setting the Transactional Behavior attribute of the invoke activity to Commit Before or Requires Own.Note: IBM Process Server might override the transactional settings that you specify or introduce additional transaction boundaries in special situations. Therefore, your process design must not rely on these boundaries. Additional information is found in the IBM Process Server topic Transactional behavior of BPEL processes.If you need guaranteed transaction boundaries, it is a good practice to factor out the business logic that needs to be executed in a single transaction into a microflow and invoke it as a subprocess. The logic of a microflow is always run in a single transaction.
- Enable persistence and queries of business-relevant data
- When this check box is enabled, the details and history of the
processing of this activity are stored in the runtime environment
for later reference, which increases the amount of data stored for
each process instance. However, without this data you might not be
able to carry out additional tasks such as reconstructing the point
in time this particular activity was navigated. If this information
is not needed, such as for auxiliary steps, clear the check box to
improve performance.When it is clear, then the data of this activity is kept only if it is needed by the runtime environment across transactional boundaries. Such situations might arise when an error occurs during the navigation of this activity or when the navigation of this activity spans multiple transactions.Note: Updates to variables are always stored in the runtime environment, independent of the option selected for the check box.