Analysis Path Processing 
The main purpose of the core component (sap.apf.core) is to handle and process analysis paths. A path and its steps are created, accessed, and processed using the APF API. During path processing, the following tasks are executed going through all steps in the order of their positions in the analysis path:
Execute the OData requests of the steps
Supply the representation objects of the steps with the response data
Notify the application UI using a callback function
In addition, the path logic accumulates filters that are derived from selections made in representations, and applies those filters in subsequent OData requests.
An analysis path contains an ordered sequence of one or more analysis steps. Optionally, the first step of a path can be an initial step, that is, a step for which the category initial has been defined in the step object of the analytical content configuration file. An initial step cannot be deleted or moved to a different path position, that is, it always remains in the first position of a path. The role of the initial step is to provide a filter for the entire analysis.
A step is created using the APF API method createStep(<id>,<callback>). It is inserted in the end of the path. The first method parameter is a unique identifier, which refers to the configuration entity that defines the step. The second parameter supplies a callback function, which is called once after the step has been created and processed.
Path processing is triggered using the APF API method updatePath(<callback>). The callback function is called each time after a step has been processed.
Runtime Objects
The following runtime objects exist:
A step object consists of a request object and a binding object.
A request object defines an OData server request. It creates and processes the OData request, processes the response, and sends the response data to the corresponding step.
The binding object sends the response data to the selected representation object. A binding object associates a step with one or more representation objects and identifies and handles the representation object that is currently selected. The binding object also defines how the selected representation translates its selection into a filter object.
A representation object wraps a chart, a table, or any other representation of data. When the user switches the representation, a different representation object is selected and supplied with data.
The relation between the objects described above is depicted in the following figure:
Runtime Objects of a Path
Processing of Runtime Objects
The steps are processed in the order of their positions in the path. The first step is processed first. The filter resulting from the first step is used to process the second step, and so on.
To describe the processing of an analysis path in more details, the following variables are relevant:
Variable | Description |
|---|---|
S_1,..,S_n | Path of length n |
S_i | Step |
R_i | Request for step S_i |
B_i | Binding for step S_i |
RO_i_s | Selected representation object for step S_i |
F_i | Filter object associated to step S_i |
F_0 | Context filter of a path. This context filter is either empty or it is the filter set by the APF API method setContext(<filter>). This filter defines the OData filter for request R_1 of step S_1. |
The processing of step S_i begins with requesting the filter F_(i-1) of the previous step. Note that for step S_1, this is the context filter F_0.
Step S_i is further processed by sending an OData request R_i to the server. The filter expression of request R_i is defined by the previous filter F_(i-1).
When request R_i returns successfully, it sends its response data to the selected representation object RO_i_s. This representation object then creates its own filter based on this data and its own UI selections. This filter can be requested by the subsequent step.
The filter is defined as a conjunctive accumulation of the previous filter F_(i-1) and the filter defined by the selected representation object (RO_i_s). The filter F_i is used for processing step S_(i+1).
When the processing of step S_i is completed, the logic executes the callback function that is passed as a parameter to method updatePath().
When a request returns a failure, the putMessage() and its registered callback method are executed and the path processing eventually stops.