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

Deployment Level DNR Script | Rollback Issue

vijetha

I have requirement to run database deployment script after open deploy is successful and Opendeploy changes should be rollback in cases of database deploy failed. Currently I am using the dnrDeploymentJob for executing the database deployment and this is perfectly executing once the Opendeploy is successful but if in case of database deploy failure(i.e dnrDeploymentJob script), the rollback of OD changes are not happening.

Script is returning the (\n) to STDOUT. Same is working fine if I call the script as deployNRun.

Is there anyway to get the deployment to fail and rollback OD changes when the deployment-level trigger fails?

TS6.7.1, OD6.1.1 on solaris10.

Thanks in advance

Find more posts tagged with

Comments

Adam Stoller

I have requirement to run database deployment script after open deploy is successful and Opendeploy changes should be rollback in cases of database deploy failed. Currently I am using the dnrDeploymentJob for executing the database deployment and this is perfectly executing once the Opendeploy is successful but if in case of database deploy failure(i.e dnrDeploymentJob script), the rollback of OD changes are not happening.

Script is returning the (\n) to STDOUT. Same is working fine if I call the script as deployNRun.

Is there anyway to get the deployment to fail and rollback OD changes when the deployment-level trigger fails?

TS6.7.1, OD6.1.1 on solaris10.

Thanks in advance

You cannot do it with dnrDeploymentJob - you can do it with dnrDeployment and set your triggerpoints correctly.

If you have need to a fan-out for the file deployment - you need to duplicate the definition and define one farm with one node and another farm with the other node(s) - and attach the dnrDeployment to the execDeployment task that is associated with the single node farm

auli

I am also facing the same problem. So what I understood is that for this scenario, we cant use more than one node in one farm. Correct me if I am wrong.

vijetha

Thanks for your reply, but here I have multiple definition to be executed. So we cant use dnrDeployment for every execDeployment task as it executes the same script multiple times.

Is there any other way to achieve this?

Thanks

Adam Stoller

Thanks for your reply, but here I have multiple definition to be executed. So we cant use dnrDeployment for every execDeployment task as it executes the same script multiple times.

Is there any other way to achieve this?

Thanks

Given your scenario I don't think there is a clean way to do what you want - you either run the DD first and then OD in transactional mode (on failure, attempt to run another DD to back out the changes you already committed) - or you run OD transactional first, and then DD (dnrDeploymentJob) and if DD fails, you either try again or do another OD to back out the files that you already committed.

In each case - you have to treat the OD and DD parts as distinct entities because you cannot pre-ordain what aspect of the OD process is going to fire off last every time in order to attach a DD process to it.

The only hack I can think of, and I'm not even sure if it's possible, is to invent a separate replicationFarm/definition/execDeploymentTask process that somehow tracks all the other legs of the deployment before saying "done" in order to attach the DD process to that "dummy" leg. It's sort of like dnrDeploymentJob but attempting to execute at the last possible moment within the dnrDeployment [not Job] timeframe.

vpatel

Have you tried looking into target-side synchronized deployments? Will that fulfill your requirements?

Adam Stoller

Have you tried looking into target-side synchronized deployments? Will that fulfill your requirements?

First - that requires that your receiver be a Base Server (enabled to run DD) - right?
Second - I'm not sure how that changes much in terms of the problems of trying to coordinate a single DD process with a multi-leg OD process in a fully transactional mode.

vpatel

First - that requires that your receiver be a Base Server (enabled to run DD) - right?

On the target side: OD RCVR can do the job just fine. OD Base is not required.

Second - I'm not sure how that changes much in terms of the problems of trying to coordinate a single DD process with a multi-leg OD process in a fully transactional mode.

I am not sure about the exact requirements and that is the reason I kicked the question back to the owner if this will suffice for his/her need. I was just wondering if he/she was aware of this feature of sync'ed deployments -- if one fails they both revert back.

Adam Stoller

OD RCVR can do the job just fine. OD Base is not required.

You're saying that a Receiver can be licensed to run DD?
I always thought that the DD feature was restricted to BaseServers

vpatel

You're saying that a Receiver can be licensed to run DD?
I always thought that the DD feature was restricted to BaseServers

Let me clear this up a little bit: you need an OD Base on the source side and OD RCVR on the target side. OD Base (source side) has to be DD enabled as well. You do not need a OD Base on the target side.

HTH

Adam Stoller

Let me clear this up a little bit: you need an OD Base on the source side and OD RCVR on the target side. OD Base (source side) has to be DD enabled as well. You do not need a OD Base on the target side.

HTH

I'm still not clear - you said target-side synchronized deployments - I took a quick look in the OD 6.2.1 Admin Guide and found the following on page 186:[indent]

possible.Did I misunderstand the documentation on target-side synchronized deployments?Did I misunderstand limitations of licensing DD to only Base Servers?If so - there's probably a doc-bug to be filed.

vpatel

Adam: you are probably correct in saying:

