What is a proper way to include report into a word document?
In general, task is to insert a grid produced by report definition into word (2013) file in Pega 7.1.6. I've tried to utilize the CreateMergedWordDoc
flow action from PegaSample, however it did not work as Word version 15 is not supported by the embeded silverlight control. My current approach is to use AttachAndHold action from Work-, but still many problem arise. To include a report definition result, I put a section with grid layout into a correspondence, which is in turn merged with a word file. As far as I understand, merge is done in the following manner:
Process Commander puts a text file, which contains our correspondence, into client filesystem;
MS Word is initiated;
user accepts embeded content in word;
AutoOpen macro is executed. This macro simply takes text from a file generated by Process Commander and puts its contents into opened Word document.
After macro has executed, a Word file contains HTML code of correspondence - Word seems to be unable to handle markup. So, having no more ideas in mind, i wrote a parser in visual basic and included it in AutoOpen macro. This is obviously not the best solution, as it is neither maintainbale nor scalable. Maybe it is possible to write custom section with report, which will be understandable for Word.
So, i would really appreciate any ideas or research directions on how I should include section into doc-file or another way to put report into doc.
P.S. It was strict requirement to use Word, as this file is expected to be edited by a person.
***Updated by moderator: Lochan to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
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:
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).
thanks a lot for Your detailed response! I'll mark the answer as correct, as my repot is relatively simple and it should produce results slightly similar to attached by You, maybe it would be even sufficient to use XML markup in a similar way. So, anyway, I think, now I have enough information to implement what is required.
Interesting thing that the first my thought, when I received this task, was utilizing a Docx4j, however, I brushed aside this idea due to client-side merging Actually, we should consider upgrading to 7.1.8...