Business application developers must frequently create solutions to automate the day-to-day activities of their organization. These activities typically involve processing and manipulating data in multiple documents, such as extracting and merging data from multiple source documents, merging data into e-mail, searching for and replacing content in a document, recalculation of data in a workbook, extracting images from a presentation, and so forth.
Microsoft Office provides a rich API that developers can use to automate the various repetitive tasks described above, making these tasks simpler. These solutions are common for desktop users, so developers are elevating them to a new level: deploying these solutions to the server. This creates a central point that focuses on solving all of these repetitive tasks for multiple users without human intervention.
Porting a solution for repetitive Office tasks from the desktop to the server looks simple, and it's not really that easy.
Microsoft's Office application suite is designed for the desktop computer environment, where a user logs on to a computer and sits in front of it. Office applications are not the best tool for server-side scenarios for reasons such as security, performance, and reliability. Office applications in a server environment may require human intervention, which is not ideal for server-side solutions. Therefore, Microsoft recommends avoiding the use of such solutions, as described in the Microsoft Support article "Considerations for Server-side Automation of Office".
However, beginning with Office 2007, the office automation story has changed dramatically. In office 2007, Microsoft launched Office OpenXML and Excel Services for developers who want to develop Office solutions on the server.
For Office 2010 and SharePoint 2010,microsoft, you provide a set of new components called application services. This provides developers with a wealth of tools for Office automation solutions. Application services include Excel service, Word Automation services, InfoPath Forms Services, PerformancePoint Services, and Visio services. You can learn more about these services in msdn.microsoft.com/library/ee559367 (v=office.14).
In this article, we'll show you how to build a simple application using Office OpenXML, Word automation Services, and SharePoint to combine individual status reports into one document.
Status Report Workflows
Suppose you are a developer of a service company, and many of the projects in the company are managed by different teams. Each week, each project manager creates a weekly status report using a common template and uploads it to an internal SharePoint repository. Your team manager now wants a consolidated report that contains all of these weekly status reports, and you are selected to perform this requirement.
However, you are lucky. As mentioned earlier, your work is becoming much easier now because you can use OpenXML and Word Automation Services to complete this requirement, and the amount of effort required is greatly reduced. With these technologies, you can develop a powerful, stable solution that you never had before.
Let's take a look at this solution first. Figure 1 shows the proposed workflow. At the beginning of the process, the project manager fills in the status report and uploads it to the server SharePoint. The team manager can then begin merging all the reports stored on the server and generating a consolidated report.
Figure 1 Workflow for generating status reports
Building templates
To implement this solution, you first need to provide a common template for all project managers to fill out weekly status reports. When they fill out the data, they upload the report to the SharePoint repository. This way, in the morning of Monday, the team manager was able to log on to the SharePoint site and start the logic used to perform the following tasks:
Read all status report documents.
Merge them into a single report.
Save the report to the repository for user access.
The status report template is shown in Figure 2 (let's call it Weeklystatusreport.dotx). As you can see, the template contains the following fields: Title, date, project manager name, milestones, and related data, as well as text fields for entering work achievements, future plans, and questions. In this example, for simplicity, we used text fields and date picker controls, but you can also easily use Drop-down lists, check boxes, or other kinds of controls to simplify data entry.
Figure 2 Weekly Status report template