Connecting enterprise applications
How DNA Solutions replaced manual transfers between two enterprise applications with an exchange that is automated, checked and traceable.
EAIApplication integration
01The situation
A company relied on two business applications that had to hold the same records. Nothing connected them. People copied records from one application to the other by hand.
Every copy had to be checked by hand. Mistakes were easy to make and hard to trace, and no reliable history showed what had been transferred and when.
Before
- Records copied by hand
- Checks done by hand
- No history of transfers
After
- Records exchanged automatically
- Business rules checked before delivery
- A history of every exchange
02What the company needed
- Records move between the two applications without manual copying.
- A record that breaks a business rule never reaches the target application.
- Every exchange can be traced afterwards: what was sent, when, and with what result.
- One faulty record does not hold back the others or force a full transfer to be repeated.
- Further business flows can be added later by reusing what already exists.
03How the exchange works
The integration handles each exchange in a fixed sequence. Records that pass every check follow the main path. A record that fails a check follows a separate path until it is corrected.
- Collect
The integration collects the records to exchange from the source application.
- Convert
Each record is translated into the structure the target application expects.
- Check
Business rules are checked before anything is delivered. Each rule has a clear failure message.
- Deliver
Records that pass every check are delivered to the target application.
- If a check fails
- Set aside
The record is held with the reason for the failure. The rest of the exchange continues.
- Correct and send again
Once the cause is corrected, only that record is sent again and checked like any other.
- For every exchange
- Record the exchange
Each exchange is written to a history: what was sent, when, and with what result.
04What happens to a failed record
A record that fails a check is not lost and does not block the exchange. It keeps the reason for the failure, so that the cause is clear. After correction it goes through the same checks again, and its history shows every step.
Example: the history of a failed record
- Received
Picked up from the source application.
- Converted
Translated into the structure of the target application.
- Check failed
A business rule is not met. The reason is recorded with the record.
- Set aside
Held until corrected. The rest of the exchange continues.
- Corrected
Fixed where the error lies.
- Checked
Goes through the same checks again.
- Delivered
Written to the target application, with every step in its history.
05Design decisions
Errors handled record by record
A single faulty record no longer delays the rest of the exchange, and nobody restarts a complete transfer to correct one line.
Rules kept apart from the connection
Mapping and validation rules sit in their own layer. When a business rule changes, the rule is updated and the connection stays as it is.
History designed in from the start
The exchange history is part of the design. Questions about a given record are answered from the history instead of being reconstructed by hand.
Room for more flows
Collection, delivery and history are shared. A new business flow adds its own mapping and validation rules and reuses the rest.
06How we run an integration project
Map the records
List the records to exchange and agree, with the people responsible for the data, how each field translates from one application to the other.
- Record inventory
- Mapping rules
Write the checks
Turn each business rule into an explicit check, with a message that explains a failure in business terms.
- Validation rules
- Failure messages
Build the integration
Build collection, conversion, checks, delivery and history as separate parts, so that each one can be tested and changed on its own.
- Integration
- Exchange history
Test with realistic cases
Cover valid records, broken rules and corrected records sent again, before the integration replaces any manual step.
- Test scenarios
Replace the manual copy
Move the exchange to the integration, with a history of every exchange from the first run.
- Automated exchange
07Results
Records copied by hand between the applications
Records exchanged automatically
Checks done by hand after each copy
Business rules checked before delivery
No reliable history of transfers
A history of every exchange
Manual effort on every transfer
Transfers without manual effort
08When this approach fits
A good fit when
- The same records have to exist in more than one application.
- Transfers are frequent and repetitive.
- Errors are costly when they are found after the fact.
- More flows are likely to follow the first one.
Probably not needed when
- A one-off data migration: a migration plan is a better fit.
- Records that rarely change: a documented manual procedure may be enough.
Questions to ask before a similar project
What we clarify with a company before connecting two applications.
Do the applications have to be modified?
Usually not. The integration sits between them and uses the ways each application already offers to read and write records. If a change is unavoidable, it is agreed with the owner of that application before any development starts.
Who owns the business rules?
The people responsible for the data. We write the rules down with them and turn each one into a check with a clear failure message, so that the reason for a failure is clear.
Can more flows be added later?
Yes. A new flow brings its own mapping and validation rules and reuses the collection, delivery and exchange history that already exist.
How is a failed record handled?
It is set aside with the reason for the failure while the rest of the exchange continues. Once corrected, only that record is sent again and goes through the same checks as any other.
Why is this case study anonymised?
We do not publish client names, sectors, systems, volumes or dates for work of this kind. Details about a company’s systems can help attackers, so they stay out of anything public. We describe the method and the result instead.