Anyone able to get the new JDE ADF Components with a load balancer or reverse proxy?



Reputable Poster
We've just completed the deployment of the new JDE ADF Components and Work Centre Calendar app. Took a bit of work, some interpretation of the documentation and a couple of calls to Oracle but we got there. Ultimately we need to get the solution to work behind a load balancer as most of the sites we work with have at least two production JAS instances. To get there we figured the next step was to get it working with a reverse proxy as this is effectively the same thing (the load balancers have to be able to handle sticky sessions). I realise this is fairly new but I thought it was worth a shot seeing if anyone on here has had a go at it or might have a bright idea.

The set up is pretty simple. We have the ADF components on one host and the JAS and AIS components on the second host. All three components are fronted with a reverse web proxy which is also the SSL end point. We've had to disable SSL for the AIS server because the mobile clients don't actually support SHA-2 certificates (go figure). From what we can gather the ADF architecture works a bit like this:

Login to JDE JAS session -> JDE returns Javascript with code to login to ADF -> Login to ADF is performed using username, environment and token received in the original login -> ADF passes this login through to AIS which then launches it's own JAS session (not sure how the token is used to authenticate this JAS session but will worry about that another day) -> New AIS session token is passed back to ADF which returns it back to the browser. Javascript then sits in a loop and effectively heartbeats the ADF server to ensure session remains open while you're in the JAS session. One requirement in this whole process is that you have cascading session timeouts so that it drops the user gracefully.

So as you can see browser is crucial to this solution because it is the only common element that can talk to both the ADF/AIS and JAS server and give the impression of a single seamless application. The problem is the browser can only see the reverse proxy so we need to use the exposed hostnames for the servers but at the same time the ADF and AIS servers are passing the same hostnames between each other to facilitate the server to server comms. In the config you need to define host whitelists which I assume are used to deal with the CORS issues in this whole process.

So we're now trying to work out which hostnames to use where to enable this whole thing to work and we've thrown in the SSL component just for a bit of extra fun (plus most customers now use their load balancer as an SSL end point for JDE). The issue we're seeing as that while the browser is communicating with the ADF server it is not actually calling the login service on the ADF server as part of the JAS login process. There are no errors in the browser console but it just is not firing.

I realise this is a bit of long shot but to save us some time, effort and frustration I thought I might check if any of the smart people on JDEList have any bright ideas. And yes, we are raising a call with Oracle on this one as well.
Hi Russell,

Were you ever able to make this work? I am curious because we are trying to get AIS to work using https with SSL offloading on the NetScaler load balancer. We are able to make it work on http but the log in page is not firing up using https. Just curious if you were able to get this working?
Yes, we got it to work once we sorted out which hostnames to put where but that was an ADF issue rather than an AIS issue.

We have the AIS server working with a reverse proxy providing the SSL endpoint. Our solution is just using a simple Apache2 server for the reverse proxy so I can't comment on something like NetScaler although we do have a customer that has F5 load balancers in front of AIS.

We did see an issue early on with the mobile applications because they didn't support the newer SSL certificates (the version of MAF they were compiled on was using Java 6) but I believe that issue has been resolved.