To reduce the size of the database significantly, assets can be stored in an external file system (EFS) on the STEP application server rather than in the STEP database itself.
Although asset storage is set to be the file system, when no content is found for an asset in the file system, the asset content is fetched from the STEP database. This makes it possible to migrate assets from the database to the file system without users experiencing missing asset content during the migration process.
No noticeable application performance degradation is registered in the various asset scenarios by storing assets in the file system compared to database storage.
Important: Management of the EFS (including maintenance and back up) is the responsibility of the customer and is not supported by Stibo Systems.
EFS File Names
The files and directory structure of the digital assets should be considered as a strictly internal part of the STEP system, should only be manipulated via the STEP server application, and should never be touched manually. Because modifications to assets within the EFS can jeopardize asset look-up and asset versions, a hashing algorithm is used for storing the files, making it impossible to identify the digital assets in the file structure from the file names.
The file name used for EFS assets is composed of a hashed STEP ID, a STEP Unique ID (UID), and a checksum. The UID includes dimension dependency and revision number data. The result is a file name similar to the following example:
98491cf212354426fede22b5b390d86dd5c9cd82_FS_0idk6sae3-0mtniy1-0vq55rb9yneo0_af1fd43d254f6ae1c0db702e17911ccd31e4e743.jpg
The EFS uses a fixed three-level folder structure, calculated using the first six characters of the hashed STEP ID. Continuing with the sample file name above, and assuming an external file root location of 'L:/ExternalFileSystem,' the path and file name would be as follows:
L:/ExternalFileSystem/98/49/1c/98491cf212354426fede22b5b390d86dd5c9cd82_FS_0idk6sae3-0mtniy1-0vq55rb9yneo0_af1fd43d254f6ae1c0db702e17911ccd31e4e743.jpg
The asset content is stored using a 'write once' algorithm, which means that STEP never updates the content of the EFS file even if new asset content is uploaded to the asset. Instead, a new file is created in the EFS with the new content and the old content file is left untouched.
Dimension Dependent Assets
The EFS supports the situation where assets are declared as dependent on one or more dimension points. The unique ID used for each asset stored in the EFS includes information about dimension dependency. When separate assets exist based on a dimension, a separate UID is generated to store the assets in the EFS.
For example, an asset exists in STEP, and the file is stored in the EFS. A new asset is added to STEP with the same ID as the existing asset but while in a different context. This results in an additional file to be sent to the EFS. The calculated UID of the newly uploaded asset includes the dimension dependency. Since the hashed STEP ID of the asset is the same as the existing asset, the new asset is placed in the same folder structure as a 'sibling' to the existing asset.
Asset Revisions
If an asset's content is updated, a new revision number is generated in STEP, and an additional file is generated in the EFS. The UID includes the revision number, and since the hashed STEP ID is the same as the former revision, the new file is saved as a 'sibling' to the existing file in the same folder structure.
Setting Up and Using an EFS
For additional information on setting up and using an EFS, refer to the following topics:
Once an EFS is configured, Asset Push can be used to make the required assets available to downstream systems, as defined in the Asset Push topic here.