FWD » Core Development » Runtime Infrastructure

Batch processes can be made to work similar to PASOE agents, full server-side, assuming that there is no need of interactive terminal.

There are not many static fields in the p2j.ui package remaining. After we clean this up and make them context-local, what we need to do is run a FWD client only on server-side.

Initial proposal is to do this still via ClientDriver, which after authentication, if it sees server-side-resources=ALL, it switches automatically to this 'headless' mode (i.e. closes the socket, etc) and initializes ThinClient and other needed UI resources on server-side.

But, this does not get rid of the OS process launch, which can be problematic when many clients need to be launch at the same time.

Instead, the solution will be to provide FWD Java APIs to launch a batch process fully server-side, in 'headless' mode, directly from the applications code. This way, there will no longer be an OS process.

An additional complication is OS-GETENV. There are applications which pass state to the launched batch process via OS environment variables. This can't be made to work without adding a separate mechanism of passing these env vars to the FWD Java API launching the OS batch process, so that we still have context-local separation of OS-GETENV (otherwise, all clients would read FWD Server's env vars).

Constantin Asofiei wrote:

Instead, the solution will be to provide FWD Java APIs to launch a batch process fully server-side, in 'headless' mode, directly from the applications code. This way, there will no longer be an OS process.

Greg, an additional note: do we want to have REST APIs instead of Java APIs to launch the batch processes?

I would generally prefer that. But I want to make sure that we plan for the most likely usage scenario. How would it be used to replace the launching of _progres or pro sessions in a script?

Greg Shah wrote:

I would generally prefer that. But I want to make sure that we plan for the most likely usage scenario. How would it be used to replace the launching of _progres or pro sessions in a script?

• the REST API will authenticate with a FWD account which has the correct permissions to launch batch processes
• the payload will specify the FWD account under which to run the batch program, plus all the other configurations to initialize the FWD context (bootstrap config, OS env vars, workingDir, etc)

Also, this would make FWD easier to integrate with other apps. And also does not rely on a JVM process to connect to the FWD server and launch this.

OK, go ahead with the REST API.

The initial work on running client-side UI in server context was implemented in 9055a. It added very limited set of use cases, like the MESSAGE statement.