Configuring System Environments > Configuration Storage Directories
  
Configuration Storage Directories
The following sections describe the configuration storage directories for browse collections, menu collections, favorites, and attachments.
Browse Collection Storage
Browse collections are stored in TomcatInstallDir/webapps/qadhome/configurations/
config-name/storage/browse-collections. Each browse collection is assigned a unique ID by the system.
Menu Collection Storage
Menu collections are stored in TomcatInstallDir/webapps/qadhome/configurations/
config-name/storage/menu-collections. Each menu collection is assigned a unique ID by the system.
Favorites Storage
Favorites are stored in TomcatInstallDir/webapps/qadhome/configurations/
config-name/storage/user-data, where subdirectories based on user ID and domain maintain UserMenu.xml files that include favorites information.
Attachments Storage
Default Attachment Storage
By default, attachments are stored in TomcatInstallDir/webapps/qadhome/
configurations/
config-name/storage/attachments, where subdirectories organize the attachments based on domain, program, type, and field. Each directory includes an underscore character (_) at the end by default to account for the possibility of using a blank.
Single WebDAV Repository Attachment Storage
Instead of using the default attachment storage location, you can configure the system to have a single WebDAV repository of attachments across multiple installations.
Instead of using the default path, you can specify a path (a WebDAV location) using the <Attachment>... <WebDAVRoot> setting in the client session configuration file (client-session.xml) file. By default, the setting is commented out. The setting’s default path is ${HomeServer}/webdav/attachments), so that all attachments are stored on the Home Server in /webdav/attachments. To use this path, simply remove the comment delimiters (<!-- and -->) around the statement. To use another location, edit the setting to use a path to some other server; for example:
<Attachment>
<WebDAVRoot>ServerURL/webdav/attachments</WebDAVRoot>
</Attachment>
Note that the WebDAV location should be UTF-8 enabled to support the WebDAV standard.
With the <WebDAVRoot> setting, you have a way to have all the attachments located on a common server.
Database and WebDAV Repository Attachment Storage
Instead of using the default attachment storage or the single WebDAV repository attachment storage, you can maintain the attachment information in the system database while the attachments are stored in a specified WebDAV directory.
This approach gives you the option of storing attachment information in the system database, which provides better control and extra tagging information on the attached files. The actual files remain in a WebDAV-accessible directory defined by QAD Enterprise Applications.
Note: This feature currently applies only to non-component based programs (programs based on procedural, Progress-based technology) and requires QAD Enterprise Applications 2011–Enterprise Edition (or later). Using this feature with a version of QAD Enterprise Applications prior to 2011–Enterprise Edition will require assistance from QAD Services to update the database schema.
This feature introduces the following Document Attachments menu items:
Document Attachment Application Maintenance — Configure the system so that document attachment information will be stored in the database.
Document Tag Maintenance — Define the tags available for document attachments.
Document Maintenance — Select the tags and other metadata for a document attachment.
Documents browse
Document Tags browse — List all the tags, and right-click on a record to list all documents associated with a tag.
Document Tags by Language Code browse — List all tags and language codes.
Document Attachment Applications browse — List all the Application IDs defined in Document Attachment Application Maintenance.
To set up Document Attachments for non-component based programs:
1 Open Document Attachment Application Maintenance.
2 Set Application ID to mfg (enter mfg for attachments to non-component based programs).
3 Set Repository to the WebDAV location where you are storing attachments. For example: http://host.domain.com/.../webdav/.../configurations/default/storage/
attachments
.
Note: The default path for storing attachments (TomcatInstallDir/webapps/qadhome/
configurations/
config-name/storage/attachments) and the storage location in specified in the config-session.xml file’s <Attachment>...<WebDAVRoot> setting is ignored. Instead, the default path for storing attachments is the path specified in the Repository field.
4 Set Repository Type to webdav.
Now, when you add an attachment to a non-component based program, the attachment’s properties include additional information after Key, including Title, Last Author, Audience, Revision, Label, and Tags.
You can define tags you want to have available using Document Tag Maintenance by entering a tag string in the Tag Name field. You can use label terms (for example, ${SALES_ORDERS}) for tags that you want to be translated.
To assign tags you have defined to a particular document attachment, open Document Maintenance and select the document in the Field Name field. Under Tags, select from the tags defined in Document Tag Maintenance. You can include up to 10 tags. Note that you can also define Title, Description, File Type, Audience, Revision fields here.
To determine the document attachments associated with a particular tag, in Document Tags browse, right-click on a row (tag record) and choose Documents by Tag Name. Documents by Tag Name launches in a tab under Document Tags, listing all the documents associated with the tag. The columns in Documents by Tag Name include: Tag Name, Description, Tag Translation, File Name (the file name of the document attachment), Title (title of the document attachment), File Size, File Type, Last Author, and Timestamp.
Additionally, Document Attachment Applications lists the Applications IDs. Right-click on an Application ID and choose Documents by Application ID to list all the documents associated with a particular application ID (for example, mfg).
Attachment Storage Path for Operating System Subdirectory Limit
Operating systems can have an upper limit to the number of files or subdirectories that a directory can have. For example, on some versions of Linux, the limit can be 32,768 (32K). Although this limit is almost never reached, in certain circumstances it is possible to approach it. For instance, if your process of adding attachments to programs in the QAD .NET UI is automated in such a way that an attachment is being added for each invoice, over time the default mechanism for storing the attachment files on the home server can approach the operating system’s limit. If you have an automated process for including many attachments and are running the QAD home server on an operating system with a limit that you might exceed, QAD provides an alternative mechanism for storing attachment files.
The alternative approach uses a hashing algorithm such that the number of subdirectories for storing attachments will always be less than 16,384 (16K). With the alternative mechanism, the directory path used for storing attachments (such as invoices) for item numbers in Item Master Maintenance (ppptmt.p) will change from the default path (attachments/domain_/ppptmt.p__/item-number_) to (attachments/32k/domain_/ppptmt.p_/hash/item-number_).
You can configure whether to use the default mechanism by setting <Bypass32kAttachmentLimit> in the client session configuration file (client-session.xml). The default value for this setting is false. If set to true, attachments will be stored using the hashing mechanism.
Note that if you change the setting from false to true, the attachments previously stored using the default mechanism will continue to be available to the system while new attachments will be stored using the hashing mechanism. No conversion steps are needed. However, if you then go back to the default mechanism, attachments stored using the hashing mechanism will not be visible to the system. The attachment files are all still there in the directory structure, but by going back to the default mechanism for storing and accessing attachments from the system, the system will not have the ability to access the attachments stored using the hashing mechanism.