Document Management - Miscellaneous

This page documents miscellaneous information when installing the Document Management component.

When to use this information:

Use this page when you have installed IFS Document Management and want to know about additional information and options that can be useful when Document Management is installed.

Contents

• Events in Document Management
• Database storage
• Content Search
• Sarbanes Oxley support (SOX)
• File Transfer Service (FTS)
• Handling very large files
• Working with document files with a large number of object connections in IFS EE

Events in Document Management

List of events

The following events are automatically registered when installing the Document Management server:

You will find the available attributes on these events in Solution Manager when you create event actions for them.

For the Approval Routing events APPROVAL_ROUTE_COMPLETE and APPROVAL_ROUTE_REJECTED there are two different variables that can be used for defining who should receive the event: DOCADM and RECEIVER. When using the DOCADM variable, the event is sent out to all the administrators of the selected document revision and when using the RECEIVER only the creator of the document revision receives the event.

For all the Approval Routing events, there are two variables named KEY_REF and OBJECT_KEY. KEY_REF contains the real key_ref value with the separate name value pairs (e.g. DOC_CLASS=100^DOC_NO=1146113^DOC_REV=1^DOC_SHEET=1^) and this can be used for formations of where clauses. OBJECT_KEY contains the key_ref value with one of the separators replaced with comma (e.g. DOC_CLASS=100,DOC_NO=1146113,DOC_REV=1,DOC_SHEET=1). This can be used in all the places where the value is shown as an information.

Lastly, for all approval events there are nine attributes named KEY01 to KEY09. These contains the separate values of the primary keys for the object to which the approval routing is connected. For example, for a document, KEY01 to KEY04 would contain the values of the document's class, number, revision and sheet, in that order (the order is like the order of the keys in the keyref). To know which values are there, experiment with the KEY_REF attribute first, to see which keys have values. These values can be used to construct URLs ("links") to the object being approved. These links can be placed in the body of the message in an e-mail event action.

There are a couple of .ins files that contains example actions for the registered events. The filename indicates which Event it belongs to.

Database storage

One of the EDM File Repository Types is Database. When used for a specific document class or set of classes, the document files will be stored in a table in the database, as Binary Large Objects (BLOBs).

The IFS Applications database will grow faster if document files are stored in there. Because of this, to make administration and backup easier, the document file storage table (EDM_FILE_STORAGE_TAB) will use a special tablespace, defined by &DOCMAN_LOB, which in turn is defined as &IFSAPP_LOB.
 

Moving files from FTP or Shared to Database repository

In order to migrate from "old" types of repositories to Database repository a new wizard has been added to the EDM Basic / Repositories form in the windows client. This wizard has two "modes", Online and Batch. Online means to do it right now, locking the client until the operation is done. Batch mode will use a background job.

Important: In order for the background job to work you need to configure a Default Data value called FILE_PATH_FOR_BATCH_TRANSFER. This path should be a path on the application server (where FNDEXT is installed) and it will be used for temporary storage of the files as they are being moved from one type of repository to another. If the application server runs on a Windows machine, the value could be something like d:\ifs\docman\temp or similar.

Content Search

For content search do work in document files, the Database repository needs to be used.

Sarbanes Oxley support (SOX)

The Document Management solution for compliance to the Sarbanes Oxley Act focuses on section 404 and 409 of the law, specifically Management Assessment of Internal Controls and Real Time Disclosure.

Note: The functionality is restricted to document files stored in the database. If you want SOX-control on document files, make sure you use a repository of type Database.

In practice, what the new functionality provides is this:

• Logging of "reads", "writes" and "deletes" of document files. The log can be browsed in the form File Operation Log in Basic Data.
• Event messages are also generated on "reads", "writes" and "deletes" of document files.

A document is "read" when a user in some way was able to look at the document file. Examples of operations in the application where this happens are Edit (Check Out), View and Print. A document was "written" when a user checks in a document file, either new or modified. A document was "deleted" when a user removes a document file.

Technically, SOX works by forcing the client to "announce" that it is going to do a file operation, by calling the method Edm_File_Op_Announce_Api.Announce_File_Operation. If the client does not announce a file operation, it will not get access to the document file (because the document is in the database, we have complete control over the access to it). We can of course control if our own clients does this but we cannot control third party, or rouge (hacked) clients, which is why this announcement concepts is needed. In the end, it is the announce method that does the logging and that generates the Event. The announce method does a COMMIT in the end to make sure that the client does not make a ROLLBACK to try to avoid a log being created.

Log records are by default saved in thirty (30) days, but this can be changed using the SYSCFG-Default Value SYSCFG_SOX_LOG_EXPIRE_DAYS. A batch job that deletes old records job is run once per day.

Make sure you consider the privacy issues using this concept. For example, the form where you can browse the log should probably not be available to all users.

Three templates for SOX Event Actions can be found in the template folder in this release. They are insert files that can be installed from SQL*Plus or similar tool. The Events are already installed.