Capturing Return status of a DAS deployment

cybervimal

All,

I would like to poll the group for a specific problem relating to DAS.

Environment:-

TeamSite 6.7.2 Windows

OpenDeploy 6.2.0


Have configured DAS for database save for the DCRs.
I'm trying to find a reliable and clean way of finding out if a particular DAS deployment for a DCR failed or succeeded.
The scenario is that Iam triggering a DAS by means of submitting a DCR to STAGING (via command line script)

I'm interested failures such as :

(a) Event-subsystem being down , hence Datadeploy itself hasnt triggered.
(b) Any database level failure such as SQL primary key constraint violation, column mapping errors etc.


I tried couple of ways but none of it seems to return a 100% reliable result.

(1) After the submit is executed, I compare the system timestamp (ignoring the microseconds part) with the timestamp in the iwtracker table for that particular branch. If both matches, It means the recent datadeploy is a success, else failure.

This is under the assumption that this is the only deployment that runs at that point of time

This method does not seem to be reliable, as 6 out of 10 times, the database is updated few seconds after the DAS is complete.
Seems like the event subscription posts the timestamp to the database and commits it to DB only after a few seconds and this time interval is not a predictable measure. i.e. the time interval of DAS finishing and the DB actually being updated with the values (in case of a success)


(2) The second way I tried was to tail the DD log and find out the last line, if it is a Failure or success.

I found this also not to be a reliable way as the file tail does not seem to give a proper result (especially this being a running log). I do not want to use any new perl module that is not in the standard perl modules. Hence wrote a custom function ,using file-seek.


I'm sure everyone who has used DAS would have faced this problem.
Would appreciate if anyone who has faced this problem can give their suggestions.

Thanks in advance,

Vimal.

ISCBorisB

DAS is by design an Event driven System with the built-in latency. You have IMO basically two options in that respect:

1. Configure a system with the "High Availability" DAS, add resources as needed, etc. Monitor operability of the critical components
like Event System and DB Engine. Monitor logs to catch operational/procedural/coding issues that cause "normal" DB Level errors.

All that means that you reasonably "trust" your overall design to work and do some online monitoring for failures.

2. To catch critical "real time" problems do not use DAS. Taking your sample, you can modify Submit WF to include direct DD Task(s)
and check OD return code, STDOUT/STDERR and the like

Personally - I try to avoid DAS. It has way too many moving parts and with the resources normally allocated for CMS project an amount
of required "trust" in the System is way above my comfort level. With the reasonable Workflow design it is always possible to do what
you need, when you need it and keep tight control on the operations that may fail