TM352 Web, mobile and cloud technologies This end-of-module assessment (TM352 EMA) must be submitted by 12 noon (UK local time) on 1 June 2017. This module uses the online TMA/EMA service for submission of the EMA. You can access this service through your StudentHome page. A link to the booklet Information for Students Submitting Examinable Work Electronically will be sent to you approximately six weeks prior to the EMA submission cut-off date by the university’s Examinations and Assessment department. This will give you formal guidance about submitting your EMA, and you should read it carefully. Submission of your EMA is not the same as submission of your TMAs and you must follow the instructions given in the booklet. This EMA takes the place of an examination and so is also referred to as the ‘examinable component’. The EMA makes up a 50% of the assessment for this module and is split into three sections: development of a demonstration API and basic web application (30%) development of a demonstration mobile application (40%) discussion of the future development of the applications and their implications (30%). What to submit It is a good approach to have a separate folder for your answers to each question and then to zip these folders to create a single EMA zip file for submission. As all the material in a folder is specific to that question, you should use three separate Solution Document files: one per question. Question 1 For this question your answer will comprise a written Solution Document and a completed NetBeans project. Your Solution Document should be a .doc, .docx or .rtf file that can be opened in Microsoft Word. Put your name, your personal identifier, the module code, the assignment number and the date on the title page of your Solution Document. It is also useful to your tutor if you include this information as part of the header or footer of your document. You are also required when submitting your completed NetBeans project to make sure that your NetBeans project is cleaned. To do this, right-click on the project in the Projects window and choose Clean Project (not Clean and Build Project). Put everything (your Solution Document and completed NetBeans project) in a single folder and then zip it up before submitting it with other parts to the online TMA/EMA service. Question 2 For this question your answer will consist of a Solution Document, which contains your description of three requirements, a description of the functionality you have implemented, and a guide to installing and running your app. You must also submit your project’s www directory, ensuring that all your HTML and JavaScript is included. Put these elements together into a folder for Question 2 to zip up as part of your EMA submission. Question 3 For this question you should submit a Solution Document that discusses the four issues you have selected. Your complete zipped EMA file must be no more than 10 MB. If your file is bigger than this then you should compress any images you may have used in order to reduce the overall size. Please note that the cut-off for this assignment is 12 noon UK time. You can find guidance on using the online TMA/EMA service via StudentHome. Because the EMA is equivalent to an exam, your marks will not be returned to you via the TMA/EMA service. Your EMA will be marked in the same way as an exam and you will be informed of your results, by letter, approximately 2–3 months after the submission date. The EMA includes use of a database, which you may not be familiar with. However, you do not have to interact directly with the database because a REST API is used. Therefore, you only need to examine the database tables and sample data, which are quite simple to understand and are described later in this document. Experience has shown that students generally do much better if they read the EMA, understand the requirements and make a plan of work as a schedule so that it is clearer how the work will be completed in time for the submission deadline. Plagiarism It is imperative that you avoid plagiarism as it is a form of cheating. If you do plagiarise then you won’t simply lose marks: instead, your work will be referred for further disciplinary action. If you are in any doubt as to what constitutes plagiarism, please refer to the University guidelines or see the Module Guide. Extensions to the submission date for your examinable work are not available. If you are not able to submit your completed examinable work by the submission cut-off date then please refer to the Information for Students booklet to see what options may be available to you. Scenario Note that although you have met MegaMaxCorp in earlier TMAs, the emphasis in the company’s profile and their desired direction have changed in some ways. Therefore you should review the scenario carefully. The MegaMax Corporation sells widgets worldwide to large companies and small businesses, through the web and a mobile sales force. Naturally, their stock situation is constantly fluctuating, as sales and deliveries are made, so they retain accurate information in a database. Specifically, they retain information on: products and prices special offers existing clients (or ‘customers’) salespeople – including their names, addresses, and contact details stock. This data is stored centrally, with varying levels of security, permissions and access. This allows access for: internal management and report generation internal sales staff who visit established clients public access, e.g. for purchasing products via the web. Prices are reviewed and altered on a day-to-day basis, with special deals regularly being made available on certain products, and to favoured clients. The database is currently hosted internally, with selected fields made available to web clients. However, the company is currently considering migrating much of its data to cloud storage. The company currently maintains a conventional set of web pages through which members of the public may obtain information about products, prices and deliveries, and through which they may place or view orders. These obviously interface with the stock, price and other data. In addition to conventional ordering from clients across the internet, the company retain a large and scattered sales force in the UK and worldwide, working generally with large corporations and businesses that make massive orders. These salespeople are given broad responsibility to: take orders from existing clients recruit new clients negotiate with and strike special deals that are not currently available centrally, with new and existing clients. Therefore, the company also requires an app for their sales force to use on a range of mobile devices. The app will provide read access to the company databases to find: current customer data customer order history current price data currently available special deals. The app will also have write access to the databases to register: new customer details updates to existing customer details orders (which may include special price deals). These functions will all be achieved through a set of forms displayed on a mobile device. The app may also provide some client-side processing to assist the salesperson in preparing orders, etc. (e.g. VAT calculations and totalling). Moreover, since the company tracks the locations of all members of their sales force, the app can use the geolocation capacities of the device on which it is running to report its position every time access is made to the company’s central servers (and/or cloud storage), as well as recording the location when a sale is made. The geolocation facility can also be used with externally available map data to plot and cost routes between clients. To demonstrate the potential benefits and risks of using REST, web and mobile technologies, MegaMax would like to see some simple prototypes developed as rapidly as possible to demonstrate how these technologies might work together and to act as a focus for discussion and future development for the company. It is important to the company that the potential to develop a new website and a mobile application are demonstrated with both applications being based on the same instance of the company sales database. To this end, the company is considering employing a REST API for the database and have already developed an initial limited prototype of the API. It is thought that under this scheme (shown in Figure 1) a set of web pages would provide both the website for online ordering by clients, and a mobile app for the sales staff to place orders. Both applications would access the sales database via a single REST API. The website will call the API over the internet, while the mobile app, used by the mobile sales force, will make calls to the API over a mobile phone network. The API itself and the website will both run on web servers. The API will translate HTTP requests from the applications into SQL operations on the database and will then return the appropriate data or an error message if something goes wrong. Figure 1 Components of web and mobile applications Throughout this document the URL for the API has an IP address of: 137.108.93.222 If it is necessary for the module team to change this IP address, the new IP address will be publicised in the TM352 EMA forum. Check the forum before starting work on this EMA. The database The prototype database has a simple set of four tables which represent the core data that the company employs to support both web sales and the sales team. The tables are: clients orders order_items widgets Each table is described in a section below. You will not interact with the database directly, but will use the REST API to access and store data. So the database details are intended only to provide you with some idea of the nature of the data and how the API functions. The REST API is described after the database description. The clients database table The clients table represents the company’s clients. Each row of the table describes a client in terms of their name, address, phone number and email address. A client is uniquely identified by an identifying number or ‘id’. The table has five columns, which are listed below with their types. id int(11) /* an integer field, up to 11 digits long name char(30) /* a character field, 30 characters long address char(100) phone char(12) email char(25) The clients table has some sample data in place, which is listed below. You should not attempt to alter, delete or add to this particular table. id name address phone email 1 Widgets Galore 555 Silbury Blvd, Milton Keynes MK9 3HL 0123 456 789 ************************ 2 Gadgets House berrill building, Walton, Milton Keynes, MK7 6AA 0124 567 890 ******************** You should use this data when you add any new data to other tables. So, for example, if you add a new record to the orders table, then the order you create contains the id of the client that the widgets are for. So you should use a valid id from the clients table above (one of ‘1’ or ‘2’). The orders database table Each row of the orders table represents an order. The table has five columns, which are listed below with their types. id int(11) /* unique identifier of this order client_id int(11) /* an ID from the clients table date datetime /* date and time the order was placed latitude decimal(10,8) /* latitude of sale location longitude decimal(11,8) /* longitude of sale location The id is a unique number which is of type auto_increment so that it is assigned by the system as a unique number when a row is added to the table. So in creating a new order record you need to provide a client id from the clients table, a date and a latitude and longitude, which specify the time and place the order was made. A latitude can range from -90 to +90 degrees and a longitudes can range from -180 to +180 degrees. It is expected that a mobile app would provide location data, but that orders from the website will not and will use ‘0’ values instead. This location (latitude 0, longitude 0) is not a valid location for any client. An example of the data that can be found in the table is shown below. id client_id date latitude longitude 10 1 2017-01-05 14:27:02 0 0 11 2 2017-01-04 16:30:00 40.******** -3.******** 12 2 2017-02-02 17:32:02 51.******** -0.******** 14 1 2017- 52.******** -0.******** Note that the actual widgets in an order are not listed in the orders table. Instead, the id from the orders table is used to create a set of one or more ‘order items’ in another table which is described next. The order_items database table The order_items table has five columns, listed below. id int(11) /* unique identifier of this order item order_id int(11) /* an id from the order table widget_id int(11) /* unique id of a widget from widgets table number int(11) /* number of the widget ordered pence_price int(11) /* price per widget in pence There can be multiple order_items that have the same order_id, which together make up the items of the order. The order_item id field is automatically generated by the system when a new record is created. Below is an example of data that might be found in this table. id order_id widget_id number pence_price 100 10 6 100 10 101 10 8 25 12 102 11 2 1000 8 104 14 9 200 15 The widgets database table In the widgets table each row describes a unique widget product. The columns in the widget table are listed below. id int(11) /* unique identifier of this widget url varchar(300) /* URL of an image of the widget description varchar(300) /* text description of the widget pence_price int(11) /* price per widget in pence The widgets table is a small catalogue of sample widgets and contains the data shown below. You should not attempt to alter or add to this particular table. The actual values in the table are shown below. id url description pence_price 8 http://137.108.93.222/openstack/images/widget1.jpg General Purpose Threaded Coach Bolt Bright Zinc-Plated M10 x 180mm 10 9 http://137.108.93.222/openstack/images/widget2.jpg Coach Screw 10 x 50mm 12 10 http://137.108.93.222/openstack/images/widget3.jpg Rawwlplug LX Masonry Bolts 12x140mm 13 11 http://137.108.93.222/openstack/images/widget4.jpg Marine Eye Bolt 6 x 40mm 8 12 http://137.108.93.222/openstack/images/widget5.jpg Exterior Coach Screw Organic Green M10 x 160mm 6 13 http://137.108.93.222/openstack/images/widget6.jpg Marine Eye Bolt 8 x 100mm 14 14 http://137.108.93.222/openstack/images/widget7.jpg Socket Button Screw A2 stainless Steel M6 x 20mm 12 15 http://137.108.93.222/openstack/images/widget8.jpg Roofing Bolt Bright Zinc-Plated M6 x 30mm 5 16 http://137.108.93.222/openstack/images/widget9.jpg Zinc-Plated High Tensile Steel Hex Bolt M10 x 120mm 9 17 http://137.108.93.222/openstack/images/widget10.jpg Concrete Bolt 10 x 100mm 12 The JPEG images have a standard square aspect ratio of 330 × 330 pixels. Widgets 6, 8 and 10 are 96 dpi rather than 72 dpi, but appear to have the same size in a browser. able relationships The tables are related as shown in Figure 2. All the tables have a unique primary key (PK) which is generated by the system. The clients table key is also used to index orders as the value of client_id so that it is efficient and simple, given a client ID, to retrieve the set of orders belonging to the client. Figure 2 Table keys and relationships The orders id key is also used to index order_items so that items making up any particular order can be retrieved. The widgets id is also used in order_items so that it is possible to find, for example, the number of a particular widget that is on order. The REST API The database sits behind a REST API coded in PHP. This allows access to the database tables in terms of saving or retrieving data for presentation. In general, REST HTTP operations are used to access data as outlined in the table below. HTTP operation Action GET Read record(s) and return these POST Create a new record PUT Update a record DELETE Delete an existing record Each database table has a corresponding URL as part of the API, which is used to access the table: Database table Base URL clients http://137.108.93.222/openstack/api/clients orders http://137.108.93.222/openstack/api/orders order_items http://137.108.93.222/openstack/api/order_items widgets http://137.108.93.222/openstack/api/widgets In calling the API, each base URL should be extended with parameters such as database authorisation************ pass******************s of data. Guidance on parameters is given later in the sections on the API. Each operation can be performed on any table via the API, but not all operations make good sense on all tables; attempting an operation that is inappropriate will result in an error being returned. Some operations require that you send some data to the API. So, for example, to delete a record wou************ pass************nique ID for the record so that the required record can be identified and deleted. All records in the database tables have a unique identifying ID item in a column called ‘id’. In general, for each API interface to a table (clients, orders, order_items and widgets) there are two operations that can be performed without an ID being supplied: A GET with no ID simply gets all records from the table. Values for any of the data found in the record can be specified, in which case only records matching the data values will be returned. A POST has to be performed with no ID as it generates a new record (using the data you supply), but the system will generate the unique ID for the record itself. And, in general, there are three operations that should be supplied with an ID to identify a single record in the database for the operation: A GET with an ID will retrieve the single record with that ID rather than all records. A PUT with an ID will update the record identified by the ID provided with the other data provided in the call to the API. A DELETE with an ID will remove the record identified by the ID provided. Note that if you provide an ID that does not exist an error will be returned (see the section on errors later in the document). The operations appropriate for each table, the data that n************ pass************API, the result (data or a message or a record) sent back by the API, and error conditions and messages are described in the following sections. First we will examine t************ pass ************edentials when calling the API. Previous Table relationships Next Authorisation Authorisation Each call to the API requires that you provide your OUCU and your************ pass*******************ers on the URL call to the API. The API is not connected to your OpenStack account or to the Horizon dashboar************ pass*******************for the API. You can************ pass*******************enStack home page at http://students.open.ac.uk/ mct/ tm352/ openstack/. So ************ pass ************and************ pass*******************ers on every call to the API. As usual with a REST API, no user state is maintained from one API call to another by the MegaMax server. Therefore the user’s credentials must be supplied with every call to the API as additional parameters on the URL sent to the API server. Examples of how to do this are given later.