Context and Problem
...
0 - Initially, the data related to the report is stored in the dataverse (SQL DB) in an XML format and precisely, in a field [FomrXML] of the table [SystemForm].
...
3 - Because the new identifier is different from the identifier stored in the dataverse, the link is broken and displays an error message in the IFrame deployed in a form of the Power Apps.
| Info |
|---|
NB: How to redeploy the new link in the dataverse based on the update published in the PBI Service ? |
Here’s a list of limits and contraints to consider :
When we publish a report from the Power BI Desktop, the process will log a message which is only accessible to the Power BI Administrator.
When we publish a report from the Power BI Desktop, no event is triggered by the process and stored in the PBI Service.
When we publish or refresh, we cannot add Power BI alerts.
The refresh of a report is not enough to determine if there was a change from the Power BI Dekstop.
The Power Platform (Power Automate) does not provide a flow which would retrieve the events / behaviors generated by any processes in Power BI Service.
The Microsoft Fabric Platform does not provide a Power BI connector capable of connecting and retreiving data and metadata from the Power BI Service.
When the IFrame in Power Apps displays the error, no event is generated by the Power Platform (Apps) or no information is stored in the dataverse.
Even it’s not possible to catch the client error in the IFrame with a JavaScript deployed in the dataverse.
Solution
Because of the limitations mentioned above, we cannot start from the Power Platform and neither from Power BI. And, so, we need to build our solution based on a schedule and not an event.
Applicative Architecture
The application could be a listener or an executable triggered by a schedule. In Azure, we would mention an Azure Worker Role or an Azure Web Role.
...
4 - To enable the changes in the DB, the service published the table.
Software Architecture
...
1 - The service will retrieve the data «FormXML» stored in the DB of the dataverse, stored as a string in the Table «SystemForm».
2 - The service will retrieve the settings stored in a generic dataverse, used aas a data mapper : settings related to reports in PBI Service and settings related to reports stored in the dataverse (target).
3 - The service will create a proxy containg all the metadata related to the report, including the Guid of the form in which the PBI report is embedded.
4 - The service will get the metadata of PBI reports stored in a workspace or a group (naming convention of PBI Service).
5 - The service will compare to establish if a difference appears between the both configuration.
6 - If a difference is found, then the service will update the environment (target) with the metadata coming from the PBI Service.
7 - Finally, the process will be logged in the environment of configuration (generic environment) : sucess or failure.
| Info |
|---|
The service is an executable developed in .NET Core 6.0. |
Limitations and recommendations
No redundancy has been implemented in order to garantee that the system keeps working.
No replication has been implemented as well, involving copies of data or systems across multiple locations.