0004156: Error handling of Method calls - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0004156	10000-003: Address Space	Spec	public	2018-02-11 12:46	2020-08-04 15:14

Reporter	Wolfgang Mahnke	Assigned To	Jeff Harding
Priority	normal	Severity	major	Reproducibility	always
Status	closed	Resolution	no change required

Summary	0004156: Error handling of Method calls
Description	I am not really sure to which part this belongs to. Issue: In the services a method call can only return StatusCodes defined by the OPC UA specification. This is often not enough and more detailed status for the specific method is desired. An often-used pattern is therefore to return a StatusCode as out parameter of the method (e.g. in FDI). What I did not found anywhere I looked was the handling of such methods in the service call. Do we need to return a Good StatusCode on the services and then a user-defined method StatusCode that could indicate that the method failed? Can I even access the out parameters when the method returns a BAD status code on the service and expect anything useful in them? From my point of view it is desirable to define in the base specs (therefore I had chosen Part 3) at least a pattern that should be used to return Method-specific status codes and what is the expected behavior for on the service level. For this case it would also be good if the out variable can be an “extendable enum”, meaning not a specific Enum DataType (which cannot be extended) but something having EnumStrings or EnumValues so that standard information models can define some base status but vendors can extend that. As I understood proving such a feature is already in discussion anyhow.
Tags	No tags attached.

Commit Version
Fix Due Date

jpfr 2018-02-15 11:02 reporter ~0008880	What about the operation level result codes (e.g. Bad_NotExecutable)? How would they be returned if the return code is a custom enum? How would the nature of the result code be communicated to a client? In total, adding an additional return argument with a custom enum seems a lot cleaner. At any rate, the signature of the call service (in terms of the request and response message) should be kept stable. Otherwise, all compatibility with existing OPC UA implementations (and deployments) is lost.

Jeff Harding 2018-12-18 18:44 developer ~0009732	This issue was discussed during the December 18th 2018 UA call. We concluded the following: Clone this issue and assign it to Part 4. This cloned issue will address the specifics the behavior of Method calls with respect to StatusCodes and returning output arguments. This issue will be redefined as a feature request to address the more general issue of how companion specification and application specific StatusCode information should be handled.

Wolfgang Mahnke 2019-02-26 14:50 developer ~0009949	I just checked something for FDI, and found this mantis issue (0002501). We decided a long time ago that companion specifications can actually define StatusCodes and add them to the CSV file with OPC UA defined StatusCodes (I was not aware about that anymore). This made sense for special cases in FDI since they needed those StatusCodes on values, I do not think that we would be able to mange StatusCodes resonable for Method handling comming from all the companion specifications - since this would be a lot of StatusCodes and the CSV would increase dramatically.

Jim Luth 2019-09-10 15:38 administrator ~0010948	Agreed to "no fix" in meeting. Methods can define custom "out" parameter as an error code. All other cases of new codes should proposed to the UA w.g. to be added to the standard CSV as was done for FDI.

Jim Luth 2020-08-04 15:14 administrator ~0012654	Agreed to no-fix in telecon.

Date Modified	Username	Field	Change
2018-02-11 12:46	Wolfgang Mahnke	New Issue
2018-02-12 13:58	Wolfgang Mahnke	Relationship added	related to 0004157
2018-02-15 11:02	jpfr	Note Added: 0008880
2018-04-24 16:45	Jim Luth	Assigned To	=> Jeff Harding
2018-04-24 16:45	Jim Luth	Status	new => assigned
2018-12-18 18:06	Jeff Harding	Issue cloned: 0004542
2018-12-18 18:44	Jeff Harding	Note Added: 0009732
2018-12-18 18:45	Jeff Harding	Relationship added	related to 0004542
2018-12-18 18:47	Jeff Harding	Status	assigned => acknowledged
2019-02-26 14:50	Wolfgang Mahnke	Note Added: 0009949
2019-09-10 15:38	Jim Luth	Note Added: 0010948
2019-12-12 00:03	Jeff Harding	Status	acknowledged => resolved
2019-12-12 00:03	Jeff Harding	Resolution	open => no change required
2020-08-04 15:14	Jim Luth	Status	resolved => closed
2020-08-04 15:14	Jim Luth	Note Added: 0012654