Overview of a SharePoint Report Repository and Crystal Reports
Although most user groups might only have the permission to view documents, an Approval group should be created with the permission to view drafts and manage lists. This group will be responsible for content approval. Content Approval is a common requirement when managing documents. With Content Approval enabled for the report document libraries, any reports that have been modified or newly uploaded will be in a pending state until it is approved or rejected by a member of the approval team. While in a pending state, only members of the Approval team and Administrators will be able to view the documents.
When applied to reports, this is a powerful concept. A report may contain bad or incomplete results. In such a scenario, it should not be viewable by most users until the issues are resolved.
As a result, auto-generated reports initially will be in a pending state and invisible to users outside of the Approval group. When a member of the Approval group has confirmed that the report can be released, the member can set its state to approved; the report automatically becomes visible to the general users. If there is a problem with the report, it can be rejected and scheduled to be generated again; the rejected report remains invisible to the general users as the report generation cycle repeats.
Such an approval process can be enhanced further by being encapsulated in a workflow. SharePoint supports workflows that can be created through the SharePoint interface. For example, emails can be sent out along with a task that can be assigned from within SharePoint. Further customization can be accomplished via the SharePoint Designer or Visual Studio.
There often are reports that are generated on a weekly, monthly, or even annual schedule. To facilitate scheduling such reports, the scheduling information should be stored in a database. Because the scheduling information might be shared with applications outside of SharePoint, as shown in Figure 1, the SharePoint content database is not used. By using document libraries and web part pages, users are able to view and modify the report schedules through SharePoint. By doing so, the SharePoint site becomes the central interface for both managing and creating documents.
Within SharePoint, a document library that hosts web part pages should be created. A web part page is an ASP.NET page composed of controls called web parts. Although there is a set of default web parts that comes with SharePoint, custom web parts will be required to access the report schedules. These web parts can be built by using ASP.NET and Visual Studio or by using a wrapper web part such as a SmartPart to host ASP.NET user controls.
An alternative approach that does not require custom web parts is to have web part pages that use the built-in Page Viewer web part. The Page Viewer web part can display web pages and can be used in conjunction with an ASP.NET application, as shown in Figure 3. This allows support for a new or existing ASP.NET application to access the scheduling information.
Figure 3: Sample Report Schedule page
There can be one scheduling page or multiple scheduling pages, depending on the need. Through the report scheduling pages, the users should be able to specify all the necessary information to generate a particular report such as the type of report, how frequent the report should be generated, and the destination document library.
Once the report scheduling pages are created, links in the quick launch menu can be added for each one, as shown in Figure 4 under the Scheduling menu. This allows easy access to the scheduling pages. By setting the permissions for the Report Scheduling document library, only users belonging to the appropriate user groups will have the ability to modify the schedules.
Figure 4: Sample custom Quick Launch links.
Reports can come in many different file formats such as Adobe PDF files, Microsoft Word documents, or Excel Spreadsheets. There can be many different sources from which reports are generated and uploaded to SharePoint. For this article, the primary report file format will be a PDF generated from a .NET application using Crystal Reports.
PDF reports offer a common format that easily can be linked in emails and shared. At the same time, they are less likely to be modified. Because this is hosted in a Windows environment, a .NET application can be created to serve as the report generator. The application should not require user interaction and can be a simple console application running in Windows Task Scheduler.
Page 2 of 3