With the underpinnings in place, you are now ready to load assets into Application Configuration Console.
Note:The tasks in this chapter assume that you are already logged in to the Application Configuration Console Client.
Part of the process of loading assets is to build a hierarchical structure that mirrors your operation. In Application Configuration Console, you load assets and configurations into objects called containers. The top-level container is a project. Under projects you can have environments, layers, and folders. Or you can have no other container levels. Remember, these are devices that you can use as necessary to fit your organizational structure. If you want to give them different labels, feel free to do so.
Figure 4-1 shows an example structure that will serve as backdrop for discussions in the remainder of this book:
In particular, we'll work with the Portal Lifecycle View project that has the Development, Staging, and Production environments, each with a Web Server and App Server layer.
Assets represent external resources, such as an application server, a Web server, or a router. They contain the Application Configuration Console configurations that hold the configuration data from the external resources. You can add an asset under any container in your hierarchy, such as directly under a project or under a layer.
Working with the foundation we've put in place, we're going to add an asset as follows:
In the Navigator view under 4, expand Portal Lifecycle View > Development.
Right-click App Server and select Add > Asset.
The Add Asset dialog opens.
Enter a name for the asset, Server1, for example.
We're creating from a resource specification, so make sure that's the radio button selected, then locate the resource spec we created in Chapter 3 (RS-XML) in the drop-down list.
After a moment, the Host/Endpoint, Authentication Pack, and Base Directory fields are filled in, based on the resource spec selected.
Click OK to load the asset configurations.
After a moment, you should see a message denoting the success of the operation.
If you look at the Navigator view, you'll see the asset Server1 and its configurations as determined by the resource spec under the App Server container.
Resource View represents the default asset view, that is, as the asset's configurations appear in the external resource. The Physical View of a configuration is its raw text format; the Primary View is a parsed view of a configuration arranged as elements and property-value pairs in a container hierarchy. Note that you can create your own custom asset views; they are a handy way of subdividing an asset's configurations into logical groupings.
Note the following additional points about adding assets:
When adding an asset based on a resource spec, you can change the host/endpoint, auth pack, and base directory to target different resources. What remains constant is the file resource definition.
You can add an asset based on an existing asset. The asset you are adding then becomes subordinate to its master, the asset it is based on. This means that the subordinate's configuration values derive from the master asset, not from an external resource.
You can add an asset based on a template that represents an asset standard or model within your organization.
Behind the scenes, we've fleshed out the data to demonstrate additional functionality covered in later chapters. We created a new resource spec (RS-CONF) to load another asset (Aeneas). We also populated the Staging environment layers with the same assets from the Development environment. Consequently, the Navigator view now appears as shown in Figure 4-2:
Additionally, we've contrived to introduce some differences so things happen when we perform tasks in later chapters. If you're playing along at home, you may want to make some edits to your data, so you experience similar results.
Note:Please keep in mind that, while we're working with just a couple of assets that have a small number of configurations, in reality, it's not uncommon for enterprises to load hundreds of assets that contain thousands or even tens of thousands of configurations.