Using RDMI

You can use RDMI to perform complex calculations that are not easy to do with SQL, or that require functions that SQL does not support, such as a randomizer. Likewise, you can use RDMI to have an external component transform a string, as when an email address string is resolved into an existing email address by a Microsoft Exchange component.

See Example 1: Invoking a randomizer.

See Example 2: Resolving an email address

You can use RDMI to have an external component validate user data in a USoft application. Invoke the component from an invocative constraint.

The query protocol must be used instead of the standard protocol, because the return value must be interpreted by the Rules Engine as "record exists" or "no record exists". In the first case, the invocative constraint containing the INVOKE clause leads to a violation. The component must be written in such a way that it returns "0" if the action is performed normally, "1" if for some reason the action could not be performed, and "-1" if a fatal error occurred.

See Example 3: Checking an email address

You can use RDMI to perform an action outside the USoft application whenever a certain condition applies to the application data. For instance, you can send a welcome mail each time a new person record is added to a table.

If you INVOKE from a constraint to trigger an external action, the purpose is to perform an action outside the USoft application when certain conditions apply. In constrast to restrictive rule checking, this purpose is not data-oriented but event-oriented.

See Example 4: Sending an email

You can use RDMI to connect USoft client/server applications to other on-line applications.

For this to be possible, components should be built as independent applications.

Transaction management is limited:

If the component performs data manipulation in the invoked application, this data is not automatically committed or rolled back along with the data in the USoft application. This may or may not be acceptable, but you probably need to find out explicitly and for each particular case what is the best approach.

If the external application is used only to validate user data or action in the USoft application, it is more likely that you can build an acceptable solution without explicit transaction management.

With RDMI it is possible to access programs running on a different kinds of machines such as a mainframe or an AS400 system.

For example, for the COM architecture Microsoft's CEDAR project allows access to IBM's CICS and IMS programs running on an MVS mainframe as if they were COM components running on the local machine. For the client of the COM component, in our case USoft Developer, there is no difference between the defining and using of such a COM component and a component which has been specifically developed in Visual Basic.

Users can re-use their existing COBOL software to access data on a mainframe, or synchronize that data whenever changes occur in the local database. Again, USoft constraints can be used quite easily to guard this, so that the SPOD principle is not abandoned. This also gives users the option to upgrade more gradually from a mainframe COBOL to a client/server USoft environment.

Another typical application of RDMI is to have an external component check, a complex IO format that is not available using the standard USoft IO format facility. This way of using RDMI is comparable to having a component perform a complex calculation, which cannot be done using standard SQL functions.

You cannot use INVOKE in domain constraints. To have a component check a complex I/O format for values in a field, define a table constraint.