I have created a workflow that creates shares and sets permissions. As part of that workflow, I have to generate (or find) names using a naming standard. The standard for a vfiler, for example, looks something like this "vfamitusen01" and it decodes something like this:
vf = vfiler, am = Americas region, it = IT department, us = User Share, en = Engineering environment, 01 = sequence number
the workflow has two modes of operation. One in which the user supplies a specific vfiler and volume where the new share will be created, and one in which the location is derived from inputs of the various components that go into the name.
In order to provide friendly names to the users while using a 2-char code in the name, I have some constants that look like
This way, in my commands, I only have to specify the vfilerName constant and it will work regardless which mode of operation the user selected.
My commands are: NoOp (to find the vfiler, volume and array), a couple custom commands to fail if certain conditions aren't met, create qtree, create share, set ACL, remove ACL. A second row is added that has only one command to set a second ACL on the share.
When I preview my workflow in "Specified" mode, everything works as expected. When I preview my workflow in "Derived" mode, the entire first row runs green. On the second row, the last command, the preview fails with a message of 'Illegal expression: useCaseMap'. Note that the use case map constant is not used in the command where the failure is reported. It is only used to generate the volume and vfiler names for the finders in the very first command - the null op command which worked. When I review the logs, the vfiler and volume names are correct. vfilerName constant was evaluated correctly and did what I expected. It's almost as if the failure is taking place after everything else is done. The worst part is, I had this working properly but forgot to save, walked away and WFA timed out losing my work. When I reconnected to the server and re-created it, now I get this error. I've tried a bunch of things to get this working and am at my wits end. I've even gone so far as to hard code one of the two-character values in place of the useCaseMap[$useCase] bit and when I did that, it started complaining about the regionMap instead. Still evaluated properly, still built a correct vfiler name, but now it's complaining about one of the other values in the list and reporting a failure at the end of the workflow.
Honestly, I can't think of anything else I can do here. Can anybody help me with this? Why does WFA interpret the MVEL correctly, populate the constant with the correct values, execute the commands successfully, then right at the end of the workflow fail with this error?
I have attached the server and finder logs and the .dar file in hopes that somebody can spot the problem. Any help would be truly appreciated.
Using the ternary operator $workflowMethod == 'Specified' ? $INPUT_Volume : 'v' + regionMap[$region] + businessUnitMap[$bu] + useCaseMap[$useCase]
Each of these had the same behavior. All the commands in the workflow preview green except the last one, then at the end I get that error message.
I even added a third row so that I could add a null-op at the end as the last command. The command that had failed before then completed and the failure moved to the new null-op. The failure is always on the last command regardless what that command is, regardless if it uses the value from the constant or not. That's got me wondering if it may be something internal to WFA rather than the workflow itself.
When a workflow is planned, it happens in various stages:
- Each of the command instances are evaluated
- Return parameters are evaluated
- Workflow constants are also registered in the internal workflow planning result.
During the planning of the attached workflow, it seems to have hit two issues in workflow constants i.e last step above:
a. Maps in constants are not getting evaluated correctly. Please refer to bug #770193 for the case that you have raised.
b. When there is a failure in resolution of the workflow constant, the error is always displayed on the last command, though that is not the location of the error. Please refer to bug #732015 for the case registered with NetApp support.
Though not ideal, instead of using maps, as a workaround I tried using functions for the five maps you had. It seems to work for the "derived" case. I did not try the "specified" case however.
I know this has been a while, but I just wanted to follow up that I did end up taking the advice and using a function to do the mapping. I only created one function and put all the maps into it rather than spread it out all over a bunch of different ones. It makes it easier for me to manage going forward. I still think since this function is only for this one workflow it would be ideal to be able to do it inside the workflow itself, but the workaround is doing the job for now.