Is it possible to use an API call in a File template

API/CLI
, ,
1

Hello All,

I’m reaching out again as I posted before asking about what I would find out to be file templates.

Post is here.

This has worked wonders for what my team is trying to do I’m wondering though if there is a way to do an API call within these templates to grab some exact info on two options lists that we have. Instead of me hardcoding them and having the host pull it.

Seems kind of out in the wild but I thought I would reach out here first.

2

I’m not quite following the ask. If you are able to elaborate a bit more or do a run through of your process.

Morpheus variables (inputs/option lists) automatically get replaced within File Templates with the standard <%= %> syntax so there should be no need for an API call to occur.

3

Chris and OP,

I believe that beyond using the <%= %> syntax for simple variable substitution, using <% %> tags instead would allow more elaborate Groovy code to be run. Which then allows you to do all sorts of complex things, including API calls to other servers etc.

Just have to keep in mind that that code is run on the Morpheus appliance side, not the Endpoint side and that the output of the Groovy code is combined with the rest of the file template before it’s sent to the Endpoint.

Two important notes on the use of file templates:

  1. Any empty first and last lines in the file template are stripped, as well as the last CR+LR. I had a ticket open for this as a defect but the development team came back with:

String autotrim is system wide. A FILE template should not care about whitespace in general and trim is considered acceptable

  1. I have an open ticket for “File Templates alters existing/new file and folder permissions on Linux system to be less restrictive than they were before deploying the File Template”. The current stance from support is that this is “as designed in order to allow the Agent to write the file”. I’m about to update my response that this can’t be correct as it’s a) a security issue and b) can cause all sorts of system issues (up and not limited to unbootable systems) if people aren’t aware of this “design feature”. The workaround is to always dump file templates into a holding place and use a task to move them into the right place. Often times it then becomes easier to HEREDOC the file template directly in the Task instead of using file templates.

-Yaron.

4

Thanks for the response,

what I’m trying to accomplish is when I call an option lists during lets say post prov I need it to return the name and not the Value, It sounds weird but we’re trying to the actual meaning and not the Value associated with it. The only way I can see atm would be to hardcore the name but i am trying to find a way for it to print name and not the value just in the case.

5

If the options mapping doesn’t already contain the name of the input versus the value, you should be able to find the names via the keySet() method.

For example I used the below line to figure out what variables are set in a particular execution context (server vs instance). I used this to understand why serverId or containerId ended up being null and throwing exceptions in my Tasks I was trying to run on the appliance and endpoints.

foo = binding.variables.keySet()

In the above ‘foo’ will end up containing an array of all variable names available within the execution context of the script.

You might be able to use the Groovy containsKey() method as well to directly see if a specific variable is set/available in a mapping. I’ve not tested this method’s availability within Morpheus though.

-Yaron.

1 Like
6

Sorry for Reviving this post,

So since then, I switched over to using a script template as doing a here-doc given in the format we wanted. Returned much better results. I’m still stuck on getting the two option lists to return name instead of value. I tried the method you provided before and did not get far.

<%= customOptions.Environment.name %>" , I tried this and that just hung there as well. Any other insight would be much appreciated.

7

I don’t think you can reference name like that out-of-the-box, but what I would suggest is something like this if possible:

  1. Create a second option list, which contains your data, and have value store your name property.

  2. Make a new input, with fieldname of say, EnvironmentName which uses the option list, dependent on your existing input (Environment) such that it will update when that is selected/changed.

  3. In your second option list, use a translation script to do the match by checking the first, so it will be set to the name and will only contain 1 value (match the data line using input.Environment)

  4. Hide the new input (EnviromentName) on your form, or use CSS to hide it

  5. Reference the new input instead in your own script, <%= customOptions.EnvironmentName%> - its value will contain the name information you need.

It’s a bit contrived, but I think that will work. If you need assistance on this professional services can help you set this up.

8

Thank for the response!

I’ll ask my team what they would like to do next. At this point I’m ironically still doing extra steps lol.

1 Like
9

Just one thing I’d add. My suggested approach above assumes you need the value as well as the name. If you don’t need the value, you could implement the translation script in the existing option list, such that both the name and value are set to store the name data.

The below demonstrates a sample translation script which does this.

// default presentation of your data from option list
let data = [
    {"name":"name 1", "value":"1"},
    {"name":"name 2", "value":"2"},
]
console.log(data)

// results are what is shown to user in dropdown
let results = [];
for (let i = 0; i < data.length; i++){
	results.push({
        // we can restructure what is added to results shown to user
		name : data[i].name, // name stored in name key
		value : data[i].name // name stored in value key
	})
}

console.log(results)