Document Window

[KVoss]

Does anyone know if the document window been integrated into EG 4.2?

Thanks

Keith

[deleted_user]

If I understand you correctly, the answer is probably yes. EG 4.1 is running on top of SAS v9.1.xxxx

http://www.sas.com/offices/NA/canada/downloads/presentations/Calgary/whats_new_in_SAS9.pdf

This presentation when searched for "document window" refers to ODS which according to the EG 4.2 webinar has been "enhanced" so I would guess yes if I am understanding what you were asking.

Tom MIller

[Cynthia_sas]

Hi:
Actually, I believe the answer is NO. EG is a headless client application -- which means it does not have an interface for windows that can "pop" open -- so just as the LIB, KEYS and VAR windows will not work in EG, I don't believe the Document window will work in EG. You can, however, submit batch PROC DOCUMENT code from an EG code node. You just can't view the document stores interactively from within EG.

When I wrote this paper:
http://support.sas.com/resources/papers/sgf09/318-2009.pdf

I checked with the EG developers and was told that the batch syntax was the way to go with EG:
"However, if you work on SAS® Enterprise Guide® (without access to the DOCUMENT window) or you want to create an ODS Document store as part of nightly production processing, then the PROC DOCUMENT syntax will allow you to
accomplish these creation, management, and replay tasks."

cynthia

[KVoss]

Thanks Cynthia. I'd like to take advantage of the document store for some large batch processes but I'm concerned about how we'll manage the contents. Ideally, I'd like to push project output to a document store so that users could selectively put together and replay portions as needed (for sales presentations, meetings etc). I've done this before in non-EG SAS and it was very nice. However, we are in an EG only environment and we have quite a bit of output being generated. This wouldn't necessarily be a problem but trying to determine which GLM or print etc has the info that the user is looking for, without the interactive window, seems messy. This is complicated by the fact that the batch process may run different processes/procedures depending on the input parms. Do you have any suggestions regarding how this can best be managed? From what I've seen there's no way to "label" the procedures at run-time (Although even if there were, I don't think we could see the labels without the interactive window).


From a dev standpoint, I would like to use this functionality to provide some added flexibility in our production reporting. However, the idea of having to manage the potential ripple effect of document references when a new proc is added (without the advantage of the interactive window for identifying/verifying output objects etc) is keeping me from moving in that direction.

I really would like to take advantage of this functionality so any suggestions you have are appreciated!

BTW...could the document window could be called via a .NET application and integrated into EG that way?

Thanks

Keith

[Cynthia_sas]

Hi:
As far as I know, the Document Window is "built-in" or hard-wired into Display Manager. I'm not sure that it can be surfaced outside of Display Manager -- for example, with .NET or any other process.

EG has a way to construct documents from the results of a project. In EG 4.1, the choice is under Tools --> Create HTML Document -- which allows users to pick and choose from the contents of a project or you can link to other documents. The Document Builder window is not the same as the Document window that is inside Display Manager, but is worth exploring. You might be able to run your batch process output into EG projects (you'd have to explore this with the EG Developer's Manual and SAS Integration Technologies doc) which would then open up the Document Builder window inside EG to your users -- if they accessed the saved projects.

Alternatively, if you were working only with batch ODS DOCUMENT stores and PROC DOCUMENT, you'd almost have to capture the object name and document store number at the time of creation, in order to sufficiently identify it for selection and replay at a later time. I don't think my approach would be to have a huge document store and keep adding to it. I think I'd organize the document stores by day, possibly by day and report in order to narrow down the objects for possible replay.

This is an interesting idea for use of ODS DOCUMENT stores. You might run your question by Tech Support (can the document window be called via .NET) so they could trickle the question to the Document Window developer for a definitive answer and possibly more thoughts on the subject.

cynthia

[KVoss]

Thanks Cynthia! I really appreciate it!

[RichardH_sas]

One last thought in addition to what Cynthia said: in EG 4.2 (and later versions of EG 4.1) you also have the capability to combine output from multiple reports in a SAS report format using New / Report. This is a bit more flexible than the document builder since you can lay things out in a grid layout rather than just one on top of another.

Again, input sources have to be in the SAS report format.

[KVoss]

Thanks Richard. I'll take a look at the New Report functionality.
The thing that I'm really struggling with is trying to integrate results from batch processes with EG. That is, trying to find a flexible way to surface those batch results to users of EG so that they can replay them or build a report based on pieces of the output (without having to re-run the job within EG). However, it seems there's no way to read that document item store from within EG except via proc document. Even this might be suitable, if I could have the batch job label the pieces of output with meaningful labels that were visible via proc document.
However, I'd ideally like to be able to import the document item store into EG. Or, maybe surface this document store via the SAS add-in for MS Office?

Thanks again for all the input! Let me know if you have any more thoughts.

Keith

[KVoss]

Maybe the only solution is to have the user replay the doc store (in its entirety) for the last batch run and then use the document builder etc to pull out meaningful pieces. I'm assuming that would run pretty fast, even with 100 or so output objects. Or, maybe we could have a stored process with a limited number of selection criteria that would run proc document in the background and pull a smaller set of the user's info back.
BTW...Would that report builder be able to pull-in both report and gplot/gchart output? We're just now getting ready to go to 4.2 and it looks like in 4.1 the graph would have to be saved as an image first prior to bringing it into the New/Report interface (based on my limited testing).

Thanks!

Keith