DNR (con't)

Granted, it is poorly documented (are you surprised?).

The following is a (massaged for the purpose) fragment of DNR code that I use for the "Transactional DNR,
on Target, After". I want a roll-back if DNR itself fails. Note that $status can be set in various places

...
use constant SUCCESS => 0;
use constant FAILURE => 1;

my $status = SUCCESS;
eval {main();};
if ($@) {
   log_it("Error Executing Deployment DNR Task: $@\n");
   $status = FAILURE;
}

# Let OpenDeploy know if processing failed
print qq(<response code="-2"/>\n) if($status);
exit($status);
...
sub main {...}

Awesome. Thank you very much, Boris.

Andy - did you see I topped the scales and am a Diamond now? I'm catching up. Only 3 billion more posts till I catch up to you...

nipper

Andy - did you see I topped the scales and am a Diamond now? I'm catching up. Only 3 billion more posts till I catch up to you...

snore, snore, snore.....huh, did someone say somthing. yawn. Oh, it i sonly smitty.

Sure whatever, I am quite impress. Smiley Very Happy

One more thing on this...what does OpenDeploy actually do when it gets this response code? Does it just log that the DNR script failed in the deployment log? Does it fail the whole deployment?

snore, snore, snore.....huh, did someone say somthing. yawn. Oh, it i sonly smitty.

Sure whatever, I am quite impress.

Speaky englishy? Smiley Tongue

Awesome. Thank you very much, Boris.

Andy - did you see I topped the scales and am a Diamond now? I'm catching up. Only 3 billion more posts till I catch up to you...

My pleasure

nipper

Speaky englishy?

so I cannot type when I am bored.

This got lost in the banter:

One more thing on this...what does OpenDeploy actually do when it gets this response code? Does it just log that the DNR script failed in the deployment log? Does it fail the whole deployment?

what does OpenDeploy actually do when it gets this response code?

That differs for different Trigger Permutations.

For the "Transactional, on Success, After" OD itself will automatically roll-back Transactional Deployment
upon receiving "-2", you do not have to do anything else. For non-transactional it's pretty much ignored.

So it doesn't show up in the deployment log as noting that something went wrong? That's disappointing. Thanks again...

This got lost in the banter

I've replied to the first one

Oh now that I look in the table in the document, it looks like it will fail the deployment if it sees an error code, so that's good news. I will have to play with it.

That differs for different Trigger Permutations.

For the "Transactional, on Success, After" OD itself will automatically roll-back Transactional Deployment
upon receiving "-2", you do not have to do anything else. For non-transactional it's pretty much ignored.

For non-transactional, I believe it should return the status code for "completed with error" which can be trapped in the script that invokes OpenDeploy if you wish to treat it as a failure (e.g. as part of a workflow).

Hi All,

This forum helped me a lot. But I would like to know one more thing.

I am doing DCR deployment and from the DNR I am updating DB.

Once OD is done, then from DNR scrpit DD is happening. Following are my configurations :

As per document and this forum discussion, I am sending the response to OD like to STDOUT. While I am checking the deployed status, The file is rollbacked but the directory structure is not getting rollbacked.

My File path is: "templatedata/aaaaa/dd-deploy-test/data/container_item_replicant.xml"

After rollback, at target the following directory structure is getting created but the file is rollbacked.
"templatedata/aaaaa/dd-deploy-test/data/".

As per understanding even this DIR path should be rollbacked.

Please let me know whether my understanding is correct or not. Any suggestions heartly welcome.

Cases_Created_Monthly.rptdesign

Hi All,

This forum helped me a lot. But I would like to know one more thing.

I am doing DCR deployment and from the DNR I am updating DB.

Once OD is done, then from DNR scrpit DD is happening. Following are my configurations :
<dnrDeployment when="after" location="source" state="success" triggerPoint="transfer">

As per document and this forum discussion, I am sending the response to OD like <response code="-2"/> to STDOUT. While I am checking the deployed status, The file is rollbacked but the directory structure is not getting rollbacked.

My File path is: "templatedata/aaaaa/dd-deploy-test/data/container_item_replicant.xml"

After rollback, at target the following directory structure is getting created but the file is rollbacked.
"templatedata/aaaaa/dd-deploy-test/data/".

As per understanding even this DIR path should be rollbacked.

Please let me know whether my understanding is correct or not. Any suggestions heartly welcome.

Hi Ghoti,

Thanks for your reply. I checked the forum date before posting my query. But as I inloved into the forum from beginning till end, I thought of updating the same, so that this forum may have completing information.

Will raise the new one and expecting your suggestions further.

Hi All,

The issue got resolved. I used the new configuration:
dnrDeployment when="after" location="target" state="success" triggerPoint="connect"

Earlier I was using:
dnrDeployment when="after" location="source" state="success" triggerPoint="transfer"

Hi All,

The issue got resolved. I used the new configuration:
dnrDeployment when="after" location="target" state="success" triggerPoint="connect"

Earlier I was using:
dnrDeployment when="after" location="source" state="success" triggerPoint="transfer"

- DNR or no DNR, failed transactional Deployment normally causes OD to remove both Files and Folders created
within Session's Transaction. The mechanism is not 100% perfect (what is?) but very reliable. If this is not
what you observe, you'll have to investigate. If you want/need more help, provide your Environment info
(Platform, TS and OD Versions/SPs, perhaps OD Configuration sample, etc...) and describe problem manifestation
in more details.

- Connection (second macro/first micro) Deployment Phase happens before data transfer. Trigger Point "connect"
may indeed have *helped* by not creating directories in the first place. It is possible that your DNR fails OD Session
before File Deployment actually starts.

- Finally, location "target" and location "source" are very different things, it is not mere configurational change.
Unless you have Base-to-Base (self) Deployment, DNR Code should exist on all Targets, excecutional Environments are
different, with the dnrDeployment it will be executed on each Target and so on. In other words, that's different
Deployment scenario.

scatter_scale_report.rptdesign

Hi ISCBorisB,

Your explanation is perfect. I agree with it. Also with respect to locaion attribute in my previous reply, it was my mistake. The behaviour is same for both source/target in this configuration. Only one thing I would like to inform here is - changing the "triggerPoint" resolved my issue, irrespective of location.

summary:
The issue got resolved. I used the new configuration:
dnrDeployment when="after" location="target" state="success" triggerPoint="connect"

Earlier I was using:
dnrDeployment when="after" location="target" state="success" triggerPoint="transfer"

If my trigger point is "transfer" then, the deployed file got rollbacked(but folders present). In case of trigger point is "connect" even the folder structure was rollbacked(folders were also not present after rollback).
Please note: Here I am speaking about folder level rollback, since I am deploying the "folders/files" to target for first time.

With the use of DNR Triggering you perhaps managed to bypass the problem for this particular Deployment, that's fine.

Something is still not right though. Once again, DNR or no DNR, irrespectively of DNR triggering, if everything works
as it should failed transactional Deployment removes both Files and Folders created within Session's Transaction.

The product behavior that you observe with "transfer" Triggering Point is simply not correct. It also *seems* peculiar to
your Environment. I used this DNR stuff for years without problems, normally with "transfer" (triggerPoint "transfer" is
actually a default for when="after" mode).

Testing with a single transactional deployment that rolls back is not a very good test. You need to test with several concurrent transactional deployments to the same target area on the same target receivers to verify that rollback actually cleans up after itself.

Because of the way transactional deployments (and their rollbacks) happen, the results of true concurrency is indeterminate.

If you are going to support "concurrent" transactional deployments, you want to make sure you enable

pathRegistryChecking

on the receiving side; and you may want to also enable

serializeDeploymentSetUp

on the sending side (see the OD Admin Guide for more details on both).

Hey, I think you actually implemented this here at Nike! Memory loss?

I think there are detailed explanations in the previous responses, but here's what I see as pertinent here:
- On the sending (base) side of the deployment, it'll just show up as a failure without much of a reason why when the DNR script throws the 'response code' error.
- On the receiving side (the receiver that runs the DNR), you can see in the micro log of the deployment that the execution of the script failed. This entry is only on the receiver, not the base.
- This all only works if the DNR script is constructed in such a way as to detect issues and then nicely spit out the 'response code' error. If the whole DNR craps out, OpenDeploy won't know about it other than perhaps eventually timing out.

I bet there have been feature requests in for 5+ years to improve the interaction between DNRs on receivers and the base OD that invokes them.

Wally
Nike, Inc.

Hey, I think you actually implemented this here at Nike! Memory loss?

That would have probably been Smitty - not me (though I don't know exactly who the "you" referred to in your statement).

I think there are detailed explanations in the previous responses, but here's what I see as pertinent here:
- On the sending (base) side of the deployment, it'll just show up as a failure without much of a reason why when the DNR script throws the 'response code' error.
- On the receiving side (the receiver that runs the DNR), you can see in the micro log of the deployment that the execution of the script failed. This entry is only on the receiver, not the base.
- This all only works if the DNR script is constructed in such a way as to detect issues and then nicely spit out the 'response code' error. If the whole DNR craps out, OpenDeploy won't know about it other than perhaps eventually timing out.

Theoretically you should be able to provide some description of the error into the logs, but as far as I know, that's never worked, you only get a "failure" notification if the script trapped the error and reported that back to OD via the XML snippet. If the DNR craps out completely, OpenDeploy will, I believe, assume that it succeeded and just continue on its merry way -- this is, at least in part, because there's no corresponding XML snippet to send to OD about success.

I bet there have been feature requests in for 5+ years to improve the interaction between DNRs on receivers and the base OD that invokes them.

Wally
Nike, Inc.

There were some attempts at getting OD to recognize failures to invoke DNR scripts, but I don't recall if it works at all or only in some circumstances.