Deployer Extension - Handle Binary Unpublish

In case you have written any SDL Tridion Content Delivery Deployer extensions, you have noticed there is no easy way in intercepting the unpublish/undeploy of a binary. This blog post shows how to intercept such an action and execute your custom code on it.

The reason why it is hard to intercept a binary undeploy is because in fact the binary remove does not happen at Deployer level; rather, it takes place in the storage level. So the extension point to be used in not a Deployer extension, but a storage FileSystem or JPA extension.

File System

The following code implements a storage extension that intercepts the removal of a binary from the File System Content Data Storage (fka the File system broker):

package com.tridion.storage.toolkit;

@Component("FSBinaryDAOExtension")
@Scope("prototype")
public class FSBinaryDAOExtension extends FSBinaryContentDAO implements BinaryContentDAO {

    @Override
    public void remove(int publicationId, int binaryId, String variantId,

            String relativePath) throws StorageException {
        // Your custom code goes here

        super.remove(publicationId, binaryId, variantId, relativePath);

        // or here
    }
}

Notice the package must start with com.tridion.storage. Without it, it will not be found during the storage module initialization.

Depending on the requirement, you can place your custom code before or after the call to super.remove.

Database Storage (JPA)

The code below implements a storage extension that uses the Database storage for Content Delivery:

package com.tridion.storage.toolkit;

@Component("JPABinaryDAOExtension")
@Scope("prototype")
public class JPABinaryDAOExtension extends JPABinaryContentDAO implements BinaryContentDAO {

    @Override
    public void remove(int publicationId, int binaryId, String variantId,

            String relativePath) throws StorageException {
        // your custom code goes here

        super.remove(publicationId, binaryId, variantId, relativePath);

        // or here
    }
}

Also note the package must start with com.tridion.storage.

Bundle XML Descriptor

We must configure the custom classes in a bundle XML descriptor file. Below is such a file, in my case called toolkit_dao_bundle.xml:

<?xml version="1.0" encoding="UTF-8"?>
<StorageDAOBundles>
    <!-- Filesystem mappings -->
    <StorageDAOBundle type="filesystem">
        <StorageDAO typeMapping="Binary" 

                    class="com.tridion.storage.toolkit.FSBinaryDAOExtension"/>

    </StorageDAOBundle>

    <!-- Java Persistence API mappings -->
    <StorageDAOBundle type="persistence">
        <StorageDAO typeMapping="Binary" 

                    class="com.tridion.storage.toolkit.JPABinaryDAOExtension"/>
    </StorageDAOBundle>
</StorageDAOBundles>

Place the bundle configuration XML file either on the class-path of your Deployer, or package it in the root position inside your extension JAR.

Final Configuration

The final configuration must be made in cd_storage_conf.xml of you Deployer. Add the following line inside node Global / Storages / StorageBindings:

<Storages>
    <StorageBindings>
        <Bundle src="toolkit_dao_bundle.xml"/>
    </StorageBindings>
...

Restart the Deployer.

With all these configuration and code in place, your custom binary handling code should be called when a Binary is unpublished/undeployed. Remember that in Tridion binaries are only unpublished when they are not referenced anymore by any published Component.