Component usage implementation
After you have discovered components, you can begin to implement their use.
If you are distributing software based on a software model, you typically package and deploy components based on a component template (see Packaging-and-deploying-a-component).
If you are ensuring compliance with a policy, you typically run a Compliance Job (see Creating-Compliance-Jobs) based on a component template. Then you can view the Compliance Job results (see Compliance-results). If you prefer, you can export the results to view them in another format (see Exporting-compliance-results).
When you set up a Compliance Job, you can enable the automatic remediation of any compliance rule failures. If you enable automatic remediation, the Compliance Job can gather BLPackages containing the settings and server objects needed to ensure compliance and deploy those packages to any servers where components require remediation. You can also deploy packages directly to components, which is particularly useful if you have multiple components on the same server.
Alternatively, after a Compliance Job finishes, you can view the Compliance Job results, where you can see which compliance rules have not been satisfied and can manually choose the situations that require remediation. To handle such items, you can gather BLPackages and deploy them to the servers or components needing remediation (see Manually-remediating-compliance-results).
Some compliance failures may not require remediation, and you can define compliance rules that ignore the failure. In addition, you can create components that do not satisfy compliance rules in the component template but are nonetheless classified as consistent when you run a Compliance Job. You can even define exceptions for a particular server object, as long as the object can be expressed in the form of a path. Exceptions must be set up on a component-by-component basis, by using the same procedure that you follow when manually creating a component (see Adding-components-to-servers-manually) or modifying an existing component (see Modifying-components).
In some situations, you may determine that a compliance rule needs adjustment or that some other aspect of the component template definition needs adjustment. If you modify the definition of the component template, your changes are automatically applied to any existing components.
After you are satisfied that the deployed components are compliant with the component template, you can begin to treat components as you would any other server object — you can browse, snap, audit, and deploy them. You may also want to continue to run Compliance Jobs on the components to ensure that they remain consistent with the component template. To run a Compliance Job, you must first define compliance rules, a task performed when you edit a component template.
You can use snapshots and audits of components for tracking change. For example, you can take snapshots of components on a regular schedule to monitor change on an ongoing basis. You can use those snapshots to identify what changes are occurring in server configurations and when those changes have occurred.
Because you can run Snapshot and Audit Jobs on multiple components simultaneously, you can group components together according to the business service they perform. For example, if you are using an enterprise resource planning (ERP) system that consists of multiple applications, you can encapsulate each application into a component. Then you can use regularly scheduled snapshots to record the configuration of all applications in the ERP. You can use audits to identify and correct discrepancies in those configurations.
For an example that demonstrates how to ensure application compliance using many aspects of component-related functionality, see Using component templates to ensure compliance for multiple instances of an application.