COMP3121 E-Commerce Technologies

1. COMP3121 E-Commerce Technologies Richard Henson University of Worcester November2011

2. Week 7: More on Server-side Shopping Carts • 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

3. Possible Data Model with entities/attributes added

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

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

6. Testing the Logical Design with Physical Data… • It works on paper… • 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

7. Typical RAD tool “errors”… • MUCH can go wrong…!!! • 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…

8. Role of Server Scripting in creating Product Pages • After the database has been thoughtfully designed… • it needs to be physically implemented • 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

9. Local storage of “remote” data • Asp.net supports local storage of data through the use of datasets • 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 • 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

10. The Dataset Display (one record) • As you have seen, VWD facilitates the set up of datasets & datagrids • 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

11. Use of The Repeater with Datasets • 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 <itemtemplate> round the <table> • adjust <repeater…> </repeater> so it wraps around itemtemplate

12. Making the Product Pages Attractive and Usable • 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

13. Encouraging Customer Interaction • It is the customer interactivity that represents “buying” through the website • 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

14. How to capture “buying” data • 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 • This session cookie is of course the dataset for the shopping cart data… • but it needs to be carefully defined…

15. More about the Cart Dataset • 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 • Essential for a business to keep records of transactions i.e. orders… • final cookie contents therefore saved to a remote database

16. Using the Cart Dataset • 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 • Data generated by the cart can also relate to essential data for orders and order-items table, managed by a different control, WritetoDB

17. More about “The Cart” • 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 <%# Eval… %> to create the screen display

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

19. Display of Shopping Calculations • Expectation that a shopping cart will display… • a line for each product – including line total • an order total • For the display of line totals and order totals… • calculations need to be included • cart fields needed for results of these calculations • 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

20. Secure Storage/Retrieval of Shopping Cart Data • Sensitive and Private Data should be secure • remote storage obviously better! • Cart data is best held locally for quick response – dilemma? • 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…

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

22. Issues with Customer Data • Not stored with the cart but customer details capture is a crucial part of the shopping SYSTEM • 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

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

24. Handling Customer Data • 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 • Under no circumstances should personal or sensitive customer data be dealt with using standard HTTP!

25. On-line Payment Systems • Requires an effective & highly secure method of: • authentication of the user • authorisation of the amount required for payment (has to follow authentication) • BOTH effectively achieved through an on-line link to the International banking system • 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

26. Authentication (Is the user really who they say they are?) • 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

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

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

29. B2C Payment Systems • Payment take place through the vendors web site • most popular method - credit or debit card • 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

30. Security Issues with B2C Payment Systems • 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 • Correct use of VPNs (Virtual Private Networks), with encryption and secure protocols throughout make it extremely unlikely that data will be intercepted en route

31. Protection of “Data at Rest” • No sensitive or personal data on the client • 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

32. Securing those Merchant Servers • 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 • Probably a lot safer to have credit details held here than written down by a stranger at the other end of the telephone line…

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

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

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

36. Thanks for listening…