Long Operations

An action executed by a rule may start an operation that takes a long time to complete. For example, an action may request a service from some other system (see Communication with Other Systems) and the other system may take minutes, days or months to implement the request. Or an action may start an operation in the user interface and wait for the input from a user (there is a number of such actions in the Rule Language – see Rule Language Reference). Again it may take a user minutes or hours to provide this input.

Aware IM seamlessly supports operations that take a long time to complete. If a reply has not been delivered to Aware IM within a certain time frame the current request that started the long operation is suspended. This means that Aware IM stores the current state of the external request that started rule execution in the first place in the database and continues with other tasks. As soon as a reply has been received (no matter how long it took to receive the reply) Aware IM restores the state of the request and resumes execution of rules as if no long operation has taken place. While Aware IM is waiting for the reply the request is considered to be “active” – it is possible to look at the list of all active processes in the system by selecting the menu item of the “Active Processes” type in the Operation Mode (see Setting Menu Item Properties).

When an action requests a service of another system Aware IM waits for a reply for one minute before it suspends the current request. After that it waits for the reply indefinitely (unless the request is cancelled by the user from the Active Processes screen).

When an action starts an operation of the user interface the request is suspended immediately. If a reply from the user has not been received within half an hour (this is the default value which can be changed in the system’s property file – see Appendix A) the request is automatically cancelled.

When a request is suspended Aware IM commits the current database transaction. When a reply is received a new transaction is started. This means that if an error occurs after the reply has been received only changes since the request has been resumed are rolled back. Any changes before the request was suspended remain committed. This behaviour means that it is generally not a good idea to perform any changes to the system prior to the execution of a potentially long operation, such as invocation of a user interface operation – all user interface operations need to be executed first and then the data collected from a user should be used to perform changes to the system.