Tridion Stack Exchange is a question and answer site for Tridion developers and administrators. It only takes a minute to sign up.
Sign up to join this community
I want to set Expiry Date of Content Items, but I don't want to use a scheduled core service to check for the expired content periodically because Daily Run of Scheduled service would be overhead on the servers.
Is it possible to schedule UnPublishing of Expired Content items (based on Metadata) on Publishing Itself? (Using Deployer Extension )
What you can do is combination of different events in Event System. For example, every time your item is successfully published (transaction state changed to Success), you can schedule same item to unpublish at specific time in future based on metadata. You also must take care of the following issues:
Honestly, I would do this as combination of Core Service and Windows Service. I would have one scheduled windows service which uses Core Service as connection to database, and would take care that item is INDEED UNPUBLISHED WHEN NEEDED.
Also, you can use direct database access to Tridion_cm database, if using core service is to extensive to you. Database in general shouldn't be used, but single select statements can be, if you know the structure of database and items. Also, you should take care of clogging transaction queue with transactions... etc...
You could do that as part of your templates, as a custom resolver or event system.
Then a task would be scheduled to unpublish content at a given date in the future. You'd need to do some testing to ensure that the unpublish task gets changed if you need to change the unpublish date, and also to ensure that it doesn't create a new unpublish task every time you (re)publish the content.
You can do it during render (using templates), resolving (using custom resolver) or deployment (custom deployer). Best case would be to use event system to ensure that your publishing activities are successful.
The simplest would be to schedule a unpublish based on the date that the item is published or a date captured in the metadata. The cons of this is already explained by Marko above.
Since expiration is something that is typically tied with different levels of compliance, you would not want to have a 'brittle' solution. Another solution would be to write all your publish transactions to a custom database based on the publish transaction and item IDs on SUCCESSFUL publish. An expiration job can be scheduled every day (if expiration is based on date only) or a scheduled time intervals (if expiration is based on date and time). This job should use Core Services to unpublish the items and also update the custom database. If an item has been published multiple times during the above interval, you should probably use the latest transaction; which is why a custom job may still be the way to go. The overhead, to be honest, should be very minimal and can be run from publisher or deployer servers in an out-scaled environment.
