Count Validatation and updation of Job even if it fails

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
nibumathewbabu
Premium Member
Premium Member
Posts: 22
Joined: Thu Jul 05, 2012 5:09 am
Location: Chennai

Count Validatation and updation of Job even if it fails

Post by nibumathewbabu »

Hi All,
This is my requriement

I need to compare file source count with target table count and write the both counts in to an audit table with status Success(If count are equal) or Fail on the other case and I also need to fail the job if count mismatch is there.

The issue I face is,If we try to achieve above with a lookup stage and fail the job if count mismatches, the counts wont be written in target table as the job is aborting.

Kindly suggest a way out
Thanks
Nibu Mathew Babu
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

Can you not perform the check, write the results to the audit table and only then abort the job if required?

And there was no reason to post this twice, I removed the duplicate post.
-craig

"You can never have too many knives" -- Logan Nine Fingers
PaulVL
Premium Member
Premium Member
Posts: 1315
Joined: Fri Dec 17, 2010 4:36 pm

Post by PaulVL »

External source stage with a filter: wc -l /path/filename.txt output to column source_count
Connector stage SQL statement: select count(*) from table output to column table_count

now just use a transformer on that stuff and redirect output to success or failure if condition branch.
nibumathewbabu
Premium Member
Premium Member
Posts: 22
Joined: Thu Jul 05, 2012 5:09 am
Location: Chennai

Post by nibumathewbabu »

Thank you for the response.But I need to write the table count to audit table and if count mismatches i need to fail the job also that is the req
Thanks
Nibu Mathew Babu
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

Okay then, how about chiming in on my response?
-craig

"You can never have too many knives" -- Logan Nine Fingers
nibumathewbabu
Premium Member
Premium Member
Posts: 22
Joined: Thu Jul 05, 2012 5:09 am
Location: Chennai

Post by nibumathewbabu »

Thank you for the response. I am fine with first part you suggested.

"and only then abort the job if required"

Could you please specify how to implement above step?
Thanks
Nibu Mathew Babu
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

Well, here's what I was thinking.

First step would be to record the results in your audit table, so make sure when that happens that your transaction size is set to 1 for the record is not only inserted but also committed so it doesn't rollback when you fail the job. I'm thinking it could be as simple as two output links from a transformer, first one to the audit table insert and then a second one (enforced by link ordering) that is a "reject" link set to "Abort after rows=1". You shouldn't need a constraint on the audit link as it should always trigger the insert but your reject constrain should only trigger when your counts don't match.
-craig

"You can never have too many knives" -- Logan Nine Fingers
nibumathewbabu
Premium Member
Premium Member
Posts: 22
Joined: Thu Jul 05, 2012 5:09 am
Location: Chennai

Post by nibumathewbabu »

Thanks Craig.
As you suggested I have two links from transformer


Link1: Constraint source count=target count then to target table with update audit table with target count and status in table is success

Target DB stage Read committed,Record Count and Array size=1


Link 2

Constraint source count <> target count then to target table with update audit table with target count and abort after 1 row and status in table is failed


Target DB stage Read committed,Record Count and Array size=1

Please guide whether the above idea is what you had meant
Thanks
Nibu Mathew Babu
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

Not quite.

The suggestion was to use the first link to update the audit table regardless of success or failure. Meaning always do it, record the result and commit the transaction, match or mismatch.

Then all the second link does is abort the job when the counts don't match. It doesn't even need to have a 'real' target at the end, perhaps use a flat file writing to /dev/null or something of that nature.
-craig

"You can never have too many knives" -- Logan Nine Fingers
nibumathewbabu
Premium Member
Premium Member
Posts: 22
Joined: Thu Jul 05, 2012 5:09 am
Location: Chennai

Post by nibumathewbabu »

Thanks, I will try and let you know
Thanks
Nibu Mathew Babu
Post Reply