I have a business requirement to post the XDP Data Package as part of a Web Service call.

I am very familiar with doing this via the HTTP Submit buttons and processing via ProcessForm method in the Java API.

I am NOT familiar with the web services peice. I have looked in the Help and Docuemntation, and I understand how to do bind fields and all that via a WSDL. But what I want to do is hit the Execute button and make a WSDL call.

In that Web Service call I want to send the XDP Data Package (XDP and Data in Form) similar to HTTP Post as an attachment or whatever.

To do web services calls you need to be able to bind the input/output of the WS call to fields on the form. So to do what you ask you need a field that will hold the data that has been collected (this data is stored in the Data Dom but it is not in a bindable field - we will have to put it there). You can make this field invisible after we get this working but leave it visible until you are sure you are getting what you want. Make the field multi-line and make it so that more than one line is visible (this will allow us to visually see that the field is getting populated). Now drop a new button on the form (this will be the user's submit button but we will program to do what we want). This button will copy the contents of the data dom to the hidden field, then execute the WS call for you. For the sake of coding lets say the field is called TempField and the WS execute button is called WSCall. Now add this code to the fake submit button's click event:

//Get data from data dom and out into a field. The pretty flag
//formats the xml to make it more readable

TempField.rawValue = xfa.datasets.data.saveXML("pretty");

//Now execute the WS

WSCall.execEvent("click");

Note that the web service will only have one input parameter. The field that holds the complete Data Dom. You may have to wrap your inbound XML in a CData section to get it through the network. You can do that by concatinatin strings.

I would like the entire XDP Package so I can have the layout and data in one file. After the post to the web service I want to store the XDP in a repository. We already do this with HTTP Submission. I am trying to do this for a Web Service invocation.

That way if I want to render the PDF again I can just pull the one document instead of pulling the Data XML and then pulling the Template out of a repository.(My company does not leverage the new Repository features in ES, we have our own template repository tool we had to build since Adobe 6 and 7 did not have one built in.)

I have a similar requirement and looking for a real neat solution for implementing this:

I have developed a pdf form using livecycle designer and it has a submit button in it. The form is published to our organization website. What we would like to do is, when the user opens and fills up the pdf form either on web browser / or after downloading to their desktop, users should be able to post the data in the form directly into our IMS database.

I understand that we need to use a Submit button with Submit As property set to XML. But, what I would like to know is the architecture and how the components communicate here. i.e. for our design document. Our users are not connected to the org. network but just to the internet where they can find this pdf form.

I am assuming that we would need to lay out these components on the diagram but not very sure of the order in which the data is flowing from LiveCycle and WebServer.

1. Web browser
2. Internet Connection
3. Webserver (this is where the org. website is and the form is located on the website)
4. LiveCycle ES on an application server?
5. Database tier.

Appreciate if anyone could tell me exactly the steps and the data flow.

1. It is possible to communicate the stand-alone pdf to the database via webservices.
2. webservices are best used for offline forms having submit button functionality.
3. we can call webservices(WSDL) by using javaScript calls.
3. It is also possible to communicate with the database by using data source. But I wouldn't recommend you to use this, because each client machine should contain DSN source.
4. It is not known that stand-alone pdf communicate with the database by using JDBC calls via thin driver.

I am guessing a stand-alone pdf shouldn't contain JVM. As we all know that this methodology is possible at the server side.