nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

iw_workarea and "New Job"

System

Production Environment: TS 6.5 (SP1) on Solaris
Development Environment: TS 6.5 (SP2) on Solaris

While testing SP2 on our Dev server, we noticed that Interwoven have *fixed* the Workflow Engine to conform to what's in the manual.

Namely, iw_workarea is no longer set when you start a Workflow with "New Job".

Under TS 5.5.2, 6.1 and 6.5 iw_workarea was set for both "Submit" and "New Job".

Is there a way to determine your workarea (other than __VALUE__('iw_workarea')) when you start a "New Job"?

Find more posts tagged with

Comments

Adam Stoller

From where are you initiating the workflow?
If you are initiating it from the Workflow tab in CCPro or the main portal UI in CCStd - iw_workarea was never set for those environments.
If you are initiating it from a workarea in CCPro - and it's not setting the iw_workarea information, I think that would constitute a bug (haven't had the opportunity to use 6.5SP2 yet)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

I am initiating the workflow from within a workarea.

What I have found in TS 6.5 SP2 is this, "You can no longer access the iw_workarea variable in the Workflow Initiation screen when you initiate a new_job." (It is provided if you start with submit).

You can get iw_workarea *once* you are in task, but not during initiation when starting with "New Job".

My question now becomes, "Is there a way to determine the workarea you are in, from within the workflow initialisation screen, when you start a new_job?"

Why do I want to do this? I have some workflows (that work just fine in TS 6.5 SP1) that setup some defaults based on the Workarea that you start the new job from.

Adam Stoller

What I have found in TS 6.5 SP2 is this, "You can no longer access the iw_workarea variable in the Workflow Initiation screen when you initiate a new_job." (It is provided if you start with submit).

I just looked through the SP2 release notes and supplement documents and can find no mention of this change. Is that quote yours, or did it come from somewhere else?

Page 77 of the TeamSite Workflow Developer's Guide (6.5 [SP1?) says:

iw_workarea Name of the current workarea (if you create the job from the workarea view or using submit). Have you contacted Support to verify if this is a [recreatable] bug or not? It certainly sounds like a bug to me.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

chuckles

We have seen this issue as well and have an open case with IW support. When we opened the case, we were told that we were not the first to report it. We are making do with SP1 for now because we rely heavily on that variable.

Johnny

We just ran into this problem as well.

I've raised a support case for it.

Migrateduser

Hi,

This has been filed as a bug and we are currently investigating it. If you select a file and then initiate the workflow through "new job", the variables will be passed properly. This is only happening when you do not select a file and initiate a workflow.

Thanks,
Helen

iwovGraduate

Can I get the bug # please?

Migrateduser

It's bug #62527

thanks,
Helen

Migrateduser

The quote in my previous messages was mine.

Thanks for the reference in the manual. It would appear that TS 6.5 SP2 only sets iw_workarea when a file has been attached to the new_job.

I have logged a Support call about this, and for the curious, I have attached a wft and screen shots if you want to test this.

Steps to re-create this bug on your SP2 server:
1. Install the workflow on your server
2. Go to a WORKAREA (with access to the installed workflow), and initiate a "New Job" (Workflow Variables Test) without attaching a file.
3. Note that iw_workarea has not been set.

Steps to see what it should do on your SP2 server:
1. Install the workflow on your server
2. Go to a WORKAREA (with access to the installed workflow) and select a file.
3. Initiate a "New Job" (Workflow Variables Test).
3. Note that iw_workarea is now set.

Explanation of files in the zip archive (iw_workarea.zip):
wft-var-test.wft
Simple workflow that can be triggered by new_job or submit that just dumps a few variables to the workflow screen, runs a dummy task, and then ends.

available_template.cfg
Extract of my available_templates.cfg file to install the above workflow.

sp1-new-job-no-files.gif
Screen shot showing the values returned when the above workflow is run from a WORKAREA TS 6.5 SP1 server. No files were attached to the workflow.

sp2-new-job-no-files.gif
Screen shot showing the errant behaviour when the above workflow is run from a WORKAREA on my TS 6.5 SP2 server. No files were attached to the workflow.

sp2-new-job-with-file.gif
Screen shot showing the correct behaviour when the above workflow is run from a WORKAREA on my TS 6.5 SP2 server. A single file was attached to the workflow.

cute_guy

Andrew,

When we migrated to the Teamsite 6.5, we also faced the same issue, iw_workarea value was not getting passed when the workflow is initiated from workarea using Action -> New Job option.

By using a script, We came know that there was an another variable "area_path" which has the workarea value.

Migrateduser

area_path does have a value set, but this value is set *after* the Workflow Initialisation screen has run.

That variable is also undocumented.

Migrateduser

(This is the experience of my organisation. Your mileage may vary).

A word of warning for those of you who have installed SP2, have experienced this issue, and want to go back to SP1. It is harder than it looks!

After finding the iw_workarea problem, documenting it, and telling Interwoven, we decided to rollback SP2 on our dev server. We followed the steps in the SP2 upplementary Guide and thought all was OK, until I ran the test workflow again.

The behaviour was still present; even though we now had SP1 on the machine. For some reason, the uninstall did not do a complete uninstall (or did it?).

We tried to then install SP1 back on top of SP1. No luck.

Not wanting to rebuilt our server from scratch, we then uninstalled SP1, then reinstalled SP1, and finally got our dev server back to how it should be. (Now, when I run New Job with no file attached, it behaves as it should.)

Half a day lost 'cause the SP2 uninstall did not work as documented.

Migrateduser

This bug is fixed in patch 1611 for Solaris and in an upcoming patch for Windows.

muks

Is this problem resolved with the latest patches installed or its still there?