Hi Angela,
Most of the entries inside of a tech doc are stored only in the content. Things like Titles, Subtitles, Lists, etc. are all only going to be accessible by parsing the XML in the content property. There are a handful of exceptions to this which can basically be boiled down to things that bring up separate dialogs when you add them like Images, Links, External Content, and Item references. However, these references use a separate ref-id attribute in order to link themselves to XML elements in the content.
The aras:id attribute you found doesn't reference an item in the database. It's randomly generated as you add new elements via the editor. I don't know exactly what it's used for, but it's just there to serve as a unique identifier in case the element needs to be looked up at some point.
One resource I'd recommend looking at if you're planning on also writing TechDoc content is this blog post on using Content Generators. These are specially formatted server methods that can be used to generate tech doc content based on some item information. It need a little more finessing since you're intending to call this via the REST API, but it should help save some of the hassle of actually writing the content to the document.
Chris
Christopher Gillis
Aras Labs Software Engineer
Hi Chris,
thanks for your answer!
I assume is not the best idea to directly manipulate the XML in the content property.
I think a solution based on your Content Generator sample is maybe the better approach. As far as I understood the blog post, the Content Generator can work with items that already exists in the data base. I assume this should theoretically work for federated data too.
One option is maybe that TechDocs get the data on demand via the REST API. So the 3rd party software doesn´t have to write anything into the Aras db.
Or we use a separate ItemType as data layer that the 3rd party software can easy access and update. This is presumably better regarding performance and data integrity.
Well, we will see which one works best for our current use case.
I'm interested in how these Tech Docs relate to the MPP Solution ProcessPlan. It seems when you create a ProcessPlan in the Process Plan editor it is using a special xml schema called MPP-Standard to render out operations, steps, tools, machines and resources. I want to know if a ProcessPlan can be constructed programmatically based off of another ProcessPlan (serving as a template) and have the rendered HTML have the ability to accept user input (that is pre-filtered to only accept specific item types from the user). Any thoughts on this scenario?
