The starting point is represented by a BEx query similar to the one described in the first airline report. A remote function module is created to load the query data. Based on it, a web service is generated. This web service will be used by Xcelsius to load the query data into an Excel spreadsheet.
Continue reading Loading Web Service BEx Query Data – SWF Airline Report
The business graphic chart gets updated every time the table showing the BEx query data changes its selection. Selected table rows represent chart series and table column names represent the chart categories. Continue reading Dynamic Business Graphics – Airline Report
Now that BEx query data is reflected into a context node, we can use this node to create dynamic tables to show its content. The first column of the dynamic webdynpro table will always represent the query Y axis, the rest of the columns representing the query X axis. Continue reading Dynamic Tables – Airline Report
Having a context node reflect the structure and content of a query data makes it easier to display it via webdynpro UI elements. InfoCube query calls are available via RRW3_GET_QUERY_VIEW_DATA function allowing advanced query control via run-time defined parameters. These parameters represent the query variables defined using BEx query designer. Continue reading Dynamic Context Nodes from BEx Queries – Airline Report
All Flight Routes webdynpro search dropdowns controls are dynamically populated at runtime based on some inner joins on table data. One may expect dropdown values contain direct data binding from inner tables just like it’s the case for webdynpro tables but this is not the case.
Continue reading Dynamic Dropdowns – Flight Routes
Create, populate and display an internal table at runtime without knowing in advance the table type. This can be achieved with the help of field symbols and data reference variables. Continue reading Dynamic Internal Tables – Custom Data Explorer
Custom data explorer is structured as one screen (screen number 100) with three subcreens: table search (150), table query where clauses (200), table data (300). Each screen is a view inside MVC. These views are totally independent of each other actions, they’re just coded to reflect model current data and dispatch controller events based on user commands. Data storage and data handling happens in model and controller. Continue reading View Elements â€“ Custom Data Explorer
Controller is responsible for updating model data based on events received from views/abap screens. It does this by defining the events it will listen to (the abap screen will dispatch these) and by registering method listeners for each controller event type. Continue reading Controller Overview â€“ Custom Data Explorer
Model acts as a central location to store data from ddic based on commands triggered by controller. It is crucial that only one instance of model exists through out the report execution ensuring all views and the controller itself access the same data. Because of this we don’t allow for a model instance to be created outside the model class. Continue reading Model Overview – Custom Data Explorer