Getting or Setting "ExtendedData"

Is there any way to access or set the "ExtendedData" values of a node through Web Services? I suspected "Features" might be related, but it doesn't seem to be what I'm looking for.

Find more posts tagged with

Comments

Carsten_Kulms

ExtendedData should not / cannot be accessed directly by the API by design: The data in ExtendedData - especially how it is stored / its format - is private to the corresponding node type implementation. There are strong arguments for this design, having data integrity and/or security in mind.The subtype specific LLNode implementation is responsible to maintain any of its properties stored in ExtentedData.In case of CWS this means the corresponding ServiceNode is responsible to perform whatever is necessary to process respectively provide/convert this data in/to features of corresponding proper SDO objects. You can see this, for example, with Projects: Some properties of a Project like the goals and mission are (currently) stored in ExtendedData - to specify (on create), update, or inspect these you have to use the ProjectInfo SDO with the Collaboration service API.In case you implement an own service and/or node type you should follow this design (i.e. at the API abstract from how the data is actually stored).This protects your implementation from inadvertently (or even intended but possibly malicious) data corruption and allows to change this aspect of the implementation when there is need without breaking the clients: the API and SDO will remain the same though the implementation details of handling and storage of exposed properties changes.

Sam_Archer

Thanks for the quick response. I definitely understand the reasoning you've suggested for hiding the Extended data from the API, but it does appear to be exposed by the DocumentsAPI in oscript already, I was just hoping to see it also available in Web Services.

More specifically to my situation, we've created a custom node type that is essentially a Document node with a few additional features, including (normally) some extra extended data properties. I can create these custom nodes through normal WebService calls by specifying my custom node type, so I was hoping I could also set the extended data without re-implementing the CreateNode web service method or writing a separate call just to update two extended data attributes.

Sounds like I'll be making an UpdateExtendedData method though, which should work fine. Thanks again for the response.

Carsten_Kulms

You do _not_ have to implement "the CreateNode web service method or writing a separate call": Since you created your own node type you should just create a corresponding ServiceNode (based on that for Document) and an extended NodeSDO specific for your type. In the latter you can define properties as you like, your ServiceNode implementation can, for example in _SubclassCreatePre, convert the data from the specific NodeSDO in something your LLNode implementation understands and puts that in the "createInfo" which is passed to your LLNode's NodeCreate function.You may like to step through a creation of your custom node type in LLBuilder to see what I tried to explain.

Jason_Smith

Another option is to use Node Features. This allows you to have additional information for specific node types, and would still just use the standard Node object. For example, URL node types use this for storing the URL location.

Sam_Archer

Quoted Carsten Kulms on 2013-02-28 12:19:

Since you created your own node type you should just create a corresponding ServiceNode (based on that for Document) and an extended NodeSDO specific for your type.

Maybe I'm missing something, but even if I did that, in my C#-based consumer of the web services, the DocumentManagementClient.GetNode() and CreateNode() methods will still be using the built-in "Node" class, which wouldn't include my additional properties. Or does creating a ServiceNode and/or NodeSDO provide an additional class that inherits Node to the service consumer?

Quoted Carsten Kulms on 2013-02-28 12:19:

I think going forward this looks to be the appropriate strategy to use. For various business-reasons (i.e. backwards compatibility) the properties will need to stay in ExtendedData for the time being, but I'll try to push in that direction.

Carsten_Kulms

Re. ServiceNode etc: Yes, basically it is as said- you get additional (sub)classes.Re. NodeFeature: this helpful remark was by Jason Smith :-)I forgot this possibility (and it is not favorite; but that would be a different story) - it could be the fastest approach to solve your issue.You can still store these additional properties wherever you like. It is up to the node implementation to handle these NodeFeature-s -- in what way ever.Setting NodeFeature on a (generic) NodeSDO is the easiest way pass additional and not specified in any way data. Just the code needs to know what to do with it (and what the keys/names are, what their type is, ...) Of course this code is to be implemented by you (ServiceNode)The ServiceNode implementation for URL is a good (and simple) example - inspect this in Builder.