![]()
image9.jpg
EMA
TM352 Web, mobile and cloud technologies
EMA
Copyright © 2019 The Open University
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, transmitted or utilised in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without written permission from the publisher.
WEB 058254
3.1
Contents
· EMA
· What to submit
· Scenario
· Part 1 A web interface to the API
· Scenario
· Overview of provided code
· Coding a web interface
· Tips and troubleshooting
· Part 2 Mobile web app
· Background
· Part 2(a)
· Part 2(b)
· Part 2(c)
· Part 3 Developing the apps
EMA
Start of Box
This end-of-module assessment (TM352 EMA) must be submitted by 12 noon (UK local time) on 16 September 2019.
End of Box
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 50% of the assessment for this module and it is split into the following three sections:
1. the development of a demonstration API and basic web application (20%)
2. the development of a demonstration mobile application (40%)
3. a discussion of the future development of the applications and their implications (40%).
The EMA documentation is presented across two documents:
· The EMA scenario and questions
· EMA Database and API document which provides an overview and details of the EMA database, its content and the API with which it can be accessed.
Please ensure you read both documents in conjunction with one another before embarking on your work for the EMA.
What to submit
It is a good approach to have a separate folder for your answers to each part 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 part.
The separate Solution Documents should use the following naming convention: ‘oucu_solution_partn’
Part 1
· For this part your answer will comprise a written Solution Document ‘your oucu_solution_part1’ and a completed NetBeans project.
Your Solution Document should be a .doc, .docx or .rtf file that can be opened in Microsoft Word. Be sure to 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 for the marker 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. This means that the project takes up minimal space. 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 for part 1, and then zip it up before submitting it along with the other parts to the online TMA/EMA service.
Part 2
· For this part your answer will consist of a Solution Document, ‘your oucu_solution_part2’ which contains your description of three functional requirements that you have implemented , along with a guide to installing and running your app. You must also submit your Cordova project’s www directory, ensuring that all your HTML and JavaScript is included. Put these elements together into a folder for part 2 to zip up as part of your EMA submission.
When you submit your mobile project work to the eTMA system, a full project directory may exceed the file size allowed. For this reason, and for simplicity, you are asked to submit just your ‘www’ project directory, which should contain all of your source HTML and JavaScript.
Part 3
· For this part you should submit a Solution Document ‘your oucu_solution_part3’ 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 may need to 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. You do not have to interact directly with the database however, because a REST API is used. You therefore only need to examine the database tables and sample data, which are quite simple to understand and these are described in a separate 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.
Start of Box
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.
End of Box
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
Start of Box
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. You should therefore review the scenario carefully.
End of Box
The MegaMax Corporation sells widgets worldwide to large companies and small businesses and intends to develop its offering so that it can sell to the public, through the web and via 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 types and levels.
These data are 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 and strike special deals that are not currently available centrally with new and existing clients.
The company thereforerequires an app for their sales force to use on a range of mobile devices. The app will provide read access to the company databases through a REST API 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 via a REST API 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 whenever 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 show 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 requests from applications into SQL operations on the database and will then return the appropriate data or an error message if something goes wrong.
Start of Figure
Figure 1 Components of web and mobile applications
End of Figure
The prototype database and REST API are described in a separate document ‘EMA Database and API’.
Part 1 A web interface to the API
Before starting this question, you may find it helpful to review some of the Block 1 NetBeans activities, in particular NetBeans Activity 9.
Also if you did not complete NetBeans Activity 13, we recommend that you read the first page, which introduces the idea of JavaServer Faces, and the model–view–controller (MVC) architecture that is used in this part. If you did complete NetBeans Activity 13, note that in this EMA you will not need to use ‘pass-through elements’.
There is a provided skeleton NetBeans web project, EMAP1. You will need to download and unzip this project before starting work on this question. Later you will need to zip your completed project and completed Solution Document and return them as part of this EMA.
Scenario
You have been asked to complete a web page-based interface to the API that will allow users to view their current orders and place new orders.
Remember that there is no log in operation and, as usual with a REST API, no user state is maintained from one API call to another by the MegaMax server. The user’s credentials therefore must be supplied with every call to the API.
You will be running a JavaServer Faces application on GlassFish, locally, and it will be interacting with the MegaMax API provided by their OpenStack server. Therefore, there are two servers involved in this question: the local GlassFish server, and the remote API server. The motivation for this is to allow you to maintain user state – including the user’s credentials – on the GlassFish server, which then allows a simpler interaction with the MegaMax API. In particular, the user only needs to supply their credentials once, and the application can then send them with each API call.
Overview of provided code
Open the provided NetBeans project EMAP1 and explore it, noting the following points.
Under Source Packages:
1. In the beans package are two examples of JavaBeans, which provide the model part of the MVC application. CredentialsBean stores the name (oucu) and password of the user, and OrderBean will be used to maintain widget order information. Objects of bean classes are created for us automatically on the GlassFish server when the application is deployed.
2. The CredentialsBean class has the annotations @Named and @SessionScoped. The first indicates that you can access the automatically created bean object from a servlet using the name credentialsBean (note the initial lower-case letter), and the second indicates that the lifetime of this bean is an HTTP session. The method widgetsGet() uses the instance variables of the credentials bean (name and pwd) to call the MegaMax API.
3. In the rest package are Java RESTful client classes. Objects of these classes are constructed to call the MegaMax API. For example, in CredentialsBean, the method widgetsGet() calls the MegaMax API GET method for the widgets resource, using the method get_application_json(). The arguments to this method are the expected response type’s class (String.class) and the user’s credentials.
4. The class Utilities in the util package includes various methods to process JSON, including the method getAsJsonObject, which converts a JSON String to a JsonObject. The method prettyWidgets() is used by widgetsGet() to format the JsonArray part of the API response, using HTML table mark-up.
Under Web Pages:
1. credentialsForm.xhtml provides a form for a user to enter their credentials.
· The tags are a mixture of ordinary HTML and Facelet tags. The Facelet tags we are using have their own namespace, prefixed h:. Facelet tags are much the same as HTML tags in structure, but they are processed by the Faces Servlet and converted into HTML at runtime.
· Note how you can interact with the state of the credentialsBean. For example, the expression value=#{credentialsBean.name} sets the name instance variable of the bean when the Submit button is pressed, using the value the user entered in the inputText field.
· The action attribute of the commandButton refers to options. The local server automatically searches for this page to process the submitted form by appending the extension .xhtml.
2. options.xhtml presents links to pages allowing interactions with the MegaMax API.
3. widgetsGet.xhtml illustrates how the application can access the state of the credentials bean and also how it can call the bean’s methods widgetsGet() and computeColour(). The responses from the methods are inserted into the web page before it is displayed, and this allows us to apply a custom colour to the user’s name and show them a table of the widgets available to them.
The Java classes OrderBean and Utilities, and the web page orderForm.xhtml, are incomplete. None of the other files require changes.
Coding a web interface
To start coding your web interface, follow these steps:
a. Run the provided project and submit your personal credentials on the opening web page. You will then be presented with a web page entitled “MegaMax API Options” which has four links. The first link, for example, is used to to view the available widgets. Before moving on, you should click this link to explore the list of widgets (Figure 2).
Your personal credentials are available on the OpenStack server.
Start of Figure
End of Figure
Figure 2 Widgets list displayed by running the Netbeans project
a. The package rest includes the example Java RESTful clients Widgets.java and Orders.java. Next you need to generate a similar class to use some of the orders-related resources in the MegaMax API.
i. First you will need to register the MegaMax web service in NetBeans. There is a Web Application Description Language (WADL) file EMA_API.wadl included in the EMA download, which describes the MegaMax API.
Register this API within Netbeans, as follows:
In the Services window, expand the Web Services node, then right-click on it and click Add Web Service….
In the ‘Add Web Service’ dialogue box, select ‘Local File’.
Click Browse…, and navigate to where you saved the WADL file. Select it and click Open.
Click OK to exit the dialogue box.
The MegaMax API web service should now be registered in NetBeans as EMA_API in the Services window.
ii. Return to the Projects window. In the provided Java project, right-click on the Source Packages rest package in the Projects window. Select New > RESTful Java Client… to open the ‘New RESTful Java Client’ dialogue box (Figure 3).
Start of Figure
Figure 3 The new RESTful Java Client dialogue
End of Figure
Enter the ‘Class Name’ OrderItems, select the REST resource as ‘IDE Registered’, and click Browse… to select the order_items node in the MegaMax API under EMA_API (Figure 4).
Start of Figure
Figure 4 Selecting the orders node in the MegaMax API
End of Figure
Click OK to select the order_items resource and then click Finish to generate the OrderItems class in the package rest. You should now have a new file called OrderItems.java in your package.
b. (2 marks)
c. To allow a user to make an order, the page orderForm.xhtml needs to be completed. The page contains two incomplete forms to interact with the model backing bean, OrderBean. Complete the two forms on the orderForm page, using credentialsForm to guide you.
i. For the first form, you need to have a single input element for the client ID. Use it to set the OrderBean clientId attribute.
The API allows you to set the latitude and longitude at which an order was made. However, we will not be using these parameters in this web application, so we have just set them to 0 in the bean.
ii. For the second fieldset, you need to have inputs for the order id, widget id, number of widgets to order, and the price in pence per unit. Use the inputs to set the corresponding attributes of the OrderBean.
You will not be able to make an order yet, as you have not written the code that calls the API.
In your Solution Document, include a plain text copy of the HTML for the two forms in orderForm.
d. (3 marks)
e. The Submit button for the first form on the orderForm page directs the application flow to orderPost.xhtml, while the second form directs the flow to orderItemsPost.xhtml. These two ‘post’ pages are used to submit orders and order items respectively.
Open the orderPost.xhtml page and note the call to the orderPost method:
Start of Computer Display
value=”#{orderBean.orderPost(credentialsBean.name, credentialsBean.pwd)}”
End of Computer Display
And on the orderItemsPost.xhtml page:
Start of Computer Display
value=”#{orderBean.orderItemsPost(credentialsBean.name, credentialsBean.pwd)}
End of Computer Display
These two web pages rely on methods in the OrderBean class to call the POST operations provided by the MegaMax API.
The OrderBean methods in turn rely on the RESTful client classes Orders and OrderItems to perform the communication with the MegaMax server.
Take a moment to look at the classes Orders and OrderItems. In NetBeans ensure that the file Orders.java is visible in the editor window and pay particular attention to the Navigator pane (Figure 5)
Start of Figure
Figure 5 Methods in the Orders class
End of Figure
The class Orders includes a constructor, a close() method, a helper method to encode query or form parameters, and methods corresponding to GET and POST operations for the REST resource. View the BASE_URI by double-clicking on it in the Navigator pane. It represents the base URI that will be visited when using this RESTful client:
Start of Computer Display
String BASE_URI = “http://137.108.92.9/openstack/api/”;
End of Computer Display
Note that the Orders constructor adds the string “orders” to the end of this URI. So constructing an object of the Orders class prepares you to access the orders resource of the REST API.
When you begin this assignment, there are no orders registered for your username. To check this, you can use a REST client such as a browser plugin (you may have used one for TMA 03)
RESTClient add-on for Firefox: https://addons.mozilla.org/en-GB/firefox/addon/restclient/
Advanced REST Client for Chrome: https://install.advancedrestclient.com/#/install
or an application such as PostMan (https://www.getpostman.com/apps), but for a simple GET operation you can use a browser and construct a URL with paramters. You can test this by visiting the orders resource in a browser and providing your username and password as query parameters:
Start of Computer Display
http://137.108.92.9/openstack/api/orders?OUCU=yourname&password=yourpassword
End of Computer Display
You will see a fail status along with the reason “404 – No Matching records”, which is as you should expect.
Adding an order requires two interactions with the REST API. First, an order needs to be added for an existing client, and then items need to be added to the client’s order. You will provide code to complete these steps in the following parts.
i. Complete the OrderBean method orderPost() so that it constructs an Orders client object and calls its POST method, post_application_x_www_form_urlencoded().
The first argument to this method is String.class, because we want a string response from this method. The remaining arguments are the oucu and password (from the method parameters), followed by the client id, latitude and longitude (from the bean’s state).
The method should return the response from the MegaMax API – i.e. the value returned by the post method.
Copy and paste the code for your method to your Solution Document.
(3 marks)
ii. Create a new order by visiting the orderForm page and providing a valid client ID. For testing purposes, MegaMax have only two registered clients at the moment. Their IDs are 1 and 2.
When you press Submit, your completed orderPost method from part (i) should return a successful JSON response from the MegaMax server, which will be included in the orderPost page.
Copy the formatted JSON output to your Solution Document.
(2 marks)
f. Next, complete the code to add items to an order.
i. Complete the OrderBean method orderItemsPost so that it constructs an OrderItems client and calls its POST method.
The first argument to this method is String.class, because we want a string response from this method. The remaining arguments are the oucu and password (from the method parameters), followed by the order id, widget id, number of widgets to order and pence price (from the bean’s state).
The method should return the response from the MegaMax API – i.e. the value returned by the post method.
Copy and paste the code for your method to your Solution Document.
(3 marks)
ii. Add items to an existing order by visiting the orderForm page and completing the second form. Provide a valid order id (for example, from an order that you created earlier) and complete the other input fields.
When you press Submit, your completed orderItemsPost method should return a successful JSON response from the MegaMax server.
Copy the formatted JSON output to your Solution Document.
(2 marks)
g. In this part you need to complete the code that produces HTML tables of order items, which will be included in the orderPost and ordersGet web pages.
There are example methods to guide you in completing this part:
· CredentialsBean method widgetsGet(), which uses Utilities prettyWidgets()
· OrderBean method ordersGet(), which uses Utilities prettyOrders().
ii. In the class OrderBean, complete the method orderItemsGet(), to get order items from the MegaMax API.
We suggest that you begin by simply returning the JSON response from the MegaMax server, rather than trying to format it using prettyOrderItems() at this stage.
iii. In the class Utilities, create the method prettyOrderItems() to return an HTML table from an array of order items.
Now complete orderItemsGet() so that it calls this method.
Test your code by visiting the ‘View orders’ (ordersGet) page. (You can also test the code by creating a new order or order items using the orderForm.)
Copy your final versions of the methods orderItemsGet() and prettyOrderItems() to your Solution Document.
Include a screenshot of your ‘View orders’ page in your Solution Document, to show that you have been able to format the order items.
(5 marks)
Tips and troubleshooting
1. There are only two valid clients of MegaMax in the prototype API.
Visit the clients resource at the MegaMax REST service and supply your OUCU and password as query parameters to see that the existing clients are 1 and 2.
You cannot add new clients by supplying different client IDs. Only MegaMax administrators can do this operation at this time.
2. If you are having problems receiving or formatting tables from MegaMax in your NetBeans application, bear in mind that you can test success in creating an order by visiting
Start of Computer Display
http://137.108.92.9/openstack/api/orders?OUCU=yourname&password=password
End of Computer Display
To see order items, you can visit
Start of Computer Display
http://137.108.92.9/openstack/api/order_items?OUCU=yourname&password=password
End of Computer Display
3. Check the GlassFish server console for output from any print statements in the Java code. This can be found in the Output window. If this is not visible, select the menu option Window > Output. You can right-click on the server console and select Clear to make it easier to see recent messages.
4. You can refresh your view of a deployed application in Chrome by pressing Ctrl+Shift+R.
5. If Chrome reports ‘no active contexts’, close Chrome and re-run the application.
6. Be aware that refreshing a page that uses a POST operation will lead to another call to the MegaMax API, which may mean an extra order or order items being added.
Part 2 Mobile web app
To complete this question you are expected to develop, test and document a Cordova app for the Android platform.
Background
The MegaMax travelling sales staff have a requirement for a mobile app which has already been given the name ‘MegaMax Sale’ to present product information to potential clients. The information is to include product descriptions, product pictures, and the standard asking price. Through negotiation, sales staff are allowed to give clients a discount for larger orders or for widgets that are being promoted.
Once an order has been compiled and the prices have been agreed, the sales staff can then send in the order to the company. The cost of the order has to include VAT. The order information together with the time and the location of the sale will be sent to MegaMax to be added to their records. A salesperson can review their journeys by reviewing the places where an order was made.
Since MegaMax salespersons bring their own smart mobile devices, some of them running iOS (e.g. iPhones, iPads), some of them running Android (e.g. Samsung, Google Nexus), the mobile app should be developed using Apache Cordova. For the purposes of developing a demonstration prototype, we assume that most of them use Android devices; therefore, you are only required to test the mobile app on the Android platform.
For your development work you may use any text editor and the Cordova command line tools. Remember that you only need to submit the www folder, which will be the same regardless of which development option you have chosen.
Part 2(a)
Provide a set of three requirements (or functionalities) for this app that you might achieve in developing a prototype (the later exercise), and describe at least one obstacle for each that you foresee which may cause some difficulty for successfully achieving these requirements. Note that the obstacle could be non-technical, for example one from a business perspective. The obstacle that you describe should be different for each functionality.
(10 marks)
Part 2(b)
You can develop the mobile app by first creating an HTML mock-up of the interface with suitable elements (buttons, fields, etc.) and layout, and then later (Question 2(c)) implementing the logic to enable the app to perform the required actions. The interface should be of a form that allows the following actions:
1. Identify the salesperson by their OUCU and the client by a valid client id found in the clients table. As all calls to the API also require a password, this can be hard written into the code.
2. Navigate (with Prev Widget and Next Widget buttons) and display widget images, in addition to the description and asking price.
3. Add the current widget to ordered items, including the amount, and the agreed price.
4. Display the subtotal, the VAT, and the total of an order, together with the client’s name, address (latitude, longitude), and the timestamp of the order.
5. When pressing Place New Order, display a map centered around the location of the salesperson. The map should use markers to show the places where orders were placed by the salesperson.
A template HTML file (index.html) is provided for you. You can download this file from the module website. This file can be used as a starting point for your work. Implement the missing parts of the project associated with the form at the places indicated by comments. Make sure that you include appropriate links (event handlers such as ‘onclick’), from HTML elements which will invoke the JavaScript logic that you code later.
An example of the mock-up of the interface is shown below.
Start of Figure
Figure 6 Screenshot of an example mocked-up interface
End of Figure
My mockup has a scrolling action to display the actual order items that have been added to the order so far (Figure 7). When all the items (widgets) have been added to the order, the ‘Place new order’ button is used, and the map location of the client is looked up using the API and then added (latitude and longitude) to the order which can then be recorded using the API. At the same time, a map with the location shown with a pin is displayed.
I am intending to use the ‘Place new order’ button also to start a new (i.e. empty) order once one has been completed and saved using this button. When this button is pressed to create a new empty order, I will also change the map to show the route between the orders that the salesperson has placed today.
I have also allowed navigation of the widget catalogue and of the existing orders with ‘Next’ and ‘Prev’ buttons for these.
Note that you can use additional buttons and screens as you wish.
As an example of my approach to the app, two screenshots of a solution are shown below in Figure 7. Your solution can be different as long as it satisfies the functional requirements.
Start of Figure
Figure 7 Screenshots of an example solution
End of Figure
(10 marks)
Part 2(c)
As described earlier, a REST API has been prepared to facilitate the management of MegaMax Sales, so that you do not have to worry about the storage of data. What you need to do is to make use of the API URLs explained in the “EMA Database and API” guide, to implement the required functionalities. Before diving into the functional requirements read the database and API guide and then return here to look at the examples of API calls below.
Start of Table
RESTful services (responses are in JSON format)
| Service endpoints and example responses |
GET |
POST |
DELETE |
| http://137.108.92.9/openstack/api/widgets?OUCU=user1&password=password
{“status” : “success”, “data” : [{“id”:”8″, “url”:”http:\/\/137.108.92.9\/openstack\/images\/widget1.jpg”, “pence_price”:”10″, “description”:”General Purpose Threaded Coach Bolt Bright Zinc-Plated M10 x 180mm”}, {“id”:”9″, “url”:”http:\/\/137.108.92.9\/openstack\/images\/widget2.jpg”, “pence_price”:”12″, “description”:”Coach Screw 10 x 50mm”}] }
{“status” : “error”, “message” : ” 401 – invalid username or password”} |
On “success”, returns the widget id, image url, price and description; otherwise returns “error”. |
N/A |
N/A |
| http://137.108.92.9/openstack/api/orders?OUCU=user1&password=password
{“status” : “success”, “data” : [{“id”:”6″, “client_id”:”2″, “date”:”2017-01-05 00:00:00″, “latitude”:”99.00000000″, “longitude”:0}, {“id”:”8″, “client_id”:”1″, “date”:”0000-00-00 00:00:00″, “latitude”:0, “longitude”:”-20.00000000″}] }
{“status” : “fail”, “data” : [{“reason”:”No matching records”}] } |
Returns all the orders placed by the user with the given OUCU with the order id, “client_id”, date and location on “success”; otherwise, returns a message why it has “failed”. Note that when the order was created without specifying the value of latitude or longitude, they may be stored as “null” instead of floating point number. To avoid this problem, you can simply make sure to only create orders with actual values for latitude and longitude, e.g., 0 and 0. |
Insert an order with corresponding fields such as {client_id, date, location}. |
On deletion, the order will be marked as not confirmed. |
| http://137.108.92.9/openstack/api/order_items?OUCU=user1&password=password
{“status” : “success”, “data” : [{“id”:”10″, “order_id”:”6″, “widget_id”:”3″, “number”:”12″, “pence_price”:”45″}, {“id”:”2″, “order_id”:”6″, “widget_id”:”4″, “number”:”10″, “pence_price”:”111″},{“id”:”8″, “order_id”:”10″, “widget_id”:”45″, “number”:”1001″, “pence_price”:”599″}] }
{“status” : “fail”, “data” : [{“reason”:”No matching records”}] } |
On “success”, returns the matched order items, where “order_id” refers to the order’s id, “widget_id” refers to the widget’s id, “number” refers to the number of items and “pence_price” refers to the agreed price.
On “fail”, no matching records are shown. |
On success, create a new order_item if the widget has not been added, otherwise the order_item will be added to the order. |
|
| http://137.108.92.9/openstack/api/clients?OUCU=user1&password=password
{“status” : “success”, “data” : [{“id”:”7″, “name”:”fred bloggs”, “address”:”45, something road”, “phone”:”01234 567 89″, “email”:”fred@bloggs.com”}, {“id”:”8″, “name”:”Fred Bloggs”, “address”:”55, something road”, “phone”:”01234 567 89″, “email”:”fred@bloggs.com”}, {“id”:”9″, “name”:”Fredina Bloggs”, “address”:”45, something road”, “phone”:”01234 567 89″, “email”:”fred@bloggs.com”}] } |
Returns the detailed id, name, address, phone and email of a client. |
Add a client, where the address will be updated by the GPS location. |
N/A |
End of Table
The call listed below is to an API called Nominatim (http://nominatim.openstreetmap.org/). This mapping application can be used to generate detailed information on the location of a client. In general a call should have the form:
http://nominatim.openstreetmap.org/search/<ADDRESS>?format=json&countrycodes=gb
Given the <ADDRESS> this returns the detailed address information, including the latitude as “lat” and longitude as “lon” attributes:.
[{“place_id”:”96368024″, “licence”:”Data © OpenStreetMap contributors, ODbL 1.0. http:\/\/www.openstreetmap.org\/copyright”, “osm_type”:”way”, “osm_id”:”141734330″, “boundingbox”:[“54.5963713”, “54.5965609”, “-5.9236627”, “-5.9233236”], “lat”:”54.59646635″, “lon”:”-5.92349534474763″, “display_name”:”Open University, May Street, Town Parks, Belfast, County Antrim, Northern Ireland, BT1 3JL, United Kingdom”, “class”:”building”, “type”:”yes”, “importance”:0.201},…]
So, for example, the address of the client with id of ‘1’ in the clients table is given as “555 Silbury Blvd, Milton Keynes MK9 3HL”. Using this address in a URL, the Nominatim application will return a JSON structure with more information. So the call
Start of Computer Display
http://nominatim.openstreetmap.org/search/”555 Silbury Blvd, Milton Keynes MK9 3HL”?format=json&countrycodes=gb
End of Computer Display
returns the structure:
Start of Computer Display
[ { “place_id”:”71155256″, “licence”:”Data © OpenStreetMap contributors, ODbL 1.0. http:\/\/www.openstreetmap.org\/copyright”, “osm_type”:”way”, “osm_id”:”32144305″, “boundingbox”:[“52.0441649″,”52.0445506″,”-0.7567538″,”-0.7558532″], “lat”:”52.0445506″, “lon”:”-0.7558532″, “display_name”:”Silbury Boulevard, Central Milton Keynes, Milton Keynes, South East, England, MK9 3AG, United Kingdom”, “class”:”highway”, “type”:”unclassified”, “importance”:0.5 } ]
End of Computer Display
You can find out more about Nominatim at http://wiki.openstreetmap.org/wiki/Nominatim.
In the other API calls in the table, 137.108.92.9 is a server at the Open University preconfigured using an OpenStack instance.
The Functional Requirements (FR) for this app are as follows:
· FR1 The app should make an order as if the salesperson is at a client site with a valid OUCU and password for the salesperson and the client id:
· FR1.1 Validating the OUCU starts with a letter and ends with a number.
· FR1.2 Navigating the widgets catalogue (with Previous and Next buttons) and display of widget images, in addition to the description and asking price.
· FR1.3 Adding the currently displayed widget to the order items, including the amount and the agreed price.
· FR1.4 Displaying the sum of ordered items and adding VAT to the agreed price of each of the order items at 20%.
(12 marks)
· FR2 For the salesperson to review their performance:
· FR2.1 Displaying a Map for the area around the current location of the salesperson when at the client’s premises and placing or viewing an order.
· FR2.2 When clicking on Place NEW Order to start an empty order, displaying the orders along the day’s journey with markers, where the location of client’s addresses are used to place the markers.
(8 marks)
Once you have completed your implementation you should produce a guide, which covers:
1. The functionality you have implemented (what the app does). You may well wish to include some screenshots of the app. This should be written with the end user in mind.
2. Instructions on installing and configuring the additional plugins that you have used. This description should be sufficient for a third party to take your source code and reproduce your application.
The maximum word count for your report for this question is 500 words. This count includes titles and figure captions. There are no penalties for exceeding the limit, but any words in excess of 500 will not be marked.
There are no marks allocated to the report itself but the report is required to gain the marks allocated to the other parts of the question. By documenting the functionality of the app (and any limitations, etc.) and how to run your app, you are assisting the marker in evaluating and testing your app.
Part 3 Developing the apps
Given the REST API and its potential to support applications such as those you have developed, how can the company go forward? The company has decided to invest in some new systems and technology, and has identified a set of issues that it believes are central to developing a better solution in the medium term. These are:
1. dealing with legal issues and security risks. The company will be storing data about clients such as contact details, bank details and transaction records, as well as stock and order details.
2. providing appropriate storage with backup and security for this, and maintaining the accuracy and consistency of data across applications
3. potential costs and savings of implementing or using new technology, staffing, training, licensing etc.
4. requirements for personnel and their skills for development, maintenance and use of the system and applications
5. potential for and approaches to scaling and supporting greater reliability of the applications.
In the first section of your report, you should outline a set of technology options and components that the company might employ to take advantage of cloud and mobile technology within their operations. Be sure to make a clear and justified recommendation for adopting your selections. Your choice of technology should describe a set of components (web server, networks, software etc) in concrete terms and not discuss, for example, the different levels of approach possible (IaaS, SaaS etc). Note that MegaMax currently has both a central IT facility and travelling salesteam with other requirements. It is advisable to include a diagram of the elements you include with clear labelling.
Then select three of the items from the list above and discuss them and how they impact MegaMax in the context of your recommendation. In your report you should have four clear sections, one for the set of technology options and then one for each item from the list. Use a range of references as a foundation for your discussion. You should search for quality information sources online, including via the OU Library.
It is important not to cover areas in general terms but to be specific to MegaMax and the development of the two applications (web and mobile) that have been prototyped, and to consider the potential uses of cloud technology. You will not gain marks for covering more than three of the issues.
Relate your discussion to MegaMax as much as possible. Do not repeat the descripton of MegaMax and you are not required here to write a structured report with an introduction etc but you should have four clear sections and a set of references that you have used.
The maximum word count for this question is 2000 words. This count includes titles and figure captions but not references. There are no penalties for exceeding the limit, but any words in excess of 2000 will not be marked.
(40 marks)
Page 1 of 3 2nd August 2019
Do you need a similar assignment done for you from scratch? Order now!
Use Discount Code "Newclient" for a 15% Discount!
