Download System Design Specification

System Design
Specification
Fin088
Era Decommissioning Project
Version: 1.0
Date: 13th May 2013
Template Revised April 2013
System Design Specification for FIN088
Version: 1.0
Contents
1
1.1
1.2
DOCUMENT MANAGEMENT .................................................................. 2
Contributors ..................................................................................................... 2
Version Control ................................................................................................ 2
2
OVERVIEW .............................................................................................. 3
3
DEVELOPMENT TOOLS AND STANDARDS ......................................... 4
3.1
3.2
Development Tools ........................................................................................... 4
Development Standards................................................................................... 4
4
SYSTEM PROCESSES ............................................................................ 5
5
USER INTERFACE ................................................................................ 13
5.1
5.2
5.3
6
6.1
6.2
6.3
Transactional Interface ................................................................................. 13
MyEd Interface .............................................................................................. 13
Reporting Interface ........................................................................................ 13
APPLICATION SECURITY .................................................................... 14
Authentication ................................................................................................ 14
Authorisation .................................................................................................. 14
Business Objects ............................................................................................. 14
7
DATABASE DESIGN ............................................................................. 15
8
APPLICATION INTERFACES ................................................................ 16
9
DATA ...................................................................................................... 17
9.1
Data Migration ............................................................................................... 17
9.2
Archiving Policy ............................................................................................. 17
10
IMPLEMENTATION ............................................................................ 18
Page 1of 18
System Design Specification for FIN088
Version: 1.0
1 Document Management
When completing this document, please mark any section that is not required as ‘N/A’. A brief
description of why the section is not required should also be included.
1.1 Contributors
Please provide details of all contributors to this document.
Role
Systems Analyst
Designer
(Owner)
Business
Analyst
Project Manager
Project Sponsor
Business Area
Manager
Other document
contributors
Unit
IS Apps Software
Development
Name
Martin Jones
Project Services
Louise Heathcote
1.2 Version Control
Please document all changes made to this document since initial distribution.
Date
13/5/13
Version
1.0
Author
MJ
Section
All
Amendment
Initial Darft
Page 2of 18
System Design Specification for FIN088
Version: 1.0
2 OVERVIEW
The aim of this project is to migrate all existing web applications using the
WorldPay/ERA payment service to use the WPM card payment gateway service.
A generic service will need to be created to handle server-server call backs from
WPM during the payment process. This service should be able to update the relevant
applications of the result of any online payments.
As WPM provides a reporting interface of its own, called the WPM card payment
gateway extranet, the ERA admin interface should no longer be required. To decouple
each application from the current ERA application and database, each application
should store transaction details within its own schema.
Page 3of 18
System Design Specification for FIN088
Version: 1.0
3 DEVELOPMENT TOOLS AND STANDARDS
3.1 Development Tools
Specify which technologies will be used to develop the application, eg Oracle 9i, Cold Fusion MX,
Oracle Forms, Business Objects, Java, PL/SQL etc.
The three web applications will be modified using
 ColdFusion 9
 Oracle 11g

