Auto Open PDF's in EnterpriseOne Web Client

There has always been an issue opening PDF files from the Work with Submitted Jobs list in the EnterpriseOne web client - the end user is prompted to determine what they wish to do with the file when, chance are very good that they want to open it.  The problem is related to how the PDF content is delivered to the browser by the E1 code and how the browser handles that content.

Full disclosure: I completely stole this issue from a JDEList thread and the solution from user ice_cube210 (Tonio Thomas).


Problem Presentation

The problem manifests as a prompt in the browser every time a user opens a PDF from Work with Submitted Jobs (WSJ) asking what they want to do with the file:

Internet Explorer 8

Firefox 6

This gets old really fast.  Users generally want to open the file.


Background

The root of the problem, as mentioned above, is how a PDF is delivered to the browser.  PDF's can be sent to a web browser as either a file/attachment or inline as defined by the "content-disposition" HTTP header.  When a web server sends a PDF to a browser the content-disposition header is set to either "attachment" or "inline" or possibly not set at all.  The value of the content-disposition header tells the browser how to handle the content as defined in the RFC's rfc2183-in-http and rfc2183.  If the header is content-disposition: attachment; the browser will enter the "Save as..." dialog.  Use of the content-disposition: inline; header or the absence of a content-disposition HTTP header will cause the browser to use default processing to handle the content.  From this point it is up to the browser to determine how to process the PDF.  For Internet Explorer 8 default processing means opening the PDF in the browser's embedded PDF viewer and for Firefox 6, a separate PDF viewer (although this behavior can be changed).


EnterpriseOne Behavior

By default, when a user selects "View PDF" in WSJ EnterpriseOne sends the PDF as a file, using the  content-disposition: attachment; header.  This causes the browser to enter the "Save as..." dialog as stipulated by rfc2183-in-http. The end user must then choose to either open or save the file.  Choosing Firefox's "Do this automatically for files like this from now on" seems to be forever broken so is of no help.

For the really geeky here's what the HTTP headers look like for the default E1 behavior:

HTTP/1.1 200 OK
Date: Wed, 21 Sep 2011 18:19:00 GMT
Server: IBM_HTTP_Server
Content-Disposition: attachment; filename =R0006P_XJDE0001_428652_PDF.pdf
Content-Length: 762280
Keep-Alive: timeout=10, max=99
Connection: Keep-Alive
Content-Type: application/pdf
Content-Language: en-US


Note the content-disposition header, with filename parameter.


Workaround/Solution

From Tools Release 8.98 on there has been an option to present PDF's in a manner that will automatically open in the user's browser.  The setting is the "UBEContentDisposition" parameter in the [OWWEB] section of the JAS.INI and can be easily changed in Server Manager in the Web Runtime configuration for the JAS server as described here.

At first I thought Oracle had used the content-disposition: inline; header but examination of the HTTP headers shows that once the setting is changed, the content-disposition header is simply removed.

HTTP/1.1 200 OK
Date: Wed, 21 Sep 2011 18:20:44 GMT
Server: IBM_HTTP_Server
Content-Length: 762280
Keep-Alive: timeout=10, max=88
Connection: Keep-Alive
Content-Type: application/pdf
Content-Language: en-US


I suppose that will work.  The RFC allows for no content-disposition header.   The absence of the header will cause the browser to use the default method of presentation and we get the desired behavior - automatically opening PDF's. I'd much rather see the content-disposition: inline; header and have Oracle also use the Disposition Parameter: 'Filename' to give us a real filename to use when saving the file from Acrobat Reader (see below).


Issues with Workaround

An issue with the fix may preclude some customers from using this workaround - when UBEContentDisposition is set to True (the default) and the PDF is sent as an attachment, the UBE name (R0006P_XJDE0001_429031_PDF.pdf) is sent to the browser/Acrobat Viewer and allows one to save the file with the original EnterpriseOne UBE name:

Original UBE Name

When using the workaround and setting UBEContentDisposition to false, a generic PDF name (com.jdedwards.jas.pdf) is passed in:

Generic Name

This causes a problem when one wishes to save the PDF using the original UBE name for reference.  You can always name the PDF whatever you like but it is darn convenient to have the report name passed in.  Whether the naming issue is important enough to keep you from changing how PDF's are handled in the browser is an internal organizational issue.  We should be able to pass in real UBE names using the content-disposition: inline; header with the 'Filename' parameter but the smart folks at Oracle probably know something I don't.  I've suggested it and we'll see.

