Log In
Home
02/22/2022
Offline
Hi all
Within our nodeset we have defined some methods to add product specifications to a server. This specifications are built with structures. They contain
- multiple structures
- multiple EUInformation (e.g. lengths)
- References to other structs within the same method call
- Refereces to elements, that are existing already on the server (separate method call, e.g. raw material definition)
The server should be able to verify the data an return an appropriate status code. There are a lot of different status codes available (https://github.com/OPCFoundati…..usCode.csv), but I have no idea which I should use for
- unsupported engineering unit (e.g. given mm and the server allows only mil, or could not covert from mm to mil) -> BadInvalidArgument or BadNotSupported?
- errors within the given structures
- non-resolvable “internal” or “external” references -> BadInvalidArgument or BadStructureMissing?
- wrong referenced struct type (e.g. they are currently linked by string-IDs – there is no type-save reference [expected a “motor-struct”, but referenced to a “fruit-struct”])
- no unique attributes, if needed (a client could just define this by a string) -> BadInvalidArgument?
- wrong attribute values (e.g. negative values, diameter or cross-sections are both optional -> what if they don’t match)
-> BadInvalidArgument? - to many attributes – could they be ignored without any feedback to the clients -> BadTooManyArguments?
- to many structs (not needed) -> BadTooManyArguments?
- For case sensitive strings (e.g. ISA95 Job-Management -> material use) what should be reported if there is a missmatch?
So back to the questions:
- Are the above assumptions/mapping with the status codes correct, or what should it be?
- For a client with the above example it is not possible to identify what was wrong – are there better solutions or could we define specific status codes for this use cases?
I hope you can point me the right direction
Best regards
Patrick
05/30/2017
Offline
If you are developing your own methods you should provide output parameters that contain error information that is useful to clients. In this case the Method return code is always Good unless there was a failure that prevented the method from being called.
If your inputs are multiple complex structures then you want to have a list of errors returned that reports all problems with the inputs (i.e. like the output of a compiler). There is no need to use StatusCodes in these structures but you are free to use any built in code as long as your usage is consisted the with description of the StatusCode.
1 Guest(s)
Usage Policy