creating a resource? is that the right way to store some strings?

[anoopvb]

I have a workflow that runs quite nicely. It dynamically fetches a list of groups based on a server that i choose from a drop down. Once the user selects a group, the workflow adds a member (vm) to that group on the server selected.

It uses the powershell module to do so. However, the powershell module is quite slow.

This results in the user waiting some time before the workflow is ready to run.

I thought perhaps, I could create another workflow that on a scheduled basis (maybe every few hours) fetches the list of groups for each server that's in my dropdown list and then updates a resource.

when the workflow runs, it simply looks at the resource for the list of groups as opposed to fetching it manually every single time.

is this a silly way to do things or am i on the right track? if so, just trying to figure out how i can create a resource that i can update dynamically on a scheduled basis.

thanks!

[cdecanini_ · Accepted solution]

I am not sure from what system you fetch the groups.

If possible I would try to implement this natively in vCO and check how fast this can be.

If it is slow then the method you described would work. If what you get is an array of objects the easy way to share the value would be a configuration element with an attribute with type array of whatever your object is. You can then use this as your other workflow attribute linking to this configuration element attribute.

For setting the configuration element you can do a config.setAttributeWithKey(attributeName, array);

If it is fast then you can use it to set a default value presentation property linked to your action.

[anoopvb]

Hi cdecanini_ Thank you for your response.

I can't create it natively in vCO as the powershell host is being used to execute a custom powershell module that I wrote.

The commands when run natively in powershell return within milliseconds for the list of groups. BUt when invoked via the powershell plugin, it takes up to 10 seconds or longer for a simple list of groups.

That's why I'd like to use the Configuration elements as you suggested. I wasn't aware that was the purpose of it.

Thank you so much for pointing me in that direction. I'll give it a go today!

[cdecanini_]

When I mention natively I mean vCO JavaScript code. For example you will get much better performance getting objects from the vCenter plug-in compared to running a powerCLI script. Using an application web service is faster than using its commandlets also JSON is JavaScript object notation which means it can be translated directly to and from JavaScript objects.

Usually the rare case where you must use Powershell are applications not offering any APIs besides commandlets (like creating a mailbox in Exchange).

[anoopvb]

I'm not using the powershell module to run vmware powercli scripts. I'm using it to run powershell scripts that i've written from a powershell module i've created that integrates with a backup appliance.

the powershell scripts fetch the list of groups from the backup appliance and my workflows add the VM selected to the group on the backup appliance.

[cdecanini_]

OK but how does your PS module talk to the backup appliance ?

If for example it is via a REST API then using the REST plug-in in vCO should give you better performance than going through a powershell host.

[anoopvb]

Hi cdecanini_

Yes. It is infact over a rest ful api.

My plan is to eventually integrate that way but i've done quite a bit of work with powershell already and didn't really have the time to work with the rest plugin.

I will definitely give it a shot at some point in the future. For now, I think the configuration elements will bridge the gap.

While the powershell plugin is slow, it's not that bad. It's only when presenting inputs that the customer has to wait 10-15 seconds so i'm trying to reduce that number initially.

thanks again! you have been a great help! I hope the likes are worth something

[cdecanini_]

Optimizing actions that are in presentation is key since end users expect fast answers. And yes the PS plug-in is convenient to reuse existing scripts.

The likes are OK but marking the answers as helpful or as the answer will help other users to identify what has been helpful to you.

[anoopvb]

Done & Done!

It's too bad that I can't assign a configuration element a script output.

thanks again!