Jelle Uenk
Read all my blogsReports created on your test tenant are moved to the production system via the transport tool. This works like a charm, all related Data Source joins, Key Figures and created extension fields are moved automatically as dependencies – nice!
In some cases, it’s a little less smooth as hoped for. E.g. when users complain that the report throws errors, or when you look at the transport log mentioning activation errors.
Transport log and report error
Often the errors are already visible in the transport log, see e.g. below screenshot – the reports have been transported and are visible in the target system though. First action usually is to re-transport the report and dependent objects, which however often does not solve the issue on the production tenant.
In this blog I describe how you can fix such issues.
As an example, we had a report on our test tenant, using the standard datasource Ticket [CRMSRQHB] to which a few extension fields (Key User Tool fields) were added, and moved to PRD.
When running the report on the production tenant, an error message is displayed.
The report wants to show a characteristic (Extension field) which was not generated correctly in the underlying Data Source, and therefore will not run successfully.
So further analysis is needed, we need to find which field is linked to above technical characteristic name /1AN/CA50DC8A028C55, and apply the necessary corrections.
Step 1 – Analyse which datasource is referenced by the report
Back on the test tenant, check the datasource(s) linked to this report:
If the datasource ID starts with a Z, you have a custom datasource (cloud-, combined or joined datasource).
Below steps are identical for these custom data sources, however instead of a single datasource you might need to check the combined/joined data sources individually.
Step 2 – Find the missing field in the datasource (on the test tenant)
In the menu Business Analytics -> Design Data Sources, look up the documentation for this datasource using the Documentation button.
Search for the characteristic triggering the error: /1AN/CA50DC8A028C255, which shows us that our extension field “Batch Number” is causing the issue.
The field is referenced in the report and datasource on our test tenant, and in the report on the production system. It looks like the used data source on the production hasn’t stored this field correctly during transport.
Step 2a – Joined Data Sources
In case the report was based on a joined datasource, you can also use the Documentation button – it shows the fields and mentions the underlying datasource where it is stored. This usually also gives enough information in which object the key field is used (e.g. Ticket or Sales Order Item).
Subsequently, look up the datasource itself.
Step 3 – Correct the field-to-datasource assignment on the production tenant
Use adaption mode to update the field-to-datasource assignment. In our example the extension field “Batch Number” is part of the ticket object, so we view a ticket in adaption mode, and edit the field properties for this field.
The system has recognized the field – datasource(s) link needs to be corrected, and offers a Repair button.
Click the Repair button, and after a few seconds the fix should be ready, no subsequent save needed, we can leave the adaption mode.
Repeat the above steps for any other Key user tool fields missing, after which the report runs without errors.
Receive our weekly blog by email?
Subscribe here:
