In my last post I went over the management pack synchronization process that brings over MP’s from Service Manager and how those MP’s drive the structure, data, and reports for data warehouse and reporting. Once those MP’s are synchronized between Service Manager and the data warehouse, we need to get the data and/or reports deployed for user consumption.
Sequentially, deployment works in this way (see figure below):
- Once all identified MP’s are synchronized with DW, MP sync triggers the report deployment workflow
- Since DWStagingandConfig is the final destination of the MP’s that have been synchronized, the deployment workflow will query the DWStagingandConfig database for any new or changed reports to deploy or any reports to remove.
- The deployment workflow will then publish any new or updated reports to the SQL Server Reporting Services server via the SSRS webservices.
- SSRS then stores the reports and appropriate metadata.
- Schema deployment workflow is triggered by MP sync
- Once again, information that is driving schema changes is retrieved from the DWStagingandConfig database based off the newly synchronized MP’s that are driving the changes.
- The schema changes are then deployed to the DWRepository.
- Any necessary changes to Extract, Transform, and Load modules are made to the DWStagingandConfig database
MP’s that contain only Service Manager specific information will not trigger the deployment activities to execute. They will only be triggered for new DW/Reporting specific elements. In my next post I will dive into what is Extract, Transform, and Load (ETL), its benefits, and why deployment makes changes to it.