This is a very handy setting to change.  Anything that makes end users' work easier and more efficient is worth doing.

EnterpriseOne Temporary Print Files on Enterprise Server

Your EnterpriseOne system may be creating hundreds of thousands of files on your JD Edwards Enterprise Server in a location that is not readily apparent and not cleaning them up...ever.

During a UBE run that involves a version that has Print Immediate turned on at the version level (introduced in TR 8.96) a 'temporary' print definition file (either PostScript or PCL depending on how you defined the associated printer) is created in the location specified in the netTemporaryDir= directive in the [JDENET] stanza in the Enterprise Server jde.ini.

The purpose of the file is to allow the Print Immediate printing of the generated PDF using the printer defined in P98616|W98616O - Work With Default Printers.  The problem is that there is no process for cleanup of the file after it has been utilized.  Deleting the job from the submitted jobs list removes the job record and the PDF but leaves the print definition file.  The R9861101X/R9861102 UBE's that purge submitted jobs doesn't remove the print definition files either.  What you end up with is a very large number of files that are not needed after the initial Print Immediate action.

Oracle's suggestion is to set KeepLogs=0 in the jde.ini but that has the effect of not keeping the UBE logs after the job completes, which is sometimes useful.  It has been suggested to development that either the 'temporary' print definition file be deleted after the file is used (preferred) or the files be cleaned up as a part of deleting a job from the submitted jobs list and/or a part of the submitted jobs purge UBE process.

Important Update (9/8/2011): Changing KeepLogs to 0 (In Server Manager for the Enterprise Server in question - Logging/Error and Debug Logging/Keep UBE Logs = Remove Logs Once Printed) and UBESaveLogfile to 1  (In Server Manager for the Enterprise Server in question - Batch Processing/Save Empty Debug Log = Keep Empty Debug Log) in the Enterprise Server jde.ini will cause EnterpriseOne to retain the UBE logs while removing the print definition file.  I'd still prefer that the software cleanup after itself instead of hacking the UBE logs code but this appears to solve the problem.  Now if only Oracle will make this the default setting.

In the meantime, feel free to go to C:\JDE_HOME\targets\Enterprise_Server_enterpriseservername\temp on your Enterprise Server and remove those files.

Restarting the EnterpriseOne Queue Kernel

There is a way to restart just the UBE queue in EnterpriseOne. If you are faced with a situation where submitted jobs are not processing and the jobs are sitting in a waiting status you can get the queue restarted without bringing down the entire E1 system, allowing interactive users to continue their work.

In older (prior to 8.9) releases the queue was a separate Windows service called JDE Update 4 B733 Queue or something similar. This service could be stopped and started independently of what was then called JDE Update 4 B733 Network or the "Network" service. This made it easy to restart the queues without bothering the main service. In the 8.9 release however, the queue service was redesigned and turned into a kernel under the main E1 service, greatly complicating the targeted restart of the queues but not making it impossible. Here's how:


Go to the JDEdwards\E812\DDP\log directory and search for files containing the text QUEUE KERNEL. This will give you the queue kernel PID in the file name (i.e. jde_9188.log). You will (should) have only one queue kernel. Go to Windows Task Manager and View/Select Columns and add the PID column. You can kill that PID and the next time a job is submitted the Queue kernel will be restarted.



There are also ways to move jobs from one queue to another but that's a post for another day.

EnterpriseOne User Specific Dynamic Logging with WebSphere Network Deployment

Denver's Server Manager product is the new(er) method for managing all aspects of EnterpriseOne servers - monitoring, configuration, tuning and logging, etc. CNC administrators can now modify settings, see what's happening on their system and do logging all in one interface . In particular the logging enhancements are worthy of mention. I will show that while Server Manager is a great tool, Oracle still has a ways to go for full integration with WebSphere in general and WebSphere Network Deployment specifically.

A new function for user specific, dynamic logging allows the administrator to:

- Log an individual JAS session without impacting other users.

- Begin and end this logging without having to stop and start the entire JAS instance.

The concept is great and I applaud the developers for this functionality. However, as with some other functions in Server Manager there are issues when one is utilizing WebSphere Network Deployment.

Network Deployment uses a centralized Deployment Manager node that controls a cell into which individual remote WebSphere nodes are federated. Any changes to configuration files are controlled by the Deployment Manager and must be propagated to the remote nodes. This appears to be where the problem starts with user specific dynamic logging.

