IXOS Server PDF

IXOS Project on Document Imaging
H:\00amswebsite\amsweb_bkup_January23_2002\overview \IXOS_documentation.doc
-1-
Table of Contents
SCOPE............................................................................................................................................................................. 2 W HAT IS IXOS?............................................................................................................................................................ 2 HOW WAS IXOS USED BY DIS? ................................................................................................................................. 2 CONSULTANT S REPORT ............................................................................................................................................. 2 TRAINING AND REFERENCE M ATERIAL.................................................................................................................... 2 1.1.1 IXOS Documentation............................................................................................................................2 1.1.2 IXOS Courses.........................................................................................................................................2 1.1.3 SAP Courses...........................................................................................................................................2 1.1.4 Typical Roles..........................................................................................................................................2 IXOS EXPERT SERVICE CENTER (ESC).................................................................................................................... 2 A RCHIVING SETUP ....................................................................................................................................................... 2 1.1.5 UofTs Setup...........................................................................................................................................2 DIS IMAGING PROJECT ................................................................................................................................................ 2 1.1.6 List of Basis Tasks.................................................................................................................................2 1.1.7 Receipts Document Type Installation ................................................................................................2 DIS: INSTALL PLANS: .................................................................................................................................................. 2 PROBLEMS LOG ............................................................................................................................................................ 2 CONFIGURATION OF DIS IMAGING DOCUMENT S.................................................................................................... 2 OPERATIONS.................................................................................................................................................................. 2 A UTHORIZATIONS ........................................................................................................................................................ 2 FIREWALL A CCESS FOR VIEWER AND SCAN STATION (ONLY ALLOW UNIVERSITY OF TORONTO IP ADDRESSES) .................................................................................................................................................................. 2 ORACLE LICENCE ......................................................................................................................................................... 2 IXOS VIEWER............................................................................................................................................................... 2 1.1.8 Win95 Install notes.......................................................................... Error! Bookmark not defined. 1.1.9 NT 4.0 Installation of Scan Client and V4.1 notes..........................................................................2 IXOS SERVER AND JUKEBOX HARDWARE............................................................................................................... 2 UPGRADE CONSIDERATIONS....................................................................................................................................... 2 1.1.10 Oracle Upgrade must be done by IXOS ............................................................................................2 1.1.11 Change of ixds/ixworm/ixar (Oracle user) password back ...........................................................2 APPENDIX......................................................................................................................................................................2 A PPENDIX A: SCOPING DOCUMENT .......................................................................................................................... 2 A PPENDIX B: RELEVANT OSS NOTES ....................................................................................................................... 2 A PPENDIX C: CONSULTANT S REPORT ..................................................................................................................... 2 A PPENDIX C: SCANNING M ANUAL AND PROCEDURES........................................................................................... 2 A PPENDIX D: HARDWARE SIZING DOCUMENT ........................................................................................................ 2
-2-
Background
Many of the supporting documents used by the Development Information System (DIS) traditionally have been stored in paper format in files. Advancement staff often accesses this information and there is a need to have this information quickly available. Storing this information online eliminates the problem of locating missing files. As the Division of University Advancement (DUA) has a number of divisional offices located across the campus, electronic storage facilitates easy access to documents to users who are not located in the central Development office.
Scope
To provide DIS users with desktop access to donor or prospect information previously only available in paper format. Using the IXOS-Archive Imaging Solution, DIS users will be able to access scanned images of documents that relate to prospects or donors through the DIS graphical user interface. At the conclusion of phase I of the project, users will be able to access the following key documents through DIS: gift agreements naming approvals administrative digests award summaries Tax receipts for donations.
DIS will have to be configured for IXOS. The complete scoping document is available in Appendix A.
-3-
What is IXOS?
IXOS is a document management system that handles both document imaging and data archiving, integrating this information into SAP applications. The documents are then accessible via SAP transactions. Imaged data are stored on an archive server. The following diagram illustrates this process:
-4-
The following is a simple representation of a typical IXOS configuration:
-5-
Note: See the sections on Archiving Set-up, Firewall Access, IXOS viewer and the IXOS server and jukebox hardware for more detailed information on the configuration.
How was IXOS used by DIS?

