Document Management File Handling Architecture - IFS

White paper
Document
Management File
Handling
Architecture

content
Introduction............................................................................................................. 1
About this document .............................................................................................. 1
Like any other component....................................................................................... 1
...but different ....................................................................................................... 1
Document Titles, Document Revisions, File References
and Document Access ............................................................................................ 1
Document Title (lu DocTitle) .................................................................................. 1
Document Revision (lu DocIssue)........................................................................... 2
File Reference (lu EdmFile).................................................................................... 2
Document Access .................................................................................................. 2
Document File Repositories .................................................................................. 3
No direct access from the client to the repository .................................................. 3
Pros and cons for the different repository types ..................................................... 3
Migrating documents between repositories ............................................................ 5
File Transfer Service (Fts) .................................................................................... 5
Clients ...................................................................................................................... 6
IFS Enterprise Explorer .......................................................................................... 6
IFS Web Client ....................................................................................................... 6
Running IFS Document Management under Citrix ................................................... 6
Usage on wide area networks (WANs) .................................................................... 7
flow of files in IFS Document Management ........................................................ 7
Oracle AutoVue integration for Document Visualization................................. 7
Technical flow of the integration with Oracle AutoVue ............................................ 8
Integration with Oracle AutoVue ............................................................................. 9
About IFS ................................................................................................................ 10

Document Management File Handling Architecture
Document Management
File Handling Architecture
Introduction
About this document
This document explains the architecture of IFS Document Management in IFS Apps 8.
Beginning with a brief introduction, the document goes on to explain and put
together the different areas to show the flow of data through the application, with
a focus on how files are handled.
Like any other component...
IFS Document Management (“Docman”) is in many ways a typical component, or
product, of IFS Applications. It consists of a number of tables and views in a database,
together with business logic, also stored in the database, as well as a number of
“screens” (forms, web pages) in our clients: IFS Enterprise Explorer (“IFS EE”) and
IFS Web Client (“web”).
These screens work like all other screens in IFS Applications; you create records,
you perform various operations or commands to manipulate the records, and you
search for the records and navigate around in the component.
...but different
Docman, however, differs in one crucial aspect: we handle files for the user. Although
Docman has support for storing information about “originals” (paper drawings,
magnetic media, microfilm etc.), what people use most of the time are electronic
media, i.e. files. These files range from simple word processing documents to complex
3D-CAD structures consisting of hundreds or thousands of different parts.
Document Titles, Document Revisions, File References
and Document Access
Before we go into detail about file handling, a brief explanation of our main database
objects will be useful.
Document Title (lu 1 DocTitle)
The document title is the umbrella for a document. It contains attributes like
document class, document number and the title of the document. A title will contain
one or more document revisions.
1. LU—Logical unit. A business object including storage and business logic in IFS Applications.
1

Document Management File Handling Architecture
Document Revision (lu DocIssue)
The document revision is what most people talk about when they refer to a document
in Docman. This is where most of the action takes place.
The document revision has five states: Preliminary, Approval In Progress,
Approved, Released and Obsolete. You start with a preliminary document, then it
optionally goes through a chain of approval steps, it gets approved and released, and
ultimately it might become obsolete—and is set as such.
When a document is released and you want to change it, you create a new revision.
Then you get a new document revision in Preliminary state that you can start to
work with.
Each document revision can have one or more file references connected to it.
File Reference (lu EdmFile)
The file reference is what the name says—a reference to a file. It is not the actual file,
but a pointer to it. It keeps information about where the file is stored (in which
repository and path), it stores the file’s name in the repository, and it also stores the
original name of the file, if there is one (files created from inside IFS Document
Management do not have an original file name in this sense). You can also see what
type the file is and if it is the original file or a view copy.
Original files and view copies
A document revision can have more than one file reference. The most common case
of this is that you have the original file and a view copy. The original file is the main
file, or master file, if you will. It will be the Word document or AutoCAD drawing
or Excel spreadsheet that you want to store in Docman. Then you can have a view
copy as well if you so choose. Typically it will be a PDF version of the same document
that you keep in sync with the original file and which can be used by people that are
not interested in opening the original file or cannot access the native application
required to view the document, such as an expensive CAD package, but still need to
see the document. If PDF files and similar are used, these files also have the benefit
of being read-only, so the risk of tampering by recipient is eliminated.
Apart from original files and view copies, Docman can store comment files and
“extra” files, but this will not be explained here.
Document Access
The last main piece of the document management puzzle is the document access
thatyou can define for each document revision. It consists of a list of persons and/or
groups as well as references to other business objects. A line containing a person will
grant that person certain access and a line containing a group with grant certain
access to the persons contained in that group.
Currently there are three levels of access for each line: View, Edit and Admin.
View access means that the document file can be viewed. Edit access means that the
2

