The community version of Alfresco 3.4 (currently 3.4.b) has many shiny new features that have been much heralded. I thought that I would make my inaugural Alfresco blog post about a smaller, 'under-the-covers' addition that will hopefully be of use to some of you Alfresco developers out there: new policies for the transfer service.The transfer service was introduced in version 3.3 to provide a means of pushing information out of an Alfresco repository to a receiver. We also built a repository receiver, thus enabling one Alfresco repository to push content to another Alfresco repository. You can read more about the 3.3 version of the transfer service on the Alfresco wiki. In 3.4, the transfer service has been extended to support many-to-one transfer and is used as the basis of the new replication service and also of the publishing mechanism used by Web Quick Start. For those unfamiliar with policies in Alfresco, they provide hook-points that allow you to plug your own java code ('behaviours') into the Alfresco system to make it do what you want it to do. If helpful, you can think of them as being a little like triggers in an RDBMS. There are many policies available in Alfresco, and they are an extremely powerful mechanism to customise Alfresco to your needs.Something that was missing from the transfer service was the ability to hook into transfer-related events on the receiving end, so we have added three new policies that allow you to do just that. These are declared as sub-interfaces of the interface 'org.alfresco.service.cmr.transfer.TransferServicePolicies', and are named 'BeforeStartInboundTransferPolicy', 'OnStartInboundTransferPolicy', and 'OnEndInboundTransferPolicy'. All of these policies are invoked on the node type 'trx:transferRecord' (TransferModel.TYPE_TRANSFER_RECORD).BeforeStartInboundTransferPolicy is invoked by the transfer receiver as soon as a request is received from a remote repository to start a transfer. At the moment a repository may only accept one inbound transfer at a time, and a lock is put in place to prevent more than one. This policy is fired before that lock is put in place, so if a behaviour that is hooked onto the policy throws an exception then the transfer request will be rejected without attempting to add the lock. Behaviours designed to hook onto this policy should specify an operation that follows the prototype defined by the BeforeStartInboundTransferPolicy interface: public void beforeStartInboundTransfer();
OnStartInboundTransferPolicy is invoked after the transfer lock has been put in place and an identifier has been allocated to the transfer, but before the identifier has been returned to the calling repository. The prototype of the operation that needs to be hooked onto this policy is: public void onStartInboundTransfer(String transferId);
OnEndInboundTransferPolicy is arguably the most useful of the three policies. It is fired at the end of an incoming transfer, and gives behaviours that are hooked onto it information about which nodes were created, updated, and deleted during the course of the transfer. The policy is triggered after the transfer has been committed, so allows custom post-processing of the affected nodes to be carried out. The prototype of the operation that is hooked onto this policy is: public void onEndInboundTransfer(String transferId, Set<NodeRef> createdNodes, Set<NodeRef> updatedNodes, Set<NodeRef> deletedNodes);
Together these three policies allow for a number of scenarios that were previously not possible. Hope you find them useful.
