Is it possible to read a component with an EclUri in ECL provider using Core service

Question

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);
        client.Impersonate(_tridionUser.UserName);
        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?

Answer 1

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.

Answer 2

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.

updated.