I know WebSEAL is a cpp application.
I suppose Junction Server could be a HTTP Server. In this case, the backend server is localhost, which means it is ISAM itself. How can Webseal fail a connection to ISAM? In fact, I have 2 junctions: /mga and /scim!
In this case localhost, the backend server, is the AAC/Federation Runtime, running on WebSphere Liberty profile.
------------------------------
Joao Goncalves
Pyxis, Lda.
Sintra
+351 91 721 4994
------------------------------
Original Message:
Sent: Mon March 15, 2021 02:25 PM
From: Steven Hughes
Subject: Junction State vs Operational State
Hello Joao,
The "Server State" indicates whether a junctioned server is up and responding to HTTP requests.
WebSEAL sends periodic "junction ping" requests to test whether junctioned servers are available.
The server state "Running" means WebSEAL is able to connect to and the junctioned server returns a correct HTTP response to a WebSEAL junction ping.
The server state "Not running" means WebSEAL is not able to successfully connect to a junctioned server for the junction type (TCP or SSL). Meaning either the TCP handshake or secure handshake is failing. I will usually debug this state with an appliance packet trace. Driving a request for a resource on the junction server with a browser to ensure there is an attempt to connect to the junction server captured in the trace.
There is also the "running, but does not appear to be an HTTP Server" state which means WebSEAL is able to connect to the junctioned server but the server is not responding correctly to the junction ping's HTTP request. I will usually debug this state by capturing WebSEAL HTTP traces (pdweb.debug and pdweb.snoop) with a packet trace.
Regards,
------------------------------
Steven Hughes
------------------------------