Keeping JDE screen active for specific users

sam123

Active Member
Hello,

We have a requirement for our shop floor users to keep the JDE screen active and never logout. This is how the legacy software designed and they would hate to log back in every time. Is there such a capability within JDE ?

But, this should only apply to specific users that work on the shop floor. I appreciate any ideas that will flow thru here on achieving this.

Regards,
Sam

E 9.2, TR 9.2.2.6, Oracle.
 
Last edited:
I feel your pain Sam and hope someone has a positive answer - but I doubt it.
Even if there is one sooner or later your web servers are gonna go down or be bounced and users are going to have to log in then. If they don't do this on a regular basis where it becomes a learned activity (User ID and password) who do you think they're going to call?

A possible alternative for you is to setup a robust single sign on (SSO) that automatically logs the operator in when he/she clicks the JDE Icon or selects a Favorite on the browser.
What we use and are extremely happy with is the Everest International SSO product. Its cheap (compared to Oracle's solution), simple, robust, and just plain works.
 
If you have the resources set up a separate web instance / JVM for those users and adjust the time out values to be larger than the usual. Now keeping the session active forever might not be acheivable but you can at least give them a longer time out than the other users. I personally havent gone more than 3 hours as the timeout setting , but I havent tested what the upper limit is. Remember to change the JAS settings and also the WebLogic web.xml assuming you are on WLS .

Give those specific users the URL to this JVM. Now, of course, this means they have a single point of failure etc, but that would be the trade-off.

You also have the pop-up message option available now reminding the user to keep their session active when it is nearing the idle timeout period

Refer to docs 2413084.1 and 1488013.1 for more info
 
I agree with both of the above while totally disagreeing and still don't know what's so hard about logging on to E1 these days. Its not like it takes 10 minutes to get anywhere anymore. However, I've been losing that argument for, oh.... 5-6 years now and have one client that insisted on 5 hour timeouts across the board (which I provided - kicking and screaming...) Even if your session is active, its not like your result sets didn't time out hours before you finished your bathroom break, had lunch, chatted with random people in the hallway and had multi lap forklift race around the warehouse.
 
Thanks Larry, Ice_Cube & TFZ for those inputs. My only concern is these machine operators incentives are tied to the machine delays (milli seconds) that are captured via PLC.
 
Sam - in that case - I suggest you investigate result set timeouts as well, and segregate them to their own web instance with very large timeouts across the board.
 
Sam,

In the past were your PLCs feeding data "directly" into a JDE Fat Client Application? If so, how?
 
We have delivered shop floor terminal solutions for JDE previously. These are not native JDE web applications thus timeout/logout is not an issue but are tightly integrated with JDE. We have also integrated them with both industrial PC and SCADA/PLC systems so that machine utilisation, efficiency, material consumption, and hours/quantities can be automatically recorded in JDE as part of work center operation. The solution also provides the ability to display detailed manufacturing instructions, videos etc at the work center as well as also integrate in with CAM so that service information can be recorded by technicians as well as accessing history etc.
 
My 2cents is that if milliseconds matter, the web is the wrong tool for the job...

You will need a direct connection of some sort.

Tom
 
We still haven't the replaced indigenous system. We have Allen Bradley rotary PLCs that communicate via ethernet to a cobol based shopfloor system.
 
Sam,

In the past were your PLCs feeding data "directly" into a JDE Fat Client Application? If so, how?

We still haven't replaced indigenous system. We have Allen Bradley rotary PLCs that communicate via ethernet to a cobol based shopfloor system.
 
We have delivered shop floor terminal solutions for JDE previously. These are not native JDE web applications thus timeout/logout is not an issue but are tightly integrated with JDE. We have also integrated them with both industrial PC and SCADA/PLC systems so that machine utilisation, efficiency, material consumption, and hours/quantities can be automatically recorded in JDE as part of work center operation. The solution also provides the ability to display detailed manufacturing instructions, videos etc at the work center as well as also integrate in with CAM so that service information can be recorded by technicians as well as accessing history etc.

That is how we have currently set it up. It is a archaic cobol based system that we want to eliminate bcoz we have to look in retirement homes for cobol programmers for maintaining it :)
 
That is how we have currently set it up. It is a archaic cobol based system that we want to eliminate bcoz we have to look in retirement homes for cobol programmers for maintaining it :)
We're more in the .NET, Android or Progressive Web Apps kiosks hooked up to things like Rockwell Automation's FactoryTalk. My favourite project was getting a kiosk application running over Citrix, deployed to a Wyse terminal that was connected via Serial Port to a machine so old that it still used RTS/CTS pins and only had an 8 bit buffer which meant it could handle one ascii character at a time. So basically, it could process one character every 250ms which was fun when you're trying to send detailed manufacturing instructions from JDE configurator to it.
 
Back
Top