Document Management File Handling Architecture
document file can be edited and deleted. Admin access means that the document can
be administered (i.e. the persons granted this access can control access and change
status of the document).
The document access can also be partially controlled by other business objects
that the document is connected to. Examples of this are projects and invoices where
these objects have special access control and business logic used to determine what
access the end-user has to a particular document
There are more details to document access, but these are explained in the end-user
documentation.
Document File Repositories
The files connected to the documents in Docman are stored in special document file
repositories. There are currently three supported types of repositories; Shared, FTP
and Database:
• Shared: The most basic one. The files are stored in a folder somewhere on the
network, where the application server can access it (read and write).
• FTP: The files are kept in a folder in an FTP server.
• Database: The files are stored as BLOBs (Binary Large OBjects) in a database
table.
No direct access from the client to the repository
There is never any direct file access from the client PC to where the files are stored.
The files are transferred using HTTP to and from the application server, which
takes care of reading and writing the files to and from the different repositories.
Pros and cons for the different repository types
Shared
This is the oldest and simplest of the repository types. The least secure of the
repository types since the files are simply stored in a normal file system folder on
the network. It is important that only the application server can access this folder,
otherwise persons with the appropriate access in IFS Document Management might
get access to sensitive files. Also, it is important to make sure that the application
server can access the folder, so if it is on a different machine than the server itself,
UNC paths (\\server\share\path\) are recommended (using mapped drives under
Windows can be problematic if the drive letters change, for example.)
Pros
• Easy to setup and understand.
Cons
• Least secure.
• No support for document content search.
• No support for file operations logging/SOX (Sarbanes Oxley).
3

Document Management File Handling Architecture
FTP
Although no encryption is used (Docman currently does not support FTPS/SFTP),
the extra layer of security using a username and password for the FTP server makes
this more secure than using Shared repositories. The FTP protocol is old, trusted,
and well known. You can run a FTP server on many different platforms and get the
same experience.
Pros
• Known technology. Easy for most customers to handle today.
• More secure than Shared repositories but still not very secure.
Cons
• Username, password and data is sent unencrypted.
• No support for document content search.
• No support for file operation logging/SOX (Sarbanes Oxley).
To consider
• Administration of an additional server.
Database
This is the latest addition to the list of repository types. The document files are kept
in a BLOB in the database so no extra servers or applications are needed.
Pros
• No extra setup is required, it just works.
• No administration of anything.
• Very secure. If required, the connection to the database can be encrypted. Even if
a user can log on to the database using some tool, he can only access the document
files he has access too since they are protected by the view on the document file
table.
• Document content search functionality.
• Supports file operation logging/SOX (Sarbanes Oxley).
To consider
• Backup and restore when there is much data can be a challenge (however, a few
customers have several TB of data without any problems), especially since the
time for taking a complete backup will increase. Defining backup strategies
require good Oracle competence and experience and the increase in data when
storing documents in the database might require a change in backup strategies,
maybe also requiring a higher budget for backup handling. Currently there are
no official recommendations on how to handle this. It is hard to give detailed
4

Document Management File Handling Architecture
recommendations on how to handle backups, but here are some general pointers:
• Use RMAN.
• Take incremental backups. Be aware however that some of the advanced
options are only available in the Enterprise Edition of Oracle.
• Parallel backup and restore can be a solution to long backup times. Enterprise
Edition only.
• An alternative to using Oracle’s own backup tools is to use disk mirroring
and keep a mirror of the database disk at all times. By stopping the mirroring
you will automatically have a complete backup from the time you stopped it.
• Restoring single documents from backup is more time consuming since the
whole database will need to be restored to some point in time.
• Storage overhead for small files can be an issue. Since each file is kept in a BLOB
column in an ordinary database table, it is eventually stored in a database block
in Oracle. If a file is smaller than the configured block size of the database, then
it still takes up one full block (not as with other records where one block can
contain data from more than one record). So for documents that are only a few
KBs in size, there can be a big overhead in percentage. For documents of hundreds
of KBs and up, the overhead is negligible however.
Migrating documents between repositories
Since IFS Applications 7, a tool is provided to help with migrating document files
from one file repository to another. Moving files from FTP to Database is the main
purpose, but it works in any direction.
File Transfer Service (Fts)
The File Transfer Service, or FTS, provides the means to transfer the files between
the client and the application server over HTTP using normal HTTP POST and
GET (HTTPS/SSL works as well, of course). The FTS is built using Java Servlet
technology and runs inside the application server/JEE Container.
Since no authentication is done in the FTS, special tickets are used instead. When
users want to access a file in the system, either checking it out or checking it in, the
system first makes sure they have the necessary access permit. If so, the client receives
a ticket as a proof that the users can check in or check out files against a certain
document revision.
For example, if a user wants to view a document file, the application server will
place a copy of the file in a certain folder where the FTS can read it and will return a
ticket to the client program. The client will then make a request to the FTS using the
document ID and the ticket, and the FTS will respond with a file stream so that the
file can be saved and opened.
5

