Method Call execution error and status codes|OPC UA Standard|Forum|OPC Foundation

Avatar
Search
Forum Scope


Match



Forum Options



Minimum search word length is 3 characters - maximum search word length is 84 characters
Lost password?
sp_Feed sp_PrintTopic sp_TopicIcon
Method Call execution error and status codes
Avatar
Sascha Zelzer
Member
Members
Forum Posts: 7
Member Since:
05/05/2015
sp_UserOfflineSmall Offline
1
09/23/2022 - 04:45
sp_Permalink sp_Print

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

Avatar
Randy Armstrong
Admin
Forum Posts: 1438
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
2
09/23/2022 - 13:42
sp_Permalink sp_Print

"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.

Avatar
Sascha Zelzer
Member
Members
Forum Posts: 7
Member Since:
05/05/2015
sp_UserOfflineSmall Offline
3
09/27/2022 - 07:44
sp_Permalink sp_Print

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.

Avatar
Randy Armstrong
Admin
Forum Posts: 1438
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
4
09/27/2022 - 08:45
sp_Permalink sp_Print

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.

Avatar
Sascha Zelzer
Member
Members
Forum Posts: 7
Member Since:
05/05/2015
sp_UserOfflineSmall Offline
5
09/28/2022 - 03:54
sp_Permalink sp_Print

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)?

Avatar
Randy Armstrong
Admin
Forum Posts: 1438
Member Since:
05/30/2017
sp_UserOfflineSmall Offline
6
09/28/2022 - 07:10
sp_Permalink sp_Print

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:

https://sites.google.com/opcfo.....ation/home

Forum Timezone: America/Phoenix
Most Users Ever Online: 510
Currently Online:
Guest(s) 25
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Forum Stats:
Groups: 2
Forums: 10
Topics: 1341
Posts: 4546