I have a Tridion Docs 13 SP2 publication with a map and several topics. The map and the topics all have a condition applied to them (something simple, like Test=Print). For instance:

enter image description here

I've published my Docs publication to my DXD broker database (shared with Tridion Sites). I'm connecting to this broker database from a typically DXA setup for Tridion Sites (i.e. reference implementation web application, that we're all used to). I can use Fiddler to see what happens when I query for my Docs publication and its topics from my DXA web application. I do indeed see tags with what appears to be the correct conditions on my content:

enter image description here

Now, I've been told that I can use the Ambient Data Framework (ADF) in my DXA web application to set some claim that will automatically cause my queries to be filtered, based on the condition I set in the claim:

enter image description here

However, what I'm observing is that nothing changes when I set the condition in the ADF. I see the map not displayed and all of the topic content is displayed, even though I put conditions around all of them. And this does not change, regardless of whether I set the condition in the ADF or whatever I use for the syntax. I have tried every combination I can think of for the syntax of my condition, on both the Docs CMS side and my DXA web application side. I even tried "{\"Test\":[\"Print\"]}", etc. etc. - I am not finding much in terms of documentation on the syntax.

So my question is, what am I doing wrong? What am I missing? I'm thinking it could be something to do with the provider code I'm trying to use (see notes below)...


I updated my Content and Discovery service configurations cd_ambient_conf.xml files to contain the relevant globally accepted claims:

enter image description here

I am using the GraphQL providers with DXA 2.1. I noticed these methods don't explicitly pass the context data. However, I was under the impression that part would be handled by the ADF:

enter image description here

enter image description here

enter image description here

This is a local development environment, so I'm running the application with IIS Express from Visual Studio. I believe the default setting is that the application pool should be in integration mode, as discussed here. I do see my Web.config with the integrated mode configured.

I did see the context data being passed in Fiddler as well. It did have the conditions set in the context data, so I think that part is working...


The issue is that I was missing the ISH Cartridge (ish_ambient_cartridge.xml, now called udp-cis-ish-cartridge.xml). I was missing the steps here. But, as I observed, in addition to those steps, the JAR files also needed to be copied directly into lib folder of my content microservice:

  • \sessioncontent\lib\commons-jexl3-3.0.jar
  • \sessioncontent\lib\commons-lang3-3.5.jar
  • \sessioncontent\lib\udp-cis-ish-cartridge-11.0.0-1024.jar
  • \sessioncontent\lib\udp-cis-ish-dynamic-11.0.0-1024.jar
  • \sessioncontent\lib\udp-cis-ish-evaluation-engine-11.0.0-1024.jar

These libraries contain code that resolves TCDL tags with Conditions in Docs content sitting in the broker database (e.g. <tcdl:If condition=\"(Test=Print)\"...). Note that these files don't appear to come packaged with the Tridion Docs install media - I had to take them from the Tridion Sites install media.

As you can see in the above code snippets, I'm clearly attempting to use the ADF and existing providers. I misinterpreted all of the documentation I encountered, as well as the informal suggestions I received. But from what I can tell, any time you are trying to use the ADF to filter content service responses based on Docs conditions, you need to set up the ISH Cartridge, as described above.

  • Thanks Damian. Those files should be present in the roles/content/ish-cartridge/lib folder on the Docs install media. I'll check here that they are being correctly distributed. – Bengineer Apr 25 at 15:17
  • I've confirmed that they are present in the distribution that our Customer Support team has. Please can you confirm where you received your media from? – Bengineer Apr 25 at 16:31
  • It seems I may have jumped the gun on this. While I was able to get my content service running with the ish cartridge referenced, upon closer inspection, I'm still seeing TCDL tags that I would expect to be rendered out by the above libraries. – Damian Jewett Apr 25 at 22:27
  • I was also seeing a warning like: "There is no a handler for tag: 'tcdl:If condition="(Test=Print)"...", so I am assuming that I need to update my TCDLEngine section of my cd_dynamic_conf. That gets me past the 'no handler' issue, but still no luck with resolving the TCDL tags... – Damian Jewett Apr 26 at 2:38

There's several approaches you can take to pass user conditions through to the content service.

The first approach (and the one that would most easily work for you I think) would be to add them directly to the ADF claimstore. Such as:

   var claimStore = AmbientDataContext.CurrentClaimStore;
   claimStore.Put(new Uri("taf:ish:userconditions:merged"), userConditions);

If you then add the claim taf:ish:userconditions:merged to your cd_ambient_conf.xml (/bin/config folder) under the ForwardedClaims element then all GraphQL requests sent will include this claim (passed through via the context data argument).

If you are not running ADF but still wish to pass claims like userconditions through you can use the ApiClientFactory to add global context claims:

                new Sdl.Tridion.Api.Client.ContentModel.ClaimValue
                    Uri = "taf:ish:userconditions:merged",
                    Type = Sdl.Tridion.Api.Client.ContentModel.ClaimValueType.STRING,
                    Value = userConditions

Finally if you don't really need to use the providers to get content you can use the PCA API directly using the ApiClient:

var client = ApiClient.ApiClientFactory.Instance.CreateClient();

This client is used internally by the providers when requesting data. You may notice that most of the methods such as GetPage(...) GetComponentPresentation(...) etc All these let you pass the context data (those claims) directly. DXA internally is looking for claims that need forwarding and pulling them from the claim store for you, hence the first option should work for you.

Just on a side note, the Api client also allows execution of any GraphQL query directly using one of the Execute() methods so if you need to execute raw GraphQL queries this is how you can do it. Also, if you wish to have a minimal GraphQL client with no frills use:

   var graphQl = new GraphQLClient(graphQLEndpoint);

Hope that helps, Paul

  • We have explored and confirmed that this is all working (sending context data via ADF and also doing GraphQL queries directly). At this point, the issue is more with TCDL rendering. The Docs conditions go into the broker database as TCDL tags that include the conditions. I've had to guess that TCDLEngine configuration was needed in the cd_dynamic_conf in order to render these TCDL tag. However, the issue now is that the TCDL tags are not getting properly recognized as balanced tridion.stackexchange.com/questions/20026/… – Damian Jewett Apr 29 at 15:48

If you are using GraphQL for querying content, you do not need to worry about ADF claims for condition evaluation. These are only needed when using the CIL. Instead, you can simply pass your conditions as contextData to your GraphQL query, such as in the query below:

  page(namespaceId: 2, publicationId: 1234, pageId: 5678,
    contextData: [{
        uri: "taf:ish:userconditions:merged",
        type: STRING,
        value: "{\"Test\":[\"Print\"]}"
    }]) {
    containerItems {
      ... on ComponentPresentation {
        rawContent(renderContent: true) {
  • Thank you. I am aware of this approach when using a GraphQL query directly. However, I was under the impression that the ADF could be used for other scenarios. If you look at my notes above, I'm using GraphQL providers, which under the hood do use GraphQL. But I am not explicitly building and using and GraphQL queries myself. I'm just calling some built-in functions of the providers. So now I'm wondering if that is my issue. The provider functions do not explicitly take in a context data object, so I'm guessing maybe they can't be used for what I'm trying to accomplish... – Damian Jewett Apr 20 at 0:29

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.