Getting Started

Workbench is part design tool and part information repository. It is where you specify the architecture and configuration of your integrated applications and define the automation procedures that build and deploy those applications. Built for collaborative environments, Workbench also maintains revision history and access control for this crucial information. ControlTier clients (CTL) pull their automation modules and corresponding runtime properties from Workbench.

ControlTier follows a model and templates approach to application management. The goal is to templatize your automation and your configuration files so that you do not need to hand-edit your templates when you make routine updates or move your applications from environment to environment. All of the environment and situation specific information that your automation and configurations need are injected on demand by the application management model (host names, package names, file locations, security details, port numbers, doc roots, performance parameters, version control tags, etc...).

There are two main kinds of artifacts managed by Workbench:

Automation Context - Workbench holds the architecture, configuration, and environment details that your automation needs to know about when it executes. You edit this information through the web GUI in Workbench. There is also programmatic access (XML interface and Ant tasks) but that is outside of the scope of this document. This information is the "Model" part of the model and templates paradigm.

Automation Commands - These object-oriented commands contain your automation procedures that the ControlTier framework will execute. You can either create new procedures or use built-in workflows to drive your existing scripts and tools. Commands are created and maintained through the Type web GUI in Workbench. The Modules (along with any configuration files they generate) are the "template" part of the model and templates paradigm.

The ControlTier Client, is responsible for executing the automation defined as Commands. Before that automation executes, the Client talks to Workbench (over http/https) to ensure that it has up-to-date versions both the automation commands (as command modules) and environment specific automation context (as properties files).

Workbench is specifically designed to be flexible about the information that it can manage. You are free to choose whatever level of information you want to manage, but it is recommended that you use the desired output as the determining factor in how much information you want to put into Workbench. Workbench is also designed to allow you to start small and add more information as you go. It is recommended that you start by picking a particular problem (e.g. code builds and deployments to QA Environments) and allow that initial problem to determine how little or how much information you initially need to manage with Workbench. As you look to solve more problems with Workbench you can add the additional necessary information as needed.

The most common use of Workbench is to manage the deployment, configuration, and management of multi-tier integrated applications. Most of this manual focuses on that use, but Workbench can be used to manage any type or scope of technical information.

For the purpose of deploying, configuring, and managing multi-tier integrated applications, it is recommended that you begin by focusing on the external integrations (or contact points) between components as well as those details that change from environment to environment. This would include information such as:

• Packages - what software packages are used by the applications?
• Settings/Properties - What details are needed to configure, integrate, or manage applications? (especially those details that change from environment-to-environment or release-to-release)
• Commands - What procedures that can be executed and how to call them?
• Nodes - To what servers are the application comments being deployed?
• Dependencies - Given a particular component, what other components are required and how must the be attached?
• Constraints - What settings, bindings, or states are allowable?

The names Workbench and ControlTier Server are often used interchangeably. However, the name ControlTier Server actually refers to an administrative server deployment that includes both Workbench and an instance of the ControlTier Client. In this case, "ControlTier Server" describes a central machine from where you both manage and kickoff your automation.

For first-time users and experienced users alike, it is recommended that you get started with a new project using the Project Builder tool. This tool helps you create a series of simple text files that drive the creation of a new automation project. The Project Builder Guide shows how to utilize ControlTier's framework hooks and built-in process building blocks as well as introduce you to essential terms and concepts.

Go to the Project Builder Guide/Tutorial

Workbench stores its information in an object-oriented, hierarchical type/object model. Editing, browsing, and searching this model is the primary purpose of the various parts of the Workbench web GUI.

Aside from searching and browsing, most activity in Workbench takes place in two areas:

• Type Editor - This is where you edit your model's Types and can define commands and set constraints (usually in the form of dependency constraints).
• Object Editor - This is where you create and edit Objects (specific instances of a Type). This is also where you define the dependencies between Objects (child and parent resources), whether they be ports, nodes, packages, applications, or any other object. Through these dependencies you define the "structure" of your integrated applications.

Type Editor

Figure: Type Editor main screen.

Legend:

1 -Select this tab to display the Type's Details View

2 -Select this tab to display the Type's Commands View (where you to edit and create commands)

3 -Select this tab to display the Type's Files View (this view provides file level access to the command files for that Type)

4 -Select this tab to display the Type's Constraints View (where you create and edit constraints for the types information and dependencies)

5 -Select this tab to display a list of Objects that are of this Type

6 -Link to create a subtype based on this type

7 -Package Commands packages up all the module files into a JAR file for client installation

8 -Hierarchical tree browser for navigating to other Types. The hierarchy is organized by subtypes and supertypes

Object Editor

Figure: Object Editor main screen.

Legend:

1 -Select this tab to show the this Object's details (attributes)

2 -Select this tab to show a list of Commands for this Object. Note that Commands are defined by the Object's Type and clicking on a Command will take you to the Command editing view for this Object's Type (in the Type Editor view).

3 -Select this tab to view and edit child dependencies or view parent dependencies for this Object.

4 -Select this tab to browse all of the Properties available to this Object's Commands when they are executed by the ControlTier Client

5 -Select this tab to define Document Transform associated with this Object. Document Transforms is a kind of templating system that provides multiple ways process and format your model data so that it may be reused for any task.

6 -These boxes are navigational tools that let do tasks like browse Objects by type, go to an Object's Type, search for other Objects, browse the Object's revision history, or browse the logs of commands associated with this Object that have been executed by a ControlTier Client.

7 -Draws directed graph of that current object. Graphs also provides an alternative way to browse through the object model. The graph's controls enable you to set the scope of what you see in the graph.

Figure: Navigation Bar at the top of Type Editor and Object Editor screens

At the top of each Object Editor and Type Editor page there is a navigation bar that corresponds to the basic building block Types. These building blocks provide a set of interfaces to pre-built automation for parts of the build to deployment lifecycle. In most cases, you will be subtyping these building block Types when creating your automation. Each box on the navigation bar takes you to a screen that list of objects that are of that Type (or Subtype) as well as tools for common tasks such as browsing, searching, and creating new objects.

Below is a list of the main building blocks Types

For documentation on these building block Types as well as the core base Types, please visit the Base Type reference section.

The diagram belows shows how the building block Types interact to form a standard build and deployment lifecycle. In this example, the Updater kicks off the entire process by calling its BuildAndUpdate command (with a tag, buildstamp, or other identifier that the Builders understand). The Builders coordinate the various build and packaging processes and registers the newly created packages with the release repository (a WebDAV-based repository generally located on the ControlTier Server or admin node). The Updater sends a command to the Site automation to modify the management model and to use the new packages to update, configure, and restart the various components that makeup the Site (Sites are user defined but are generally a collection of related Services that makeup an integrated business application in a particular environment).