Posts tagged "XDP"

Updating Hostname of WSDL Connections in XDP with LiveCycle Form Rendering Process

A lot of times form developers develop form designs locally on their machines or on development servers. When dealing with web services, they would use the local or development instances of the web services by creating data connections pointing to WSDL URLs on localhost or dev.server.com. This is perfectly fine until the forms need to be migrated to other systems such as system test, stating or productions. The form developers would need to revisit the forms and update the data connections to point to the appropriate URLs depending on which environment the forms are being migrated to.
This becomes a big time consuming issue on projects dealing with a vast amount of form designs. So recently what I have been recommending my customers is to use a form rendering process that updates the WSDL data connections in the form design automatically on the fly as the form is requested by a user.


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. 
wsdl-updating-form-rendering-process.png

Requirements

  • 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)
Download

Download wsdl-updating-form-rendering-process.xml
and import the XML into LiveCycle Workbench as a process.

Further thoughts
  • 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.