Error handling

During the integration process, the following types of errors can happen.

1. Business error
2. Availability or defects in the integrated systems
3. Error due to defect in the integration code or data setup of the integrator

When errors happen the integration code has two choices, whether to move to and process the next and the rest of the records or to stop the integration process completely.

Business error

These are error scenarios that are known at the time of writing integration code. These errors happen when the two integrated systems and the integrator are working as expected but the error can still happen due to users or known business scenarios. e.g. when a patient is being synchronized from Bahmni to Avni there are two subjects in avni with the same Sangam number (unique identifier).

Availability or defects in the integrated systems causing errors during integration

These are errors that the integrator doesn't have any way to recover from, as it is outside the scope of the integrator if even it itself is working as expected.

• one or both of the systems being integrated are not available due to network or other issues
• one or both of the integrated systems have software defects that cause the integration process to work not as expected

Error due to defect in the integration code or data setup of the integrator

self-evident

Error Handling

Business error
Integration code should be coded to capture all business errors and log them into the Error Records in the integrator database. The integrator should move to the next record and process it. Since the business error has happened specifically to one record (e.g. patient) the next record can be successfully processed. These errors should not be notified to bugsnag, as it is a known scenario that has been handled.

For other types of error, it is difficult to differentiate and tell whether the integrator can process the rest of the records successfully or not. These errors are where the system throws an exception (NPE, IO exception, SQL exception, etc). Just based on exception type usually it is very difficult to tell exactly what is the cause and take corrective action in the code. Hence for such exceptions, the integrator should simply abort that whole Integration process for all records and notify Bugsnag. Two things follow:

• The next run of the process will pick up from the same record and try to process again.
• The error is notified to Bugsnag. Again from there are two things that can follow:

1. The error is due to availability. If it is due to availability then uptime monitors for these services will also catch them. Hence in bugsnag, such errors should be marked as ignored so that next time they do not raise a trigger.
2. The error is due to some defect in any of the three systems. The error can be rectified and the bug can be marked as fixed in Bugsnag.

Error classification

Since the business error needs to be resolved by fixing the data. These errors can be browsed through the avni integration web application. The integration framework allows the developer to define their own error types and then log the errors against that - to assist in browsing the errors.

Error processing

A schedule or task in within the existing schedule can be defined to reprocess these errors. In the data has been corrected then the error corresponding to them will resolve itself.