4

I am trying to query the v4 endpoint of the odata content service with no luck. The reason I want to use that endpoint is because odata's v4 has more "filtering" options and more advanced querying functions. However unless I query for metadata or to see the entities: enter image description here I get different exceptions, for example using POSTMAN:

enter image description here

I've also tried using the "automatically generated proxies" (which work when generated against the v2 endpoint) and I get this error too:

DataServiceClientException: {"error":{"code":"1800","message":"This query is not supported: http://service-url-goes-here:8081/client/v4/content.svc/ComponentPresentations?$top=1"}}

I've spent a good full day trying serveral things, and I am starting to think that either the v4 endpoint is not ready for use or that I might have the content service not properly configured to use such endpoint.

Any pointers would be highly appreciated.

UPDATE I decided to switch to CIL, instead of doing my thing. However when using the API I get the following exception: Invalid v4 service endpoint for content-service

Which tells me that I was kinda right with the assumption that my v4 endpoint (or the content service all along) might not be properly configured. I went over the documentation over and over and checked my discovery service, which has the content service properly configured pointing to the right server. I added the configuration settings in my web.config with the oauth properties and the discovery service uri:

enter image description here

3

So I finally figured it out... It was a combination of several things, but long story short, it had to do with my settings having the wrong encoding (assuming you had the rest of the setup correctly).

However, these are the things I tried and hope that might help others when having issues connecting to the odata v4 (or v2 for that matter), using the CIL libraries:

  1. Made sure I had the right settings in my web.config
  2. Made sure that those settings were not copy-pasted as I realized that the discovery service setting had some weird character encoding messing around
  3. Made sure all the host names in all services were not "localhost", rather the actual host name of the server, so services could be accessed from outside the server itself.
  4. Made sure the "ContentService" capability was registered in the discovery service

I also recommend that when you encounter these issues, you enable "logging" in your application web.config too.

These are my settings:

    <!-- SDL WEB Settings - Services -->
    <add key="token-service-uri" value="http://server:port/token.svc"/>
    <add key="discovery-service-uri" value="http://server:port/discovery.svc"/>
    <add key="oauth‐enabled" value="true"/>
    <add key="oauth‐client‐id" value="cduser"/>
    <add key="oauth‐client‐secret" value="CDUserP@ssw0rd"/>

    <!-- SDL WEB Settings - Logger -->
    <add key="log-level" value="DEBUG"/>
    <add key="log-output" value="c:\temp\logs\sdl-core.log"/>

Nuget Packages Versions (This only applies for the versions mentioned belowç)

Make sure that the dll versions on your application are compatible, for example, I am using version 8.5.0 of the Sdl.Web.CIL package which does not work with version 5.8.4 of Microsoft.Data.Edm, Microsoft.Data.OData, etc... I had to downgrade to version 5.6.4 and although the Dependency list in nuget specifies any version >= 5.6.4 should work, that's not the case. I also downgraded the "odata" dependencies to 6.15.0 (Microsoft.Spatial, Microsoft.OData.Core, Microsoft.OData.Edm, Microsoft.OData.Client)

Hope this helps :)

2

I could be wrong, but I believe the v4 was never intended for public use.

  • You are right. The CIL API uses a mix of OData V2 and V4 under the hood. The idea was to further mature the V4 endpoint before declaring it public, but it now seems that will never happen and a new GraphQL endpoint will become the public API. – Rick Pannekoek Aug 14 '18 at 15:19
  • Ok, so I switched to CIL (because I was expecting something like v4 shouldn't be used... etc...). I get the following error: "Error": "Invalid v4 service endpoint for content-service" – Jaime Santos Alcón Aug 14 '18 at 16:03
  • Before anything.. checking the registered capabilities on the discovery service... – Jaime Santos Alcón Aug 14 '18 at 16:06
  • I have all these capabilities: PreviewWebServiceCapability, ContentServiceCapability, DeployerCapability, WebCapability and TOkenServiceCapability. Do I also need the ContextCapability mentioned here:tridion.stackexchange.com/questions/17760/… – Jaime Santos Alcón Aug 14 '18 at 16:10
  • If you're getting a v4 endpoint error, it could be worth double checking that you definitely have the Discover Service URL configured correctly in your web.config. It should be something like: <add key="discovery-service-uri" value="http://localhost:8082/discovery.svc" /> – Jonathan Williams Aug 14 '18 at 20:45
1

I'm not sure if it's supported to directly use the v2 or v4 service endpoints. I always thought the CIL libraries know internally which service to use for a specific query.

  • I am trying to avoid using the CIL libraries – Jaime Santos Alcón Aug 14 '18 at 13:35
  • @Harald, v2 is supported and can be used without any issues, for v4 I'm not certain. There are some valid use cases for directly using these endpoints. The biggest disadvantage of this approach however I would say is that you have to handle the OAuth part (initial authorization, token renewal when expired, etc.) manually (if the Content Service is protected that is). – Atila Sos Aug 14 '18 at 14:46
  • I have a class that takes care of the OAuth part... and CIL doesn't seem to be working, so I might have something not properly configured... dunno what, though – Jaime Santos Alcón Aug 14 '18 at 16:36

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.