Let's take a look at the steps needed to reproduce the situation and what we can do to work around the issue until Oracle fixes it:


Enable user specific dynamic logging by selecting Create New User Specific Log Configuration, entering the user name for the user for which you wish to enable logging.
















Modify for Verbose logging and Threads and apply.



This action will write the logging information to the jdelog.properties file in the target's config directory but will not write it to the actual jdelog.properties file on the WebSphere node.





User specific logging is not yet actually occurring even though no error message in Server Manager will tell you so and, according to the documentation, the logging should begin immediately.

What's happening is that the jdelog.properties file on the remote node is not getting updated and therefore the node has no information on the user specific logging.

We must use the synchronize function in Server Manager to propagate the changes and make user specific logging work in a Network Deployment environment since, among other things, the Synchronize Node command will copy the configuration files (jdelog.properties in this case) to the remote node(s).

If you select the HTML managed instance for which you set up the logging you will be prompted to synchronize the configuration.



This is your first indication that the local and the remote configuration files are not in agreement.

Go ahead and synchronize the configuration but be warned that as of right now, selecting the Synchronize Configuration button will expire all users sessions for that JAS instance without warning from Server Manager. (Note: Apparently fixed in TR 9.1.  Synchronize Configuration no longer restarts the instance unexpectedly but one must not manually restart the instance to see the changes.)

After synchronization completes you can see that the jdelog.properties files on the remote node now contains the individual logging settings.




Oracle has been made aware of the issue but I do not foresee a quick fix to the issue. In the meantime, you can manually synchronize using the button but remember that you will kick your users off if you do so. Oracle has been made aware of this issue was well. It's not quite as "dynamic" as intended but will allow you to do user specific logging.

EnterpriseOne SQL Security

Permissions in SQL for E1 are granted thru the System User/Multiplexing User's (JDE usually) membership in the database role PUBLIC.

The PUBLIC database role has Create Table permissions.

The PUBLIC database role has SELECT, INSERT, UPDATE, DELETE permissions on all tables within the database.

The object owner (PRODDTA, PRODCTL, etc.) database role has explicitly granted object permissions to allow SELECT, INSERT, UPDATE, DELETE. This allows the object owner to perform certain actions through E1 (R98403, Copy Table, etc.)

Because the PUBLIC role has database and object level permissions it is imperative that any newly created SQL Server login that you wish to have read-only access to a database be placed in the db_denydatawriter database role in addition to the db_datareader database role to explicitly override INSERT, UPDATE, DELETE permissions granted to all database users via their membership in the PUBLIC role.

Note: Due to the way E1 grants object permissions via PUBLIC, it is not technically necessary to place a database user in the db_datareader role. However, doing so will make permissions viewing easier.

It is also important that a newly created SQL Server login be explicitly denied the create table permissions in the database at the user level if table creation is not desired.


Two ways to deal with this:

Continue to use Public security and

1) remove SQL Server guest user from each database (SQL 2000) or revoke CONNECT permission (SQL 2005/SQL 2008) and
2) be sure to place ad-hoc (non-E1 app) users in the db_datareader and db_denydatawriter roles for each database
3) Deny CREATE TABLE to new SQL Login

or

Perform Oracle's MS SQL Server 2005 Public Shutdown for JD Edwards EnterpriseOne

I prefer the first method.

EnterpriseOne CNC Training

From the mailbag came the following question that I thought I would answer for everyone:

"Hi Jeff, what do you recommend for Oracle CNC training?"


My answer:

Depends on who it is for. A new CNC guy should have his training tailored and more importantly, timed to coincide with what they are doing on the system.

Common Foundation will provide the CNC trainee with the basics of E1 and should be taken just prior to the start of the implementation.

During an implementation the CNC person should be taking the CNC System Admin class while doing the tasks necessary to configure the system.

The Security Principles class should be taken about mid-way through the implementation as the security design is about to occur.

Late in the implementation, either near or just after go-live the CNC admin should attend the OMW/Change Management course.

System Administration Troubleshooting should be taken after the CNC person has a bit of experience.


The key is to align the classes so that the knowledge gained in the class is relevant and used right away, before the information gets stale and is forgotten. It also helps to have the correct knowledge ready for the events taking place during the implementation.

