I need to fail a job flow if the FTP connection is unsuccessful

[Anon Anon]

What can I do to stop the job / fail it if my FTP does not return the 226 (complete and successful) code. I am NEW to this and it is my very first project to work on.

[Anon Anon]

Hi Brian, Welcome to the Community. 

Which product and version are you using?

 

[Anon Anon]

UC4 Automic SP8 / the properties say dialog version 9.0 & build:402-991.

We updated to the Automic version from UC4 just last night. 

[Pete Wirfs]

 

Are you using the RA FTP agent, or are you issuing your own FTP commands? 

If you are issuing your own FTP commands, then I would consider writing a post-process script to scan the FTP report for the 226 message and modify the job's return code if it can't find it.  This logic could be put inside of an include object so it can be used by many jobs.

If you are using an RA FTP agent job it has built in error checking but the behavioral rules have to be customized for each command in the "command sequence" area.

[Anon Anon]

This is already written... I am just adding the error checking. It is written to issue it's own FTP commands. I am a .NET developer thrown in to learn something new, so this is very new to me. I see where the successful codes are returned in the statistics/ report. But I am not sure where to put logic to read them, or to halt the job. 

Would I create a new job in the workflow after this, or would it be held within?

Here is the Code for the calls... There are 6 blocks basically identical to this (different file names) to update 6 .csv files. 

FILE=abc_to_def_loss_report.csv

RPTFILE=`echo $FILENAME_PREFIX`_$FILE

STATUS=`grep -c 'MISMATCH' $PMTargetFileDir/$FILE`

RECORDS=`wc -l < $PMTargetFileDir/$FILE`

let RECORDS=RECORDS-1

echo $STATUS

if [ $STATUS -eq 0 ]

then

  echo "abc to def Loss Balance Report: OK ("$RECORDS" total entries)" >> $PMTargetFileDir/def_link_body.txt

  echo "        File Name: "$RPTFILE >> $PMTargetFileDir/def_link_body.txt

else

  echo "abc to def Loss Balance Report: NOT OK ("$RECORDS" total entries)" >> $PMTargetFileDir/def_link_body.txt

  echo "        File Name: "$RPTFILE >> $PMTargetFileDir/def_link_body.txt

fi

echo "" >> $PMTargetFileDir/def_link_body.txt

---  I hope this makes sense... and gives you enough info.

[Anon Anon]

It looks like this could be evaluated as a postcondition in the workflow.. just discovered this...  but  I'm not sure which condition would be best to evaluate: return code, check file ftp, check process, or another?

[Pete Wirfs]

In my opinion, this is not a product that one should try to 'learn' via forum discussions.  You really need a local mentor that can look at things with you.  There is just too much to learn.  But I'll try anyway. (I have .net background too, so I sorta know where you are coming from.)

QUESTION: Does your job have a RunTime tab setting specified?  This is typically where you tell the scheduler what return code level is to be considered "OK" vs "NOT OK".  If you do not have one, then Automic will assume that your return code must be zero otherwise it will automatically block the workflow from continuing.

workflow post-condition might be your best solution, or it might not.  This product is very flexible.  Execution order;

 1. workflow pre-condition

 2. job pre-process script

 3. job process script (typically where you run your process)

 4. job post-process script

 5. workflow post-condition

The workflow conditions are limited in what they can do, but they can also do certain things that you can not do with the scripting language.  the three process script phases are more flexible because the scripting language is so rich.  There is a 663 page scripting manual in pdf form (it has lots of screen images) or you can use PF1 to find what you need.

QUESTION: So where is your code stored?  Is it stored in the job process script, or is it in an external file that is invoked from the job process script?

Hopefully you can just add the Automic script command ":EXIT 1" at the right place to set a non-zero return code and trip the RunTime functionality of blocking the workflow.  This will be easier to do if your code is in the job process script and not stored externally.

 

[Anon Anon]

The code is in the job process script, not called.

I will be able to talk to someone here in a couple of days, but I wanted to make a good effort ... or at least get a clue, since I had time while waiting. I have a 1000 page manual I'm looking at... I can't wait to find the 6000 page one!  Thanks.