Job Name and Step Number in DI Studio
The SAS log for a DI Studio job includes, at the start of each step, a comment block giving the Name and Description of the step, as entered by the programmer; however, when a step produces a great deal of log output, locating the most recent such comment block before a message can be a chore. A message that included the step number would be more convenient.
Knowing the job name can be useful when, for example, writing post-processing code to send an email when a job has failed. Such emails are considerably more useful if they can say which job it is that has the problem.
There are automatic macro variables &JOBID and &TRANSFORMID that identify the job and step, but these are metadata IDs (or URIs - "Universal Resource Identifiers"), and not immediately useful. However, a little metadata programming can derive the job name and the step number from them.
The jobname is not too hard to get. Here macro variable MJOBID contains the full URI for the job. This is created by prefixing the automatic macro variable &JOBID with the string "omsobj:Job\". "Job" here is the type of metadata object we are dealing with.
The data step then uses the METADATA_GETATTR function to get the value of the "Name" attribute of this object, and store it as NAMETXT. This is the value we want; it is written to a macro variable JOBNAME.
Getting the step number is a little more interesting.
Automatic macro variable &TRANSFORMID identifies a metadata object of type "TransformationStep", whose URI is constructed in macro variable MSTEPID. Its "Name" attribute is the name of the step, which we extract using the same technique as was used above for the job name. The object has another attribute called "Desc", which could be extracted in the same way (not show here), and corresponds to the step's "Description", as entered by the programmer.
Metadata objects of different types are linked together by "associations". Information about associations can be obtained using the function METADATA_GETNASN, which works in much the same way as METADATA_GETATTR. A little confusingly, the two linked objects know their mutual association by different names. In the case which is relevant here, a "TransformationStep" object has an association called "ReferencedObjects" which links it to an object of type "CustomAssociation". The name of this object is "ControlOrder". This object is linked back to "TransformationStep" objects - one for each step in the job -“ by an association called "AssociatedObjects".
What the code does is to find the CustomAssociation object for the job, check that it is called "ControlOrder", establish how many TransformationSteps it is linked to, and then look at the URIs of each of these in turn until it finds the one that matches the URI we started with. The value of the loop counter at that point will be the step number. (In principle, the TransformationStep object could be linked to more than one CustomAssociation object, and we ought to loop around until we find the "ControlOrder" one.)
An important point to note is that this code will not work while the job concerned is checked out. Checking the job out does interesting and temporary things to its metadata. Have faith that this code should work properly once the job has been checked back in. However, another important point is that it was developed under SAS 9.4. Metadata structures are liable to change between major SAS releases, and they have certainly done so in the area of DI Studio jobs and steps. This code cannot therefore be guaranteed to work under earlier versions of SAS.