In this book, we use the designation “enterprise application” to describe a class of applications that are deployed in an organization that have the following characteristics:
A) Are functionally complex with numerous procedural contingencies
B) Are driven by user context
C) Must integrate with and access multiple information sources
D) Are accessed by a large population of users
An employee-absence tracking application, when implemented robustly to incorporate the complex use-case functionality required in large organizations, is emblematic of an enterprise application. As such, the exercise of designing and creating a reference implementation of this commonly used application will be an object lesson in identifying the numerous enterprise requirements relevant to an employee-absence tracking application, and demonstrating how the SharePoint platform can accommodate them effectively and efficiently.
As part of their overall compensation and benefits package, organizations provide employees with vacation, sick and personal leave time, and some organizations allow carry-forward balances from year to year as well. Employees typically draw down these allocations through an absence-request process. Employee absence-tracking applications manage the process, policies and contingencies of employees using their allocated leave time.
In large organizations, leave-time allocation and record keeping is a function of a centralized Human Resource or Payroll system, but the actual transactional process of requesting and approving leave time is executed in a separate application and very often in multiple instances of such applications.
The reason for this is that the policies and contingencies governing the consumption of leave time are typically set and managed differently within the multiple operational and regional units of an enterprise. Attempting to accommodate all of the unit and regional contingencies for absence management in a single application instance is unwieldy and impractical.
Consequently, the architecture of this Employee Absence Tracking reference implementation decentralizes the rule logic for absence request contingencies, yet centralizes the time recording and accounting information—the time-away allocations, the cumulative usage and the balance of time available; as this information is typically also used by or is relevant to other HR applications such as payroll.
Multiple instances of this Employee Absence Tracking application can be instantiated and configured individually to implement only those rule sets that are applicable to any given operating entity; but each instance will access a common organization-wide data store that maintains the categorical absence time available and used by each employee.
We use an SQL Server 2008 database to represent this information store, and we will use SharePoint Designer and Business Data Connectivity Services (BCS) to create External Connections, External Content Types, and External Content Type Lists to make this information available to SharePoint and InfoPath, and enable bidirectional read/write access to the database.
The functional logic of the application is implemented in an InfoPath form and a SharePoint Designer workflow, and is “loosely coupled” from the data store. It is easy to create and deploy multiple instances of the application that can be customized as required, all of which will use a BCS External Content Type to interact with the same database.
In a well-designed absence tracking application, when an employee starts an absence request, they are presented with their entitlements, and the time used and still available in each leave category. Often it will show carry-forward days from a previous year and any forfeiture of accumulated leave time if not used based on the organization’s policy. In this reference implementation, InfoPath is used to create the Absence Request form, which will be rendered in a browser using InfoPath Form Services as shown in Illustration 1 below.
Form rule logic executes automatically upon the creation of the form to auto-populate the organizational and leave time information about the user. This is accomplished by using the userName function of InfoPath to determine the identity of the user creating the form, and passing the user identity as a query parameter to an Employee Information database created in SQL Server and exposed through Business Data Connectivity Services.
The Form Load rule logic that auto-populates the form is shown in Illustration 2 below.
The Absence Request form presents the user with date-picker controls to pick the dates that they want to take off within each leave-time category. Rule logic is implemented that constrains the dates that the employee can choose as well as the behavior of the form based on the leave policies and contingencies of the organization. The leave policies and restrictions implemented as rules in the Absence Request form are:
The policy that vacation time away cannot be requested for past dates. The Absence Request form contains rule logic that prevents picking dates prior to the current date for vacation and personal leave days; however, past dates can be picked for sick-leave days. Organizations want to manage time away as best as possible; allowing people to take vacation days before they request them would diminish the ability of an absence-tracking system from working effectively. This policy is not applied to sick days, which are typically not planned for.
Designating restricted and reserved days that cannot be picked for vacation or personal leave time. In any operational group of an organization, there are typically periods where an intense effort is required. In finance and sales, the week before the end of a fiscal quarter, and certainly before the end of the year, are crush times, and taking time off during those periods is discouraged if not actually prohibited. Special events are also typically scheduled in advance so that people will plan around them. The Absence Request form contains rule logic that will check requested vacation dates against a SharePoint list of restricted and reserved dates by organizational code in real-time, and prevent the conflicting choice to be made.
Illustration 3 below shows the Restricted and Reserved Dates list used for this purpose.
Leave time requested in any allocation category cannot exceed the available balance. The Absence Request form will compare the total amount of time requested in each leave category with the available balance, and prevent the user from requesting more time than is available. Furthermore, leave time in any category cannot be requested if the balance of available time has been depleted. The Absence Request form will hide the date request sections for each leave category once the balance of leave time has been exhausted.
The requirement for management approval when the aggregate leave time requested is above a threshold in conjunction with a consideration of the employee’s tenure. The Absence Request form uses submit-rule logic to trigger an approval process if the total leave time requested exceeds a threshold for a defined tenure period.
Illustration 4 below shows the rule conditions that evaluate whether an absence request requires management approval based on the employee’s tenure and the amount of leave time requested.
After the user selects valid leave dates for each leave category, they submit the request to a SharePoint form library. The application generates new values for the year-to-date leave time used and the year-to-date leave time balance in each absence request category. It does this by adding the existing year-to-date values from the Employee Information database with the total leave time in each category requested in the form. These new year-to-date values are written to the form library columns when the form is submitted. This serves as the interim record of the transaction prior to updating the permanent employee record in the Employee Information database. The workflow component of the Employee Absence Tracking application will update the Employee Information database with the new values as well as execute the rule logic for the approval contingencies.
The Absence Request form also contains rules to address the different behavior required when a submitted form is opened by one of three possible individuals: the original initiator of the request, the manager responsible for approving the request, or a person who is neither the initiator nor the designated approval manager. If the original initiator opens the submitted form, it will open in a view that is read-only. If the designated approver opens the form, it will open in an editable version displaying the approval section. If a person who is neither the initiator nor the designated approver attempts to open the form, they will be presented with a view that simply presents the message that “they are not authorized to view this form”.
The pervasive use of user context attributes is a distinguishing characteristic of an enterprise class application. The form is designed to use the identity of the user from the outset to provide all the relevant information to the user as well as drive the form behavior in numerous ways. Without the use of contextual drivers, the application would be significantly less useful in an enterprise, or the required functionality would need to be implemented downstream in a far less integrated and elegant way. These contextual drivers are what define the complex use-case requirements of many enterprise applications.
