Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
How do I change a jobvariable after running iwmodelch
DenisMP
After I start a workflow with iwmodelch, how do I get the workflow to wait for me to run iwjobvariable so that I can change the value of a global workflow variable? When I run:
iwmodelch -i StageFiles /default/main/testCategory/development/WORKAREA/denis
iwjobvariable -c JOB_NAME DENISJOB 13889
The workflow hangs in the first task because JOB_NAME is empty as a default in the workflow modeler. If I default the JOB_NAME to something like "myjobname" in the workflow modeler, the workflow takes off with the default value and not the one I set with the iwjobvariable command.
How do I get the workflow to wait until I set the global workflow variable from the command line and then proceed afterwards?
Find more posts tagged with
Comments
DenisMP
Hey Everybody,
I had a very informative meeting with the support folks at Interwoven.
Based on the conversation I learned the following:
1. The iwvariable commands do work as advertised.
2. There is a useful command called iwgetwfobj that dumps
the xml of the values in the workflow at the time the command is run.
3. The external task command attribute value, the script that gets
run when the external task is activated, only understands the value of
its command line arguments at the time the workflow is instantiated and
they cannot be changed. In other words, the -j CONFIGURABLE(JOBID) is
frozen once the workflow is started.
4. However, the value of the JOBID can be changed after the
workflow is started and the command scripts can set and read them at any
time, by using the iwjobvariable or iwtaskvariable commands within the
command scripts themselves. This mean that the current external task
can change the value of a variable before it transitions to the next
task.
What this means for us:
1. The script that calls the iwmodelch command must
communicate our jobid via a file or some other mechanism before the
workflow is instantiated via the iwmodelch command.
2. The first task in the workflow will need to be an external task
that reads the jobid via a file or some other mechanism in the command
script.
3. This same command script will then have to call the
iwjobvariable -t JOBID POPS_TRR1234567_1120i before it calls
the iwcallback .<br>4. This will cause the JOBID to be POPS_TRR1234567_1120i for any<br>tasks further down the workflow.<br>5. To get the value of JOBID, the command scripts will need to call<br>the iwjobvariable -g JOBID <iwjobid> to retrieve the new/current value<br>of JOBID.<br>6. This means that our external task command scripts need to remove the -jobid<br>POPS_TRR1234567_1120i argument from the command line arguments, or at<br>least not make the -jobid a required argument. The script will have to<br>get the JOBID as described above.<br><br>UPDATE:<br><br>Okay, so there was another little bit of information that I didn't know<br>about with the calls to iwmodelch and the iwjobvariable -t commands. I<br>put a 2 second sleep between the two calls. It appears that the<br>ControlHub needs a second or two to get the workflow set up enough for<br>the iwjobvariable -t commands to work effectively. This allows me to<br>invoke the workflow from the command line as we discussed in the<br>previous support case.<br><br>In my mytest.ksh external task command script I then repeatedly call the iwjobvariable -g command with a 2 second wait. This gives the OS command line script<br>time to invoke the workflow, wait 2 seconds, and then set the desired<br>workflow variable.<br><br>I also call the iwgetwfobj <wfid> in mytest.ksh and dump the xml to my<br>log. It is now setting the variable as we had previously discussed, and<br>my mytest.ksh script is able to read it.<br><br>So basically some handshake has to go on. The external task command scripts must poll for the value of the variable via the iwjobvariable -g command a number of time with a sleep until the variable is set or the max retries is exceeded. If the command script can't read the variable, perform an iwcallback with a transition link to an error task, such as an email task. I put the retry count to 30 with a 2 second sleep.<br><br>The user then must call the workflow via the iwmodelch command, wait 2 seconds and then call the iwjobvariable -t command to set the variable.<br>The user then must call the workflow via the iwmodelch command, wait 2 seconds and then call the iwjobvariable -t command to set the variable.