Challenge Overview

1.0 - Challenge Overview

Welcome to the Helium Web App Frontend Assembly challenge! In this challenge, you will need to build the Frontend for the new Helium web application based on the architecture design. This challenge will produce the front end pages and HTTP handlers.

1.1 - Project Overview

The client for this project runs a business where they fill and ship containers of liquid helium.  The current process of planning and scheduling container fills and shipments includes manual steps, such as adding data to Excel files.  For this project, the client is looking to create a web application that fits into their existing system and can be used to eliminate these manual steps and streamline the process of production planning for their liquid helium business.

The existing logistics planning system uses a combination of manual processes, including data from paper/excel spreadsheets and live data in the client’s existing production logistics system.  This current logistics system collects data from existing, client facing systems and orders entered via an order entry system.  All of this data will need to be consumed by the new web application.

On a weekly basis in the current process (or somewhat real-time when conditions change), logistics personnel will gather data from multiple different sources and make a draft schedule. If everything appears good with that draft schedule, they will create a “fill and ship” schedule to deliver to the client’s plants. This schedule tells the plant employees what container to fill, for which customer, and when to ship it. The plant employees are sent repeated schedules if there are any changes from unforeseen conditions.

The new web application will need to integrate with the existing systems and fill in the gaps where manual steps are currently involved.  The end product produced by the system will be the fill and ship schedule.

1.2 - Competition Task Overview

A complete list of deliverables can be found in the TopCoder Assembly competition Tutorial at: http://apps.topcoder.com/wiki/display/tc/Assembly+Competition+Tutorials

Note: Extensive implementation notes are provided at method documentation on UML Class Diagrams. Please follow them for implementation.

Note: Please read the whole Application Design Specification first. All the details not mentioned in this specification are provided in that document.

1.2.1    Front End
This assembly is responsible for all stuff in the TCUML Frontend Class Diagram. Related pages and JavaScript code are also in scope.

1.2.2    Dashboard Page (dashboard.aspx)

Code Behind: DashboardPage
Wireframe: Logistics Planner - Dashboard

Quite some content of this page is rendered in server side, see the Page_Load method for details. But some content are rendered in client side using Javascript, using AJAX calls to server side:
(1)    In the DISRUPTIONS widget: when page is ready, and when the search criteria are changed, make AJAX request to SearchDisruptionsHandler to get matched disruptions, then update the widget content with AJAX response.
(2)    In the ORDERS, ORDERS WITHOUT OVERSEAS BOOKING, ORDERS WITHOUT CARRIER BOOKING widgets: when page is ready, and when the search criteria are changed, make AJAX request to SearchOrdersHandler to get matched disruptions, then update the widget content with AJAX response. Note that the OrderSearchCriteria.WithoutOverseaBooking, WithoutCarrierBooking fields may be used for the later two widgets.
Note that if QueryOrderLastDayCount is configured in client side, then corresponding time range conditions should be added to the order search criteria.
(3)    In the CONTAINER STATUS widget: when page is ready, and when the search criteria are changed, make AJAX request to SearchContainerStatusesHandler to get matched disruptions, then update the widget content with AJAX response.
(4)    In the BOOKINGS widget: when page is ready, and when the search criteria are changed, make AJAX request to SearchBookingsHandler to get matched disruptions, then update the widget content with AJAX response.

Note that if QueryBookingLastDayCount is configured in client side, then corresponding time range conditions should be added to the booking search criteria.

The “CURRENT PRODUCTION SCHEDULE” and “CARRIERS - SCHEDULE, PLANNING AND MILEAGE CALCULATION SHEET” widgets are rendered as server side, so if their header selection buttons are changed, it should post back to server to update the page. But assemblers may enhance it to render all these two widgets content into client side, then show/hide corresponding content when the header selection is changed.

When the dashboard setting is updated, it should call the server side SaveSetting_Click method.

User may drag and drop a widget to reorganize the widgets. This will change the widget ordering. The client side will make AJAX request to DashboardSettingHandler to save the updated settings.
The dashboard should allow any widget to popup, this is just UI feature that should be done in prototype.

In the wireframe page, the “CURRENT PRODUCTION SCHEDULE” widget shows fill and shipping schedules in a single table, this is wrong, fill schedules and shipping schedules should be separated in two tables. This is like the View Schedule Option 1 Page, see 1.2.5 for details about how to render schedules.

1.2.3    Edit Schedule Calendar Page (editScheduleCalendar.aspx)

Code Behind: EditScheduleCalendarPage
Wireframe: Logistics Planner - View/Edit Production Schedule (calendar view)

