COMP3121 E-Commerce Technologies Richard Henson University of Worcester November 2011

Week 7: More on Server-side Shopping Carts n Objectives  Plan and design a relational database for use in storing product, customer, order data  Use pre-written assemblies as web controls for use within the VWD environment  Integrate pre-written assemblies with web controls to produce a server-side shopping cart system

Possible Data Model with entities/attributes added

Possible basic data (entity) model for a Shopping System customer Order line order product No entity relationships shown! Where does Shopping Cart fit?

Creating the Physical Database from a Logical Design n Database that can work with SQL required… n Popular options for small(ish) databases:  Microsoft Access »only Access 2000 onwards properly SQL compliant  MySQL »originally shareware for Unix »now available for W2K n Popular options for larger databases:  SQLServer  ORACLE

Testing the Logical Design with Physical Data… n It works on paper… n But a practical working model is needed:  create database tables  link them together, according to the Entity model you created  populate the tables with trial data of an appropriate format  make sure all is consistent

Typical RAD tool “errors”… n MUCH can go wrong…!!! n Before embarking on shopping cart development…  need to make sure all loca/remote web server settings are correct  screen fields and db fields must use the same format »mustn’t use “reserved words” or punctuation, inc spaces  users must have sufficient access rights to write to the database »this especially includes the “IIS process” user  major adjustments may be needed in response to a minor change in design… »TRUE OF MOST SOFTWARE DEVELOPMENT PROJECTS… »all the more reason to get the design right…

Role of Server Scripting in creating Product Pages n After the database has been thoughtfully designed…  it needs to be physically implemented n Server behaviours with appropriate embedded SQL are then required for:  picking the right data out of the remote database  writing data to the appropriate locations in HTML pages on the local client browser

Local storage of “remote” data n Asp.net supports local storage of data through the use of datasets  a local copy of various data fields held on one or more data tables on the remote database  simply a local copy of various data fields held on one or more data tables on the remote database  each field becomes a variable in local memory n The dataset fields map directly onto the fields in the remote database  new data can therefore always be stored locally until the appropriate server command is made that writes it to the remote database

The Dataset Display (one record) n As you have seen, VWD facilitates the set up of datasets & datagrids n Can then be used to display dataset data on a HTML page, as the shopping cart  a from/further control can be used to create a HTML table for displaying a single record  a navigation bar object can then be added and used to navigate to other records

Use of The Repeater with Datasets n To display Multiple Records from a defined dataset, a procedure is used similar to that for a Repeater DataSource control, when used with an external database:  create the table  create “Repeater”  wrap round the  wrap round the  adjust so it wraps around itemtemplate

Making the Product Pages Attractive and Usable n All the principles of web page design learned in COMP1141, 2121, 2040, etc. should still apply:  use master pages, and CSS to give all the pages a common background layout and the same “look and feel”  use client-side scripting, written in various languages, to enhance user interface  make sure the pages load quickly by using software such as Photo Editor or PhotoShop to keep graphics small, lower resolution, or both

Encouraging Customer Interaction n It is the customer interactivity that represents “buying” through the website n Again, server scripts must be written/engineered/used to extract the data from various types of HTML forms and store it:  temporarily in the local datasets  permanently in the remote database

How to capture “buying” data n Data collection needs to be triggered from the shopping pages…  a hyperlink passes the product record ID to a newly created session cookie  An associate page extracts other data from the remote database to the session cookie e.g. price from the product table n This session cookie is of course the dataset for the shopping cart data…  but it needs to be carefully defined…

More about the Cart Dataset n Each new cookie needs an ID  a cookie represents an order… »orderID therefore represents cookieID  a cookie record is created for each new product ordered »this represents an orderline… »each orderline needs an ID »orderlineID therefore equivalent to cookie record ID n Essential for a business to keep records of transactions i.e. orders…  final cookie contents therefore saved to a remote database

Using the Cart Dataset n The AddfromDb control extracts data from fields from products table, held on a remote database  stored as a cart record  stored securely in local memory n Data generated by the cart can also relate to essential data for orders and order-items table, managed by a different control, WritetoDB

More about “The Cart” n Needs to be designed to carry a number of parameters and settings  the WebXelCart assembly pre-defines the variables to store these settings  values need to be added to the cart control via the control “properties” or source code  Data easily extracted from the cart using to create the screen display

Displaying the Shopping Cart n A web page needs to be designed to display cart data from the dataset in an appropriate place n A table design tool saves time…  rows and columns as appropriate…  <%# Eval etc. as appropriate in the cells

Display of Shopping Calculations n Expectation that a shopping cart will display…  a line for each product – including line total  an order total n For the display of line totals and order totals…  calculations need to be included  cart fields needed for results of these calculations n Creation of the cart display is then a simply a matter of:  extracting data from the local dataset  displaying it on the pre-formatted page

