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; } } }

WF change in the new version

Jenni

Hi All,

Thanks for the replies. We are on TeamSite 7.2.1a (windows 2008 64 bit VM). We have a workflow (partial code is shown below) that would just go on executing the first task in the workflow without user input once initiated by clicking the submit button. But when we moved the workflow and its related files to the prod env. from dev env, after initiating the workflow by clicking the submit button there is need for us to go to the workflow tab and click on the "Start Input Task" button to proceed the workflow. Also everything else works fine.

I even verified that we are invoking the same workflow from available_templates.cfg.

I am curious to know how the "Start Input Task" button is appearing on the workflow and also why do we need to go to the workflow tab to start the workflow process.

Any pointers on this matter is greatly appreciated.

[html]

owner="__TAG__('iw_user');"
creator="__TAG__('iw_user');"
description="__INSERT__($submit_cmt);">

__INSERT__("$fin_var");

name="Submit_And_PostProcessing"
start="t"
immediate="t">

__INSERT__("");

 if (__ELEM__('iw_file') != 0) { __INSERT__("<files>\n"); for (my $i=0; $i < __ELEM__('iw_file'); ++$i) { __INSERT__(" <file path='__TAG__(iw_file[$i]);' comment='__TAG__(File_comment_$i);'/>\n"); } __INSERT__("</files>\n"); } 

owner="__TAG__('iw_user');"
description="Failure email notification to CM">

__INSERT__("");

[/html]

Find more posts tagged with

Comments

interDev

Do you see this behavoir with a specific role or with all the roles including Master?

Also Is the owner of Workarea same in both the environments?

Adam Stoller

Since

__TAG__('iw_user');

is being used for the owner / creator of the workflow and the owner of the CGI Task - the owner of the workarea shouldn't really have an effect in this case.

The code looks correct. If you have the ability to enable WFT debugging, I suggest you do so, run the job on both your DEV and PROD environments with debugging enabled to get the job specification file from each - and then diff the two files (ignoring timestamp and TS server name differences) and see if you can find anything that might account for the difference in behavior.

