question about adobe merge plugin and E1 web users

FNorelli

FNorelli

Well Known Member
There is an Adobe Acrobat reader plug-in for merging JDE .pdf files with Create!Form project templates. Every Citrix server has a merge plug-in. When a user views the output of a JDE batch job using Work Submitted Job | View PDF, there is an Adobe option is available for the user to ‘Merge’ that .pdf with a Create!Form template. Otherwise, if a user prints the output without viewing it first, the .pdf merge happens automatically before the output is sent to a print device.

With a web implementation , If the user directly prints the .pdf from WSJ, the merge will happen automatically, just like on the Citrix server. HOWEVER, if a user decides to view the PDF first, a copy of the .pdf is displayed from the web server using the local workstation’s Adobe Acrobat reader. This will NOT have the plug-in for merging. There is no way for the user to merge the raw JDE .pdf with a CF template.

To get around the issue, simply install the Adobe plug-in on the user’s workstation. This will add a merge option to the local Adobe application. However, given that there will be 400 + users on the JDE web implementation, each one will need their own copy of the plug-in. This becomes an administrative nightmare. First off, the plug-in must be manually installed. Next, the plug-in is based on a specific Adobe version. Since Acrobat is a free application downloaded from the internet, users can freely update the software making the plug-in is vulnerable to users initiated updates.

So my question is simply "if you are using a JDE web implementation along with Create!Form, how are you handling the Adobe merge plugin issue"?

Thanks,

Fred
 
Fred,

We have what can only be described as a unique solution. In short we automatically "print" the jobs that have Create!form formatting and copy the merged PDF back to the server and overwrite the original PDF. So when ever any user views or prints (via Adobe Reader or straight from JDE) the PDF, it is already formatted. The set up is simple in method, but a little complex in putting into action.

There are 2 problems we have:

1) If a user viewed the PDF before it was overwritten with the merged version, the original version is cached (I believe) and if they try to view the PDF again after it has been overwritten, they see the unmerged version still. They have to log out and log in again before they can see the merged PDF.

2) Because Adobe can scale PDFs when printing and the setup on individual PCs can vary, when printed from Adobe after viewing the PDF, the output can vary from PC to PC. This can cause problem for things such as cheques and invoices.
 
Peter, could you please indicate how you have implemented the following:
1) When you indicated you automatically "print" the document how is this done? Are you using Director and PDF publisher to merge with a Create!form project and output to a folder?

2) When you overwrite the original PDF does this affect JDE security? Does JDE use the meta in a PDF to control who submitted the report? Can any user access the merged PDF's and does this affect work with submitted jobs?

3) What is the name of the folder you are copying the Merged Output to, is it a user or just the print queue folder?
 
Will,

To answer your questions:

1) Automatic printing is done via modifications to JDE (see post #121224 and #121267) that either use the print immediate parameter when a batch job is submitted or via a jde table trigger on the F986110. The pdf is "printed" to a "create!formed" print queue which uses Director to merge the output and Publisher to output to a folder on the Create!form Server.

2) Overwriting the PDF does not effect how JDE accesses it. It is all as if it was not overwritten.

3) Publisher is used to output to an intermediary folder on the Create!form Server.

To provide more information:

From here we have a cmd file that is run by the windows scheduled tasks and wakes up ever 5 mins to move the output file and overwrite the original pdf on the enterprise server. This is done because Publisher can only write to a local folder (or, I think, a mapped drive - not sure about that - but we wanted to avoid mapping a drive). The cmd file uses the xcopy command to copy the output from the Create!form Server (a windows box) to the print queue folder on the enterprise server (a unix box). Access to the print queue folder on the enterprise server is set up to be done via the \\server\share method. Explanations for using xcopy and how the print queue folder on the enterprise server is set up to be done via the \\server\share method can be provided if required.
 
Can I recommend an update to your solution?
If you have a San, attach a drive or similar as a local drive to both your application servers and your create!form server. Then publisher should be able to map to it, and the drive would so up as a local attached drive. Move your print queue to this drive. Then both servers would see it as local drive.

But I like your idea of updating the PDF immediately. I might try that.

For certain reports do you have them set to email at this same time?
 
Radjammin2,

I had considered the mapping of drives, but we have a policy of not mapping drives on servers. I have no idea why, but that is a limitation I have to work within.
 
I am talking about a local resource drive. So not like a user or network base drive mapping. So your computer will treat it as a local drive, vs. a network drive. If the server is attached to a SAN it should be able to attach disk space in this manner.
 
Radjammin2,

We have a SAN (or similar) attached to the Enterprise Server (Unix box), but not to the Create!form server (Wintel box). I'll ask our systems people to see if this is possible and within our IT policies. I'd love to be able to get rid of the cmd file. Thanks for your suggestion.
 
Our system people say that we use NAS and it is not possible to set it up as a local resource.

They also said that it wasn't possible to set up a SAN so that two different Operating systems can both see it as a local resource.
 
Hi there

Not quite sure what tricks I used to get it to work, but I am using a COPYTO command in Director to save a PDF to a folder using UNC pathnames, in the format \\aixstl17\myfolder\myfilename.pdf and what's more, the thing is a Samba share.

C
 
Back
Top