14

We have the following situation: a large amount of components are published to a broker database and are also deployed to a SmartTarget server.

As this content is no longer relevant to be in SmartTarget, we wish to remove this content from SmartTarget, but not from the broker. I know unpublishing the content sends a delete xml to the SmartTarget server, so it gets removed from there, but we can't just unpublish all this content, as it needs to stay available in the broker (this is a live site).

I was wondering if there is a standard, supported method of removing content from a SmartTarget server?

Additional note : we can't simply remove the entire SmartTarget database, as some of the items need to stay - so we need to be able to specify which items should be removed, and which ones shouldn't.

As the unpublish command sends out an xml like this to SmartTarget, I was thinking of creating such an xml myself.

<items>
   <item identifier="tcm_11-1234-16_tcm_11-1546-32" operation="delete"/>
   <item identifier="tcm_11-6549-16_tcm_11-1546-32" operation="delete"/>
</items>

So is this a supported way of working? Or are there other (better) ways to accomplish what I want to do?

13

What you propose is definitely the approach I would take...

  1. Remove the "publish to SmartTarget" TBB from the Component Templates to make sure items don't end up there again...
  2. Create a set of "delete" operations for Fredhopper (probably scripted to make sure I don't copy/paste the wrong URIs)
  3. Drop this file in the "incoming" folder of Fredhopper

I was going to add "grab a coffee while Fredhopper cleans this up", but it will probably take way less than a second for FH to process this... so no point in even getting up.

  • Just weighing in to say that I also think this is the best solution for the given issue. There are two other possibilities I could think of: 1) Unpublish, remove the "Add to SmartTarget TBB", and then republish. 2) Remove all of the SmartTarget items and republish only the ones you want. Neither of those solutions seem worth it in this case; there's just a greater potential for messing it up :) – Peter Kjaer Nov 29 '13 at 8:54
  • In case you have trouble finding the 'incoming' folder, its something like /data/instances/{instanceName}/data/xml/incoming/batch – Will Price Jul 14 '15 at 8:21

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.