Document Management File Handling Architecture
Clients
IFS Enterprise Explorer
In IFS EE all file handling goes through the FTS. It works as explained above.
IFS Web Client
Although the web client could handle files through the FTS it does not, for various
reasons. One reason is that the web server is most often on the same machine as the
application server, and it would affect performance negatively to make an extra
HTTP call to the FTS when we are already “on the inside”.
However it works a bit differently depending on which repository type is used:
• FTP: The web server makes the call to the FTP server directly. So if the web
server is running in its own application server, the firewall must accept active
(not passive) FTP transfers from the web server.
• Shared: Currently not supported by the web client.
• Database: The web server cannot directly read the file from the database so the
application server does it and places it in a shared folder where both the web
server and the application server can read and write. This folder is identified with
two default values defined in Docman: SYSCFG_SHARED_PATH_FNDWEB
and SYSCFG_SHARED_PATH_APPSERVER.
Running IFS Document Management under Citrix
Although the point of running IFS Applications under Citrix is not that big now
that IFS EE exist and the old windows client is gone, customers will still want to do
it, for various reasons. If you do this, there are some things to think about:
• All applications needed to open documents must be available on the Citrix server.
Since the file is actually opened on the Citrix server itself, it must have the
necessary program to open the file. For a user running IFS in Citrix seamless
mode this might not be self-evident. The same goes for document macros, if those
are used. Whatever those macros are doing/using, it must be available on the
Citrix server. Also, for heavy applications like 3D-CAD and similar, make sure
it runs well under Citrix (no lag, for example) before you go for such a solution.
• Think about how close the Citrix server is to the application server. This is a
general concern but especially important for document files since they can be
quite big. The data transfer is done between the Citrix server and application
server and not between the end-user’s PC.
• Special functions in IFS EE, for example drag/drop of files from the client to
document management will not work when using Citrix.
6

Document Management File Handling Architecture
Usage on wide area networks (Wans)
In IFS Applications 8 all file handling goes through the application server, and then
out to the client. This means that even if an FTP repository, for example, is “close”
to where a user works, the file transfer might still be time consuming since the
application server must first download it before it will be streamed to the client PC.
In the old windows client, where the files were directly downloaded by the client
program, you could benefit from having a Shared or FTP repository placed locally.
Currently there is no similar solution to this for IFS Applications 8, but see below
for information about the Instant View functionality.
flow of files in IFS Document Management
Now that all bits and pieces are in place we can display the full architecture in a
diagram.
Application Server
File Repositories
IFS EE
HTTP
FTS
Database
Web
Browser
Temp Folder
Shared
Folder
Middle
Tier
FTP
Shared path
HTTP
Web
Server
FTP
Flow of files in IFS Document Management
Oracle AutoVue integration for Document Visualization
In IFS Applications 8 we are integrating Oracle AutoVue with IFS Document
Management. Oracle AutoVue can briefly be described as a powerful platform for
document visualization. The first functionality we will use it for is Instant View,
which is a way for any user to view virtually any type of document file without
needing to have the original application that created the document file. A normal
user might have common word processing or spreadsheet applications installed on
his PC, but most users will not have the means to view advanced 2D or 3D CAD
files.
7

