Conceptual Analytics Engine
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.
| Type of ownership | Creation |
| Original tool | New component developed in the context of this project |
| Planned OS license | Mozilla Public Licence 2.0. |
| Reference community | ADOxx Community. |
Consist of
- Conceptual Analytics Service (REST API exposing all core functionalities)
Depends on
- Semantic KB
Component responsible
| Developer | Company | |
|---|---|---|
| Kyriakos Kritikos | kritikos@ics.forth.gr | FORTH |
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 architecture 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.
 Architecture of the Conceptual Analytics Engine. |
Installation Manual
The component has been implemented purely in java. It depends on other external components / frameworks like Spring, swagger, jersey and sesame/rdf4j. 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).
 Artifact dependencies for the Conceptual Analytics Engine. |
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:
- Download source code from https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/evaluation_skb/repository/archive.tar?ref=master
- Unzip code with tar (or any other tool)
- Go to the root directory of the installed code
- Change the configuration file to provide the right access information for the Virtuoso Triple Store (https://virtuoso.openlinksw.com/)
- Run:
mvn clean install
and then:mvn war:war
- Move the war file to the webapps directory of tomcat and start tomcat, if not yet started
- Test installation by entering in your browser the following URL: http://localhost:8080/evaluation/
Production
The same instructions as above hold for this component
Test Cases
You can run test cases directly from the URL (http://localhost:8080/evaluation in your development environment) 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 "MeanAvailabilityKPI". Then, he/she can browse the methods of the API and click on the one named as "evaluateKPI". 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 "MeanAvailabilityKPI", the field of "brokerId" with the value of "bwcon" and the field of "bundleId" with the value of "SendInvoiceSaaSEurope". Then he/she can press the "Try it out!" button.
Finally, he/she will be able to see the respective curl command issued, the request URL, the corresponding results, as well as the response status and headers as indicated in the following figure: 
User Manual
API Specification
The reader should refer to the swagger-based API web page (http://localhost:8080/evaluation for a local installation or http://134.60.64.222:8080/evaluation for a remote existing installation) for browsing an on-line documentation with the capability to execute the API methods. In the following, the API methods of the Conceptual Analytics Service are analysed below:
evaluateKPI
This method enables to produce current and historical measurements for a certain KPI in the context of a specific BPaaS. As multi-tenancy is supported, the id of the broker needs to be specified in order to set the appropriate context for the method execution.
POST ca/evaluateKPI/{brokerId}
The expected input format is multipart/form-data. The following input parameters are expected:
- brokerId: denotes the id of the broker for which the evaluation needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
- bundleId: denotes the id of the BPaaS bundle for which the evaluation needs to be performed (optional)
- kpiName: denotes the name of the KPI to be evaluated (obligatory)
- kpiPeriod: denotes the (history) period of the evaluation. If this parameter is specified, then a set of KPI evaluation values and not just one can be returned matching the respective period provided. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)
- tenant: denotes the id of 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
- 404 -- The resource requested (i.e., the broker) was not found
- 406 -- The format requested for 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": [
{
"bundleId": "SendInvoiceSaaSEurope",
"value": "0.8010364041400798e0",
"instant": "2016-01-27T11:43:38.588Z"
}
]
}
evaluateMetric
This method enables the production of current and historic measurements for a KPI metric. It is similar to the "evaluateKPI" method but requires from the broker to appropriately specify the KPI metric in two different ways: (a) the metric and its context are passed as input parameters; (b) the name of an existing metric is provided:
POST ca/evaluateMetric/{brokerId}
The expected input format is multipart/form-data. The following input parameters are expected:
- brokerId: denotes the id of the broker for which the evaluation needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
- metricName: denotes the name of the existing metric for which the evaluation needs to be performed. This parameter is optional as there is an alternative way of determining the KPI metric to be evaluated (optional)
- metric: provides a CompositeMetric specification in OWL-Q for the metric to be evaluated. As a composite metric is associated to a specific metric context, the "metricContext" parameter does not need to be provided in this case (optional)
- metricContext: provides the MetricContext specification in OWL-Q for the metric to be evaluated. This metric context includes scheduling and window information for the metric at hand. This parameter is optional and might be provided in case that we need to modify the context of an existing metric (whose name is specified in the "metricName" parameter) temporarily for the context of this evaluation (optional)
- bundleId: denotes the id of the BPaaS bundle for which the evaluation needs to be performed (optional)
- kpiPeriod: denotes the (history) period of the evaluation. If this parameter is specified, then a set of metric measurement values and not just one can be returned matching the respective period provided. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)
- tenant: denotes the id of the tenant for which the identified metric can be evaluated. In this way, the metric measurements are only produced for this tenant and not across all tenants that have purchased the respective BPaaS (optional)
- maxRows: denotes the maximum number of metric measurements 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
- 404 -- The resource requested (i.e., the broker) was not found
- 406 -- The format requested for 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": [
{
"bundleId": "SendInvoiceSaaSEurope",
"value": "0.8010364041400798e0",
"instant": "2016-01-27T11:43:38.588Z"
}
]
}
kpiDrillDown
This method enables to perform a drill-down over a certain KPI for a specific BPaaS (again under the context of a specific broker). The drill-down results can be provided in a tree-based form in both JSON & XML formats, where each result contains information which is equivalent to that of the aforementioned methods:
POST ca/kpiDrillDown/{brokerId}
The expected input format is multipart/form-data. The following input parameters are expected:
- brokerId: denotes the id of the broker for which the KPI drill-down needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
- bundleId: denotes the id of the BPaaS bundle for which the KPI drill-down needs to be performed (optional)
- kpiName: denotes the name of the KPI for which the KPI drill-down needs to be performed (obligatory)
- kpiPeriod: denotes the (history) period of the drill-down. If this parameter is specified, then a set of drill-down values and not just one can be returned matching the respective period provided. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)
- tenant: denotes the id of the tenant for which the identified KPI needs to be drilled down. In this way, the respective KPI measurements and their drill-down are only produced for this tenant and not across all tenants that have purchased the respective BPaaS (optional)
- maxRows: denotes the maximum number of drill-down 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
- 404 -- The resource requested (i.e., the broker) was not found
- 406 -- The format requested for 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": [
{
"bundleId": "SendInvoiceSaaSEurope",
"kpi": "MeanKPIAvailability",
"value": "0.8010364041400798e0",
"instant": "2016-01-27T11:43:38.588Z",
"subRows": [
{
"bundleId": "SendInvoiceSaaSEurope",
"kpi": "MeanIaaSKPIAvailability",
"value": "0.8526374638629035e0",
"instant": "2016-01-27T11:43:37.466Z",
"subRows": []
}
]
}
]
}
kpiHistory
This method enables to query the historical measurements for a certain KPI in the context of a specific BPaaS. As multi-tenancy is supported, the id of the broker needs to be specified in order to set the appropriate context for the method execution. The results are equivalent to those returned by the "evaluateKPI" method. Please note that the content of the history fragment of the broker concerned needs to be populated via the "evaluateKPI" method in order to be able to obtain any result.
POST ca/kpiHistory/{brokerId}
The expected input format is multipart/form-data. The following input parameters are expected:
- brokerId: denotes the id of the broker for which the historical query over the broker-specific historical fragment needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
- bundleId: denotes the id of the BPaaS bundle for which the historical query needs to be performed (optional)
- kpiName: denotes the name of the KPI for which historical measurements need to be obtained (obligatory)
- kpiPeriod: denotes the (history) period. If this parameter is specified, then a set of KPI historical measurement values and not just one can be returned matching the respective period provided. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)
- tenant: denotes the id of the tenant for which the KPI history query can be evaluated. In this way, the required historical KPI values to be retrieved map only to this tenant and do not cross all tenants that have purchased the respective BPaaS (optional)
- maxRows: denotes the maximum number of KPI historical measurement 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
- 404 -- The resource requested (i.e., the broker) was not found
- 406 -- The format requested for 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": [
{
"bundleId": "SendInvoiceSaaSEurope",
"value": "0.8010364041400798e0",
"instant": "2016-01-27T11:43:38.588Z"
}
]
}
kpiQuery
This method enables to retrieve the list of KPIs that have been defined in the context of a specific broker. When the id of the BPaaS is also provided, then the KPI list is filtered to include only those KPIs that have been specified for the BPaaS.
POST ca/kpiQuery/{brokerId}
The expected input format is multipart/form-data. The following input parameters are expected:
- brokerId: denotes the id of the broker for which the KPI query needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
- bundleId: denotes the id of the BPaaS bundle for which the defined KPIs need to be retrieved - as stated, if not given, then this maps to obtaining all the KPIs that have been defined for all BPaaSes of a certain broker (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
- 404 -- The resource requested (i.e., the broker) was not found
- 406 -- The format requested for 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:
[
{
"name": "MeanIaaSAvailabilityKPI",
"description": null,
"abbreviation": null,
"synonym": null,
"constraintContext": null,
"obliged": null,
"firstArgument": {
"name": "MeanIaaSAvailability",
"description": null,
"abbreviation": null,
"synonym": null,
"scale": null,
"monotonicity": "POSITIVE",
"unit": null,
"valueType": null,
"aggregationType": null,
"measuredObject": "http://www.cloudsocket.eu/evaluation#IaaS1",
"attribute": null,
"level": 2,
"metricContext": {
"name": "MC1",
"description": null,
"abbreviation": null,
"synonym": null,
"window": null,
"schedule": {
"name": "OneDaySchedule",
"description": null,
"abbreviation": null,
"synonym": null,
"interval": 1,
"repetition": 0,
"scheduleType": "FIXED_RATE",
"timeUnit": {
"name": "Day",
"description": null,
"abbreviation": null,
"synonym": null,
"scale": null,
"monotonicity": null,
"quantity": null,
"quantityKind": null,
"unitType": "SINGLE",
"unitMappings": null,
"uri": "http://www.cloudsocket.eu/evaluation#Day"
},
"uri": "http://www.cloudsocket.eu/evaluation#OneDaySchedule"
},
"uri": "http://www.cloudsocket.eu/evaluation#MC1"
},
"formula": {
"name": "mean_iaas_availability",
"description": null,
"abbreviation": null,
"synonym": null,
"function": "MEAN",
"functionURI": null,
"argumentList": [
{
"RawMetric": {
"name": "IaaSAvailability",
"description": null,
"abbreviation": null,
"synonym": null,
"scale": null,
"monotonicity": "POSITIVE",
"unit": null,
"valueType": null,
"aggregationType": null,
"measuredObject": "http://www.cloudsocket.eu/evaluation#IaaS1",
"attribute": null,
"level": 1,
"metricContext": null,
"sensor": null,
"measurementDirective": null,
"manual": true,
"uri": "http://www.cloudsocket.eu/metrics/IaaSAvailability"
}
}
],
"uri": "http://www.cloudsocket.eu/formulas/mean_iaas_availability"
},
"metricList": [
{
"RawMetric": {
"name": "IaaSAvailability",
"description": null,
"abbreviation": null,
"synonym": null,
"scale": null,
"monotonicity": "POSITIVE",
"unit": null,
"valueType": null,
"aggregationType": null,
"measuredObject": "http://www.cloudsocket.eu/evaluation#IaaS1",
"attribute": null,
"level": 1,
"metricContext": null,
"sensor": null,
"measurementDirective": null,
"manual": true,
"uri": "http://www.cloudsocket.eu/metrics/IaaSAvailability"
}
}
],
"uri": "http://www.cloudsocket.eu/metrics/MeanIaaSAvailability"
},
"comparisonOperator": "GREATER_EQUAL_THAN",
"optimisationOperator": null,
"secondArgument": 0.9,
"warningThreshold": 0.8,
"validity": null,
"childKPIs": null,
"bundleURI": "http://www.cloudsocket.eu/evaluation/bwcon#SendInvoice",
"qualifyingCondition": false,
"uri": "http://www.cloudsocket.eu/kpis/MeanIaaSAvailabilityKPI"
}
]
kpiTenantQuery
This method enables to retrieve the list of tenants/customers for which there exist measurements for a certain KPI for the BPaaSes that they have purchased in the context of a specific broker. When the id of the BPaaS is also provided, then the tenant list is filtered to include only those tenants which have purchased the respective BPaaS.
POST ca/kpiTenantQuery/{brokerId}
The expected input format is multipart/form-data. The following input parameters are expected:
- brokerId: denotes the id of the broker for which the KPI tenant query needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
- bundleId: denotes the id of the BPaaS bundle that must have been purchased by the tenants to be returned (optional)
- kpiName: denotes the name of the KPI for which measurements should have been produced for the tenants to be returned (obligatory)
- kpiPeriod: denotes the historical period for which KPI measurements should have been produced. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (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
- 404 -- The resource requested (i.e., the broker) was not found
- 406 -- The format requested for the method output is not supported
- 500 -- Internal server error exception
The output can be in both json and xml formats. A sample for a json output is given below:
[
{
3c1ab6ac-6a7e-4791-8c16-f8f6d400231c
}
]
ldQuery
This method enables to pose an arbitrary query over the broker-specific fragment of the Semantic KB. Such a query should only be posed by an expert on semantic technologies which should have an appropriate knowledge of SPARQL as well as of the Evaluation and OWL-Q (KPI Extension) ontologies that have been developed in the context of WP3 in CloudSocket.
POST ca/ldQuery/{brokerId}
The expected input format is multipart/form-data. The following input parameters are expected:
- brokerId: denotes the id of the broker for which the KPI tenant query needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
- query: signifies the SPARQL query to be posed over the Semantic KB (obligatory)
- timeout: specifies the maximum amount time for waiting (in milliseconds) until a response can be obtained from the Semantic KB. A value of 0, which is the default, denotes that the broker can wait indefinitely (optional)
- maxRows: denotes the maximum number of rows to be produced by the query. A value of 0, which is the default, denotes that all rows should be returned. As SPARQL has the LIMIT construct, the broker should be careful of not specifying SPARQL queries including this construct that are evaluated via this method for which has a positive value for this parameter has been provided. In this latter case, the outcome would depend on the correlation between the values for the LIMIT construct and this parameter, i.e., if LIMIT is X and parameter value is Y, >= X, then X values will be returned. If Y < X, then Y values will be returned. In other words, the lowest from the values provided will prevail (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
- 404 -- The resource requested (i.e., the broker) was not found
- 406 -- The format requested for the method output is not supported
The output can be in "application/sparql-results+xml", "application/sparql-results+json", "text/csv" and "text/tab-separated-values". A sample for the "application/sparql-results+json" output is given below:
{ "head": { "link": [], "vars": ["bpaas", "id"] },
"results": { "distinct": false, "ordered": true, "bindings": [
{ "bpaas": { "type": "uri", "value": "http://www.cloudsocket.eu/evaluation#BPaaS_bwcon_SendInvoiceSaaSEurope" } , "id": { "type": "typed-literal", "datatype": "http://www.w3.org/2001/XMLSchema#string", "value": "SendInvoiceSaaSEurope" }},
{ "bpaas": { "type": "uri", "value": "http://www.cloudsocket.eu/evaluation#BPaaS_bwcon_SendInvoiceSaaSWorldwide" } , "id": { "type": "typed-literal", "datatype": "http://www.w3.org/2001/XMLSchema#string", "value": "SendInvoiceSaaSWorldwide" }},
{ "bpaas": { "type": "uri", "value": "http://www.cloudsocket.eu/evaluation#BPaaS_bwcon_SendInvoiceIaaSEurope" } , "id": { "type": "typed-literal", "datatype": "http://www.w3.org/2001/XMLSchema#string", "value": "SendInvoiceIaaSEurope" }} ] } }
rawMetricQuery
This method enables to obtain all the raw metrics that have been defined in OWL-Q for a certain broker. In case that a respective BPaaS is also determined, then the raw metric list is filtered to contain only those raw metrics that have been defined for this BPaaS. As has been already stated, this method is a utility one which enables the broker to construct KPI metric specifications out of those returned by this method in order to subsequently make evaluation queries for those KPI metrics via the "evaluateMetric" method and thus better explore the possible KPI metric space.
POST ca/rawMetricQuery/{brokerId}
The expected input format is multipart/form-data. The following input parameters are expected:
- brokerId: denotes the id of the broker for which the raw metric query needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
- bundleId: denotes the id of the BPaaS bundle in order to restrain the raw metric list to be obtained to contain only those metrics that have been defined for this bundle (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
- 404 -- The resource requested (i.e., the broker) was not found
The output can be in XML or JSON form. A sample of an output in JSON form is given below:
[
{
"name": "CycleTime",
"description": null,
"abbreviation": null,
"synonym": null,
"scale": null,
"monotonicity": "NEGATIVE",
"unit": null,
"valueType": null,
"aggregationType": null,
"measuredObject": "http://www.cloudsocket.eu/evaluation#Workflow_SendInvoice",
"attribute": null,
"level": 1,
"metricContext": null,
"sensor": null,
"measurementDirective": null,
"manual": true,
"uri": "http://www.cloudsocket.eu/metrics/CycleTime"
},
{
"name": "EmailNotSent",
"description": null,
"abbreviation": null,
"synonym": null,
"scale": null,
"monotonicity": "NEGATIVE",
"unit": null,
"valueType": null,
"aggregationType": null,
"measuredObject": "http://www.cloudsocket.eu/evaluation#Workflow_SendInvoice",
"attribute": null,
"level": 1,
"metricContext": null,
"sensor": null,
"measurementDirective": null,
"manual": true,
"uri": "http://www.cloudsocket.eu/metrics/EmailNotSent"
},
{
"name": "EmailSent",
"description": null,
"abbreviation": null,
"synonym": null,
"scale": null,
"monotonicity": "POSITIVE",
"unit": null,
"valueType": null,
"aggregationType": null,
"measuredObject": "http://www.cloudsocket.eu/evaluation#Workflow_SendInvoice",
"attribute": null,
"level": 1,
"metricContext": null,
"sensor": null,
"measurementDirective": null,
"manual": true,
"uri": "http://www.cloudsocket.eu/metrics/EmailSent"
},
{
"name": "SaaSAvailability",
"description": null,
"abbreviation": null,
"synonym": null,
"scale": null,
"monotonicity": "POSITIVE",
"unit": null,
"valueType": null,
"aggregationType": null,
"measuredObject": "http://www.cloudsocket.eu/evaluation#ExternalSaaS1",
"attribute": null,
"level": 1,
"metricContext": null,
"sensor": null,
"measurementDirective": null,
"manual": true,
"uri": "http://www.cloudsocket.eu/metrics/SaaSAvailability"
},
{
"name": "CustomerSatisfaction",
"description": null,
"abbreviation": null,
"synonym": null,
"scale": null,
"monotonicity": "POSITIVE",
"unit": null,
"valueType": null,
"aggregationType": null,
"measuredObject": "http://www.cloudsocket.eu/evaluation#Workflow_SendInvoice",
"attribute": null,
"level": 1,
"metricContext": null,
"sensor": null,
"measurementDirective": null,
"manual": true,
"uri": "http://www.cloudsocket.eu/metrics/CustomerSatisfaction"
},
{
"name": "IaaSAvailability",
"description": null,
"abbreviation": null,
"synonym": null,
"scale": null,
"monotonicity": "POSITIVE",
"unit": null,
"valueType": null,
"aggregationType": null,
"measuredObject": "http://www.cloudsocket.eu/evaluation#IaaS1",
"attribute": null,
"level": 1,
"metricContext": null,
"sensor": null,
"measurementDirective": null,
"manual": true,
"uri": "http://www.cloudsocket.eu/metrics/IaaSAvailability"
}
]
Handbook
Funding Partners
Horizon 2020