File size limitation
- What is the file size limitation for files stored on OpenText xECM Server? Is there a maximum file size imposed by the platform itself, or does it depend on the configuration?
- Are there any recommended best practices for managing large files within OpenText ECM? For instance, are there strategies for optimizing performance or handling files that exceed a certain size threshold?
Thanks you.
Best Answer
-
It appears to be an issue with the Application Server rather than Content Server.
In classic uploads, there is no limitation in Content Server, only in the Application Server.
Here a specific article on Support Site:A different scenario applies to the drag and drop mechanism: The maximum size of a file when using the drag and drop operation is configured on the administration page - 'Core System - Server Configuration' - 'Features' - 'Configure Container Options'.
Towards the bottom, in the third-last section, there is a parameter that limits the maximum number of files that can be uploaded and the maximum size of a single file:
?func=admin.navigationconfig
The information provided above outlines the established procedures for configuring upload limits in OpenText xECM.
If you are utilizing the Module Suite and are in the process of implementing custom, visually appealing webForms for file uploads, you have the advantage of complete control over the process. You can tailor the upload limits to suit your specific requirements.
For instance, when it comes to file uploading, the 'DropArea' widget is an excellent choice. By configuring it appropriately via Content Script, you can set the upload limit according to your preferences.
It's worth noting, however, that these limits should not exceed those set at the server level, as mentioned previously.
The following snippet demonstrates a simple extension and size check implementation in a Content Script:
Key points include:- Line 3: The uploaded file is automatically injected in the execution context as a
java.io.Fileobject and can be accessed via theparams.am_dropFileparameter. - Line 4: The name of the uploaded file is automatically injected in the execution context and can be accessed through the
params.am_dropFile_filenameparameter. - Line 12: If the file exceeds the maximum size, an error is appended to the form object for further handling or visualization.
- Line 15: If the file extension is not among the accepted ones, an error is added to the form object for further handling or visualization.
Note that you have the flexibility to enhance this validation as needed. Additionally, for more precise validation, you might want to include custom or specific libraries, such as the
net.sf.jmimemagic.Magicone, to validate MIME type and ensure that the extension matches the actual file content.3 - Line 3: The uploaded file is automatically injected in the execution context as a
Answers
-
No such thing as OpenText xECM Server but XECM is a product of OT Content Server. Files in the system are governed by architecture. So if your CS is on an IIS front end you have to find from Google or MS site what its maximum upload size is I think from memory it is 4G. Traditionally users on browsers or mobile devices do not have time or need to upload files of a very large nature so APIs exist both SOAP(older) and REST(newer).
In the SOAP realm, a TC-supported SOAP server is able to upload higher file sizes than IIS so it is not uncommon in an organization to run CS on IIS for ease for users facing ones, and for API level integration they would run web services on TC.
REST large uploads has been introduced very new so I am not sure how it completely works
0 -
It appears to be an issue with the Application Server rather than Content Server.
In classic uploads, there is no limitation in Content Server, only in the Application Server.
Here a specific article on Support Site:A different scenario applies to the drag and drop mechanism: The maximum size of a file when using the drag and drop operation is configured on the administration page - 'Core System - Server Configuration' - 'Features' - 'Configure Container Options'.
Towards the bottom, in the third-last section, there is a parameter that limits the maximum number of files that can be uploaded and the maximum size of a single file:
?func=admin.navigationconfig
The information provided above outlines the established procedures for configuring upload limits in OpenText xECM.
If you are utilizing the Module Suite and are in the process of implementing custom, visually appealing webForms for file uploads, you have the advantage of complete control over the process. You can tailor the upload limits to suit your specific requirements.
For instance, when it comes to file uploading, the 'DropArea' widget is an excellent choice. By configuring it appropriately via Content Script, you can set the upload limit according to your preferences.
It's worth noting, however, that these limits should not exceed those set at the server level, as mentioned previously.
The following snippet demonstrates a simple extension and size check implementation in a Content Script:
Key points include:- Line 3: The uploaded file is automatically injected in the execution context as a
java.io.Fileobject and can be accessed via theparams.am_dropFileparameter. - Line 4: The name of the uploaded file is automatically injected in the execution context and can be accessed through the
params.am_dropFile_filenameparameter. - Line 12: If the file exceeds the maximum size, an error is appended to the form object for further handling or visualization.
- Line 15: If the file extension is not among the accepted ones, an error is added to the form object for further handling or visualization.
Note that you have the flexibility to enhance this validation as needed. Additionally, for more precise validation, you might want to include custom or specific libraries, such as the
net.sf.jmimemagic.Magicone, to validate MIME type and ensure that the extension matches the actual file content.3 - Line 3: The uploaded file is automatically injected in the execution context as a
-
Some things to add to all responses above……
While it may be possible to load "large files" into xECM/Content Suite (subject to the web server's limits etc), one should consider the potential consequences. In particular, how will this impact on:
- Search/indexing - do you really want those files to be searchable based on content? And in my general experience, once you get to those sizes, it's usually a waste of resources trying to index the content.
- Versions and storage size. As all documents are version controlled, do you need to consider the permitted number of versions on these items? i.e. if somehow someone edits or adds a version, you'll potentially chew through storage quite quickly. You may want to look at introducing limits on the number of versions in this instance - noting that while there's a setting to enforce max versions on a document, this is global to the system, so if you need to "target" these large files, some form of intervention will likely be required.
- Impact on xECM/CS threading. You may want to consider enabling "direct fetch" and potentially "Browser Document Cache". The first of these should help reduce threads being "held" while users are downloading content. The 2nd will attempt to use the web server cache and if the document can be found there and is current, will use this rather than from the storage provider. Obviously, with caching, consideration to sizing of the web server cache to account for "large files" would also be prudent.
I'd also consider the frequency of ingestion/retrieval of these large files and whether this may impact on users working with "normal files". i.e. ensure that the network and storage architecture account for needs.
Rgds,
David
3 -
If you're dealing with large video files—like those edited in CapCut. understanding OpenText xECM's file size limitations is crucial for efficient storage and workflow management. Many video editors need to store high-resolution project files, so knowing whether xECM allows configurable limits can help in organizing and archiving CapCut projects. Has anyone tried managing large media files within xECM? Would love to hear best practices!
0
Categories
- All Categories
- 124 Developer Announcements
- 54 Articles
- 156 General Questions
- 155 Thrust Services
- 56 Developer Hackathon
- 38 Thrust Studio
- 20.6K Analytics
- 4.2K AppWorks
- 9.1K Extended ECM
- 920 Core Messaging
- 84 Digital Asset Management
- 9.4K Documentum
- 35 eDOCS
- 195 Exstream
- 39.8K TeamSite
- 1.7K Web Experience Management
- 11 XM Fax
- Follow Categories
