Trigger automation from catalog inputs?

[#1]

Hi there,

I’m looking to have optional workflows/tasks accessible from the service catalog as options at request time for a customer doing VM provisioning. Something like a checkbox for agent-based backups that will cause an existing workflow to run that creates an additional nic and installs the backup agent.

Is there a way to use an input in a catalog item to determine what automation runs during provisioning (or immediately after, as long as it’s not additional work for the requester)?

[#2]

Thanks @cbunge,

I see what you’re doing, and was able to get it to work for a single workflow. However, this then replaces the normal workflow that happens during provisioning. Is the process limited to a single workflow taskset, or is there a way to stack them? There’s a set of config tasks that will always be needed, but they’re hoping to add some optional ones that can be enabled at request time in addition.

[cbunge]

@markp This is road mapped and we’ll start to see early work towards this with the release of 6.0 in a few weeks!

[#4]

cbunge:

The post task would check for any of the Boolean options and then make the pertinent API call to make that workflow execute against that system.

Is there a preferred/obvious approach for making this API call from the post task? I tried using fetch/JavaScript, but the API call fails with a message fetch is not defined. Fetch was the default example generated by the API docs when I clicked JavaScript. Is there a preferred way to do this in JS or prereqs I missed?

Not an urgent question, I’ve got it working in Python (and PowerShell in the homelab, because I’m a Windows guy at heart). I’m curious what it’d take to get it working in JS though.

[mphe]

This is where workflow logic could do with being enhanced a bit within Morpheus… have decisions made in a workflow task which determines the direction of travel (even just a true/false response would be advantageous). Also being able to have a workflow call another workflow would be useful.

The way I’ve done this is had each task verify if a checkbox was ticked at the start and exit gracefully if it’s not checked. This doesn’t work for a workflow sadly, since the task itself will just end and the rest of the workflow continues. Ideally I wanted to have a generic “check” task that could take an input with the option name to validate. Perhaps in a future release this functionality will be enhanced.

[#6]

cbunge:

Note: I have not tested this, so you may have to pass some value. Maybe a 0 or an empty workflow with an else {0}

And because I forgot to mention this previously. I tested, and it does want a value.

[cbunge]

So a few things:

1. This definitely shouldn’t be replacing any workflow that they have set. Assuming that they have a workflow configured as a policy, on the domain, or even set statically on the specific layout. That’s the way that any assigned and always needed to run workflow should be set.

2. If you’re going to offer a combination of many it might be best just to have a post-task always run as part of the default workflow. The post task would check for any of the Boolean options and then make the pertinent API call to make that workflow execute against that system. This way you could have all of your checks within one script in any language you desire.

[#8]

Thanks Chris,

RE: 1, we’ve got workflows set on the individual layouts. I’ll dig into that more if it’s unexpected. I’m not the only one in the environment, so sometimes there’s bonus changes I don’t find out about until something stops working.

RE: 2, I think that’ll be what I do. There’s talk of eventually fronting the Morpheus builds with their ticketing system, so keeping the logic in tasks rather than the catalog would make that simpler down the road too.

[cbunge]

On the catalog you would need to either add or modify this object in the json:

You probably only need to pass the taskSetId and it may allow a null value. So something like:

"workflow": {
  "taskSetId": "<%= if (customOptions.backups == 'on') {274} %>"
}

Or you can write a post task that runs the applicable workflow you would like as well.

Note: I have not tested this, so you may have to pass some value. Maybe a 0 or an empty workflow with an else {0}