Automate composite workloads according to business policies
IBM Tivoli Workload Scheduler (TWS), the leading software automation tool, provides the backbone for automated workload management and monitoring. TWS offers a single console, real-time alerts, reporting and self-healing capabilities to help manage the workloads that span your enterprise. The Tivoli Workload Automation (TWA) family can help address automation and scheduling issues through
- Visibility - Tivoli Dynamic Workload Console (TDWC) is a central web based console that provides visibility of the enterprise wide scheduling requirements and their current status. This removes the requirement to visit individual systems to determine the status of processing.
- Dependencies- Tivoli Workload Scheduler can schedule processes based upon any combination of the Job, File, Date/Time and/or Resource. It can also schedule processes dynamically based upon events that occur throughout the enterprise.
- Centralised control and management of batch processes across the organisation
- Reduced administration due to more efficient centralised control
- Single global view of workload dependency across multiple platforms and applications
- Improved use of existing resources resulting from better process coordination across different platforms and/or applications
- Lower cost of ownership when working with a single scheduling solution instead of multiple independent schedulers
- Common scheduling functionality across different operating systems and applications
Let us maintain TWS for you
Orb Data’s Managed Services allow you to manage your schedules while we manage TWS for you
This inexpensive service is aimed at customers who need a scheduling solution however don't have the manpower or will to manage the implementation. Using Orb Data's experts to manage and support your TWS implementation we will become part of your team to ensure the software works to the optimum for your business.
When using the individual schedulers providing by the operating system, there is a lack of visibility of the overall batch processing (i.e. a global enterprise view). To verify if each batch process has executed successfully, it is necessary to check each scheduler individually under the Windows Task Scheduler or cron on each individual system. Otherwise, each batch process would need to contain logic to report to a central location - this extra effort takes important and costly development resource away from ensuring that the batch process works successfully and instead concentrates upon developing a central reporting function.
Using the basic scheduling services of the operating system is generally satisfactory when the batch processing is on a single system and requires only a specific start time as a dependency (e.g. 18h00). If other dependencies are required such as:
- The batch process B on system B cannot start until the batch process A on system A has completed successfully. If batch process A completes in an error state, do not execute batch process B.
- The batch process C on system Z must execute only on business work days and cannot start execution until the transfer of file /opt/customer/N12678/incoming/orders has completed successfully
- If batch process D terminates successfully, execute batch process E, otherwise execute batch process R to perform a recovery
- Batch process B cannot start before 18h00, but only if batch process A has already run and completed successfully. If batch process A has not completed before 18h00, hold batch process B until batch process A has completed successfully
- Batch process G can only run on the last working day of the month and must run after the daily batch process F has completed successfully
Looking at the typical dependencies listed above, it quickly becomes difficult to schedule the various batch processes unless the different dependencies are built into the batch processes themselves. This amounts to “reinventing the wheel” as each batch process would need logic to determine if it should execute or not. A far simpler and cost effective solution would be to use a product such as TWS to manage these complex requirements as it is specifically designed with this objective.
The increased number of batch processes requires additional management capability for scheduling automated processes and can also lead to increased complexity of the scheduling and automation requirements. Traditional scheduling requirements are generally static such as priority, start time, resource or file based dependencies, whereas automated business processes require a more dynamic capability. Consequently, there is a need to respond to events occurring throughout an automated process in a more dynamic and timely manner. The TWA products support this capability known as event based or event driven scheduling.
As more business related processes become automated they are ideally suited for background (non-interactive) processing. However, these processes generally require a more dynamic approach to scheduling as they do not usually occur at a pre-defined time or frequency. The TWA products use a rule-based event engine to support these processes, reacting to changes in process status in real time, allowing the processes to be initiated based upon the presence (or absence) of predefined criteria. Interfaces with a number other external products allows TWS to submit and track batch processes on their behalf, for example based upon the availability of a specific application.
TWS now includes the functionality previously only available within the Tivoli Workload Broker product. The broker functionality provides a completely dynamic environment for process execution by using agents that report resource availability to a central broker manager. The broker manager will use this information to dynamically select the system that best matches the resource requirements of the process to be executed.
Combined with the powerful dependency resolution criteria already provided by TWS, the broker capability provides the ability for the process to be executed on any available system that matches the resource requirements in real time. If the “usual” system used to execute the process is unavailable for whatever reason, the broker function will automatically and dynamically execute the process on another available system that satisfies the execution criteria.
The dynamic agent can execute native job definitions in support of Web Services, Microsoft SQL Server, Database, J2EE, File Transfer (FTP,SSH, etc.), Shadow and JCL (mainframe) jobs. TWS provides a pulg-in capability to develop additional interface support if required.
The dynamic agent also supports the concept of pooling, allowing the user to define pools of systems (i.e. agents) that can be grouped together for execution of similar processes. This helps to ensure maximum availability for processing as any available member of the pool can be used to execute the process, thereby removing a single point of failure.
Managing batch processes using operating system or application schedulers can quickly become unmanageable. It may be acceptable to manage 5 to 10 batch processes on a single server, whereas managing 5 to 10 batch process on 5 to 10 (or 100!) servers very quickly becomes a management nightmare.
Change is the single most consistent aspect of IT - things will change and batch processes will not be an exception. Whilst changing 5 to 10 batch processes on a single server may be manageable, changing 5 to 10 batch processes across 5 to 10 (or 100!) servers is both labour intensive and prone to error.
Especially in the current economic climate, companies are looking to reduce costs through more efficient and effective use of existing resources. One area being considered is business processes with a view to making them more automated and less labour intensive. The TWA family of products can assist with the automation of existing business processes, providing the scheduling control and management of the resulting automated process. As more processes become automated this requires a scalable solution to managed the increased number of batch processes.
Centralised management of the enterprise wide scheduling requirements is performed from the web based TDWC console. All that is required is a current browser (e.g. Internet Explorer or Firefox). Scalability is provided for small enterprises consisting of a few servers through to large enterprises using many hundreds of servers. The scheduling capability can be increased (or decreased) as required by adding (or removing) intermediate domain managers within the scheduling infrastructure. This allows you to add additional scheduling capacity as your scheduling and automation requirements grow.