(I'm assuming that clicking on Start Input Task works - right?)

Jenni

Do you see this behavoir with a specific role or with all the roles including Master?

Also Is the owner of Workarea same in both the environments?

Hi interDev,

The issue is with all roles. The owner of the WA remains the same in both environments.

Jenni

Since
__TAG__('iw_user');
is being used for the owner / creator of the workflow and the owner of the CGI Task - the owner of the workarea shouldn't really have an effect in this case.

The code looks correct. If you have the ability to enable WFT debugging, I suggest you do so, run the job on both your DEV and PROD environments with debugging enabled to get the job specification file from each - and then diff the two files (ignoring timestamp and TS server name differences) and see if you can find anything that might account for the difference in behavior.

(I'm assuming that clicking on Start Input Task works - right?)

I had checked the job specs on both the environments. They look the same. When I click the Start Input Task, it works fine.

Adam Stoller

I had checked the job specs on both the environments. They look the same. When I click the Start Input Task, it works fine.

I suggest you open a case with Support - you'll probably have to get them to set up a webex session so that it can be seen by them in real-time.

interDev

Hi interDev,

The issue is with all roles. The owner of the WA remains the same in both environments.

Do you have any other workflow in your production env. which has cgi task as the first of workflow. If yes, how does it behave?
If not, will there be possiblity for you to create a very simple workflow which will start with cgi task. Dont do any processing or anything. Simply check how it behaves.

I dont have any specific answer to your problem but i am trying to find out if its a environment problem vs code problem.

Also i would assume that the behavoir is across all branches and workareas.

Jenni

Do you have any other workflow in your production env. which has cgi task as the first of workflow. If yes, how does it behave?
If not, will there be possiblity for you to create a very simple workflow which will start with cgi task. Dont do any processing or anything. Simply check how it behaves.

I dont have any specific answer to your problem but i am trying to find out if its a environment problem vs code problem.

Also i would assume that the behavoir is across all branches and workareas.

We dont have any other wf that has CGI as the first task. But the OOB submit direct also behaves in the similar manner with minor change(the wf goes to the workflow tab, has the Start input Task button and executes in about 1 mins without user clicking the button.) I will try to code a wf witha a CGI and post the results shortly.

Yes the behaviour is across all branches/workareas.

Migrateduser

Do you have any other workflow in your production env. which has cgi task as the first of workflow. If yes, how does it behave?
If not, will there be possiblity for you to create a very simple workflow which will start with cgi task. Dont do any processing or anything. Simply check how it behaves.

I dont have any specific answer to your problem but i am trying to find out if its a environment problem vs code problem.

Also i would assume that the behavoir is across all branches and workareas.

How much more simple a workflow can they write than the one they posted?

interDev

How much more simple a workflow can they write than the one they posted?

Did you read Jenni's message completely? It has been clearly mentioned that the code shared is partial, so i dont know what exactly is missing from this sample code. You want to take the assumption, go ahead.

do you have any suggestion for Jenni, post it instead of finding out problems with the suggestions of others..

Migrateduser

Did you read the workflow, genius? It's a complete workflow. Suggestion - try some decaf...

Adam Stoller

In the interests of trying to separate custom code issue from product code issue - try changing:[html]...
__INSERT__("");
...[/html]to:[html]...

...[/html]The job will never transition past the CGI Task - but it would be useful to know if the show_env window starts "immediately" or requires the clicking on the "Start Input Task" button.

If show_env.ipl has the same problem, I again suggest contacting Support - using the example with show_env.ipl as that way you eliminate some of their "it's custom code we don't debug custom code" arguments (they still might use that for the WFT, but it's simple enough that you should be able to get by that hurdle)

If show_env.ipl works without any problems, please verify what the value

$cmd1

- if possible (without crossing any corporate boundaries) post the actual value exactly as-is.

Jenni

In the interests of trying to separate custom code issue from product code issue - try changing:[html]...
__INSERT__("");
...[/html]to:[html]...

...[/html]The job will never transition past the CGI Task - but it would be useful to know if the show_env window starts "immediately" or requires the clicking on the "Start Input Task" button.

If show_env.ipl has the same problem, I again suggest contacting Support - using the example with show_env.ipl as that way you eliminate some of their "it's custom code we don't debug custom code" arguments (they still might use that for the WFT, but it's simple enough that you should be able to get by that hurdle)

If show_env.ipl works without any problems, please verify what the value
$cmd1
- if possible (without crossing any corporate boundaries) post the actual value exactly as-is.

Hi Ghoti,

I am having the same issue with show_env.ipl. I have opened a case with the support as well.

My take on this.. this is not a coding issue. The code works well on all 6.7.1 versions and our development/uat 7.2.1a evnironments but not on production 7.2.1a environment.

Jenni

Do you have any other workflow in your production env. which has cgi task as the first of workflow. If yes, how does it behave?
If not, will there be possiblity for you to create a very simple workflow which will start with cgi task. Dont do any processing or anything. Simply check how it behaves.

I dont have any specific answer to your problem but i am trying to find out if its a environment problem vs code problem.

Also i would assume that the behavoir is across all branches and workareas.

The issue is with the new workflows with CGI as the first task.

Adam Stoller

Hi Ghoti,

I am having the same issue with show_env.ipl. I have opened a case with the support as well.

My take on this.. this is not a coding issue. The code works well on all 6.7.1 versions and our development/uat 7.2.1a evnironments but not on production 7.2.1a environment.

Well, given that it works in your DEV/UAT 7.2.1a environment but not your PROD 7.2.1a environment - it sounds like an environment issue rather than a product code issue.

Were all three environments done as upgrades? fresh-installs? or a mix?
Are all three environments running the same OS? All on VMs?

You might consider downloading (if you don't have it already) Beyond Compare and performing a complete comparison between your DEV (or UAT) and PROD IWHOME directories to verify that all the product files are identical (or contain only understandable differences like embedded IP addresses and hostnames)

Jenni

All three environments were a fresh install and we moved our content store/custom files over.

We have the same OS configurations (2008 Windows 64 bit VM).

I will do the comparisons and post the results.

Jenni

I went ahead and did the compare of the iw-home directory. There were no noticable differences in the files (especially the workflow and its external files).

Adam Stoller

I went ahead and did the compare of the iw-home directory. There were no noticable differences in the files (especially the workflow and its external files).

I'd be more interested in the files that live in IWHOME/bin, IWHOME/httpd/iw-bin, etc. as it sounds like the problem is more of an underlying issue than a workflow-specific issue (or did I misunderstand that aspect of the issue?)

You can try to go through Support - maybe they'll be able to assist or provide you some alternative ideas for debugging the issue?

Jenni

I had contacted the support.
Setting the below value to true in iw.cfg worked well.

[authentication]
impersonate_without_password=true