Chapter 8. Managing Jobs

We have spent a lot of time looking at how to build integration jobs using the Studio and some of the different components available to developers for achieving specific tasks. However, a key part of the development process focuses not on the job functionality itself, but on managing the code that is produced by a development project.

In this chapter, we will learn how to manage our job code using the Studio. Specifically, we will look at the following topics:

• Code versioning and how we can use the Studio to manage iterations of the same job

• Exporting and importing jobs from the Studio for collaboration purposes or to back up

• Exporting jobs for standalone execution

• Scheduling jobs for automated execution

Job versions

Mostly software development is an iterative process. Within a project, developers will iterate through a develop and test cycle until the software is ready to be put into production use. We can also think of an iterative process across projects; release 1 is deployed and is used for a period of time, but some enhancements or amendments are needed, so another project is undertaken and, at the end of this, release 2 is deployed into the wild. This process may go on for many years!

In order to support these iterative processes, the software is versioned to keep track of the code and components that constitute a given release. While the Studio does not contain a full-featured version control system, it does have some features which allow developers to manage software versions.

As we have been developing jobs in the previous chapters, you may have noticed that the Studio adds a version number to the end of the job name that we define. You can see this in the Repository view of jobs...

Exporting and importing jobs

The Studio offers a number of different ways to export and import the jobs you create and each approach has a different purpose behind it. In this section we will look at the different methods of importing and exporting jobs and also look at why you might choose one method over another.

Exporting jobs

As we have seen in the section about job versions, the Studio creates file artifacts when you create a job design and stores these on your local computer's filesystem. When you run a job within the Studio, the artifacts, which represent the job configuration, are compiled into Java code before being executed. This development setup and process may be sufficient for some readers, particularly where there is only one developer creating jobs and/or the jobs can be run manually from the studio tool.

When this is not the case, it is useful to be able to export jobs from the Studio tool for two primary reasons:

1. You want to collaborate with other developers and need some...

Scheduling jobs

Once a job has been developed and tested, it can be deployed into production use. Most integration jobs tend to run on some sort of schedule-every day, every hour, every Monday at 9 a.m., and so on.

The Studio does not offer a built-in scheduling tool, but through the job export options we can package up all of the code required to run a job outside of the Studio. As noted previously, this package includes a shell script to execute the job under either Windows or Linux/Unix. The shell scripts can be scheduled using your operating system's native tools, Windows Task Scheduler or, on Linux, Cron, or there are many scheduling tools, both open source and proprietary, that can be used to schedule the shell scripts.

Summary

Managing jobs is not nearly as exciting or rewarding as building jobs, but understanding the processes around version control, exporting and importing jobs from the Studio, job execution, and scheduling will be critical to all serious users and developers. Building the disciplines of version control into your development process will improve organization and quality and will allow developers to collaborate or handover integration jobs with minimum fuss. Readers who are new to formal source control processes are encouraged to read further on this subject and to use the tools built into the Studio, versioning, exporting, and importing, to make their development processes as robust as possible.

In the next chapter, we will learn how we can make integration jobs flexible by utilizing global variables built into the Studio environment. We'll also look at context variables, which allow us to run the same job with a different context; for example, executed once with variables that relate...