XFA Specification
Chapter 11, Forms That Initiate Interactions with Servers
Using Web Services
331
3. The
preExecute
event is triggered. If there is a script associated with it, the script has a chance to
examine and modify the message in the Connection Data DOM. For example, the script may add
additional SOAP headers.
4. The XFA application serializes the message in the Connection Data DOM to XML and constructs the
input message for the service.
5. The XFA application sends the input message to the server.
6. The server performs the operation.
7. The server sends a reply to the XFA application. The reply may include an output message.
8. If the operation has an output message, it contains data serialized as XML. The XFA application loads
the data from the received message into the Connection Data DOM, replacing the input message that
was there previously.
9. The
postExecute
event is triggered. If there is an associated script, it runs. While the script is
running
$event.soapFaultCode
and
$event.soapFaultString
are set to the received fault
code and fault string. These are contained in the
soap:faultcode
and
soap:faultstring
elements, respectively, inside the
soap:fault
element. If the operation succeeded, there is no
soap:fault
element and both event properties default to the empty string (“”). The script can detect
success by checking for an empty string in
$event.soapFaultCode
. The script can also inspect and
modify the received data in the Connection Data DOM before it is imported into the Form DOM. For
example, it may check for headers.
10. The XFA application imports the received data into the Form DOM. There are two ways the XFA
processor can carry out the importation. When the executeType property of the event object is set to
import, it simply updates the data that is bound to the output of the connection. This is simple and
efficient but it does not support dynamic subforms, which are inserted into the form where required
and/or as often as required by the data. For dynamic subforms the XFA processor clears the Form DOM
and rebuilds it using a merge (data binding) operation. This is done when the
executeType
property
of the event object is set to import.
Note:
The merge operation is modified when there is a connection active. As the XFA processor builds
the Form DOM, when it comes to a candidate field or exclusion group associated with the
current connection, it reaches into the Connection Data DOM and plucks the associated data (if
any) from there. If the field or exclusion group was already bound to data in the Data DOM, the
new data propagates through to the Data DOM, updating the node that is already there;
otherwise a new data node is created to hold the data.
11. The message in the Connection Data DOM is deleted.
Structure of a Web Service Message
A Web Service message uses the XFA data description grammar to describe its header and body (“Data
Description Specification” on page 746)
and references a Web connection defined in the XFA connection
set (“Connection
The data description for a web service is a special case. The data description must declare the schema for
the input message (from client to server). In addition it must declare the name of the web service
connection which will be referenced in connect elements in the template. This is done using the following
structure:
<dd:dataDescription