Advanced use cases

In the previous section, we covered a basic example where a file and it’s metadata is uploaded to Alfresco. Now we will describe some more advanced scenario’s that can be handled in custom metadata actions.

Upload without content

In some cases, we don’t need to upload the content to Alfresco’s content store because it already exists.
E.g. when Alfred Inflow is used for importing nodes that were exported from another Alfresco, the content doesn’t need to be transferred between the two Alfresco’s if the same content store is used.

Alfred Inflow supports this behavior and allows to use an existing content url when uploading documents. To achieve this, we need to add a contentUrl to the outgoing FileInfo in the metadata action:

FileInfo outgoing = new FileInfo();
outgoing.put(Parameters.PARAM_CONTENTURL, "contentUrl=swarm://2018/12/13/9/20/12cd394c-ea31-46a9-aee5-bf977faab371...");

When the content url is provided, Alfred Inflow will not try to upload any content to the Alfresco content store and uses the provided content url to create a record in Alfresco.

Uploading new versions of a document

Alfred Inflow supports uploading new versions of existing documents. To achieve this, some version information can be attached to the outgoing FileInfo.

FileInfo outgoing = new FileInfo();
outgoing.put(Parameters.PARAM_VERSIONINFO,
        new VersionInfo.Builder()
        .setEnableVersioning(true)
        .setVersionType(VersionInfo.VersionType.MAJOR)
        .setVersionDescription("New version of this document")
        .build()
);

The value of this parameter needs to have the eu.xenit.move2alf.model.VersionInfo class. If another class is provided, Inflow will reject the document and the upload will fail. As we can see in the example, the move2alf-datamodel dependency provides a builder that can be used to generate a VersionInfo object.

Following parameters can be configured in the VersionInfo object:

  • enableVersioning
    Indicates that Inflow is allowed to create a new version of the document if the document already exists in Alfresco. Defaults to false, which means Alfred Inflow does not create new versions of existing documents by default.

  • versionType
    Indicates the type of version that will be used if a new version is created. Defaults to MAJOR and can also be MINOR

  • versionDescription A description that will be added to the version if a new version is created.

Some other things to keep in mind when enabling versions in Alfred Inflow and Alfresco:

  • Alfresco and therefore also Alfred Inflow does not support versioning for folders.
  • If we indicate that versioning is enabled but the document does not yet exist in Alfresco, Inflow will just create an initial version as it would if verisoning was not enabled.
  • When creating multiple versions of the same document in a single cycle, the versions should be bundled into a single package. If not, it is possible that different versions are created in separate transactions and Inflow cannot guarantee a correct working.

Locating existing Alfresco nodes with custom code

By default, the Inflow backend locates existing Alfresco nodes based on the path. In some cases, we wish to locate existing nodes with custom logic. E.g. when Alfresco contains a policy to move nodes to another folder structure, Inflow cannot match existing nodes based on their path.

To support custom node location logic, Alfred Inflow allows customers to implement a NodeLocatorService, which will be used to match uploaded documents to existing Alfresco nodes.

Developing a custom NodeLocatorService implementation

The NodeLocatorService interface is exposed as part of the public Inflow backend API. Therefore, the project that builds the custom implementation needs following dependency:

compileOnly "eu.xenit:inflow-backend-lib:${your-Inflow-version-here}"

This Inflow backend is an Dynamic-Extensions OSGI bundle that exports the required public API packages. Custom bundles containing NodeLocatoreService implementations can import these public API packages.
The Inflow backend will search at runtime for NodeLocatorService implementations that are available in the bundle context. For all found implementations, the locateNode(PipelineDocument pipelineDocument) method is invoked to locate existing nodes. If no NodeLocatorService if found in the bundle context, the default behavior (search by path) is applied. Since the Inflow backend scans its bundle context for NodeLocatorService implementations, it is important that custom implementations are exposed as @OsgiService.

Custom NodeLocatorService template:

import com.github.dynamicextensionsalfresco.osgi.OsgiService;
import eu.xenit.alfred.inflow.backend.api.NodeLocatorService;
import org.springframework.stereotype.Service;

@Service
@OsgiService
public class CustomNodeLocatorService implements NodeLocatorService {

    @Override
    public String locateNode(PipelineDocument pipelineDocument) {
        // Logic that locates an Alfresco node that corresponds to the provided metadata of the PipelineDocument

        // returning null means this NodeLocatorService couldn't locate a corresponding node
        return null;
    }
}