This may sound crazy but worth discussing it as We have alot around ECL and thought everyone should get the benefit.

Usecase: Read a stub component with its ECL Uri using core service in ECL Provider

Example of reading Publication:

private static void ReadComponentFromCoreservice(IEclUri eclUri, ITridionUser _tridionUser)
        var client = new SessionAwareCoreServiceClient("netTcp_201603", My.MyCoreServiceUrl);
        var pubTcmId = "tcm:0-" + eclUri.PublicationId + "-1    //tcm:0-2-1

        //This gives me full Publication object
        PublicationData publication = (PublicationData)client.Read(pubTcmId, null);

       //I want to read my component using ecluri :ecl:2-s3-lfek2p-fls-file 


Is this possible?

2 Answers 2


Yes, it is technical possible, but there are a few traps you should avoid:

  1. The Stub Component will not be available on the first call to the Provider. This is due to the transaction scope - the Stub is created inside a transaction that is not finalized before the call to your ECL provider completes.

    It is technical possible to flow the transaction to the provider, but iI am not sure joining your CoreService client to the transaction will be sufficient to get access to the Stub - it is not something we tried. Flowing the transaction to the provider will result in a distributed transaction, so it will blow up on cloud databases.

  2. You will have a call sequence going (for example) CoreServiceHost -> ECL provider -> CoreServiceHost. If an item is modified in the CoreService host before the ECL provider is called and you then try to modify the same item the database will deadlock.

    I do not recall the transaction settings used by TCM, so I can't say exactly which operations will be problematic, if you are unlucky it will even deadlock on reading a list the stub could be in. Turning of transactions for your CoreService client can help make it less likely to deadlock.

  • That's interesting.. I do close my Core service client after my transaction. and I know that EclSession is persisted when Provider is initialized. Mar 22, 2017 at 17:26

To read the Component from the ECL URI, you can use the ECL API, since it has a method for getting the Stub Component URI from the ECL URI:

string tcmUri = eclSession.TryGetTcmUriFromEclUri(eclUri);
if (!String.IsNullOrEmpty(tcmUri))
    ComponentData comp = (ComponentData)client.Read(tcmUri, new ReadOptions());

Note what Lars mentioned about the Stub Component not being available yet, and in the class implementing the IContentLibraryContext interface (I often just call that the Mountpoint class), you also have the following methods available:

public void StubComponentCreated(IEclUri eclUri, string tcmUri)
    string versionlessTcmUri = tcmUri.Replace("-v0", string.Empty);

public void StubComponentDeleted(IEclUri eclUri, string tcmUri)

There you have both the ECL URI and the TCM URI available, but note the -v0 postfix on the TCM URI in the StubComponentCreated method, indicating you are dealing with a newly created item.


  • Yeah, there it is. Thanks Bart. I need few thing to test before I mark this a an answer, will update in a bit. Mar 22, 2017 at 17:23
  • Strangely I do not get the tcmUri using EclSession.. It return Null, can't attach any screenshot. Let me try if i can. Mar 22, 2017 at 17:44
  • 1
    @VikasKumar as per the API documentation, if it returns Null, then the stub component hasn't been created yet. So you are too early in the transaction. Mar 22, 2017 at 17:46
  • Yeah. that is true..trying to get it at the right place. Mar 22, 2017 at 17:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.