Calling External Procedures

Procedures from external systems may be used in a number of forms-based activities and from within LC LSX scripts. Some connectors provide procedure functionality as an alternate method of performing data selection or modification operations, while for others it is the only method of communicating with an external system. In all cases, there are various contexts and requirements regarding the behavior and handling of parameters for procedures.

Instructions for using procedures within a given IBM® Lotus Enterprise Integrator® (LEI) activity or Domino® Enterprise Connection Services (DECS) operation can be found in the documentation for that activity. Any special considerations for calling procedures within a specific connector can be found in the documentation for that connector. In general, parameters will be provided to procedures by name if named parameters are supported, otherwise by position. Output from procedures will be expected as returned result sets when supported, otherwise output parameters may be used.

A procedure is generally used within three general contexts:

• Perform a black box action

  In this case, the caller is not concerned with the action being performed; inputs may be provided, but no specific behavior or output is expected. This context is generally used within an LC LSX script, as most forms-based LEI activities expect specific behavior from a stored procedure. In this case, input parameters are provided as indicated in the script, and parameters of the corresponding name and data type will be supplied to the procedure. For connectors that do not support named parameters, the parameter position becomes relevant.

• Perform a modification

  In this case, the stored procedure is being used to alter data in the external database. This context is used in many situations; both from forms-based activities and scripts. When called from a script, it is treated like the black box action described previously. When used in forms-based activities, the input parameters provided and the behavior expected is defined by the normal activity behavior. For example, when using a stored procedure as the destination of a Direct Transfer activity, the input parameters match the destination fields being stored, and the insertion of new data records is the expected behavior. The activity in question will specify what parameters are provided for a given context. For example, a single Virtual Field activity can perform inserts, updates, and deletes through different stored procedures, and the parameters provided are specific to the action being performed.

• Produce a result set

  In this case, a procedure is being used to return information from an external system, either to simulate a standard selection operation or as the only method of producing a result set, depending on the connector. Input parameters may be provided, and a result set should be returned. The input parameters are supplied in the same manner as the other procedure contexts described previously. The result set contents are generally determined by the procedure definition. In some systems, the fields being returned must be identified at the time of the procedure call by the caller. In this case, the output fields will be identified by the calling activity, or manually within the script. An example of this behavior is Oracle procedures, which only return results in output parameters that must be identified at the time of the call.