7

While creating ECL multimedia Components using the Core Service, we've noticed a difference between creating them via the Core Service and creating them within the SDL Web UI.

  • Creating them in the UI displays the key {tcmid} AND ECL Media {eclidfile}
  • Creating them via the Core Service does not display the ECL Media {eclidfile}
  • However, both in the source of the Components look to be correct

Manually Created in UI

enter image description here

<MediaBlock xmlns="http://ecm.disney.com/wdpr/MediaBlock">
    <key xmlns:xlink="http://www.w3.org/1999/xlink" 
         xlink:type="simple" xlink:href="tcm:401-124373" 
         xlink:title="finderStandardThumb"></key>
    <media xmlns:xlink="http://www.w3.org/1999/xlink" 
           xlink:type="simple" 
           xlink:href="ecl:401-mb-200466156-fil-file" 
           xlink:title="star-tours-gallery06-sq.jpg"></media>
</MediaBlock>

tcmids do not match screenshots

Created via Core Services

enter image description here

<MediaBlock xmlns="http://ecm.disney.com/wdpr/MediaBlock">
    <key xmlns:xlink="http://www.w3.org/1999/xlink" 
         xlink:type="simple" xlink:href="tcm:401-124373" 
         xlink:title="finderStandardThumb"></key>
    <media xmlns:xlink="http://www.w3.org/1999/xlink" 
           xlink:type="simple" xlink:href="ecl:401-mb-200466156-fil-file" 
           xlink:title="star-tours-gallery06-sq.jpg"></media>
</MediaBlock>

tcmids do not match screenshots

So the issue is when we preview in TCM or publish the Component with media on it, it does not expose the ECL Media node.

Is there anything that is stored in a different place? AppData?

UPDATE

enter image description here

We are importing ECL and creating (content) Component relationships, and from that we are missing the Media ECL ID as shown above in 2nd screenshot. If its created manually in the UI everything is good, but through the Core Service something is missing.

We are just trying to figure

  1. How to access that info that is missing ecl:0-mb-200450850-fil-file
  2. Or, if this is a defect? Since that is how we grab the ECL metadata from DAM external system
2
  • What do you mean saying "Creating ECL components using Core server"? Are you creating stubs? Jul 14, 2017 at 15:18
  • What I mean is we are importing ecl and creating (content) component relationships, and from that we are missing the media ecl id as shown above in 2nd screenshot. If its created manually in the UI everything is good, but through coreservices something is missing.. just trying to figure #1. how to access that info that is missing ecl:0-mb-200450850-fil-file #2. Or, if this is a defect ? Since that is how we grab the ecl metadata from DAM external system Jul 14, 2017 at 15:21

2 Answers 2

7

In order to understand what is going on you need to understand how ECL works. The ECL URI that you see in the UI is not what actually gets saved in to the CM.

When you use an ECL component somewhere in other component or page, under-the-hood ECL creates stub component (if it does not yet exist) and substitutes the ECL URI with the TCM URI of the just-created stub component. So in CM we never save any ECL URIs.

If you're curious to see this, try to read one of the multimedia components that you created manually using the Core Service. You will see TCM URI in place of ECL URI. So the ECL URIs exists only in UI while in CM we operate on TCM URIs.

When creating components programmatically you need to ask ECL to give you the TCM URI of stub component for a particular ECL URI using the ECL service.

This ECL service is a WCF service very much like the core service, but for ECL.

You need to add Tridion.ExternalContentLibrary.Service.Client.dll to your project references (it can be found in %Tridion_Home%/web/WebUI/WebRoot/bin).

Also add Tridion.ExternalContentLibrary.Data.dll (it can be found in %Windows%\Microsoft.NET\assembly\GAC_MSIL\Tridion.ExternalContentLibrary.Data\v4.0_8.5.0.116__ddfc895746e5ee6b)

Add WCF endpoint in to your app.config

