20
Using IBM Workload Scheduler, you can define different types of dependencies for your workflow, including file dependency, which prevents the execution of a task until the file is created on a particular server.
The file name of the dependency can be defined explicitly or defined using classical IBM Workload Scheduler variables. This means that the file name is statically defined at definition time (using explicitly file name) or at planning/submission time (using classical variables).
In order to introduce more flexibility for file dependency scenarios, IBM Workload Scheduler has introduced the possibility to define them adopting the dynamic variable substitution method already used for dynamic jobs definition. In that case the variable must be preceded by the $ (dollar) sign and enclosed in {} (curly brackets).
If you’re wondering why IBM Workload Scheduler dynamic variable substitution should be used for file dependencies, here are the top three reasons in our opinion:
-
The file name becomes dynamic and it’s automatically resolved at job execution time. This dynamic variable is useful when the file name is unknown a priori and the name can be dependent on run cycle.
For example, you have a predecessor that creates a file with a timestamp in the file name: myFile_103120161820.txt, and you want to define a dependency on that file. Since the name of the file it's not known until it's created, you can use now dynamic variables instead of file name in the file dependency, and when the file is created it's only needed to modify accordingly the variable in the specific variable table. For that reason, the Variable Table modification was also simplified as described below.
-
The new dynamic Variable Table job type gives you the ability to add or modify a variable in a variable table “at runtime”. With this feature you can easily add a sort of collaboration between different Job Streams without adding glue code. Indeed, you can dynamically add and modify the value of a variable in a variable table. So, in our file dependencies example, the file name variable could be changed by another application.
Here a screenshot sample, from IBM Workload Scheduler user interface, of the Variable Table job. The variables’ value is updated “at runtime” using the dynamic job properties values exported by previous Job in the same Job Stream, once these variables are updated in the variable table they can be accessed by any other Job Stream.
-
Using the dynamic variables, you can extend the name of your file dependencies. In this release, all the variables into the variable tables have been extended: the variable value changed from 72 to 1024 characters, in this way your file name dependency could reach a longer path. Also the variable name was extended from 16 to 64 characters, so you can easily use a variable mapping.
Depending on the specific scenario, obviously the advantages of new file dependencies could be different. For that reason, we strongly suggest you to participate to IBM Workload Scheduler "Beta program" to learn about and try all of the new IBM Workload Scheduler features, and to stay tuned for latest news.
If you want to talk more about new file dependencies and IBM Workload Scheduler in general, leave a comment below.
See you next time!
About the authors:
Eliana Cerasaro has 10 years of experience working in design and implementation for IBM Workload Automation area. She is a Senior Software Engineer at the HCL Development HUB in Rome, Italy.
Luigi Presti is currently an Advisory Software Engineer and is working as a developer for the IBM Workload Automation for distributed platforms product (on-premise & SaaS) at the HCL Development HUB in Rome, Italy. Luigi has been working since 2006 as a Level 3 Service Specialist for the Tivoli Workload Scheduler product, acquiring a deep knowledge of customers' needs in that area. He is interested in everything that is strongly related to supporting customers in their technological challenges. He has a background in computer science technologies, in particular in the design and development of parallel and distributed software architecture for high-performance computing. He has written several publications and was a member of the Program Committee for Academic International Conferences about Software Architecture.
Riccardo Rossi joined IBM in 1998 with the goal to automate the manual test suite for the IBM License Use Management product. During these years Riccardo worked for many IBM products of the IBM Rome Laboratory covering different positions in the development life cycle, level 3 service support, test automation leader, product developer and designer, acquiring a deep knowledge in the development cycle. Riccardo is currently an Advisory Software Engineer working as scrum master and developer for the IBM Workload Automation for distributed platforms product (on-premise & SaaS) at the HCL Development HUB in Rome, Italy.
