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

OpenDeploy Error Control

System

What is the most reliable way to determine if a deployment was successful?

The existing logic is calling iwodstart (is there some better way?) and ignoring any results. The first thing I need to know is whether the content was deployed or not - can I check the OS return code and/or the output of the command? What OS return codes indicate success/error? Do I expect the output of the command to include or not include something if there is no error, or do I expect it to include or not include some token in the case of error? Once I know whether or not there was an error, what is the best way to determine the root cause?

Right now I am using Version 5.6.0.1.0 Build 21220 Interwoven 20030618 but I would prefer to avoid reworking this with upgrades and patches.

Find more posts tagged with

Comments

ts_user

You should be able to check the iwodstart return code to check if the deployment was a success or a failure.
Return codes:

0 --- Success
1 --- Failed to start
2 --- Ran and failed
9 --- Completed with errors

You can also have a DNR to email you in case of a failure in deployment. We check the return code to be a 0 else send an email informing of a failure irrespective of the reason. You need to check the log files to know the reason for the failed deployment ( GUI or not).

Thanks.

Migrateduser

Thanks. Counting on the OS return code does not seem reliable though - I just ran iwodstart.bat with some config file that doesn't exist on the command line and errorlevel was set to at least 1, but from within an ExteranlTask running the same command line returned 0. Maybe there is some pattern or rule here, but for now I will assume an error occurred if it returned non-zero or the output includes either 'ERROR' or 'Failed'. Of course this will break under some other conditions. If anyone knows a better way...

I wonder why there are no Perl modules for invoking OpenDeploy. It seems nuts that we are all determining these things and coding around them when ERROR CONTROL SHOULD SHIP WITH THE PRODUCT, at least as a free option. Enterprise-class my...

Migrateduser

It sure would be nice to have more pre-packaged ways of checking the results of a deployment when you run the CLT. The error codes are only half the story. I've run into cases where the CLT returns a non-zero error code but the deployment was successful. The problem is that whenever a deployment returns a non-zero error code, my workflow automatically sends an email to a bunch of people saying their deplyoment failed. Then I have to send another email to everyone saying basically "never mind". It's not very solid and makes us look like idiots. I like the idea of a perl module to handle all the possible error checking. Also making the CLT more robust in general would help - and clearer documentation defining what the specific scenarios cause each error code.

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

Migrateduser

> I've run into cases where the CLT returns a non-zero error code but the deployment was successful

Seems like I've hit this one before too, but I don't remember the specifics. If you remember any details, let me know. Do you know if there's any way to code around this?

Migrateduser

My case happens because one of our remote DNR scripts that gets executed after a deployment takes anywhere from 10 to 30 minutes to execute and evidently the CLT times out and thinks it failed, and returns an error code of 256 (which is I guess really 1). But the DNR is just still churning and eventually finishes and the deployment completes just fine. But by that time my fancy email has gone out to everyone telling them their stuff didn't deploy.

Todd suggested there's a timeout value I can set in my deployment config in OD5.6 SP1 and above, but we're still running OD 5.5.2 so that won't help me until we upgrade.

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

ts_user

> after a deployment takes anywhere from 10 to 30 minutes to execute and evidently the CLT times out and thinks it failed

How about running the DNR script asynchronously so that your deployment returns successfully and not have to wait for your DNR script to complete. The DNR script can then send an email after it completes so that you are notified if the DNR completed successfully or failed. Just a thought, not sure if it would work in your case.

Migrateduser

That would be too much of a pain. First of all, the DNR script is moving the new files from the staging server to production, and the next step of the workflow is a review step for someone to check the files in production, so I don't want to get to that task till all the files are actually in production. And I use Template Based email, so with the DNR script living on the staging server, it can't exactly send out my Template Based email. It would completely change the whole dynamic of my workflow. The point is, it shouldn't matter whether my DNR script takes a friggin' hour to run, the deployment CLT should not report a failure when nothing has failed.

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

Migrateduser

Fyi, OpenDeploy 6.0 ships with a web services-based API. Java client examples are provided. If you want to code in something other than Java, you can generate client bindings from the WSDL.

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Migrateduser

I don't see myself moving away from perl anytime soon with my workflow scripts. We definitely plan on using Java for creating our own UI in place of the TeamSite UI, but until workflow changes drastically away from being so perl-centric, there's no point in recoding the dozens of scripts we currently use in our workflows. I wouldn't even know how to implement a java script from an externaltask. I'm sure it's probably easy enough to do, but I'm not a java developer and the workflow documentation certainly doesn't help.

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

Migrateduser

> ships with a web services-based API.
> If you want to code in something other than Java, you can generate client bindings from the WSDL.

Can you provide a Perl module that wraps the service call with appropriate error control?

I would bet that at least 90% of your customers are still on Perl. In fact it is pretty tricky to write an ExternalTask in Java and most will be on Perl indefinitely.

Migrateduser

My understanding is that it's possible to generate Perl bindings from the WSDL. We didn't have time to investigate that prior to releasing 6.0, but it would seem worthwhile to look at.

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

Migrateduser

Seems like the vendor should provide a proof of concept piece here...

Adam Stoller

This thread seems to have gone off-topic pretty quickly - but with Smitty around, that's normal ;-)

ts_user posted the defined results for exit status from iwodstart - which should work correctly on Unix and on W2K (if memory serves correctly) but not, unfortunately, on WindowsNT. For Windows - it was generally recommended that you try using ODHOME/solutions/perl/iwodstart.ipl rather than ODHOME/bin/iwodstart.bat.

However, as of OD 5.6 SP1 - you could also switch to using iwodcmd start in place of iwodstart and I believe you will get consistant results on all platforms (operative word: believe) and you will generally get better performance since you will not be initiating a new JVM for each deployment.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

NathansDIS

Hi Todd, et al:

Would it be possible to create a feature request for OD 6.x to implement a new state in OpenDeploy DNR tasks that would trap on a failure or a success with errors condition? Something like this:

<dnrDeployment location="source" when="after" state="failureOrCompletedWithErrors">

Thanks,

-Nathan
Washington DIS

Migrateduser

Presumably you're running a non-transactional deployment, which can produce the "completed with errors" result. I've filed a new FR for state="failureOrCompletedWithErrors": 58075

In the meantime, you can probably invoke a DNR on success that parses the manifest for failed files.

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

NathansDIS

Thanks Todd-

If you haven't already done this, please add us to the FR for this. Do you have any example code of a DNR script that runs on success, and searches the manifest for errors and then emails a notification if an error is found? We are just looking for a way to get notified when a deployment fails to send all files to all hosts in a non-transactional deployment. We had so many issues with renaming directories in a transactional deployment that we had to abandon the transactional aspect of the deploy.

Thanks again,

Nathan
Washington State DIS

Migrateduser

Sample scripts for parsing manifest data and sending emails are located under OpenDeployNG\solutions\perl. You should be able to borrow from these to achieve what you need. Or maybe someone has something already done that they can share?...

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com