I guess your CIS services run on a different machine than your web application.
In that case, it is important that your CIS capabilities are not registered with localhost URLs. The web app will contact the Discovery Service to retrieve the URL of the Content Service (and other CIS Services). If those are registered with localhost URLs, the web app will ...
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:
You need to connect to Content svc via CIL. Here are a couple links:
Unfortunately, only metadata fields are published to a specific broker table to allow you for querying or sorting, so sorting on content fields isn't possible using the regular API.
Some options you may have
move the field you wish to sort on to metadata (most recommended option)
add a metadata field and copy the contents of the sort field to this field ...
AFAIK, you don’t need DCPs to be able to query for Component metadata.
For example, the Latest News widget on the DXA Example Site Home Page queries embedded Component Presentations.
In general, the DXA Resolver is intended to deal with dynamic expansion. That is: linked Components based on a Schema associated with the “Generate Data Presentation” DCT ...
Based on my quick investigation, I could say it is possible.
As I could retrieve multimedia components by adding a one more additional query criteria of new MultimediaCriteria(true) in the buildCrieria method of DefaultContentProvider.
But strantegly, ComponentMeta of MM componenets does not seems to have SchemaId filled. So I had to remove ...
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"), ...
Just as your question is vague, I am afraid that the answer is also. What you need to do is basically do a stress test. See how your app behaves with this number of requests.
In general, bottleneck can happen in few places:
CD microservices - you can scale them up really easily - just add more servers and you are good to go. You can use different scaling ...
You should use the DXA API functions to retrieve that kind of content, instead of the regular Broker API.
The reason for that is that, these DXA API functions call the model service that takes care of these link resolving for you (or in case of earlier DXA versions, those functions also perform link resolving for you).
The function you need to call is the ...
I believe, in this case, the best option you may have is to contact customer support, who can provide you with a supported/approved sql query to remove this data from the broker DB.
Alternatively, you could create a new empty broker database, republish everything that is currently published, and switch your current db (containing the old publication data) ...
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,
You need to configure cache invalidation messaging - see the documentation on this topic: https://docs.sdl.com/LiveContent/content/en-US/SDL%20Web-v5/GUID-7E728735-073B-4827-AABE-B45592CFF36D
With this in place, the deployer will send messages to the Content Services invalidating whatever has just been published.
What have you tried so far? I'm asking because this question is a "do my homework instead of me" type, so there is little chance that someone will write your code instead of you. Best we can do is give you some hints, and then using the API found HERE you can easily put together your own code. For debugging purposes you can attach to the Template Builder ...
I’m a bit confused by your comment “this is going to be on a TBB and run at the runtime. This code won’t run at the rendering time.”
In general, TBB code runs at rendering time. And the reason why Jonathan asked for it, is because only templating and event handler code is supposed to use the TOM.NET (rather than the Core Service).
Anyways, assuming that ...