Document Management File Handling Architecture
When Instant View is used, the end-user will never get hold of the actual file.
Instead only the information he needs to see right now is streamed from the Oracle
AutoVue server out to a special viewer (implemented using Java applet technology).
This has at least three additional benefits:
• Security and protection of intellectual property. Since the user never gets hold of
the original file he can never send the original file to someone else. For simple
documents he can still take a screenshot, of course, but for heavy 3D applications
or other large documents it will not be practical to do so.
• Better performance over WANs or bandwidth-limited networks. Since only the
content the user is looking at right now is streamed to the client, it will not require
much bandwidth compared to downloading the full file to the client for viewing.
• Since the file is cached on the Oracle AutoVue Server, if the same or another user
views the document again, it will be quicker than the first time, and this will be
very noticeable for large document files.
In future release of IFS Document Management we will make use of other functionality
in Oracle AutoVue, for example creating thumbnail versions of document files
for direct display in the client, automatic PDF file generation on the server when a
document is checked in or released, and watermarks when printing or viewing
documents Oracle AutoVue has also very powerful functionality for document
markup handling and document review that we might make use of.
Technical flow of the integration with Oracle AutoVue
Here is an overview of the steps done when a user executes the Instant View operation
in the client:
• Create a special user authentication ticket. Since the communication between the
viewer and the AutoVue Server is done without any proper authentication, we use
a randomly generated ticket instead. This ticket is proof that we have an authenticated
user. The ticket is valid for only one minute.
• Open viewer and send in the document ID and ticket.
• Viewer sends request to VueServlet.
• VueServlet pass along the request to the AutoVue Server.
• The AutoVue Server sends a request to the IFS AutoVue Connector (based on
Java Servlet technology).
• IFS AutoVue Connector uses the ticket against the database, which validates and
removes it.
8

Document Management File Handling Architecture
• IFS AutoVue Connector checks to see that the authenticated user have the required
access to view the document.
• IFS AutoVue Connector calls IFS Middle Tier to check out a copy of the document
file.
• IFS AutoVue Connector returns a file stream of the file copy to the AutoVue
Server.
• The AVS streams back only the required image information to the viewer running
on the client.
Integration with Oracle AutoVue
The diagram below shows only the parts relevant to the IFS Document Management
—Oracle AutoVue integration.
Clients
Application Server
File Repositories
IFS EE
Web
Browser
AutoVue
Viewer Applet
HTTP
VueServlet
Middle
Tier
Temp Folder
Database
Shared
Folder
IFS AutoVue
Connector
FTP
HTTP
AutoVue
Server
IFS Document Management—Oracle AutoVue integration
9

About IFS
IFS is a public company (OMX STO: IFS) founded in 1983 that develops,
supplies, and implements IFS Applications , a component-based
extended ERP suite built on SOA technology. IFS focuses on agile
businesses where any of four core processes are strategic: service
& asset management, manufacturing, supply chain and projects.
The company has more than 2,000 customers and is represented
in some 60 countries with 2,800 employees in total.
More details can be found at www.IFSWorlD.com.
For further information, e-mail to info@ifsworld.com
Americas. .................................................................+1 888 437 4968
ArgenTIna, BrazIL, Canada, MEXICO, UnITED STATES
Asia Pacific .............................................................. +65 63 33 33 00
AUSTRALIA, InDOnESIA, JAPAn, MalaySIA, new Zealand, PhILIPPInES,
PR China, SingAPORE, ThAILAnd
Europe east and central asia .....................................+48 22 577 45 00
BALKANS, CzECh REPUbLIC, GEORGIA, HungARy, Israel, KAZAkhSTAN,
POLAnd, RUSSIA and cis, SLOVAkIA, TURkey, UKRAINE
Europe Central .........................................................+49 9131 77 340
AUSTRIA, BelgIUM, GERMAny, ITALY, nEThERLAnDS, SWITZERLAND
Europe West ...........................................................+44 1494 428 900
FRAnCE, IRELAnd, PORTUgAL, SPAIn, UnITED KingDOM
MiDDle East and africa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .+971 4390 0888
InDIA, SOUTh AFRICA, SRI Lanka, UnITED ARAb EMIRATES
Nordic .....................................................................+46 13 460 4000
DenMARk, Norway, SwEDEn
Finland and the Baltic area. ...................................... +358 102 17 9300
ESTOnIA, FinLAnd, LATVIA, LIThUAnIA
www.ifsworld.com
ThIS document may contain statements of possibLE future funCTIOnALITy for IFS’ softwARE products
and technOLOgy. SUCh statements of future funCTIOnALITy are for inFORMATIOn purposes only
and shOULD nOT be inTERPRETED as any commitment or represenTATIOn. IFS and all IFS product
nAMES are trademarks of IFS. The nAMES of actual companIES and products menTIOnED hEREIn
MAy be the trademarks of thEIR respective ownERS.
IFS AB ©2013
En4505-2 Production: IFS Corporate Marketing, September 2013.