Hi Yahor,

I don't know whether there is a single 'proper-way' of doing this.

But here's some (half-baked currently) ideas on how you could consider approaching (some aspects at least) of this requirement.

Firstly : note from PRPC 7.1.8 onwards: the OOTB WORD generation is now done Server-Side using the Java Library DOCX4J rather than client-side using the SilverLight control.

(Note: DOCX4J can read and write native DOC files - which is handy to know).

You can see that the DOCX4J JARs are available in OOTB 7.1.8 by running the SQL:

SELECT * FROM pr_engineclasses
WHERE UPPER(pzjar) like '%DOC%';

So on 7.1.8 - you would probably want to consider leveraging the same API to create files on the server-side: where you do not have to worry about client-side installation tasks (Silverlight, WORD, permissions etc).

As you are on 7.1.6 : this option is not available to you OOTB (although you could import the same third-party library into your PRPC 716 system probably).

Here's one approach that might suit your needs - it uses the older Microsoft Office 2003 XML Format : and the advantage of this, is that you can create documents that can be delivered as a single XML document.

I have thrown together a basic example of creating a dynamic WORD file on the PRPC-side, and delivering it to a Windows-based PC - which will allow you to launch WORD directly on the document.

This is how is works:

1. Create a new 'Rule-File-HTM' rule in your Application (mine is 'GCS-GCSAPP-Work') like this:

You can populate this 'HTML' (actually XML) with the contents of some examples on the Web - for instance : Intro to Word XML Part 1: Simple Word Document - Brian Jones: Office Solutions - Site Home - MSDN Blogs or The WordprocessingML Vocabulary — Lenz Consulting Group, Inc. (or in fact there is one on the Wikipedia entry I linked above).

You can deliver this file to your end-users using a PRPC ACTIVITY , that does a Show-Stream (and sets up some HTTP Headers, to make the file launch correctly in WORD).

Here's my Activity that does this:

The 'ContextPage' is created only so we look in the right CLASS Structure to find the HTML (XML) file we want to deliver to the end-users.

The Last step is a Java Step to setup the HTTP headers - and reads:

ClipboardPage objHeadersPage = tools.findPage("pxRequestor").getProperty(".pyHTTPResponseHeaders").getPageValue();
objHeadersPage.putString("contentType" ,"application/msword");
objHeadersPage.putString("ContentDisposition" ,"attachment;filename=myword.doc.xml");

So these two rules will deliver a 'static' WORD file (in XML format, but the end-users will probably not notice any difference); but in order to make this dynamic, we can use 'pega' JSP tags.

I have created an example document which outputs some values from a couple of System Clipboard Pages (OperatorID, AccessGroup).

Here's the full source of the XML inline - I'll post as an attachment also:

<?xml version="1.0"?>
<?mso-application progid="Word.Document"?>
<!-- Modified from:  http://www.lenzconsulting.com/wordml/ -->
<w:wordDocument
    xmlns:w="http://schemas.microsoft.com/office/word/2003/wordml" xmlns:o="urn:schemas-microsoft-com:office:office"
    xml:space="preserve">
  <o:DocumentProperties>
        <o:Author><pega:reference name="OperatorID.pxInsName" mode="literal"/> </o:Author>
    </o:DocumentProperties>
  <w:styles>
    <w:style w:type="table" w:styleId="MyTableStyle">
      <w:name w:val="My Table Style"/>
      <w:tblPr>
        <w:tblBorders>
          <w:top w:val="single"/>
          <w:left w:val="single"/>
          <w:bottom w:val="single"/>
          <w:right w:val="single"/>
          <w:insideH w:val="single"/>
          <w:insideV w:val="single"/>
        </w:tblBorders>
        <w:tblCellMar>
          <w:left w:w="108" w:type="dxa"/>
          <w:right w:w="108" w:type="dxa"/>
        </w:tblCellMar>
      </w:tblPr>
    </w:style>
  </w:styles>
  <w:body>
<w:p>
    <w:r>
        <w:t>Document Created by <pega:reference name="OperatorID.pxInsName" mode="literal"/> :</w:t>
    </w:r>
    </w:p>
<w:p>
      <w:r>
      <w:t/>
      </w:r>
    </w:p>
<w:tbl>
      <w:tblPr>
        <w:tblStyle w:val="MyTableStyle"/>
      </w:tblPr>
        <w:tr>
        <w:tc>
          <w:p>
            <w:r>
              <w:t>pyRuleName</w:t>
            </w:r>
          </w:p>
        </w:tc>
         <w:tc>
          <w:p>
            <w:r>
              <w:t>pzIndexOwnerKey</w:t>
            </w:r>
          </w:p>
        </w:tc>
          </w:tr>
        <pega:forEach name="AccessGroup.pxRuleReferences">
      <w:tr>
        <w:tc>
          <w:p>
            <w:r>
              <w:t><pega:reference name="$THIS.pyRuleName"/></w:t>
            </w:r>
          </w:p>
        </w:tc>
     
         <w:tc>
          <w:p>
            <w:r>
              <w:t><pega:reference name="$THIS.pzIndexOwnerKey"/></w:t>
            </w:r>
          </w:p>
        </w:tc> 
      </w:tr>
          </pega:forEach>
    </w:tbl>
    <w:p>
      <w:r>
      <w:t/>
      </w:r>
    </w:p>
  </w:body>
</w:wordDocument>

Running the 'ShowWordFile' with this XML as input will produce a WORD Document similar to this (screenshot here, I will attach also for reference):

NOTE: If you plan on users EDITING this file - they can do this, and they can save it locally with no issues (WORD might advice to change to a different format)  - but PRPC will no longer be able to process this file (unless you develop a separate solution using perhaps 'DOCX4J').

The next part of the puzzle - is how to embed a REPORT into this WORD file?

I have not yet worked out how to run a REPORT from my ACTIVITY in such a way as I that I have access to the Page 'pyReportContentPage(Code-Pega-List).pxResults' (which the Portal creates on the Thread 'Reports').

But it should be possible to do this - using very a very similar approach to the above - just using different Pages/Properties as inputs. (Although for a fully-flexible mechanism - that can deal with different reports without having to change your WORD XML each time - it would be necessary to also process the ReportDefinintion to figure-out column-headers and so on).

The OOTB Activity "pzCreateExportData" is probably useful as a guide - as it does a very similar thing to the above (It actually create HTML that EXCEL is able to process).

Anyway : I hope some of this might be off some help - maybe somebody else can ship in regarding the REPORT-side of things here (and/or information about a 'DOCX4J' approach).

Cheers,

John