CHECK_EAIWITHDRAW_ONPURGE

Transaction Control Configuration

Summary

When you purge a case that contains an outstanding delayed release EAI step, the BG process attempts to withdraw the EAI step (sending an instruction to the external system to remove any data associated with that step). By default, iProcess checks if any outstanding delayed release EAI steps have been successfully withdrawn before committing the purge transaction.

The CHECK_EAIWITHDRAW_ONPURGE process attribute allows you to configure this behavior to suit your requirements.

If the withdrawal fails, the data is left in the external system even though the case is purged. The external system and iProcess case are thus out of synchronization with each other. Therefore, TIBCO recommends that the default setting (1) is used instead.

Applies To

This attribute must be set for ALL processes.

Permissible Values

The attribute value must be one of the following:

Value	Meaning
0	iProcess assumes that the EAI step is successfully withdrawn, commits the transaction and purges the case. If the value is set to 0, iProcess assumes that the withdrawal succeeds, commits the transaction and purges the case.
1	iProcess checks whether the EAI step is successfully withdrawn or not. If the withdraw: • succeeds, iProcess commits the transaction and purges the case. • fails, iProcess rolls back the transaction and does not purge the case. This is the default value.

Default Value

The attribute is assigned the following default value when iProcess Engine is installed.

Machine ID	Process	Instance	Value
0	ALL	0	1

Notes

If CHECK_EAIWITHDRAW_ONPURGE is set to 1 you should note the following implications:

•

If you are using a custom shell EAI Server Plug-in (developed using the EAI SDK), and you want to use delayed release EAI steps, you must implement the EAIRun_Withdraw function. The iProcess Suite uses the return value from this function to determine whether it should commit (EAI_SUCCESS) or rollback (any return value other than EAI_SUCCESS) the purge transaction.

•

If the purge transaction fails, it will be automatically re-queued and retried a number of times, as determined by the values of the IQL_RETRY_COUNT and IQL_RETRY_DELAY process attributes.

•

The external system is responsible for handling failed withdraws, and ensuring that the withdraw attempt ultimately succeeds. Otherwise, cases will be left in iProcess that cannot be purged.

•

If you use the TIBCO iProcess Workspace’s Case Administration tool to purge cases (by selecting a case and clicking the Purge Case(s) button), if the purge transaction fails the case will still be visible when you click the Refresh button.