Document Management - Miscellaneous
This page documents miscellaneous information when installing the Document Management component.
Supported Repository Types
In IFS Cloud 21R2, the supported repository types for document storage are:
- File Storage
For more information refer to the end-user documentation under Topics in IFS Cloud / Create and Maintain Document / Document File Repositories. Currently the File Storage repository supports Azure Storage only, but other backends will be added (local ones, in particular). At some point, it will be the only repository type available for Docman and configuration for the different backends will be done in the File Storage.
FTP is now using Passive transfer mode only
In IFS Cloud 21R1 and onwards, the FTP repository type now supports Passive transfer mode only.
Shared repositories require username and password
In IFS Cloud 21R1 and onwards, Shared repositories require username and password. The reason is that our containers run Linux and has no automatic access to file systems outside of it. Read more in the end-user documentation under Topics in IFS Cloud / Create and Maintain Document / Document File Repositories.
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 Cloud database will grow faster if document files are stored in there. If you plan to use large volumes of documents, it is recommended to use the FSS repository type.
Repository types supported in managed cloud
In IFS managed cloud, File Storage and Database are the only options supported. FTP and Shared repositories are only supported on premise.
Events in Document Management
List of events
The following events are automatically registered when installing the Document Management server:
|LU Name||Event Name||Description|
|ApprovalRouting||APPROVAL_ROUTE_COMPLETE||Approval Route is completed.|
|ApprovalRouting||APPROVAL_ROUTE_REJECTED||Approval Route is rejected.|
|ApprovalRouting||STEP_READY_FOR_APPROVAL||New step is ready for approval.|
|ApprovalRouting||STEP_REJECTED_NODOC||Approval Route is rejected.|
|DocDistEngine||USER_HAS_RECEIVED_NEW_DOCUMENT||User has received a new document.|
|DocIssue||APPROVAL_BACKJOB_COMPLETE||Background job completed with unapproved documents.|
|DocReferenceObject||DOC_REFERENCE_OBJECT_INSERT||Insert of document reference object connection.|
|DocReferenceObject||DOC_REFERENCE_OBJECT_UPDATE||Update of document reference object connection.|
|DocReferenceObject||DOC_REFERENCE_OBJECT_DELETE||Delete of document reference object connection.|
|EdmFileOpAnnounce||DOCUMENT_FILE_READ||User read the document.|
|EdmFileOpAnnounce||DOCUMENT_FILE_WRITTEN||User modified the document.|
|EdmFileOpAnnounce||DOCUMENT_FILE_DELETED||User deleted the document.|
|DocumentTransmittal||TRANSMITTAL_NOTIFICATION||Notifying when a deadline of an expected send or receive date of a document transmittal has been exceeded.|
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.
Moving files between document repositories
In IFS Cloud 21R2, moving files between repositories is supported for the File Storage and Database repositories only. This is done from the Transfer Documents page. Refer to that page and the end-user documentation for more information.
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 extra powerful for document files stored in the database. With externally stored files, there is always a higher risk that a user can get hold of a copy of a file.
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.
File Transfer Service (FTS)
The FTS is obsolete in IFS Cloud from version 21R1 and onwards. It is no longer needed since the OData provider/Aurena server provides upload and download of files in a streaming fashion. Behind the scenes, Docman reads or writes the files from and to the configured repisotory (File Storage, Database, FTP or Shared).
Handling very large files
The connection time-out of the FTP servers (FTP repositories) should be increased to a sufficient amount, depending on the sizes of the files to be transferred.
Please note that handling of large files might lower the performance of the client, server machines and network.