7. Error Handling and Logging

Error handling is part of the Directory, Authentication and Status methods. When a request is rejected for system-related or field-related reasons, an error message is sent in response to the occurrence of this error.

A generic error response message is sent as a reaction to:

• The Directory request;
• The Authentication request;
• The Status request.

For all messages received by the iDIN Software Library, a log will be created containing references to the DateTimestamp, and the actual message including any errors the message might contain.

The libraries provide extensive logging support for monitoring the messages between the Merchant and Routing Service. This will be optional and configurable from the application configuration file (see Section 4.2 – Library Settings, for more information about how you can configure the library to output these messages).

In addition to logging the response and request messages to disk, the libraries allow programmatic access to the messages, to be used in cases in which simply logging the message to disk doesn’t fulfill your requirements (e.g. running in a cluster, saving the messages in a database, sending a notification when an error message is received, etc.). This can be achieved using any of the following approaches:

• The original XML response messages are accessible directly from the response objects for the directory request, new authentication request and status request. This approach enables developers to associate a response with its XML representation, but it is only available for responses, and only for the responses with no parsing errors. For more details on how to access the XML messages for each response, see Chapter 0;
• The internal logging code uses a pluggable architecture, allowing developers to plug in their own logging code and handle the messages however they see fit. This is the more powerful approach, allowing Merchants to save all messages (both request and response), even if parsing errors occur. The messages will not be associated with their object representation however, so if this is needed then the first approach should be used. For more information on how to plug your own logging code, see the platform-specific sections below.

Additionally, apart from logging the request and response, the libraries will also log diagnostic information, enabling you to investigate potential configuration issues. Instructions for how to enable the logging of diagnostic information for each platform are included below.

7.1 .NET Core Logging

The following steps should be followed to plug in your own logging code:

• Implement interface ILogger, specifically the Log and LogXmlMessage methods. The Log method will be called by the library for logging trace/diagnostic messages, such as when a signature is being computed, the result of a message validation checks, etc. The _LogXmlMessage will be called by the library when logging a request/response message, and will receive the entire XML message as an argument. This method can be uses to save the messages wherever you see fit;
• Create a configuration class that implements BankID.Merchant.Library.IConfiguration and attach your own ILogger implementation to the class.

For logging diagnostics, the library is using the standard Trace class, and in order to enable the saving of these messages to disk they have to be configured to output for standard .NET trace diagnostics. For more information on how to do this, see this MSDN article - https://msdn.microsoft.com/en-us/library/xe8whywc(v=vs.110).aspx .

Additionally, the library will itself throw errors whenever it detects invalid input data. In order to handle these errors, you should catch the library-specific exception, CommunicatorException.