- No longer limited to jobs in the particular AE system in which this workflow is run. If you set up connection objects for each of the AE systems’ databases, you can run this workflow in any AE system, and it can pull the necessary info from another system if necessary.
- No longer dependent on SQL VARAs. Instead, the workflow now uses the approach I described earlier today for creating anEXEC VARA wrapper around an SQL job.
- A greatly simplified SQL query eliminates the costly AH subquery and, and simply looks up job details based on the run ID returned by converting the base-26 alphanumeric job ID to the decimal equivalent using
ALPHA2RUNNR
.
- Update UC0.MAL.TOOLS.LJDFLF.UC4_SYSTEMS.VARA_STATIC so that it contains a list of your AE systems.
- Update
the pre-process of both SQL jobs so that they set
the connection object name appropriately for your
environment.
- Make sure that the referenced connection
object(s) exist and work correctly. These connection objects should be
able to read (SELECT) from your respective AE system(s)’ DB(s). There should be one connection object for each AE system you defined in the static VARA.
Update 2017.08.26: I updated the workflow to use a greatly simplified SQL query.
In some cases, it’s actually beneficial or necessary to use a VARA object for this sort of thing. This use case is not one of these cases though! :smile:
Update 2017.08.26: I updated the workflow to use a greatly simplified SQL query.