We will use Infragistics schedule control (http://www.infragistics.com/samples/aspnet/schedule/overview) to render the calendar view. We will bind its GenericDataProvider to ICollection, see http://www.infragistics.com/samples/aspnet/schedule/bind-genericdataprovider-to-icollection for details. We need to prepare resources and appointments for the data provider for the schedule control. The resources include “Fill schedule”, “Shipping Schedule” and “Disruption”. The appointments are constructed from the fill schedules, shipping schedules and disruptions.

Published fill schedules are in color light yellow.
Draft fill schedules are in color strong yellow.
Published shipping schedules are in color light blue.
Draft shipping schedules are in color strong blue.
Disruptions are in color red.

A fillSchedule should not be shown if there is a draftFillSchedule whose ExistingFillScheduleId = fillSchedule.Id; similarly, a shippingSchedule should not be shown if there is a draftShippingSchedule whose ExistingShippingScheduleId = shippingSchedule.Id.

When user edits schedule data, the following data will be tracked:
(1)    For create/update/delete of published data (FillSchedule, ShippingSchedule), a draft data (DraftFillSchedule, DraftShippingSchedule) will be created. For example, if user drag and drop a published schedule data, this is to edit its Date, then a new DraftFillSchedule will be created, draft data will be same as the linked published data except that the Date field is updated.
(2)    For update of draft data (DraftFillSchedule, DraftShippingSchedule), that same record is used but with updated values. For example, if user drag and drop a draft schedule data, this is to edit its Date, then the DraftFillSchedule’s Date will be created.
(3)    For delete of draft data (DraftFillSchedule, DraftShippingSchedule), deleted draft schedule id will be tracked.

Thus finally, the “edit schedule” operations are all tracked with draftFillSchedules, draftShippingSchedules, deletedDraftFillScheduleIds, deletedDraftShippingScheduleIds. When “Publish Ship and Fill Schedule” or “Save Changes” buttons are clicked, these data will be posted to server side. These data may be stored in hidden fields using JSON formats, and in server side, use JavaScriptSerializer to deserialize them. For detailed publish/save handling, see the TCUML Publish_Click/Save_Click methods.

The  “Cancel Changes” button simple links to the dashboard page.

1.2.4    Edit Schedule Table Page (editScheduleTable.aspx)

Code Behind: EditScheduleTablePage
Wireframe: Logistics Planner - View/Edit Production Schedule (table view)

In the table header, there are search fields, when these are changed, it should post back to server so that the table content is updated.
When “Add” button is clicked, it will create draft data (DraftFillSchedule, DraftShippingSchedule) in client side, it won’t trigger server side method, all updates will be handled together in “save” or “publish” buttons click handlers.

Draft records should be highlighted with bold texts.

The rest processing is similar to the “Edit Schedule Calendar Page”.

1.2.5    View Schedule Option 1 Page (viewSchedule1.aspx)

Code Behind: ViewScheduleOption1Page
Wireframe: Plant Employee - View/Export/Print Ship and Fill Schedule - Option 1

This page is rendered in the Page_Load method, it accepts start, end, fillSlotName query parameters, see the Page_Load method doc for more details.
When the “Print” button is clicked, it uses browser’s print functionalities to print the current page.
When the “Export” button is clicked, it will ask user what format to export (Excel or CSV), then make request to ExportScheduleHandler to download the export.

1.2.6    View Schedule Option 2 Page (viewSchedule2.aspx)

Code Behind: ViewScheduleOption2Page
Wireframe: Plant Employee - View/Export/Print Ship and Fill Schedule - Option 2

The processing of this page is similar to the above page. Note that all fill and shipping schedules are rendered, and when “Fill Schedule” / ”Ship Schedule” are selected, hide/show corresponding schedule data.

1.2.7    Help Pages

The wireframe has no help pages, but the prototype provided to this assembly may contain help pages. These help pages if present will be static pages.

 

1.3 - Technology Overview

- Windows Server 2008 R2
- MS Office 2007
- MS SQL Server 2005
- IIS 7
- C# 3.5
- .NET Framework 3.5
- ASP.NET Web Form
- jQuery 1.11.1 http://jquery.com
- Open XML SDK 2.0 for Microsoft Office (already included in .NET 3.5)
- Microsoft Chart Controls for Microsoft .NET Framework 3.5 - http://www.microsoft.com/en-us/download/details.aspx?id=14422
- Infragistics Ultimate 2014 Vol. 1 - http://www.infragistics.com/

 

1.4 - Documentation Provided

Documentation and Applications that will be provided to registered members:

Document Name    Document Description                                
Application Design Specification    Architecture documentation attached
Class Diagrams    Architecture documentation attached
Sequence Diagrams    Architecture documentation attached
ERD    Architecture documentation attached
Backend Assembly Code    The completed Backend Assembly code
UI Prototype    Completed UI Prototype

 

1.5 - Testing

Please include unit tests to verify your application successfully meets the requirements of the project.  You should provide functional tests.



Final Submission Guidelines

- Completed code for the application frontend (see architecture documentation and section 1.2 of this challenge spec above)
- A complete and detailed deployment documented explaining how to deploy the application including configuration information.
- Tests to verify your application successfully meets the requirements of the project.

A complete list of deliverables can be found in the TopCoder Assembly competition Tutorial at: http://apps.topcoder.com/wiki/display/tc/Assembly+Competition+Tutorials

ELIGIBLE EVENTS:

2015 topcoder Open

REVIEW STYLE:

Final Review:

Community Review Board

Approval:

User Sign-Off

SHARE:

ID: 30047451