What is the best practice for dismounting an ECL provider? My doubts are mainly related to the removing of the stub components and stub schema. Has anybody had (good or bad) experiences with it?
2 Answers
Removing a mount point is pretty straight-forward : you just remove it from the ecl config file, and then you can delete the stub components & schema's.
Off course, just like with any other Tridion item, if these ECL items are used in other components, or if they are published, then you will first need to unpublish them, or alter the components that are using them.
So, before unmounting an ECL provider, you should first check where these ECL items are used. You can check the 'where used' dialog on ecl stub items, so if you have a large amount of items, you can write a core service script to get the items using your ecl stub items, and also the publish targets (see http://codedweapon.com/2012/12/getting-using-and-used-items-with-core-services/ for an example).
Then, depending on your use case, you could chose to remove these ecl items from using components and unpublish them, or you could let your content editors modify all components using these ECL items.
Once that's done, you should be able to safely dismount the provider, and to remove the ECL stub components.
-
3I would personally delete stubs first, then remove the MountPoint configuration. That way you won't get any surprises, Tridion will stop you if one of the stubs is in use/published and you can take action without fighting a misconfigured ECL stub in the meantime, Commented Apr 1, 2015 at 14:05
Like Harald explain, it is pretty easy to dismount ECL but better you take care all dependencies before dismounting.
I had some bad experience where I even didn't dismount but some items were deleted directly from source and then all components using those ECL components were corrupted and I was not able to open/use them from GUI. I had to unpublish, delete and create new components for all components using those ECL components. so similarly if you dismount completely your all ECL components wouldn't be available in GUI and hence all main components using ECL may get corrupted because of ECL reference.
-
It is unfortunately very easy to program a provider so items can't open if they contain references to items no longer on the remote system. It's also easy to program it so it won't be a problem, but you need to know how to do it. :) Commented Apr 1, 2015 at 14:09
-
Thanks Lard, Sorry I am bit confused for your comments. Please suggest how to ignore ECL reference issue if ECL content deleted from source. Commented Apr 2, 2015 at 5:36
-
The implementation of IContentLibraryContext.GetItem must throw an exception if the requested item does not exist (or the user does not have access). The implementation of IContentLibraryContext.GetItems MUST NOT throw an exception in these cases, it should simply not return the item. This behavior match the get single item/bulk loading of items exposed by Tridion (TOM.NET and Core Service). Commented Apr 8, 2015 at 15:00