Cautions when using the remote API facility

When the remote API facility is used and the RAP-processing client's node is TP1/Server Base or TP1/LiNK, do not issue an API substitution execution request to a RAP-processing server on the same node as the RAP-processing client. If such a request is issued, operation cannot be guaranteed.
When you use the remote API facility, you cannot use the feature for compressing RPC user data if TP1/Server Base serves as the RAP-processing client.
When a chain RPC is performed using the remote API facility (specifying DCRPC_CHAINED in the flags argument of the dc_rpc_call function) and the RPC terminates abnormally to stop the UAP issuing the dc_rpc_close function, the RAP-processing server outputs the message KFCA26921-E reason code=401. This completely clears the resources of the chain RPC and terminates abnormally with Vrext03. Even if the chain RPC is performed normally, the RAP-processing server also goes down if the terminating RPC is not performed for the chain RPC (specifying DCNOFLAGS in the flags argument of the dc_rpc_call function).
The user service definitions for the RAP-processing listener, RAP-processing server, and RAP-processing client manager created by the rapdfgen command are assumed to be under $DCCONFPATH. Therefore, do not move them from under DCCONFPATH to under $DCUAPCONFPATH. If moved, the operation cannot be assured.
Do not execute the following commands on a RAP-processing server; otherwise, correct system operation cannot be assured.
- scdchprc command
- scdhold command
- scdrles command
- scdrsprc command
When you use the remote API facility between OpenTP1 systems by specifying the -w option in the dcsvgdef definition command in the user service network definition (for example, to perform an RPC via a gateway such as the application gateway firewall), the dc_rpc_call function will not become a transaction even though you specify the transaction attribute. Therefore, when the remote API facility is used, starting a chained RPC from within a transaction and ending the chained RPC in synchronous point processing does not work correctly. You will need to end the chained RPC explicitly by using the dc_rpc_call function in which DCNOFLAGS has been specified in the flags parameter.
If you monitor messages, check for the KFCA26952-I message to determine whether or not the remote API facility has started. Do not use the KFCA01813-I message for this purpose because it is also output when an error occurs during the RAP-processing listener start processing.
For details about these messages, see the manual OpenTP1 Messages.

3.12.7 Cautions when using the remote API facility