DUA decided to scan and image frequently used documents and link those documents to DIS in order to better manage donations and donor relationships. These documents are: gift agreements naming approvals administrative digests award summaries Tax receipts for donations. Some of the advantages to implementing IXOS within the DIS environment were: Costs would be reduced as a result of lower photocopy costs, reclaimed space for files and reclaimed time through efficiency; Users would have immediate access to documents when handling phone inquires from donors; The viewing of documents could be handled via SAP and the Internet and documents could also be distributed via e-mail. IXOS supports a number of processing scenarios for document management that involve scanning: Early archiving Late archiving, also known as scan and store
-6-
Late archiving with Workflow Late archiving with Barcode.
Late archiving of scanned documents was used in the DIS implementation. The following illustrates the process of archiving a gift agreement:
Documents created through SAPScript can also be archived (Archiving of Outgoing Documents). The receipting projected was implemented using the Archiving of Outgoing Documents. Tax receipts may now be generated for donations via SAPScript and the output associated with each payment. Users can then view an image of the actual receipt at any time.
-7-
Technical Application
Consultants Report
A consultant from IXOS was brought in to evaluate the project requirements and develop a recommendation for the implementation. The complete report is contained in Appendix C. The report is a very good overview paper on the DIS/IXOS implementation. Overview:
! ! ! ! ! ! ! ! ! !
Standard processing scenarios usually applied to IXOS A description of IXOS and how it is typically used Information on the IXOS viewer Results of the analysis of the DIS requirements A guide to ArchiveLink enabling DIS Document Security Logical archives and retention periods Scanning IXOS architecture Archive Client Workstation.
Training and Reference Material
1.1.1
IXOS Documentation
All of the IXOS documentation is located on the AMS server in DAMS1\Vol1\Shared\IXOS (I:\AMS\). The documentation contains guides and help for: Administration Client Install Customizing Doculink Exchange Link Working with EnterpriseScan (view user) Viewing, Scanning and Archiving (scan user).
-8-
1.1.2
IXOS Courses
A complete listing of courses provided by IXOS is available on their web site. Ken Chamberlain from CNS was sent to the IXOS-Archive Administration course as this course was recommended for archive administrators.
1.1.3
SAP Courses
ABAP programmers should take the SAP Object Oriented Programming course.
1.1.4 1.1.4.1
Typical Roles IXOS Administrator
Knowledge and Background: UNIX and SAP experience TCP/IP, RFC communication Networking experience Client/Server experience Responsible for: Day to day monitoring of the back end of the IXOS/SAP product Communications between the servers (IXOS & R/3), Jukebox and scan client Monitoring jobs within the archive server Monitoring and maintaining WORMS and logical archives Networking and communication issues and errors. Adding new logical archives and configuring SAP. Ken Chamberlain from CNS is the current IXOS administrator for UofT. 1.1.4.2 Functional Administrator
Knowledge and Background: Business process and SAP super user type of experience Configuration experience Responsible for: Day to day monitoring of the front end of the IXOS/SAP product Software installation of the viewer as needed Configuration of new document types and logical archives on SAP (Developers) Contact person for end users for any issues and acts as a liaison to IXOS. Anne Joiner is the current Functional administrator. 1.1.4.3 Scanning Administrator
Responsible for: Deleting and reassigning Links within the SAP system Scan Client configuration
IXOS Expert Service Center (ESC)
-9-
The IXOS Expert Service Center (ESC) is an online information system that supplements the support services described in the support contract and provides information concerning IXOS products around the clock. Current Release Notes, documentation, technical hints on installation, administration, troubleshooting and regular news updates about the latest developments concerning IXOS products are available on the ESC site. Users may also submit new questions to the help desk or open up support cases. The ESC site is located at www.ixos.com/esc. When setting up a new ESC account, the installation number must be supplied. The installation number for the University of Toronto is A092618. E-mails may also be sent directly to archive-support@ixos.com. Any e-mail messages sent to archive-support@ixos.com must include ones name, company, installation number and an indication that its a new case.
- 10 -
Archiving Setup
1.1.5 UofTs Setup
Overview: Archive HOST IXOS Version DISK Host name is archie, connected to the BFD. We are running base IXOS archive for R3 V4.1A patch level 0. Installation completed Feb 22, 2001. Now at version 4.2A. 9Gb SSA disk volumes dedicated to the OS and SWAP. 2 9Gb SSA disk volumes STORM backup, Oracle archive logs and IXOS/Oracle software (Mostly empty, 8Gb free) 9Gb SSA disk currently unused 35Gb SSA RAID-5 device IXOS (Mostly used, 12Gb free) Oracle data, Oracle index, buffers, cache, data pipeline, STORM filesystem CACHE Our cache is on the RAID, is about 4Gb in size and is used by all Logical Archives in retrieving documents. Cache is used on a FIFO basis by documents retrieved from WORM (or CDROM) media. We currently have a 5Gb buffer named buffer1 Pools can be of three types: Hard disk, WORM or CDROM. Currently we have logical archives D1, D2, T1 and T2 . Only by using different logical archives can you guarantee media separation. D1 and D2 are production archives and T1 and T2 are test achives. The exchange directory is a UNIX filesystem owned by the SAP db server and shared to the archive server. The data pipeline is where documents go during the archiving process. Buffers, Hard Disk pools and Oracle log and data files are backed up by the operating system backup tool. (TSM in our case). IXOS requires an offline backup of most of its filesystems.
BUFFER POOLS LOGICAL ARCHIVES
EXCHANGE DIRECTORY DATA PIPELINE BACKUP
- 11 -
U of T Archiving Setup Archive HOST Host name is archie, connected to the BFD. IXOS Version We are running base IXOS archive for R3 V4.1A patch level 0. 2001
Installation completed Feb 22,
DISK 2 9Gb SSA disk volumes dedicated to the OS and SWAP. 2 9Gb SSA disk volumes STORM backup, Oracle archive logs and IXOS/Oracle software (Mostly empty, 8Gb free) 3 9Gb SSA disk currently unused 35Gb SSA RAID-5 device IXOS (Mostly used, 12Gb free) Oracle data, Oracle index, buffers, cache, data pipeline, STORM filesystem CACHE Our cache is on the RAID, is about 4Gb in size and is used by all Logical Archives in retrieving documents. Cache is used on a FIFO basis by documents retrieved from WORM (or CDROM) media. BUFFER We currently have a 5Gb buffer named buffer1. We also have a 2Gb buffer named buffer2. They are both on the RAID. Buffers can be shared by Logical Archives. All WORM and CDROM pools must have an associated buffer. The reasons to have multiple buffers are: different buffering options OR to make different logical archives independent. Examples of buffer options: Required available space: Ive chosen 1% or 50 Mb. Cache before purging -- only recommended in early archiving scenarios To clear archived documents older then x days: Ive chosen to clear archived documents after 180 days. When (or if) the buffer purge jobs runs: Ive chosen to run all the jobs daily Monday to Friday at 7AM. Examples of logical archives that you might want independent from each other are image archives and SAP data archives, because a SAP data archive will move much larger files into the buffer, potentially filling it up. A full buffer doesnt accept any archives until something happens to make space in it, such as the purge job. At this writing buffer1 has used 7Mb and contains 78 documents of which 56 are images. Images seem to range from 10Kb up to 400Kb. Printlists (so far) are much smaller. Buffer2 has yet to be used. IXOS suggests keeping the buffer(s) nearly full. This allows hardware maintenance to jukeboxes not to interfere with most document retrieval (especially in early archiving scenarios).
H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Created by: Ken Chamberlain Date last changed: Mar 30, 2001
12
POOLS Pools can be of three types: Hard disk, WORM or CDROM. Both WORM and CDROM pools need a BUFFER (access times of WORM and CDROM are too high). In our case, only WORM or Hard disk pools are possible. Annotations and Notes in a logical archive can be directed to a different pool than the default. IXOS suggests using hard disk pools for annotations and notes. The reason being that an image retrieval with annotations and notes (the default in the viewer) can then only require one WORM or CDROM mount. Both WORM and CDROM pools have an associated write job.
13
I have created a WORM pool t1_pool which uses buffer buffer1 and has a (currently disabled) write job scheduled Monday to Friday at 17:00. This pool contains one WORM, labeled T1_20010222_A_001 (side A) and T1_20010222_B_001 (side B). No backup WORMs are allocated to this pool.
I have created a WORM pool d1_pool which uses buffer buffer2 and has a write job scheduled Monday to Friday at 18:00. This pool contains one original WORM and one backup WORM, both labeled D1_20010329_A_001 (side A, side B is uninitialized). I have created a WORM pool d2_pool which uses buffer buffer2 and has a write job scheduled Monday to Friday at 19:00. This pool contains one original WORM and one backup WORM, both labeled D2_20010329_A_001 (side A, side B is uninitialized). WORM sides (partitions) are given write priorities. IXOS suggests (for performance reasons) that the two sides of a single WORM volume not be given sequential priority. IE. Write Volume 1 side A, then Volume 2 side A, then Volume 1 side B and finally volume 2 side B. IXOS recommends sticky labels never be used on WORM media, preferring magic marker hand written labels colour coded for primary and backup set(s) media. LOGICAL ARCHIVES Currently we have logical archives D1, D2 and T1. Only by using different logical archives can you guarantee media separation. The retention period concept is not implemented in the IXOS H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Created by: Ken Chamberlain Date last changed: Mar 30, 2001 14
software. If you wish to destroy media (for liability reasons) after a certain period of time, you have to physically mark the media (with the fill date) when it becomes full and periodically physically examine all media to see if it is time to destoy. This works best with CDROM since CDROM is written all at once whereas WORM is written a little at a time. It is possible to remove a volume, be it hard disk, CDROM or WORM from the IXOS database. I dont think the SAP database(s) are updated to reflect this. This is supposed to be handled by data archiving. EXCHANGE DIRECTORY The exchange directory is a UNIX filesystem owned by the SAP db server and shared to the archive server. It is only used for printlists and data archiving. Currently named
/exchange/<SID>/archive and is 160Mb mirrored.
DATA PIPELINE The data pipeline is where documents go during the archiving process. It is both a physical area on disk (2Gb in size on the RAID) and software concept. While a document exists in the data pipeline, its attributes include the steps that still must be carried out until that document is fully archived. BACKUP Buffers, Hard Disk pools and Oracle log and data files are backed up by the operating system backup tool. (TSM in our case). IXOS requires an offline backup of most of its filesystems. Currently IXOS comes down at 23:00 Sunday to Friday for its offline backup which takes around half an hour. WORM media is backed up to WORM media. When we have WORM media we wish to backup we need to insert backup WORM media into the library and label it identical to its primary media, but indicate to IXOS that it is to be used for backup. An IXOS backup job, run periodically, copies each primary volume to its identically labeled backup volume on a volume by volume basis. OFFSITE WORM BACKUP using a single IXOS server If you wish to store backup WORM media offsite, IXOS recommends using two sets of backup media. Label each volume on its outside jacket with its label in a different colour for primary, backup set 1 and backup set 2. The internal labels are all identical. Prior to the first backup cycle, all primary volumes and backup set 1 volumes are in the library. A backup job local_backup is scheduled after all the (daily) write jobs complete. H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Created by: Ken Chamberlain Date last changed: Mar 30, 2001 15
An operator can check that the backup job has completed successfully (right click the job and select protocol) and then the operator must eject each backup volume (on the device tab, select WORM on the left and on the right select a backup WORM right click and select eject, go to the library and remove the volume, close the door and repeat with the next backup volume). The ejected volumes are taken offsite and the next set is returned onsite. The operator then inserts each returned backup media into the library (on the devices tab, select WORM on the left and right click on white space on the right and select insert, go to the library insert a volume and close the door, repeat with the next returned volume). If this seems awkward it is possible to network two (or more) archive servers together and then backup from one server to another remotely situated archive server. JOBS
16
17
DIS Imaging Project

1.1.6 List of Basis Tasks
Please see J:\AMS\IXOS\Plan\Technical.xls, and select the Basis tab.
1.1.7
Receipts Document Type Installation
Please see J:\AMS\IXOS\Plan\Technical.xls, and select the Receipts Setup tab.
DIS: Install Plans:

