ActiveBatch Architecture
The ActiveBatch architecture has always been a multi-tier approach (enabling centralized job scheduling with distributed job execution) consisting of the following elements:
* ActiveBatch Job Scheduler — This Microsoft Windows-based layer consists of the ActiveBatch automation intelligence and logic to understand the requirements presented in operating a real-time, event-driven system;
* ActiveBatch Backend – This database tier is where the “job” definitions and templates are maintained along with how the “jobs” are to be triggered (i.e., date/time-based, event-based, data-based, or on-demand). This layer also determines which resources are required (e.g., servers) to run the defined jobs, and what to do upon a job’s success or failure, or based on other information. This layer uses either Microsoft SQL Server or Oracle database;
* ActiveBatch Client – This client layer is the interface in which the user, developer, or operator interacts with the ActiveBatch system. Workflow design, programmatic connections, or simply review of jobs’ status (success or failure) can be monitored or reviewed. There is a raft of possible client-side technologies, such as Microsoft Common Object Model (COM), Web Services/Simple Object Access Protocol (SOAP) for cross-platform environments, Windows-based applications, Command Line Interface (CLI), Web Server interfaces, Personal Digital Assistant (PDA) gadgets, SmartPhone devices, and wireless BlackBerry handheld devices; and
* ActiveBatch Execution Agents – This tier represents the physical or virtual hardware and software systems, which execute the “jobs,” applications, processes, etc., as directed by the abovementioned ActiveBatch Job Scheduler. Execution agents can run on a number of operating system (OS) platforms like Microsoft Windows (including Windows Vista, Windows Server 2003, Windows XP, and Windows 2000), UNIX, Linux, OpenVMS (including the Alpha and Itanium brands), and IBM z/OS (for the ActiveBatch Job Library feature that will be explored later on).
A fully operational ActiveBatch instance requires each of the basic architecture layers, i.e., Job Scheduler, Database, Client/User Interface (UI), and a minimum of one ActiveBatch Execution Agent. Most ActiveBatch shops have Windows systems. But even some like, for example, LiveWire Mobile that have over 90 Linux servers and only a few Windows systems, still strongly support ActiveBatch as a key approach to integrating applications, databases, and platforms into coherent workflows.
Panoply of Job Types and User Views
As mentioned in Part 1, ActiveBatch attempts to provide “Intelligent Automation” for its users with an approach that can minimize or eliminate scripting. Up through Release 6, the product has offered the following five types of jobs (by comparison, most of other counterpart job scheduling products only support one or two job types):
1. Process Job — lets users run user-written scripts and/or executable program files. For example, I could un the Windows Internet Explorer executable (IEXPLORE.exe) and pass TEC’s Uniform Resource Locator (URL) as a parameter to open the TEC’s home page. Worth noting here is the “Copy Script to execution machine” option for running scripts as a process, as well as the ability to allow pre- and post-job steps;
2. File Transfer Protocol (FTP) Job — can initiate a series of FTP and/or Secure FTP commands in a heterogeneous fashion, using the following secure protocols: Secure Socket Layer (SSL) v3 and v2, Private Communications Technology (PCT), Transport Layer Security (TLS), Secure Shell (SSH), or without embedded security;
3. File System Job — lets users perform operations such as Copy, Delete, Rename or Move Files, or Create New or Delete a Directory, without regard to the specific platform they are on, and what Command shell they might need to use.
4. Email Job – lets users compose e-mails, whereby email servers and/or clients that leverage Simple Mail Transfer Protocol (SMTP) can be utilized (not necessarily only Microsoft Outlook or Microsoft Exchange Server). A notable capability is the use of variables to create alerts/triggers (e.g., when a certain stock symbol reaches certain value); and
5. Script Job — where the script (rather than an executable file, e.g., a Visual Basic Script [VBS] piece of code) is placed into an ActiveBatch job so that it can be executed on any system rather than being limited to the system where the file resides. Scripts using virtually any script language can be used, and if ActiveBatch does not provide an extension the designer can simply add it to the list. However, the server running the script must be able to associate with the relevant file extension.
Various Views to Monitor Jobs
Furthermore, ActiveBatch comes with a number of different ways of viewing and monitoring ongoing enterprise jobs. To that end, the Run Book view shows operators’ job schedules in a calendar view (à la Microsoft Outlook), whereas the Daily View shows daily job executions in a detailed list. Both views can be used by operators to monitor the status of jobs that have been run, are still running, or are scheduled to run (past, present, and future). Jobs can be filtered by days or execution status (i.e., “Show me only jobs that have failed, aborted, not run, or are still executing!”).
The Gantt View can be used by job designers as well as administrators and operations staff to identify load levels (to balance loads) or quiet periods for system’s planned maintenance, etc. Finally, the Administrators View helps administrators with setting policies, defaults, etc. Part 3 will unveil the latest enhancements and options offered within Release 7.
ActiveBatch Evolution
ASCI continues with ActiveBatch’s ongoing development with a cycle of 18 months between versions. This allows the vendor to offer existing and new customers the ability to take advantage of new features and approaches in technology by applying them for improved performance and usability.
In the ActiveBatch V4 product release, the ActiveBatch Backend layer was changed from a proprietary database to the much more standard Microsoft SQL Server and Oracle. This has enabled the vendor to take advantage of the database programming power that the “stored procedure” capabilities could deliver. Also, these two database systems were the primary databases used by the ASCI’s target marketplace as part of their IT infrastructure, thereby reducing the learning and training costs for users.
Moreover, ActiveBatch V4 added support for additional OS platforms such as IBM AIX, HP-UX, and Linux to the previously supported Windows, Sun Solaris, HP Tru64 UNIX, and OpenVMS environments. The client interface was updated with a new graphical user interface (GUI) for drag-and-drop operations to simplify the design of workflows. Finally, the High Availability capability was added, remote management access was provided for Internet access, and remote management was made possible using BlackBerry devices.
In the ActiveBatch V5 release, performance became paramount as ASCI took advantage of the power of the supported databases. The vendor was able to test actual performance of up to 2,000 disparate server connections (i.e., execution agents), and over 1,300,000 jobs triggered in a 24 hour period. Moreover, ASCI says that there are no architectural limits in this regard.
As for managing workflows and all ActiveBatch objects such as Jobs, Schedules, Calendars, Users, Servers, Alerts, and more, the product was now able to put these objects into a one container called a Job Plan. Finally, while ActiveBatch had always fully exposed its Microsoft COM interface for programmatic access to its objects, methods, and properties, this release added a Web Services programmatic access for users who were not Windows-based, for true cross-platform capabilities.
ActiveBatch V6 – The Game-changing Begins?
The ActiveBatch V6 release had many major enhancements. For one, it introduced the framework for the abovementioned Job Library, containing templates to applications and key functions used by IT departments in support of the customer’s business. The goal was to reduce code scripting, so that users could simply add key information (e.g., select options in a wizard-like style), and ActiveBatch would be able to run jobs behind the scenes.
These templates include a variety of jobs, such as follows: Structural Query language (SQL) routines, Data Transformation Service (DTS) packages, SQL Server Integration Services (SSIS), Crystal Reports creation, etc. The library also caters to functions like Secure FTP, file archiving, ZIP file operations (compressions), email jobs, etc. The use of ready-made job libraries within ActiveBatch eliminates both errors through reusability and the hassles of creating scripts. In layman terms, complex workflows can be composed by selecting options from a library of routines rather than via pesky coding of scripts.
The V6 release also featured a much improved audit system for compliance and control with both internal policies as well as governmental regulations. In addition, there is the capability for dynamic policy auditing using the Audit Variable feature. Also, policies can be mandatory or optional, and users can also conduct policy version comparisons.
The release offered HP OpenView and Microsoft System Center Operations Manager (SCOM, formerly Microsoft Operations Manager [MOM]) to fully manage and monitor objects in the ActiveBatch system around the clock. V6 also introduced the ActiveBatch Mobile capability for Smartphones and PDA’s (beyond BlackBerry devices).
Furthermore, ActiveBatch Windows execution agents now fully support 64-bit systems as well as 32-bit ones as appropriate. Other general changes for improved IT service levels entailed the following:
* setting expected start times for event-based jobs;
* alerting for delayed and late running jobs;
* Windows PowerShell; and
* setting the maximum dispatch time.
As another major enhancement, ActiveBatch 6 introduced the concept of Virtual Root to allow for its job scheduler to be made available as a multi-tenant utility within or outside of the enterprise. Each organization’s unit will see its “Job Plans” populated with its ActiveBatch objects, but, if so required, will not be able to see or access other users’ plans and objects. In other words, each user/tenant is isolated, secured, and “blind” or transparent to the other. Each unit’s plans are published as directory references for secure access.
Last but not least, event management capabilities were enhanced for non-Windows-based systems. The options range from file triggers, centralized logging (log files can be made directly to the UI/client regardless of platform type), and silent (push) installations. The system also features integration of jobs to be executed on a mainframe system, or for a mainframe job to trigger other workflows on Windows, Linux, UNIX or OpenVMS systems.
The ActiveBatch architecture has always been a multi-tier approach (enabling centralized job scheduling with distributed job execution) consisting of the following elements:
* ActiveBatch Job Scheduler — This Microsoft Windows-based layer consists of the ActiveBatch automation intelligence and logic to understand the requirements presented in operating a real-time, event-driven system;
* ActiveBatch Backend – This database tier is where the “job” definitions and templates are maintained along with how the “jobs” are to be triggered (i.e., date/time-based, event-based, data-based, or on-demand). This layer also determines which resources are required (e.g., servers) to run the defined jobs, and what to do upon a job’s success or failure, or based on other information. This layer uses either Microsoft SQL Server or Oracle database;
* ActiveBatch Client – This client layer is the interface in which the user, developer, or operator interacts with the ActiveBatch system. Workflow design, programmatic connections, or simply review of jobs’ status (success or failure) can be monitored or reviewed. There is a raft of possible client-side technologies, such as Microsoft Common Object Model (COM), Web Services/Simple Object Access Protocol (SOAP) for cross-platform environments, Windows-based applications, Command Line Interface (CLI), Web Server interfaces, Personal Digital Assistant (PDA) gadgets, SmartPhone devices, and wireless BlackBerry handheld devices; and
* ActiveBatch Execution Agents – This tier represents the physical or virtual hardware and software systems, which execute the “jobs,” applications, processes, etc., as directed by the abovementioned ActiveBatch Job Scheduler. Execution agents can run on a number of operating system (OS) platforms like Microsoft Windows (including Windows Vista, Windows Server 2003, Windows XP, and Windows 2000), UNIX, Linux, OpenVMS (including the Alpha and Itanium brands), and IBM z/OS (for the ActiveBatch Job Library feature that will be explored later on).
A fully operational ActiveBatch instance requires each of the basic architecture layers, i.e., Job Scheduler, Database, Client/User Interface (UI), and a minimum of one ActiveBatch Execution Agent. Most ActiveBatch shops have Windows systems. But even some like, for example, LiveWire Mobile that have over 90 Linux servers and only a few Windows systems, still strongly support ActiveBatch as a key approach to integrating applications, databases, and platforms into coherent workflows.
Panoply of Job Types and User Views
As mentioned in Part 1, ActiveBatch attempts to provide “Intelligent Automation” for its users with an approach that can minimize or eliminate scripting. Up through Release 6, the product has offered the following five types of jobs (by comparison, most of other counterpart job scheduling products only support one or two job types):
1. Process Job — lets users run user-written scripts and/or executable program files. For example, I could un the Windows Internet Explorer executable (IEXPLORE.exe) and pass TEC’s Uniform Resource Locator (URL) as a parameter to open the TEC’s home page. Worth noting here is the “Copy Script to execution machine” option for running scripts as a process, as well as the ability to allow pre- and post-job steps;
2. File Transfer Protocol (FTP) Job — can initiate a series of FTP and/or Secure FTP commands in a heterogeneous fashion, using the following secure protocols: Secure Socket Layer (SSL) v3 and v2, Private Communications Technology (PCT), Transport Layer Security (TLS), Secure Shell (SSH), or without embedded security;
3. File System Job — lets users perform operations such as Copy, Delete, Rename or Move Files, or Create New or Delete a Directory, without regard to the specific platform they are on, and what Command shell they might need to use.
4. Email Job – lets users compose e-mails, whereby email servers and/or clients that leverage Simple Mail Transfer Protocol (SMTP) can be utilized (not necessarily only Microsoft Outlook or Microsoft Exchange Server). A notable capability is the use of variables to create alerts/triggers (e.g., when a certain stock symbol reaches certain value); and
5. Script Job — where the script (rather than an executable file, e.g., a Visual Basic Script [VBS] piece of code) is placed into an ActiveBatch job so that it can be executed on any system rather than being limited to the system where the file resides. Scripts using virtually any script language can be used, and if ActiveBatch does not provide an extension the designer can simply add it to the list. However, the server running the script must be able to associate with the relevant file extension.
Various Views to Monitor Jobs
Furthermore, ActiveBatch comes with a number of different ways of viewing and monitoring ongoing enterprise jobs. To that end, the Run Book view shows operators’ job schedules in a calendar view (à la Microsoft Outlook), whereas the Daily View shows daily job executions in a detailed list. Both views can be used by operators to monitor the status of jobs that have been run, are still running, or are scheduled to run (past, present, and future). Jobs can be filtered by days or execution status (i.e., “Show me only jobs that have failed, aborted, not run, or are still executing!”).
The Gantt View can be used by job designers as well as administrators and operations staff to identify load levels (to balance loads) or quiet periods for system’s planned maintenance, etc. Finally, the Administrators View helps administrators with setting policies, defaults, etc. Part 3 will unveil the latest enhancements and options offered within Release 7.
ActiveBatch Evolution
ASCI continues with ActiveBatch’s ongoing development with a cycle of 18 months between versions. This allows the vendor to offer existing and new customers the ability to take advantage of new features and approaches in technology by applying them for improved performance and usability.
In the ActiveBatch V4 product release, the ActiveBatch Backend layer was changed from a proprietary database to the much more standard Microsoft SQL Server and Oracle. This has enabled the vendor to take advantage of the database programming power that the “stored procedure” capabilities could deliver. Also, these two database systems were the primary databases used by the ASCI’s target marketplace as part of their IT infrastructure, thereby reducing the learning and training costs for users.
Moreover, ActiveBatch V4 added support for additional OS platforms such as IBM AIX, HP-UX, and Linux to the previously supported Windows, Sun Solaris, HP Tru64 UNIX, and OpenVMS environments. The client interface was updated with a new graphical user interface (GUI) for drag-and-drop operations to simplify the design of workflows. Finally, the High Availability capability was added, remote management access was provided for Internet access, and remote management was made possible using BlackBerry devices.
In the ActiveBatch V5 release, performance became paramount as ASCI took advantage of the power of the supported databases. The vendor was able to test actual performance of up to 2,000 disparate server connections (i.e., execution agents), and over 1,300,000 jobs triggered in a 24 hour period. Moreover, ASCI says that there are no architectural limits in this regard.
As for managing workflows and all ActiveBatch objects such as Jobs, Schedules, Calendars, Users, Servers, Alerts, and more, the product was now able to put these objects into a one container called a Job Plan. Finally, while ActiveBatch had always fully exposed its Microsoft COM interface for programmatic access to its objects, methods, and properties, this release added a Web Services programmatic access for users who were not Windows-based, for true cross-platform capabilities.
ActiveBatch V6 – The Game-changing Begins?
The ActiveBatch V6 release had many major enhancements. For one, it introduced the framework for the abovementioned Job Library, containing templates to applications and key functions used by IT departments in support of the customer’s business. The goal was to reduce code scripting, so that users could simply add key information (e.g., select options in a wizard-like style), and ActiveBatch would be able to run jobs behind the scenes.
These templates include a variety of jobs, such as follows: Structural Query language (SQL) routines, Data Transformation Service (DTS) packages, SQL Server Integration Services (SSIS), Crystal Reports creation, etc. The library also caters to functions like Secure FTP, file archiving, ZIP file operations (compressions), email jobs, etc. The use of ready-made job libraries within ActiveBatch eliminates both errors through reusability and the hassles of creating scripts. In layman terms, complex workflows can be composed by selecting options from a library of routines rather than via pesky coding of scripts.
The V6 release also featured a much improved audit system for compliance and control with both internal policies as well as governmental regulations. In addition, there is the capability for dynamic policy auditing using the Audit Variable feature. Also, policies can be mandatory or optional, and users can also conduct policy version comparisons.
The release offered HP OpenView and Microsoft System Center Operations Manager (SCOM, formerly Microsoft Operations Manager [MOM]) to fully manage and monitor objects in the ActiveBatch system around the clock. V6 also introduced the ActiveBatch Mobile capability for Smartphones and PDA’s (beyond BlackBerry devices).
Furthermore, ActiveBatch Windows execution agents now fully support 64-bit systems as well as 32-bit ones as appropriate. Other general changes for improved IT service levels entailed the following:
* setting expected start times for event-based jobs;
* alerting for delayed and late running jobs;
* Windows PowerShell; and
* setting the maximum dispatch time.
As another major enhancement, ActiveBatch 6 introduced the concept of Virtual Root to allow for its job scheduler to be made available as a multi-tenant utility within or outside of the enterprise. Each organization’s unit will see its “Job Plans” populated with its ActiveBatch objects, but, if so required, will not be able to see or access other users’ plans and objects. In other words, each user/tenant is isolated, secured, and “blind” or transparent to the other. Each unit’s plans are published as directory references for secure access.
Last but not least, event management capabilities were enhanced for non-Windows-based systems. The options range from file triggers, centralized logging (log files can be made directly to the UI/client regardless of platform type), and silent (push) installations. The system also features integration of jobs to be executed on a mainframe system, or for a mainframe job to trigger other workflows on Windows, Linux, UNIX or OpenVMS systems.
No comments:
Post a Comment