What You Need to Know About Requests Processed Through the LANSA Composer Request Server
There are several key things to understand about requests that are processed through the LANSA Composer Request Server. Some of these have consequences that may have a significant bearing on the way that you design your solutions that use the LANSA Composer Request Server.
1. The function "call" happens in a different process or job or even on a different computer
Normally it is impossible for a LANSA application running in one LANSA system and/or partition to directly call a LANSA function running in a different LANSA system and/or partition. In order to emulate this capability, the LANSA Composer Request Server directs the requests to a separate process or job or even a separate server system, exchanging the request and response data with that job as required.
In many respects, this fact is transparent to the requesting application. Depending on your application design it may have no functional implications at all. However, it does mean that the execution context for the function call may not be what you might otherwise expect it to be.
Understanding this point is fundamental - the remaining points in this section are largely a direct consequence of this fact.
2. On IBM i servers, the function "call" executes with the user credentials of the request server job
The LANSA Composer Request Server for IBM i makes no attempt to exchange user credentials with the request server job that executes the request and the request server does not switch user contexts. The request that executes in the request server job will execute with the user credentials of the request server job. If necessary, you can change the way that the request server jobs are started such that they use a different user profile of your choosing. Refer to Configuring the LANSA Composer Request Server for IBM i to Suit Your Needs for further information.
3. The function "call" happens in the execution environment of the request server job
Because the requests execute in a separate process or job, it follows that they are subject to the execution environment of that request server job - not of the job that made the request. Particularly on IBM i servers, this is significant for a range of job attributes, including (but not limited to):
- File overrides in the requesting job do not apply to the request
- Open data paths in the requesting job are not shared with the request
- The contents of the QTEMP library of the requesting job are not available to the request
- The request executes with the library list of the request server job (not the requesting job)
4. The execution environment of the request server job does not persist from one call to another
It is not valid to assume that the execution environment of the request server job(s) that process your requests will persist from one call to another. For example, if a called LANSA function on an IBM i server makes changes to the library list or creates objects in QTEMP, you must not design your solution relying on the fact that those changes will still be in effect for the next called function. There are two main reasons for this:
- It may not be the same process or job
On Windows servers, every request directed through the LANSA Composer Request Server executes in a new process.
On IBM i servers, to handle a given load, more than one request server job may be active to service requests to a particular LANSA system. There is no guarantee, for example, that the same job will execute the requests for successive CALL_FUNCTION activities in a LANSA Composer Processing Sequence.
- Each request server job reinitializes its state between requests
On IBM i servers, in order to ensure the integrity of the state of the LANSA execution environment from one request to another, the request server jobs perform certain re-initialisation between requests.