The complete plan is located at J:\AMS\IXOS\Plan\Technical.xls. The file contains a list of the required tasks, who was responsible for the task, when it was required and any additional comments about each task. 1.1.7.1 QNA
See the QNA tab in J:\AMS \IXOS\Plan\Technical.xls.
1.1.7.2
AMS
See the AMS tab in J:\AMS\IXOS\Plan\Technical.xls.
18
Problems Log
Description of Problems
Action Taken
OSS Msg
Compone nt
Comments
Error in ArchiveLink-DLL viewer not communicating with IXOS Server
regedit.exe Folder IxArchivRPC must contain: Proxy1 "archie,poort.utcc.utoronto.c a,0" etc Add "Enable=0" code to the [Cache] options in c:\windows\alviewer.ini file applied OSS note 401670 on May 22/01 N/A
Depositing of scanned documents in the c:\windows\alviewer.ini file Incorrect IXOS Archive Time - Imaged Documents Archiving Time is based on GMT no GMT -5 hrs. Print list time is okay There are entries in the Confirmation error queue in Transaction OAM1 Links Pop-up Screen shows "--unknown--"
57961
BC-SRV ARL
tested by Wes Moon in FIS and moved to production transport FISK937021
Caused by doing RFC Connection Test
There is no field to store the userid in the link tables TOA01-03. Only in print list table TOADL does the userid get stored. Corrected by Viewer 4.2A
Receipts Forms overlay not being displayed by viewer 3.5DV Investigate Restriction of Annotations and Notes to Small Group
Viewer 4.2 has profiles Wes investigating
Profiles can be created in IXOS server by User group defining restrictions. There is a default profile I.e. all users have annotations turned off and then set-up a user group with annotation turned on. (re: Ken's email dated May 31/01)
An ODMA action could not be completed for DMS or Message: G"\WIn32Appt\SAPgui 45B\sapgui\AFIS010 PDF could not be opened for writing
archive server definition for new 4.2A viewer was corrected
19
Configuration of DIS Imaging Documents

ROADMAP for configuring new objects: Create new Business Objects (transaction SWO1).
! ! ! ! ! ! !
Menu path: Tools->Business Documents-> Transaction: SOA for Business Documents Administration Create a new document type: - table TOAVE Menu path: Tools->Business Documents->Document Types->Global Document Types Transaction: OAC2 for Global Document Types Create a Workflow (WFL) Document Type: - table TWFDB_C Menu path: Tools->Business Documents->Document Types->WFL Document Types Transaction: SOA0 for WFL Document Types Create a new Link Entry - table TOAOM_C Menu path: Tools->Business Documents->Basic Settings-Links Transaction: OAC3 for Link Entries Define Default Settings - Table TOAPRS_C and TOAPRE_C Menu path: Tools->Business Documents->Miscellaneous->Default Settings Transaction: OAWS for Default Settings Create a detail line for the Presetting ID:
Once all of the above steps above have been completed, the document type is now available for use. Users can access the document types for scanning through the following menu path: Office->Business Documents->Move or transaction OAWD.
New logical archives are created by the Archive administrator (e.g. T1 and D1). The test archives (T1 and T2) should be used in the test and QA systems. Additional information on configuring objects is available in the consultants report in Appendix A.
20
Configuration of DIS Imaging Documents Create new Business Objects (transaction SWO1) (Note: done by IXOS programmer - transport FISK935286) ZZDF1OIXOS IXOS : Object Type for ZZDF1 ( Pledge Doc no ) ZZDP4OIXOS IXOS : Obj for ZZDP4 (Project No.) ZZDR1OIXOS IXOS : Object for ZZDR1 ( Receipt No.) Configuration for DIS Imaging Documents (Note: done by John Walls, Allison, Paul, Anne - Transport FISK935468) Menu path: Tools->Business Documents-> Transaction: SOA for Business Documents Administration Create a new document type: - table TOAVE Menu path: Tools->Business Documents->Document Types->Global Document Types Transaction: OAC2 for Global Document Types Select Global Document Types Select New Entries Enter the new document type, description and document class. E.g. Document type: ZDI_GIFT Description: Gift Agreement Document Class: FAX Save
H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001
21
Create a Workflow (WFL) Document Type: - table TWFDB_C Menu path: Tools->Business Documents->Document Types->WFL Document Types Transaction: SOA0 for WFL Document Types Select WFL Document Types Select New Entries Enter the new document type and object type (created in step one, create objects) E.g. Document type: ZDI_GIFT Object Type: ZZDF1OIXOS Task: do not have to enter anything for this Method: do not have to enter anything for this The following Workflow Document Types were created: ZDI_ADMIND Administrative Digest ZZDP4OIXOS ZDI_AWARD Award Record ZZDP4OIXOS ZDI_GIFT Gift Agreement ZZDF1OIXOS ZDI_NAMAPP Approval Letter ZZDF1OIXOS ZDI_SUMSHE Summary Sheet ZZDP4OIXOS ZDO_RCPT Receipt ZZDR1OIXOS Save
22
Create a new Link Entry - table TOAOM_C Menu path: Tools->Business Documents->Basic Settings->Links Transaction: OAC3 for Link Entries Select Link Entries Select Change Select New Entries Enter the new document type and object type (created in step one, create objects) E.g. Object Type: ZZDF1OIXOS Document type: ZDI_GIFT Archive: T1 S(tatus): X (X activates it) Link: TOA01 (this is the link table) Ret Per: leave it blank as it is primarily for informational purposes
Save
23
Define Default Settings - Table TOAPRS_C and TOAPRE_C Menu path: Tools->Business Documents->Miscellaneous->Default Settings Transaction: OAWS for Default Settings Select Default Settings Select Change Select New Entries Enter the Presetting ID and Description E.g. PR: ZD01 Long Text:: Pledge Documents Save
Create a detail line for the Presetting ID: Select the line in the table control of the entry just created. Select Entries Select New Entries Enter the Doc type and check the checkbox to Assign and Store. E.g. Doc type = ZDI_GIFT The OT and Agent ID fields can be left blank.
24
SAVE
Once all of the above steps above have been completed, the document type is now available for use. Users can access the document types for scanning through Office->Business Documents>Move or transaction OAWD. Note: When the transports go to production, the pointer to the archive server must be changed from the test archive server (T1) to the production archive server (P1). This can be accessed through Basic Settings->Links. After a client copy to QNA or TNG the archive server will also have to be changed from the production archive server to the test archive server. The table containing this information is TOAM_C.
25
Creating Business Objects
Publish the object: The function module SWU_OBJECT_PUBLISH is used to publish the object id of the new object. Objects are only available to IXOS and the link enabler once they are published. In order to publish an object, this function module must be inserted into PBO section of your application. See SAPMZD28, screen 0400 for an example of publishing an object and archive link enabling a transaction ( module 0400_ixos_publish). To quickly determine if the object exists and has been archive link enabled, set a breakpoint in the function SWU_OBJECT_PUBLISH and run the transaction to be link enabled. Create the business object (SWO1):
Note: Objects cannot be local objects as they must be transportable.
26
Must add IFARCH21, the SAP ArchiveLink Interface to the folder
1) add key fields to the key field folder 2) now some ABAP programming has to be added to Existence Check & Confirm check methods Create a document type for each different archive document category.
27
Add the Workflow Document types which will link the document types to the object types for workflow.
Add the links for the external storage system: 1) links an object and a document type to an logical archive
28
Setup the SAP ArchiveLink Presettings: This screen determines how the document types are grouped in SAP (i.e. like a report tree)
29
How data is scanned in: Menu path to scan documents in
Select the document type to be scanned. Enter the SAP key value for the scan document
30
Viewing the scanned document in DIS: View using the programmed push button or System -> Links Select the document to view and the IXOS viewer will be launched.
31
Forms Overlay for IXOS Viewer (used for images generated through SAPScript) Transaction J8AF
Overview screen
Detail screen for a form
32
Creating a new version of an existing forms overlay: /nJ8AF Select the form and view the detail screen. Select New version from the button bar. Select Assign form pages.
Accept the default options and press ENTER or the CONTINUE button.
33
The two other buttons are now available (Get Scanned Form or Get Form files).
If the document is to be scanned in, then select Get scanned form. If the document is in a file, then select Get form files. The file MUST be a TIF file.
34
Operations
ROADMAP: Archive Server Operations Task MONITORING archie Description Run IXOS Archive Monitor to detect potential problems as early as possible Open the SSH window to archie by double clicking the F-secure SSH ICON on his desktop. OFFSITE BACKUP Archive server archie is backed up by Tivoli Storage Manager (TSM, formerly known as ADSM) Sunday to Friday at 11PM. Any time after the TSM backup is complete, the operator should run the Archive Administration tool (Start> Programs> IXOS-ARCHIVE> Archive Administration) to view the jobs run and whether they were successful or not. In particular make sure that the jobs write_d1_worm, write_d2_worm, Local_backup and Save_Storm_Files ran successfully. FUTURE NOTEWORTHY EVENTS Check if the WORM has filled up by selecting the Archives Tab, selecting each pool d1_pool, d2_pool and t1_pool in turn you will see a display that includes Capacity and Free. When the Free amount goes to Zero there is supposed to be a full indication, possibly in the Status field.
ARCHIVE SYSTEM REQUIREMENTS OF OPERATIONS STAFF
BACKGROUND The University has purchased an archiving system associated with its SAP systems. The archiving system consists of an IBM RS6000 server named "archie" with a SCSI attached IBM jukebox with 2 drives and slots for 52 Write Once Read Many (WORM) cartridges. Each WORM cartridge can store 2.6 Gb on each of two sides. The server is running IXOS archive for R/3 V4.1. Initially the server will store images of document received and produced by DUR, but after the DUR project proves successful there will be much more use of this technology. ASSUMPTIONS Operations staff will need: A Microsoft Window type workstation An X windows system solution for Windows such as Hummingbird Exceed A secure shell implementation with TCP/IP forwarding capabilities such as F-secure SSH SSH access through filter.utcs.utoronto.ca to archie from their Windows based PC. 35
A limited use userid on archie, that can run the "startIxmonview" and hold the SSH IP tunnels open.
MONITORING archie Operations staff will be required to run the IXOS Archive Monitor to detect potential problems as early as possible. The Hummingbird Exceed needs to be running for the following to work. The operator should open the SSH window to archie by double clicking the F-secure SSH ICON on his desktop. After supplying an RSA Identity Passphrase (like a password but uses stronger security technology), he runs the "startIxmonview" command. This results in the following traffic signal like assessment of archies condition.
You will note archie has a green light. Should the traffic light turn yellow or red, pressing the "archie" button will give the operator more details. In any event the archive administrator (currently Ken Chamberlain) should be notified on the next business day. Pressing the archie button produces a window that looks as follows:
H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Created by Ken Chamberlain 36 Date last changed: April 3, 2001
OFFSITE BACKUP The archive server archie is backed up by Tivoli Storage Manager (TSM, formerly known as ADSM) Sunday to Friday at 11PM. Note that IXOS is down during the backup, so expect the archive monitor to show a red light for about half an hour. TSM only backs up the hard disk on archie. The archive server software uses WORM media to backup WORM media. For each original WORM there is a backup WORM (with the exception of the test WORM pool, which at $135 a pop H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Created by Ken Chamberlain 37 Date last changed: April 3, 2001
is deemed unworthy of backup). Every evening all documents archived throughout the day are writen to original WORM media by IXOS jobs. Prior to the TSM backup, an IXOS job runs that backs up the original WORM media to backup WORM media. Any time after the TSM backup is complete, say after midnight, the operator should run the Archive Administration tool (Start> Programs> IXOS-ARCHIVE> Archive Adminitration).
Right click on the "localhost" button and select Connect
Logon with userid aroperator, initially without password (but a password should be established), and select the Jobs Tab.
Right click on any of the jobs and select Protocol and you get a listing of all jobs run to date.
Note the coloured light bulbs. Again green is OK, red means some errors were encountered and the archive administrator should be contacted during the next business day. In particular make sure jobs write_d1_worm, write_d2_worm, Local_backup and Save_Storm_Files ran successfully last evening. Any red bulbs can be expanded by clicking on the line opposite the offending bulb and then clicking on the messages button:
Press OK and Close in succession to get back to the Jobs tab. To provide for offsite storage of backup media an additional set of backup WORM media is introduced. IXOS warns against using stick labels on the WORM media (they have been known to come off), instead suggesting the label be written on the media in magic marker. Since original and backup media are labeled internally the same, different colours of marker are suggested. I have used blue for original WORM media and green for the first set of backup WORM media. Switch to the Devices Tab and click on the Worm Icon. On the right hand window click on the Flags button once or twice so that the backup WORMS (flag Bak) are displayed at the head of the list.
Right click on the first backup volume and chose Eject. Now go over to the WORM library and remove the ejected WORM and close the door.
Repeat this process for all remaining backup WORMs. If everything has been done correctly, all the backup WORMs youve ejected should be labeled with the same colour. These backup WORMs can then be taken over to the vault, retrieving the alternate coloured set.
Right click on the WORM icon and select insert. Now go over to the WORM library and insert one of the retrieved WORMs. Close the door. Note if the WORM media prevents the door from closing, it has been inserted backwards.
Repeat for all WORMs returned from the vault.
Note that WORMs returned from the vault need to be inserted into the WORM library prior to the WORM backup job "Local_backup" scheduled at 20:00 nightly. FUTURE NOTEWORTHY EVENTS After some time in use we expect the WORMs weve initialized to fill up. Hopefully the Archive Monitor will warn us when that event is close at hand. If you select the Archives Tab and select H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Created by Ken Chamberlain 42 Date last changed: April 3, 2001
each pool d1_pool, d2_pool and t1_pool in turn you will see a display that includes Capacity and Free. When the Free amount goes to Zero there is supposed to be a full indication, possibly in the Status field.
Prior to a WORM side (Partition) filling up we would initialize another WORM. You might have thought that wed initialize side B of the worm weve been using, but IXOS recommends against this for performance reasons. Something about inserting a WORM to retrieve a document, then needing something in the near future of the retrieved document causing the WORM to be flipped over, etc. So instead well initialize Side A of a brand new WORM as well as side B of the original WORM, assigning lower priority to side A of the new WORM than Side B of the original WORM. As the original and backup WORM sides become full, the WORMs should be ejected temporarily to mark the fill date on the WORM. At some time further yet in the future both sides of a WORM will become full. When that happens full backup WORMs can be removed from the WORM library permanently. Perhaps one copy might be stored in the vault, the other sent to the owner of the data. For pools D1 and D2 that would be DUR.
Authorizations
The following is a list of the authorizations that currently exist (Authorizations->Basis->Central Functions, under SAP ArchiveLink):
The IXOS user profiles all begin with S:IXOS*. These are the user profiles that currently exist:
Firewall Access for Viewer and Scan Station (Only allow University of Toronto IP addresses)
All users with access to SAP have access to view imaged documents. All users using the IXOS Scanner Station port must be part of the IXOS Firewall group. If they are not part of this group, then they will be unable to scan documents.
Oracle Licence
The Oracle licenses agreement is not an issue with the University of Toronto installation as there is a full Oracle site license in place.
IXOS Viewer
The IXOS viewer may be downloaded from the AMS website. To download the viewer: Go to http://www.utoronto.ca/ams Under the Fast Track Section on the right hand side of the screen, select Software. You may also go directly to http://www.utoronto.ca/ams/techsup.htm. To access the installation instructions and the software youll have to use the following userid and password: UserId: Password: sapdist getitnow
1.1.8
NT 4.0 Installation of Scan Client and V4.1 notes
IXOS Server and Jukebox Hardware

