I'm trying to render a form guide using the forms>renderformguide action/orchestration. It finds the xdp just fine, and the guides tag, but pukes when it tries to read the swc for the guide from the repository. I've verified that I can get the form guide working in designer view just fine, but it's just not rendering for me with the orchestration. I used the code from the quickstart ( http://livedocs.adobe.com/livecycle/es/sdkHelp/programmer/sdkHelp/wwhelp/wwhimpl/common/html/wwhelp.... ) to try and make it work with webservices but it just keeps failing.
Have you tried your form with the FormsIVS sample application? This will remove the form or the guide as the problem. If the form renders properly in FormsIVS, then your code that calls the program may have an issue. If the form will not render properly there either, then we know it is a form issue or how the template is stored in the repository.
Thanks Paul. I checked the logs and it appears to be deriving the URI for the associated form guide incorrectly. repository:/// is what it starts with instead of repository:// as I would expect. The interesting thing is if I take and set my base content URI to the FormsIVS/forms URL the code works just fine. It only seems to be having a problem expanding the relative URI when I'm using the repository.
Also, thanks for the tip on FormsIVS site, I'll check that out.
The last thing I want to put out there is that I've since updated the base content URI to repository://servername/userfolder/forms/ and the changed my form query string to just the name of the xdp and that actually will render the guide OK but still is not importing fragments of the base form logging the same "ALC-FRM-001-022: Unexpected exception: URI not found: repository:///servername/userfolder/forms" message
That's interesting because whenever that third slash is in there it (Livecycle ES Server) can't find what it's looking for. If it's just two then it seems to find it just fine. Does that mean that there is something wrong with my particular server?
Typically this is broken out in two parameters in the service. The form to render is the location of the form in the Repository (/category/formname) and the Content Root URI is set to repository// which is the pointer to the repository. These are added together to give you a path of repository///category/filename
OK, so my first parameter I've set to repository:// my second parameter when set to /wherever/whatever.xdp doesn't resolve to my xdp file- with or without the leading slash. When I have it set to repository://wherever/ and my formquery parameter set to whatever.xdp that works everytime. That's what I mean by it being interesting because my server doesn't seem to understand repository:///
Do you have any further insights? Thank you for your post and time.
Well, I fixed the issue this weekend. I'm not sure which it was, but I changed two things on the server and now it works as Seth describes. I first reinstalled SP2 because it looked like it wasn't completely installed successfully, and second I made sure that the jdk in my java home environment variable matched the version of jdk that jboss is using on our installation. After that and an application server restart it worked. Thank you all for you time and help walking me through this.