The next blog in this series was intended to discuss automating the pulling of files using built-in TWS functionality. However, when starting to write the article I realised that to do so involves using some of the new advanced job types. The advanced job types will only execute on dynamic agents or POOL type workstations and so before discussing these advanced job types I thought it may be useful to have a small diversion to review dynamic agents and POOL workstations.

I was extremely sceptical when I first read about dynamic agent support and the ability of jobs to “follow the application” and execute wherever was “deemed” best. Most of the customers that I work with are not yet working actively with public/private clouds based applications that move dynamically from system to system or expand automatically to meet increased demand. So what use would these dynamic agents and POOL workstations mean to my customers? Very little from what I could see as these are probably functions that the large multi-national enterprises are looking for.

I am the first to admit that my initial assumptions could not be further from the truth. Like the majority of my customers I thought that as I only have one instance of Application X the job has to run on that instance and therefore could see no real benefit in dynamic agents and POOL workstations.

The single major benefit that dynamic agents and POOL workstations bring is the removal of the single point of failure (SPOF) that is the Fault Tolerant Agent (FTA) or eXtended Agent (XA). Like most customers using TWS for business critical processing, any failure of an FTA or XA can have a significant impact on the ability of business to process critical workloads. TWS has always had the ability to provide backup capability for the MDM and DM components, but no built in support for backup of the FTA or XA. This limitation was usually addressed by either hosting the FTA/XA within a clustered solution or involved some degree of “on the fly” reconfiguration to host the XA elsewhere. Other customers host the XA on the MDM or DM as they provide the ability to failover to a backup MDM or DM. However, none of these options resolve the limitation that the job executes on a specific workstation and if that workstation is unavailable for whatever reason, the job will not execute.

With the introduction of dynamic agents and, more specifically, the POOL workstations, the SPOF between a batch job and the TWS agent (FTA/XA) used to execute can be removed completely. Instead jobs can be executed against a POOL workstation where TWS will automatically execute the job of an available (dynamic) agent that best meets the workload requirements – it all happens automatically without any need to fail over procedures or on the fly reconfigurations.

The diagram below provides a simple TWS configuration that uses a POOL workstation to execute batch workloads. Instead of jobs being defined to execute against a specific FTA or XA, all jobs execute against a POOL workstation (in the centre of the diagram) named BATCH_PROD. When the job is ready to execute TWS will check the status of the available agents defined as members of the BATCH_PROD pool and, in the absence of any other criteria, balance the execution of jobs across the available agents.

For example, in the diagram below the first job would execute on the AGENT1 system, the next job on the AGENT2 system and so on.

If a planned or unplanned outage occurs that takes AGENT1 out of service, TWS will automatically route any workloads to be executed through the remaining available agent AGENT2. When AGENT1 becomes available once again, TWS will automatically start balancing the workloads once again.

The workstation POOL can contain any number of dynamic agents, so if you need to process a greater number of concurrent workloads, adding additional agents to the POOL is a simple way to increase the throughput.

Note when using advanced job types it is critical that the TWS database is available 24/7 as these jobs are submitted from the Dynamic Workload Broker (DWB) at the time they are scheduled to run.

Before your TWS jobs can fully exploit the use of POOL workstations as described in the example above, they will need to be converted to an advanced job type. For some existing job types this conversion is relatively straight forward, but for others a little more work may be required.

For example, jobs that execute against SAP have historically been defined to execute against an XA workstation. TWS uses the TWS for Applications supplied method r3batch to communicate with the target SAP system. The r3batch method connects to the target SAP system using the Remote Function Call (RFC) interface using configuration options from the associated r3options file. The XA workstation name determines the r3options file to be used for connection to SAP.

When a SAP job executes using a POOL workstation, the advanced job type of “xajob” includes a reference to the r3options file to be used to access the target SAP system. As the job can execute on any agent defined as a member of the POOL, the r3options file must be available on every agent within the POOL.

For the more traditional jobs that execute operating system programs or scripts, the Remote Command advanced job type can be used. For this job type, TWS uses SSH or SMB to remotely login to the target Windows/UNIX/Linux system, execute the script or program and return the results to TWS.

The major advantages of using these advanced job types include

• Execution through POOL workstations provides built-in HA and/or DR capability for the workloads by dynamically executing them on the available dynamic agents
• Potential to reduce the TWS licensing requirements by consolidating the agents into POOLs
• Easily create “custom” methods to be executed as advanced xajob types

Pools and Dynamic Pools

TWS supports two different types of pools – these are confusingly names pools and dynamic pools. The pool definition is effectively a static pool in the sense that member (dynamic agent) workstations are defined manually and remain static or unchanged until the list of workstations is modified.

The dynamic pool definition, as it’s name suggests, contains dynamic agent workstations based upon selection criteria. For example, all dynamic agents running on the Linux OS could be specified. The dynamic pool would contain all currently active dynamic agent workstations that run on Linux. If a dynamic agent was stopped or the Linux OS on which it was running shutdown, the dynamic agent workstation would be automatically removed from the dynamic pool. When the OS is restarted, and the dynamic agent starts running again, it would be automatically brought back into the dynamic pool and be available to execute batch for the dynamic pool.

The dynamic pool can be configured to use different algorithms for selection of the agent chosen to execute the batch workload. For example, the ordered workstation option can be used to always execute the batch on the first available workstation in the list of eligible (dynamic agents) workstations. This could be used, for example, to always execute a job on the BAU workstation in the dynamic pool and only if that was unavailable, execute the job on the standby agent in the pool. This scenario could be used for a failover configuration instead of having to use a clustered FTA solution.

The next blog in the series will look at using the built-in file transfer advanced job types to automate pulling files from remote sites such as 3^rd party suppliers.

Visits: 966