General - Alfresco Federation Services - 3.2 - 3.2 - Ready - Alfresco - external - Alfresco/Alfresco-Federation-Services/3.2/Alfresco-Federation-Services/Using/Task-List/General - 2025-03-04

Basic JDBC

This task is for a scenario where if you have extra metadata that points to an external source repository like a JDBC Database 3Sixty will merge that data into your documents as they are being read.

• User Name: JDBC User Name
• Password: JDBC Password

• Driver Class: The driver for the JDBC database. A number of possible drivers are listed here.

  The Database Driver Class supports:

  • com.microsoft.sqlserver.jdbc.SQLServerDriver
  • oracle.jdbc.driver.OracleDriver

• JDBC Url: Url to connect to the database. Each type of database uses a different format. Refer to the linked table for formats.

  JDBC Url examples:

  • jdbc:sqlserver://localhost:1433;encrypt=false;databaseName=Objdemo
  • jdbc:oracle:thin:@dos1029ecm01.eng12.ocl:1521:ora
• ID Field: The field (without table name) which will be used to name binaries queried from the database.
• Query: The query to execute. All results will be added to the document in the format [tableName].[fieldName]

Buffer Binaries to File System

This task will buffer files to temporary directory. In this case the value of the System Property java.io.tmpdir. The task takes a timeout which will fail the document if it does not complete staging in the given amount of time. The default is 10 seconds, but for larger files (100+ MB), we recommend 60 seconds.

Convert Array Value To String

Converts a property on a repository document from an array to a String.

• Delimiter: The delimiter to place in between values of the Array. If left empty will default to space
• Property Name: The array repository document property to convert into a String. The new String property will have the same name. This field cannot be an expression.

Convert String to Boolean

The String to Boolean Task is designed to check the value of a string and return true of it matches the expected value. This is a quick way to convert a string field into a Boolean and is used to manipulate data as it is being processed. You also have the option to specify whether the match should be case-sensitive or not.

Here’s an example:

In the above example, we are going to check the field dc:availability. If the string value of that field equals available (Expected Value) the dc:availability field will be updated to a true (boolean). As we elected not to use case sensitivity, the string AvailAble would also return true. Otherwise, a boolean false value will be stored.

Convert To UTC

This task will convert date fields to the given format, with the given offset.

• Date Fields to Convert: A comma delimited list of repository fields or the output of calculated field.
  • If you do not supply field names, the task will attempt to process all the Job’s Date/Time mappings. Note: only calculated field mappings are available to job processors.
• Offset: Timezone offset.
• Date Time Format: Final format for the field you’re converting.
• Define Date Time Format Check box: Check to define an output format, uncheck to return default format (i.e. 2019-11-05T16:00:00Z)

Date Based Folder Path

This task takes ones of the date fields on the Repository Document and uses it to generate the parent folder path for the document. This mimics how Alfresco stores its data in the filesystem

Configuration

• Repository Document Field: the field to use for the path - can be any date field
• Pattern: The pattern used to break down the date into a folder path

The default is /yyyy/M/dd/kk/mm/ss/

In this case, kk is used for hours.

Example

For the document file.txt, if you set the field to use the modified date '#{rd.modifieddate}' and the date is 1999-04-20T12:01:23, then your path with the default pattern will be:

/1999/4/20/12/01/23/file.txt

Field Lookup

This task is intended to allow users the ability to perform a look-up operation and update the matching fields of the repository documents. This task was originally created for integrations in which certain field values could only be obtained by importing them from an external source.

• Task Name: Name of the Lookup Job Task
• Delimiter: Denotes the delimiter character if values are not in list format.
• Property Field: Path Uses preset configurations to evaluate values against the path
  • File Name Uses preset configurations to evaluate values against the file name
  • Other Property Evaluates a property entered by the user against the given values
• Property Name: A specific property entered by the user. This property will be used only if Other Property is selected from the property field drop-down list.
• Values: Key=Value listing to be used as the source data for the lookup operation.
• Look for an exact match: If set to true, properties that have an exact (whole case) match will be updated. If set to false, properties that contain the entered value(s) will be updated. For instance, if set to true the value 123 will only have a match with 123. If false, a match will be identified if 123 is present in any part of the field and only that portion will be updated with the new value.

