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.
UC4 Automic SP8 / the properties say dialog version 9.0 & build:402-991.
We updated to the Automic version from UC4 just last night.
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.
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.
RECORDS=`wc -l <
if [ $STATUS -eq 0 ]
echo "abc to def Loss Balance
Report: OK ("$RECORDS" total entries)" >>
echo " File Name: "$RPTFILE >>
echo "abc to def Loss Balance
Report: NOT OK ("$RECORDS" total entries)" >>
--- I hope this makes sense... and gives you enough info.
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?
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.
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.