Changes to pCounter interfaces will also need to comply with any MyEd proxy
requirements.
3.2 Development Standards
Tick the appropriate box to indicate the standards being followed for this application:
√ indicates compliance
√
√
Standard
Database Design
Cold Fusion
Java
Uportal Development
Accessibility
Web Style Standards
Supported Web Browsers
√
√
√
√
Page 4of 18
System Design Specification for FIN088
Version: 1.0
4 SYSTEM PROCESSES
Take each process specified in the Business Requirements Document (BRD) and state how it will be
implemented technically (please make reference to the corresponding paragraph number in the BRD).
Where applicable, a specification of each screen which makes up a process should be provided (ie a
screenshot and descriptions of every data item displayed).
All paragraphs should be numbered to assist cross referencing in testing stages.
4.1 Application Components
4.1.1 Create a generic WPM callback service
The server to server callbacks from WPM do not seem to have any authentication
model provided. A user could read the outgoing form post and easily use the details to
post payment confirmation to the callback url specified in the XML packet inside that
form, bypassing the entire payment process with WPM altogether. After consultation
within IS Apps, it has been decided to create a separate, firewalled and IP restricted
(to WPM’s IP range) service to handle callbacks from WPM.
The WPM call back services should have:
1. Its own secure url’s:
www-dev.wpmservice.finance.ed.ac.uk
www-test.wpmservice.finance.ed.ac.uk and
www.wpmservice.finance.ed.ac.uk
and should also be:
- ssl encrypted
- IP restricted to WPM’s IP range of 213.206.140.0/22 & 82.195.160.0/22
- Not EASE/Cosign protected
*nb: All this information is more for the TAD. I am only including here for
reference until the TAD is created
2. A modular ColdFusion 9 application, within the Finance instance, which
should be lightweight, quick to respond and should not require any persistent
storage of its own (ie session, database).
It will receive a server-server XML post from WPM and should respond with
an XML packet confirming or refusing the transaction.
There should be a generic ColdFusion component, or “base class”, that should
provide common functionality needed for any application wishing to use the
service. This functionality should include being able to read and translate
incoming XML data and have the ability to create an XML response.
3. Each WPM “pathway” (calling Application) should have its own ColdFusion
component that extends the “base class” above and contain more specific logic
to update the database(s) and applications appropriate to that pathway. These
should be outlined in more detail in the Application specific notes that follow
in this section (ie 4.1.2/3/4)
Code: A new directory in the IS Apps Subversion (SVN) repository should be created
to keep a copy of the code.
Page 5of 18
System Design Specification for FIN088
Version: 1.0
Database: There is no requirement for the WPM callback service to store
transactions; therefore this does not require a database of its own.
Interfaces: Not required. This is a web service only.
BRD references: All – a callback service is required to replace all existing WorldPay
call back pages.
Documentation: As the callback service will be a separate application it will require
its own TAD and reference page on the IS Apps InSite Wiki.
Page 6of 18
System Design Specification for FIN088
Version: 1.0
4.1.2 Migrate pCounter to WPM.
The callback service needs to update the pCounter database with the success/failure of
the transaction and also update the PCTEPay (print credit e-payment) printing
application via another web service call.
Code
As per the BRD section 3.3.10 and the Finance documentation at
https://www.wiki.ed.ac.uk/display/Finance/Card+Payment+Gateway++Developer+Information
The XML being sent to WPM should contain:
 Finance Cost Centre
 Finance Account Code
 Finance Job Code
These are written out in custom fields for each item being paid.
Finding the above codes:
pCounter currently uses hard coded values for the productID and productItemID’s for
use with the ERA tables – these values are different for dev, test and live.
The era_product_items table has columns for cost_centre, account_code and
job_activity_code so querying live should return the values needed.
These should be:
<customfield1>869064</customfield1>
<!-- Cost Centre -->
<customfield2>1532</customfield2>
<!-- Account Code -->
<customfield3>
T8L100</customfield3>
<!-- Job Code -->
The reliance on CCDS for user details should be removed and replaced with a Central
Auth LDAP lookup. Please see the code in svn from studebt:
https://svn.ecdf.ed.ac.uk/repo/is/apps/software/studebt/trunk/src/system/model/busine
ssObjects/centralAuth.cfc as a guide.
Codebase repository moved from VSS to IS Apps Subversion (SVN).
The htdocs/pcounter/index.cfm file should include a new file to send the customer to
WPM instead of WorldPay.
The htdocs/transfers directory should contain a new folder called WPM to handle
cancelled transactions from WPM. This has to be handled within the application as
the WPM callback service will be restricted to WPM’s IP range only and the
cancellation link is a static link used by the user.
Create pCounter specific modules for WPM callback service (4.1.1 above) to use
pcounter specific updates – to generate success/failure emails.
Database
Transactional information (cardholder, cardtype) will now be available through the
WPM extranet. As there is no requirement in the BRD to capture this information
locally pCounter can be decouple from the ERA database. The PCTRANS_ID column
currently is a reference to the ERA transaction ID and cannot be null. So there is a
Page 7of 18
System Design Specification for FIN088
Version: 1.0
clear changeover from previous data, the new records should use the
pctepay_trans_seq.nextval prefixed with ‘PC’. The PC identifier also being that used
to identify the pathway in WPM.
Interfaces
No change
Security
No change.
BRD references:
Section 3, Item 3.
Documentation:
Changes to the application should be documented on the IS Apps Insite wiki.
https://www.wiki.ed.ac.uk/display/insite/Online+Print+Credit+%28OPC%29++PCounter
Page 8of 18
System Design Specification for FIN088
Version: 1.0
4.1.3 Migrate Ollbook to WPM
Code
As per the BRD section 3.3.10 and the Finance documentation at
https://www.wiki.ed.ac.uk/display/Finance/Card+Payment+Gateway++Developer+Information
The XML being sent to WPM should contain:
 Finance Cost Centre
 Finance Account Code
 Finance Job Code
