The DXACTBAS1 ancestor class implements several methods specifically for loading and calling LANSA Integrator services. The methods provided wrap and simplify the calls to the Java Service Manager (JSM) and perform much of the necessary housekeeping, exception handling and logging.
These methods do, however, assume that you use a single connection to the JSM. If your Activity Processor needs to have multiple connections open, then you will have to write the code to manage the second and subsequent connections yourself.
Your Activity Processor does not have to use LANSA Integrator services. If it does not, you do not need to use these methods.
For more information about developing applications that use LANSA Integrator services, refer to the LANSA Integrator Guide.
ExecuteJSMOpen
Opens a connection to the Java Service Manager for executing LANSA Integrator services. The result is True if successful. Performs exception handling and logging as required. Sets the Activity return code to error if the open fails.
A successful call to ExecuteJSMOpen will usually be followed immediately by a call to the ExecuteJSMLoad method to load the required service.
ExecuteJSMLoad
Issues the SERVICE_LOAD service command to load the named JSM service, automatically enabling tracing according to the value specified in the System Settings, and performing exception handling and logging as required. Sets the Activity return code to error if the service load fails.
ExecuteJSMCommand / ExecuteJSMCommandEx
Executes a specified service command through the Java Service Manager. Performs exception handling and logging as required. By default, this sets the Activity return code to error if the command fails. However, if the iRecoverable parameter is set to True, the warning level will be set instead.
NOTE: If the service command you are using requires your activity processor to exchange fields and/or working lists with the JSM, then you cannot call the ExecuteJSMCommand or ExecuteJSMCommandEx methods. You must use the JSMX_COMMAND built-in-function instead, directly in your activity processor, otherwise the exchange of fields and/or working lists defined in your activity processor cannot work.
For example, this code does NOT (and cannot) exchange fields and/or working lists):
#lResult := #com_owner.ExecuteJSMCommand( #mycommand 'My log message for this step' )
If you need to exchange fields and/or working lists, you could use code like this instead:
use builtin(jsmx_command) with_args(#com_owner.JSMHandle #mycommand) to_get(#com_owner.JSMStatus #com_owner.JSMMessage #mylist)
#lResult := #com_owner.JSMCheckStatus( #mycommand 'My log message for this step' )
Refer below for a description of the JSMCheckStatus method.
ExecuteJSMUnload
Issues the SERVICE_UNLOAD service command. Performs exception handling and logging as required. Sets the Activity return code to warning if the command fails.
ExecuteJSMClose
Closes the connection to the Java Service Manager, optionally unloading the currently loaded service first. Performs exception handling and logging as required.
JSMCheckStatus
Instead of using the ExecuteJSMCommand or ExecuteJSMCommandEx methods, you may execute a JSM service command directly in your activity processor using the JSMX_COMMAND built-in-function. If the service command you are using requires your activity processor to exchange fields and/or working lists with the JSM, then you must use that method.
In that case, you may still use the exception handling and logging of the ancestor class by calling the JSMCheckStatus method after the JSMX_COMMAND built-in-function. By default, this sets the Activity return code to error if the command fails. However, if the iRecoverable parameter is set to True, the warning level will be set instead.
NOTE: For this to work correctly you must specify the #com_owner.JSMStatus and #com_owner.JSMMessage properties of the ancestor class on the JSMX_COMMAND built-in function.
Refer above for an example of using JSMX_COMMAND and the JSMCheckStatus method.