CCAPI process

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 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.

You 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 {{String}}s, 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.

You 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.

Version of configuration object

IBM Control Center keeps Versions of configuration objects for managed servers. When a local update to a configuration object is made and IBM Control Center finds out, IBM Control Center creates a Version of the objects of that type. For example, if a netmap node is updated locally, or through IBM Control Center, IBM Control Center 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 make IBM Control Center 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 Versions for a specified type of object on a specified server.
  • setVersionDescription() sets a description for the specified Version 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.

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. Templates 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.