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 the Semantic 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).

The Conceptual Analytics Engine does support multi-tenancy. This means that it can support multiple brokers instead of one in a concurrent manner. This feature is enabled via the Harvester component which partitions accordingly the information space in the Semantic KB in broker-specific fragments. Each broker-specific fragment is further separated into normal and historical sub-fragments. In this way, an analysis functionality for a certain broker can be operated over the suitable broker-specific fragment such that, in the end, multiple tenants/brokers can be supported.

Apart from API methods that directly map to the core KPI analysis functionality offered, also auxiliary/utility methods are also offered to better facilitate the analysis and visualisation tasks of the Hybrid Business Dashboard. In overall, the following functionality is offered by the Conceptual Analytics Engine component:

• KPI Measurement: the capability to measure the performance of a BPaaS is offered either for the current moment or across a certain time period. The measurement can be across all customers of the broker that have purchased the corresponding BPaaS or for a certain customer. The measurement can be performed either via the KPI name, for fixed KPIs originally defined for the BPaaS at hand, or via the specification of a KPI metric (for a more creative exploration of the possible metric space).
• KPI Drill-Down: this offered capability enables to perform root-cause analysis for the violation of a top KPI. As soon as a top KPI is violated, the Hybrid Business Dashboard can call this functionality in order to check the status of the KPIs within the hierarchy of the top-level KPI violated. What happens in the background is that both the top-level KPI and its descendants are evaluated via the first type of functionality analysed in the previous bullet. The measurement results are then compared with the KPI thresholds to derive the chain of KPI violations that led to the top-level KPI violation.
• Retrieval of Raw Metric Information: this capability enables to obtain the information of which raw metrics can be exploited by the broker in its effort to produce a new KPI metric. Such raw metrics map to measurements that have been already collected from the BPaaS Execution Environment by the Harvester. These metrics are actually exploited in the production of the KPI metric hierarchy mapping to a new KPI metric that has to be evaluated by the broker via the invocation of the functionality in the 1st bullet. Thus, they participate in the formulas of the metrics involved in this KPI metric hierarchy.
• Tenant Information Retrieval: this capability enables the broker to obtain the list of tenants for which KPI measurements have been produced for a certain BPaaS. Such information can then be exploited, e.g., in order to perform KPI measurement and drill-down in a customer-specific manner.
• KPI Retrieval: could be argued that this capability is not needed to be offered as the Hybrid Business Dashboard already has the knowledge about which KPIs have been defined for a BPaaS inside the BPaaS Design Package. However, by considering the fact that some KPIs are defined later on by the BPaaS Evaluation Environment, this utility capability, in the end, enables to present to the broker all KPIs that have been defined for a BPaaS and have been incorporated in the corresponding BPaaS bundle definition.

Only the CloudSocket broker has been enabled to exploit such the Conceptual Analytics Engine with the rationale that the BPaaS Evaluation Environment is a facility offered only for this entity that enables it to assist it in the proper management of its BPaaSes. Of course, any CloudSocket enhanced implementation might also take the view of providing an analysis functionality also for the customer. In any case, we consider that only one role from the CloudSocket broker can be involved in the exploitation of the BPaaS Evaluation Environment which is the evaluation expert. This is due to the fact that both the Hybrid Business Dashboard as well as the requirements imposed by its underlying analysis functionality do not force the use of a more technical role. In the context of KPI analysis, this is in contrast to other frameworks which tightly couple the definition of KPIs with the underlying measurement/storage technology (e.g., database queries used for KPI evaluation). On the contrary, the Conceptual Analytics Engine does not impose such a requirement as it demands the use of the OWL-Q language, which is a high-level, implementation-independent language for the definition of KPIs. In this way, the evaluation expert needs just to learn this language in order to define new KPIs which comprise metrics that are specified in a quite user-intuitive and familiar way for the expert. In case that new KPIs are not needed to be specified, then the evaluation expert does not need to possess any special knowledge in order to exploit the analysis functionality offered which greatly eases his/her job.

This component could be easily replaced by another component developed by an organisation outside the CloudSocket consortium. Its integration will be easy as it is loosely coupled with just one from the rest of the BPaaS Evaluation Environment components, the Semantic KB and especially its Semantic KB Service which hides and abstracts away from any implementation details involved in the Semantic KB.

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 Conceptual Analytics Engine is a composite component offering KPI analysis capabilities, which is coloured in red in the overall BPaaS Evaluation Environment depicted in the figure below. As it can be seen, it is invoked by the Business Management Tool in order to execute the respective BPaaS analysis functionality. This invocation, in turn, leads to exploiting the content of the Semantic KB at the Data Layer in order to support the analysis functionality needed.

The final, internal 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

The component has been implemented purely in java. It depends on other external components / frameworks like Spring, swagger, jersey and sesame/open rdf. It also depends on an internal component developed in the context of this project, the owl-q one which enables the parsing of OWL-Q models into domain-specific objects as well as their writing. The following figure explicates the sole artefact generated mapping to this component as well as its dependencies on other artefacts (at a coarse-grained level to simplify the figure).

Maven has been exploited as the main build automation tool, prescribing how the component/artefact can be built and its main dependencies. Such a tool facilitates the building and automatic generation of this artefact for the different CloudSocket environments (development and production) and their configuration. A complete description of how such artefact building and generation can be performed for the different environments is given in the installation manual below.

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