Error Handling Strategy

Size: px

Start display at page:

Download "Error Handling Strategy"

Meghan Day
6 years ago
Views:

1 DECC/ SEC Subsidiary Document Consultation Draft V1.0 Error Handling Strategy Author: Date: 9 th May 2014 Page 1 of 8 Public

2 DECC/ SEC Subsidiary Document Consultation Draft V1.0 Contents Error Handling Strategy General Provisions Definition of an error Error Handling and Retry Principles Retry Behaviours Retry Behaviours Error Handling and Retry Scenarios Availability Availability 8 Page 2 of 8 Public

3 DECC/ SEC Subsidiary Document Consultation Draft V1.0 Error Handling Strategy 1.1. General Provisions This document is the Error Handling Strategy subsidiary Document The Gateway Interface Specification is a separate Subsidiary Document that supports this Strategy Definition of an error An Error is an unexpected condition in the Total Systems specifically as a result of raising, executing or transmitting a Service Request, Service Response or alert. Errors apply to Gateway operation and onward transmission Error Handling and Retry Principles The approach to Error Handling and Retry within the Total Systems follows four main principles: a. Acknowledgement - where data is passed across an interface between two parties, there will be an acknowledgement to indicate that responsibility has passed from one party to another b. Retry - where an error has occurred the Total Systems shall reattempt to process / transfer the data a set number of times before failing c. Notification - in all cases where the Total System is called on by another party to perform a task, the Total Systems shall inform the caller of the final status of that task, whether it was successful or not d. Fulfilment Responsibilities - each interface specification shall clearly state whose responsibility it is to reprocess / resend data, and what the expected outcomes shall be 1.4. Retry Behaviours For retry and timeout behaviour the shall apply the following behaviours: a. components shall perform one or more retries within the Target Response Time Section H13.1 b. components can also carry out a further Retry beyond the Target Response Time Section H13.1 if this is likely to give an increased chance of success. However, this shall not stop an incident from being raised Page 3 of 8 Public

4 DECC/ SEC Subsidiary Document Consultation Draft V1.0 c. retry and timeout behaviour for components at a lower layer of the processing stack shall be within the duration of Retry and timeout behaviour of components at higher layers of the processing stack (i.e. a higher level component shall not time out before a lower layer has completed its Retry behaviour). Layers of the processing stack correspond to the different stages in the path of the message flow 1.5. Retry Behaviours The shall document and maintain business processes that align with the Error Handling Strategy Error Handling and Retry Scenarios Errors are caused by one of two failure scenarios within the Total System:- a) a failure to deliver a valid message to the device b) a failure to process an incomplete or invalid Service Request The shall ensure that the Response Code contained in the Service Request response message indicates the failure type The shall, where reasonably appropriate, notify the of all Errors that are encountered when processing a request that cannot be resolved by the retry strategy The approach detailed below shall be applicable to both Critical and non- Critical Service Requests. Further detail including exact error codes can be found in the Gateway Interface Spec [DUGIS] Error Scenario Classification Service unavailable Mode of Operation Transform, Only, Dated Approach The shall raise an incident in the Incident Management Log in accordance with the Incident Management Policy Section 1.2 The shall validate connectivity to the, if connectivity cannot be confirmed the shall follow their internal business process for confirmation of the next steps to be taken In the event that the can confirm connectivity to the the can Retry as defined in their business processes In the event that the error code is repeatedly returned by the the can raise an Incident with the having first checked for known issues via the Self-Service Page 4 of 8 Public

5 DECC/ SEC Subsidiary Document Consultation Draft V1.0 Error Scenario Classification Invalid request or Access Control failure Mode of Operation Transform, Only, Dated, Scheduled Approach Interface in accordance with the Incident Management Policy Section 1.2 The shall send the failure message with the error code to the The shall validate the Service Request, make the required amendments and re-submit it to the, if that is appropriate to their business process Only once the above has been completed, and the failure is still occurring, can the raise an Incident with the having first checked for known issues via the Self- Service Interface in accordance with the Incident Management Policy Section 1.2 Failure to send command over SMWAN Dated The shall Retry the message a minimum of once more If still failed after sixty seconds the shall return an Alert with the appropriate response code to the requesting If still failed after twenty four hours the shall return an alert with the appropriate response code to the requesting In the event that the response code is repeatedly returned by the the can raise an Incident with the having first checked for known issues via the Self-Service Interface in accordance with the Incident Management Policy Section 1.2 Failure to receive response over SMWAN Dated, DSP Scheduled, Meter Scheduled The shall retry at least once within initial retry period of 60 seconds If it is still failed after sixty seconds the shall return an Alert with the appropriate response code to the requesting If still failed after twenty four hours the shall return an alert with the appropriate response code to the Page 5 of 8 Public

6 DECC/ SEC Subsidiary Document Consultation Draft V1.0 Error Scenario Classification Mode of Operation Approach requesting In the event that the error code is returned by the the can raise an Incident with the having first checked for known issues via the Self-Service Interface in accordance with the Incident Management Policy Section 1.2 Unable to deliver response to Dated, DSP Scheduled, Meter Scheduled, Device Alerts, Alerts The shall Retry at regular intervals If still failed after 300 seconds the shall place the request on the failed queue for re-delivery once the connectivity is restored The shall hold failed responses for a minimum of 2 days for attempting a re-sending If the is unable to deliver data to the, then the shall notify the In the event that the fails to receive expected Service Responses / Alerts then the can raise an Incident with the having first checked for known issues via the Self-Service Interface in accordance with the Incident Management Policy Section 1.2 Failure to send Device Alert over SMWAN In the event that an alert has been successfully sent but not received due to SMWAN failure the shall undertake reasonable steps to buffer the alert and transmit when the SM WAN becomes available Page 6 of 8 Public

7 DECC/ SEC Subsidiary Document Consultation Draft V1.0 Error Scenario Classification No response received from Smart Metering Device Mode of Operation Future Dated, DSP Scheduled Approach If no response is received from the specified Smart Metering Device within 24 hours of the execution date and time contained within the original Service Request the shall return an alert to the with a Timeout response code On receiving the Timeout response code the shall review their business process and can raise an Incident in accordance with the Incident Management Policy Section 1.2 fails to receive response from at scheduled time Meter Scheduled The shall validate connectivity to the, if connectivity cannot be confirmed the shall follow their internal business process for confirmation of the next steps to be taken. Where business process directs the can raise an Incident in accordance with the Incident Management Policy Section 1.2 Incorrect response code received If the receive a response code that does not correlate to the Service Request type an Incident will be raised in accordance with the Incident Management Policy Section 1.2 If a receives a response code that does not correlate to the Service Request type they can raise an Incident with the having first checked for known issues via the Self-Service Interface in accordance with the Incident Management Policy Section Availability In the event that a has a known outage that could affect operations within this Strategy they shall notify the as soon as is reasonably practical Once service has been restored they shall inform the as soon as is reasonably practical. Page 7 of 8 Public

8 DECC/ SEC Subsidiary Document Consultation Draft V Availability In the event that the has a known outage that could affect the operations within this Strategy they shall, as soon as reasonably practical, notify s via the Self Service Interface or other appropriate mechanism Once service has been restored the shall, as soon as reasonably practical, update the notice on the Self Service Interface. Page 8 of 8 Public

Error Handling Strategy

Error Handling Strategy Author: DCC Operational Policy Draft Version 1 Date: 1 st May 2014 Page 1 of 13 Contents 1. Document History 3 1.1 Document Location 3 1.2 Review Dates 3 1.3 Revision History 3