LDK SEPA Toolkit and Framework

SEPA XML Processing A Toolkit Approach It’s a Framework and a Toolkit http://www.dijkstra-ict.com Lolke B. Dijkstra, Dijkstra ICT Consulting, 2009 http://www.dijkstra-ict.com

Challenges   Implementation Timelines   Budgetary Constraints   Staying in sink with new versions of the Standards   Meeting Quality Requirements   Managing Complexity

But..   Writing XML may be easy, Reading is an other ballgame..   Technology makes parsers complex to implement   High volume data/Very large XML documents (out of memory)!   Complex Data formats

SEPA challenge..   Need to be able to process (large amounts of) data accurately and reliably   This thing is huge…   New versions of standard will keep us busy…   Limited time-to-market

We want to..   Increase Quality of our software   Dependability   Maintainability   Be in time, on budget   Focus on Business Needs, not technology

We need..   Improve Quality and Dependability   Better Maintainability   Decreased time to market   Better Predictability

LDK SEPA Toolkit for Java   Helps your team focus on business needs instead of technicalities   Provides common foundation   Provides easy to use pluggable architecture. It’s a framework   Separates Processing from Reading   Fully encapsulates the Reading of XML data, without sacrificing flexibility   Your team implements the processing specific part of the Parser and connects it to the Reader Component

LDK SEPA Toolkit for Java   Cost Effective, you only pay for functionality you need   Dependable, flexible, highly efficient   High Quality Documentation   Highly Flexible   Comes with full source code, so no risk of vendor lock-in   POJO: plain old java objects, you don’t need anything except Java 1.5 or later, no exotic environmental requirements

Organization of the Toolkit

Under the hood.. architecture   The Reader Component is provided by the toolkit   Your team concentrates on the business logic and processing of the data in the Application Processor Component

Under the hood.. architecture Common Foundation Framework Payments Cash … JavaBeans Application Specific Processor

Under the hood.. coding

Under the hood.. logging   Exceptions due to validation errors are simply handled (for instance for logging purposes) by catching the SAXException error   Exceptions due to processing errors are handled by catching the ProcessorException error in the main

Mapping Model to Code ISO 20022 Generated Code

Processing Data

Configuration   Ease of configuration, changing processing and lifetime in memory per XML element at runtime without programming a single line   Using a configuration file per application to:   Enable/Disable processing for XML elements (defaults to disable)   Detaching XML elements from their parent element, making them short-lived (defaults to attaching items to parent)

Configuration – XML fragment Example XML for Pain.001.001.03 messages:

Configuration – Specifying options Example configuration for Pain.001.001.03 messages: Configuration just contains the instructions other than the default: process = false, detached = false

Configuration – Java code In your main just write:   Your application’s Reader Component will automatically configure itself with the specified options.   In the example it means we’d like to process GrpHdr, PmtInfo and CdtTrfTxInf.   And since there are potentially unlimited number of PmtInf and CdtTrfTxInf, we detach them, so we don’t keep them in memory once we’re done with them.

Quality, Compliancy, Flexibility..   “The standard is huge, how do you guarantee consistency of your code and how do you maintain your code?”   “We (Bank) do follow the standard, but there are exceptions..”   “Options for validation? What if..”

Model Driven Engineering!   The model (ISO 20022) drives our mapping and code..   So, you won’t have to learn a new API   We use an engine for generating code directly from the model and have now applied it to the SEPA domain   MDE is especially beneficial for large models, in fact the ISO 20022 set of standards is huge!   Finally, code and model are consistent and in sync…   Use different schemata for certain channels?   We can generate code from schemata!

Quality, Compliancy, Flexibility..   We wrote a common (small) framework in Java, which is extended by the generated code   The generated code is clean and not redundant, is heavily reuses the common framework   We maintain the code generator, and the framework not the generated Java code   Java reference documentation is generated and in sync with the code   We use automated unit tests

Quality, Compliancy, Flexibility..   What about validation?   “Want to reject XML message when validation fails”   “Just want to reject individual transaction when not valid but process the valid ones”   First case:   Pre-validation; the XML message is either valid or invalid   Process validated XML document   Second case:   Document is well-formed, but some information may be missing   Pre-validate with a relaxed XML Schema, specifying your minimum requirements (optional)   During processing decide what to do per transaction

Summary   Model and code are perfectly in sync. Guaranteed!   Your team focuses on the functionality of processing of data instead of dealing with the intricacies of the standard   Easy to use and highly flexible   Common foundation for all SEPA parsers, increasing maintainability, dependability and cost effectiveness   Increased productivity due to reuse of common reader components

More Information It’s a Framework and a Toolkit For more information navigate to: http://www.dijkstra-ict.com Dijkstra ICT Consulting Lolke B. Dijkstra Lolke B. Dijkstra, Dijkstra ICT Consulting, 2009 http://www.dijkstra-ict.com

LDK SEPA Toolkit and Framework

0 comments

Notes on slide 1

Favorites, Groups & Events