Schedule and Orchestrate any vendor's Automation Plan

This page has not been liked. Updated 9/19/13, 4:55 PM by TuanTags: None

Business Goals

  1. The customer will be able to schedule jobs across TWS instances (the well known "submit and track" feature). The customer may have a TWS instance for each geography or one for each department or line of business. In this scenario, one TWS instance is taking care of the orchestration and triggers the execution of a workflow on a remote TWS instance.
  2. The customer will be able to schedule jobs on Tivoli System Automation. Customers are already requesting to schedule jobs defined on TSA/MP and this integration will make it possible.

Pre-conditions

  1. The customer has to specify the service provider URI. The customer can directly specify the URI or can use the pick list provided by TWS to select the service provider from the list of all the providers registered in the provider registry. If the customer wants to use this option, he has to install and configure the provider registry and the OSLC Automation provider has to be registered in the provider registry.
  2. The OSLC automation provider (TWS,TSA or alike)  is installed.
  3. The automation plan is already defined on the automation provider.
  4. The OSLC automation provider must comply with the specification (implement all MUSTs), and must also implement the following extension(s):
    1. The provider must implement a delegated creation dialog (fabrication dialog)  that returns the representation of the automation request to the client, but does not initiate execution of the Automation plan.
    2. The provider's delegated fabrication dialog must also allow selection of an existing Automation plan.
    3. The RDF representation of the automation request from the TWS job definition (client-side) is usable as the input to the automation provider's Automation Request creation factory. (It is not obvious to all that this capability is required by the Automation 2.0 spec, so we are being conservative by listing it as as an extension).
    4. The fabrication dialog must support json representation of the oslc results.
    5. The fabrication dialog must support the prefilling capability (see the specifications for creation dialogs).

Post-conditions

  1. The automation plan is executed on the OSLC automation service provider.
  2. The information to troubleshoot a failure is available to the customer.
  3. The output and/or any result of the execution of the workflow/action is available to the customer and to the subsequent jobs.

Steps

  1. On the client interface (TWS), the user selects the creation of a TWS job definition of type "OSLC/Automation" from the list of all the available TWS job types (see  selectJobType.jpg ). The list of the available job types includes scripts, sql statements, JMS messages, Web services, SAP jobs, and so on as well as associated information like access credentials.
  2. On the client interface (TWS), the user defines a name for the TWS job definition and the workstation that will run the job (see jobGeneral.bmp ). The first three tabs are common to all the TWS job definitions while tabs 4 and 5 are specific for the OSLC Automation job definition type. This step is common to all the job types.
  3. On the client interface (TWS), the user selects the provider registry where the automation provider is registered. The list of resource registries was previously configured by the user (see registryServices.bmp ).
  4. On the client interface (TWS), the user selects the appropriate automation provider (Eg TWS,TSA..) from a list of all the automation providers present in the registry (see serviceProvider.bmp ).
  5. On the client interface (TWS), the user presses the "configure instance" button. The following screenshot shows how the panel looks like before the user hits the button: button.bmp .
  6. On the client interface (TWS), TWS shows the user a delegated creation dialog exposed by the automation provider (see pre-conditions for required behavior). In the screenshot below the "No Create" creation dialog of a remote TWS instance is shown. A TWS JobStream is mapped to an OSLC AutomationPlan (see creationDialog.bmp ).
  7. Within the provider's delegated dialog, the user configures the action to be scheduled.
  8. On the client interface (TWS), the user saves the job definition. The RDF representation of the automation request is included in the TWS job definition (see jobdefintion.bmp ).

Once the job is defined it can be scheduled.

  1. On the client interface (TWS), the user submits/schedules the job execution. The job can be submitted for immediate execution, or at a specific time, or can be scheduled to be executed with a specific period. The RDF representation of the automation request from the TWS job definition (client-side) is used as the input to the automation provider's Automation Request creation factory.

When all the TWS job dependencies are met, TWS triggers the execution of the job. Execution might occur once, or on a repeating schedule.

  1. On the client interface (TWS), the user monitors the execution of the action (see monitorJobs.bmp ) until it completes.
  2. On the client interface (TWS), after the job completes, the user checks the final result and the properties it set. In the screenshot below, TWS is showing as TWS job properties the output parameters of the automation result, the URI of the automation request and, if provided, the URI of the automation result preview UI (see properties.bmp ).