Great things always happen overnight. That's probably the case for European Oracle Apps DBAs in the same situation, like myself. This morning I read Steven Chan's latest
blog post about Java Web Start certification with Oracle E-Business Suite and its support release to the public. We heard about it during some informal discussions at Collaborate 17 conference. Everything is ready, the documentation is prepared, and they are just waiting for final bug related to Workflow Activity Monitor to be addressed... ...and about twenty days later, it was released. This is a superb evolutionary event! And, of course, I made time to fit in some good introductory, hands-on experience.
Applet window is transparently opening. The example below is from Workflow Activity Monitor using Firefox. No extra browser tab / window opened in my case, although there was a mention of known issue with Firefox.
Applet files downloaded are automatically cleared once the applet is loaded, you will not find them on the disk. Chrome, as an example, updates the status of each item under Downloads tab.
So again.. Windows platform is covered well. What about the rest? Linux is not a certified platform for Oracle E-Business Suite end user desktops. Although I was successfully using it in my experience, and it
should work, the Oracle team still is not testing and certifying it. You may use and play around it at your own risk, and it shouldn't be the right production direction. I personally haven't tested it yet for JWS, but my guess is that it will have the same problem as MacOS is having. Maybe a to-do for this blog post update at some point. MacOS... Steven Chan's blog post, as mentioned above, states that "Safari on MacOS"
is not certified because of MacOS Gatekeeper security feature that is "making the Java Web Start user experience very challenging". That's fine. We know a workaround to go to System Preferences app and click on Open Anyway button, though it's required every time we launch the Forms session. But... we don't even reach this point. In the example below, I will outline a sequence of "
nuances" I faced. It will be based on Safari screenshots, as only Safari is officially certified on MacOS. Absolutely the same issues I faced in Firefox on MacOS, and in Chrome on same MacOS. First - we are trying to open Forms, but just getting this familiar screen.
Why? Because the URL still goes to browser plugin mode - "/forms/frmservlet
?config=browserMode&appletmode=..." We can go and set the ICX_FORMS_LAUNCHER profile option to "/forms/frmservlet
?config=jws" on Site level, as MOS note outlines. This works, but it will be required every time we run AutoConfig, as the profile option is always being reset to just "/forms/frmservlet" on Site level, and Forms opening process is supposed to follow FND_ENABLE_JAVA_WEB_START value direction. After the manual fix this is what's happening. Safari is downloading the applet.
We launch it and face a known Gatekeeper issue (only now).
Applet is loaded, but not Forms.
I would expect Safari to cover this itself, but in my case I have Firefox configured as default Web browser in the system. That caused Firefox tab to be opened (called by initial applet) and a second applet download to be requested.
Once the second applet is up, I finally get the Forms session running. Sort of, it's a similar flow that is happening with a browser plugin, but it is just killing the user experience. Initially second applet was blocked by same Gatekeeper, and I had to use the known workaround. But at a later testing MacOS is always blocking only the first applet while launching Forms, second - not anymore. Maybe, I suspect the issue is with a miss of jndi extension for the file.
I got the Forms running. But what a process it was... And nothing is cleared. My Downloads folder is full of these fndservlet.jndi files downloaded.
Initial thoughts while going through Doc ID 2188898.1
1. Java Runtime version for client.- JRE 8 Update 131 b31 or JRE 8 Update 121 b33 are required (as a minimum). This isn't clearly visible - these are special update releases (look at b31 and b33), available only through My Oracle Support download via Patch 25767257 and 25450542. A public release containing the support is only scheduled for next quarter and is set to be released with Update 141.
- JRE 6 and JRE 7 are out of scope! If you don't have JRE 8 support there in your system, now is the right time to think about it.
Now to talk about my hands-on...
I used my R12.2.6 Vision lab instance built on AWS. The patching exercise took something like 30 minutes in total (10.1.2 patch, ebs patches, JAR regeneration). But I was doing this in hotpatch mode and not through online patch cycle, (yes, not the right way, but my goal was to avoid ADOP time consuming tasks. I also installed the required JRE 8 update 131 b31 64-bit version on my laptop. I made a huge mistake starting this testing on my MacOS, which introduced a number of issues that almost led me to a huge "why Oracle?" facepalm result. And it's not just Gatekeeper security feature known issue mentioned for Safari on MacOS. But I'll talk about this later. Brought up my Windows 7 VM. All IE 11, Firefox's latest public update, and Chrome just worked like a charm. I didn't experience any issues like I faced previously on my Mac. "Save File" to Downloads folder and then a double-click, or "Open with" to open the applet immediately. And your Forms session is up. Look at the screenshot - CHROME! Applet window is transparently opening. The example below is from Workflow Activity Monitor using Firefox. No extra browser tab / window opened in my case, although there was a mention of known issue with Firefox.
Applet files downloaded are automatically cleared once the applet is loaded, you will not find them on the disk. Chrome, as an example, updates the status of each item under Downloads tab.
So again.. Windows platform is covered well. What about the rest? Linux is not a certified platform for Oracle E-Business Suite end user desktops. Although I was successfully using it in my experience, and it
should work, the Oracle team still is not testing and certifying it. You may use and play around it at your own risk, and it shouldn't be the right production direction. I personally haven't tested it yet for JWS, but my guess is that it will have the same problem as MacOS is having. Maybe a to-do for this blog post update at some point. MacOS... Steven Chan's blog post, as mentioned above, states that "Safari on MacOS"
is not certified because of MacOS Gatekeeper security feature that is "making the Java Web Start user experience very challenging". That's fine. We know a workaround to go to System Preferences app and click on Open Anyway button, though it's required every time we launch the Forms session. But... we don't even reach this point. In the example below, I will outline a sequence of "
nuances" I faced. It will be based on Safari screenshots, as only Safari is officially certified on MacOS. Absolutely the same issues I faced in Firefox on MacOS, and in Chrome on same MacOS. First - we are trying to open Forms, but just getting this familiar screen.
Why? Because the URL still goes to browser plugin mode - "/forms/frmservlet
?config=browserMode&appletmode=..." We can go and set the ICX_FORMS_LAUNCHER profile option to "/forms/frmservlet
?config=jws" on Site level, as MOS note outlines. This works, but it will be required every time we run AutoConfig, as the profile option is always being reset to just "/forms/frmservlet" on Site level, and Forms opening process is supposed to follow FND_ENABLE_JAVA_WEB_START value direction. After the manual fix this is what's happening. Safari is downloading the applet.
We launch it and face a known Gatekeeper issue (only now).
Applet is loaded, but not Forms.
I would expect Safari to cover this itself, but in my case I have Firefox configured as default Web browser in the system. That caused Firefox tab to be opened (called by initial applet) and a second applet download to be requested.
Once the second applet is up, I finally get the Forms session running. Sort of, it's a similar flow that is happening with a browser plugin, but it is just killing the user experience. Initially second applet was blocked by same Gatekeeper, and I had to use the known workaround. But at a later testing MacOS is always blocking only the first applet while launching Forms, second - not anymore. Maybe, I suspect the issue is with a miss of jndi extension for the file.
I got the Forms running. But what a process it was... And nothing is cleared. My Downloads folder is full of these fndservlet.jndi files downloaded.
