3

What to do when an ECL item is not available anymore in the source repository and Tridion still has components linked to it?

Case: we have a video integration with 23video and 1 of the video's has been deleted from the 23video channel, but the item is still linked in several Tridion components.

Currently we cannot open the components anymore ("Object reference not set to an instance of an object") for editing/unlinking and also publishing fails for these components, as the ECL item cannot be resolved anymore.

2

There is one way to open component:

Open the web dav for the CME and go to the location of the component. Copy the component xml and paste it in file system.

Open xml document and remove the reference to video and then replace the component xml using webdav.

2
  • This could solve the problem for my linked components, thx! But is there also a more 'solid' way for solving this? Because eg this still gives errors in my GUI (when searching for ECL items), because the item cannot be found anymore in the repository. And I would like to prevent editors to go into WebDav digging into XML's. May 13 '15 at 7:05
  • If you want to give control to other users then I can think of creating custom page which will allow to remove the video association. For this implementation, potentially there are two approaches: 1. Use core service to update the component 2. Use webdav approach suggested above and do it programmatic way.
    – Hiren Kaku
    May 13 '15 at 17:02
1

Without any details (like ECL log files showing details on where the exception is thrown) my best guess is that this is an error in the provider.

The implementation of IContentLibraryContext.GetItems is not allowed to throw an exception for items no longer available on the remote system (or if it is not accessible to the user). Instead they should be excluded from the result list.

Notice this is not the case for IContentLibraryContext.GetItem - it should throw an exception if the item is not available (I would recommend something a bit more descriptive than NullReferenceException if possible).

0

First and foremost, ECL layer does not create a two way mapping for assets referenced. It creates a stub which holds the GUID for the asset being referenced and it is only in Tridion. We have faced this issue multiple times when the assets were removed from Digital Asset Management system and we had to find and delete the component using the asset and stub component as well. So there is not a simplistic way to address this issue :(

To prevent this from happening in future, you can write eventing code around ECL layer. On Stub component creation event (you can get it on save and filter if the component schema is the one for stub component), either add a lock on the asset in the other system or add a metadata to the asset in the other system that it is being referenced in Tridion. This will ensure that when someone tries to remove it from the other system it can be prevented by a writing an event in the other system on delete.

5
  • Why not just fix the ECL provider? And if you want to add locking of items in use on the remote system what is the benefit of using the standard Tridion event system instead of the stub create/delete methods being called in your provider? May 14 '15 at 5:55
  • Also do notice that you will not get an exception when reading the item through the core service even if your provider is broken. The error happens in the UI layer. May 14 '15 at 5:57
  • @LarsMøllebjerg for customers like us who do not own\have the source code for ECL layer (Tridion side ECL connector or the third party side connector), the option I suggested is one of the plausible option to prevent this issue from happening. Also, I am not clear of what option you are suggesting in your comment. It will be great if you can write your approach as an answer as it will help the community and its users a lot :) May 14 '15 at 17:12
  • I already did write an answer - the provider is broken (given the limited information available). Sure if you are running software without any form of support so you can't even get bugs fixed it can be needed to implement a workaround, but I will always consider that option as a last resort. May 15 '15 at 6:16
  • removed the coreservice part from my answer May 15 '15 at 19:52

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.