* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Contoso Catalog
Survey
Document related concepts
Transcript
Design decisions App type Explore the key design decisions for this app. Language Development technologies Tools UX Data storage TIP Click to get more information. Deployment Provider-hosted This is a provider-hosted app that runs as an Azure web site that provides a product catalog stored in a Windows Azure SQL Database. managersand can JQuery propose Visual C#, HTML5,Product CSS3, JavaScript, This provider-hosted app is changes to product prices. A implemented as a Model-ViewSharePoint workflow manages the Controller (MVC) website hosted as an approval process for price changes. Azure website. Server-side logic and The app provides a custom view for a data access is written in Visual C# and SharePoint 2013 client-side object model, ADO.NET, SQL product manager to access the This provider-hosted app the modern, responsive user interface workflow and approve or rejectusing price communicates SharePoint is implementedwith in HTML 5, CSS3, changes. This type of architecture the .NET client-side object model, is JavaScript, and JQuery. perfect for for the managing provider-hosted specifically SharePoint model. and list items used in the Visual Studio 2013lists This app was developed using Visual approval workflow. All other data, Studio such as2013. Category and Product details, are stored in Windows Azure SQL Database and managed by robust MVC, HTML5, CSS3, JQuery SQL stored Therobust app uses TheJavaScript, app hasprocedures. aand modern and ADO.NET to call the user experience. Thestored user interface procedures and display data whereare elements and the user experience required. implemented MVCand Views and The app needsusing to store maintain Windows Azure SQL Database (Category, Product), HTML5, and make heavy use of CSS3, relational data for categories and SharePoint List (Proposals) JavaScript,Windows and JQuery. products. Azure SQL Database tables are ideal for The app can be deployed to this type of data. Approval in the SharePoint online data or toused SharePoint approval process is stored in on-premise environments. It can also App catalog or the Office Store SharePoint lists, where it is easily be published to your organization’s accessed by or thetoincluded workflow. app catalog the Office Store. Design decisions Data Data How should data be managed? Storage type Database or list? Relationships How are relationships implemented? Location Host site or app web? Creation User? Declaratively? In code? Database How Host User? are site Declaratively? relationships or orapp list? web? Inimplemented? code? It willProposals Any The data given notmodel be Category a list good is isrelational. required can userhave experience Categories only zero,by one, to theforce or have workflow more related theproducts. user included Products, to create This in the which theapp, couldbybethe one-to-many and proposal implemented listapp manually relationship itself. Therefore, withcan lookup beitimplemented should fields in beastored SharePoint by using in theprimary list. appHowever, web. key givenforeign and the fact key that constraints atomic transaction in Windows processing Azure SQLis Database. required for Because the list must reside in the app site, it can be created inserting, updating and deleting data, this model should be declaratively in Visual Studio. implemented as a Windows Azure SQL Database. Data that is used in workflows, however, is stored in a stand-alone SharePoint list.so that is The workflow included in the app requires the list definition, another reason to create the list declaratively in Visual Studio. Design decisions Entity relationship diagram Entity relationship diagram Category Fields • • • • CategoryID Name Description ImageURL 1 has ..* Product Fields • • • • • • CategoryID ProductID Name Price Description ImageURL 1 has ..* Proposal Fields • • • • • • • • • ID Title ProductID ProductName Existing Price ProposedPrice ProposedBy ReviewedBy Status Design decisions The PriceChangeApproval workflow The PriceChangeApproval workflow How should the workflow function? How should it run? Manually or automatically? What should it do? What data does it interact with? How does it appear to users? Native SharePoint UI or custom UI in the app? Manually What Native data SharePoint ordoes automatically? it UI interact or custom with? UI in the app? The SharePoint workflow runs should task-based when run aautomatically new UI for item listsisand added to implement workflows to the Proposals isthe very business different list in rule the that web. app from no theprice fluid It reads changes appthe UI, pertinent and can be is potentially made datainfrom the confusing that database list, and such until laborious asa the director current to gives their approval. price directors of the who product, are It isfamiliar not theoptional, proposed with the and app new sobut price, should perhaps and notthe be not person left that to familiar the whouser is to decide proposing with SharePoint whether it. Theor workflows. workflow not to run then Therefore, thebuilds workflow. aastreamlined task The to design include process ofa this friendly for app includes provisioning representation interacting withofworkflow thatalogged custom datadata, should list in and the beassigns app provided web theto right task store to in proposed the members app itself, of price the so the Directors’ changes, directors group. sodohaving not need the workflow to performrun multiple whenever operations a new proposal in is entered from SharePoint just the toapp approve via the or client-side reject a proposed object model price change. is the ideal solution. Design decisions Categories Categories What features should be provided in the Category UI? Category displays Browsing actions Editing actions How should categories be displayed? How should category browsing be implemented? Who can edit categories, and how do they do so? Who should How can editcategories category categories, browsing beand displayed? how be do Categories implemented? they doshould so? be displayed in an engaging, touch-friendly, tile- based UI. Given that the number of categories relative to the number of Product managers and product directors can editshow categories. This includes A simple click onscreen a “browse” actionisshould the contents of the products is low, real estate not too much of a concern. updating names, descriptions, and image URLs. selected to is the user. Browsingcategory categories likely to be performed frequently by a traveling Product managers and product directors can also create and should delete categories. sales team on mobile, devices, so can this be an easy All users, regardless oftouch-enabled their group membership, browse the When a category is deleted, all of the products that it contains are also deleted. process. category data model provides for images to be used as the contents The of categories. background for the user category tiles. The security-trimmed interface provides actions for adding, editing, and deleting categories. These actions are not shown to sales folks. Design decisions Products Products What features should be provided in the Product UI? Product displays How should products be displayed? Browsing actions How should viewing product images be implemented? Editing actions Who can edit products, and how do they do so? Who should How can editproducts viewing products, product beand displayed? how images do they be Given that the number of products relative to the number of categories is implemented? do so? potentially high, screen real estate is a concern. Therefore, the products should not Product Products managers should beand displayed product indirectors ashould list, along canshown with edit various products. includes depending updating onthe be displayed as tiles, but instead be in a listactions toThis make best use of the names, user’s descriptions, security group. and image Most of URLs. the relevant If, however, dataa for price a product change proposal should beisshown available screen. in this list made, then view rather but,than to save committing screen real thatestate, change thedirectly product toimages the database, shouldthe not be Actions for working with should be displayed alongside shown directly. custom approval Instead, workflow a “view” isproduct started. actiondata should be included to show the product in a client-side pop-up. the products in the and directors should support gestures. Product managers andlist, product can also touch-based create and delete products. However, only product directors should be able to see the workflow actions. Sales folks should only the see the product details and the image viewer. Design decisions Architecture Architecture Azure SQL Database hosts the database WhatWindows are the main components of and deals with all transactional data operations the app, such and as: where do they run? • • • • Retrieving category data. Adding, updating, and deleting category data. Retrieving product data. Adding, updating, and deleting product data. The provider runs as an Azure web site. This provides global access to app for a traveling sales team, and supports reading and writing to the Windows Azure SQL Database. The provider adds data to the proposals list in the app web when a price change is proposed. This action automatically starts the approval workflow. The app accesses the list and workflow in an on-premise SharePoint 2013 environment but could also work with SharePoint online. The workflow retrieves data from the Proposals list, and creates suitable tasks for Directors to approve or reject price changes.