Workload Automation Agents

 View Only

 Applications Manager Predecessors Move to Wrong Component

cathyt's profile image
cathyt posted Apr 13, 2021 11:07 AM

Hi,
I am having an issue with a few of my process flows in Automic V9 Applications Manager.  I have set up a process flow with over 80 steps and use the default predecessor type of the previous step being a success.  At the end of the day yesterday, the process displayed in one column as usual on the components tab with each job showing only one predecessor, this being to the previous job.

The problem I'm having, and have had over the last few years, is that when I open the process to work on it the next day, multiple jobs have changed the predecessors to point to one single job causing me to have to go in and re-define the correct predecessor, and remove the incorrect one. It often turns out to change the predecessors for every second job to the last job I worked on the previous day.  For this reason, and so that I can fix this relatively quickly, I have begun numbering my jobs so that I can put them back in the correct order relatively quickly.  So for example, when I saved my work last night, job # 2 had job #1 as it's pred, and it followed in kind until job 75 had job 74 as its pred.  Now, most of my jobs point to Job 75 as their predecessor and I must go back through and reset them. The only constant seems to be that I have an sftp job set up between each job (RCPTP22, GLBDATA, ​​ROPPCAT, RORBPST, ETC) that sends the output to a specific secure drive where the end users can go to retrieve it, instead of Automic emailing possible PII.  Every time I have had this problem, the incorrect predecessors have been moved from the correct sftp job with the number previous to the working job number to the last sftp job.  So component 3 pred is changed to 75_sftp_output, when it should be going to 2_sftp_output. The problem continues down the line with the banner jobs all showing 75_sftp_output instead of the correctly numbered job.

This is how it displays when the preds are correct:

And this is what happens when they break and all point to a single sftp output. You'll notice job 03 now has 75 as its pred:
And this when not zoomed in:

Can anyone tell me why this is happening and how to prevent it?  Each of the sftp jobs do the same thing, they send the output to the correct secure drive and then delete the sub-variable, so that it can be used again with the proper output from the previous job.

This wastes way too much of my time, and I would love to know if anyone else has had this issue. My version information is below.

Thank you,
Cathy Tumlin
WSCC

Release: v9.3.2_29190_29223 Build: 29223 Fri Mar 20 15:10:47 PDT 2020
VM Memory: 85.0 of 130.7 MB used, 45.7 MB free
Client Java VM: Java(TM) SE Runtime Environment 1.8.0_121
Server Java VM: Java(TM) SE Runtime Environment 1.8.0_191
Workstation: wscc-d3cqnt2 (wscc-d3cqnt2/10.10.220.33)
Remote host: wsc-p-btch-01.tbr.edu (10.128.2.6)
RMI Port: 1099
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.7.0.0.0
Oracle JDBC driver 19.3.0.0.0