Please see appendix D for the Hardware Sizing report from IXOS.
Upgrade considerations
1.1.9
Oracle Upgrade
The IXOS project consultant recommended that the Oracle upgrade be done by IXOS or certified by ESC. 1.1.10 Change of ixds/ixworm/ixar (Oracle user) password back
H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc
46
Appendix
Appendix A: Scoping Document
Scoping Document
Implementation of IXOS imaging application Development and University Relations University of Toronto PHASE I
Submitted by: Holly Yoos, Senior Records Analyst Wes Moon, Systems Analyst Development and University Relations October 24, 2000
H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc
47
PROJECT DESCRIPTION Goal To provide DIS users with desktop access to donor or prospect information previously only available in paper format. Using the IXOS-Archive Imaging Solution, DIS users will be able to access scanned images of documents that relate to prospects or donors through the DIS graphical user interface. At the conclusion of phase I of the project, users will be able to access the following key documents through DIS: Gift Agreements Admin Digests Other documents directly related to bottom-line Proposed documents for phase II: Award Records Proposals Objectives / Benefits The DIS -IXOS imaging application will reduce DUR costs via: photocopy savings. At a minimum, one third of all documents are copied, sometimes more than once, and filed in multiple areas across the University. The DIS -IXOS imaging application will eliminate the need for multiple copies of hard-copy documents. reclaimed space. Maintaining documents in electronic format will dramatically reduce hard-copy file requirements and costs. reclaimed time through efficiency. Paper handling of donor/prospect documents will be drastically reduced. Filing, retrieval, re-filing and lost-misfiled documents virtually eliminated. Documents will be available in seconds versus 10 minutes. Staff will be able to print or email from desktops in seconds. The DIS -IXOS imaging application will increase customer satisfaction by making information available in seconds for phone inquiries. Increased efficiencies will free up staff to research and contact more donors and thereby generating more revenue for the University.
48
Assumptions Documents imaged and linked to DIS will be the official DUR record. Staff should not retain document originals or copies elsewhere -- unless specified in approved retention schedules.
Implementation Steps See attached plan. What IXOS will provide Requirements workshop: three days on-site to determine customer objectives, needs, requirements and transfer knowledge. Assessment development: findings are analyzed and documented Scenario implementation and verification: customization of DIS object, walk-throughs, knowledge transfer Follow-on consulting support or extended implementation: additional support Go-live support: testing, training, walk-throughs. APPROACH Overview Strategy The DIS -IXOS imaging application is another step towards making DIS a more comprehensive donor/prospect information resource. In addition, the IXOS product includes a data archiving component that DUR may wish to consider in the future. Tasks and Deliverables Scoping document developed and approved IXOS requirements workshop Document types defined and keys developed Processes and business rules defined Purchase and installation of server, jukebox, optical platter and scanner Software programming completed and software operational Training completed and documentation compiled Four key documents scanned, linked and made available through DIS Week of October 23/00 ASAP, likely week of November 13/00 To be reforecast after workshop. Likely end To be reforecast after workshop. Likely end To be reforecast after workshop. IXOS requirements of December/00 IXOS requirements of December/00 IXOS requirements
To be reforecast after IXOS requirements workshop. To be reforecast after IXOS requirements workshop. To be reforecast after IXOS requirements workshop.
49
PROJECT ORGANIZATION AND RESOURCES
Project Team Project Leader AMS Advisor Analyst Analyst Network / scanner Application Application Basis admin User representative Consultant Holly Yoos Cathy Eberts Wes Moon Vicki Vokas Roshan Jayatunge Allison Dubarry Paul Littlefield Ann Joiner TBD Jim Ash Senior Records Analyst; DUR Associate Director; AMS Systems Analyst; DUR Manager, DIS Client Services; DUR Network Admin; DUR DIS Programmer DIS Programmer CNS/AMS Researcher; DUR IXOS
APPENDICES 1. Project Plan Gantt Chart 2. Draft document type list 3. Document type description template
50
Document Management for DUR
IMAGING SYSTEM: PHASE I DOCUMENT SELECTION The project team recommends that gift agreements , admin documents , and receipts be selected as our phase I documents. CRITERIA FOR PHASE I DOCUMENTS Criteria 1: Efficiencies Any documents selected for imaging and linking to the DIS system must result in improved efficiencies and/or cost savings Evaluative criteria includes: elimination of photocopying and distribution reduced turn-around times for donor inquires or services reduction in maintenance of duplicate document sets risks associated with utilizing superceded versions improved business processes Criteria 2: Success Documents selected for Phase I should permit quick and successful implementation Evaluative criteria includes: coding marked on document eliminating need for DIS searches prior to scanning amount of DIS programming required amount of process redesign required types of document formats available (ie. paper and/or electronic) availability of complete and current documents sets that are segregated from other documents RECOMMENDATION: GIFT AGREEMENTS Efficiencies Frequently referenced by DUR staff to understand nature and details of gift Reduce time spent identifying and retrieving gift agreements Reduce time spent clarifying relationship between DIS records and gift agreements Reduce errors produce through referencing superceded gift agreements Faster response time to donor inquiries that relate to gift agreement Reduce time spent photocopying and distributing paper copies (currently distributed to approximately seven people within DUR) Reduce space requirements for maintaining duplicate sets and reduce time spent maintaining duplicate sets throughout DUR Reduce time spend responding to inquiries from constituencies that have DIS access Success Complete segregated hard-copy set is available in Jons office for scanning Longer implementation process than admin documents because a document expert will need to search DIS to identify correct record for linking. Limited process redesign Limite d programming RECOMMENDATION: ADMIN DOCUMENTS Admin documents include admin digests , summary sheets , and award records. Efficiencies Prepared by Holly Yoos Submitted to Rivi Frankle November 21, 2000 51
Frequently referenced by DUR staff to understand nature and details of gift. Admin documents avoid use of legalese found in gift agreements. Reduce time spent identifying and retrieving admin documents Reduce time spent clarifying relationship between DIS records and admin documents Reduce errors produce through referencing superceded admin documents Faster response time to donor inquiries that relate to gifts Reduce time spent photocopying and distributing paper copies (currently distributed to approximately five people within DUR) Reduce space requirements for maintaining duplicate sets and reduce time spent maintaining duplicate sets throughout DUR Reduce time spend responding to inquiries from constituencies that have DIS access Success Rapid implementation as project number is already indicated on documents Rapid implementation as many admin documents are already available in electronic format reducing the need to scan. Rapid linking to DIS as project number is identified directly on the document Limited process redesign required Limited programming time required RECOMMENDATION: RECEIPTS Implementation would be more complex, but warranted by substantial efficiency gains. Efficiencies Processes already under review Opportunity to significantly improve turn-around times for receipts (from weeks to hours) Reduce number of follow-up inquiries from donors, increase donor satisfaction and reduce staff time needed to respond to inquiries Success Requires significant programming Requires significant process redesign
Appendix B: Relevant OSS notes

