Re-request jobs from history?

[Reed Byers]

As Oregon State University migrates from Application Manager to AWA [12.3.0+build.1563349870418], one feature that we use frequently in AM, seems to be missing.

Our customers frequently look up an old job they ran several months ago, and re-request the job, using the same parameters as before.  They are then given the chance to tweak the parameters, and then submit the job.

AWA has a "restart" feature that is similar, but it reruns the job using the old runid.  It even stores the newly changed parameters under the old runid!

This appears to be intended to restart a recent job that ran incorrectly.  "Forget that run; do it THIS way instead."

But we want to keep our history, and just allow the user to run the job anew, without having to remember all the parameters they used last time.

Is there a "re-request" feature we're just not finding?  If not, is this something Broadcom would consider adding?

(Alternatively, a user-driven "saved parameter sets" option would work nearly as well.)

Thanks again...

------------------------------
Reed Byers
Programmer/Analyst
Oregon State University
------------------------------

[Tim Quakulinsky]

Hello, Reed,

Unfortunately, as a long-time Automic user, I can't understand your statements.

Every execution, even a restart, gets a unique RunID under which all information is stored in the DB (primary key). For reasons of traceability, information from older runs must not be overwritten.

Where do you see the old RunID? In the Automic script? If so, note the difference between SYS_ACT_ME_NR and SYS_ACT_RESTART_ME_NR.

Greetings from Germany
Tim

------------------------------
Automation Evangelist
Fiducia & GAD IT AG
---
Mitglied des deutschsprachigen Automic-Anwendervereins FOKUS e.V.
Member of the German speaking Automic user association FOKUS e.V.
------------------------------

[Reed Byers]

Yes, there IS a new RUNID.  Unfortunately, the restart "pollutes" the original history.

Let us demonstrate.

I have three objects:
PRPT.PROMPT_TEST  -- takes three text parameters.
SCRI.PROMPT_TEST  -- does a :PRINT on the three parameters.
JOBP.PROMPT_TEST  -- takes the prompt set and runs the script.

Here is the workflow:

STEP 1: Run JOBP.PROMPT_TEST.  Here are my initial parameters:

STEP 2: Verify it ran:

STEP 3: Restart the workflow.  (Note that "restart" is under the "modify" menu!)

STEP 4: Enter the new parameters:

Step 5: Verify it ran:

STEP 6: Restart the FIRST run. (Please note I am restarting the EARLIER run!):

STEP 7: Note the *WRONG* parameters!

Extra Credit: Hit "Cancel Task" at this point, and then restart the ORIGINAL job *AGAIN*.  Now the prompts are blank!

Either this is an interface bug (restart shows the most recent run, rather than run you intend to restart), or we indeed *ARE* overwriting information from previous runs!

This is going to be a big problem for our users when we go live with AWA in a year...

Thanks in advance for any help/advice you can give!

------------------------------
Reed Byers
Programmer/Analyst
Oregon State University
------------------------------

[Pete Wirfs]

@Reed Byers   First of all, I'm an Oregon State University graduate and am currently working at SAIF Corporation in Salem Oregon, just a short hop away.  So "Hi".

We migrated from AM to AE in 2012.  We budgeted one year for the migration, but it took us an entire two years, running both systems in parallel so we could move chunks of our applications at a time. ​ Our best practices evolved over time as we learned more about the product.   We are currently on AE 11.2, and are planning for our upgrade to 12.3.

So with our 11.2, we discovered a different issue with the "restart" feature.   Promptset date objects want to be populated in yyyy-mm-dd format, and can then be asked to deliver the value in the output format of your choice.   For restart however, the product seems to store are recover the value in output format, which sometimes gives an error, and other times gives you the wrong value.  (We've had some production restarts with wrong date values that were not pretty.)  Our workaround is we manually validate/correct all date parameters upon restart.  (non-date fields seem to always restore properly.)

The scenario you have laid out is disturbing though, in that now we may no longer be able to trust non-date fields to be restored properly either.   Strongly suggest you educate someone at the product support desk about this, and see where it leads.


------------------------------
Pete
------------------------------

[Carsten Schmitz]

I don't know Application Manager​, but I believe this is an issue with how Automic handles things vs. other software. In AE you create job objects and then run one or more instances of that job object. Each instance gets it's unique RunID.

The "restart" function is, as you said, to restart a job in the same way it was run the last time. In practice, you mostly use it for aborted jobs, e.g. a job expects a file, file is not there, job fails. You put the file in place and restart the job. You can restart jobs that were ended on failure, but also those that ended OK (though the later probably isn't used that much), but both of this only within those constraints.

If you want a flexible job object that can be run repeatedly with different parameters, you'd have to parameterize the job. The prime way of doing so is Prompt Sets, an Automic facility allowing users to fill runtime parameters directly in the interface. Works a bit like a forms editor in other software.

You can also parameterize a job from Automic variables in a multitude of ways (but then those then obviously also need to be filled with the desired values before runtime). We use, for instance, variables to have one job process files for multiple countries. The job instance is triggered from script (ACTIVATE_UC_OBJECT) and gets variables passed down to it, and operates on, say, "datafile_&country#_.txt". But this, also, has to be constructed ahead of time with the desired flexibility in mind.

Hth,

[Gary Chismar]

Greetings from Florida State University!

Question: Are these generally the SAME jobs that get requested?  I.E., the same X jobs get requested to run again and again?  If so, you could design a prompt interface for them to use; providing they have access to Automic and are comfortable using it.  Another way we might do that here at FSU would be to design a run control page (for us that would be PeopleSoft mainly) and have them enter the parameters and kick that off.  The api to Automic would kick off a Workflow that would use a SQLsec variable to pull the information from the transaction database and populate the variables to be used by Automic.

I am currently writing a program utilizing PS and Automic whereby we are going to set up all of our file transfers in PS and have Automic go through them, populate all the needed variables and then execute the file transfer.  This way any file transfers can be modified in the future solely through PS and all we have to do on Automic is set up a simple WF that executes based on the Workflow name.

Although different in nature, the concept is the same.  Utilize their system to supply the information to Automic.  This gives them the control they desire and does not require much on the Automic back end to execute.

Good Luck,
Cheers,
Gary Chismar