When using DXA 2.1 with Sites 9 and DXD 11, DXA can raise pretty ambiguous exceptions, making it hard to troubleshoot.
For example, when a page or dynamic component presentation does not contain the expected DXA JSON, the following exception will be raised. This is a common use case, for example when old non-DXA content is published, or when there is additional data in the page content and component presentation content added by a TBB like the SI4T TBBs.
DxaException in the DXA website:
PCA client returned an unexpected response when retrieving enity model data for id 6336-805.
Exception of type 'Sdl.Tridion.Api.GraphQL.Client.Exceptions.GraphQLClientException' was thrown.
GraphQLError : Exception while fetching data (/componentPresentation/rawContent) : Error occurred while transforming component presentation content at Line : 5 Column :4
Under the hood, the DXA framework uses the Sdl.Tridion.Api.Client to call the PCA service with DXA model addon, calling this service returns a much clearer exception which explains the cause of the error:
...
"errors":[
{
"message":"Exception while fetching data (/componentPresentation/rawContent) : Error occurred while transforming component presentation content",
"path":[
"componentPresentation",
"rawContent"
],
...
"extensions":{
"0849e23e-bfaa-41c4-b1d0-2e2fd4ee2a81":"Error occurred while transforming component presentation content",
"334d162d-0e6c-491f-ae53-5a293cb5442e":" Couldn't deserialize content '<!-- INDEX-DATA-START: <indexdata><url>tcm:9-6336 </url><title>08-0001</title><publicationid>9</publicationid><schemaid>770</schemaid><itemtype>16</itemtype><parentsgid>0</parentsgid><type>0</type><body>...
From the last error message it is clear: my SI4T TBB has left some XML data in the component presentation content, and the PCA DXA plugin cannot read this data. Now I need to know what to fix. This information is not visible in the DxaException.
Solution A
The error handling in the DXA framework or in the Sdl.Tridion.Api.Client could be improved so that this crucial error detail bubbles up in the chain of errors and exceptions.
Solution B
The detailed error complains about not being able to de-serialize the content. Since this and expected scenario (DXA can only read DXA/DD4T data but technically other data could be present in the Content Delivery data store) the PCA DXA plugin could handle the situation better and raise a specific error message which explains that the page or component presentation content is not the expected DXA or DD4T content.
Workaround
I could get the additional error detail by reproducing the error locally in a website running in Visual Studio, and configuring the Web.config to use a proxy. With Fiddler I could inspect the PCA service calls, and inspect the error detail.
When using DXA 2.1 with Sites 9 and DXD 11, DXA can raise pretty ambiguous exceptions, making it hard to troubleshoot.
For example, when a page or dynamic component presentation does not contain the expected DXA JSON, the following exception will be raised. This is a common use case, for example when old non-DXA content is published, or when there is additional data in the page content and component presentation content added by a TBB like the SI4T TBBs.
DxaExceptionin the DXA website:Under the hood, the DXA framework uses the
Sdl.Tridion.Api.Clientto call the PCA service with DXA model addon, calling this service returns a much clearer exception which explains the cause of the error:From the last error message it is clear: my SI4T TBB has left some XML data in the component presentation content, and the PCA DXA plugin cannot read this data. Now I need to know what to fix. This information is not visible in the
DxaException.Solution A The error handling in the DXA framework or in the
Sdl.Tridion.Api.Clientcould be improved so that this crucial error detail bubbles up in the chain of errors and exceptions.Solution B The detailed error complains about not being able to de-serialize the content. Since this and expected scenario (DXA can only read DXA/DD4T data but technically other data could be present in the Content Delivery data store) the PCA DXA plugin could handle the situation better and raise a specific error message which explains that the page or component presentation content is not the expected DXA or DD4T content.
Workaround I could get the additional error detail by reproducing the error locally in a website running in Visual Studio, and configuring the
Web.configto use a proxy. With Fiddler I could inspect the PCA service calls, and inspect the error detail.