Configurable Job Variable

I have a WFM workflow where I am defining a hidden Configurable Job Variable and assigning it a default value of some string. I also have a PostProcessor Java class that updates the value of that Configurable Job Variable string based on some logic. That works great.

Problem is, I have some individual task variables that I also want to be updated to this same value as the Configurable Job Variable. I define the Value of the individual task variables to be the Configurable Job Variable (same ID). It would make sense (to me) that therefore, when the job variable is updated, the task variables would also be updated. But the task variables retain their same default string when I modify the job variable in the PostProcessor code.

I am verifying this by using the Debug mode during instantiation of the workflow. I can see that the job variable is updated, but the task variables are not. Is this just not how it works? Do I need to also update each task variable individually in the PostProcessing code? That would be a pain. I suppose I could change the code that uses the task variables to use the job variable instead, but I was hoping to not change any code.

If there's a cool way to map a task variable to a configurable job variable where if you change the job variable, all the task variables automatically update to that same value, please enlighten me.

TS 6.7.2 Solaris

Find more posts tagged with

Comments

Adam Stoller

Do you define the configurable variable as a workflow variable or a system / global variable?

Try defining it in the System (or Global - can't remember right now) Variables and then reference it in the tasks, etc. (not creating another variable with the same name, actually referencing the one that already exists) - and see if that helps.

Migrateduser

Do you define the configurable variable as a workflow variable or a system / global variable?

Try defining it in the System (or Global - can't remember right now) Variables and then reference it in the tasks, etc. (not creating another variable with the same name, actually referencing the one that already exists) - and see if that helps.

I initially defined the variable as a System/Global variable (Global is a type of System Variable) and I was not able to use the PostProcessor class to update that variable. It claimed that it could not find a variable by that name when I used WFMWorkflow.updateVariable(). Only when I made it a Job Variable was I able to manipulate the value using my PostProcessor class.

If you have any idea how one can update the value of a System/Global variable from the WFM package, I'm all ears. I am still not sure why the value for the Job Variable doesn't get propagated to the values of my task variables when I set the value to equal the Configurable Job Variable. Do you know if that *should* work?

I'm pretty sure I would be able to reference the Job Variable instead of the Task Variables I am trying to assign to the value of the Global Variable, but then I'd have to change the code in my externaltask classes and I don't want to to that if I can help it. Even worse, I would have to set the Reviewer Group in my ReviewTask in the code, and I really don't want to do that.

Migrateduser

I have been messing around with this a bit more and trying to figure out why the WFMWorkflow instance doesn't recognize Global Variables as variables that are available with the updateVariable() method.

I was able to create a Global Variable (configurable) and assign that value to a task variable and to the reviewer group in my ReviewTask. That seems to work with the default value. However, I want to change the value in my PostProcessor class and can't seem to do that - it doesn't recognize Global Variables as Variables, which is weird. If I choose Debug in my instantiation screen, you can see the Model contains the Global Variables as a separate property from Job Variables:

[HTML]
Online_Mkt_Workflow_Approvers
[/HTML]

It does not, however show its label, which I set to "ApprovalGroup". It also does not show up anywhere in the Final Job Spec - that value is just filled in for the task variable and shared-by that I assigned to equal the Global Variable. So I am thinking that this Global Variable is not changeable in the CSSDK, pretty much treated as a constant and not a variable, which I think is a bug.

Adam Stoller

I don't think this will work - but you might give it a try:

Then see if your post-processor code can manipulate the value of the job variable and if so, if that manipulation carries through to the task variable (probably not, but ...)Another issue here might be that you're using a PostProcessor class rather than a PreProcessor class (I'm assuming both exist - I haven't tried doing anything with either) - and whether it's "too late" to manipulate the global variable in the Post-operative processing...Can you provide a semi-detailed explanation of what you're trying to do?I'm wondering if there might just be a different approach that might work better.(For instance, I've tended to replace all my global CVs with global SVs because the code for managing pre-branch configurations is (IMO) very buggy and thus not reliable for use - so instead if create these little mini-scripts to set values for things based on the value of other things (like "$IW_WORKAREA"))

Migrateduser

Thanks for the suggestion. I tried something similar and it didn't work. It only updated the job variable and not the task variables. Good try, though - you'd think it would work.

What we're trying to do is use a single WFM, which has a ReviewTask, but allow it to be used for multiple different departments and therefore assign different approval groups to the ReviewTask based on who is executing the workflow. So we decided the best approach would be to have one entry in the available_models.xml for each department, uniquely named for that department, but assigned to the same WFM. We'll use the PostProcessor class to parse the workflow name that was chosen, map that to a specific TeamSite group, then assign that group to the ReviewTask. That's it in a nutshell - there's more but that's the crux of it.

The problem is that there appears to be no way to change a Global Configurable Variable via the SDK. You can have it appear in the instantiation form and change it manually, but there's no mechanism to change it in any Java class. This is substantiated by the fact that if you look in the debug output of the instantiation, the Global Variables are only saved by value, not by name/value pair, as the Job Variables are. So there's no way to even reference them by name, even if they gave you a Java hook into the Global Variables. Seems like someone dropped that ball to me.

I can see why you wouldn't allow any changes to Global Variables after instantiation, but certainly you should be able to modify the value during instantiation, or before (PreProcessor). But the same Java classes are available for both Pre and Post instantiation, so regardless, there's no method to do it.

So what I am going to do is make it a Job Variable and update it appropriately in my PostProcessor class. Then in all the places where I have a Task Variable assigned for that value, I will change the code for those tasks to look at the Job Variable instead. That's easy. And in the ReviewTask and GroupTask, I will just search for those tasks and set their Reviewer Group and Shared By values in the PostProcessor code. Not ideal, but it should work.

If you have a better suggestion, I'd love to hear it. Thanks for your help thus far.

Adam Stoller

What we're trying to do is use a single WFM, which has a ReviewTask, but allow it to be used for multiple different departments and therefore assign different approval groups to the ReviewTask based on who is executing the workflow. So we decided the best approach would be to have one entry in the available_models.xml for each department, uniquely named for that department, but assigned to the same WFM. We'll use the PostProcessor class to parse the workflow name that was chosen, map that to a specific TeamSite group, then assign that group to the ReviewTask. That's it in a nutshell - there's more but that's the crux of it.
...
If you have a better suggestion, I'd love to hear it. Thanks for your help thus far.

Well, you might be able to do the same thing with a Global Script Variable - depending on how closely you can map the workflow name to the reviewer group (and depending on what actually gets stored in $IW_WFNAME):

"$IW_WFNAME" + "_Reviewers";

Or:

if ("$IW_WFNAME".match(/HR/)) { "hr_reviewers"; }
else if ("$IW_WFNAME".match(/Marketing/)) { "mkt_reviewers"; }
...
else { "general_reviewers"; }

If that works, you can use the global script variable as the value for the group that shares the grouptask, etc.

It's obviously not a major breakthrough - just a possible variant of your own devised work-around.

You should probably open a case with Support - they'll probably classify it as an enhancement request, but it's better than not getting it filed at all...

Migrateduser

Thanks again for the ideas. I like that approach, but I'm not sure I have the correct variable I would need for the display name of the workflow. The display name, in other words the name you assign to the workflow in available_models.xml and the name the user sees on the list of available workflows when they click the Submit button, is an obscure job variable called '[size=2]IW-ModelDispName'. This is different than the Workflow Name, which is the name you assign the workflow in the WFM, which is what I believe $IW_WFNAME contains. This is just an example of the fun stuff I have learned from this process. So if there is a way to get [color=black]the [size=2][size=2]IW-ModelDispName in the script, it might be doable.[/size][/color][/size][/size]
[size=2][color=black][size=2][size=2][/size][/size][/size][/color]
[size=2][color=black][size=2][size=2]I did open a case with support, but I'm sure it will be a couple weeks before I hear anything. And thats optimistic. I agree that they will likely consider this an enhancement, even though I think it's a glaring hole in their SDK design[/size][/size][/size][/color]
[size=2][color=black][size=2][size=2][/size][/size][/size][/color]
[size=2][color=black][size=2][size=2]Thanks again for all your help![/size][/size][/size][/color][size=2][color=black][size=2][size=2]
[/size][/size][/size][/color]

Migrateduser

Well I'm back to square one. Interwoven has made it very difficult to accomplish what I want to do. Evidently you are not allowed to update a ReviewTask's review groups from a PostProcessor. It throws an exception. Why? I have no idea. So I tried to update the Workflow Name (the actual WFM workflow name) to include the same unique prefix that the Workflow Display Name contains to distinguish it. But this is not possible either. There is no setName() method on a WFMWorkflow object. Why? I have no idea. I also tried making the WFM Workflow Name a configurable variable and updating that variable in the PostProcessor. Didn't work.

So I am going to drop the idea of using Pre/PostProcessor code to do this. It *should* be doable, but I don't have time to figure out how. I am going to just create a new externaltask at the start of the job that does what I need to do.

Migrateduser

More Interwoven awesomeness. There is no such thing as a CSReviewTask in the CSSDK, so there's no way that I can see to modify the reviewer groups from that framework. This is effing nuts...

***UPDATE***
Evidently a ReviewTask is a CSGroupTask as far as the CSSDK is concerned. I found this out purely by accident - there appears to be no documentation to lead you there. I was going to turn my RevliewTask into a GroupTask (not sure what the difference is anyway), but first I wanted to be sure that I could change the SharedBy group for a CSGroupTask in the code and make it work. Once I did that - change the SharedBy group for all GroupTasks in the workflow, I discovered that it changed the ReviewerGroup in the ReviewTask as well. Go figure. So I think I have a hack of a solution. Woohoo!

jbonifaci

Dave,

I change groups for tasks dynamically at instantiation in all of my WFMs. My normal method is to do it from the custom instantiation screen. Rather than register your model multiple times, you can probably access the same logic in the custom instantiation instead.

For example, if your different groups are based off of branch name, you can set the group for the task based on the branch in the custom instantiation:

1) Create a global WFM variable named "ReviewerVariableName".

2) Add the custom variable "ReviewerVariableName" to your reviewer task sharedby.

3) Create a custom_instantiation.cfg for your WFM (you probably already have one).

4) Add an item to the custom_instantiation.cfg named "ReviewerVariableName" that is multi select.

5) Add code to your formapi to set the options of the "ReviewerVariableName" item to the users you want in your group and mark them all selected. (base this on branch, user name, etc.).

That should work, although you may have some work to do around loading the users from your group via either inline or a callserver.

Hope that helps.

~Jeff