Database queries are defined by multiple objects in arcplan. Apart from the object with the query itself, other objects define the columns, rows and filter settings. In so doing, they are able to influence themselves, as well (performance arrows, selection-based filters…)
Linking the objects for a database query is defined by the connection of the objects in the connection mode. Arrows are drawn. Even though the objects are frequently set up together, the place or the order of the objects is irrelevant for the function. These objects may even be located on various reporting levels.
Time and again, there are connections between multiple levels in reports, where the filter objects are located on document level and the actual data query is located on one of the background levels due to further editing. Moreover, it is quite frequent if objects are moved and rearranged in the course of (further) developing the report. In this context, not all related objects are moved together all the time.
This distribution of the objects across the report is technically possible and does not entail any functional disadvantages at first, either, but should nevertheless be avoided.
The reason is primarily technical. Even though the connection works, the connecting arrows over multiple levels are not displayed in the connection view upon the activated display of the arrows.
This is demonstrated in the following screenshot:
Here, a data query is located on level 1. The data query is here apparently defined only by the currency filter ([<Filter_Currency>]) apart from the row and column object. However, this is not correct in this case, as the two other filters ([<Filter_Period>] and [<Filter_Customer>]) are taken into account in the query, as well, namely on the reporting level; this, however, is not displayed. Deactivating the display of arrows in the connection mode, as shown in the following screenshot, will make this visible.
Here, all five objects defining the data query are now displayed by the little red arrow in the lower right object corner. This, however, can only be recognized if the objects are in the visible field. If this is not the case, there is the danger that one wrongly assumes that there are only three objects relevant to the query, and that thus, the report is misunderstood.
In order to avoid this, the display of the number of connected objects (green circle 1, bottom right) and also of the arrows in the connection window (green circle 2, top right) are good functions in order to recognize whether there are any further objects relevant to the query on other levels, i.e. which objects are relevant. The display of the number of related objects shows the number of objects connected to the selected object. This applies both to the database connection and to the formula reference. In case of a data query, it shows the number of all objects relevant to the query. If they exceed the number of visible objects, and if arrows are not visible in arrow mode, then objects relevant to the query are located on other levels. The arrows in the connection window (green circle, top right) are only used in order to find these. Thus, all related objects are highlighted, while the display focuses on the respective object.
All this is quite long-winded and very time-consuming. As in case of doubt, this needs to be done for every data base query in order to ensure that nothing is missed.
Thus, we see that connecting arrows across multiple levels work technically, but severely impede the overview. While it is possible, it is quite long-winded to recognize the exact functionality and the correlations in these cases. While this is still manageable in the development phase with one developer in case of smaller reports, it may already cause problems in case of larger reports.
If one adjusts the reports after a few months by oneself, or if a colleague takes over the report, it may become very time-consuming and prone to errors.
Thus, connecting arrows across multiple levels should be avoided. Basically, in the best case, all connected objects should always be positioned in close proximity to the data query and be designed with uniform layout. This should also be part of the model approach taken by everyone. The time invested at the outset in this context is quickly gained if it becomes necessary to understand the report again in the course of adjustments/developments or transfers.
Do you want to replace the IoT core with a multi-cloud solution and utilise the benefits of other IoT services from Azure or Amazon Web Services? Then get in touch with us and we will support you in the implementation with our expertise and the b.telligent partner network.
Domain Lead Insights & Information Design
SAP data integration is complex: performance issues, storage limitations, and third-party system integration pose significant challenges for businesses. With our flexible framework, you can create a powerful and scalable solution that seamlessly complements SAP BW and S/4HANA—efficient, future-proof, and cost-effective.
With the new function REPLACEEXPRESSION, arcplan 7 affords the possibility to influence the automatically generated SQL and MDX statement. This has the benefit that a design can continue to be made with “arrows” and that one is not limited to formulas. Currently, only simple adjustments of the query are possible with this tool; however, there is a large impact on the resulting possibilities.
With the Q2 2023 updated titled "New optimized story experience - unified strories and applications", SAP analytics cloud offers users new ways to develop reports and dashboards even more flexibly and easily in an integrated design enviroment. We'll showyou which new features theupdate provides and how it supports you in creating reports,
No previous post
No next post
