3

In a distributed environment where we have multiple servers defined under a publication Target, we want only one of the servers in the group be able to write content to the database.

For the other servers we want only to upload the binary files to the file system. In this case, is there a way for the ‘binary only’ content delivery servers to ignore all other content?

I was thinking of removing the defaultStorageId on these servers specifying just a typeMapping for the binary types. However the defaultStorageId attribute is required.

Sample configuration for 'binary only' servers.

<ItemTypes defaultStorageId="defaultDataFile" cached="false">
  <Item typeMapping="Binary" cached="false" storageId="defaultDataFile" />
  <Item cached="false" typeMapping="BinaryMeta" storageId="defaultDataFile"/>  
  <Item cached="false" typeMapping="BinaryVariant" storageId="defaultDataFile"/>
</ItemTypes>

Or is there a better way to manage this on the CMS side where the publication target is defined ?

3

While I agree with Bart that you shouldn't use the Deployer with multiple destinations as a pure high availability option and use a SAN solution where possible, I do see a lot of use cases where only Binaries should be deployed. Think for instance of a subdomain to host images from in case there are a huge amount of images or other binary assets which you want served separately from your pages, or other CDN like approaches.

So, while you can't exclude items to be published when Tridion items are deployed, it is perfectly feasible to publish to one single Deployer Destination and to let a Storage Extension handle Binaries in any way you want. In fact it's only a couple of lines of code if you override the standard Binary DAO:

package org.example.storage.dao;

import java.io.ByteArrayInputStream;
import java.io.File;
import java.io.IOException;
import java.io.InputStream;

import com.tridion.broker.StorageException;
import com.tridion.storage.BinaryContent;
import com.tridion.storage.filesystem.FSBinaryContentDAO;
import com.tridion.storage.filesystem.FSEntityManager;
import com.tridion.util.FileUtils;

public class MyBinaryContentDAO extends FSBinaryContentDAO
{

    public MyBinaryContentDAO(String storageId, 
            String storageName, File storageLocation, FSEntityManager entityManager)
    {
        super(storageId, storageName, storageLocation, entityManager);
    }

    public MyBinaryContentDAO(String storageId, String storageName, File storageLocation)
    {
        super(storageId, storageName, storageLocation);
    }

    @Override
    public void create(BinaryContent binaryContent, 
            String relativePath) throws StorageException
    {
        // Calling the super method will keep the binary managed.
        // Handy when unpublishing
        super.create(binaryContent, relativePath);

        /*
         * At this point you can do anything you like with the binary,
         * like:
         * - posting it to a webservice
         * - copy it to an array of different server shares or paths
         * - change the actual content of the binary before saving it
         * 
         * You can even call the FileUtils static methods (pseudo code):
         */
        InputStream inputStream = new ByteArrayInputStream(binaryContent.getContent());
        try
        {
            FileUtils.copy(inputStream,new File("\\MyShare\\"+relativePath));
        }
        catch (IOException e)
        {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }

    @Override
    public void update(BinaryContent binaryContent, 
            String originalRelativePath, String newRelativePath) throws StorageException
    {
        super.update(binaryContent, originalRelativePath, newRelativePath);

        // see the create method.
    }

    @Override
    public void remove(int publicationId, 
            int binaryId, String variantId, String relativePath) throws StorageException
    {
        // Remove your binary from all the places where you've put it.
        // Should you need the actual content, you can do:
        // BinaryContent contentToRemove = 
        // this.findByPrimaryKey(publicationId, binaryId, variantId);
        super.remove(publicationId, relativePath);

        // Do your removal stuff here, pseudo code
        // FileUtils.removeFile("\\myshare\\"+relativePath)
    }
}

This way, you don't have to fiddle around that much with exotic storage configurations and you don't get to have multiple destinations and deployer setups to maintain.

So while the new Storage configuration is a bit more restrictive than the old Broker configuration, the flexibility you get by having the DAO mechanism imho outweighs that (if you're not afraid of Java).

2

If I am understanding correctly you have 1 publication target with multiple destinations, if that is the case, you can surely do it, basically you will need to configure a deployer for each destination, it means that each destination will have its own cd_storage_conf.xml file where you can specify independent configuration settings like sending some items to the database or file system.

UPDATE:

We cannot skip all other information to be stored because there are dependencies like metadata, link info, references entries that should go to either the database or file system. What you are describing in your comment below it more suitable for a replication tool that can be executed after your first destination has successfully processed.

Other way to do it is by using an storage or deployer extension to replicate your binaries to your other two destinations, I would prefer the replication tool.

  • Yes, 1 publicaton target with multiple destinations. I understand that each destination will have its own cd_storage_conf.xml file. In this case for some of the destinations I want to only store 'binary' type mappings. All other types, I want ignored. Is it possible to 'ignore' all other types ? IE SERVER 1 - store binary types to file system and all other types store in database as default. SERVER 2 - store binary types to file system, ignore all other types. SERVER 3 - store binary types to file system, ignore all other types. SERVER 4 .. (same as SERVER 3). – Brian E. Sep 23 '13 at 17:03
  • I see, I don't think it is possible to accomplish, have you considered using a replication tool instead of the deployer? it seems that you just care about the binaries to be replicated in those 3 servers. You can use Robocopy or any similar tool for it. – Eric Huiza Sep 23 '13 at 17:33
  • It used to be possible to do this with the old broker config by simply missing out the bindings you didn't want. I think this is a completely valid use-case, and if the current configuration doesn't allow it, I'd happily vote for it as an idea on ideas.sdltridion.com – Dominic Cronin Sep 23 '13 at 20:03
2

If I'm reading the question correctly it looks to me like you are looking for a sort of poor mans solution to a high availability cluster.

The first thing I always mention in these cases is that SDL Tridion is NOT a replacement for clustering software, SDL Tridion is a Content Management system which has a Content Delivery tier. Trying to build such a solution based on SDL Tridion's Deployment mechanism will not solve your actual problem of keeping environments in sync if one of the nodes goes down. So if this is your end goal, you really should look into using a SAN and deploying only to a single node through a load balancer and have the SAN handle your replication scenario.

Back to your actual question, what you are trying to accomplish is indeed not possible anymore since the new storage model was adapted. All mappings follow the default unless an exception is defined.

One thing which might still make this possible is by adding a storage extension on the default path, and have that extension just drop the items rather than actually storing them somewhere.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.