Simply match the learning with the doing. If this is not possible try to match the two as closely as you can. If you are asking this question post go-live, which is likely, just start hacking away at the courses, being careful not to take the next class before the information is learned, absorbed, practiced and solidified.


A listing of all Oracle courses can be found here.

Regards,
Jeff

Using Alternate EnterpriseOne Serialized Objects Tables

No downtime, middle of the day full serialized objects generation.

When CNC admins have time to sleep they dream of getting more sleep. They imagine that there is the possibility of performing administrative tasks at some time of the day other than during The Maintenance Window.

Generating a full set of serialized objects is not as critical as it was prior to Dynamic Web Generation and Auto Package Discovery, both introduced in the 8.96/8.12 release, but if you are on a Tools Release prior to 8.96 or simply wish to generate a full set of serialized objects without disrupting your users or possibly your social life, try using two sets of the serialized objects tables (F989998/F989999).

The concept is that *PUBLIC will be using one set of serialized objects tables while an EGEN user will be using another set during the full generation.

Setup

Create an E1 user EGEN with associated security record, role membership, etc. Ensure the EGEN user has access to the J* environments.

Using OMW, generate the F989998 and F989999 serialized objects tables in the Business Data datasource for each environment.

Create copies of System OCM's for F989998 and F989999 for all J* environments so that you have OCM's for both tables for both Central Objects and Business Data for both *PUBLIC and EGEN, one active and one inactive.

The easiest way to get the OCM's copied correctly is to copy the existing F989998 and F989999 OCM for Central Objects, changing the Data Source to Business Data and the System Role to EGEN during the copy and then make those OCM's active. Then copy all J* environment F989998/F989999 OCM's, changing only the System Role from *PUBLIC to EGEN or from EGEN to *PUBLIC during the copy. This step will create the proper inactive OCM's.

You should end up with something that looks like this:

Environment	Object Name	Object Type	Primary Data Source	System Role	Object Status
JDV812	F989998	TBLE	Central Objects - DV812	EGEN	NA
JDV812	F989998	TBLE	Business Data - TEST	*PUBLIC	NA
JDV812	F989998	TBLE	Business Data - TEST	EGEN	AV
JDV812	F989998	TBLE	Central Objects - DV812	*PUBLIC	AV
JDV812	F989999	TBLE	Business Data - TEST	EGEN	AV
JDV812	F989999	TBLE	Central Objects - DV812	*PUBLIC	AV
JDV812	F989999	TBLE	Central Objects - DV812	EGEN	NA
JDV812	F989999	TBLE	Business Data - TEST	*PUBLIC	NA
JPD812	F989998	TBLE	Central Objects - PD812	EGEN	NA
JPD812	F989998	TBLE	Central Objects - PD812	*PUBLIC	AV
JPD812	F989998	TBLE	Business Data - PROD	EGEN	AV
JPD812	F989998	TBLE	Business Data - PROD	*PUBLIC	NA
JPD812	F989999	TBLE	Business Data - PROD	EGEN	AV
JPD812	F989999	TBLE	Central Objects - PD812	*PUBLIC	AV
JPD812	F989999	TBLE	Business Data - PROD	*PUBLIC	NA
JPD812	F989999	TBLE	Central Objects - PD812	EGEN	NA
JPY812	F989998	TBLE	Central Objects - PY812	EGEN	NA
JPY812	F989998	TBLE	Central Objects - PY812	*PUBLIC	AV
JPY812	F989998	TBLE	Business Data - CRP	*PUBLIC	NA
JPY812	F989998	TBLE	Business Data - CRP	EGEN	AV
JPY812	F989999	TBLE	Business Data - CRP	EGEN	AV
JPY812	F989999	TBLE	Central Objects - PY812	*PUBLIC	AV
JPY812	F989999	TBLE	Central Objects - PY812	EGEN	NA
JPY812	F989999	TBLE	Business Data - CRP	*PUBLIC	NA

Again, the concept is that *PUBLIC will be using one set of serialized objects tables while EGEN will be using another set during the generation. When the full gen is done, you will have a completely populated set of serialized objects tables waiting to be used while the other set continued to be used during the full generation. An OCM swap and a cache flush will put the newly generated tables into use without interrupting users.

Execution

Update (10/25/2009):  Starting with release 8.12 you must generate a package manifest for auto-package discovery to work when you deploy update (or full) packages.  This package manifest exists as a record in the serialized objects tables so if you truncate the F989998/9 tables prior to a full generation, the auto-package discovery functionality will be broken.  Since this impacts our method I have added a step to account for this functionality.

