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).