local and distributed file storage    

Business objects may have associated documents and other generic files. An OBEROn object may be used to store files that have been generated by any software application. For example, a drawing object can have attached CAD files, a product object can have attached photos, a project can have planning files and so on.
A filespace is a storage location for application files. All files attached to OBEROn objects are contained into a file store. A filespace simply defines a physical place where you can find the file. You can define file stores for documentation files, problem reports, drawings and so on.
A filespace provides:
• Information on the physical storage location of each file put into OBEROn.
• Access to that information.
• Access to files using different access methods depending on the filespace type.
• Full text search. A filespace can be configured to provide full text search
capabilities for the files it contains, but this functionality requires additional indexing software.

Users enabled to manage filespaces (see user access rights ) can create a new instance by clicking the "Add new FileSpace" button from the "Context Design" menu and compile the relative form.

The control that OBEROn has over the physical storage, retrieval, and security of a file is dependent on the type of filespace used and in particular depends on the adopted protocol. You can choose between four types of protocols:

- database: file contents are placed inside database BLOB fields. This results in the fastest processing times and the simplest file maintenance. Database files and information within them are completely controlled by OBEROn. Once a file is put, it can be retrieved only using OBEROn commands and cannot be accessed using any of the system file utilities.

- file: in this case the files are stored in the Network File System (NFS) where the storage location is established by the absolute (mounted) path. Valid paths are also UNC paths on Windows, with the following syntax: \\servername\filesystem\pathname (where servename may be a name with the form: domain.host or IP address for the server). This type of filespace offers a more flexibility than database filespaces in regard to system control while still taking advantage of OBEROn’s access control. Files are maintained by OBEROn although it is possible to access it from the file system.

- ftp: uses the standard File Transfer Protocol to exchange and manipulate files over a TCP/IP-based network, such as the Internet. FTP is built on a client-server architecture and utilizes separate control and data connections between the client and server applications. FTP is used with user-based password authentication or with anonymous user access. The access control is similar to the "file" filespace type: files in ftp (and file) filespaces should not be manipulated or altered outside OBEROn even if they can be directly accessed by other tools.

- http: files are exchanged by a "FileSpace" web service. This service, exposed by a host over a TCP/IP-based network, implements a virtual file system and contains methods that allow the manipulation of folder structures and file content. This kind of filespace provides the least amount of OBEROn control. OBEROn maintains information about the file, but does not control the physical file itself: the naming, maintenance, and general access is controlled external to OBEROn.

The filespaces can use file name hashing, which is the ability to encrypt the file name. If file name hashing is active OBEROn generates a hashed name for each attached file: this name is represented by 8 digit hexadecimal random number followed by a synchronization counter and the filetype related extension.
For example if you attach a file named My_attached_file.log for the "Text File" filetype (extension .txt) the hashed name may be: 14D195A2_03.txt, where counter "03" is incremented for each fileput operation.
When the files are physically stored on disk, the names appear hashed and can be recognized by OBEROn only. On the other hand, if the file name hashing is off, the file names appear in the storage folders with original file names followed by the synchronization counter (i.e. My_attached_file_03.log ) and the application should assure itself the file name collision avoidance inside the filespace.

For file, ftp and http filespace types the physical storage path is identified by the concatenation of <filespace-Path>/<filespace-SubPath> inside the destination file-system.
files. If the filespace will be accessed via FTP or HTTP, the Path can be relative to the username login, but not necessarily it is the root directory of the FTP/HTTP server system.

In addition, hashed files can be organized in such a way that number of files inside each storage folder is limited. If the Use Sub-Folders option is active the filespace physical path is subdivided into more sub-folders and the location for each file is determined by the generated file name. For example you can find the hashed file 14D195A2_08.txt under the
<filespace-Path>/<filespace-SubPath>/14/D1 directory.

Equivalent filespace creation OOQL commands might be:

Filespaces can have alternate storage areas (called localarea) where the data are replicated. The reason for introducing localareas is to enhance performance for clients (or application servers) that require access to a centralized storage space. The replication is asynchronous: files are duplicated to and from mirrored localareas only when synchronizing commands are passed telling OBEROn to do so.
Therefore, when a files is attached to an OBEROn object, it is copied to the user’s preferred localarea if it supports the destination filespace, or if no match is found, directly into the filespace. A filespace can be mirrored to one or more remote localareas; the system keeps track of localarea that contains the most updated file version.
When another user requests the file, OBEROn will attempt the download from the localarea that contains the newest copy, privileging the user's preferred area or in alternative the central filespace. Object attached files can be published to all localareas associated with the filespace by running the OOQL synchronization command .

Users enabled to manage localareas (see user access rights ) can create a new instance by clicking the "Add new LocalArea" and then add it to one or more filespaces.



The equivalent localarea creation OOQL command is:

As said above a filespace can have more than one related localareas, similarly a given localarea can contain replication for more than one filespace. When a localarea is associated with a filespace the physical storage path for files is the following: <localarea-Path>/<filespace-SubPath>
This means that the filespace's replicas are all collected under subfolders inside the localarea Path on the relative filesystem.