Steps for 8.12/8.96 and greater:

1. Truncate the serialized tables that are actively OCM mapped to the EGEN E1 user
2. Comment out the [JDBJ-SPEC DATA SOURCE] stanza in jdbj.ini to use the WebDev machine for egeneration (Thanks to John Bassett for this tip.)
3. Log into egenerator using the EGEN E1 user
4. Generate manifest
   
5. Generate core objects
6. Login to the web client once using the EGEN E1 user
7. If you wish to pre-generate serialized objects, perform a full generation
8. Rebuild the indexes for the F989998 and F989999 tables
9. Perform an OCM swap for *PUBLIC and EGEN
10. Flush the OCM and serialized objects caches

Steps prior to 8.12/8.96:

1. Truncate the serialized tables that are actively OCM mapped to the EGEN E1 user
2. Comment out the [JDBJ-SPEC DATA SOURCE] stanza in jdbj.ini to use the WebDev machine for egeneration (Thanks to John Bassett for this tip.)
3. Log into egenerator using the EGEN E1 user
4. Generate core objects
5. Login to the web client once using the EGEN E1 user
6. If you wish to pre-generate a full set of serialized objects, perform a full generation
7. Rebuild the indexes for the F989998 and F989999 tables
8. Perform an OCM swap for *PUBLIC and EGEN
9. Flush the OCM and serialized objects caches

The OCM swap will make the "alternate" serialized objects tables active for *PUBLIC and inactive for EGEN and will make the "original" serialized objects tables inactive for *PUBLIC and active for EGEN, ready for the next full gen and swap.

Example

Before:

Environment	Object Name	Object Type	Primary Data Source	System Role	Object Status
JDV812	F989998	TBLE	Central Objects - DV812	EGEN	NA
JDV812	F989998	TBLE	Business Data - TEST	*PUBLIC	NA
JDV812	F989998	TBLE	Business Data - TEST	EGEN	AV
JDV812	F989998	TBLE	Central Objects - DV812	*PUBLIC	AV
JDV812	F989999	TBLE	Business Data - TEST	EGEN	AV
JDV812	F989999	TBLE	Central Objects - DV812	*PUBLIC	AV
JDV812	F989999	TBLE	Central Objects - DV812	EGEN	NA
JDV812	F989999	TBLE	Business Data - TEST	*PUBLIC	NA

After:

Environment	Object Name	Object Type	Primary Data Source	System Role	Object Status
JDV812	F989998	TBLE	Central Objects - DV812	EGEN	AV
JDV812	F989998	TBLE	Business Data - TEST	*PUBLIC	AV
JDV812	F989998	TBLE	Business Data - TEST	EGEN	NA
JDV812	F989998	TBLE	Central Objects - DV812	*PUBLIC	NA
JDV812	F989999	TBLE	Business Data - TEST	EGEN	NA
JDV812	F989999	TBLE	Central Objects - DV812	*PUBLIC	NA
JDV812	F989999	TBLE	Central Objects - DV812	EGEN	AV
JDV812	F989999	TBLE	Business Data - TEST	*PUBLIC	AV

Now go dream about getting more sleep.

Hitler and the CNC Guys

Services Console Reconfiguration

So John Bassett and I were working at a client today, complaining about how often we had to go into the Services console and how bad the default settings were.  Every time you open the Services console the default view is Extended instead of Standard, the Window is mis-sized, and the columns are squished.

It looks something like this, which is pretty useless:


Figure 1 Services console default

My first move is usually to select the Standard tab and then resize the first column. Doing this every time is a hassle, so I found a way to set the default to the Standard tab and have it sized appropriately every time I open the Services console.

1- Find the Services console in Administrative Tools or as services.msc in the %SystemRoot%\system32 folder. (Usually C:\Windows\system32\services.msc)

2- Right-click and select 'Author'

3- Make the changes you desire i.e. Resize the window, change to the 'Standard' tab, resize the 'Name' column, etc.

4- Close the window, saving the changes when prompted

5- Re-open the services console either by double-clicking services.msc or selecting the menu item 'Services' from Administrative Tools and check your changes


Figure 2 Services console reconfigured

Every time you open the services console on that server in the future it will appear as you configured it. Also, you can copy services.msc from server to server if you wish.