[ Up To Index ]
Menu IVIEW, option 1:
This display is used to add or change an archive definition, although one can not
change the meta data fields after the archive is created.
*DATE to include QDATE *TIME to include QTIME *INDEX01 - *INDEX20 to include the current values of these meta data fields
*RETAIN Retain in Outqueue *ORIGINAL Archive Original *SYSTEM Archive Post Processing *NONE Do Not Archive
with current software and should be set to N.
This will impact what profile owns the spool file post-processing.
*SYSTEM Use iView System Profile *SPLFOWNER Use Splf Owner Profile
iDocs Application: If you want the spool file processed through iDocs before archiving specify the application here. If specified what is archived is a laser document, else it is a pdf document made from the text spool file. Product: Specify IDOCS to create a laser document using the iDocs Suite. Otherwise leave blank. This field is used for integrations with other document products. Storage Format: Specify the document type of the file. *PDF is the usual selection due to ease of use with a browser. PDF is also the front end default and any other selection may require front end configuration changes.
*PDF *USERASCII PDF Conversion *TIFF Tiff Image
The meta data fields are defined by their position in a *SCS spool file.
Seq#: You can change the order of the columns of the meta data table by keying a different sequence number
and pressing <enter>.
Page#: Use keywords *FIRST, *LAST, *ALL, or a specific page number to specify from which page the meta data
value is scraped.
No. Pgs Indexed: Key the number of pages from which spool text is scraped and concatenated to form the
meta data for the meta data field. Left blank, 1 page is scraped unless *ALL pages is specified.
Sorting is specified as it is in iDocs:
1 Primary Sort Ascending 2 Primary Sort Descending 3 Secondary Sort Ascending 4 Secondary Sort Descending 5 Third Sort Ascending 6 Third Sort Descending 7 Forth Sort Ascending 8 Forth Sort Descending 9 Fifth Sort Ascending
Since this is text against which users will search in a browser, the normal practice
is to define short, one line text fields as meta data. Fields such as customer name, customer number, etc.
You can define text blocks as meta data but the searching dynamics should be considered.
Meta data is stored in the meta data file, having the same name as the archive application, in the iView library.
Bursting works as it does in iDocs and as one would intuitively expect.
A path is defined to create a directory structure in the archive. The directories are in the IFS and are real, not virtual. The archived document is placed in the path created by the path definition.
At archive time the engine creates a file path using the specified meta data fields, creates the directories if they are not present, then places the archived document in the path.
Example:
Archive application is INVOICES.
*PATH01 is INDEX01, which evaluates to 100100 at archive time for a specific document.
*PATH02 is INDEX02, which evaluates to 2013JANUARY at archive time.
The iView IFS root is /iview6 ( data area DSIVIEWDIR ).
The archived document ( named 01000010001.pdf ) is placed thus:
/iview6/invoices/100100/2013JANUARY/01000010001.pdf
[ Up To Index ]