In a simple test setting, I’m converting a table of contents macro to export_view
format, using the contentbody/convert
endpoint.
This works well, using the synchronous (but deprecated) contentbody/convert
endpoint. It does not, using the asynchronous contentbody/convert/async
endpoint.
Here’s my test page’s storage XML:
<ac:structured-macro ac:name="toc" ac:schema-version="1"
ac:macro-id="d968a3d8-3d77-4313-9a7a-1644222a69bc">
</ac:structured-macro>
<h1>Heading 1</h1>
Using the deprecated contentbody/convert/export_view
endpoint, the result is something like this:
<style type='text/css'>snip</style>
<div class='toc-macro rbtoc1739281782416'>
<ul class='toc-indentation'>
<li><a href='#id-2025-02-11T14:49:35_96Page0-Heading1'>Heading 1</a></li>
</ul>
</div>
Using the recommended async contentbody/convert/async/export_view
endpoint, the result (after GET
ting it via contentbody/convert/async/JOBID
) is:
Yes. That’s pretty empty.
Status of the job is COMPLETED
, no error message.
Are there known issues with the async contentbody/convert
endpoint?
Edit: Other macros seems to work (tested with profile
) - might be an issue specifically with the table of contents macro.
Edit2
Thinking about this more, the issue might be that the deprecated endpoint respects the content
part of the payload that establishes a page context for the conversion, while the new endpoint might not.
My request body looks like this:
{
"content": { "id": "524289"},
"value": "<xml>",
"representation": "storage"
}
The content ID is crucial to establish page context.