Automic Workload Automation

Is anyone using PowerShell forInterpreter jobs on Windows? We are experimenting with this, but have not found a completely workable configuration. The sticking point right now is error & return code handling.

The TRAILER.WINDOWS JOBI (include) in client 0 has a bunch of commands that are specific to Windows jobs of type BAT. These include commands to run the job messenger daemon. E.g.,

:INC TRAILER.WINDOWS.USER.END ,nofound=ignore
:IF &UC_WIN_TYP = "BAT"
&UC_JOBMD JNR=&UC_REALNR MNR=&UC_MANDANT PNR=&UC_IP_PORT IPA=&UC_IP_ADR TYP=E RET=00000000 TXT="        Job ended"
:DATA @set retcodemsg=%errorlevel%
:DATA @set retcode=0
GOTO JOBENDE
...

My understanding is that these job messenger commands are important for sending information about the status of the job back to the agent and the Automation Engine. There are other similar :IF clauses later in the same JOBI, and in HEADER.WINDOWS too (and this header JOBI is incidentally where several important JDM script variables are set). The default JOBI objects for Windows jobs do not include equivalent commands for PowerShell, or indeed for any jobs of type Interpreter. I gather that this is part of the problem.

I began working on a solution based on inserting similar commands in TRAILER.WINDOWS.USER.END

:IF &ATT_WIN_TYP = "EXTCOMPROC"
! Return code handling for PowerShell systems
: PRINT "*** Including PowerShell-specific instructions from TRAILER.WINDOWS.USER.END ***"
! insert return code handling and JMD commands here

Before I spend too much time on this, I thought I would ask the experts. Has anyone devised a good way to use PowerShell for interpreter jobs?

Michael,

Have you set up a windows agent to act as a powershell interpreter?  The ini file for a WINDOWS agent needs to be configured to act as a powershell interpreter.  it will require a windows agent license, 

SEE EXAMPLE ini file below

start the agent and  create a windows job, clicking on interpreter in the WINDOWS tab.  

use  your powershell scripts (point to them in the process tab, or write the powershell code in the process tab)

here is an example..

Michael,

Have you set up a windows agent to act as a powershell interpreter?
...

ECPEXE=C:\windows\system32\windowspowershell\v1.0\powershell.exe

ECPEXT=PS1

here is a simple get-executionpolicy script that writes the output to a file ( this uses both uc4 variables and powershell variables)  this is placed in the process tab of your new job

$date = (get-date).dayofyear

get-executionpolicy | out-file "c:\temp\&$AGENT#\$date.log"

  write-host "* * * * * * * * * *"

  write-host  ("   Return Code: $? " -f $LastExitCode)

  write-host "* * * * * * * * * *"

  exit $LastExitCode

it writes the return code to the job's report and the output to a file in c:\Temp\PowerShell\40.log

you can use output filters to check for errors.

Thanks. That’s an interesting approach. I assumed there was a more straightforward way, but perhaps not.

My initial approach was to find a solution that did not require the user to register output files, configure filters, or add steps to the Post-Process tab. This is why I thought of putting special PowerShell handling steps directly into the USER HEADER and TRAILER includes.

Obviously though, exit codes in PowerShell aremore complicatedthan the simple integer exit codes or error levels of shell or batch scripts. It might not be possible to reduce this complexity without risking losing information. I suppose we could enforce conventions on PowerShell developers, so that a simplified approach would work; however, I generally don’t like imposing arbitrary and restrictive standards on our developers.

Perhaps a more general approach based on the oneMark Blackmerproposed above would be wise.

A general solution would ideally catch all exceptions from the PowerShell job (both terminating and non-terminating exceptions), and store as much information about these exceptions as possible. It should also capture the return codes of any normal Windows programs run from the script. All this information should be stored in a form that is easily accessible to UC4 — perhaps a registered output file. This information could then be acted upon by UC4, to set the status of the job or perform other actions.

In a comment on a post on the unofficialAutomic blog, Joachim (‘joz’) suggests using the USER HEADER and TRAILER job includes to wrap the whole job in a try/catch block.

The login joz in this blog is mine.

I wrote in german a short description for me (see pdf attached) how to use powershell in UC4 as an alternate commandshell with seamless error handling. 

Hello Joachim,

Your description looks promising; I looked into your PDF and there is one part I do not understand. Where are the WINDOWS.TRAILER.USER.* objects included in the actual job? Is the START included Pre-Process and the END and ABEND in Post-Process? 

Jeroen

I believe the header is inserted at the top of the job script, but is still part of the job and not the Pre-Process. Similarly, I believe the trailer is added to the end of the job script, but is a part of the job, not the Post-Process. Look at the HEADER and TRAILER includes in client 0 to see how these user JOBIs are included. Enable extended reports (in the Header tab of a job) to see additional output from your job, including aJCLtab that shows the generated script, and aScript tab that shows some of the behind-the-scenes activities that the Automation Engine performs during activation & generation.

Joachimor Automic team, please correct me if I’m mistaken.

Thanks! 

See also the section of theInside UC4 Guidethat describes the phases of object execution. In the section entitledPhase 2: Generation(webhelpe/Content/ucacni.htm), there is a description of where the header and trailer come into play:

1. AgentGroup resolution
   The relevant Agent is selected for tasks that are processed in an AgentGroup. Subsequent changes are possible in the Process tab.
2. Object variables
   The object variables of the task and its superordinate task are provided.
3. Pre-Process
   Jobs: Pre-Process tab contents are processed.
4. Attribute dialog
   The Attribute dialog is only displayed if the task is activated manually and NOT generated at runtime.
5. Header
   Jobs: Header Include and related User Includes are processed.
6. Process
   Process tab contents are processed.
7. Trailer
   Jobs: Trailer Include and related User Includes are processed.
8. JCL generation
   Jobs: JCL generation is possible after UC4 script processing. JCL modifications are possible before the job starts on the destination computer.
   

The Post-Process is handled much later, duringPhase 4: Completion(webhelpe/Content/ucacnk.htm).