3

I have implemented and event system that changes component after publish/unpublish and adds time stamp in component field. The component is shared among different publications and we always do publishing in all child publications. So for every website, we change the same component and update the same field. The problem is that our event system does checkout/save/checkin action over component, and so do all other treads of it. Also, we have 2 out-scaled publishers that do this action. The problem that we observed, is that once component is checked out in event system, resolver gets crazy and in another tread resolves items to less number of templates then needed. This way component stays published with some of the templates in some publications. We tried to implement lock over component change action, but it doesn't fix our issue. Additional problem is that we have 2 out-scaled publishers so lock is not possible in that case. We have also contacted SDL customer support and they told us that it is possible that resolver can do this and that we must ensure that it doesn't vi implementation.

So to make it plastic:

  1. tread 1: resolves component, unpublishes it and start changing it
  2. tread 2: resolver tries to resolve same component, see that its locked and somehow resolves it to less items (component should be unpublished with 7 templates but it gets resolved and unpublished to for example 4).

So my question is how? We cannot localize component in child publications because of requirements.

UPDATE AFTER RESPONSES: I just wanted to clarify based on provided answers. I agree that implementation should be changed, but what i don't understand, and what this question is really about, is Why is resolver affected by event system. Ok, i understand that ES is changing components (checkout/save/checkin). But even with these operations, shouldn't resolver get latest major version and resolve it to correct number of component presentations?

  • One option could be to write the timestamp + component uri to an external database (With the eventsystem, possibly async). Write a windows service (or powershell script, or... you get it ;) ) and run this every hour. Or every minute. Or push it to a queue and write a queue listener... – Albert Romkes Mar 13 '17 at 14:12
  • Could be worse.... I once inherited a system that did this on component save. – Dominic Cronin Mar 13 '17 at 19:39
  • Some clarification: on component (un)publish you write the timestamp and component-uri to a (Apache MQ) queue. A (windows)service listens to this queue and updates the component-field with the core-service. It's not an ideal solution, but if you can't change the current implementation... – Albert Romkes Mar 13 '17 at 19:54
3
+50

Since you are updating component after publish with datetime, I assume that you need that information on content management side and not on delivery side.

If the above assumption is correct then the question why are you storing it as part of component? There could be two alternatives to store these data:

  1. Create another component with key / value pair and in that component key will be component name and value will be the datetime value that you need.
  2. Store the datetime information as part of AppData and event system has access to appdata for which you don't need to do check out / in.

The reason I am suggesting it to separate the storage of datetime as those are related to component only in case of publish so all other operations related to update should not affect these data.

Hope this helps

Update based on feedback

Many a times, I have seen client defining how particular solution should be implemented rather than giving the actual requirement. Here, the requirement seems to be that when component is opened they should be able to see the last published datetime.

If you go by the requirement and not the direction of how to implement it, given below is the solution:

  1. Store the last publish datetime by either of the approach given above.
  2. Write GUI extension that extends ComponentView
  3. In GUI extension, retrieve the data from appdata or other component and display it.

So even though data is not part of component, it still gives the feel that those are stored together.

  • I couldn't agree with you more. :D And to answer your question why we change field in component that we publish, the answer is CLIENT REQUEST. On multiple sessions we wanted to provide them PublishInfoData with all info, but no, they requested additional field. So, only solution for us at the moment is to make it work via event system. – Marko Milic Mar 13 '17 at 13:44
  • 2
    Storing it in AppData gives you the advantage that you don't need to check-out/check-in to deal with updates... but then indeed you need a UI extension to show this data. Would maybe be a simple one to add to a list? – Nuno Linhares Mar 13 '17 at 14:27
  • @NunoLinhares - When you are saying, add to a list means, add as a field to component, is that correct? – Hiren Kaku Mar 13 '17 at 14:29
  • 1
    I meant as an added column in a CME folder list, as explained here: docs.sdl.com/LiveContent/content/en-US/… – Nuno Linhares Mar 13 '17 at 14:57

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.