Global Workflow Configurtion

Using TS 7.4.1 on RHEL and the WFM

We have a branch structure such that each site has Development, QA and Production subbranches. Then workflows are used to move updates to the next environment or revert to a previous version. There are various rules and configurations for each environment like if approval is required and who is notified and what OD deployment to use etc.

I'm looking for a way to define the environment configuration in one location so that different workflows in each environment use the single configuration file.

After combing the documentation, I think I have three options:

- Use a InProcessJavaCommand class to manipulate the global variables before the job is created
The problem with this it that it doesn't appear that you can set or even access the global variables which I believe is where the config information should be placed so it can be used universally.

- Customize the initiation form of each workflow and use IWDatacapture.callServer to get the common data and then populate a bunch of hidden global variables
I think this would work but it doesn't seem elegant and seems a bit laborious. I think I would need to hook the init and then use callServer to get the config info but it's async so I would have to block access to the initiation form until the callServer call is complete.

- Possibly write a MapDataSource to expose the common settings and then use it for the various properties.
However, data sources seem to be used for multivalue things like an approver picker. I don't know how I would supply the key for the value that should be used.

Has anyone done anything like this and have suggestions ?
Can anyone clarify the restrictions above?

I thought the InProcessJavaCommand was the way to go until I discovered that you don't have "legal" access to the global variables and the predefined variables like IW_WORKAREA. You can get these values using workflow.getParams() to get the hashmap but the docs say "The user is not supposed to use this map.". Given that note, I didn't go as far as trying to set the values. I don't know if using it will be a problem in the next version....

Find more posts tagged with

Comments

Garth McMillan

I've not looked into the workflow model's PreProcessor Command or PostProcessor Command, though they do seem to be what you might want.

In my case I created task called "Initialise job" which is the first task in the workflow and sets certain properties etc.

EDIT: I should add that you may want/need to be using Job variables instead of Global variables.

Adam Stoller

I'd think that configurable job variables would be the way to go.

Since you're concerned about the values of those variables on different branches, you could either use the WFM's ability to set values for different variables for different branches (see the section entitled "Configuring Workflow Models Using the Content Tab" in the WFM manual) or use FormAPI callServer to read a properties file and set the values for the various variables.

WGM

Using job variables is easier and they can be set up in InProcessJavaCommand.

However, unless I misunderstand things, only global variables can be used for task attributes. So if, for example, the configuration specifies a different workarea then the out-of-the-box update and submit tasks can't be used.

Not wanting to reinvent the wheel, I’d like to solution this in such a way that the configuration information can be used in the out-of-the-box tasks like update and submit as well as condition paths etc.

Is there a way to “surface” the job variables into something like a global variable?

Or I am going against the "model" of the new workflow/WFM pattern?

Is it normal to have custom things like URL tasks to do the ootb operations in "advanced" scenarios like this?

I was reviewing our older version of TeamSite (7.2 I think) and the perl based workflows therein. If I understand them, their basic model is a perl script generates the workflow model for instantiation and this provides the ultimate control over instantiation because the model is basically "defined" on the fly. These older workflows are using a global configuration in XML which is parsed in perl and the model dynamically altered as required and configuration information “injected” when needed.

In trying to mimic those older workflows, I guess I'm basically trying to do the same thing on a lesser scale (restricted to just initializing some variables preferably global).

Any suggestions?

Thanks in advance.

BTW: you guys are a great asset to the forums! If there is a reply it is usually one of you guys.

Rick Poulin

WGM wrote:
- Possibly write a MapDataSource to expose the common settings and then use it for the various properties.
However, data sources seem to be used for multivalue things like an approver picker. I don't know how I would supply the key for the value that should be used.

Create a datasource that checks a parameter called "prop". Then, create multiple datasource variables in your model, one for each property, and call your datasource with that property name as the variable. Your datasource will also "know" the branch context, so return a map/list/set/whatever containing only the one value for that field.

In the instantiation form, you'll end up with one dropdown per configuration property, and each should only have one value -- the one that corresponds to the property name and current branch. You can optionally hide these fields in your instantiation form via FormAPI if your users don't need to know the values. You may also need some FormAPI to actually setValue(0) [the first option].

I'd use this approach over a preprocessor or callserver shenanigans, personally.

Topic_39107__Using DIV to create charts__cwong.rptdesign

Topic_39107 -- DIV chart using BIRT.png

WGM

Thanks rpoutin, I'll give that a try. That might be a good compromise.

I'll just need to work out the syntax for the parameter and how to get the current workarea...

Adam Stoller

WGM wrote:
Thanks rpoutin, [...]

Rick - are you moonlighting as the head of Russia? ;-)

report.zip

WGM

LOL, Sorry about that... regardless of your nationality or political leanings, I think with a barrel of oil being ~$40, we can all agree that it's a bad time to be the leader of Russia when the country is soooo dependent on oil revenues....

So let me correct that and say:

Thanks rpoulin!