renderPDFForm problem
wo...@subjectivist.org
version 9. The process in 8.2 was real simple using renderPDFForm, only.
There was a form name input variable as a string, a data input variable as
a document, and a PDF output variable as a document. The form had to
already exist on the server in the repository area. The form name variable
was used as the file name to fetch from the repository area. The data was
given as a URL on the web server requesting the print service. When the
process executed it would create a flat PDF at a temporary path on the
Adobe server and return a URL in the reply XML.
I did a screen print of the process from 8.2. Not much to look at. There
is the one service type, two input variables, and one output variable.
I was told not to import into version 9 but redo everything. No big deal
it would seem. I made all variable types "document". Back when I was
developing on 8.2 I was told in the next version I could supply the form
AND data in the command XML, and the form would not have to be found and
read from the Adobe server.
Right now I'm just trying to invoke my new version 9 process to see what
happens. It tells me:
ALC-DSC-002-000: com.adobe.idp.dsc.RequiredParameterException: Parameter:
inFormDoc is required
I don't know where to enter this info. Also, is it appropriate to use
"document" for the three variable types. Thanks
RobMcD
> I don't know where to enter this info. Also, is it appropriate to use
> "document" for the three variable types. Thanks
process.
How are you trying to invoke the new process you've created? From
workbench?
You should get a dialog that has your input parameters listed. If
they are document variables, there will be a button to the right with
several dots on it. You can hit that button to select a local file.
You need to select a local file for your XDP form template and for
your XML data. After the process executes you will get another
similar dialog that lets you view or save the resulting output
document (presumably a PDF).
> Back when I was
> developing on 8.2 I was told in the next version I could supply the form
> AND data in the command XML, and the form would not have to be found and
> read from the Adobe server.
advanced technique, and I would not try it until you have more
experience.
The form does not have to be passed in as a document however. You can
pass in a string containing a filename and then retrieve the form into
a document variable. What service you use move it into the the
document variable will be different depending on where the form
resides. You can use the Foundation/File Utilities/Read Document
service to retrieve it from the file system or the Foundation/
Repository/Read Resource Content service to retrieve it from the
LiveCycle repository.
Another approach I used recently was to point the Content Root to the
local hard drive (e.g. C:/Adobe/LCForms) and then use a string
variable to hold the template name. This does require that you select
the "all" process properties setting instead of just the "basic" ones.
Regards,
Rob
Rob McDougall | Senior Technical Architect | 4Point | www.4Point.com
wo...@subjectivist.org
Thanks Rob. The thing started working. I changed the form variable to a
literal, read from the Adobe server, and it rendered. Then I changed it
back to a document variable where I needed to provide the form via prompt,
and it continued to work. Weird.
When I invoked the process via workbench and received the form and data
prompts, I tried pasting in HTTP urls instead of file names. That worked,
too. But I think workbench read the urls, converted to blobs, and sent as
blobs. I don't think workbench actually sent the urls.
The WSDL for the service shows all the data types accepted. I was using a
url for the previous 8.2 service. Unfortunately my local web server is not
exposed to the Adobe server, so it can't pull from a url. The 8.2 Adobe
server was able to see my local web server.
This is a classic ASP application where some PDFs have been scabbed in.
Now I'm working on base64 encoding.
RobMcD
On Jun 7, 2:29 pm, w...@subjectivist.org wrote:
> When I invoked the process via workbench and received the form and data
> prompts, I tried pasting in HTTP urls instead of file names. That worked,
> too. But I think workbench read the urls, converted to blobs, and sent as
> blobs. I don't think workbench actually sent the urls.
> This is a classic ASP application where some PDFs have been scabbed in.
> Now I'm working on base64 encoding.
DIME, MIME, or MTOM to send and receive the documents as attachments.
This is much more efficient than sending a base-64 blob.
Have a look at the quickstarts in the Adobe documentation for
examples: http://help.adobe.com/en_US/livecycle/9.0/programLC/help/index.htm?content=000230.html
wo...@subjectivist.org
>> Now I'm working on base64 encoding.
>
> You shouldn't need to do that. You should be able to set up either
> DIME, MIME, or MTOM to send and receive the documents as attachments.
> This is much more efficient than sending a base-64 blob.
>
> Have a look at the quickstarts in the Adobe documentation for
> examples:
> http://help.adobe.com/en_US/livecycle/9.0/programLC/help/index.htm?content=000230.html
>
> Regards,
> Rob
>
> Rob McDougall | Senior Technical Architect | 4Point | www.4Point.com
Already did the base 64. Works great. Only four lines of code using an
Microsoft.XMLDOM object. I don't use it for the XML but it has a base 64
convert routine.
If I sent a blob I was afraid I would get a blob back, too, but the
service returns a url for the created PDF, making everything work perfect.
With this web service we can create a PDF from any application, web or
desktop. One command XML is sent containing the form and data. The reply
XML contains a url for the created PDF.
I may see about MIME which is a little more efficient.