Note 28552 90285 115708 Short Text What is ArchiveLink? No archiving of outbound documents Display of outgoing documents in PDF format
The following file contains a listing of further OSS notes: I:\IXOS\pre-install check list\OSS Notes\OSS notes.xls.
Appendix C: Consultants Report

Prepared by Holly Yoos Submitted to Rivi Frankle November 21, 2000 52
IXOS SOFTWARE INC. 19 Campus Boulevard, Suite 100 Newtown Square, PA 19073 Tel.: (610) 355-7467 Fax: (610) 355-7479 http://www.ixos.com
Consulting Report Business Document Imaging for SAP R/3 using IXOS-ARCHIVE for University of Toronto by John Walls IXOS SOFTWARE, INC.
Business Document Imaging for SAP R/3 using IXOS-ARCHIVE
53 of 1
Version Business Document Imaging for SAP R/3 using IXOS-ARCHIVE Doc.-Version: 0.0.1 Author: John Walls Source: iXOS Blueprint.doc Date: 26 June, 2003 Copyright 2003 IXOS SOFTWARE, INC. All rights are reserved, including those of duplication, reproduction, use or disclosure of the contents of this documentation, or any part of it. No part of it may be reproduced in any form, passed on to third parties or particularly by electronic means, processed, reproduced, distributed or used for publication without the written permission of IXOS Software Inc. We reserve the right to update or modify the contents. Trademarks UNIX: Unis Systems Laboratories, Inc. OSF, Motif, OSF/Motif: Open Software Foundation, Inc. X Window System: Massachusetts Instit ute of Technology PostScript: Adobe Systems, Inc. FrameMaker: Frame Technology Corporation Citrix, ICA, MetaFrame, WinFrame: Citrix Systems, Inc. IXOS: IXOS Software Inc. ORACLE: ORACLE Corporation, California USA Microsoft, WINDOWS, EXCEL, NT: Microsoft Corporation SAP, R/3, SAPmail, SAPoffice, SAPscript, SAP Business Workflow, SAP ArchiveLink: SAP AG Intel, Intel Inside: Intel Corporation Other product names are only used for identification. They also may be registered trademarks. Table of Contents 1 1.1 2 3 3.1 3.2 3.3 4 4.1 4.1.1 4.2 4.2.1 4.2.2 4.2.3 5 5.1 5.2 5.3 5.4 5.5 Preface 2 Document Revision History 2 Management Summary 2 Project 2 Objectives 2 Limitations 2 Analysis contacts 2 Processing Scenarios 2 Scanning 2 Scan Scenario Summary 2 Retrieval 2 Viewing Scanned Documents with the SAP GUI 2 E-Mail 2 Windows 98 Second Edition/Windows 2000 2 General Analysis Results 2 Gift Agreements 2 Admin Documents 2 Donor Biographic Information 2 Receipts 2 Reports 2
5.6 6 7 8 8.1 8.2 8.3 8.4 8.4.1 8.4.2 9 10 10.1 10.2 10.2.1
DesktopLink and Correspondence 2 ArchiveLink Enabling DIS 2 Document Security 2 Logical archives, retention periods 2 Promote to Production Strategy 2 Refreshing and cloning other SAP systems Scan Volume 2 Scanning 2 Scanning Architecture 2 Scanning Recommendations 2 Implementation Notes 2 IXOS Architecture 2 EnterpriseScan Stations 2 Archive Client Workstation 2 Windows 2
55 of 1
Preface The University of Toronto (UofT) is operating an SAP R/3 system, version 4.5B. The initial focus of the IXOS enhanced imaging package will be on the custom Donor Information System (DIS) used by the Development and University Relations (DUR) department. IXOS is tasked with designing and implementing a document management solution for this system. Donor documents at UofT have traditionally been stored in their original paper form. The University spends a lot of time retrieving these documents manually. The University would like to make this process more efficient, by retrieving these documents electronically, while increasing their office space. This document includes some configuration of both the SAP and IXOS system as well as any new business processes associated with document management. It is based on information received as of November 10, 2000. By its nature, this is a living document with assumptions made as noted. Document Revision History This report is based on the information gathered during an on-site analysis conducted November 08 through November 10, 2000. Version 1.0 delivered electronically to UofT for review on November 20, 2000. Management Summary IXOS Software Inc. has been contracted to assist the University of Toronto with complementing the DIS system with document management and improved business processes. Documents under consideration for archiving are those relating to the DIS system. Phase I documents will be those documents that provide the greatest process improvements combined with relatively simple implementation requirements, such as gift agreements, admin documents, and payment receipts. Since the DIS system is considered a bolt on to the standard SAP system, it will be required to be ArchiveLinked enabled. ABAP programming is required to ArchiveLink enable an object, if one exists. If not it will have to be created and this will involve some development work. The object will also have to be published in the program in which, the document is to be retrieved. Once all this has been completed the SAP authorization object will also have to be added to the program in order to perform the authorization check. During this implementation, effort will be focused on ArchiveLink enabling the DIS system, and establishing standards and procedures for electronic handling of donor documents. Easier and quicker access to information is the immediate and expected results. Throughout this analysis, it became apparent that UofT would benefit from implementing the late archiving scenario for their current donor documents. Other document management scenarios, specifically early archiving with workflow and late archiving with workflow could become very beneficial for UofT in the future. It is important to note that any recommendations made in this report are based on information obtained and discussed onsite the week of November 8, 2000. These recommendations are subject to change based upon further decision(s) made by UfoT, or in light of any new information. Project Objectives This analysis report is the product of the IXOS-ARCHIVE Advanced Imaging and Archiving Consulting Package which is designed to determine which business document imaging scenarios will best reduce costs and optimize a companys business processes. The primary objectives of this consulting package are: Introduce IXOS-ARCHIVE and discuss business document archiving concepts. Ascertain customer expectations and define the project scope.
56 of 1
Discuss possible improvements in the current document handling process. Identify Documents and the SAP objects (transaction codes) they are to be linked to. Determine scenario requirements, document types, and document volume. Provide our expert understanding of IXOS-ARCHIVE to identify how IXOS-ARCHIVE can provide the greatest benefit to UofT. Illustrate the concept of ArchiveLink enabling a Object Evaluate and specify system configuration, logical archive divisions, distributed network needs. Prepare a summary report describing the IXOS analysis, open issues and offer guidelines for both immediate and future activities to get the most out of UofTs IXOS-ARCHIVE and SAP R/3 investment. Limitations The scope of this assessment is limited to the immediate objectives of phase I. We have limited our analysis to all the documents associated with the DIS system. This report will address the concepts behind ArchiveLink enabling SAP objects, but not the actually ABAP programming, or development work. It should also be noted the desire to automatically archive outgoing receipts will have to be investigated further on site or remotely. It will be addressed, but not in any great detail. The process as it stands now will probably have to be changed.
Analysis contacts Over the course of the consulting visit, the consulting team met with the following individuals either in small groups or as the entire project team. Name Holly Yoos Wes Moon Anne Joiner Allison Dubarry Paul Littlefield Cathy Eberts Vicki Vokas Roshan Jayatunge Bill Lauriston Roles Project Coordinator Analyst Basis Admin DIS Programmer DIS Programmer AMS Advisor Analyst Network Admin Basis Admin Contact Phone Numbers 416-978-7872 416-978-3847 416-978-2220
Processing Scenarios Scanning The scanning process is just one-way to bring supporting documents into SAP and IXOS. The SAP ArchiveLink interface provides the necessary functionality within SAP to link business document images to SAP documents (transactions), and to communicate with the IXOS-ARCHIVE server, scan client, and viewer software. The actual documents are stored in a permanent optical media (WORM platters) managed by the IXOS-ARCHIVE server. The only information stored within SAP is a table entry containing the link between the archived document image and the SAP document object. There are four
57 of 1
different scenarios for linking supporting SAP documents, but only Late Archiving will be implemented at the UofT during the initial phases. Early Archiving (also called Store for Entry Later in SAP version 4.5x) Late Archiving (also called Store and Assign) Late Archiving with Workflow (Store for Subsequent assignment) and Late Archiving with Barcode are the four different scenarios. Late Archiving (Store and Assign) In late archiving, the scanned document image is assigned to an existing SAP object (i.e., donor number). The assumption is that the SAP object to which the scanned document is to be assigned already exists and the key fields are known (i.e. Donor ID number). This is most often used for supplemental documentation that comes in after-the-fact or documents that have been generated by the system but requires a signature. This scenario has little if any impact on existing business process. Paper flows through the office just as it has always done. The only change is that paper work ends up at the scanner instead of the filing cabinets. This scenario is used when the existing business process remains in tact, and indexing is done at the scan station. This scenario is very easy to implement. Current analysis indicates initial implementation of document management will be heavily weighted towards late archiving, also referred to as store and assign. Implementation of this archiving scenario allows document images to be associated with an existing SAP object. Once the information is entered into SAP, associated paper documents may be imaged and linked to the SAP record by the scan operator. In the late archiving scenario a scan operator is responsible for linking document image(s) to an existing SAP object. Image data may come from a file system, or scanned input. The UofT would only use the scanned input and file system. Figure 4-1 is a flowchart depicting the basic imaging process flow for the imaging scenarios discussed in this analysis. Scan Scenario Summary The following are some of the added values of using document imaging with SAP: Images of all supporting documents can be retrieved directly through the SAPGUI by any SAP user, whether local or at a remote branch (assuming they have SAP, SAP authorization to the related SAP document). The scanning process is generic and can also be used for other processes at UofT.
58 of 1
Documents
Documents are scanned or imported from the Fax Server Scanners
Scanning Scenario is chosen in SAP Late Archiving
Client PC File system DesktopLink
Images are assigned to a Document type within SAP
Files are uploaded from client and archived in SAP
As soon as the doc type is selected the image is indexed The Sap Object already exists. Images are only indexed Images are indexed at scanning locations
Archive Server
Images are Archived once Indexed
JukeBox
(Figure 4-1)
59 of 1
Retrieval Viewing Scanned Documents with the SAP GUI Once documents have been archived, the images will immediately be available for viewing. The SAP GUI makes a call to the archive server and the image is displayed within the IXOS viewer. There are two ways to retrieve and view documents. The most common method to access the image is from within the application (System > Object Links click Display). Documents have to be linked to a key field such as Donor ID or Pledge number. The second method of document retrieval is from SAPs Archive Administrator (OAAD). Access to this transaction is restricted to only supervisors since it allows for the deleting and reassigning of document links. E-Mail If UofT needs to have people other then employees involved with the DIS system to view documents, then there is another option. The images could be e-mailed to individuals who do not have access to the SAP system. This would require the individual to have the IXOS viewer installed on their client if they wanted to see the image with annotations and notes. If not, then any application that will open a TIF image will work. These images could be mailed as a link or as a copy. If the images were e-mailed as a link then the annotations would be available in the IXOS Viewer, if it was sent, as a copy then there would be no annotations. Keep in mind that the SAP authorization check is by passed if the image is e-mailed. Windows 98 Second Edition/Windows 2000 IXOS Viewer The IXOS 4.1 Viewer will only work on clients running Windows 98 Second Edition/Windows 2000 Professional or Windows NT 4.0. Window 95/98 will have to run the 3.5D version of the IXOS Viewer. The viewer application is called by the SAP GUI to view images and allows the user to perform such functions as zooming, rotating, panning, annotations, notes, e-mailing and printing. The added benefit to the system is that there is no load placed on the system after the GUI makes the request for the document. The communication is now between the IXOS Archive Server and the client, not R/3. When the request is made from within the application, or the Optical Administrative (OAAD) screen a security check is performed based upon the one or all of the following: object, document type, and logical archive associated with the image and the security profile of the user (See Section 6 and 7). If the user has the clearance the image will be displayed within the IXOS Viewer.
General Analysis Results The current imaging project at UofT will involve the archiving of documents related to donors and donations that are tracked in the DIS system. The overall project will be divided into a number of phases where groups of document types will be linked to DIS records via the IXOS system. Phase I documents will be selected on the basis of their ease of implementation and the degree of payback. Phase I documents may include document types such as gift agreements, admin documents, donor biographic information, and receipts. These document types are described in sections 5.1 to 5.4 below. Sections 5.5 and 5.6 discuss the implementation of report archiving and desktop linking. Gift Agreements Every single Donor to the University of Toronto is entered into DIS R/3 system for tracking purposes. Each donor is tracked with a unique donor identification number. Every donation or pledge to the university is tracked with a unique pledge number. It is at this level (the pledge header) that the University of Toronto would like to attach any documents related to the pledge, in particular the Gift
60 of 1
Agreement. (Please note that not all pledges will contain Gift Agreements.) The Gift Agreements will be linked to the Pledge ID field, the key field. In order for this to be configured, an object will have to be created and ArchiveLink enabled. Please see section 6 for further explanation. The only issue open that would need to be addressed is security. UofT would have to decide of all the users who have access to the pledge screen who would they want to have the ability to view the associated documents. See section 7 Admin Documents Admin Documents, which include Admin Digest, Summary Sheets, and Award Records, are documents that the University would like to archive against projects. Every project maintained in the SAP system is given a unique Project ID#. It is this key field that these Admin documents would be linked to. There would not be much work involved to set up archiving for these documents. An object would have to be created for Admin Docs as well, but if your already creating an object for Gift Agreements then this might not be a big deal. See Section 6 As with Gift Agreements, security will have to be addressed here as well. See Section 7 Donor Biographic Information Every person who makes a donation to the University of Toronto is entered and tracked in the DIS system by a unique Donor ID number. The University would like to take documents like Donor profiles and Jackpots and other informational documents and link them to the Donor ID. There would not be much work involved in setting up archiving for these documents. Again a object would have to be created, ArchiveLink enable, and then published. If youre creating an object for Gift Agreements, then it would be very easy to create one for donors. Once this is done any number of document types could be configured and linked to the Donor ID number. Receipts Receipts are generated and sent to a line printer in batch, once payment has been received and processed by the system. There is a multiple payment line relationship to the receipt number. These receipts are given a unique receipt number when they are generated. The payment line item screen will be updated with the Receipt number once it has been generated. The receipt appears to be printed in ALF or report format. This would have to be investigated further to determine if the format is ALF or OTF (SAP script). It has been brought to the attention of IXOS that the receipt process will be changed in the coming month. The change would include changing both the receipt and the acknowledgement letter to SAP script and printing it on an 8 1/2 x 14 perforated form. The top section of the form would contain the acknowledgement letter with the receipt on the bottom and the perforation in between. The archiving of receipts is handled differently then the archiving of paper documents. The outgoing document produced by SAP is normally sent directly to a printer, however if it is also going to be archived, then a spool request is sent to the printer as well as the archive. IXOS would like to recommend that this process is modified before an attempt is made to archive enable it. IXOS would strongly recommend that the UofT grant IXOS dial up access to the DIS system in order to Archive enable the archiving of out going receipts and to verify and/or assist with the programming and development work required to ArchiveLink enabling all the objects. (There is considerable cost saving with remote access) It has also been suggest by our (IXOS) programmers that a receipt archive button could be created and placed within the receipt dialog box. (The receipt dialog box is called when the receipt button is click on the payment details screen.) This archive button would then display from the archive in PDF format the receipt, which cold then be printed or emailed.
61 of 1
Document Gift Agreements Admin Document Donor Profiles Receipts Reports YTB = Yet To Be
Linked to Pledge Header Projects Donor Receipts Number Freely defined
Object type YTB Created YTB Created YTB Created YTB Created DRAW
Key Field(s) Pledge Number Project Number Donor ID Number Receipt ID Info, description, report name, etc.
Reports The University has expressed interested in being able to archive monthly reports or (printlist). Although this seems to be out of scope in this phase, a single printlist document type will be set up by the installer to test the configuration of the network and the communication between the R/3 system and the Archive server. Since this is considered a nice to have and is not in scope in Phase I it will only be addressed time permitting. It is only being considered, because of the simple nature of printlist archiving. UofT would need to identify the reports that they would like to archive so that a naming convention can be decided on. They would also need to consider retention periods and report security during this time. Please note that the Security Object used for printlist is S_WFAR_PRI, but the limits and activities are the same. DesktopLink and Correspondence During the analysis it became apparent that the University could make use of the IXOS DesktopLink product. DesktopLink allows the end-user to archive desktop files such as MS Word and Excel documents against objects in SAP. Documents are archived from the file system, so there is no need to print and scan the images. These documents can be archived from any PC, which would cut down the paper handling and processing time. The Documents being considered are generally special thank you or correspondence from the University to the Donors. ArchiveLink Enabling DIS In Order for these documents to be linked to the correct SAP ID (SAP transaction code) for example the Donor ID number, a Business Object will have to be created. Business Objects are related to a Table in SAP, but not all tables have an associated object. ArchiveLink enabling a custom SAP transaction is a three-step process. The first step is to create a business object. T-Code SWO1 will take you to the BOR or the Business Object Repository where the object is created. The object will be created in relation to a table in SAP. For example, if you were creating an object for the Donor master, it would be created in relation to the Donor master table that contains the Donor ID number as the key field. Once this has been done there are 5 sub steps. The first would be to add the FIARCH21 SAP ArchiveLink Interface to the Interface folder. This will be the source of the two needed methods Existence Check, and Confirmation which will be discussed later. Next step is to add the Key field to the Key field folder. This will be the same as the Key field within the related table. The Methods will now have to be redefined (Edit > Redefine) so that changes can be made. There is now some ABAP programming that has to be added to the both the Existence Check, and the Confirm Check. Select one of the methods click on the programs button, you will be asked if you would like to implement the Method, Click YES. The foundation of the of the program will be created, it just has to be modified to check against entries within the customized table. The Existence check verifies that the SAP document (Donor in this case) exists, while the Confirm check will display the donor information as a
62 of 1
final step before archiving to it. This is done so that an image can be compared to the Sap document (Donor) it will be linked to. The Object will have to be released and then generated. The Second Step would be to Publish the object. In order to publish an object the include SWU_OBJECT_PUBLISH, must be inserted into the desired program on the application side. For example, the program that is used when you display a donor profile after entering in the donor ID number. This include would have to modified slightly. The newly created Object and its key field would have to be exported as seen below. In UofT case the key field would be the field of the Donor ID. At this point the ArchiveLink Enabling of the Module is completed.
Figure 6.1
This is an example of a custom IXOS object.
The third step is not a critical step in the ArchiveLink enabling the DIS module but it has to be addressed. This step covers document retrieval security. In the program that retrieves the donor information, the security object S_WFAR_OBJ would have to be (should be, it is entirely up to the University) checked. It is with this object that the UofT could control access to documents via the Object type, Document type,
63 of 1
and Logical Archive, or any combination of the above (Please see Section 7). This object also controls the activities that can be performed on as far as document archiving. See figure 6.2
Figure 6.2
Document Security
64 of 1
User secruity will need to be tested and adjusted to allow the ixos software to view documents from the Users desktop. There is a possibility of either modifing the current entrance through the firewall or creating a new entrance through the firewall based on the protocols used. Access to DIS related documents will be controlled most fundamentally through restricted access to DIS itself. Access to individual documents can also be restricted via object S_WFAR_OBJ. This object will limit access to documents by way of the Object, Document type, or Logical archive. This needs to be (should be) considered prior to configuration of Document types, and Logical Archives. It is also possible to control access to documents via restrictions on viewing SAP transactions. ,. If someone doesnt have access to view the SAP transaction then there is no way for them to retrieve the images. It is important to note that IXOS makes use of SAP authorization concept. Logical archives, retention periods Logical archives are used to define retention periods. All documents with the same retention period will be archived to the same logical archive. The UofT has not yet determined retention periods for their documents but many of them will need to be maintained for as long as possible. A logical archive is designed to be a static storage media, meaning that it is used with documents that have set retention periods. For example most financial documents are kept for seven (7) years and then they can be deposed of. In order to do this, the WORMs will be locked down. This means that at a particular date the WORM is locked down, meaning nothing else will be written to it. It is from this point forward that the clock starts ticking, and after 7 years the WORM can be destroyed. Confident that the youngest document on the WORM is exactly 7 years old. The static storage media is very suitable for the UofT and their required retention period. Promote to Production Strategy The best method to move configuration changes is, with the use of SAP transports. One method is to transport all the configuration changes all the way to production the way that you would want to see it. Then go back into the DEV and QAS systems and change the link table entries to point to the test logical archives. Master data, which includes organizational units and number ranges are not transportable. Refreshing and cloning other SAP systems Please note that care must be taken when refreshing the DEV system. The link table entries from the DEV system should be exported before the refresh and then imported afterwards. This will keep users in the DEV system from being able to view sensitive production images. After the refresh has been completed, the link table entries should be changed back so that they are pointed back to the test logical archive. This will keep users from archiving test documents to the production Archives. Scan Volume The University of Toronto is currently looking at central scanning at a single location. The volume of documents to be scanned by UofT is relatively small, about 300 per day. Scanning Scanning Architecture In determining the Scanning Architecture for the Donor documents, the need for quality, accuracy and resources including both labor and equipment have been taken into consideration. It has been determined that a central scanning location will be used and located within the DUR department. The advantages of this scanning architecture are pretty clear: UofT employees will not have to be burden with task of learning a completely new business process on top of a new software solution. A concentrated number of users who would need to be trained Cost savings associated with personnel, scanners, and PCs that would not be needed if only a central scanning location were running. Quality and Accuracy could be controlled, managed, and measured much easier and efficiently if scanning were to be centralized.
65 of 1
Scanning Recommendations There are a lot of features of a scanner to consider before purchasing such as; Through put volumes expressed in ppm (pages per minute), Please note that most manufactures express their ppms in landscape mode. Most scanning is done in portrait mode. Average daily workload expressed as ppd (pages per day). This is the realistic daily scanning volumes. This is the difference between Production, Departmental, and Personal Scanner. Duplex or Simplex- the ability of the scanner to scan single or double sided documents. Automatic Document feeders and their capacity. Paper type Size and paper weight limitations. Flatbed feature Allow scanning of damaged, and unusually small documents like receipts and checks. Implementation Notes The current project plan being maintained by the UofT is quite accurate in regards to the tasks and their duration and will serve as the Implementation guide going forward. IXOS would like to make sure the following suggestions (these are not all consider tasks, but rather points) UofT will modify there receipt output UofT will start work on ArchiveLink enabling their newly created object. Remote access- In order to assist the UofT with their development and programming work 5 days of configuration, testing and knowledge transfer. 3-5 days of end-user training and go-live support. I dont think that there is any need to physically have a programmer on site. I think that the Universitys programmers can handle this on their own with support from IXOS. If UofT feels that they would like to have someone on site this can also be arranged. IXOS Architecture EnterpriseScan Stations For the Enterprise Scan workstations we recommend a Pentium II 400 MHz processor, 128 MB RAM and a minimum 21 monitor. We further recommend that you have at least 1 GB of free disk space. For color scanning we recommend a resolution of 100 dpi. Color scanning with higher resolution requires fast scanning stations with a minimum of 256 MB RAM. UofT is not currently considering color scanning If more than one scanner is being used, IXOS recommends the same scanner type be used in each location. This provides greatest flexibility when needs change, minimizes the training problems, and maximizes the ability to share configuration settings among the scan clients. Note: Scan stations must run Windows NT on an Intel platform. (See Release Notes) Archive Client Workstation Client machines may consist of Windows compatible workstations. Supported configurations include: (See Release Notes) Windows Minimum requirements: Windows NT 4.0, Windows 98 SE (Second Edition) or Windows 2000 are required to run IXOS 4.x. Window 98/95 will have to run IXOS viewer 3.5D. Client components require a Pentium 166 MHz processor, 64 MB RAM and 200 MB free disk space. Occasional users may use less RAM, but this may lead to performance loss. For Windows 2000, the manufacturers requirements for the operating system are also adequate for IXOS-ARCHIVE components. Windows operating systems can only be used with Intel compatible process
66 of 1
Appendix D: Scanning Manual and Procedures

