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.

Simplified E1 URL

Wanna see an ugly URL?

http://thisismyservername:82/jde/owhtml


Can we please stop doing this to our EnterpriseOne users? Not only is it tedious and non-descriptive, it looks amateurish.

The use of aliasing and Virtual Hosting techniques in DNS, IBM HTTP Server (Apache), and WebSphere allows E1 JAS instances to be referenced by name instead of by TCP Port Number. DNS mappings, Apache VirtualHosts, and WAS Host Aliases are created to enable this solution. This gets rids of the port numbers.

Paper is here: http://sites.google.com/a/karamazovgroup.com/blogfiles/Home/whitepapers/E1%2CEliminatePortNumbersJAS.pdf?attredirects=0


In addition, we can get rid of the "/jde/owhtml" portion of the URL by using the Apache DocumentRoot directive.

Paper for this part is here: http://sites.google.com/a/karamazovgroup.com/blogfiles/Home/whitepapers/E1%2CSimplifiedURLusingDocumentRootv1.00.pdf?attredirects=0

These white papers are a bit dated in the WebSphere area but the methods remain the same.

When you get done you will have proper URL's that look something like this:

http://e1development
http://e1prototype

or

http://e1dv.domain.com
http://e1py.domain.com

or

http://whatevernameyourlittleheartdesires

Load Balancing at all Levels in EnterpriseOne with Web Technology

I am surprised to hear that so many people are not using all available methods to load balance and create redundancy in their E1 systems. This is not the first time I have read someone mention that Network Deployment is not a good solution. I think that ND is the only really feasible application-level load balancing and failover device available. I try to introduce redundancy into my system at every level in the following ways:


1) Network- Accomplished using either DNS round-robin, NLB, or a hardware device.

I haven't worked with NLB yet but apparently it offers improvements over DNS like fault tolerance and intelligent load balancing.

- DNS will continue to send network traffic to a down server and is rather dumb when balancing.

Note: DNS round-robin will recognize when just an HTTP server is down and route to the other HTTP server

- NLB will stop sending diners to the dead waiter's table : - )
- NLB is also supposedly session sensitive, meaning that it will continue to send packets to the server holding the active session.



Another possibility is using IBM's Edge Components that are included with the Tech Foundation.

If you have a lot of money a hardware load balancing device is the way to go


2) HTTP - Multiple HTTP servers (Apache or IIS) preferably on separate servers from WebSphere.

It is not always economically feasible to separate these from WAS but to ensure high availability
at the HTTP level one must have more than one HTTP server, fronted by a method mentioned above balancing the load to these servers.


3) WebSphere - On WAS 4 we cloned software JAS servers in server groups (Vertical and Horizontal) to ensure high availability at the WAS level. In WAS5 and WAS6 all we do is create a cluster of JAS servers and manage them with Network Deployment. There are a couple of items that need to be done with ND but this works and the load balancing works. Not sure why we would not take advantage of this and heck, it is easy to create a cluster. The use of a vertical cluster ensures efficient utilization of memory on the box and several small JVM's have much more efficient garbage collection than one large JVM. I am not sure how others are scaling their web systems without using WAS clustering. If you use a single instance and increase the JVM heap size to accommodate additional users the system will pause too long during garbage collection. I create 3 or 4 instances using clustering and give each one a 512 or 768 MB heap size.

As far as the comment about how NLB load balances, if you have sticky sessions configured you should get the same server as last time. NLB cannot determine that a JAS session is not responding and will continue to send network traffic to that box. If the server (hardware, OS, NIC, etc.) stops responding then and only then will NLB redirect. You have to count on WAS clustering (using Network Deployment) to direct away from failed JAS instances.

You have to use the right tools for the right job- NLB will redirect away from failed hardware, the HTTP WAS plug-in will redirect away from failed WebSphere servers, WAS clustering will redirect away from failed JAS instances.