Difference between DeliveryApi 0.9 and 1.0

Experience Manager (PaaS/OnPrem)
1

We use components that have some fields that need to be filtered down before being sent to the frontend. Imagine something like a list of related documents but dependening on the channel only documents marked for a certain country should be displayed. Or in the example below a document that serves as a navigation basis and thus only resolves some properties of the linked documents so we can save on bandwidth.
For that we have beans like the following

@HippoEssentialsGenerated(internalName = "PROJECT:NavigationDocument", allowModifications = false)
@Node(jcrType = "PROJECT:NavigationDocument")
public class NavigationDocument extends BaseDocument {

    private final List<ResolvedNavigation> resolvedNavigations = new ArrayList<>();

    private List<PageReference> references = null;

 
    @HippoEssentialsGenerated(internalName = "PROJECT:references", allowModifications = false)
    public List<PageReference> getReferences() {
        if (references == null) {
            references = getChildBeansByName("PROJECT:references");
        }
        return references;
    }

    public List<ResolvedNavigation> getResolvedNavigations() {
        return resolvedNavigations;
   .....
}

The components in this case interacts with the resolved navigations variable via normal java calls (in this case List.add/ List.AddAll).
When using delivery api 0.9 the “resolvedNavigations” field has some content in the resulting JSON. But when using delivery api 1.0 the field is empty. So in this case switching between the different versions actually has implications beside the different structure.
So my questions are:

  • Is using these kind of “cache” variables in document beans recommended at all?
  • Is there some configuration required to make this work for delivery api 1.0?

I’m aware there are other ways to fulfill this specific feature, i.e.moving the entire filtering etc. logic from the component into the getter or just using HstRequestContext.setModel to provide the information. But that’s not the way our project went.

2

Hi @SBG ,

Please refer to this Introduction to the Delivery API - Bloomreach Experience Manager (PaaS/Self-Hosted) - The Fast and Flexible Headless CMS documentation for the differences of the Delivery API 0.9 and 1.0

3

Hi @Pselvam
thanks for that page but I fail to see how it relates to this specific question.
Yes 0.9 and 1.0 are different. But I fail to notice any section in the linked page that mentions the case I outlined in the question.

4

From the bean I see no issue, but the component code may reveal something else. I’m not sure what you mean by cache variable though. Could you explain that?

5

In this case I just meant the resolvedNavigations field in the bean. It is manipulated by a custom component.
The result of the manipulation are present in the 0.9 version of the delivery api JSON but fail to appear in the 1.0 version.

6

Could you share your component code?

7

Sure.

@ParametersInfo(type = NavigationDocumentComponentInfo.class)
public class NavigationDocumentComponent extends BaseDocumentComponent {
    public static final Logger log = LoggerFactory.getLogger(SimpleContentPageComponent.class);


    @Override
    public void doBeforeRender(final HstRequest request, final HstResponse response) throws HstComponentException {
        super.doBeforeRender(request, response);

        Object contentBean = request.getModel(REQUEST_ATTR_DOCUMENT);
        if (!(contentBean instanceof NavigationDocument)) {
            log.warn("model key \"{}\" held object with class [{}] was used in NavigationDocumentComponent", REQUEST_ATTR_DOCUMENT, contentBean.getClass().getSimpleName());
            return;
        }
        NavigationDocument document = (NavigationDocument) contentBean;

        final HstRequestContext requestContext = request.getRequestContext();
        final String mountName = ChannelUtil.getChannelNameFromResourceApiMount(requestContext.getResolvedMount());
        final String baseChannel = ChannelUtil.getBaseChannel(mountName);

        document.getResolvedNavigations().addAll(
                document.getReferences().stream()
                        .map(p -> {
                            try {
                                if (StringUtils.isEmpty(p.getProductReference())) {
                                    Node navigationNode = p.getDocument().getNode().getNode("mc3sbrxm:navigation");
                                    Navigation object = (Navigation) requestContext.getObjectConverter().getObject(navigationNode);
                                    HstLink hstLink = requestContext.getHstLinkCreator().create(p.getDocument().getNode(), requestContext);
                                    if (hstLink.isNotFound()) {
                                        log.debug("Resolving navigation for document {} [path: {} , handleUuid: {}] produced a page not found", document.getName(), document.getCanonicalPath(), document.getCanonicalHandleUUID());
                                        return null;
                                    }
                                    HstComponentConfiguration componentConfiguration = hstLink
                                            .getHstSiteMapItem()
                                            .getHstSiteMap()
                                            .getSite()
                                            .getComponentsConfiguration()
                                            .getComponentConfiguration(hstLink.getHstSiteMapItem().getComponentConfigurationId());
                                    if (isPublishedForChannel(componentConfiguration, baseChannel) && isPublishedForChannel(componentConfiguration, mountName)) {
                                        return new ResolvedNavigation(object, LinkModel.convert(hstLink, requestContext).getHref());
                                    } else {
                                        return null;
                                    }
                                } else {
                                    return new ResolvedNavigation(p.getProductReference());
                                }
                            } catch (Exception e) {
                                log.error("Failed to resolve navigation", e);
                            }
                            return null;
                        })
                        .filter(Objects::nonNull)
                        .collect(Collectors.toList()));
        //clear links to full documents after we resolved navigations
        document.getReferences().clear();
    }

    private boolean isPublishedForChannel(HstComponentConfiguration componentConfiguration, String channelName) {
        return Boolean.parseBoolean(componentConfiguration.getParameters().getOrDefault(ChannelUtil.PUBLISHED_FOR_PREFIX + channelName, "false"));
    }
}
8

@jasper.floor seems like you didn’t notice an obvious mistakes in the component code either. Do you have other recommendations on how to proceed here?
Meanwhile I have found some other components in our project that don’t work like they used to in BrXm 13 anymore. At least that one is not working regardless of the delivery api version

9

HI,

Yeah, sorry. I didn’t see any immediate problems, but I was also pulled into other issues so this one sort of faded into the background. I’d suggest putting a breakpoint in the component where you resolve the navigation. See if the data is actually being collected there.

Otherwise consider reaching out for support from our Professional Services department.