The section "Administration Guide › Reporting › How to Run Snapshot Reports › Create a Snapshot Definition › Create a Custom Snapshot Parameter XML File" could be improved by stating that if neither all_attributes is specified and no specific attributes are specified by name, then there will be no data written to the attribute detail tables. This is a way to speed up the export process and reduce hard disk requirements. Also, the existing doc implies by example that if a specific attribute is specified (or a group of attributes) with the exportattr element in a Snapshot Parameter file, then only those attribute(s) will be exported to the attribute detail tables (this is only applicable to where exportattr is supported, in user, group, organization and role objects). If there are sensitive attributes that you do not want to export, then do not use exportattr = |all_attributes|. Instead use exportattr once for each attribute you do wish to export. We only export the requested attributes to the attribute detail tables if the attribute is not already included in the primary tables. Any such attributes requested will not be duplicated in the attribute detail table, but can instead be found in the primary table.
It was reproduced by support and reviewed by sustaining engineering that the snapshot process is missing some custom information about objects and is exporting all attribute information regardless of the attribute filters implemented within the snapshot xml's themselves.
SP10 has added support for AdminRoles and AccessRoles to export custom attributes to the imrroleattr12 table.
Methodical inspection of the data stored within the snapshot database, as a result of the data mining snapshot process, has resulted in the elimination of the duplication of data stored within imruserattr6, imrgroupattr6 and imrogratt6 snapshot tables, which is already exported to imruser6, imrgroup6 and imrorg6 snapshot tables.
SP10 includes a fix for how “exportattr” is supported in Snapshot Parameter XML files. It will NOT export all_attributes unless |all_attributes| is specified for user, group, organization or role objects. If all_attributes is not specified, export will only export the attributes that are requested by name (in addition to the default attributes that always get exported).
Using some OOTB Snapshot Parameter XML Files and some custom Snapshot Parameter XML files, the following tests were performed:
1) Enabled custom attributes to be specified for AccessRole, AdminRole and ProvisioningRole, added custom attributes, exported object role with all_attributes set in Snapshot Parameter XML file. Verified that all custom attributes specified for all 3 role types were exported to the imrroleattr12 table, and verified that none of the data being written to the imrrole6 table is being replicated to the imrroleatt12 table.
2) For objects user, group or organization, verified that all attributes are written to the attribute detail tables only if all_attributes is set for the object. Also verified that if all_attriubes is not set, that we export only the attributes that are requested by name.
3) Verified that users can specify attribute names in Snapshot Parameter XML files in a case insensitive way (eTCity is same as etcity, for example).
4) Conducted all these tests twice, once in env where user=prov, one where user!=prov
The only OOTB report that is applicable is the subreport of the User Profile report, because this is the only report that uses any of the attribute detail tables (the subreport includes relevant imruserattr6 data). Use this report with default UserProfileReportSnapshot.xml file to test use of all_attributes enabled to verify all user attributes are generated, without duplicate of what data is exported to the imruser6 table. Then make a copy of the UserProfileReportSnapshot.xml file, and edit the user object section to no longer export all_attributes, then specify specific (non default) attributes. Rerun the report against the new snapshot to verify only the requested attributes are included in the subreport attribute detail drill down. Verification that data is not getting duplicated in the attribute detail tables imrgroupattr6, imrogratt6 and imrroleattr12 will require viewing the sql/oracle tables directly, because we do not have OOTB reports that report on these tables (this fix is simply to generate the data, not also report on it. These tables fall under the "they are there if you want to use them, but we do not report on them". There is no OOTB report to report on the role attribute details. You can develop a custom report in Crystal to do so, but if you would like another OOTB report to utilize this information, please contact support and we'll submit an enhancement request.
A sample is attached for how you can specify which user attributes to export to the userattr12 table
(Make sure you have values on City and Street address fields for at least one user to verify imruserattr6 table.)
Please post any questions or concerns.
Principal Support Engineer
Identity Manager Reporting Expert