- summary Component structure.
This adapter wraps codeserver information with RIV-TA compliant Web Services, and is designed to be deployed in the SLL regional service platform (RTjP).
There are four main modules:
* *codeserveradapter-core* - The core service layer (business logic) and information model layer * *codeserveradapter-schemas* - RIV-TA Web Service definitions (contracts) in this service domain. RIV-TA applies the specification first pattern, i.e. the Java code is generated from WSDL, and the service domain is expected to be packaged according to a common convention. * *codeserveradapter-mule-app* - The Mule (ZIP) application packaging (experimental) * *codeserveradapter-web-app* - The Web (WAR) application packaging (currently used)
The technology stack is based on
* Java 1.7 * Spring Framework 3.1 * Apache CXF 2.5
And for the Mule app packaging:
* soitoolkit 0.6 * Mule 3.3
Core uses an annotation driven approach, while the app component uses a more traditional spring (XML) based approach.
The code structure divides between generic codeserver stuff, such as parsing of files etc and stuff that are specific for the payment responsible service. This means that adding a new service based on codeserver information should be a pretty straight forward task, both when it comes to development and deploy/maintain.
Business logic belongs to the module and service interfaces are located in the package . This layer primarily is about to build an index to enable lookup of commissions and payment responsible. Payment responsible is a company and the codeserver id is mapped to either HSF or TioHundra, see configuration parameters and
Service implementations shall be annotated as .
Integration logic is maintained by the mule application and the mule flow handles fetching of files from the codeserver using FTP transport. The mule flow handles Web Service request response pattern for the service.
FTP transport is configured using the following properties:
The Web application integration also runs a FTP Job (calls a script) which is scheduled as a Spring task. The same configuration parameters as for the Mule app is used with just the addition of:
* {{{pr.script}}} The actual shell script to invoke to fetch FTP master data files
After parsing XML files the created HSA mapping index is saved to a local file specified by the configuration property . On restart the service always reads the latest locally saved index file, and uses this until a scheduled rebuild is carried out.
Web Services Java interfaces are generated from WSDL files using Apache CXF and maven. Implementations are located in the the invoice-data-app module and Java package . Almost the same implementation is in the the Mule and Web application packaging. Currently the deviation is due to configuration discrepancies and more specifically Spring annotation driven configuration doesn't work the same in a Mule app as in a plain Web app.
- Please note*: Web Service endpoints are specified using mule flow and the configuration parameter specifies the complete endpoint path.
The application returns SOAPFault on all technical server side errors. The only application error at this time is when a given HSA ID can't be found in the index, and then a normal response with response code in element set to NOTFOUND_ERROR is returned.
A JMX bean is used to instrument/monitor interfaces and perform health check operations. See package .
The JMX bean in question is named , and it's only activated in the Web application packaging.
At the time it's just about reading publicly available information, and therefore there's no need for any particular security mechanism.