Standard buttons not displayed on web

Hello,

We are having issues with one of our custom forms. On Fat / Citrix Client the form is displayed with all the standard toolbar buttons like OK and Cancel.

But on the web the form is visible but without any standard toolbar buttons (OK, Cancel etc). We have web generated the application and the form several times and also cleared the cache too but of no help.

Can somebody help us on this in finding out what could be the issue here? Since it is only on web and not on fat/ citrix it looks like a web only issue but not sure what can it be.

Appreciate your help in advance.

Thanks,
CNC Guy
E1 8.10
Web sphere 5.0 on UNIX

I had an issue previously with almost the same issue.. My find. ok buttons were missing.

But then it was because the the BSFN for the J env was mapped locally instead of server. Be careful, few of the BSFNs has to run local though even for J envs..

Freddy

The reason for this problem is the JAS server cannot access call object kernels or the security kernel on the enterprise server for one reason or another. The reasons I have encountered are:

SecurityServer=<blank> in the enterprise server's JDE.INI

OCM Mapping for the "J" environments that point BSFN's to LOCAL instead of the Enterprise server.

Disconnect from Call Object Kernels - depending on tools release the JAS does not reconnect gracefully when the enterprise services have been stopped and started.

Call Object kernels not starting for some other reason such as DB error.

Take a look at your jas.log and enterprise server logs. The particular reason the JAS cannot contact the kernels may jump out at you.

We've noticed different instances of missing buttons/icons when the user was using IE7. Not sure if this pertains to your current situation but thought I would bring this to your attention just in case.

Regards,
Bayeser

[ QUOTE ]
Disconnect from Call Object Kernels - depending on tools release the JAS does not reconnect gracefully when the enterprise services have been stopped and started.

[/ QUOTE ]

Hi Justin,

Can you point a specific tools release is this first fixed or corrected... Under our Tools Release 8.96G1 this is still an issue.

thanks.

Thanks for the suggestions people but we've tried this (bouncing the enterprise and the web server to get around the Call object kernel issue if any and checking the mappings of the BSFN user in J environment. None of them had an active mapping).

Also our IE is 6.0.

We have tried most of the things possible here but of no help. Can there be any other reason causing this weird thing?

thanks,
CNY Guy

Have you examined the JAS.log? Does anything jump out? The things I mentioned in my post are the only things I have ever seen cause this problem. Perhaps you have come across something new. If you post your log to this thread the group can be of more assistance.

Sorry, I should have given a more detailed comment. I don't know of a specific tools release that guarantees that reconnect from a running JAS to a restarted enterprise server will work. I have a site on 8.96F1 and we find that usually we do not have to restart the JAS after an enterprise server restart. However as a matter of practice, in production we usually restart everything in sequence because we have found that the failover/retry behaviour of E1 is inconsistent.

Take a look at this white paper to get some official results from Oracle internal testing on failover:

http://www.peoplesoft.com/corp/en/doc_archive/red_paper/rp_e1perf_rac.jsp

The document is specific to Oracle RAC (Real Application Clusters) but the observations apply to pretty much any failover scenario with E1. I saw an early version of the document and the basic conclusion I made at that time is that transparent failover is not guaranteed.

Depending on what a particular user is doing at the time they are "reconnected" to an enterprise server there are four basic scenarios:

1. The user will not notice the reconnect and the active transaction will complete successfully while writing valid/complete data to the transaction tables.

2. The user will not notice the reconnect and the active transaction will "appear" to complete successfully while writing *invalid/incomplete* data to the transaction tables.

3. The user will be presented with an error message. Exiting the specific application and restarting it (not the E1 session) will allow them to continue working.

4. The user will be presented with an error message and will have to logout and login to get back to a valid session state.

The second experience is the most dangerous as the user is not aware of any problem and there may be data corruption after a failover.

Based on Oracle's own findings we should definitely keep restarting the JAS after a service restart or node failover (at least in production):

"EnterpriseOne interactive clients and batch processing UBE’s produced various results that were not consistent across the EnterpriseOne applications tested when the RAC node fail-over occurred. If Oracle 10g R2-RAC is implemented, users must be aware of the normal EnterpriseOne application interactive behavior and be very observant to visual differences that might indicate a node failure has occurred.

When the Oracle database RAC option is implemented a data verification process needs to be previously defined, tested, and accepted as a reliable method to be able to check the integrity of the data that was being accessed when the RAC node fail-over occurred. The methods implemented to perform this data integrity check may be an automated job, a manual interactive user process or a combination of both that every company implementing RAC must decide on how to best perform this check."

Again, although the above is Oracle RAC specific the findings definitely apply to the other supported E1 platforms/DB's.