Component state

On a component's State tab, you can determine the moment when a component is constructed and when it is destroyed. You can also set what functionality it supports.

MR_bmp0065

Statefulness

RDMI components can be stateful or stateless.

When the Rules Engine invokes a method of a stateless component, it checks if a constructor exists and then calls that constructor. If the constructor has arguments, those arguments are supplied by the constructor SQL. Then the physical method is called. After the call, the component is released.

When the Rules Engine invokes a method of a component with Lifetime = Session, it checks if the component is already instantiated (an instance of the component has been created). If not, it calls the constructor. If the constructor has arguments, those arguments are supplied by the constructor SQL. Finally, the physical method is called. The component is released at the end of the session.

When the Rules Engine invokes a method of a component with Lifetime = Transaction, it checks if the component is already instantiated (an instance of the component has been created). If not, it calls the constructor. If the constructor has arguments, those arguments are supplied by the constructor SQL. Finally, the physical method is called. The component is released at the end of the transaction.

Lifetime

Stateful components can have the lifetime of a session or the lifetime of a transaction.

It is possible to have a component with a Lifetime = Transaction that does not actually participate in the transaction. The component is created the first time it is accessed within a transaction. It will be destroyed not directly after the call, but at the end of the transaction when a commit or rollback is issued. A component with Lifetime = Session receives commits and rollbacks but is not destroyed at the end of a transaction. It will only be destroyed at the end of a session.

Participate in transaction

When a component participates in a transaction, the Rules Engine calls the Commit, Rollback and Precommit methods of the component if you have specified on the State tab that the method is supported.

When the Rules Engine performs a commit, the Rules Engine first calls the PreCommit method for each transaction component involved. If all PreCommit calls are successful, the Rules Engine commits all transaction components.

When the Rules Engine performs a rollback, it calls the Rollback method of all transaction components.

PreCommit	This method checks whether changes made by the InsertRow, UpdateRow, or DeleteRow method are correct. It must return 1 for OK, and 0 or –1 for fail. If –1 is returned, the transaction is rolled back.
Commit	Has no input, output or return parameters. When called, this method permanently stores all data that has been changed by the InsertRow, UpdateRow, and DeleteRow methods.
Rollback	Has no input, output or return parameters. When called the method undoes all changes made by the InsertRow, UpdateRow, and DeleteRow methods.

If the PreCommit method of a transaction component returns 0, the Rules Engine does NOT commit, and does NOT rollback. Also, the Rules Engine does NOT issue an error message.

As writer of the transaction component code, you need to provide these error messages.

If the PreCommit method of a transaction component returns –1, the Rules Engine performs a rollback, and provides the corresponding message for a rollback.

It is also possible to raise an exception from the PreCommit method. As part of this exception, you can provide a message. This message will then be displayed within a USoft environment, and a rollback will be performed. You can translate these messages by using Application Strings.

Support table component

Check this box if the component serves as a basis for a component table. Such a component must be stateful.