Archive hierarchy

Archive hierarchy is a consumer that creates a nested hierarchy with one or more levels of subfolders. It is used to archive jobs into a structured hierarchy at the end of a flow. The resulting jobs are to be consumed (and removed) by an external process. The backing folder (on disk) for an archive hierarchy should typically be user-managed.

It is not allowed for an external process or a user to place files into an archive hierarchy.

An archive hierarchy uses the hierarchy location path stored in a job's internal job ticket to determine where the job should be stored, up to the nesting level specified for the archive hierarchy. Any superfluous segments in a location path are ignored. Subfolders are created automatically.

See Using hierarchy info for more details.

Keywords

If you enter one of the following keywords in the Search field at the top of the Flow elements pane, the Archive hierarchy element will be shown in the list:

backing
folder
subfolder
structure
output

Connections

The Archive hierarchy allows outgoing traffic light connections. With the help of these traffic light connections, you can fail files that were not archived properly and you can also send a notification to the administrator or IT department about this problem.

With the Archive hierarchy tool, you can first archive your files and later send email notification to internal operators, CRMs, etc. You can also store your files in the internal Archive before uploading them to an FTP Server to make them accessible to external users.

Properties

Property	Description
Name	The name of the flow element displayed in the canvas
Description	A description of the flow element displayed in the canvas. This description is also shown in the tooltip that appears when moving your cursor over the flow element.
Path	The path of the archive hierarchy's backing folder on disk, or "auto-managed".
Subfolder levels	The number of nested subfolder levels in the archived structure; see also the description on subfolders earlier.
Safe move	This option is only relevant for transferring job files between folders on different volumes (drives/partitions). If set to Yes (default value), Switch will first copy the job to a temporary file before deleting the job from the original location. This is useful to avoid that files get lost in case of network problems. If set to No, Switch immediately moves the job files to the Archive hierarchy. This may be necessary in case of network permission issues.
Strip unique name	If set to Yes, the unique name prefix added to the filename by Switch is removed before placing the job in the archive hierarchy; the default is to strip the prefixes from jobs deposited in an archive hierarchy - leaving the prefixes in place avoids overwriting a previously deposited job with the same name
Duplicates	Determines what happens when Strip unique name is set to Yes and a job arrives with the same name and location as a job already residing in the hierarchy: Overwrite: replace the existing job with the new one – this is the default behavior. Keep unique name: preserve the new job's unique name prefix, leaving the existing job untouched (without unique name prefix). Add version number: add an incrementing version number at the end of the filename body for the new job ("2", "3", … "9", "10", "11"), leaving the existing job untouched. For example, "job.pdf" will become "job1.pdf"," job2.pdf", ... Optionally, you can add a separator between the filename body and the version number, for example an underscore. In that case, e.g. "job.pdf" will become "job_1.pdf"," job_2.pdf", ... By default, the Separator property is empty. You can also determine the width of the version number, i.e. the number of digits used for the version number. For example, if Width is set to "5", the version number will consist out of 5 digits (e.g. job_00001.pdf), meaning that leading zeros will be added as required. Fail: move the new job to the problem jobs folder, leaving the existing job untouched.