loading...

Case Study

Introduction (The full case study is available here as a pdf)

This case study is for an application developed using Enfacade for the global engineering and construction company Foster Wheeler.

The application was for the entry of timesheets into their man-hour accounting database by an employee or contractor working for them anywhere in the world via the internet.

They already had a legacy client-server based application for this purpose. However, as is often the nature of client-server applications, it needs to be installed on each PC that wishes to use it. Furthermore, it was not geared towards SQL access across the internet.

There was a medium to long term strategy of replacing the entire man-hour accounting system, so there was no justifications for a big spend on this system. However, the budget available was considered enough for an Enfacade application that would be fit for purpose for the period until the entire man-hour accounting system was replaced.

The application was subsequently developed to the point of final testing in about 2 man-weeks.

The resulting runtime was stress tested to handle 500 concurrent users.

In production, the application is being used to enter up to 5,000 timesheets per week, the vast majority often concurrently on a Friday.

The application has now been live for a couple of years and, to date, apart from some fine tuning in the first few weeks, there have been no reported problems.

Requirement and Resulting Application

The functional specification was effectively the old client-server application, but working using any web browser across the internet.

The new application therefore needed to access and update the existing legacy SQL database.

Users access the application in the normal way of invoking a URL which causes the logon page to appear:

Logon

They then enter a user Id and password which would be validated with invalid attempts reported back to the user on the same page.

Entering a valid logon causes the timesheet web page populated with data for that user, and for that particular week, to appear:

Timesheet

The timesheet page dynamically adjusts depending on the user's conditions of employment. For example, columns for overtime hours may or may not be required; the user may or may not need to enter hours on a daily or weekly basis; and so on.

The user can then enter/edit the timesheet entries they wish to present for the week. A timesheet entry is basically the hours booked against a particular booking code. Many timesheet entries can be added for a timesheet, all against unique booking numbers. These are entered in a tabular fashion with the hours dynamically adding up horizontally and vertically in a spread sheet type manor to give the overall picture.

Pick list functionality was required for choosing the booking codes. The logic required for calculating the content of the pick lists is complicated by the fact that it could vary depending on the user, the week, and other parts of the booking code already entered.

Pick List

Three different options were required for selecting codes:

  • Recently booked codes.
  • Common and Popular codes (e.g. holiday, sick, general overhead etc).
  • A general pick list searching on Charge No and/or description.

This functionality was supplied in one pop-up window with a tab for each option. For the last of these options wildcard querying was required. For example, the screenshot above shows the wildcard '002' being entered to display all the Charge Numbers whose Charge No has '002' embedded in it.

All this functionality comes as standard with Enfacade with no programming required.

At any time the user can choose to save the timesheet. Before saving, the hours and booking codes entered are validated. Invalid bookings are reported back to the user with the reason for the failure. They can then optionally view these errors via the menu:

Errors

The algorithms for this validation are very complicated - along the same lines as the pick list logic. The validation logic in the existing client-server application was embedded in the front-end rather than on the SQL database, so the validation needed to be re-written in its entirety in the new application.

As well as entering the current week's timesheet, the user can also edit any past and future timesheet. They simply choose the timesheet date from the drop-down list of valid timesheets to edit which will cause the chosen timesheet's data to be displayed.

Data Drop Down

Some final pieces of functionality are the ability for a user to change his/her password, print the displayed timesheet, view the booking codes that are currently blocked to them, and open the online help.

What follows is a summary walk through of the major design decisions that were made in developing the application. The narrative assumes that the reader is relatively familiar with the way Enfacade works and the terms it uses. Therefore, it is recommended that the Summary and the Enfacade Layers have already been studied. Although not essential, viewing of the Tutorial Videos would also help.

The narrative from here onwards also uses the conventions used in all Enfacade documentation. In particular:

  • Terms that have a specific meaning in Enfacade are always capitalized e.g. Entity Set, Layer Processing, and so on.
  • XML and Business Object names are shown in red.
  • XML is in light blue.

The full case study, including the above, is available here as a pdf.