See Scanning Manual 100401.doc in the IXOS directory on the DAMS server.
Appendix E: Hardware Sizing Document
Business Document Imaging for SAP R/3 using IXOS-ARCHIVE 67 of 1
IXOS-ARCHIVE Hardware Configuration for University Of Toronto
For IXOS-ARCHIVE at University Of Toronto, we recommend a configuration using one AIX-based IXOS-ARCHIVE Server, one WORM jukebox, one scan station and unlimited retrieval (viewer) clients. Depending on future requirements and additional applications for IXOS-ARCHIVE, this initial configuration can be easily added to with additional scanners, jukeboxes or servers, if necessary.
For proper sizing of system components, we rely on the sizing questionnaire completed during the initial analysis survey. Please see the attached document that lists the input assumptions. Based on that information, the following is the suggested archive server:
Hardware requirements: RAM: minimum 512 MB, recommended: 1024 MB. Hard disk space: 25GB (portion protected by RAID technology. See table below) SCSI interface host adapter CD ROM drive (this is for installation, it does not have to be local) Optical jukebox Network connection Backup Facility (network or local tape drive) IXOS-ARCHIVE requires no graphical terminal on the UNIX servers
AIX Archive Server Hardware Requirements: Supported operating system: Supported database:
AIX ORACLE
4.3.X*** 8.1.5
***We recommend that you install AIX 4.3.3, which includes Java version 1.1.8. Java 1.1.8 is required. http://www.rs6000.ibm.com/ * The maximum cable length is 2 m for single-ended SCSI and 15 m for differential SCSI. Please note that SCSI connections must be terminated on both sides. - A configuration communication via TCP/IP must be provided. For all platforms and for all archive servers static IP addresses and unique names are required. The hardware should be easy to upgrade. - The hard disk volumes required by the archive system - including those for the database, except for the exchange directory - MUST reside on the archive server machine locally. If you decide to use an archive server with a remote-standby you must ensure that both machines use the same type of optical media (CD or WORM) on both machines.. - Ensure you have adequate licensing for your Oracle Database.
H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: Nov 16/00 68
Archive Sizing Results: The size of the hard disk is determined by several factors, including how many documents are to be stored on readily available magnetic media. Calculations based on these input volumes indicate that the hard disk space for your archive server should be a minimum of 25GB but rounding it to 30GB would be safer. The total data volume calculated is 22.7 GB the first year, and 9.9 GB per year thereafter, which will require approximately 5 WORM disks the first year and 3 WORM disks per year thereafter.
Hard disk sizing Purpose Operating System SWAP space (page file) Database binaries Database data files Database index files Database log files Database mirrored log files Database archive files (redo logs) IXOS binaries Disk space to build a CD image Disk space for worm hash table Backup space for STORM Disk space for DP directory Temporary disk space for IXOS Minimum amount of hard disk space for read cache Minimum amount of hard disk space for write cache Total hard disk space HD Size 1000MB 0MB 1000MB 2000MB 1000MB 500MB 500MB 500MB 500MB 0MB 2713MB 2813MB 2340MB 2925MB 5000MB 2500MB 24.7GB Raid/Mirroring recommended no monthly backup required required recommended recommended recommended monthly backup no required required no no no required
Please remember that RAID technology requires redundant disks In case you are using RAID 1 technology, we recommend the use of at least 4+4 disks In case you are using RAID 5 technology, we recommend the use of at least 5 disks
Archive Sizing Results (continued):
Total Number of optical disks Number of disks needed / yr for scanned/faxed docs Number of disks needed / yr for OTF docs Number of disks needed for data archiving (1st year) Number of disks needed / yr for data archiving (growth) Number of disks needed / yr for MS-Office documents Number of disks needed / yr for E-mail Number of disks needed / yr for DMS documents Number of disks needed for DocuLink (1st year) Number of disks needed / yr for DocuLink (growth) Number of disks needed / yr for ALF (printlists) Total number of disks needed / yr (1st year) Total number of disks needed / yr (yearly growth) 1.7WORM 0.1WORM 0.0WORM 0.0WORM 0.0WORM 0.0WORM 0.0WORM 0.6WORM 0.3WORM 0.0WORM 2.8WORM 2.2WORM
Optical Disk Jukebox: All supported WORM & MO jukeboxes must be used with a SCSI interface in IXOS-ARCHIVE V4.x. Based on the input from University Of Toronto, a recommended Optical WORM Jukebox is the IBM 3995C-62 with 2 drives. It has 52 slots and holds 270GB of data. Nevertheless, if you prefer to jump to the next available model, it would be the 3995C-64 with 2 or 4 drives and 104 slots. Take note however that this later model is much bigger then your needs recommends. IBM Optical Disks: In addition, University Of Toronto will need to order optical disks. Please order a 1-year supply or about 15 platters. This is more than the required number in order to account for backup disks and test/development archives. Specify Permanent WORM Media. IBM part number: 59H4791 5.2GB 2048 bytes/sector Permanent WORM platters Scanning Hardware: The sizing results for the Archive Server and Jukebox account for the volume of scanned images indicated in the input assumptions. It is divided in two part: the Scanning Workstation and the scanner itself. SCAN WORKSTATION Any Intel based Pentium II system, 400+ MHz Windows NT Workstation 4.0, Service Pack 5 RAM: 128 MB recommended. Super VGA graphics adapter CD ROM Drive (for installation) 21 monitor with a resolution of 1280 x 1024
Minimum 2 GB hard disk space Single ended Adaptec SCSI adapter for the connection of the scanner NTFS File System must be used
Scanner
Because documents will be double sided, make sure the scanner you select will support it. A recommended scanner would be the Fujitsu M 3093 DG. IT supports double sided documents, has a feeder and provides good throughput of 20 pages/minute. For more supported scanners, the following list can help you. Some of them a very expensive and to big for the requirements specified. Manufacturer Bell & Howell Type Firmware Copiscan II 3338A Copiscan II 6338 Copiscan 1000FB Copiscan 1500FB Copiscan 5000FS Copiscan 6000FS Copiscan 8080D DR 5080C IS420 IS430 3500 D/S MCP 1.0.21 5500 D/S MCP 3.30 7500 D/S MCP 3.30 990 D/S MCP 8.51 or SCSI 9.04 9500 D/S MCP 8.51 or SCSI 9.12 Manufacturer Fujitsu** Type M 3091DC M 3093 GX M 3093 DG M 3096 GX M 3097 G+ M 3097 DG M 3099 GX M 3099 GH ScanPartner 300c ScanPartner 600c*** ScanPartner 10c Scanjet IIc Scanjet IIcx Scanjet 3c Scanjet 4c Scanjet 6100c Scanjet 6200c Scanjet 6250c * Only the firmware listed has been tested **Both versions (IPC2 and IPC3) of image processing boards are supported *** Only with firmware 1.04 or higher. Important Notes on Scanners: All the scanners are connected to the scan workstation via a single ended SCSI interface. The only supported SCSI adapters are from Adaptec and are listed in the following section. To achieve the best performance we recommend the use of a SCSI interface for the exclusive connection of the scanner. All Fujitsu Scanners must have at least 4MB Memory For the 3093GX and the 3096GX the 4MB Memory Expansion Board must be ordered Fujitsu Part Number 4MB CMP2 CA01952-D196 The Image Processing Circuit (IPC) may be added to the Fujitsu 3093 and 3096 Scanners . The IPC board is included with the Fujitsu 3097G+, 3097DG, 3099GX, and 3099GH scanners. An Endorser may be added to the Fujitsu 3099 Scanners All Kodak scanners must have an additional dedicated SCSI board in the scan station. Consult IXOS before any Kodak scanner is purchased. All Bell & Howell scanners must be ordered with the Bell & Howell SCSI Interface box
Canon Ricoh Kodak*
Hewlett-Packard
SUPPORTED SCSI ADAPTERS ON WINDOWS NT The following SCSI adapters are the only supported method for connecting scanners and jukeboxes to Windows NT. Computer Bus PCI Type Manufacturer AHA - 2940 Adaptec AHA - 2940 U / AU (Ultra) AHA - 2940 UW (wide)* AHA - 3940 AHA - 3940 U / AU (Ultra) AHA 3950 U2 (Ultra Wide)* * Wide to narrow SCSI adapters must be terminated
http://www.adaptec.com R/3 Retrieval Client (32 bit) NT 4.0 or Win2000 (For Windows 2000, the manufacturers requirements for the operating system are also adequate for IXOS-ARCHIVE components) Pentium 166MHz (Intel compatible) 64 MB RAM 200 MB free Hard Disk space Network adapter 21 monitor (1280x1024 resolution) for frequent retrieval (posting clerks using early archiving) 17 monitor (1024x768 resolution) for occasional retrieval (occasional document retrieval)
Other comments
Printlists: The number of yearly saved printlists of 72 appears to be low. You should expect to create more. The good news is that making this twenty times the original amount with 25 pages each will still not impact this configuration. Read Access: Number of read access in peak time of 25. This value appears to be high. Yet, it is still in the ranges that would not impact network access and this configuration.

