DNR script running twice

I think my DNR script is running twice and causing problems...

I'll try and solve this on my own but if you have a quick response to this I would apperciate it.

Is this because I am doing a fan out and when each server completes it calls the script? How do I call it just once when the deployment to both servers finishes?

Here is the meat and tators of the config

<replicationFarmSet >
<replicationFarm name="nnn" >
<nodeRef useNode="n1" >
</nodeRef>
<nodeRef useNode="n2" >
</nodeRef>
</replicationFarm>
</replicationFarmSet>

<deployment transactional="yes" >
<execDeploymentTask useDefinition="blah" downRev="" >
<deployNRun >
<dnrDeployment location="source" when="after" state="success" >
<script cmd="D:/progra~1/interwoven/teamsite/iw-perl/bin/iwperl

/progra~1/interwoven/teamsite/httpd/iw-bin/script.ipl $wfid $taskid $area" as="admin" where="" async="no" >
</script>
</dnrDeployment>
</deployNRun>
</execDeploymentTask>
</deployment>

The Professor-

Find more posts tagged with

Comments

Migrateduser

Task-level triggers run for each deployment leg. Deployment-level triggers run for each deployment job. Check out OD 5.6 Admin Guide, starting on p. 202.

Also see the OD 5.6 SP1 Release Notes for supplemental info on DNR behavior with -2 response code (p. 51.)

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

ProfessorX

Does this apply to OD 5.5 as well...not on six yet

The Professor-

Adam Stoller

OpenDeploy 5.5 only supports execDeploymentTask-level DNRs.
The ability to specify dnrDeploymentJob DNRs is new as of OpenDeploy 5.6
In 5.5, you'd have to modify your DNR script to somehow keep state of how many times it's been attempted to be run and have it [gracefully] exit if it isn't the "last" time (a hack solution, but if you haven't / can't upgrade...)

--fish
(Interwoven Senior Technical Consultant)

ProfessorX

Thanks for your post...more reasons to upgrade to 5.6

just out of curiosity when you mean by "maintaining state" do you mean something like opening a temp file and then looking for a flag. If the flag is not there then it must be the first time the scritp was called so set the flag.

If not could youi please explain further.
thanks

The Professor-

Adam Stoller

That's one possible way of maintaining state, yes - and kind of what I was thinking of, though there are probably other ways to do it too. Like I said, it's pretty much a hack and probably not very robust - but it might allow you to simulate the functionality you're looking for.

--fish
(Interwoven Senior Technical Consultant)

ProfessorX

This post **** me off. What good is a dnrDeploymentJob if the return code is always 0=success

see post

http://devnet.interwoven.com/forums/cgi-bin/showthreaded.pl?Cat=&Board=PRODUCTS_OPENDEPLOY&Number=19868&page=0&view=collapsed&sb=5&o=0&vc=1#Post19868

The Professor-

Migrateduser

Sorry, didn't mean to upset anyone. Just wanted to point out the documented behavior.

Without getting too much into the details, I believe only DNR trigger points that occur while the sender and receiver are connected have the ability to report back success or failure of the DNR script.

I've filed a feature request for trigger points outside the connection window to be able to return error status (FR #44993). Please contact Tech Support to register interest in this request.

Todd Scallan
Group Product Manager
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com