The status of the Servicecall is represented by the serviceResultcontained in the ResponseHeader(see 7.29). The mechanism for returning this parameter is specific to the communication technology used to convey the Serviceresponse and is defined in OPC 10000-6.
The status of individual operations in a request is represented by individual StatusCodes.
The following cases define the use of these parameters.
- A bad code is returned in serviceResultif the Serviceitself failed. In this case, a ServiceFaultis returned. The ServiceFaultis defined in 7.30.
- The good code is returned in serviceResultif the Servicefully or partially succeeded. In this case, other response parameters are returned. The Clientshall always check the response parameters, especially all StatusCodesassociated with each operation. These StatusCodesmay indicate bad or uncertain results for one or more operations requested in the Servicecall.
The Servicesdefine various specific StatusCodesand a Servershall use these specific StatusCodesas described in the Service. A Clientshould be able to handle these Servicespecific StatusCodes. In addition, a Clientshall expect other common StatusCodes defined in Table 177and Table 178. Additional details for Clienthandling of specific StatusCodesmay be defined in OPC 10000-7.
If the Serverdiscovers, through some out-of-band mechanism that the application or user credentials used to create a Sessionor SecureChannelhave been compromised, then the Servershould immediately terminate all sessions and channels that use those credentials. In this case, the Serviceresult code should be either Bad_IdentityTokenRejectedor Bad_CertificateUntrusted.
Message parsing can fail due to syntax errors or if data contained within the message exceeds ranges supported by the receiver. When this happens messages shall be rejected by the receiver. If the receiver is a Serverthen it shall return a ServiceFaultwith result code of Bad_DecodingErroror Bad_EncodingLimitsExceeded. If the receiver is the Clientthen the Communication Stackshould report these errors to the Clientapplication.
Many applications will place limits on the size of messages and/or data elements contained within these messages. For example, a Servermay reject requests containing string values longer than a certain length. These limits are typically set by administrators and apply to all connections between a Clientand a Server.
Clientsthat receive Bad_EncodingLimitsExceeded faults from the Serverwill likely have to reformulate their requests. The administrator may need to increase the limits for the Clientif it receives a response from the Serverwith this fault.
In some cases, parsing errors are fatal and it is not possible to return a fault. For example, the incoming message could exceed the buffer capacity of the receiver. In these cases, these errors may be treated as a communication fault which requires the SecureChannelto be re-established (see 5.5).
The Clientand Serverreduce the chances of a fatal error by exchanging their message size limits in the CreateSessionservice. This will allow either party to avoid sending a message that causes a communication fault. The Servershould return a Bad_ResponseTooLarge fault if a serialized response message exceeds the message size specified by the Client. Similarly, the Client Communication Stackshould report a Bad_RequestTooLargeerror to the application before sending a message that exceeds the Server’slimit.
Note that the message size limits only apply to the raw message body and do not include headers or the effect of applying any security. This means that a message body that is smaller than the specified maximum could still cause a fatal error.