3Sixty can utilise any properties that are associated with a repository document. We recommend running a BFS output job with no mappings and Include Un-Mapped Properties set to True. This will generate a xml file similar to the example below and allow you to see what properties are available for your documents:

<properties>
<entry key="document.name">3Sixty Overview.doc</entry>
<entry key="type">document</entry>
<entry key="folderpath">test3Sixty_Setup</entry>
<entry key="document.Culture">en-US</entry>
<entry key="document.Customer">123456</entry>
<entry key="document.Category">training</entry>
</properties>

In the example above you will notice that the document.Customer field has a numerical value associated with it, but not the actual customer name. The task will allow you to import a list of customer IDs along with their associated customer names and update those values as desired.

The updated values will then be available in subsequent job tasks. For instance, you could then use override folder path task to build out a folder structure with the updated values. Using the scenario above, you could build out a folder for each customer by name instead of numerical value.

HTTP

The purpose of this task is to execute a GET or POST HTTP call for each repository document. If the status is any of the following, then processing will continue, if not, the document will be skipped.

200 OK 201 Created 202 Accepted 203 Non-Authoritative Information 204 No Content 205 Reset Content 206 Partial Content 207 Multi-Status (WebDAV) 208 Already Reported (WebDAV) 226 IM Used (HTTP Delta encoding).

• Username/Password: Credentials to access the endpoint
• Action URL: The endpoint being contacted, without parameters
• POST or GET: Selects the HTTP Method
• Request parameters: In the form of param1=value1&m2=value2
  • The ‘values’ can be dynamically created using the Expression Language (see Federation Services Expression Language)
• Send body with request: The body can be raw text and can use the Expression language.
  • If the text begins with the symbols [ or {, then the body will be need to be valid JSON
• Action to take if the call does not return 200 (OK): Continue, Skip or Fail are the options
• Timeout in milliseconds: How long to wait for the call to execute before attempting to continue.
  • If the timeout is reached, the action selected will be used.

JavaScript Processing

This task is a custom operation that allows the user to ask 3Sixty to do things that are not already available in the software. 3Sixty’s JavaScript Task allows you to run JavaScript against a repository document during processing. The task uses the ECMA 5.1 specification to execute the JavaScript against the native Java API. Currently, only one root object is exposed called rd (repository document). Any method that can be called against the repository document can be called using JavaScript syntax.

Fields that are also available:

Variable Name : Variable The Job ID : jobId The Job Run ID : jobRunId

The variable result is automatically declared in each run of the JavaScript task, and its return value can be used to control which documents continue processing.

The task only supports single quotes for strings. Double quotes will cause errors due to how the content of the script is saved to the database.

Pause

This task can be useful when outputting to a repository with rate limits, such as Box or SharePoint.

• Pause in seconds: How long to pause for each document.

Remove Mappings

Removes mappings from a repository document if the field has no values.

• Source Fields: Comma delimited list of the mappings to remove if it has no values.

Two Way Sync

The Two Way Sync Job Task is to filter out any unnecessary documents when doing an incremental sync between two systems. Documents can be filtered by matching MD5 Hash or If the document was just seen in the last run by the other sync Job.

Configuration

For Two Way Sync you will need to set up two Incremental Migration jobs and chain one Job after the other. You will want to put the Job that should win on a collision as the first Job in the chain.

On each Job add the TWO Way Sync Job Task and, if using the MD5 Hash option, you will need to add the MD5 Hash Job Task before the Two Way Sync Job Task.

• Check Last Run: If this document was just moved by the other Job in the Sync to this Repository, then let’s skip it. If you want to sync it back (maybe after a rule/formula set to false).
• Compare MD5 Checksums: Check MD5 Hash of this Document and the Last Document moved by the synced Job. If set to true and MD5 Hashes match, then skip this Document.
• Job ID of Other Job: The Job ID of the other chained Job in this Two Way Sync