Word Automation Services Share Point 2010

Word Automation Services is available as a service application in SharePoint Server 2010. Three components make up the overall architecture:

  • Front-end object model In, you saw how the architecture of the framework allows for the generation of proxy classes that can be used on the front end to access the underlying service. The Word Automation Services object model is an example of such proxy classes.
  • Document queue The Word Automation Services application makes use of a central database to maintain a queue of jobs being processed. Each job may contain one or more documents. The primary function of the service application is to write items to the queue and to retrieve details of the status of current jobs.
  • Word Automation Services engine The real work behind Word Automation Services occurs in a separate rendering engine that is capable of rendering Word documents and providing a range of features such as file format conversions, dynamic data updates, and repagination. The output of the rendering engine is then stored in the SharePoint content database as a new document.

Creating Conversion Jobs
From a front-end object model perspective, the primary interface to Word Automation Services is the ConversionJob class. The following code snippet shows how to create a job to convert a document to a PDF format:

Determining which action should be performed on all documents within a job is a job for the ConversionJobSettings class. The following class view shows the main properties:

Creating Conversion Jobs

Checking Status of Conversion Jobs
In Word Automation Services, document processing actually occurs in a separate process, and all jobs are queued for processing. As a result of this, determining the status of a submitted job is an important requirement when it comes to designing an application that makes use of the service.
We can retrieve the status of a submitted job by querying the ConversionJob object that we used to create the job. Effectively, a ConversionJob object is passed as a Windows Communication Foundation (WCF) message from client to server; on the server side, after the job has been written to the document queue database, a job identifier is returned to the client. The identifier can be obtained by querying the ConversionJob.JobId property. Because conversion jobs can take a long time to complete, common practice is to store the job identifier for later use. A separate process can then periodically check on the status of the job, as the following snippet shows:

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Share Point 2010 Topics