Authorized space and promotion filtering
Authorized space and promotion scope filtering allows you to import only the actual CI data that you plan to manage in your authorized space.
This method provides more fine grained control over exactly which classifications and which attributes of these classifications are imported. It requires authorized CI classifications and promotion scopes to be created in Deployer's Workbench and exported to Maximo IT. As such, it also requires more up front planning. However, this is the recommended approach for medium to large sized environments, as it provides a significant performance improvement in Integration Composer actual CI mapping. This is because only those attributes that you specify in the promotion scope are imported.
To import only the CI data that you plan to manage in your authorized space, create and export your authorized CI space using Deployer's Workbench.
When authorized space filtering is enabled, the default depth setting and the individual depth values for the active, top-level classifications will be used to retrieve CI data, but all other depth settings will be ignored. It will follow the relationships of the top-level CIs to find related CIs. The difference is, as each CI is being processed, its classification and each attribute will be checked against the authorized space you created to determine whether the classification or attribute type has been included in the authorized space. If it is included, it is imported, otherwise the CI or attribute is skipped and the next CI or attribute is checked. This process continues until each top-level CI and their related CIs have been processed.
Understanding authorized space filtering settings
It is important to understand how both the CI Type activation settings and promotion scopes determine what CI data is imported when authorized space filtering is enabled. The activated CI Types determine what data is retrieved for processing. These activated CI Types must also be in a promotion scope in order to be imported. Additionally, you can also include specific CI type attributes in the promotion scope in order to reduce the amount of data that is imported. Related CI classifications must also be in a promotion scope in order to be imported.
Depth level | Class |
---|---|
1 | Computer System |
2 | .........Operating System |
3 | .................Software |
You activate ComputerSystem with a depth of 3.
In your authorized space, you create a ComputerSystem promotion scope, and add the ComputerSystem and OperatingSystem classifications within the promotion scope. In the ComputerSystem authorized CI classification, you add the ComputerSystem_FQDN attribute. In the OperatingSystem authorized CI classification, you add the OperatingSystem_Name and OperatingSystem_Version attributes. You then export your authorized CI classifications and promotions scopes to your Maximo IT server from Deployer's Workbench and run the actual CI mapping.
In this scenario, all the ComputerSystem CIs are retrieved along with their related OperatingSystem and Software CIs. As each ComputerSystem CI is processed, it is imported, but only the ComputerSystem_FQDN attribute is imported for each one, because this is the data you have included in your ComputerSystem promotion scope. Any other attributes are ignored.
The relationships are then followed to depth 2 to find the OperatingSystem CIs. These are imported with the two specified OperatingSystem attributes, since you added them to your ComputerSystem promotion scope.
Finally, the relationships are followed to depth 3, to find the Software CIs. However, the CIs are not imported because the Software CI type was not added to a promotion scope.
A CI Type is in a promotion scope but not activated
In this example,Sys.WindowsComputerSystem CI Type is activated and the authorized CI classifications Sys.WindowsComputerSystem and Sys.VMWareUnitaryComputerSystem are in a promotion scope. In this case, all of the WindowsComputerSystem CIs are imported and their related CIs are retrieved using the depth you specify.
If any of the related CIs are VMWareComputerSystems, those VMWare CIs are imported because that classification is also in a promotion scope. However, not all VMWare CIs are retrieved because the VMWare CI Type is not activated. Instead, only the VMWare CIs that are related to WindowsComputerSystem CIs are imported. If you do not want VMWare CIs in this scenario, remove Sys.VMWareUnitaryComputerSystem from the promotion scope and export the authorized space again from Deployer's Workbench. If you wanted all the VMWare CIs, not just the ones related to WindowsComputerSystem CIs, activate the VMWare CI Type.
A CI Type is activated but not in a promotion scope
- Activate Sys.WindowsComputerSystem and add it to a promotion scope. In this case, you import the preceding data, together with all the WindowsComputerSystem CIs.
- Activate Sys.VMWareUnitaryComputerSystem. You import all VMWare CIs and not just those related to WindowsComputerSystem CIs.
A super class CI Type is activated but only a subclass is in a promotion scope
In this example, a superclass, such as Sys.ComputerSystem, is activated and a subclass, such as the Sys.ZSeriesComputerSystem authorized CI classification, is in a promotion scope. All of the subclasses of Sys.ComputerSystem are processed, but only the Sys.ZSeriesComputerSystem CIs are imported in this scenario, because that is the only one in the authorized space. To further improve performance, it would be best to activate only the subclasses you need instead of the super class in this type of scenario.