This document describes various Entire Output Managements setups for the processing of binary documents - with and without the Open Print Option (OPO). It covers the following topics:
For general information on the processing of binary documents, see the section Processing of Binary Data in the Concepts and Facilities documentation.
There are three possible ways of setting up an environment that integrates binary data of UNIX and Windows computers with Entire Output Management:
using OPO with a Windows printer driver,
using OPO without a Windows printer driver,
using the file system without OPO.
The above diagram shows that any Windows application can produce any output that is bound to a printer destination using a Windows printer driver. OPO can be put "behind" this printer driver acting as a Windows printer port monitor to redirect these outputs to Entire Output Management. No user script is required; the Entire Output Management monitor does not even need to know the machine. No further Software AG runtime environment (besides the EntireX mini-runtime) is required on the Windows computer.
The second way to use OPO for routing data to Entire Output Management is to forward data from files to OPO directly, that is, without using a printer driver. In this case, instead of printout pages in the hardware-dependent printer language, the file format itself is transferred to Entire Output Management:
This construction will take a file and forward it to the OPO client,
which will encode the data and send them to Entire Output Management as a
binary file of the original type. The pipe function of Windows is used to pass
the data to the OPO client nomrpt.exe.
The script can be part of a Windows user application, a Microsoft Word macro, or a simple command line like:
type filename.filetype | nomrpt.exe
The third setup is to omit OPO completely if binary files are to be transferred to Entire Output Management which are filed to a UNIX or Windows directory that is owned by Entire Output Management:
This requires a UNIX node and predefined report definitions in Entire Output Management depicting which directories are to be viewed and handled by the monitor of the respective source system. The directories will be scanned synchronously in each Entire Output Management monitor cycle.
The first two setups are asynchronous. Even if the Entire Output Management monitor is not active, the data will be transferred to an Entire Output Management container file from which the Entire Output Management monitor will then receive the documents. The only prerequisite is that the Entire Output Management RPC server is active. The first setup will not require any intermediate files. Even the second setup will put the data into the Entire Output Management container directly without the requirement to manage the files on Entire Output Management-owned directories of the source system.
The main difference is that the first setup will store formatted printout pages with all device-dependent properties in Entire Output Management, whereas the second and third setups will forward the original file to Entire Output Management which can be automatically archived/distributed as required. Each document can then be reprinted using the corresponding application on the target system (which in fact could also be the source system).
The first setup requires the layout of the printout and the used hardware to be defined before the document is transferred to Entire Output Management. This cannot be changed afterwards, because the printout data contain all formatting commands of the Windows printer driver. The other setups can be used to store files in Entire Output Management with the ability to decide where to print and which layout is to be used at the time when the document is printed out of Entire Output Management.
If the second or third setup is used, it will not be possible to printout a binary file to a printer directly, because Entire Output Management does not know the binary format of the file. However, the output converter function (see the description of printer type DISKUNIX) of Entire Output Management is able to invoke the print function of an application on the target system which can do the job. This is the way to have the printout of binary files controlled by Entire Output Management, or to convert binary data on the target system for subsequent processing.
The following examples are all based on the following assumptions:
An Entire Output Management installation is active on a mainframe or a UNIX system.
The source system of the documents is a Windows PC called "win"
with Entire System Server UNIX installed and a service npr_win
being active.
The target system for the output of documents is a UNIX sample
system called "unix" where the Entire System Server UNIX service
npr_unix is active.
The following cases are covered:
Convert any Windows printouts to PDF and store them as PDF files in Entire Output Management.
Entire Output Management can read binary files from UNIX or Windows directories. This feature can be used to fetch all PDF files from a directory owned by Entire Output Management.
Define a report as follows:
**** ENTIRE OUTPUT MANAGEMENT ****
User ID XYZ - Report Definition >Unix Identification -
Report
Name .............. GET-PDF__________________
Unix Attributes
Node Name ......... npr_win_____ Read-binary... B
Path:
/output/
and Files ......... *.pdf________________________________________
_____________________________________________
_____________________________________________
_____________________________________________
_____________________________________________
|
By using this report definition the Entire Output Management
monitor will look for PDF files in c:\output of the specified
Windows PC regardless of whether Entire Output Management runs in a mainframe
or a UNIX environment.
In order to convert the required printouts to PDF format, a PDF
converter must be used. Customize a PDF converter which is installed as a
virtual printer and which writes the resulting PDF file to the directory
c:\output.
Now you can use the print function of any Windows application by printing on the created printer. The output will be converted to PDF, and the Entire Output Management monitor will load the PDF files for further processing.
Microsoft Word documents are saved to the directory
c:\output. They have to be converted to PDF and then transferred
to Entire Output Management as PDF files.
Use the input converter feature of Entire Output Management. Assuming the PDF converter printer profile "NOM-Printing" is available and the Entire Output Management report "GET-PDF" (as defined in Example 1) is active, the following report will instruct the Entire Output Management monitor to convert Word documents to PDF and load them into Entire Output Management:
**** ENTIRE OUTPUT MANAGEMENT ****
User ID XYZ - Report Definition >Unix Identification -
Report
Name .............. DOC2PDF__________________
Unix Attributes
Node Name ......... npr_win_____ Read-binary... B
Path:
/output/
and Files ......... *.doc________________________________________
_____________________________________________
_____________________________________________
_____________________________________________ |
Enter the following jobcards:
**** ENTIRE OUTPUT MANAGEMENT ****
User ID XYZ - Report Definition >Printing Attributes -
Report
Name .............. DOC2PDF__________________
Hold Logic ........... _
Printers ............. ________ ________ ________ ________ ________
Copies ............... ___ ___ ___ ___ ___
Separator Pages
Start ............. ________
End ............... ________
Copies ............ ___
Length ............ ___
Style.. ______________________________________________________________
Jobcards
input-cmd=""C:\Program Files\Microsoft Office\OFFICE11\WINWORD.EXE"
&f /q /n /mNOMPrinting"____________________________________________
___________________________________________________________________ |
Add the following macro "NOM-Printing" to Microsoft Word, using the Visual Basic editor:
Sub NOMPrinting() Dim printerName As String Dim CurrentDoc As Word.Document Set CurrentDoc = ActiveDocument Set printerName = Trim$(Left$(ActivePrinter, _ InStr(ActivePrinter, " on "))) ActivePrinter = "NOMPrinting" ActiveDocument.PrintOut ActiveDocument.Close ActivePrinter = printerName End Sub
The following will happen:
Entire Output Management will recognize the ".doc" file in
the directory c:\output.
The monitor will activate the report DOC2PDF and execute the input command in the jobcards fields. Afterwards the ".doc" file will be deleted and not processed further by Entire Output Management.
The command (without the outer quotation marks) will be
executed on the Windows source system "win" (where the c:\output
directory resides).
There Microsoft Word will be invoked without splash screen (/q), without opening a new document (/n) but opening the recognized ".doc" file (&f) and executing the macro "NOM-Printing" (/m). If it is called using a batch user of this Windows system, the user will not see any part of the execution of this function.
The Microsoft Word macro will set the current default printer to "NOM-Printing" and print the document using the PDF converter. Then the former default printer will be restored.
Entire Output Management will get the created PDF file with the report "GET-PDF" from Example 1.
Entire Output Management will replace "&f" with the current file name.
No user intervention is required, and the procedure will be
carried out for all Word documents that have been filed in
c:\output. Everything is triggered by the Entire Output Management
monitor on a mainframe or on UNIX.
Print a PDF file that has been stored in Entire Output Management on a real printer.
Ensure that the product Ghostscript is installed.
Create a logical printer "PRTPDF" of type NATUNIX with the following special attributes:
**** ENTIRE OUTPUT MANAGEMENT ****
User ID XYZ - Logical Printer >Special Attributes -
Logical Printer
Name ............. PRTPDF__
Description ...... Print a PDF file
Attributes
Formfeed ..........
Linesize ..........
Max-Pages .........
Output-Target ..... 1
Pagesize ..........
Printer-Name ...... gs -sDEVICE=printserver01:printer09
Print Method ...... tty
Profile ...........
Trace ............. 0
|
Ensure that the product Ghostscript is installed on the target system "unix".
Create a logical printer "PRTPDF" of type DISKUNIX with the following special attributes:
**** ENTIRE OUTPUT MANAGEMENT ****
User ID XYZ - Logical Printer >Special Attributes -
Logical Printer
Name ............. PRTPDF__
Description ...... Print a PDF file______________
Attributes
command ........... gs
filename ..........
filetype ..........
logpath ...........
Opt1 .............. -sDEVICE=printserver01:printer09
Opt2 ..............
Parm1 .............
Parm2 .............
Parm3 .............
Path .............. /tmp
Server ............ npr_unix
Trace ............. 0
|
If a binary active report containing a PDF file is printed on the
printer PRTPDF, a file filename.pdf
will be written to the directory /tmp of the UNIX computer on
which the Entire System Server UNIX node npr_unix is active, where
filename is the origin file name of the file.
Ghostscript will send the printout to the printer printer09 on the
printer server printserver01.
Print Microsoft Word documents on a virtual printer which stores the printed pages (not the file) in Entire Output Management for later printing on a real printer. Pass the document properties to Entire Output Management for viewing with the meta data key (PF2).
Use OPO to collect the data. As the collection is not triggered by the Entire Output Management monitor, the printout will be asynchronously transferred and saved in the defined Entire Output Management container file, regardless of whether the Entire Output Management monitor is active or not.
The advantage of storing printouts rather than files is that the decision as to how the printout is to be formatted, which printer tray is to be used, whether the printout should be printed in colour etc. can be made at initiation time of the printouts (on the client side).
The disadvantage is that after this decision has been made, the printout and its attributes can no longer be changed. For instance, the printer type has to be the same as requested by the client.
OPO can transfer meta data (in this case the properties of a Word
document) using XML files. The following Word macro reads the properties,
creates an XML file that complies with OPO and saves it as
word.xml in the Windows temp directory. Then it prints the
document on the printer "PrintToNOM" which is defined as any printer with a
printer port of type OPO (see
Installing the Open Print
Option for details):
Sub PrintToNOM()
Dim prop As DocumentProperty
Dim propName As String
Dim propString As String
Dim CurrentDoc As Word.Document
Dim DocName As String
Dim DocType As String
Dim DocPath As String
Dim printerName As String
Set CurrentDoc = ActiveDocument
Documents.Add
If InStr(CurrentDoc.Name, ".") > 1 Then
DocName = Left(CurrentDoc.Name, InStr(CurrentDoc.Name, ".") - 1)
DocType = Mid(CurrentDoc.Name, InStr(CurrentDoc.Name, ".") + 1)
Else
DocName = CurrentDoc.Name
DocType = ""
End If
DocPath = Replace(CurrentDoc.Path, "\", "/")
With Selection
.InsertAfter "<?xml version='1.0' ?>"
.InsertParagraphAfter
.InsertAfter "<metadata>"
.InsertParagraphAfter
.InsertAfter " <filename>" & DocName & "</filename>"
If DocType <> "" Then
.InsertParagraphAfter
.InsertAfter " <filetype>" & DocType & "</filetype>"
End If
If DocPath <> "" Then
.InsertParagraphAfter
.InsertAfter " <path>" & DocPath & "</path>"
End If
End With
On Error Resume Next
For Each prop In CurrentDoc.BuiltInDocumentProperties
propString = ""
On Error Resume Next
propString = prop.Value
On Error GoTo skip1
propName = Replace(prop.Name, "Number of ", vbNullString)
If InStr(propName, "(") > 1 Then
propName = Left(propName, InStr(propName, "(") - 1)
End If
propName = Replace(propName, " ", "_")
propString = Replace(propString, "<", "-")
propString = Replace(propString, ">", "-")
propString = Replace(propString, """", vbNullString)
propString = Replace(propString, "'", vbNullString)
propString = Replace(propString, "\", "/")
Trim (propString)
If Len(propString) > 0 Then
With Selection
.InsertParagraphAfter
.InsertAfter " <" & propName & ">"
.InsertAfter propString
.InsertAfter " </" & propName & ">"
End With
End If
skip1:
Next prop
On Error Resume Next
For Each prop In CurrentDoc.CustomDocumentProperties
propString = ""
On Error Resume Next
propString = prop.Value
On Error GoTo skip2
propName = Replace(prop.Name, "Number of ", vbNullString)
If InStr(propName, "(") > 1 Then
propName = Left(propName, InStr(propName, "(") - 1)
End If
propName = Replace(propName, " ", "_")
propString = Replace(propString, "<", "-")
propString = Replace(propString, ">", "-")
propString = Replace(propString, """", vbNullString)
propString = Replace(propString, "'", vbNullString)
propString = Replace(propString, "\", "/")
Trim (propString)
If Len(propString) > 0 Then
With Selection
.InsertParagraphAfter
.InsertAfter " <" & propName & ">"
.InsertAfter propString
.InsertAfter " </" & propName & ">"
End With
End If
skip2:
Next prop
With Selection
.InsertParagraphAfter
.InsertAfter "</metadata>"
End With
ActiveDocument.SaveAs _
FileName:="C:\Program Files\Software AG\Open Print Option 3.2.0\word.xml", _
FileFormat:=wdFormatText
ActiveDocument.Close
Set printerName = Trim$(Left$(ActivePrinter, _
InStr(ActivePrinter, " on ")))
ActivePrinter = "PrintToNOM"
ActiveDocument.PrintOut
ActivePrinter = printerName
End Sub
Save this macro "PrintToNOM" using Microsoft Word's Visual Basic editor.
This macro prints on the printer "PrintToNOM".
In Windows, create a printer "PrintToNOM" which is linked to OPO,
and configure the OPO port to use word.xml as the XML file for
meta data.
Executing the macro will collect all meta data Microsoft Word
supplies, write them into word.xml, and print them on the printer
"PrintToNOM", which will pass the printed pages and the meta data to Entire
Output Management.
Use the print function of any Windows application to create AFP data. Store these data in Entire Output Management for later printing on AFP printers.
Install a Windows AFP printer, such as the IBM AFP driver for Windows.
Link it to an OPO printer port (according to the OPO documentation).
This will store AFP data in Entire Output Management which can be sent to an AFP printer.
Store XML documents in Entire Output Management; at printing time, these documents are to be formatted and rendered to several different documents.
Create the desired XML documents with any application.
Transfer them to Entire Output Management, using the UNIX identification feature as text files.
Create several printers of type DISKUNIX that forward the documents to an XML renderer which takes care of the final formatting. You may consider using the Apache Formatting Objects Processor (Apache FOP) for the final formatting.