These are written out in custom fields for each item being paid.
Finding the above codes:
Ollie currently uses hard coded values for the productID and productItemID’s for use
with the ERA tables – these values are different for dev, test and live.
The era_product_items table has columns for cost_centre, account_code and
job_activity_code so querying live should return the values needed.
These should be:
<customfield1>554OST </customfield1>
<customfield2>1260</customfield2>
<customfield3>
<!-- Cost Centre -->
<!-- Account Code -->
B00001</customfield3>
<!-- Job Code -->
The checkout pages are referenced from the root index.cfm file. See the switch
statements starting at line 310. New files should be created and referenced from this
location to handle the XML creation and transfer to WPM.
A cancel function should also be created to handle that process.
See files:
_dsp_checkout_bookingconfirmation
_dsp_checkout_wp_return
act_process_payment
_act_email_student_booking_confirmation
_act_email_special_study_requirements
_act_email_office_booking_confirmation
Create OLLBook specific module within the WPM callback service specified in
section 4.1.1 above. This module should update the OLLBook database and generate
any necessary notification emails.
Database
OLL should be decoupled from ERA database as transaction information will now be
available through the WPM extranet.
Interfaces
User should not notice any significant change within the OLLbook application.
BRD references:
Section 3, item 1.
Page 9of 18
System Design Specification for FIN088
Version: 1.0
Documentation:
Changes to the application should be documented on the IS Apps Insite wiki.
https://www.wiki.ed.ac.uk/display/insite/OLLBOOK
Page 10of 18
System Design Specification for FIN088
Version: 1.0
4.1.4 Amend ‘studebt’ Finance channel to use new callback
service
The (formerly Student) Finance Channel should already be using the WPM card
payment gateway service. It needs to be converted to use the newly created callback
service from section 4.1.1 above.
Code:
Create a studebt specific module within the WPM callback service specified in section
4.1.1 above. This module should update the ERA database and generate any necessary
notification emails as is currently done.
Update the WPM callback url’s in the mach-ii config xml files.
Database
Due to budget and time constraints, this application will need to continue to use the
ERA database. The ERA database should therefore be upgraded and moved to the
(FIN<environment>) Finance instance in Oracle.
Interfaces
No changes.
BRD references:
Section 3, item 2.
Documentation:
Changes to the application should be documented on the IS Apps Insite wiki.
https://www.wiki.ed.ac.uk/display/insite/Student+Finance+Channel
Page 11of 18
System Design Specification for FIN088
Version: 1.0
4.1.5 Remove redundant interfaces from MyEd
Code
There are two MyEd iChannels (launcher channels) called
 ERA Administration &
 Payments to the University
Both need to be removed from MyEd and VSS.
Database
n/a
Interfaces
Delete old launcher channels.
BRD references: Section 3.1 Non-Functional Requirements.
Documentation:
There does not appear to be any documentation to delete about these iChannels.
Please investigate to make sure.
Page 12of 18
System Design Specification for FIN088
Version: 1.0
4.2 USER INTERFACE
4.3 Transactional Interface
The key difference between the (old) WorldPay and (new) WPM payment service is
that the user is not involved in the callback. The [Finish] transaction button that takes
the user back to the web application is little more than a styled link.
4.4 MyEd Interface
No change apart from the removal of the two launcher channels specified in section
4.1.5
4.5 Reporting Interface
The reporting interface provided by ERA is to be replaced by the WPM card payment
gateway extranet.
https://www.wiki.ed.ac.uk/display/Finance/Card+Payment+Gateway+-+Extranet
Page 13of 18
System Design Specification for FIN088
Version: 1.0
APPLICATION SECURITY
This section relates to application rather than physical security which is covered in the Technical
Architecture Document (TAD).
4.6 Authentication
n/a. use existing methods
4.7 Authorisation
Include application, menu and page authorisation and any application roles.
n/a. use existing methods
4.8 Business Objects
Include any specific object/row authorisation.
n/a. use existing
Page 14of 18
System Design Specification for FIN088
Version: 1.0
5 DATABASE DESIGN
As outlined in 4.1.1: the WPM callback service should use the existing application
specific databases.
Page 15of 18
System Design Specification for FIN088
Version: 1.0
6 APPLICATION INTERFACES
Apart from the fact that the payment screens will be through the WPM interface other
than WorldPay, the user should not notice any difference.
Page 16of 18
System Design Specification for FIN088
Version: 1.0
7 DATA
7.1 Data Migration
As mentioned in section 4.1.4. The ERA database should be migrated from the MIS
Oracle 9 instance to the FIN Oracle 11g instance.
7.2 Archiving Policy
To be confirmed:
The ERA database should delete records older than 6 months. This should be done
each day as part of the daily batch upload from ERA to eFin (see Finance Channel).
Page 17of 18
System Design Specification for FIN088
Version: 1.0
8 IMPLEMENTATION
Specify any implementation issues that should be considered when creating an implementation plan at
the Build stage.
Each application should be cleared of current users to make sure that no payments are
being made with WorldPay at the time.
Page 18of 18