0

I need a little help with a process we're trying to build that should be able to react dynamically.

The process goes a little something like this. User will submit a process request against an environment, submitting an array of string values as a runtime value. The process will take these in, as an array in bash, and loop through them, checking them against a predefined string list for validity. Upon finding they are valid, reacting differently based off of which values are in the string.

Example: User submits a process request with values "abc", "bcd", "cde", "def" Values "abc", "bcd", and "def" are valid.

We do a bit of manipulation to make them usable:

echo ${p:inputArray}
inputArray="${p:inputArray}"
inputArray=${inputArray//]/}
inputArray=${inputArray//[/}
inputArray=${inputArray//,/}
inputArray=( "${inputArray[@],,}" )

Then loop through each value and react:

for inputValue in $inputArray; do
    if [[ "${validInputArray[@]}" =~ "${inputValue}" ]]; then
         // Check if value is the outlier case "A"
         // Or if the value is normal (but multiple) case "B"
         // If case "B" then we'll build a variable for it
         // It should be something like ${p:environment/$inputValue.action}

This, ideally, would give me the value of ${p:environment/abc.action} for example. But it does not. It gives me a string. I have no way to evaluate the dynamically created property request, as all properties are evaluated at initialization and not on the fly.

We can handle it via a "case" method - but it's a bit ugly, and will only get uglier as our number of valid inputs grow.

Trentus
  • 1
  • 1

1 Answers1

0

Instead of sending it an array of values, you can configure UCD to prompt them for specific values. You can do this on the application process. That way, when the user kicks off the deployment, there is no guessing on the validity of the input.

On the process page of the application, click on the Application Process Properties link

enter image description here

From there, you can configure it to require a certain pattern (checked via regex), or explicit values from a drop down, raw text, dateTime, etc. Here, I've configured a property with a multi-select to allow specific JVM maximum heap values. By limiting this to specific values, you can avoid typos and failed deployments.

Once configured, when you launch your process, you are presented with the property in the interface:

enter image description here

Kenny
  • 316
  • 1
  • 9
  • Don't you still run into the issue of knowing what to do with/how to use each value? In your example - it's a multi-select so they could choose 2gb, 4gb, and 8gb. If they only choose one - that's a simple property replacement. However, if they choose all three, then it again becomes an array property, without a proper way to pull out the value other than a "check all values" type of loop. Unless I'm missing something? – Trentus Feb 01 '19 at 14:01
  • You have multiple data entry types. I selected a multi value. This could have been a drop down instead. – Kenny Feb 01 '19 at 16:49
  • Yes - but in our case it would be a multi-select as well. But how do you differentiate the values and react to them accordingly? If you were to select "2gb" and "4gb" in the same Deployment run, they both come across in the same variable (MaxHeapSize). However, they don't come across as a proper array. So how can you react to the multiple inputs without having a solid way to identify what the input is that you're bringing in? – Trentus Feb 04 '19 at 14:11
  • You would not use a multi-select if the variable can only have one value. This above is the example of adding 1 property. You can add multiple properties each with a different visual style (text, combo, check box, etc). – Kenny Feb 04 '19 at 16:51