IXOS Server PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IXOS Server PDF

Uploaded by

Copyright:

Available Formats

IXOS Project on Document Imaging

The following is a simple representation of a typical IXOS configuration:

How was IXOS used by DIS?

Late archiving with Workflow Late archiving with Barcode.

Training and Reference Material

Typical Roles IXOS Administrator

IXOS Expert Service Center (ESC)

BUFFER POOLS LOGICAL ARCHIVES

EXCHANGE DIRECTORY DATA PIPELINE BACKUP

Installation completed Feb 22,

/exchange/<SID>/archive and is 160Mb mirrored.

DIS Imaging Project

Please see J:\AMS\IXOS\Plan\Technical.xls, and select the Basis tab.

Receipts Document Type Installation

Please see J:\AMS\IXOS\Plan\Technical.xls, and select the Receipts Setup tab.

DIS: Install Plans:

See the QNA tab in J:\AMS \IXOS\Plan\Technical.xls.

See the AMS tab in J:\AMS\IXOS\Plan\Technical.xls.

Error in ArchiveLink-DLL viewer not communicating with IXOS Server

tested by Wes Moon in FIS and moved to production transport FISK937021

Caused by doing RFC Connection Test

Viewer 4.2 has profiles Wes investigating

archive server definition for new 4.2A viewer was corrected

