(DRAFT - 7/15/2002 - DW)
Background
Corporate Financial data is currently transferred from the campuses to UCOP on a monthly cycle. The file formats and procedures are well-defined on IR&C's web site at http://www.ucop.edu/irc/systems/cfs.html. In brief, there are two types of files, ledger balance files and capital asset files. The campuses transfer these files using FTP to a campus-specific location on UCOP's UCCMVSB system. After a file is FTP'd, an electronic mail message is sent to the IS&C Librarian with information about the transferred file, including the campus ID, contact information, the number of records in the file, the cycle date, and the creation date. This information is verified by IS&C staff before the file is processed.
This document is a proposal to re-implement this process as a pilot for the use of XML in file transfers of this type.
General Principles
Use clear and extensible file format definitions.
Automate processes where appropriate.
Maintain the spirit of controls, even if we change their implementation.
Minimize initial change in external interfaces, but enable future change.
Use digital certificates for authentication.
Ensure that schemas, program code, etc. are readable by humans.
Proposed Implementation
It is proposed that the current pairing of FTP and electronic mail be replaced by the implementation of a Web Service that performs the following functions:
Transfer the Corporate Financial information to UCOP along with the campus ID, contact information, the number of records in the file, the cycle date, and the creation date.
Verify overall consistency of the file with its proscribed XML schema, as well as the number of records and the cycle date. Notify the campus user immediately of any inconsistency.
Assuming no inconsistency, initiate processing of the file.
Initially, client and server Java programs will be developed to accomplish these tasks. In order to minimize changes for other software, the Java programs will translate to and from the current "flat" file format so that neither the campuses nor OP need to modify existing software initially; the Java programs simply replace FTP. Because of the well-defined Web Services interface, however, the functions of these standalone programs can be integrated into existing software at some time in the future. In order to enable authentication and encryption, the Web Service will be defined to use the HTTPS (SSL) protocol, and the server will be configured to verify that the campus's digital certificate is one that is authorized for use of this service.
Deliverables
An XML Schema defining the transfer file format.
A WSDL description of the Web Service.
A client program that reads an old "flat" file and transmits it to the server program. If errors occur, it will report them to the user.
A server program that is invoked by the client program to receive the new XML-formatted file. It will check for consistency, reporting appropriately to the client program, and write an old "flat" file to disk when there are no inconsistencies in the transferred data.
A collection of Java Beans that provide methods for accessing and manipulating the new file format, as well as implementing the Web Services interfaces. The beans can be reused at a later date for tighter integration with existing software.