Secure Storage/Retrieval of Shopping Cart Data n Sensitive and Private Data should be secure  remote storage obviously better! n Cart data is best held locally for quick response – dilemma? n Compromise  use local datasets with best options for local security  only store non-sensitive data in cart fields  no customer data in the cart…  dataset deleted as soon as the customer logs out…

When to collect customer data n Long standing debate amongst shopping cart designers… n Can either:  make customers “register” when they enter the site  Or… only make customers register when they are ready to buy n The former might be better from a marketing perspective (collecting “intelligence” on potential customers…)  but will put some customers off even browsing the site n Customer registration only when buying is preferable (IMHO…)

Issues with Customer Data n Not stored with the cart but customer details capture is a crucial part of the shopping SYSTEM n Private Data!!!  MUST (1998 Data Protection Act) be kept up to date, stored and moved securely  better not to store locally  write directly to/from the remote, secure, database  always sent/received using secure http

Essential Customer Fields for Purchase n Name & address fields  include postcode n address  fulfilment information & messages n Telephone no  in case fails n Shipping address fields  customer may not want goods delivered to the same address…

Handling Customer Data n Added by the customer to a HTML form  extracted by put or get  sent securely using http-s  Processed remotely on a secure server & stored on a secure remote database  sensitive data (e.g. customer’s credit card details) should be sent securely to a specialist provider with an SSL certificate »can only send such data via https over a secure connection to a secure server n Under no circumstances should personal or sensitive customer data be dealt with using standard HTTP!

On-line Payment Systems n Requires an effective & highly secure method of: 1.authentication of the user 2.authorisation of the amount required for payment (has to follow authentication) n BOTH effectively achieved through an on- line link to the International banking system n Usually a fee required to make this link  makes sense to do authentication & authorisation at the same time  some shopping cart payment systems authenticate NOW, and authorise LATER

Authentication (Is the user really who they say they are?) n Will require confirmation of:  name  type of account  account number  other information (e.g. start date, expiry date, issue number), depending on the type of account

Authorisation (even if they are that person, can they pay?) n Just because the user has that account with those details, doesn’t mean they have the funds available to pay for the goods… n The account needs to be checked against the invoice amount to make sure that the account has sufficient funds…

B2B Payment Systems n Usually make use of EFT (Electronic funds Transfer) n Both buyer and seller need to contact relevant bank computer:  for authentication purposes  to transfer funds n On-line banking system needs to be very secure:  512 bit encryption  private networks with secure gateway from the Internet

B2C Payment Systems n Payment take place through the vendors web site  most popular method - credit or debit card n Relevant bank computer needs to be contacted  uses The Internet to find gateway to bank network  security between bank, server, and browser a major issue - use VPN & secure protocols such as SSL & http-s  Once within the International Banking Network, similar authentication and funds transfer systems as for B2B

Security Issues with B2C Payment Systems n Data could technically be intercepted either:  at the user’s browser  at the vendor’s server  at the gateway to the International Banking Network  en-route between any of the above n Correct use of VPNs (Virtual Private Networks), with encryption and secure protocols throughout make it extremely unlikely that data will be intercepted en route

Protection of “Data at Rest” n No sensitive or personal data on the client n What about the server? The Internet allows any node to be a potential target…  some early systems stored credit card details on the vendor’s server »without encryption! »asking for trouble!  Some concern also about the “secure servers” of merchant service providers »must hold e.g. credit card numbers »may be protected by VPN but data still stored in an encrypted format

Securing those Merchant Servers n Server security a a matter of:  configuration and management of the server software  setting appropriate user privileges and file security  auditing of all access to confidential data  appropriate monitoring of attempted entry to the system by “invalid” users n Probably a lot safer to have credit details held here than written down by a stranger at the other end of the telephone line…

Keeping the Customer Informed! n By ! Relatively easy to set up  of paramount importance, bearing in mind that customers may be from overseas n Opportunities to send messages when:  credit details are authenticated  order is paid for  order is picked  order is dispatched

Summary of Main Points n Client-server shopping system must have a well designed database held remotely n Cart & cart fields should be held in local computer whilst user is logged on n Customer data should be held remotely n Standard shopping cart should not handle online payment data at all, just forward it securely

Good Planning for Shopping Systems n Develop the data model (database) n Plan the shopping pages n Identify the scripts needed to store customer shopping data, produce the cart and invoice n Plan the datasets that will be used for temporary data storage n Choose an Implementation model to interface with the data model (e.g. IIS, asp.net/c#, MDAP, Access) n Select a Payment System that works with the Implementation model chosen

Thanks for listening…