Configuration of DIS Imaging Documents

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

Creating Business Objects

Note: Objects cannot be local objects as they must be transportable.

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

Must add IFARCH21, the SAP ArchiveLink Interface to the folder

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

How data is scanned in: Menu path to scan documents in

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

Detail screen for a form

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

ARCHIVE SYSTEM REQUIREMENTS OF OPERATIONS STAFF

H:\00amswebsite\amsweb_bkup_January23_2002\overview\ IXOS_documentation.doc Date last changed: March 6, 2001

Right click on the "localhost" button and select Connect

Repeat for all WORMs returned from the vault.

NT 4.0 Installation of Scan Client and V4.1 notes

IXOS Server and Jukebox Hardware

PROJECT ORGANIZATION AND RESOURCES

Document Management for DUR

Document Management for DUR

Appendix B: Relevant OSS notes

Appendix C: Consultants Report

Document Management for DUR

Business Document Imaging for SAP R/3 using IXOS-ARCHIVE

Business Document Imaging for SAP R/3 using IXOS-ARCHIVE

Business Document Imaging for SAP R/3 using IXOS-ARCHIVE

Business Document Imaging for SAP R/3 using IXOS-ARCHIVE

Business Document Imaging for SAP R/3 using IXOS-ARCHIVE

Documents are scanned or imported from the Fax Server Scanners

Scanning Scenario is chosen in SAP Late Archiving

Client PC File system DesktopLink