Implementing CCAPI

Use of the CCAPI revolves around the CCProxy class, which implements both the ControlCenterProxy, and the ConfigServiceProxy interfaces. Users will instantiate a copy of a CCProxy, providing all the connection information necessary to initiate a connection with a IBM Control Center Monitor engine, including:
  • IBM Control Center engine IP address (or DNS host name)
  • IBM Control Center engine API port
  • IBM Control Center User ID
  • IBM Control Center User password
  • Indication of whether a secure connection is to be used or not

Use CCProxy to initiate IBM Control Center operations.

The CCProxy manages the session between the user's code and the IBM Control Center engine by automatically connecting and disconnecting to the engine when necessary. Therefore, the user does not need to establish, or disconnect, connections with the IBM Control Center engine.

Using CCProxy to Initiate Control Center Operations

After a CCProxy has been constructed, the following IBM Control Center operations may be initiated:

  • getDvgIDs() returns a list of the existing DVG identifiers.
  • getDvg(String dvgID) returns the specified DVG object.
  • createDvg(Dvg ccAPIObject) creates the specified DVG object.
  • deleteDvg(String dvgID) deletes the specified DVG.
  • updateDvg(Dvg ccAPIObject) updates the specified DVG object.
  • getRoleIDs() returns a list of the existing Role identifiers.
  • getRole(String RoleID) returns the specified Role object.
  • createRole(Role ccAPIObject) creates the specified Role object.
  • deleteRole(String RoleID) deletes the specified Role.
  • updateRole(Role ccAPIObject) updates the specified Role object.
  • getServerIDs() returns a list of the existing Server identifiers.
  • getServer(String ServerID) returns the specified Server object.
  • createServer(Server ccAPIObject)creates the specified Server object.
  • deleteServer(String ServerID) deletes the specified Server.
  • updateServer(Server ccAPIObject) updates the specified Server object.
  • getServerGroupIDs() returns a list of the existing ServerGroup identifiers.
  • getServerGroup(StringServerGroupID) returns the specified ServerGroup object.
  • createServerGroup(ServerGroup ccAPIObject) creates the specified ServerGroup object.
  • deleteServerGroup (String ServerGroupID) deletes the specified ServerGroup.
  • updateServerGroup(ServerGroup ccAPIObject) updates the specified ServerGroup object.
  • getUserIDs() returns a list of the existing User identifiers.
  • getUser(String UserID) returns the specified User object.
  • createUser(User ccAPIObject) creates the specified User object.
  • deleteUser(String UserID) deletes the specified User.
  • updateUser(User ccAPIObject) updates the specified User object.

In addition to these operations, the following Node object configuration operations may be initiated:

  • create() constructs new Node Configuration objects.
  • delete() deletes existing Node Configuration objects.
  • update() updates existing Node Configuration objects.
  • rekeySecurePlusParmFile() performs a rekey of a server's Secure Plus parmfile using a provided seed value.
  • synchSecurePlusParmFile() performs a Secure Plus parmfile synch operation for servers.
  • validateSecurePlusParmFile() performs a Secure Plus parmfile validation for a server.

The configuration object operations create() and update(), and the configuration template operations createTemplate() and updateTempate(), all work with ConfigObject, or one of the following subclasses of ConfigObject:

  • InitParms
  • NetmapCommpath
  • NetmapMode
  • NetmapNode
  • SecurePlusCert
  • SecurePlusCipher
  • SecurePlusKeyCert
  • SecurePlusNode
  • SecurePlusParmFile
  • SecurePlusTrustedCert
  • UserAuth
  • UserProxy

Submitting and Ascertaining Status for Control Center Configuration Operations

When node configuration operations are initiated, a JobID is assigned to the work to be performed, and control along with the assigned JobID, is returned immediately to the caller. The user application may receive control back from the CCProxy before the specified operation is even started, and almost always before it is completed.

All configuration jobs have one of the following status values after they have been submitted to the IBM Control Center engine:

  • NodeConfigConstants.JOB_HELD - held configuration jobs may be released or canceled.
  • NodeConfigConstants.JOB_COMPLETE - completed configuration jobs may be run again by releasing them. A new JobID will be assigned to released completed jobs.
  • NodeConfigConstants.JOB_CANCELED - configuration jobs that have been canceled.
  • NodeConfigConstants.JOB_RUNNING - running configuration jobs may be held.
  • NodeConfigConstants.JOB_SCHEDULED - scheduled configuration jobs may be held to prevent them from starting at their appointed time.

