There is a difference between the RDML and RDMLX BIFs

There are some gems on the Lansa forums every once in a while. If you use Lansa (and if not, what are you doing here?) you should register there and follow the threads.

The thread about JSM/JSMX and builtin function signatures is very enlightening and I am quoting it here:

There is a difference between the RDML and RDMLX BIFs.

The RDML BIF cannot access the function internals to determine the working list field definition, so the SERVICE_LIST keyword is required on the command.

The RDMLX BIF can access the working list field definition, so the SERVICE_LIST keyword is not required and ignored.

RDML

1. The following command will only send the command string to the service.

use builtin(JSM_COMMAND) with_args(‘TEST KEY(VALUE)’) to_get(#JSMSTS #JSMMSG)

2. The following command will send the command string and all fields in the function to the service.

use builtin(JSM_COMMAND) with_args(‘TEST KEY(VALUE) SERVICE_EXCHANGE(*FIELD)’) to_get(#JSMSTS #JSMMSG)

3. The following command will send the command string, the working list and all fields in the function to the service.

use builtin(JSM_COMMAND) with_args(‘TEST KEY(VALUE) SERVICE_LIST(*FIELD)’) to_get(#JSMSTS #JSMMSG #WRKLST)

If a working list and the associated SERVICE_LIST keyword is used, then all fields are passed and a SERVICE_EXCHANGE(*FIELD) is not required on the same command.

RDMLX

1. The following command will only send the command string to the service.

use builtin(JSMX_COMMAND) with_args(#JSMXHDLE ‘TEST KEY(VALUE)’) to_get(#JSMXSTS #JSMXMSG)

2. The following command will send the command string and all fields in the function to the service.

use builtin(JSMX_COMMAND) with_args(#JSMXHDLE ‘TEST KEY(VALUE) SERVICE_EXCHANGE(*FIELD|*FIELDS)’) to_get(#JSMXSTS #JSMXMSG)

3. The following command will send the command string and working list to the service.

Note: the function fields are not sent.

use builtin(JSMX_COMMAND) with_args(#JSMXHDLE ‘TEST KEY(VALUE)’) to_get(#JSMXSTS #JSMXMSG #WRKLST)

4. The following command will send the command string, all fields in the function and working list to the service.

use builtin(JSMX_COMMAND) with_args(#JSMXHDLE ‘TEST KEY(VALUE) SERVICE_EXCHANGE(*FIELD|*FIELDS)’) to_get(#JSMXSTS #JSMXMSG #WRKLST)

5. The following command will send the command string and the function fields defined in the field list to the service.

use builtin(JSMX_COMMAND) with_args(#JSMXHDLE ‘TEST KEY(VALUE)’ #FLDLST) to_get(#JSMXSTS #JSMXMSG)

6. The following command will send the command string and function fields defined in the field list and the working list to the service.

use builtin(JSMX_COMMAND) with_args(#JSMXHDLE ‘TEST KEY(VALUE)’ #FLDLST) to_get(#JSMXSTS #JSMXMSG #WRKLST)

(slightly edited by me)

In summary:

  • In JSMX BIFs you can send a working list to the service, with or without sending all or some of the fields in the function.
  • In JSM BIFs you can only choose to send none or all of the fields in the function to the service, and if you send all fields you can also send a working list.
Advertisements

Setting timeout for SOAP client

This one required help from our support. I don’t know what the default timeout value for the JSM SOAP client is, but by experiment I would guess about 3 minutes. Which is a long time to wait for a user.

So I wanted to change this and it turns out to be quite easy, though not supported by the Lansa Integrator UI.

In the solution folder, like

drive:\lansarootfolder\partitionfolder\Integrator\Studio\workspace\projectgroup\project\solutions\solutionname

you add a file called

AGENT_INCLUDE.TXT

in this file you write

stub.setTimeout ( 20000 );

if you want the timeout to be 20 secconds (20,000 milliseconds, obviously).

Then you generate, compile, publish and reboot the JSM service and your new timeout is set. And, again obviously, this applies to the entire solution. I wonder if it is an Apache Axis client Stub we are using here, and this page holds the documentation?
https://axis.apache.org/axis/java/apiDocs/org/apache/axis/client/Stub.html

JSM bindings and field length

Normally, in RDML, setting a char field to a string value that is too long truncates the string, silently.

Imagine my surprise when, using Lansa Integrator’s JSM, this was different. I am pretty sure that is because JSM, being Java, does not truncate a string value silently. In fact, looking at the trace files, in SERVICE.TXT I find

stack trace: java.lang.IllegalArgumentException: DataTypeText: byte data exceeds size of data type definition (34,30) (field: WERROR)
at com.lansa.jsm.d.setValue(Unknown Source)
at com.lansa.jsm.service.SOAPAgentService.a(Unknown Source)
at com.lansa.jsm.service.SOAPAgentService.do(Unknown Source)
at com.lansa.jsm.service.SOAPAgentService.a(Unknown Source)
at com.lansa.jsm.service.SOAPAgentService.for(Unknown Source)
at com.lansa.jsm.service.SOAPAgentService.command(Unknown Source)
at com.lansa.jsm.f.for(Unknown Source)
at com.lansa.jsm.f.do(Unknown Source)
at com.lansa.jsm.f.run(Unknown Source)

Command : ERROR : "DataTypeText: byte data exceeds size of data type definition (34,30) (field: WERROR)"

Unfortunately, using RDML and JSM, this is difficult to prevent in all cases. In this specific case, I can be fairly sure what the maximum length of the string value will be so I changed #WERROR to be a char(255).