And as far as I know, the latter is not [officially?] possible.

The way I understand this works is basically when you kick off a sync'ed OD/DD deployment:
1. It will OD files to target server + some other "internal" artifacts related to the target side deployment.
2. On the target side, OD will create "internal" DD deployment config file (yes deployment config file) + "internal" DD file list (only certain files will make it to the DB).
3. OD RCVR is built in a way so that it can actually handle these "internal" deployments that provide target-side deployment facility.

This is what I have seen/noticed in this process. Overall that seems to be the process. OD Engr'ing can speak for the actual nitty gritty details but at the end of the day it may be irrelevant to know the nitty/gritty details.

I'm still not clear - you said target-side synchronized deployments - I took a quick look in the OD 6.2.1 Admin Guide and found the following on page 186:

Please refer to DD Admin guide page 115 and onwards. Here is a sentence from the very first paragraph on that page:

After receiving the deployed content, the receiver subsequently deploys the content into a supported relational database using JDBC.

HTH

Adam Stoller

Please refer to DD Admin guide page 115 and onwards.

Hmm - well, perhaps my reading (or the writing) of what I quoted before was incorrect and maybe you can license and enable DD on the Receiver.

Ultimately, it's up to vijetha to follow through on this to see if (a) it can be done and (b) if it solves the problem originally presented in this thread.

I'm now a bit more convinced that (a) may be possible, but not yet convinced that (b) will actually resolve the issues at hand - which is: how does one invoke DD once and only once for a complete multiple-definition fan-out transactional deployment in such a way that if DD fails, all the OD processes rollback.

I hope it does work - I'm just skeptical that it will.

vpatel

I do not think you have to "license / enable OD RCVR for DD" per say. At least in my experience I do NOT recall ever having to tinker around with any licensing or configuration at all on the OD RCVR side. As I had explained in the last post, I think OD is engr'ed to handle these "internal" deployments just fine -- in other words DD will work on OD RCVR in this target-side deployment scenario.

As far as whether this will fit "vijetha's" needs or not I am not sure. I have used this mechanism for OD/DD sync'ed deployment ONLY. I have NOT tried it out for fan-out deployments. However, it is clearly documented that fan-out deployments are supported. Here is an excerpt from the doc:

Additionally, target-side database deployments allow you to take advantage of many OpenDeploy features, including the following:
???? Fan-out transactional deployment, which allows synchronization of files and database content.

HTH

Adam Stoller

I do not think you have to "license / enable OD RCVR for DD" per say. At least in my experience I do NOT recall ever having to tinker around with any licensing or configuration at all on the OD RCVR side. As I had explained in the last post, I think OD is engr'ed to handle these "internal" deployments just fine -- in other words DD will work on OD RCVR in this target-side deployment scenario.

As far as whether this will fit "vijetha's" needs or not I am not sure. I have used this mechanism for OD/DD sync'ed deployment ONLY. I have NOT tried it out for fan-out deployments. However, it is clearly documented that fan-out deployments are supported. Here is an excerpt from the doc:

HTH

As we've monopolized this thread of late, I'll add a bit of a response here:

Firenze

Has the original posted question about getting the DD DNR to fail and cause the rollback of the file deployment legs to trigger been answered? The correct response code would need to be set for the DNR to trigger a failure in OpenDeploy. I didn't see that in the postings.

Getting multiple Database deployments to go out in parallel and then rollback may be more challenging. I thought this could be handled in DataDeploy thought so the DD DNR's failure would handle that transaction.

Adam Stoller

Has the original posted question about getting the DD DNR to fail and cause the rollback of the file deployment legs to trigger been answered? The correct response code would need to be set for the DNR to trigger a failure in OpenDeploy. I didn't see that in the postings.

Getting multiple Database deployments to go out in parallel and then rollback may be more challenging. I thought this could be handled in DataDeploy thought so the DD DNR's failure would handle that transaction.

In a simple scenario - one leg of OpenDeploy with one DNR script that invokes DD and check the results to determnie if it should send the response string that will tell OD that the DD process failed - is trivial.
As soon as you add more legs to the OpenDeploy process (e.g.: fanout) the situation becomes more difficult because you do not want the same DD process run for each leg (one DD process might succeed, but the others will fail if there are any new entries to be created - you can only do a CREATE statement once for a given set of data)
Then there's the issue of multiple definitions - which brings up multiple execDeploymentTasks, and you're trying to make sure that the DD process runs after all the OD processes - which you cannot guarantee.

Going back to the original posts though, I see that I jumped to the conclusion that this was a fan-out issue.

If it's not a fan-out, but is a multiple definition issue only - then you might be able to resolve this along the "simple" lines by consolidating the defintions into one - that uses multiple pathSpecification elements. If you can do that, you're back to a single leg, single definition deployment process on which you can add a single DNR script to run DD and check the results.

vijetha Are you still out there? Can you provide more details about your situation?