Hello everyone,
I've implemented a WSDL connection with a postExecute event handling the SOAP fault messages (has described in the XFA specification). The form needs to handle the following scenarios;
1. Successful operation: WSDL doesn't return soap fault code.
2. Failed operation (WSDL returns soap fault code).
3. Connection timeout (? - simulated by setting a breakpoint in WSDL).
4. Failed to connect to WSDL (? - simulated by stopping WSDL service).
First two scenarios are properly handled however I'm having a harder time with the last two. Initial testing showed Reader actually handled these scenarios by displaying an error message however the postExecute event doesn't fire which makes sense. I implemented this solution in another form and can't get Reader to generate the warnings anymore. Note the first two scenarios work fine in the new form. I notice one time Reader wrote the warning in the JavaScript debugger. Not sure why since the debugger is always enabled. Why would it write to it this time and not previous times?
Questions
1. Is there anything that can affect this type of messaging? Reader preferences?
2. Is there a better/safer/consistent way of handling timeouts/failed connection other than relying on Reader?
Form built in Designer ES2, target version 8.1
Reader 8.4
Reader Extensions ES2
Thanks much!
Hélène
Solved! Go to Solution.
Views
Replies
Total Likes
The examples that I have seen use a try catch block and if the catch gets fired then there is an issue. It returns a number (14) but no description so you could test for the e.number == 14 and write your own message. Other than that I do not know of a way (unless you use the Acrobat Soap object method).
Hope that helps
Paul
Views
Replies
Total Likes
Good morning,
Further testing showed that clicking the button, generated by the WSDL connection, Reader displays a dialog box with warning when the connection failed (good). The behaviors changes when I use script to execute the click event of the WSDL generated button. In this case, Reader writes the warning in the JavaScript debugger console instead (not good).
I also tried changing my script to execute the connection using script e.g. xfa.connectionSet.DataConnection.execute(0); . Makes no difference. Reader still write to the console.
The reason why I'm not using the WSDL generated button directly is because I need to verify the form has changed before connecting to the WSDL. The WSDL is responsible to saving the form's data. Maybe I should move this script on the preExecute event? I'll give it a try.
Hélène
Views
Replies
Total Likes
Forgot the xfa.event.cancelAction is not supported in xfa 2.6 so can't move the script to the preExecute event.
Ah well, if anyone has any idea why Reader writes to the console instead of displaying a dialog and/or if there is any way to work around it please let me know, that would be great.
Thanks again.
Hélène
Views
Replies
Total Likes
Are you executing your code in a try/catch block?
Paul
Views
Replies
Total Likes
Hi Paul,
It's good to hear from you. No it's not executing in a try catch. Let me try that and I'll get back to you.
Hélène
Views
Replies
Total Likes
The examples that I have seen use a try catch block and if the catch gets fired then there is an issue. It returns a number (14) but no description so you could test for the e.number == 14 and write your own message. Other than that I do not know of a way (unless you use the Acrobat Soap object method).
Hope that helps
Paul
Views
Replies
Total Likes
Beautiful! That's exactly what I am looking for and more. It allows the form to customize the error message instead of displaying Reader's default message.
Thanks again for your help Paul, I appreciate it.
Have a good one.
Hélène
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies