Expand my Community achievements bar.

Graphql endpoint is not working when calling in Sling Model - AEMaaCS

Avatar

Level 2

Hi Everyone,

 

I am developing an AEM component on AEMaaCS instance (headful approach).

I need to get content fragment data and display it on the page using the AEM component in headful architecture. I am using Sling model to make a call to graphql endpoint. 

I used Apache libraries HttpGet, CloseableHttpClient to make a GET call to graphql endpoint.

The code works fine in local AEM instance  but on AEMaaCS, it gives a "read timed out" error while making the graphql call.

 

Any help in resolving this issue?

 

 

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

8 Replies

Avatar

Level 2

ERROR  Error in Response: Read timed out
java.net.SocketTimeoutException: Read timed out
at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:278)

Avatar

Level 4

Hi @grandhip ,

 

The “read timed out” error happens because AEM as a Cloud Service blocks or limits direct HTTP calls from backend Java code (like with HttpClient) to its own GraphQL endpoint for security and performance reasons. This works locally, but in the cloud, these calls often get blocked, delayed, or don’t go through.

 

What you should do:

  • Get content fragment data using Sling Models and AEM APIs (not HTTP GraphQL calls) if you’re inside AEM’s backend.
  • For front-end or browser use, let your JavaScript (AJAX or fetch) call the GraphQL endpoint directly instead of making the server call.
  • Avoid server-side Java HTTP requests to GraphQL endpoints in AEM Cloud—use supported and cloud-friendly patterns.

Switching to these supported methods will make your component work smoothly on AEMaaCS.

 

Thanks,

Vishal

Avatar

Level 2

Hi @VishalKa5 ,

 

The reason for leaning towards graphql endpoint instead of AEM APIs like Content Fragment API is because.

1. The JSON schema is nested 3-4 levels deep and iteration logic with the nested CFs is more complicated to handle.

2. We have a headless app that uses the graphql endpoint for same content so we want to be maintain sync between headless vs headful (AEM) apps.

 

Thank you,
Pavan

Avatar

Level 4

Hi @grandhip 

Please try this below ways:

Your problem: AEMaaCS blocks your Java code from making HTTP calls back to itself. It's a security thing in the cloud.
Best fix: Don't use HttpClient at all. Instead, use AEM's built-in GraphQL Java client or Content Fragment APIs that work internally without HTTP calls.
Quick alternative: If you must keep your current approach, increase your timeout settings to 30+ seconds and make sure you're calling the GraphQL endpoint using an internal path (not the full external URL). AEMaaCS is just slower than local.
If nothing works: You'll need to configure "Advanced Networking" in Cloud Manager to allow your environment to make these calls, but that's overkill for this use case.
Bottom line: Switch from HttpClient to AEM's internal GraphQL client libraries. Same queries, same results, but works properly in the cloud.

Thank you

Avatar

Community Advisor and Adobe Champion

Reason your GraphQL call works locally but times out on AEMaaCS is probably because making HTTP calls to your own AEM instance from within AEM (like using `CloseableHttpClient` to call the GraphQL endpoint) isn’t really supported in the cloud setup. AEMaaCS runs in a containerized, secure environment, and internal HTTP calls can run into network restrictions — which is likely maybe why you're seeing that read timed out error.

What You Can Do Instead

Since you're building a headful component (not a headless app), you probably don’t need to call GraphQL from the backend at all. A better approach is to use the Content Fragment API directly in your Sling Model. This lets you work with content fragments without making a network call, and it’s much more efficient in AEMaaCS.

Adobe provides a full Java API for working with Content Fragments. You can find the official documentation here:
Content Fragment Java API – AEM 6.5 - https://developer.adobe.com/experience-manager/reference-materials/6-5/javadoc/com/adobe/cq/dam/cfm/... 

You can use this API (com.adobe.cq.dam.cfm) to directly read structured content, elements, and metadata from the content fragment in your Sling Model — no need to call the GraphQL endpoint.

Instead of calling GraphQL, your model could:

  1. Read the content fragment path from the component dialog.
  2. Adapt the resource to a `ContentFragment` object.
  3. Read the elements you need using `getElement("name").getContent()`.

This way, everything stays in-process and fast, and you're not depending on a fragile network call that might get blocked or timeout in the cloud using the Content Fragment API (com.adobe.cq.dam.cfm).

Avatar

Level 2

Hi @BrianKasingli ,

 

The reason for implementing graphql endpoint instead of AEM APIs like Content Fragment API is because.

1. The JSON schema is nested 4 levels deep and iteration logic with the nested CFs is more complicated to handle.

2. We have a headless app that uses the graphql endpoint for same content so we want to be maintain sync between headless vs headful (AEM) apps.

 

 

 

Avatar

Employee

Hello @grandhip 

For headful (WCM/Sites) components, you can also access Content Fragments using the Sling Models API :

For Example :
https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/sites/administer...

If you want to expose fragment data as JSON, build a Sling Model Exporter :
https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/implementing/dev...

GraphQL API can be used from *external* clients needing headless content delivery :

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/sites/administer...

Avatar

Level 2

Hi @muskaanchandwani ,

 

I am aware that the graphql is meant for headless but is there any limitation that it cannot be used in headful (AEM components)?

I haven't see any official documentation around the limitation of graphql with in AEM headful architecture.

 

The reasons for implementing graphql endpoint instead of AEM APIs like Content Fragment API is because.

1. The JSON schema is nested 4 levels deep and iteration logic with the nested CFs is more complicated to handle.

2. We have a headless app that uses the graphql endpoint for same content so we want to be maintain sync between headless vs headful (AEM) apps.

 

Thank you,
Pavan