Does anyone know if there is a way to enable an action to support returning an xml nodelist.
I am trying execute a workflow against a list of xml nodes. The problem I have is you cannot return an xml type from an action or a script action. Therefore I cannot create a workflow loop and as such the loop is required to be written into the code. I have tried to return an "any" type but I fails to deserialize xml.
Although in code it works in principal it means there is not much of a workflow.
I guess I could populate configuration objects and then loop but it would be much easier to just have an xml return type.
And I forgot to mention that you can consider the question as answered since actions can not return XML types.
We can of course continue the conversation if needed for the best work arounds.
Christophe.
Unfortunately XML type is not serializable in vCO (this type cannot be saved to the database between 2 boxes) . What I do is that I convert the XML back and forth to string. Another solution is to convert it to a Properties type (property list object) back and forth but this is more complex. I think someone in my team also put XML in a mimetype object set to XML.
Since this is becoming annoying I would recommend opening a support request so this can be supported in a next version.
Christophe.
Hi!
I usually also use strings to move small xml-data between different workflows elements. With E4X it's quite easy. For reference see these links:
http://www.xml.com/pub/a/2007/11/28/introducing-e4x.html
http://stackoverflow.com/questions/3912640/converting-string-to-e4x-xml-using-javascript
http://www.vcoportal.de/examples/xml-handling-the-e4x-way/
The way with mime-types I only use if there is a need to read/save the data in a file (in a resource element for example) or if external systems are in the game...
Regards,
Joerg
I had a crack at putting it into a config object which seems to have worked ok.
Its not very elegant but it does work.
I had a number of strings which needed to be kept together. I guess an easier way would have been the a delimited string but I wanted to work out the config objects as well so I figured I would take the harder route to success.
In the end I created a config object.
Put the number of attributes into the object
then loaded the strings against each xml node into arrays.
so the first line of my xml for example was
servername ip etc
then in my attributes for row one I would put it into
configElement(serverName[1])
configElement(ip[1])
then the next row of data would be loaded to
configElement(serverName[2])
configElement(ip[2])
then I used the array length as the counter for the loop.
its way over complicated but it was a learning process. As you say an xml return type would be significantly less expensive in terms of code.
The reason I used a config object was mainly as I wanted to create a loop from the xml data. Passing single strings would not have allowed the loop.
where does one log a support request.
One of the issue with config elements is that all attributes in a config elements are loaded by your workflow when starting and saved together when you update one of the attribute. Apart form the possible performance issue if provessing a lot of data you open the door to simultaneous updates overwriting each other.
I think that you know what you are doing and will figure out if this is a possible problem in your case.
For the support request, one or more people in your company must be the "technical contact" who can call / email VMware global support services. vCenter Orchestrator is part of vCenter so as long as you have a valid vCenter support contract you are entitled to open support requests.
Christophe.
And I forgot to mention that you can consider the question as answered since actions can not return XML types.
We can of course continue the conversation if needed for the best work arounds.
Christophe.
after you mentioned the properties I figured it would be cleaner to use a config array of properties objects.
re the loading of data, I didn't notice or know of the loading issues, so it is very useful to keep this in mind. In this case however I am not sure it will be a problem and performance is fairly low on the priority scale in this case. The tasks I am planning will be 24 hours or so execution anyway so a few seconds here and there are unlikely to be a problem.
I will worry about performance after I sort out exception handling.
If you go for properties you should use properties of properties instead of array of properties.
Christophe.