<system.serviceModel>    
    <bindings>
      <netTcpBinding>
           <binding name="EclNetTcpBinding" maxReceivedMessageSize="2147483647" receiveTimeout="00:10:00" sendTimeout="00:10:00">
                 <readerQuotas maxArrayLength="2147483647" maxStringContentLength="2147483647"/>
          </binding>
      </netTcpBinding>
    </bindings>

    <client>
        <endpoint name="EclBinaryEndpoint" address="net.tcp://{your_server_address}:2660/ExternalContentLibrary/2012/netTcp" binding="netTcpBinding" bindingConfiguration="EclNetTcpBinding" contract="Tridion.ExternalContentLibrary.Service.Client.ISessionAwareEclService"/>
    </client>
</system.serviceModel>

And create client same as core service:

ISessionAwareEclService eclService = new SessionAwareEclServiceClient();

Unfortunutly ECL service is only avalable through Net.TCP protocol.

You can test that service working by calling something simple like:

 var types = eclService.GetDisplayTypes();

To convert ECL URIs to TCM URIs you need to use:

 var stubUris = eclService.CreateOrGetStubUris( eclUris );

This method returns TCM URIs of stub components for each ECL URI and creates stub components if they do not exist yet.

You can convert them one by one or in bulk (to save you some time).

Once you have the TCM URI of a stub component, use it in your code that programaticaly creates components, instead of ECL URI.

<MediaBlock xmlns="http://ecm.disney.com/wdpr/MediaBlock">
    <key xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="tcm:401-124373" xlink:title="finderStandardThumb"></key>
    <media xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="[TCM URI of Stub component]" xlink:title="star-tours-gallery06-sq.jpg"></media>
</MediaBlock>

If you have difficulties with using ECL service You might consider using ECL API in form of direct API (Like Tom.NET for CM).

You need to reference Tridion.ExternalContentLibrary.dll (it can be found in %Windows%\Microsoft.NET\assembly\GAC_MSIL\Tridion.ExternalContentLibrary\v4.0_8.5.0.116__ddfc895746e5ee6b)

Also reference Tridion.ExternalContentLibrary.V2.dll (it can be found in %Windows%\Microsoft.NET\assembly\GAC_MSIL\Tridion.ExternalContentLibrary.V2\v4.0_8.5.0.116__ddfc895746e5ee6b)

Then create ECL session

var cmSession = new Session();
var eclSession = SessionFactory.CreateEclSession(cmSession);

Using the session you can get access to all ECL API including methods described earlier.

This also can be used for changing metadata of ECL items.

Like TOM.NET this approach can only be used on same machine where CM and ECL installed.

2
  • Use of TOM.NET API from a custom application is discouraged (because your application would become a CM Kernel host in itself). I assume the same goes for the in-process ECL API. Jul 24, 2017 at 19:19
  • Yes, generally, it is same for ECL. It is not that big, but it will load provider and other stuff in to calling process. I added this as despaired measure if using service is not an option Jul 24, 2017 at 21:59
3

The Core Service does not known about ECL URIs; an XLink which does not contain a TCM URI or WebDAV URL will be treated as an external link and will not result in a managed link.

ECL uses Stub Components to represent the ECL items in Content Manager. These Stub Components have a TCM URI (and WebDAV URL) and these should be used in your XLink.

ECL uses a UI Data Extender to change the TCM URI of a Stub Component into the associated ECL URI. So, in the UI it seems you can have XLinks to ECL URIs, but if you read the same item through the Core Service, you will see the TCM URI.

11
  • Ok, I realize after the association (ecl item inside a component) is made in tridion, that it creates a binding directory which is an instance of the ecl item with a tcmid. So when that binding happens, I wonder why a manually created item shows with a media ecl id in preview or published output and why a coreservice created item does not display the same result (above in screenshots). Jul 14, 2017 at 13:51
  • As mentioned, you should ensure that the media element is an XLink referring to the ECL Stub Component by either its TCM URI or its WebDAV URL. In your example, you are using an ECL URI, which the Core Service does not expect. Jul 14, 2017 at 17:50
  • So if the item has never been linked I can’t tell what the tcmId would be.. Jul 14, 2017 at 17:57
  • 1
    You will first have to create the ECL Stub Component in that case. Jul 15, 2017 at 9:28
  • 2
    Creating ECL stubs without using ECL is bad idea. There is specific requirements where stub need to be created. And overall we consider ECL stub components internal implementation so users should not tinker with it. ECL have its own service that can be used to manipulate ECL items in proper way. Jul 17, 2017 at 7:40

Your Answer

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

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