If you had to convert Word documents to PDFs using the Word Automation Services in SharePoint 2010, you had to store the files at least temporary in document libraries. That was true, even if you have created the documents dynamically, for example based on SharePoint list item data using the Open XML SDK and sent as response to a web request (as illustrated in this example). Typically you could solve this requirement using streams or byte arrays otherwise, but the ConversionJob class supported in SharePoint 2010 only working with files stored in document libraries via the AddFile method. A further limitation of that only asynchronous conversation was supported, if you needed a synchronous operation, you should have to find workaround, like this one.
In SharePoint 2013 we have the SyncConverter class, that – as its name already suggests – provides the synchronous conversion as well stream and byte array support via its Convert method.
Recently we are working on a document conversation solution again (similar to the SharePoint 2010 example I referred to above), but we did not want to deploy the SharePoint solution each time we change the logic in the Word document creation, but still wanted to have the ability to test:
- If the WAS is able to convert the word document to PDF.
- Does the output of the conversation fulfill our expectations.
- How much time the conversion takes.
So we called the appropriate methods of our Word document creation assembly from PoweShell, and stored the result in a byte array. This step is specific to the current customer project and as such out of the scope of this post. Instead of this we simulate the step simply by reading the static content of a .docx file in the script below. Next we got a reference to the Word Automation Services Proxy, and converted the Word document from the byte array into another byte array, holding the content of the PDF conversion. In the original SharePoint solution this byte array would be sent back in the web server response to the client. In the script we simply save it into a file into the file system. If you run this script, don’t forget, that if the target file already exists, it is overwritten without any confirmation request!
- $url = "http://YourSharePointSite"
- $inputFilePath = "C:\Data\input.docx"
- $outputFilePath = "C:\Data\output.pdf"
- [byte[]]$inputContentBytes = Get-Content $inputFilePath -Encoding Byte
- [byte[]]$outputContentBytes = $null
- # get the WAS proxy assigned to the site
- $site = Get-SPSite $url
- $serviceContext = [Microsoft.SharePoint.SPServiceContext]::GetContext($site)
- $wasAppProxy = $serviceContext.GetDefaultProxy([Microsoft.Office.Word.Server.Service.WordServiceApplicationProxy])
- # or if you have a single WAS proxy in your farm you can use this as well:
- #$wasAppProxy = Get-SPServiceApplicationProxy | ? { $_.TypeName -eq "Word Automation Services Proxy" }
- [void][System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Office.Word.Server")
- $job = New-Object Microsoft.Office.Word.Server.Conversions.SyncConverter($wasAppProxy)
- $job.Settings.OutputFormat = "PDF"
- $job.Settings.UpdateFields = $true
- $job.UserToken = ($site.RootWeb).CurrentUser.UserToken
- $jobInfo = $job.Convert($inputContentBytes, [ref] $outputContentBytes)
- [System.IO.File]::WriteAllBytes($outputFilePath, $outputContentBytes)
- If ($jobInfo.Succeeded)
- {
- $duration = ($jobInfo.CompleteTime – $jobInfo.StartTime).TotalSeconds
- Write-Host Job completed in $duration seconds
- }
- Else
- {
- Write-Host Job completed with error $jobInfo.ErrorCode
- }
You should have the Word Automation Services infrastructure (I mean the service application and the related services) up and running. I was sure, that it is OK in our case, but wanted to keep the script simple, so I did not check these things in the script above. If you are not sure that your farm was set up correctly, you should have a look at this script and extend my version with the test steps if you wish.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
