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

Workflow timing

I am using custom scripts with my workflows that kick off submit, publish and deploy functions. Here is where I am seeing the potential for a problem: When a user kicks off a workflow and attaches their files, it will submit the files and publish an edition. At this point, it begins deploying the edition to our production servers. If another user kicks off a workflow and it submits and publishes an edition, the deployment files will see this new edition instead of the one that was created for employee number 1. If employee #1's deployments are not done when the new edition is created, the new edition will be deployed. The deployment files look for the latest edition and compare it to the one previous when getting the differences to deploy. Anyone have any suggestions on how to prevent this from happening?

Find more posts tagged with

Comments

Is there a particular reason you are using edition-compare deployment ?

If you want to deploy just the files that are in the submit list, use a file-list deployment. You will loose the do_delete option though. You can run a daily (or at a desired frequency) directory-compare deployment to take care of deletions.

Also, I am not sure why you need to publish an edition for each submit event.

We have multiple environments that we post to. Dev, QA, production, and training. We are using edition based so that a user may deploy files to the QA server, then are able to check their work prior to advancing the workflow on to the other environments. We are using Oracle Portal, so we are not able to truly see what our content will look like in Interwoven without deploying it to a server.

I am not sure I understand the process. Can you explain ?
I still think you can use file-list deployment instead of edition-compare.

So your wft might be something like:
deploy file-list to QA -> Approval Step --> Deploy file-list to training --> approval step --> deploy to prod.

Why can't you keep track in your workflow (as a variable) the name of the edition published in the workflow? Then you can use a substitution variable in your deployment config for the edition name and that should keep things clear between workflows.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

Would this option deploy only the differences between the named edition and the one right before it? I'm fairly new to this process, so I'm not quite sure how to implement that.

You could easily do that, just create substitution variables in your deployment config in each spot you need to enter your editions to compare. To figure out a previous edition, you can use the following code (substituting your own path names of course):

my $objid = `/interwoven/iw-home/bin/iwattrib <path to the edition> objid`;
my $nextObjid = `/interwoven/iw-home/bin/iwattrib -o $edObjid prevedition`;
my $nextName = `/interwoven/iw-home/bin/iwattrib -o $nextObjid name`;

The contents of $nextName will contain your previous edition name.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

How does the Edition number or name get stored so that I can pass it to the workflow and deployment in order to store it in the my $objid object? When the publish command executes, does it store that edition name/number in a variable that can be passed back to the workflow?

Evidently the iwpublish CLT does not return the name of the edition it creates (would be nice if it did). You can get it by doing the following right after you publish:

my $currobjid = `/interwoven/iw-home/bin/iwattrib <branch path> lastedition`;
my $curredname = `/interwoven/iw-home/bin/iwattrib -o $currobjid name`;

It's a bit of a pain, but once it's in the script you don't have to worry about it. And you should probably "chomp" the results of all these iwattrib commands.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

thanks!..I'm going to try that...I'll let ya know how it works out!

You might also look at: iw-home/bin/iwlasted /branch/vpath ...

--fish
(Interwoven Senior Technical Consultant)

Well sure, if you want to do everything the easy way...

Smiley Wink

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

PDL Rference Guide for Xerox WC 75xx series.pdf

I've implemented this line in my iwpublish.ipl file. I use it twice, the first time when I am first coming into the file to get the current edition and then afterwards when a new edition has been created. I am having problems however when trying to send the values that I created back to the workflow for use later. I have tried the CreateVariable function with no success....I believe I am not using it correctly. What I have is:
$job->CreateVariable("EDITION", $curredname);
$job->CreateVariable("IW_PREV", $prevedname);

Is this not the proper way to use them? If it is, how do I get the values back out of these variables for use in my deployment path? I plan on having EDITION and IW_PREV as my variables within the deployment config files. Any information would be greatly appreciated.

How are you attempting to read these variables in your deployment script?

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

I haven't gotten that far yet...I was just trying to debug them to a log file to make sure that they are there in the workflow...I was going to append at the end of my area: $EDITION^ and at the end of previousarea: $IW_PREV^. I just haven't figured out how to send them back to the workflow so that I can send them to the deployments.

I'm not sure I understand what you mean by make sure that they are there in the workflow. If you create workflow variables in a script, at what point are you printing them to your log file? Are you doing it in that same script? In another script? In your wft? What specifically are you doing that leads you to believe these variables are not being set up properly?

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

I have tried to debug them out to a log file in both the script file and my wft file and have not seen them in either instance in the log file.
This is a sample of what I have in my script file:
$currobjid = `c:/iw-home/bin/iwattrib $branch lastedition`;
$curredname = `c:/iw-home/bin/iwattrib -o $currobjid name`;
&debug ("currenteditionname:" . $curredname);
&debug ("currentobjectid:" . $currobjid);
$job->CreateVariable("EDITION", $curredname);
$job->CreateVariable("IW_PREV", $prevedname);
this debug shows up in the log file, however, if I look for $EDITION in either the script file or the wft file, it writes a blank to the log file.

First of all, you definitely won't see a workflow variable that is created in one of your externaltask scripts in your wft because by the time your externaltask script is executed, your wft file is a distant memory. It has already been converted to a job spec and newly created variables have no relationship with your wft file. Second, you do not refer to workflow variables by prepending a dollar sign to them ($EDITION). In order to look at this workflow variable:

$job->CreateVariable("EDITION", $curredname);

you would retrieve it in the same or another script like this:

my $edition = $job->GetVariable("EDITION");

Then you can print the $edition variable to your log file.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

thanks...that worked on getting me the variable...I have a question regarding parameter substitution with deployments: Is it possible to substitute more than one variable? This is what I'm using and it is not passing the previous parameter correctly...

C:\\od-home/bin/iwodstart " . $deploy_name . " -k current=" . $edition . " previous=" . $prevedition;

You need a -k for each parameter you are substituting for. You can't substitute more that one parameter for each -k on your command line.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

this all worked great!...Thanks for all your help!