Oracle Forms and Websockets - frmwebsocketjsi - Session cannot be started

Ralf Dünkelmann

Hallo Community,

I am trying to get a Form for Websocketcommunication via frmwebsocketjsi.jar up and running in a WLS-Forms-Server environment.

I am following the doumentation for setup, so I signed the jetty-all.jar, changed the formsweb.cfg. I provided both, jetty-all.jar and frmwebsocketjsi.jar, so that it is successfully downloaded to the client when starting my application.

So far, I am able to query the version of the bean with

 Get_Custom_Property( bean_id, 1, 'WSJSI_BEAN_VERSION') ;

and to start the server with

  Set_Custom_Property( bean_id, 1, 'WSJSI_START_SERVER', port );

A Query to

 Get_Custom_Property( bean_id, 1, 'WSJSI_IS_SERVER_UP') ;

returns TRUE.

However, my next step to start the session to open a named canal is not successfull:

   Set_Custom_Property( bean_id, 1, 'WSJSI_SET_SESSION_ID', sessionId );

    Set_Custom_Property( bean_id, 1, 'WSJSI_BEGIN_SESSION', port ) ;

A following query to

    Get_Custom_Property( bean_id, 1, 'WSJSI_IS_SESSION') ;

will always return FALSE.

My further investigations showed, that after I start the server (in my case on port 7779) the port is not bound to a loopback device (what I expected), but rather to either my 192.xxx or 10.xxx IP-address. Could this be the cause of my problem and if yes, why is it not using localhost/127.0.0.1.

By the way, there seems to be no Property to configure the IP address we are working on.

Any hint and help would be appreciated. Thank you in advance!

Best regards,

Ralf

Michael Ferrante-Oracle

If you are not already using Forms 12.2.1.4, I encourage you to do so.

When used correctly, WSJSI will always use localhost. Admittedly, there is limited documentation on using this feature. This is an issue being worked on behind the scenes.

Regardless, no mechanism is exposed to set the address. It is important that the server only run on a local address. Also, it is important that you not attempt to set the port of the WJSI server to one that may already be in use. Also, WSJSI will attempt to ensure this doesn't happen, it is important to understand that it works this way.

The flow to make it work (at a high level) goes something like this:

.1. Create or update your web page (HTML) and include a reference in it to frmwebsocketjsi.js

.2. Create or update your form (FMB) and include/attach websocketJSI.pll (ensure this has been compiled to PLX)

.3. Using websocketJSI.olb, copy or subclass the object group into your form.

.4. The Forms app must start the websocket server then start/create a session before the web page attempts to use it.

.5. Once the Forms app is running and has started the WSJSI server and session, the web page can now "connect" to that server and the corresponding session.

The communication between the two will occur using some variation of localhost (IPv4 or IPv6).

Information about using WSJSI can be found in these documents:

https://docs.oracle.com/en/middleware/developer-tools/forms/12.2.1.4/working-forms/oracle-forms-and-javascript-integration.html

https://www.oracle.com/a/tech/docs/oracleforms-1221-newfeatures.pdf

Ralf Dünkelmann

Hallo Michael,

thanks for your information.

We are already using Forms 12.2.1.4. Apologies for forgetting to inform about that.

You are saying that "It is important that the server only run on a local address". Are you talking about the Forms Server and can you explain the consequences a bit more? In a scenario like ours, we use a separate forms server on a weblogic machine, that is delivering forms and jars to the client on runtime (a scenario, i guess, many customers use). I am not a network expert, but how should a server like that only run on a local address?

Best regards,

Ralf

Michael Ferrante-Oracle

The "server" to which I was referring is the Jetty server that will run on the user's machine. I mentioned that it must run on "localhost" meaning that when the server starts it must use an address that maps to localhost/127.0.0.1 only. I said that just for informational purposes. You are not able to change that behavior.

Here is a bit of a lower level view of how WSJSI works:

Ralf Dünkelmann

Thank you very much for clarification.

From here I see, that I am asking the right question. Though I did everything as described, the server grabs a non-localhost IP address, i.e. in our case either a 192.X.X.X or 10.X.X.X.

Since you stated that it must bind to localhost and I am not able to change the behaviour, I'd conclude that the jar does not work as designed.

Why am I sure, that I find it binding to a non-localhost address? After setting the port (in my case 7779) and starting the server, I can see an entry 10.X.X.X/7779 via "netstat -q" in powershell.

Do you have any other idea of what to do? Would I be able to extend the class and add a feature of setting the IP?

Michael Ferrante-Oracle

Do you have a loopback adapter installed on the failing machine? If so, does the same reproduce on a machine that does not have a loopback? My suspicion is you have a loopback that points to the 192.x or 10.x you mentioned.

Ralf Dünkelmann

The network might be configured like that but even if I find out, what should I do with this information? I am not able to change the company's network configuration.

You said that the jetty server must use an address that maps to localhost/127.0.0.1. If this is a must, why is the program not tied to that address? Instead it guesses a different IP although localhost/127.0.0.1 is available.

I'd say that the code of frmwebsocketjsi should be changed accordingly. Therefor again my question, could the class be extended, so that the IP can be configured from outside?

Michael Ferrante-Oracle

We have no plans to expose a way to set the IP address. This would expose a variety of other issues. As for whether or not a loopback adapter or other setting can be found on the machine, none have anything to do with the "company's network" settings. The loopback handling is entirely a function of the user machine and has nothing to do with accessing the corporate network (or any other).

That said, I believe I may have found a way to reproduce your claim. What I would recommend is to contact Oracle Support and file a Service Request so the issue can be properly investigated. If an issue is identified, development can explore what options might be needed to correct it.

Ralf Dünkelmann

Thank you very much for your information, Michael!

A Service Request is on its way.