Configuration Element attribute not editable when saved programatically

[qc4vmware]

I am saving an array to a configuration element attribute during a workflow run and the resulting value is saved as read only.  I was hoping to also be able to edit these values by hand if needed.  Is this by design and if so is there anyway to allow these to also be edited manually?

Paul

[cdecanini_]

How do you see it is read only ?

I just wrote the following and it works as expected.

First scriptable task

var array =new Array("Item1","Item2");
configurationElement.setAttributeWithKey("array",array);

Second scriptable box

array = configurationElement.getAttributeWithKey("array").value;
array.push("item3");
configurationElement.setAttributeWithKey("array",array)

I can then inspect the config element attribute and it contains the 3 items.

Usual error with config elements : forget to call the value property.

Usual error with arrays : forget to set it as output parameter in a scriptable box.

Christophe.

[qc4vmware]

I mean trying to edit it manually after saving it programatically.  Here is a screen shot.

[cdecanini_]

Good point. No, you cannot.

This would be a good feature request.

[cdecanini_]

In fact the reason you cannot is that the type is set to array and not array of organizations.

If you create an emty attribute of type, array of organization, fill it programatically you should be able to edit it manually after.

[qc4vmware]

It is actaully supposed to be an array of strings.  I am creating the attribute programatically as well.  Each one holds a blueprint of sorts.  Is there anyway programatically to save it as an "Array of strings"?

[Burke-]

If there is, I haven't come across it yet.. as far as I know, this cannot be done programmatically. That's why my team generally tries to create all the needed configuration attributes for any packages we create - to ensure that the object types are matching.

[qc4vmware]

My frustration is trying to figure out a good way of keeping user editable information for use within the workflows and also having these things be something that can be created if they don't already exist.  I like the configuration elements especially since they are easily to go in and manually adjust with the orchestrator client if I need to.  The resource elements are cumbersome to work with since I have to load them into a text file first to manipulate and if there is a mistake I can't quickly jump in and edit them.  What I was attempting to do with this array is create one configuration element called "Blueprints" and have a single attribute that is an array of strings.  That way I can add/remove them programatically and easily come in and view/edit the blueprint manually if I need to.  I am creating workflows that do the creation/editing so I can always fire those up but I guess I want what I want and it is frustrating tha I keep hitting these little roadblocks (and they are features that I am boggled don't exist).  Anyway if you have a suggestion on how I can easily accomplish what I am trying to do I'd love to get some guidance.

As always thanks for your expert help!

Paul.

[cdecanini_]

If these are just strings you could create an action adding them / getting them CSV style and converting back to array using the split method.

This would not be as nice as setting attributes in an array but this would allow editing.

Config element have been designed to be created at dev time in a similar way you can create workflow attributes : I was told from a vCO developer 5 years ago that the fact you can create a config element with setAttributeWithKey was indeed a bug. In the first place it was designed to set an existing attribute.

The feature request would be to make this bug official with having a method to create a configuration element attribute and set its type.

Christophe.

[qc4vmware]

Thanks Chris... I could do the delimited string but I am averse to that in most cases.  I'll likely just keep it in an array for now or use a properties type.  I still find myself a little confused on the composite types so I don't know if that is also an option.  I did put in a feature request now so who knows maybe they will change their thinking.  I really don't understand why it wouldn't be allowed.