Did you set the response on webservice side? if so, can be get the same on the form.
Webservice takes the request and process it then send response.
From form side we can able to set request and get response using the bindings.
Webservice response can be set to multiple elements, So can send as many details you want(success or faults or exceptions).
Based on the response you can display messages on the form using the reponse details. If webservice failed to give any type of response form cannot do anything, so all posiible things showld be done on webservice to get the proper response. Also If this is using LiveCycle process, other failure reasons (system, configuration, invocation exceptions etc) can be captured and routed on LiveCycle processes to address the same using the "Invoke Web Service" fault routes.
thanks for the response, however
1 I cannot change the response of the webservice to include a "status". it is a third party webservice
2 the webservice is a customer search. it throws a fault or error exception (whatever terminology you like) if there is no customer found or there is a database error.
3 the operation in the wsdl is defined as
<wsdl:input message="tns:searchRequestMsg" name="searchRequest"/>
<wsdl:output message="tns:searchResponseMsg" name="searchResponse"/>
<wsdl:fault message="tns:search_faultMsg" name="fault"/>
the dataconnection does not show the fault. those this mean LifeCycle form will not allow me to correctly bind to this webservice? Are there any workarounds?
In the form without data binding we do not have an option to capture anything.
If this this is using a "LiveCycle Process", it can be done. we can have access for the whole returned xml from wsdl response, so it can be parsed and read/update details to form specific and input the modified xml to form. This requires LiveCycle workbench and may be some more modules to perform these operations.
there are two sides to handling faults on Form's making SOAP calls.
1) On the form side... make sure you 'try catching' the dataconnnection execute - iterate through the properties of the Exception.
2) On the server side ... assuming LiveCycle Workbench is used.
- Create various outputs parameters as required. (eg: searchResponseMsg, search_faultMsg... or whatever your process requires)
- Ensure you handle all exceptions in the process so that a controlled message can be given back to the form (ie: the little lighting bolts on each service need to be catered for).