Introducing Word Automation Services

Over the last couple of months, we've posted about many of the exciting new features of Word 2010 – Co-authoring, the new Find experience, and the Word Web App. This week, at SharePoint Conference 2009, we announced one more (and one that I'm especially excited about): Word Automation Services.

In the post on framing the Word 2010 release, one of the pillars described is "Word Power in New Contexts". Word Automation Services is a big part of that pillar, and represents our desire to ensure that the power and functionality of Word is available beyond the desktop; in this case, by enabling developers to harness the capabilities of Word on the server as part of SharePoint 2010.

Word Automation Services

Have you ever wanted to convert .docx files into PDF? We've heard from many customers trying to perform server side conversions of Open XML files (.docx) into fixed formats (PDF and XPS) using the Word desktop application, and that's what motivated us to create Word Automation Services.

As a component of SharePoint 2010, Word Automation Services allows you to perform file operations on the server that previously required automating desktop Word:

  • Converting between document formats (e.g. DOC to DOCX)
  • Converting to fixed formats (e.g. PDF or XPS)
  • Updating fields
  • Importing "alternate format chunks"
  • Etc.

If you've done any automation of Word, you're probably familiar with the challenges of doing so – challenges well documented by this Knowledge Base article: http://support.microsoft.com/kb/257757. With Word Automation Services, those challenges are a thing of the past:

  • Reliability – The service was built from the ground up to work in a server environment, which means that you no longer have to worry about issues like dialog boxes that bring the process to a halt, expecting a user to provide input; creating interactive user accounts under which to run the application to avoid running into permissions issues, etc.
  • Speed – The service is optimized to perform server-side file operations, and in doing so provides performance significantly better than existing solutions.
  • Scalability – The service can take advantage of the processing power available on typical server hardware (multiple processors, additional memory). For example, although a single instance of WINWORD.EXE can only utilize a single core of processing power, with Word Automation Services, you can specify the number of simultaneous conversions (and the # of processing cores) to use based on the available hardware.

And you still have a solution that has 100% fidelity with respect to the Word desktop application – documents are paginated the same way on the server as they are on the client, ensuring that what you see on the client is what you get from the server.

In future posts, I'll spend some time digging into exactly how the service works, as well as each of these benefits of the service in further detail.

Word Automation Services and the Open XML SDK: Better Together

One of the most important things to understand about the service is what it doesn't do: this service is not intended to be a 1:1 replacement for the existing desktop object model.

Instead, the server is one half of a replacement for the existing object model – the other half being the Open XML SDK.

  • The SDK is designed to handle tasks that don't require application logic, such as inserting or deleting content (paragraphs, tables, pictures), inserting data from other data sources, sanitizing content (removing content, accepting tracked changes), etc.
  • The service is designed to handle those few tasks that do need application logic: reading all of the document formats that Word supports, converting to all of the output format that Word supports, recalculating dynamic fields, etc.

The two halves together enable the creation of rich, end-to-end solutions that never require automation of the client applications, yet sacrifice none of its capabilities – another topic we'll discuss in more detail in the future.

I wanted to keep this introductory post short, but there's a lot we'll talk about in the coming weeks – this service is a big part of our vision of "Word power in new contexts", and should change the way you think about and build document-based solutions on the server.

- Tristan

Office Blogs Comments

Comments: (17) Collapse

  • Will it do mail merge, that is the £64k question as far as I'm concerned!

  • You say "as part of SharePoint 2010." What exactly does that mean? What if I just want to write some .Net code that converts a docx to pdf?

  • Yes Edward, will it do mail merge? I hope so.

  • I know this is a Word blog, but will other products introduce an automation service too? I would really like to be able to convert PowerPoint files to PDF in a reliable way too.

  • Hi, Tristan When can we expect more details on authoring tools in word, for example about the mechanism of co-editing the same document and the approval of the part your partners have just revised? Also, have you thought about making docx the mainstream and take the place of doc? Many biz orgs are still preferring doc. and may create potential problems for folks that are advocates for new & innovative technologies. Best Regards, Paul Zhang [who you may see pretty soon. :) ]

  • I agree completely on the mail merge requirement, and I'd like to add printing to the list. The usual client requirement is something along the lines of: - Create some word templates and store them.

    - Merge them with data (on the server)

    - Print them (from the server) and/or:

    - Email them (from the server) possibly after converting to PDF, XPS, Html or Mhtml(pretty please).

    - Additionally rather than just mail merge which is data bound it would be nice to manipulate the document in code to inject data possibly via content controls, or allow binding to a .Net data table or objects. Is this scenario supported? Also will this be released separately from Sharepoint or do you have to have sharepoint installed? Will it work with WSS? If it's tied to sharepoint and doesn't support some form of data manipulation or mail merge then it's actually not very exciting at all...

  • Section breaks have always been difficult to manage in all versions of Word. Basically they are difficult well impossible in 2007 to delete, move and are basically inflexible. Will any of the automation provided by 2010 automatically insert section breaks because it that is the case it will definitely cause more harm than good!

  • LaughingJohn, check this article: msdn.microsoft.com/.../ee532473.aspx

  • I have seen this article: msdn.microsoft.com/.../ee532473.aspx,thanks very much ,very helpfull.

  • Seconding Kelly's question, will it be possible to use Word Automation Services without needing to install and set up SharePoint?

  • I found the article cited (msdn.microsoft.com/.../ee532473.aspx) completely impenetrable and poorly written. It certainly wasn't pitched at me!

  • Hey guys, Catching up on the comments (will be much better in the future!) - I'll also try to post a bit more to give some additional details that should provide context. @Edward/Marc: The service won't do mail merge - that task is much better suited to the Open XML SDK (which dovetails nicely with the service), as you can open the XML and replace the MERGEFIELD fields as desired. I'll try to post on this in my series. Edward - sorry you found the other article unclear, I'll try to do better when I post. @Kelly/Michael Teper: This means that we're a shared service on top of SharePoint - you can write the code you describe, but only in the context of a solution built on top of SharePoint. As a first class file document management solution, we believe it makes a lot of sense for us to build on top of their platform. @Bram: Good feedback - in the 2010 release wave, it will just be Word, but I'll pass on yuour interest (it was a common question at the SharePoint Conference as well) @Paul: See Jonathan's series of posts on coauthoring for details on that. @LaughingJohn: To the first question, we do support PDF, XPS and MHTML output (but not direct printing; for that, you can convert to PDF or XPS and spool those files to the printer). I love your scenario though, it's one of the things we were targeting in doing this work - using the Open XML SDK to inject the data, and the service to convert the files. The service is built on top of SharePoint's service application foundation, so it won't be released seperately.

  • When is this due for release?

  • @amajid: It's part of the next release of Office (Office 2010).

  • Just to clarify does Word Automation Services work with SharePoint Services or it requires Microsoft Office SharePoint Server ?

1 2  Next >
Comments

Comments: (loading) Collapse