Users may ascertain the status of configuration operations previously initiated using the following CCProxy methods:

  • getCompletedJobs() returns a list of Jobs known to IBM Control Center, which have completed (status JOB_COMPLETE).
  • getQueuedJobs() returns a list of Jobs known to IBM Control Center that have not completed. Each Job returned may have its status checked using the Job.getStatus() method.
  • getJob() returns the Job associated with the specified JobID value. The Job returned may have its status checked using the Job.getStatus() method.
  • getJobs() returns a list of JobIDs with the specified job name.
  • getJobResults() returns a list of Strings, each one representing a status event associated with the specified JobID value.
  • isJobInProgress() returns True if the configuration job specified is neither complete nor scheduled to run.

Users may affect the status of non-canceled configuration object jobs using the following CCProxy methods:

  • cancelJob() transitions running (status JOB_RUNNING) and held (status JOB_HELD) jobs, to a status of JOB_CANCELED.
  • holdJob() transitions scheduled (status JOB_SCHEDULED) jobs, to a status of JOB_HELD.
  • releaseJob() transitions held (status JOB_HELD) jobs, to a status of JOB_SCHEDULED.
  • updateJob() updates held (status JOB_HELD) jobs.

Additionally, the CCProxy class provides several helper methods to assist in the initiation of configuration object operations:

  • getCRUDAbility() returns the CRUDAbility object, which specifies the type of functions (create, read, update, and delete) that can be performed for the server and object type specified.
  • getConfigObjects() returns the latest Version of objects of the type specified for the server named.
  • getServerOSType() returns a string representation of the OS the specified server is running on.
  • getServers() returns the list of servers (accessible by the requesting user) that can manage the specified type of configuration object.
  • getManagementObjectTypes() returns a list of object type values that represent the type of objects manageable by the specified serverID.

Managing Versions of Configuration Objects for Managed Servers

IBM Control Center Monitor keeps Versions of configuration objects for managed servers. When a local update to a configuration object is made and IBM Control Center Monitor finds out, it creates a Version of the objects of that type. For example, if a netmap node is updated locally, or through IBM Control Center Monitor, Control Center Monitor creates a Version of the set of affected server's netmap nodes. The number of Versions of each object type kept by IBM Control Center is controlled by the System Settings. Also, authorized users can enable IBM Control Center Monitor to automatically check for local updates made to managed servers' configuration objects using System Settings. You can manage Versions of netmap nodes, netmap modes, netmap communication paths, initialization parameters, Secure Plus nodes, Secure Plus key certificates, Secure Plus trusted certificates, Secure Plus cipher suites, functional authorities, and user proxies using the following CCProxy methods:

  • getLastSync() returns the time of the last synch operation.
  • getVersion(serverID,objectType) returns the most recent set of configuration objects in IBM Control Center, of the specified type, for the specified server.
  • getVersion(VersionID) returns the list of configuration objects in the specified VersionID.
  • getVersions() returns the VersionIDs of s for a specified type of object on a specified server.
  • setVersionDescription() sets a description for the specified of objects.
  • synch() initiates a configuration job to synchronize the copies of configuration objects IBM Control Center has, of the type specified, with the specified servers at the time specified. New Versions of configuration objects may be created, or the time stamp on the current Versions may simply be updated, depending on whether or not any differences are found between what is received from the servers and the contents of the current Versions of those objects held by IBM Control Center.

Using CCProxy to Manage Configuration Templates

In addition to management of node configuration objects, the CCProxy can be used to manage configuration templates, which can be set up for many configuration object types. In addition to management of node configuration objects, the CCProxy can be used to manage configuration templates, which can be set up for many configuration object types and add efficiency to the process of creating new configuration objects, using the following methods:

  • createTemplate() constructs a new configuration template.
  • deleteTemplate() deletes a configuration template.
  • updateTemplate() updates a configuration template.
  • getTemplate() returns the configuration template with the specified ID and type.
  • getTemplateIDs() returns a list of IDs for all configuration templates of the specified configuration object type.
  • getTemplates() returns a list of all templates of the specified configuration object type