Log In
Home
05/05/2015
Offline
Hi,
we are implementing UA method call suport in our UA server. I’d like to clarify the interpretation of the spec here regarding error handling and status codes.
For the StatusCode in the Call Service Response, the spec mentions:
This StatusCode is set to a bad StatusCode if the Method execution failed in the server, e.g. based on an exception.
We are trying to interpret what “Method execution” means, especially if this covers runtime errors when the Server executes a particular method call or not. If this doesn’t cover runtime errors, a bad status code would cover only input argument validation, permission checking, and communication errors. If the method actually executes on the server but experiences a runtime problem within the call timeout, is the status code supposed to be bad or good?
Thanks,
Sascha
05/30/2017
Offline
“Method execution failed” means there are no output arguments and nothing changed in the server.
If output arguments are returned or any changed occurred the return status must not be Bad.
05/05/2015
Offline
Thanks for the clarification.
From my understanding, the requirement “any change occurred then the return status must not be Bad” is impossible to meet except for the simplest methods.
A composed operation timing out with changes partially applied will automatically result in a Bad_Timeout status code, right? Otherwise, the spec would have to mandate some sort of transactions for method implementations.
05/30/2017
Offline
A timeout is a service level error and it means that the client cannot know if any operation completed.
The method return code is a operation level error and if the client receives it, it knows processing has completed.
If you can’t be certain that the state has not changed you can return uncertain codes.
The best practices whitepaper (draft available to members, to be released soon) recommends adding a status output argument for complex methods where detailed application specific error information would be helpful.
Bad means no output arguments and no change to the state of the server.
05/05/2015
Offline
Thanks.
Currently, for each call containing multiple methodsToCall entries, we process them in parallel and check if they individually time out. If one of the methods times out, we set its operation level error to Bad_Timeout because we would still want the other methods which completed successfully to return their output arguments. Is this flawed in the sense of UA best practices? If I understand you right, it is, because the Bad_Timeout operation level code does not guarantee that no change took place on the server.
The hint about using uncertain codes is good. Is there a recommendation / best practice how to handle the service level code if one of the operation codes is uncertain? Should the service level code then also be uncertain?
I found this document from 2020 regarding best practices. Is this the one you mentioned, or is there something else to be released (to members or the general public)?
05/30/2017
Offline
If the service level code is bad then no parameters are returned in the response.
service level codes are Good if not Bad (no Uncertain or Good variants).
You would want to return status argument with ‘timeout’ as possible value.
That makes it clear that it is timing out within the processing of the method rather than a network timeout.
The harmonization WG is working on an update. You can ask to join:
1 Guest(s)
Usage Policy