Automic Workload Automation

In several earlier discussions, I laid out some of the problems and challenges related to terminology used in Automic’s products and documentation.

• Consistent, clear, unambiguous terminology

• API naming consistency

• Objects & tasks (This discussion thread is missing, and was apparently not migrated from community.automic.com)
  

I later combined these observations and recommendations into a single enhancement request:

Clear, consistent, unambiguous terminology in products and documentation

Automic product management deemed that the problem would be too costly to solve in terms of time and manpower.

Despite this apparent setback, the topic does appear to be one that the company takes seriously. Today I learned that UC_TERM and UC_TERMD tables in the AE database contain definitions of terms (in English, French, and German), along with descriptions of their approved use in the product and documentation.

select TERM_ID, TERMD_ARTICLE, TERMD_TERM, TERMD_DEFINITION, TERM_NOTES,
TERM_SHORTNAME, TERM_VERSION, TERMD_MODUSER, TERMD_MODDATE
from UC_TERM left join UC_TERMD
on UC_TERM.TERM_ID = UC_TERMD.TERMD_ID
where TERMD_LANG = 'E'
and TERM_DEPRECATED = 0
order by TERM_ID asc

The modification dates indicate that not much has been changed in the past couple of years. This could be because of the aforementioned reluctance to commit resources to make the terminology more consistent; or it could be simply because there have been relatively few terminology changes in the product in recent years.

What is the difference between an ACTIVE and an ACTIVATED task?

1. ‘variable’ and related terms
   
2. ‘run number’ and related terms
   
3. ‘active’ and related terms

1. ‘object variable’, ‘variable object’, etc.

• Avariable objectis a separate      type of object (short name VARA) that stores static tabular data or serves      as a dynamic reference to an external data source.
• Anobject variableis a variable      defined in the Variables & Prompts tab of a UC4 object.
• Ascript variableon the other      hand is a variable defined in the Pre Process, Process, or Post Process      tab of an executable object.
• The termvalueis often used to refer to object or script variables set via the:READcommand or aprompt set.
  

The termsobject variable andvariable object are too easily confused with each other. Moreover, the use of these terms is not always consistent. Lastly, the technical distinction between an object variable and a script variable is not really clear. E.g., it’s possible to promote a script variable to an object variable using :PSET. Also, particularly in the context of prompt sets, the termsvariable andvalueare often used interchangeably even though they appear to be functionally equivalent.

2. ‘Run ID’, ‘Run number’, ‘Running number’, etc.

• A task’srun IDis the eight-digit      decimal integer identifier of an instance of an executable UC4 object,      unique across the UC4 client.
• The termsrun numberandrunning      numberare also used to refer to this unique eight-digit identifier      many times in the documentation and user interface.
• In the context of the MODIFY_TASK scripting      command (and similar commands), the termrunning numberis used to      refer to the small (usually 1-3 digit) integer identifier that uniquely      identifies each task in a workflow. The number corresponds to the order in      which the task was added to the workflow.

My instinct is to think of the long integers assigned dynamically to tasks by the Automation Engine asIDs, because they are unique, and they are not chosen by the user. Oh the other hand, the small integers that indicate the order in which a task was added to a workflow seem more likenumbersto me, perhaps because of their ordinal nature. So perhaps it would make sense to refer to the former exclusively asrun IDsand to call the latter simply task numbers.

3. ‘Active’, ‘inactive’, etc.

• In the context of theACTIVATE_UC_OBJECT      scripting command (and related commands), the termactivatemeansexecute,      orsubmit for execution. When one uses this scripting command, it      is equivalent to clicking theExecutebutton in the User Interface.      This meaning of the termactivateprobably refers toactivation,      the first of the four stages of object execution (activation,      generation, processing, and completion).
• In the context of theEarliest tab of theTask      Properties window, the termsactive andinactiverelated to      whether a taskenabled for execution.If theActiveattribute is set to NO, the task will still be a part of the workflow, but      it will not be assigned a run ID, and will not be executed. Instead, it will be skipped and its state will be      set to ENDED_INACTIVE.
• In the context of theMODIFY_TASK scripting      command (and related commands), the termactivehas a similar      meaning to that in the previous example. However, the two meanings are not      interchangeable becauseMODIFY_TASK does not change the state of theActivecheckbox in a task’s properties. In fact, it cannot change the state of      tasks whoseActivecheck box is not checked.MODIFY_TASK alters      only whether a particular task instance within a particular run of a      workflow is enabled for execution.
• In the Attributes tab of a      workflow or job object, and in the Activity list, the terms activeanddeactivaterefer to whether detailed information about a task’s execution is retained and displayed in the Activity list.
• In the Activity list, the task statusActivemeanscurrently running.
• In the output from theAbstractTask.getStatus() method,state_inactiverefers to a whole category of statuses for tasks that are not running but that may still be in the Activity list.
• In the Details for a task, the wordsExpress Deactivatedappear if theExpress option is disabled.

Consider the following example. Imagine that a colleague asks you “Is task ABC active?”

Do you know what she means by her question? Because of the ambiguous use of the termactive within the product and its documentation, she could conceivably be asking one of four (or five) different questions:

1. “Has task ABC  beenexecuted?” (e.g, usingUC_ACTIVATE_OBJECT)
   1a. Alternately, “Has task ABC   passed theactivationstage of object      execution?”
2. “Is task ABC markedactivein the Task Properties within its parent      workflow?”
3. “Has task ABC   been changed to activeusing theMODIFY_TASK command?”
4. “Does task ABC   still appear in the Activity window, or has it beendeactivated?”
5. “Does the task ABC have the task statusActive?” (Is it currently running?)
   

This is just one example. You can surely imagine other similar situations related to variables or run numbers.

Unambiguous terminology greatly simplifies conveying information about product features. This applies not only to the product documentation, but also to all other communication related to the product, including support incidents, emails between colleagues, product training, and so on.

At some point, Automic should make a comprehensive review of its products, and come up with a clear, concise, and unambiguous set of terms, adopting new names where appropriate, to better distinguish between distinct elements and concepts.The product and the documentation should then be thoroughly reviewed to ensure consistent use of these terms throughout, and to eliminate instances of ambiguous or inconsistent terminology. When terminology choices have been made, every effort should be undertaken to ensure consistency.