Reporting Architecture Best Practice

[Anon Anon]

Reporting Architecture Best Practice

For scalability and to conform to reporting architecture guidelines,
It's a best practice to separate your Audit and Snapshot Database repositories into separate schema than the Identity Manager Object store or Reporting Server Database (CMS DB).



In the above diagram, the “Reporting Database” is simply a logical representation of any RDBMS that is the repository of report information, which the IAM Report Server will consume as the data for the reports. In this instance, the two databases that are listed under the logical container for “Reporting Database” are the “Audit”, and “Snapshot” databases respectively. Identity Manager’s snapshot process will data mine a tremendous amount of information, which will be stored within the database. In a large scale environment, Audit will store millions of transactions in it’s database. It’s extremely important to segregate this load from IM’s object store, which will further simplify database administration, and will help to keep IM’s Object Store db a finely tuned workhorse that will serve Identity Manager Application far into the future. It’s important to note, the SQL DDL can change, within the Reporting Databases, (from version to version) and these changes may not be reflected in the Object Store upgrade / install. It’s important that you run the SQL DDL scripts(for both snapshot and audit databases) on their specific repositories, before capturing a snapshot or auditing your environment, subsequent to an install OR upgrade. It's important to separate the Reporting Database from the CMS Database because the Reporting Databases are developed by CA, but the CMS database is developed by SAP. Since these are two products, which are developed in their own silo's we should not intermingle database objects in the same repository, due to unforseen and unsupported complications, which may result by doing this.

Please post with any questions or concerns.
Thank you.
Regards,

Chris Thomas
CA Technologies
Principal Support Engineer
Identity Manager Reporting Expert
Tel: [phone]
[e-mail]

[Anon Anon]

Great knowledge share..

What is the associated Techdoc number for this knowledge?

[Anon Anon]

Owl,

The customers I've been supporting seem far more satisfied with the Tuesday Tips style tech documents I've written. cool) They are living documents, can be accessed anonymously, and are indexed on Google, which makes them incredibly easy to find. Another added benefit is that I can keep them updated frequently to ensure they're as bulletproof as possible. I tend to edit them periodically when I learn more about the subject matter. What's great is MyCA communities allows me to update them instantaneously and get information to our customers' and colleagues' right away. I always solicit our customers' and colleagues' to post their feedback on the knowledge thread with any questions or concerns about what I've written, so that I can ensure these postings are helpful and live up to our customers' and colleagues' expectations. Unfortunately, the traditional knowledge doc system doesn't easily show me the number of views or whether or not the customers find it useful. Also they can not be anonymously accessed, docs can be difficult to find and posting new or updated information takes more time to accomplish. Is there a specific reason you're looking for this identical information within the more antiquated knowledge document format? If so, please let me know and I'll be glad to post one up for you.

If you feel it's more of an internal discussion, please feel free to follow up with me directly via email.

Thanks for the feedback.
Regards,

Chris Thomas
CA Technologies
Principal Support Engineer
Identity Manager Reporting Expert
Tel: [phone]
[e-mail]

[System]

Thanks for posting this great tip Chris!