How does this work? (Please also refer to the process map below.)
- The process reads the requested form design resource from the LiveCycle repository.
- It then copies the content of the form design as XML to process variable and counts the number of WSDL data connections in the form.
- Then it loops through every WSDL connections and update the domain name including the port with a new domain name extracted from a process variable called targetURL. (This targetURL variable is passed in automatically when you set up your the Render Service setting in your form variable.)
- It then updates the form design variable with the new XML that has new WSDL information.
- Finally LiveCycle renders the form design into a PDF.
- LiveCycle Forms ES server.
- The form design has to be in an XDP format.
- The XDP has to be in the LiveCycle repository (e.g. database, Documentum, FileNet, etc.).
- All web services used in the XDP have to be on the same server as the LiveCycle instance.
- The only difference between web services on various environments must be the domain name and port. (e.g. http://dev:8080/soap/services/Weather?wsdl and http://staging/soap/services/Weather?wsld – OK but http://dev:8080/soap/services/Weather?wsdl and http:/staging/soap/services/Weather2?wsdl – Not OK)
and import the XML into LiveCycle Workbench as a process.
- If you need to reader extend your forms, add a Reader Extensions action at the end of the process map.
- If your form design is in PDF, you could modify the process map to read the PDF resource from the repository and convert it to XDP.
- What if you only deploy PDFs to your production system and don’t want to render them only the fly? You could render XDPs to PDFs as a batch process by creating a watched folder endpoint that invokes this form rendering proess.