Summary

The Conceptual Analytics Engine is a composite component in the BPaaS Evaluation Environment which is responsible for performing two types of KPI analysis over the Semantic Knowledge Base (Semantic KB) at the Data Layer of this environment's architecture. This component is invoked by the Hybrid Dashboard to execute the required type of analysis and visualise the respective analysis results according to the best possible visualisation metaphor. The two types of KPI analysis include:

• KPI metric measurement: Derives the current and historical measurements for a KPI metric enabling their evaluation against the corresponding KPI threshold by the Hybrid Business Dashboard. This type of analysis is offered in two forms: (a) on-the-fly derivation of the KPI measurements based on measurement information of raw metrics derived from the BPaaS Execution Environment; (b) querying over a historical fragment of theSemantic KB to obtain the measurement history of the KPI. The first form is actually a facilitator of the second as it enables the broker to store the derived information in the historical fragment. The first form is also offered in terms of two variants: (a) KPI measurement: the measurement of the metric of an existing KPI is supported; (b) Metric measurement: measurement for metric specifications which do not necessarily map to KPIs. The second variant is ideal for exploring the possible metric space in order to enable the broker to come up with new KPIs for his/her BPaaSes. This has been deemed a necessity for KPI analysis environments as the determination of KPIs is not an easy task to perform which also requires some form of creativity that has to be supported by such an environment.
• KPI drill-down: Drills-down the measurement of a metric of a KPI to the whole KPI hierarchy. Via the checking of the corresponding thresholds of the KPIs involved in the hierarchy, this enables to perform root-cause analysis (for the KPI violation that has occurred at the top-level of the hierarchy).

In overall, the functionality exposed by the Conceptual Analytics Engine is the following:

• 1
• 2
• 3

The following table indicates the details of the component.

Consist of

• Conceptual Analytics Service (REST API exposing all core functionalities)

Depends on

• Semantic KB

Component responsible

Architecture Design

The final architecture of the Conceptual Analytics Engine, which is depicted below, comprises the following 6 main components:

• Conceptual Analytics Service: A REST service which encapsulates the whole functionality of the Conceptual Analytics Engine in the form of REST API methods. Depending on the respective API method invoked, different underlying components are executed by this service.
• Query Creator: this component is responsible for creating SPARQL queries which are then evaluated by the Conceptual Analytics Service over the Semantic KB. Such queries map to the core functionality of the Conceptual Analytics Engine, thus enabling to obtain measurements related to KPI assessment and drill-down. They also map to auxiliary/utility functionality which is also offered in the form of specific API methods of the Conceptual Analytics Service.
• Drill-Down Handler: this component is responsible for performing the drill-down of KPIs. As a KPI forms a hierarchy with its underlying KPI descendants, the facilities of the Query Creator are exploited in order to construct the KPI measurement queries for all the KPIs involved in the KPI hierarchy.
• KPI Handler: this component is responsible for obtaining the definition of KPIs and their corresponding metrics from the Semantic KB and offers the functionality of retrieving such information both to the Conceptual Analytics Service and the two main components underlying it. This means that there exist API methods which can be exploited in order to obtain the KPI information involved in the definition of a certain BPaaS.
• SPARQL Transformer: it is responsible for transforming the definition of a KPI metric into an SPARQL query which can be exploited in order to derive the measurements of that metric in a certain time period. It is solely exploited by the Query Creator component.
• Resource Accessor: it has the duty to retrieve information from external information sources, i.e., REST APIs or databases. It is called by the Query Creator in order to produce the appropriate input information (mapping to such external information source accessing) in metric formulas which is to be implanted in the query that has to be generated for a specific metric. This is due to the fact that metric formulas comprise input parameters, which can be metrics, constants or information generated from calling such external information sources.  

Installation Manual

Development

Currently, the following requirements hold for this component:

• Oracle's 1.7.x JDK or higher
• Apache tomcat 1.7 or higher
• Maven tool for code compilation and packaging

The installation procedure to be followed is the one given below:

1. Download source code from (to be completed)
2. Unzip code with tar (or any other tool)
3. Go to the root directory of the installed code
4. Run:

   mvn clean install
   

   and then:

   mvn war:war
   

5. Move the war file to the webapps directory of tomcat and start tomcat, if not yet started
6. Test installation by entering in your browser the following URL: http://localhost:8080/rest-test-swagger-0.0.1-SNAPSHOT/

Production

See instructions above

Test Cases

You can run test cases directly from the URL of the REST service due to the use of swagger (http://swagger.io) which enables the execution of the API method exposed by exploiting user input provided in a form-based manner. The following test cases are envisioned:

• Run a KPI evaluation query

Suppose that the user desires to obtain the most recent value for a KPI named as "Reliability". Then, he/she can browse the methods of the API and click on the one named as "kpiQuery". The following screenshot indicates the upper part of the description of the method when selected: Next, he/she can fill in the kpiName field with the value of "Reliability" and press the "Try it out!" button. He/she will be able to see the respective curl command issued and the request URL as indicated in the following figure. Finally, he/she can check the output produced along with the response status and headers by scrolling a little bit more on the screen as indicated in the next figure:

User Manual

API Specification

The reader should refer to the API web page of swagger for browsing an on-line documentation with the capability to execute the API methods. In the following, the API methods of the Conceptual Analytics REST Service are analyzed below:

kpiQuery

This method enables the posing of semantic queries over the underlying Semantic KnowledgeBase in order to evaluate the respective KPI involved:

POST skb/kpiQuery

The expected input format is multipart/form-data. The following input parameters are expected:

• kpiName: denotes the name of the KPI to be evaluated (obligatory)
• kpiPeriod: denotes the evaluation period such that a set of KPI evaluation values and not just one can be returned matching this period (optional)
• tenant: denotes the tenant for which the KPI can be evaluated. In this way, the KPI is assessed only for this tenant and not across all tenants that have purchased the respective BPaaS (optional)
• maxRows: denotes the maximum number of KPI values to return. Default value is 0 indicating that all possible values can be returned (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

• 200 -- The method execution was successful
• 400 -- Wrong parameter values have been provided
• 406 -- The format requested to map to the method output is not supported

The output can be in both json and xml formats. A sample for a json output is given below:

{
  "results": [
    {
      "value": "0.8010364041400798e0",
      "instant": "2016-01-27T11:43:38.588Z"
    }
  ]
}

Handbook