Bulk File System

The BFS Connector is useful for outputting files and their metadata as separate entities. File binaries will be output with their metadata in a file with the format. It can also read in these files for export to other systems.

[filename].metadata.properties.xml

Integration Connection

Most Integration Connections can act in both repository (read) and output (write) modes. If it can't, it will not appear as an option when creating or editing a job. This connection can only be used as a repository connection. Click here for more information on setting up an integration connection.

Configuration

  • Connection Name: This is a unique name given to the connector instance upon creation.

  • Description: A description of the connection.

Job Configuration

Repository Specification

  • Source Directory: The directory to begin crawling for BFS files.

  • Do not convert metadata keys to lowercase: 3Sixty converts all type and field values to lowercase by default. If this is checked all fields will keep their original case

  • Process Folders: Tells the job to process to folders. If checked and the job is rerun for errors, folders will be processed again.

  • Process Files: Tells the job to process files. Check by default

  • Check for multi-valued fields: Will check for commas in field values. If present, they will be added as multivalued fields to the metadata

Output Specification

  • Name: Name of your BFS Auth Connector

  • Output Folder Path: The output directory location where your BFS files will be stored

  • Multi-Value Separator: Multi-value fields will be combined into a list using this separator

  • Include Un-Mapped Properties: If selected, all available properties will be included in the metadata output file. If not selected, only mapped properties will be included in file

  • Inherit ACLs: If selected, inherited ACL properties will be included in the metadata output file.

  • Metadata as XML: Creates a metadata XML file. If not selected, metadata will be stored in a properties file

  • Zip Output: If selected, output will be created as zip files. This option can only be used with batch migrations (i.e. batch size must be greater than 0).

  • Aspect Remove Field Mapping: Takes a JSON string. Remove aspects if the listed fields are not present.

The example of the UI:

{"myaspect:two":["field1","field2"],"myaspect:one":["field1","field2"]}

Meaning that if field 1 or field 2 is not present, do not add the aspects.

DateTime Config (Output)

Note:  BFS as an output repository now uses the job's Repository Time Zone and Output Time Zone fields for time zone conversion

  • Date Format: Date mappings will be converted to this ISO format

  • Date Time Format: DateTme mappings will be converted to this ISO format

Version History Files

The import tool also supports loading a version history for each file. To do this, create a file with the same name as the main file, but append it with a v# extension. For example:

  • IMG_1967.jpg.v1 <- version 1 content IMG_1967.jpg.v2 <- version 2 content IMG_1967.jpg <- "head" (latest) revision of the content

This also applies to metadata files if you want to capture metadata history as well. For example:

  • IMG_1967.jpg.metadata.properties.xml.v1 <- version 1 metadata

  • IMG_1967.jpg.metadata.properties.xml.v2 <- version 2 metadata

  • IMG_1967.jpg.metadata.properties.xml <- "head" (latest) revision of the metadata

Additional notes on version history loading:

You can’t create a new node based on a version history only. You must have a head revision of the file. Version numbers do not have to be contiguous. You can number your version files however you want, provided you use whole numbers (integers). The version numbers in your version files won’t be used in Content Services. The version numbers in Content Services will be contiguous, starting at 1.0 and increasing by 1.0 for every version (so 1.0, 2.0, 3.0, and so on). Content Services doesn’t allow version labels to be set to arbitrary values, and the bulk import doesn’t provide any way to specify whether a given version should have a major or minor increment. Each version can contain a content update, a metadata update or both. You are not limited to updating everything for every version. If not included in a version, the prior version’s content or metadata will remain in place for the next version. The following example shows all possible combinations of content, metadata, and version files:

  • IMG_1967.jpg.v1 <- version 1 content

  • IMG_1967.jpg.metadata.properties.xml.v1 <- version 1 metadata

  • IMG_1967.jpg.v2 <- version 2 content

  • IMG_1967.jpg.metadata.properties.xml.v2 <- version 2 metadata

  • IMG_1967.jpg.v3 <- version 3 content (content only version)

  • IMG_1967.jpg.metadata.properties.xml.v4 <- version 4 metadata (metadata only version)

  • IMG_1967.jpg.metadata.properties.xml <- "head" (latest) revision of the metadata

  • IMG_1967.jpg <- "head" (latest) revision of the content

API Keys

BFS Connector: Read=true: Write=true: MIP=false

Repo (Read) Specs

Key

Description

Data Type
sourceDirectory Source Directory String

bfsNoLowerCase

Do not convert metadata keys to lowercase

Boolean

processFolders

Process Folders

Boolean

processFiles

Process Files

Boolean

checkMulti

Check for multi valued fields

Boolean

bfsMultiValueSeparator

Multi-value field separator

String

Output (Write) Specs

Key

Description

Data Type
outputfolderpath Output Folder Path String

multivalueseparator

Multi-value field separator

String

metadataasxml

Output Metadata as XML

Boolean

includedUnMapped

Include Un-Mapped Properties

Boolean

inheritAcl

Inherit ACLs. If processing ACLS The parent's ACL list will be merged into the child's.

Boolean

zipoutput

Zip Output

Boolean

includeAspect

Include Aspects With No Field Mappings

Boolean

arfm

Aspect Remove Field Mapping

String

bfsDateFormat

Date Format

String

bfsDateTimeFormat

Date Time Format

String

Need help using the BFS conector? We can help.