By StuRamage on Apr 18, 2011
Traditionally we have approached the development of payment interfaces as a separate design element for each project that I have worked on, due to the differing nature of the various agencies used by each client, and the various permutations of requirements in relation to validation on each.
Recently however we started looking at a better way of doing this, with the intent of delivering a single interface that can be all things to all installations, and thanks to the work of our design team (specifically DL, thanks for all the effort expended in relation to this interface), we believe that we now have a re-usable interface that can easily be extended to cater for processing of payments from a variety of agencies, in a variety of formats.
The historic approach was always similar to:
This meant that any changes required as a result of the introduction of additional business validation rules had to be applied to numerous code modules to ensure a consistent approach to each interface file. It also meant that the introduction of new payment agencies required further development of new modules specific to these new file formats.
Our new approach is:
Develop a common routine which accepts an XML interface definition file as an input, along with an associated payment file. This XML file is defined once, and contains the definition of the input files received from this agency.
This file contains:
- An indicator of whether the file is Column-Delimited, Comma-Delimited or XML
- Whether a Header record exists, and associated identifiers (e.g. Record type)
- Field mapping for this Header record
- Validation requirements in connection with this Header record
- Whether a Footer record exists, and associated identifiers (e.g. Record type)
- Field mapping for this Footer record
- Validation requirements in connection with this Footer record
- Detail record identifiers (e.g. Record Type)
- Field mapping for detail records
This logic is then applied to the incoming payment files at run-time, and the resulting records are validated and loaded into the Payment Upload Staging Table for processing by the base product PUPL batch process. The new process takes the form of:
This has the advantage of allowing clients to extend the number of payment agencies that they are able to interface to via CC&B with minimal additional configuration (i.e. the documentation of the interface specification in the associated XSD file, and the definition of a new Batch Control in CC&B, to utilise this XSD), with no additional coding requirements. It also ensures that a single code-mass is responsible for processing these records resulting in reduction of code duplication and easier maintenance in the event that business rule changes are required.
A Sample interface XML definition is available here
The Design document associated with this interface is available in pdf format here