Custom Reporting Metrics, Reports, and Dashboard Guide€¦ · 1. RevisionHistory...

Kony Fabric

Reporting and Analytics

Custom Reporting – Metrics,

Reports, and Dashboard Guide

Release V8 SP4Document Relevance and Accuracy

This document is considered relevant to the Release stated on this title page and the document version stated on the

Revision History page. Remember to always view and download the latest document version relevant to the software

release you are using.

© 2019 by Kony, Inc. All rights reserved 1 of 149

Custom Reporting – Metrics, Reports and Dashboard GuideVersion1.4

Copyright © 2013 Kony, Inc.

All rights reserved.

February, 2019

This document contains information proprietary to Kony, Inc., is bound by the Kony license

agreements, andmay not be used except in the context of understanding the use andmethods of

Kony, Inc., software without prior, express, written permission. Kony, Empowering Everywhere, Kony

Fabric, KonyNitro, and Kony Visualizer are trademarks of Kony, Inc. MobileFabric is a registered

trademark of Kony, Inc. Microsoft, theMicrosoft logo, Internet Explorer, Windows, andWindowsVista

are registered trademarks of Microsoft Corporation. Apple, the Apple logo, iTunes, iPhone, iPad, OS

X, Objective-C, Safari, Apple Pay, AppleWatch, and Xcode are trademarks or registered trademarks

of Apple, Inc. Google, the Google logo, Android, and the Android logo are registered trademarks of

Google, Inc. Chrome is a trademark of Google, Inc. BlackBerry, PlayBook, Research inMotion, and

RIM are registered trademarks of BlackBerry. SAP® and SAP® Business Suite® are registered

trademarks of SAP SE in Germany and in several other countries. All other terms, trademarks, or

servicemarksmentioned in this document have been capitalized and are to be considered the

property of their respective owners.


1. Revision History Custom Reporting – Metrics, Reports and Dashboard GuideVersion1.4

1. Revision History

Date DocumentVersion

Description of Modifications/Release

02/04/2019 1.4 Document updated for V8 SP4



09/19/2017 1.0 Document published for V8GA



Table of Contents

1. Revision History 3

2. Custom Metrics 7

2.1 Prerequisites 8

2.2 Defining CustomMetrics in KonyCloud 9

2.3 Rules for CustomMetrics Data Types 12

3. Implementing Custom Metrics 14

3.1 Implementing CustomMetrics in Kony Visualizer 15

3.2 Implementing CustomMetrics in Kony Server 18

4. Custom Metrics APIs for Kony Server 26

4.1 com.konylabs.middleware.metrics.KonyCustomMetricsDataSet 26

4.1.1 setMetricsString 27

4.1.2 setMetricsBoolean 27

4.1.3 setMetricsLong 28

4.1.4 setMetricsDouble 28

4.1.5 setMetricsDate 29



4.1.8 setMetricsTimestamp 31

4.1.9 setMetricsTimestamp 33

4.1.10 getMetricsMap 34



4.1.11 get 34

4.1.12 Remove 35

4.1.13 toString 35

4.2 com.konylabs.middleware.metrics.KonyCustomMetrics 36

4.2.1 addCustomMetrics 36

4.2.2 getCustomMetrics 36

4.2.3 getCustomMetricsJSON 37

4.2.4 clearCustomMetrics 37

4.3 MetricsException 38

5. Custom Reports 39

5.1 Creating a Report (Table, Chart, and Crosstab) 40

5.1.1 DataSets Dictionary 58

5.1.2 Table Report User Interface 100

5.1.3 Chart Report User Interface 102

5.1.4 Crosstab Report User Interface 105

5.2 Saving CustomReports and AdHocViews 107

5.3 Running CustomReports 109

5.4 Editing Ad HocViews 112

5.5 Advanced Actions in CustomReports 114

5.5.1 Using Filters 114

5.5.2 Changing Data Format 116



5.5.3 Creating CustomFields 118

6. Custom Dashboards 121

6.1 Accessing CustomDashboards 121

6.2 Prerequisites 122

6.2.1 Prerequisites for Cloud 122

6.2.2 Prerequisites for On-premises 122

6.3 Overview of Dashboard Designer 122

6.3.1 Dashboard Designer Interface 123

6.3.2 Dashlets and Dashboard Elements 127

6.3.3 Dashboard Properties 127

6.3.4 Dashlet Properties 129

6.4 Working with CustomDashboards 134

6.4.1 Creating a CustomDashboard 134

6.4.2 Updating a CustomDashboard 141

6.4.3 Deleting a CustomDashboard 142

6.4.4 Input Controls (Parameter) Mapping 143


2. Custom Metrics Custom Reporting – Metrics, Reports and Dashboard GuideVersion1.4

2. Custom Metrics

CustomMetrics is a feature of Kony Fabric Cloud that lets you to capture custom data from an

application and build reports using the custom data. You receive access to a set of standardmetrics

gathered from the application such as the platform and the channel. You can use these standard

metrics to build custom reports. This feature is available to the application deployed to an app services

server in the development cloud.

The CloudManagement portal lets you define the custommetrics. Administrators andOwners of the

cloud account will see CustomMetrics and CustomReports in the Console tab.

l Custom Metrics lets you add or deletemetrics that they intend to send from the application.

The CustomMetrics page shows a list of development clouds (environments) in the account

and a list of applications deployed in each cloud. If you deploy an application to Kony Fabric

Cloud, it is displayed in the Custom Metrics page.

l Custom Reports lets you create/modify/save reports with themetrics created in the Custom

Metrics screen.

l You can also choose to save the reports as Private Reports or Shared Reports. Private

Reports are accessible only to the creator where as the Shared Reports are accessible to

all users who have permission to view custom reports in that particular account.



Note: To access the CustomMetrics page, register at manage.kony.com.

2.1 Prerequisites

To create custommetrics and generate custom reports in KonyCloud, meet the following

prerequisites:

1. A working account in KonyCloud.

2. Active Kony Fabric Cloud.

3. An application deployed to Kony Fabric Cloud.


https://manage.kony.com/


2.2 Defining Custom Metrics in Kony Cloud

TheCustomMetrics page enables you to define themetrics for an application. Eachmetric is identified

by a unique keywithin the application. There are six types of data: String, Boolean, Long (Integer),

Double, Date, and Timestamp. The page shows all development clouds and applications deployed to

these clouds. To add custommetric parameters to an application, in the Reports section of the

application, go to Custom Metrics tab , click on + Add Custom Metric button.

For applications that already have custommetrics defined, clicking on Add + will show the list of

Parameter Names, Data Type, and Default Aggregation function.

The application can sendmultiple key-value pairs that will be stored as custommetrics for reporting

purposes. The user must register each key sent by the application and provide the Data Type and

Default Aggregation values.

To create a custom metric, follow these steps:



1. Click Add Custom Metric. The following pane appears.

2. Enter a name in the Name (key) area. Eachmetric is identified by a key that must to be unique

within the application. The application codemust use the sameName for sending data in the

key-value pairs in JSON string . The key is case insensitive.

3. Select a Data Type from the list. The available values are Long (integer values), Double (values

with decimal points like 12.5), String, and Date.

Note: The data typementioned heremust match the data type sent from the application for

themetric name.

4. Select a Default Aggregation from the list. The Default Aggregation is the cumulative function

you apply to the data while building the application. The available values are Sum, Average,

Highest, Lowest, Count, and Distinct Count. Default Aggregation functions are only applicable

for Long and Double.

5. Click Save. The parameters will be defined and saved under the application name. The custom

metrics defined will be sent to the application to collect data.



6. Click Cancel to cancel adding custommetrics to the application.

For example, the image below shows custommetrics for one of our sample apps KonyStore:

To delete a custom metric, follow these steps:

1. Select the custommetric in the application.

2. Click Delete. A warningmessage appears.



3. Click Yes, I'm sure to delete the custommetric.

Note: Data from an application with a key corresponding to a deleted parameter namewill not be

saved. Existing reports and ad hoc views already created from the domain that use the deleted

parameter will work. However, creating new ad hoc views from the same domain will have the

underscore _ deleted suffix for the parameter name to denote to the developer building reports

that this is currently a deleted parameter.

2.3 Rules for Custom Metrics Data Types

l Long - Integer values

l Double - Valueswith decimal point like 450.99

l Boolean - true/false

l String - Any string value, maximum length 500 characters.

l Date - String value denoting date in the format yyyy-mm-dd. Example: "2014-05-01"

l Timestamp - String value denoting timestamp. Valid formats for timestamp are shown below

o yyyy-mm-dd hh:mm:ss --- preferred format

o yyyy-mm-dd hh:mm:ssz



o yyyy-mm-dd hh:mm:ss+hh:mm

o yyyy-mm-dd hh:mm:ss-hh:mm

o z stands for zulu (UTC)

o +hh:mm is positive offset of time fromUTC

o -hh:mm is negative offset fromUTC.

o Example:

"2014-04-15 13:02:55"

"2014-04-15 13:02:55z"

"2014-04-15 13:02:55+05:30"

"2014-04-15 13:02:55-05:30"


3. Implementing Custom Metrics Custom Reporting – Metrics, Reports and Dashboard GuideVersion1.4

3. Implementing Custom Metrics

You can implement CustomMetrics through code on client side and server side. CustomMetrics

support Kony Visualizer andMBaaS SDK clients.

The data type defined in cloud portal for the applicationmust match the data type sent from the

application. After the data is defined, you can use this data to build reports.

Implementing CustomMetrics in Kony Visualizer

Implementing CustomMetrics in Kony Server



3.1 Implementing Custom Metrics in Kony Visualizer

To implement custommetrics in Kony Visualizer, send data from your application to the custom

metrics in KonyCloud. You can also send custommetrics by calling a new API in Kony Visualizer,

KNYMetricsService.sendCustomMetrics (,).

This API will initiate a service callback to Kony Server in a development cloud with service ID as

capturekonycustommetrics.

To definemetrics in Kony Visualizer, follow these steps:

1. In Kony Visualizer, design a form for an application.

2. To implement themetrics for an application in Kony Visualizer, choose one of the following

methods:

a. Right-click on a form element. Define themetrics using

KNYMetricsService.sendCustomMetrics in an onClick event by adding a

code snippet to the Action Sequence.

b. Configure themetrics in a codemodule.

3. Define themetrics.

a. The supported formats for key values are as follows:

Each JSON object in the following formats correspond to one set of associated data.

/* Array of JSON Objects with single key: */

/* The following format is used if data is not associated.

For example, met1 and met2 are unassociated data points. */

[

{

"met1": "metVal1"

},



{

"met2": "metVal2"

}

]

/* JSON Array with single JSON object with multiple keys: */

/* The following format is used for sending a single set of

associated data. For example, you can check the value of met2

when the value of met1 is metVal1. */

[

{

"met1": "metVal1",

"met2": "metVal2"

}

]

/* JSON array with multiple JSON objects: */

/* The following format is used for sending or collecting

multiple sets of associated data */

[

{

"met1": "metVal1", "met2": "metVal2"

},

{

"met1": "metVal3", "met2": "metVal4"

}

]

The following example shows a custommetrics code defined for an element in Kony Visualizer.



var custmetrics = [{"onSale":true,"prodName":"iPad 16

GB","prodPrice":450.0,"salePrice":400.0,"prodSKU":"1231sdf2","rat

ing":4.5}]

KNYMetricsService.sendCustomMetrics("frmProduct", custmetrics)

For more information about metrics APIs, refer to SDK documentation.

4. After you define the CustomMetrics in Kony Visualizer, rebuild and publish the application to the

same cloud for which the custommetrics was defined.

5. After the application is published and the appropriate trigger point is hit (button click or form load

wherever the earlier API is called), metrics will be sent to cloud and stored for reporting

purposes.

Note: After the data is sent from an application, it takes about 15-20minutes for the data to

reflect on cloud reports.


http://docs.kony.com/konylibrary/konyfabric/kony_fabric_user_guide/Default.htm#KonyStudio/Installing_KonyJS_SDK.htm%23MetricsS?TocPath=SDKs|Kony%2520Visualizer|_____10


3.2 Implementing Custom Metrics in Kony Server

Important: Familiarize yourself with CustomMetrics APIs before you proceed with this section.

You can implement CustomMetrics in Kony Server using java classes defined for the application such

as preprocessor and postprocessor class for services, or java service class.

Usage class allows you to easily add/edit custommetrics from the server code without affecting the

client logic.

Pre-requisites:

l Metrics defined for the application in themanagement console.

l Java programming knowledge.

To implement metrics in Kony Server, follow these steps:

1. In Kony Visualizer, navigate to and open the service you want to set metrics for.

2. Do one of the following

a. If your preprocessor and/or post processor class exists, define the logic for sending

custommetrics in them.

b. If you do not have preprocessor and post processor classes, create themwith custom

metrics logic.

See the following examples:

Preprocessor

package com.kony.preprocessors;

import java.util.Date;

import java.util.HashMap;



import org.apache.log4j.Logger;

import com.konylabs.middleware.common.DataPreProcessor;

import com.konylabs.middleware.common.MWConstants;

import com.konylabs.middleware.controller.DataControllerRequest;

import com.konylabs.middleware.dataobject.Result;

import com.konylabs.middleware.metrics.KonyCustomMetrics;

import com.konylabs.middleware.metrics.KonyCustomMetricsDataSet;

public class CustomMetricsPreProcessor1 implements

DataPreProcessor {

Logger logger = Logger.getLogger

(CustomMetricsPreProcessor1.class);

@Override

public boolean execute(HashMap map, DataControllerRequest

request, Result result)

throws Exception {

KonyCustomMetrics kmetrics = new KonyCustomMetrics();

KonyCustomMetricsDataSet metricsDataset = new

KonyCustomMetricsDataSet();

metricsDataset.setMetricsString("Product Name", "Dell

Vostro");

metricsDataset.setMetricsBoolean("On Sale", true);

metricsDataset.setMetricsLong("Product ID", 395923);

metricsDataset.setMetricsDouble("Product Price", 399.90);

Date now = new Date();

metricsDataset.setMetricsDate("On Sale Date", now);

metricsDataset.setMetricsTimestamp("Promo start time",

"2012-10-10", "yyyy-MM-dd");

metricsDataset.setMetricsTimestamp("Promo end time",

"2012-10-10 17:00:00");

KonyCustomMetricsDataSet metricsDataset1 = new


metricsDataset.setMetricsString("Product Name", "Lennovo



Lattitude");





kmetrics.addCustomMetrics(metricsDataset);

kmetrics.addCustomMetrics(metricsDataset1);

request.setAttribute(MWConstants.C_CUSTOM_METRICS,

kmetrics);

return true;

}

}

Postprocessor

package com.kony.postprocessors;

import java.util.List;

import org.apache.log4j.Logger;

import com.konylabs.middleware.common.DataPostProcessor;

import com.konylabs.middleware.common.MWConstants;



import com.konylabs.middleware.metrics.KonyCustomMetrics;


public class CloudPostProcessor implements DataPostProcessor {

private static final Logger LOG = Logger.getLogger

(CloudPostProcessor.class);

@Override

public Object execute(Result arg0, DataControllerRequest

arg1) throws Exception {

// TODO Auto-generated method stub

if (null != arg1.getAttribute(MWConstants.C_CUSTOM_



METRICS)) {

KonyCustomMetrics objKonyCustomMetrics =

(KonyCustomMetrics) arg1

.getAttribute(MWConstants.C_CUSTOM_METRICS);

String metricsJson =

objKonyCustomMetrics.getCustomMetricsJSON();

LOG.debug("::KONY METRICS JSON IN POST PROCESSOR

BEFORE MODIFICATIONS== " + metricsJson);

List cusMetDataSetList =

objKonyCustomMetrics.getCustomMetrics();

LOG.debug(":::::: LIST SIZE BEFORE CLEAR:::::" +

cusMetDataSetList.size());

objKonyCustomMetrics.clearCustomMetrics();

LOG.debug(":::::: LIST SIZE AFTER CLEAR:::::" +

cusMetDataSetList.size());

if (cusMetDataSetList.size() > 0) {

KonyCustomMetricsDataSet

objKonyCustomMetricsDataSet = (KonyCustomMetricsDataSet)

cusMetDataSetList

.get(0);

cusMetDataSetList.remove(0);

String key1value =

objKonyCustomMetricsDataSet.get("Product Name").toString();

LOG.debug("::KONY METRICS VALUE @ GET METHOD== "

+ Dell Vostro);

objKonyCustomMetricsDataSet.remove("Promo end

time");

objKonyCustomMetricsDataSet.remove("Product

Name");

objKonyCustomMetricsDataSet.setMetricsString

("Product Name", "modified value");

cusMetDataSetList.add(0,



objKonyCustomMetricsDataSet);

}

for (KonyCustomMetricsDataSet dataSet:

cusMetDataSetList) {

objKonyCustomMetrics.addCustomMetrics(dataSet);

}

LOG.debug(":::::: FINAL CUSTOM METRICS LIST :::::" +

objKonyCustomMetrics.getCustomMetrics());

arg1.setAttribute(MWConstants.C_CUSTOM_METRICS,

objKonyCustomMetrics);

}

return arg0;

}

}

Note: If you have created preprocesser and postprocessor classes, enter those

details in their respective text boxes.

FromV8 SP1 onwards, you can add custommetrics through custom code by using the

Services Manager API. This API can be used for all services (Integration, Orchestration, and

Object services).

Note: The support to add custommetrics by using the earlier method still exists in the

request attribute. The earlier method is supported only for Integration Services.

package com.kony.middleware.javaTestUtilites;

import java.text.DateFormat;

import java.text.SimpleDateFormat;

import java.util.Date;

import com.konylabs.middleware.common.JavaService2;




import com.konylabs.middleware.controller.DataControllerResponse;



public class CustomMetricsJavaService implements JavaService2 {

@Override

public Object invoke(String methodID, Object[] inputArray,

DataControllerRequest request,

DataControllerResponse response) throws Exception {

KonyCustomMetricsDataSet metricsDataset = new


metricsDataset.setMetricsString("Product Name", "Dell

Vostro");




DateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");

String dateString = "2018-04-17";

Date now = sdf.parse(dateString);


metricsDataset.setMetricsTimestamp("Promo start time",

"2012-10-10", "yyyy-MM-dd");



metricsDataset.setMetricsTimestamp("Promo end time",

"2012-10-10 17:00:00");

KonyCustomMetricsDataSet metricsDataset1 = new


metricsDataset1.setMetricsString("Product Name", "Lennovo

Lattitude");

metricsDataset1.setMetricsBoolean("On Sale", true);

metricsDataset1.setMetricsLong("Product ID", 395924);

metricsDataset1.setMetricsDouble("Product Price",

349.90);

metricsDataset1.setMetricsDate("On Sale Date", now);

request.getServicesManager().getKonyCustomMetrics

().addCustomMetrics(metricsDataset1);

request.getServicesManager().getKonyCustomMetrics

().addCustomMetrics(metricsDataset);

return new Result();

}

}

3. Right-click your service and select Build a Jar. The created jar file should be in /services/ (xml or json or java)/lib

4. Right-click on your project and select Properties. Application Properties window appears.



5. In Kony Server Details tab, make sure that the jar you created is available in the App Libraries

section.

6. Right-click the project and select Build all to build and publish the application. To deploy jar file,

publish the project.

The application is published and ready to provide custommetrics when an appropriate service is

invoked.

Note: Integration of CustomMetrics with third party tools is an app developer’s responsibility. For

more details, refer How to use third party APMProviders with Kony application.


https://docs.kony.com/konylibrary/konyfabric/Kony_Analytics_Cloud_FAQs/Default.htm#Kony_Analytics_Cloud_FAQs.htm?TocPath=_____2

4. Custom Metrics APIs for Kony

Server

Custom Reporting – Metrics, Reports and Dashboard

GuideVersion1.4

4. Custom Metrics APIs for Kony Server

This section contains Javadoc information about classes. Class define the API required for sending

custommetrics fromKony Server. These classes are as follows:

l com.konylabs.middleware.metrics.KonyCustomMetricsDataSet

l com.konylabs.middleware.metrics.KonyCustomMetrics

l MetricsException

4.1 com.konylabs.middleware.metrics.KonyCustomMetricsDataSet

The com.konylabs.middleware.metrics.KonyCustomMetricsDataSet class containsmethods

required for setting custommetrics. To enable custommetrics from server, the followingmethods are

available.

l setMetricsString

l setMetricsBoolean

l setMetricsLong

l setMetricsDouble

l setMetricsDate

l setMetricsDate

l setMetricsDate

l setMetricsTimestamp

l setMetricsTimestamp

l getMetricsMap

l get



Server


GuideVersion1.4

l remove

l toString

4.1.1 setMetricsString

Thismethod is used to set custommetrics for the data type, string.

4.1.1.1 Signature

public void setMetricsStrting(String key,String value)

throwsMetricsException

4.1.1.2 Input Parameters

key

value

4.1.1.3 Return Values

Void

Can throw metricsException.

4.1.1.4 Java Example

metricsDataset.setMetricsString("Product Name", "Dell Vostro");

4.1.2 setMetricsBoolean

Thismethod is used to set custommetric for the data type, boolean. Thismethod takes either true or

false as values.

4.1.2.1 Signature

public void setMetricsBoolean(String key,boolean value)



Server


GuideVersion1.4


key

value


Void



4.1.3 setMetricsLong

Thismethod is used to set custommetric for the data type, long.

4.1.3.1 Signature

public void setMetricsLong(String key,long value)


key

value


Void



4.1.4 setMetricsDouble

Thismethod is used to set custommetric for the data type, double.



Server


GuideVersion1.4

4.1.4.1 Signature

public void setMetricsDouble(String key,double value)

4.1.4.2 Input Parameters:

key

value


Void



4.1.5 setMetricsDate

Thismethod is used to set custommetric for the data type, date. It takesDate Object as input. The

Data Object format should be yyyy-MM-dd'.

4.1.5.1 Signature

public void setMetricsDate(String key,Date date)



key - String

value - Date


Void



Server


GuideVersion1.4



metricsDataset.setMetricsDate("On Sale Date", "2012-10-20");


Thismethod is used to set custommetric for the data type, date. The input takes date value as a string

and the date value format should be yyyy-MM-dd.

4.1.6.1 Signature

public void setMetricsDate(String key,String val)



key - String

value - String, Date value in string


Void.



metricsDataset.setMetricsDate("On Sale Date", "2012-10-20");


Thismethod is used for setting custommetric for the data type, date. Thismethod takes date and

format as a string and evaluates the date value with the given format. Input takes date value as a string

and the date value format should be yyyy-MM-dd.



Server


GuideVersion1.4

4.1.7.1 Signature

public void setMetricsDate(String key,String dateStr,String format)



key - key

value - date as string

format - date pattern

timezone - optional parameter


Void



metricsDataset.setMetricsDate("On Sale Date", "2012-10-10", "yyyy-MM-

dd");

4.1.8 setMetricsTimestamp

Thismethod is used to set custommetric for the data type, timestamp. Thismethod takes value as a

string and evaluateswith any one of the following formats:

l yyyy-MM-dd hh:mm:ss

l yyyy-mm-dd hh:mm:ssz

l yyyy-mm-dd hh:mm:ss+hh:mm

l yyyy-mm-dd hh:mm:ss-hh:mm



Server


GuideVersion1.4

- timestamp in UTC. Timestamp value.

z - timestamp in UTC. Timestamp in above format + lower case z.

+hh:mm - timestamp in UTC + positive offset in hours andminutes, separated by colon.

-hh:mm -timestamp in UTC + negative offset in hours andminutes separated by colon.

Note: = yyyy-mm-dd hh:mm:ss

For example,

"2014-04-15 13:02:55"

"2014-04-15 13:02:55z"

"2014-04-15 13:02:55+05:30"

"2014-04-15 13:02:55-05:30"

4.1.8.1 Signature

public void setMetricsTimestamp(String key,String value)



key

value


Void




Server


GuideVersion1.4


metricsDataset.setMetricsTimestamp("Promo start time", "2012-10-10

09:00:00", "yyyy-MM-dd");

4.1.9 setMetricsTimestamp

Thismethod is used to set custommetric for the data type, timestamp. Thismethod takes value as a

string and evaluateswith any one of the following time stamp patterns:

l yyyy-MM-dd hh:mm:ss

l yyyy-mm-dd hh:mm:ssz

l yyyy-mm-dd hh:mm:ss+hh:mm

l yyyy-mm-dd hh:mm:ss-hh:mm

4.1.9.1 Signature

public void setMetricsTimestamp(String key,String value,String

pattern)



key

value

pattern


Void




Server


GuideVersion1.4


metricsDataset.setMetricsTimestamp("Promo end time", "2012-10-10

17:00:00");

4.1.10 getMetricsMap

Thismethod returns custommetrics as a Hashmap.

4.1.10.1 Signature

protected Map getMetricsMap()


None


Map

4.1.11 get

Thismethod retrieves value with the key in the current request scope.

4.1.11.1 Signature

public Object get(String key)


key


If the key exists, returns value as an object. If the key does not exist, returns null.



Server


GuideVersion1.4

4.1.12 Remove

Thismethod removes key and value frommetrics in the current request scope.

4.1.12.1 Signature

public boolean remove(String key)


key


True if successfully removed, otherwise returns false.

4.1.13 toString

Thismethod retrieves entire custommetrics as a json string.

4.1.13.1 Signature

public String toString()

Overrides:

toString in classObject


None



Server


GuideVersion1.4

4.2 com.konylabs.middleware.metrics.KonyCustomMetrics

The com.konylabs.middleware.metrics.KonyCustomMetrics class containsmethods required for

adding and getting customMetrics. Thesemethods can be added to Preprocessor and PostProcessor

class by the App developer to send custommetrics. Custommetrics is converted into a JSON string

before sending it to the back end for processing.

The com.konylabs.middleware.metrics.KonyCustomMetrics class has the followingmethods:

l addCustomMetrics

l getCustomMetrics

l getCustomMetricsJSON

l clearCustomMetrics

4.2.1 addCustomMetrics

Thismethod takes KonyCustomMetricsDataSet object and adds as a json string.

4.2.1.1 Signature

public void addCustomMetrics(KonyCustomMetricsDataSet metricsDataSet)


metricsDataSet


None

4.2.2 getCustomMetrics

Thismethod returns all KonyCustomMetricsDataSet objects that were added using

addCustomMetricsmethod.



Server


GuideVersion1.4

4.2.2.1 Signature

public List getCustomMetrics()



None


Void


4.2.3 getCustomMetricsJSON

Thismethod returns custommetrics as a JSONArray string.

4.2.3.1 Signature

public String getCustomMetricsJSON()


None


String

4.2.4 clearCustomMetrics

Thismethod clears all custommetrics in the current request scope.



Server


GuideVersion1.4

4.2.4.1 Signature

public boolean clearCustomMetrics()


None


None

4.3 MetricsException

MetricsException is a class that occurs if an exception takes place while processingmetrics data.

Various validation scenarios are as follows.

metrics_dateparse_error = The date string you provided does not match

the format provided value as . Not able to parse date.

metrics_ts_error = The timestamp string you provided does not match

the default format of yyyy-mm-dd hh:mm:ss, yyyy-mm-dd hh:mm:ssz, yyyy-

mm-dd hh:mm:ss+hh:mm, or yyyy-mm-dd hh:mm:ss-hh:mm. Not able to parse

timestamp.

metrics_tsparse_error = The timestamp string you provided does not

match the format provided value as . Not able to parse

timestamp.

metrics_notnull_error = Cannot be added to custom metrics as null is

not a valid value.

metrics_date_null_error = The date/timestamp value cannot be null.

metrics_error = Please pass the valid value.


5. Custom Reports Custom Reporting – Metrics, Reports and Dashboard GuideVersion1.4

5. Custom Reports

After you have defined the custommetrics for your application, you can create a custom report. A

custom report can be generated in three formats: table, chart, and crosstab.

Table

Chart



Crosstab

Click the following links to view the user interface elements of these reports.

1. Table

2. Chart

3. Crosstab

Note: Youmust be an owner or an administrator to create reports.

Note: To Import and Export CustomReports and CustomDashboards throughMFCLI, refer to

Import CustomReports and CustomDashboards throughMFCLI

5.1 Creating a Report (Table, Chart, and Crosstab)

To create a custom report, follow these steps:

1. In the Reports > Custom Reports, click CREATE REPORT. The following Data Choose:

Source dialog appears.


https://docs.kony.com/konylibrary/konyfabric/kony_fabric_user_guide/Default.htm#Export_Import_Custom_Reports_Dashboards_MFCLI.htm


Kony On-Premise Kony Cloud

JasperReports Server 6.0/6.2/7.1 JasperReports Server 7.1

2. Select Data.

There are two types of datasets. Datasets starting with word Standard containsmetrics

collected for all applications deployed to development environments in the Cloud/Kony Fabric

account. The Standard datasets are available even if no custommetrics have been defined.

Standard Metrics V8.0 is the latest Standard dataset. Standard Metrics V7.2, Standard

Metrics, and Standard Metrics and Events are older versions of datasets and subsets of the

Standard Metrics V8.0. For Cloud/On-premises, it is recommended to use Standard Metrics

V8.0 dataset.

3. Click Choose Data. The Data Chooser dialog appears.

l For CustomReports using Standard Metrics V8.0, the Source is classified into three



sections such as Sessions, Requests, Events.

Note: For KonyCloud, Subrequests, Direct API Requests, and Direct

API Subrequests sections are supported fromV8 SP4 Fixpack 3 onwards.

The Data Chooser for Standard Metrics V8.0 is as follows:

l Session is a dataset used to retrieve the information such as the number of times

the app is used, the number of users who used the app, the location where the app

is accessed, andOS versions of the app. This table contains an entry for every time

the user launches the app or when the app comes to the foreground after being in

the background for more than 30minutes. It is used as a default dataset for building

reports. If you do not have any requirements from other datasets, it is

recommended to use only session dataset for building reports because it has the

least volume of records and helps to build the reports faster.



l Events table contains an entry for every event that the client app generates as part

of the project settings. Kony Fabric SDKs can send data on the application events

to track the journey of a user in the app. The APIs can report standard app events

such as FormEntry, FormExit, Service Request, Touch, Gesture, andOrientation.

The APIs can also report error events and app crashes. You can use the data in

the table to analyze the app flows that a user takes, how much time a user spends

on a form, or how often does the app crash or cause an error. One session can

contain several application events based on how a developer configures the app.

l Requests table contains an entry for every service invocation to the Fabric server

such as integration, object, and orchestration service. This dataset is used while

analyzing the server-side service performance, checking the volume of service

calls. One session contains several service requests.

l Subrequests are requests within the context of another request, such as

integration service invoked within an object service.

l Direct API Requests are similar to Requests except that the requests aremade

directly to the API endpoint, instead of client app built using Fabric SDK.

l Direct API Sub Requests are similar to Subrequests except that the calls are

made directly to the API endpoint, instead of client app built using Fabric SDK.

The Data Chooser dialog from V8 SP2 onwards (For Kony Cloud only):

For CustomReports using Standard Metrics V8.0, or custommetrics, the source is

classified into the following eight sections:

l Sessions

l Requests

l Events

l Subrequests



l Direct API Requests

l Direct API Subrequests

l Custom Metrics

l CustomMetrics - Direct API

Note: Subrequests, Direct API Requests, Direct API Subrequests, Custom

Metrics, and Custom Metrics - Direct API are supported fromV8 SP4 Fixpack 3

onwards.

Important:l With the latest changes in the CustomMetrics, you can pull all the application



related fields directly from the Custom Metrics view instead of pulling it from

the Requests view. This will accelerate the report creation process.

l If the views pertaining to Direct API (Direct API Requests, Direct API

Subrequests, CustomMetrics - Direct API) are selected, the elements related

to the Direct API views are only allowed to bemoved as part of adhoc

reporting.

l If the views pertaining to Kony SDK (Sessions, Requests, Events,

Subrequests, CustomMetrics) are chosen, the elements related to the Kony

SDK views are only allowed to bemoved as part of adhoc reporting.

l While retrieving the data for custommetric fields fromCustomMetrics or

CustomMetrics - Direct API views, you will get the data for both Direct API and

Kony SDK requests by default.

To differentiate between the Direct API data and Kony SDK data, do the

following:

1. Add a filter on the sdktype field.

2. Pass the following conditions and values in the sdktype field:

l For Direct API(CustomMetrics - Direct API view) requests, use

the equality condition with the value as api.

l For Kony SDK(CustomMetrics view) requests, use the non-

equality condition with the value as api.



l If the reports are configured onMySQL, the following Choose Data screen

appears:

Note:l Due toMySql database join restrictions, in Standard Metrics V8.0 and

Standard Metrics V7.2, the end user can create the custom reports for

either sessions, requests, or events. The RequestsAndEvents section

is also provided if the end user wants to create the custom reports with

the fields selected from the Requests and the Events.



l For MySql database, in Standard Metrics V8.0, the user can create

reports fromSessions, Requests, and Events together fromV8 SP3

onwards.

l For On-Premise custom domain, all the custommetrics fields are displayed outside the

standard views.



l For CustomReports using other datasets

4. Select items from the Source pane andmove them to the Selected Fields pane.

a. Click Add tomove an item fromSource pane to Selected Fields pane.

b. Tomove all the items fromSource pane to Selected Fields pane, click Add All

icon.

c. To remove the items fromSelected Pane, select an item from the Selected Fields pane

and click Remove icon.

d. Tomove all the items fromSelected Fields pane to Source pane, click Remove All

icon.

l For CustomReports using StandardMetrics V8.0, StandardMetrics V7.2, or

CustomMetrics Domain.



l For CustomReports using other datasets.

Note: Selecting display fields in the Fields screen is amandatory step.



5. Click Pre-filters. This is an optional setting if you want to restrict data available to the report

builder.

a. To add a Pre-filter, double-click a field from Fields pane. The field is added to the Filters

pane, and you can configure options to customize the filter. For example, if you want to

view only the data of custommetrics services, and not view data of other service calls for

the same application, create a filter for Service ID. Next, choose a function as equals,

choose capturekonycustommetrics from the list, and configure it.

b. Click the Locked check box tomake the pre-filter unchangeable within the report builder.

Important: Do not use this option if you want the filter value to be editable from the

report builder (Ad Hoc view).


CustomMetrics Domain.



The following image shows a filter added to the Filters pane.




b. Select criteria from the list. By default, equals is selected. The following options are

available:



c. Search for the type by entering a keyword in the box and click Search. The type of the

item is based on the selected pre-filter.

d. You can also select the type from the list. The list is populated with all the values of the

selected pre-filter. In the current example, the list is populated with all types of channels.

Note: Selecting display fields in the Fields screen is amandatory step.

6. ClickOK. The filter is added to the Data Chooser.

You canmodify or remove the filter by clicking on Change or Remove links.

7. Click Display. The following screen appears.



l For CustomReports using StandardMetrics V8.0, StandardMetrics V7.2, or custom

metrics.

In this screen, you can change the display name for fields, re-order, and pick the list type.




a. Click a Display Label and an editable box appears.


custommetrics.


b. Enter a name for the display label.

c. Move the fields up or down using theMove Up andMove Down options.



d. Movemultiple fields to top or bottom using theMove to Top andMove to Bottom

options.

8. To generate a report, select an option from the following list. The Data Chooser dialog provides

three options to generate the report:

a. Click Table to generate a table report. A report builder screen appears in which you can

customize the view of the report with Fields andMeasures. To view the user interface

elements of a table report, click here.

b. Click Chart to generate a chart report. There are different kinds of chart reports available

in the cloud portal. To view the user interface elements of a chart report, click here.

c. Click Crosstab to generate a cross tabulation report, which allows you to do cumulative

operations such as total and sum. To view the user interface elements of a crosstab

report, click here.

d. Click Cancel to close the Data Chooser dialog.

Note: The default data view type is Crosstab. You can change it to any format after the

report builder user interface gets loaded.

The Default Ad HocView for Table report is illustrated in the following picture:

l For CustomReports using StandardMetrics V8.0, StandardMetrics V7.2, or custom

metrics.




Two types of items appear in the New Ad Hoc View dialog to the left:

5.1.1 DataSets Dictionary

There are two types of datasets. Datasets starting with the word Standard containsmetrics collected

for all applications deployed to development environments in the Cloud/Kony Fabric account. The

Standard datasets are available even if no custommetrics have been defined.

StandardMetrics V8.0 is the latest Standard dataset. StandardMetrics V7.2, StandardMetrics and

Events, and StandardMetrics are older versions of datasets and subsets of the StandardMetrics

V8.0. For Cloud/On-premises, it is recommended to use StandardMetrics V8.0 dataset.

l StandardMetrics V8.0

l StandardMetrics V7.2

l StandardMetrics and Events



l StandardMetrics

l CustomDataSets

5.1.1.1 Standard Metrics V8.0

Fields

l Sessions

1. Session Environment guid - GUID of the environment.

2. Session Application Name - Name of the application.

3. Session Application Type - Type of the application. For example, Native and SPA.

4. Session Channel - Channel of application. For example, Mobile and Tablet.

5. Session DeviceModel - Themodel type of client device.

6. Session DeviceID - Unique ID of the device for the application.

7. Session Kony User ID - User ID of the end user using the app. Value has to be set using the

setUserID API in the application.

8. Session OS Version - Version of the client device's OS.

9. Session Platform - Application platform. For example, iOS, Android.

10. Session City - Obtained from IP for geolocationmapping. This field is not populated if this detail

cannot be resolved from the IP address.

11. Session Country - Obtained from IP for geolocationmapping. This field is not populated if this

detail cannot be resolved from the IP address.

12. Session Region - Obtained from IP for geolocationmapping. This field is not populated if this


13. Session Zip - Obtained from IP for geolocationmapping. This field is not populated if this detail




14. Session TimeStamp_Local – Timestamp of the session in the local time zone. The local time zone

is set in the user’s profile in Kony Fabric console.

15. Session TimeStamp_UTC – Timestamp of session init in UTC.

16. Session Error Message – Error message.

17. Session Error Stack Trace – Stack trace of error. Applicable for event types Error/Crash if the

same is available for the type of error/Crash.

18. Session Kony Fabric (MobileFabric) app name – application name provided on creation of an app in

Kony Fabric console.

19. Session Kony Fabric (MobileFabric) app guid – application guid generated on the creation of an app

in Kony Fabric console.

20. Session Remote IP

21. Session Integration service version header – Version of the integration service requested by

application in the service request header.

22. Session Integration service version – Version of the integration service served by the application

server for a service request.

23. Session SDK Type - If an app is built using Kony Fabric SDK this will indicate the type of SDK

such as iOS and PhoneGap.

24. Session SDK Version - Version of the Kony Fabric SDK used in the client binary.

25. Session Service Group - Integration service name of the service request for applications defined

from Kony Fabric console.

26. Session User Agent - User agent of the client device from a network call.

27. Session Application Version - Version of the application.

28. Session Session Category (For Cloud only) - Type of session whether interactive or non -

interactive.



l Requests

1. Request Environment guid - GUID of the environment.

2. Request Application Name - Name of the application.

3. Request Application Type - Type of the application. For example, Native and SPA.

4. Request Channel - Channel of application. For example, Mobile and Tablet.

5. Request DeviceModel - Themodel type of client device.

6. Request DeviceID - Unique ID of the device for the application.

7. Request OS Version - Version of the client device's OS.

8. Request Platform - Application platform. For example, iOS, Android.

9. Request Service ID

10. Request TimeStamp_Local – Timestamp of an event in the local time zone. The local time zone is

set in the user’s profile in Kony Fabric console.

11. Request TimeStamp_UTC – Timestamp of an event in UTC.

12. Request City - Obtained from IP for geolocationmapping. This field is not populated if this detail


13. Request Country - Obtained from IP for geolocationmapping. This field is not populated if this


14. Request Region - Obtained from IP for geolocationmapping. This field is not populated if this


15. Request Zip - Obtained from IP for geolocationmapping. This field is not populated if this detail


16. Request Error Message – Contains any request message that is added by platform code or app

developer to providemore info on error events.

17. Request Error Stack Trace – Stack trace of error. Applicable for event types Error/Crash if the




18. Request SDK Type - If an app is built using Kony Fabric SDK this will indicate the type of SDK

such as iOS and PhoneGap.

19. Request SDK Version - Version of the Kony Fabric SDK used in the client binary.

20. Request Kony Fabric (MobileFabric) app name– application name provided on creation of an app in

Kony Fabric console.

21. Request Kony Fabric (MobileFabric) app guid – application guid generated on the creation of an

app in Kony Fabric console.

22. Request Service Group - Integration service name of the service request for applications defined

from Kony Fabric console.

23. Request FormID

24. Request Integration service version header – Version of the integration service requested by


25. Request Integration service version – Version of the integration service served by the application

server for a service request.

26. Request Object name – Name of the object that is mapped in a service request. Applicable for

services with object mapping.

27. Request Object method – Type of the object method. For example, PUT and POST. Applicable for

services with object mapping.

28. Request Kony User ID - User ID of the end user using the app. Value has to be set using the


29. Request Remote IP

30. Request User Agent - User agent of the client device from a network call.

31. Request Application Version - Version of the application.

32. Request Service Type (For Cloud only) - Type of Kony Fabric service of the application. The

values include Integration, Object, andOrchestration.



33. Request Connection Type (For Cloud only) - The type of connector. For example, JSON and

XML.

34. Request Request Type (For Cloud only) - Type of Request from the device. For example, Upload

and Download.

35. Request Request Bytes (For Cloud only) - Transaction request data in bytes.

36. Request Response Bytes (For Cloud only) - Transaction response data in bytes.

37. Request Sync Error (For Cloud only) - If an error occurs during a sync service call, the value of

Request Sync Error is true. Otherwise, it is false.

38. Request Sync Mode (For Cloud only) - Sync Mode of the application. The values includeOnline

andOffline.

39. Request Session Category (For Cloud only) - Type of session whether interactive or non -

interactive.

l Events

1. Events Environment guid - GUID of the environment.

2. Event Application Name - Name of the application.

3. Event Application Type - Type of the application. For example, Native and SPA.

4. Event Channel - Channel of application. For example, Mobile and Tablet.

5. Event Platform - Application platform. For example, iOS and Android.

6. Event DeviceModel - Themodel type of client device.

7. Event User ID- Unique ID of the user.

8. Event DeviceID - Unique ID of the device for the application.

9. Event User Agent - User agent of the client device from a network call.

10. Event Application Version - Version of the application.



11. Event Plugin Version IDE - Plugin versions of Kony Visualizer Enterprise used for building the

app. This will be populated only for Crash event type.

12. Event Plugin Version Platform - Plugin version of the platform (such as iOS plugin) used for

building the app. This will be populated only for Crash event type.

13. Event SDK Type - If an app is built using Kony Fabric SDK this will indicate the type of SDK such

as iOS and PhoneGap.

14. Event SDK Version - Version of the Kony Fabric SDK used in the client binary.

15. Event Type - The type of application event. For example, FormEntry andGesture.

16. Event Sub Type - The event sub type of application event. Meaning of subtype depends on the

event type. For FormEntry event subtype denotes form entered. For Gesture, it denotes the type

of Gesture such as a double-click.

17. Event Form ID - Form ID of the form where the application event occurred.

18. Event Widget ID -Widget Id of the widget where the application event was triggered. Not

applicable for events that do not involve a widget such as FormEntry and FormExit.

19. Event Flow Tag - Optional parameter that can be set by a developer via an API call to identify a

flow. It helps in easy identification for data analysis.

20. Event Error Code - Error code if the event type is error and Exception code if the event type is an

exception.

21. Event Error Message – Contains any event message that is added by platform code or app

developer to providemore info on error events.

22. Event Error Crash Report – Crash Report from the device for event type Crash. Data is not

symbolicated.

23. Event Custom Error Message – Contains any custommessage that is added by platform code or

app developer to providemore info on error events.

24. Event Error File – Application code file where an error occurred. Applicable for event types

Error/Exception if the same is available for the type of error/exception.



25. Event Error Method – Application function call where an error occurred. Applicable for event types

Error/Exception if the same is available for the type of error/exception.

26. Event Error Stack Trace – Stack trace of error. Applicable for event types Error/Crash if the same

is available for the type of error/Crash.

27. Event Error Type – Type of error. For example, Error, Exception, and Crash.

28. Event Is Error – true if the event type is error/crash and false if the event type is an exception. Not

applicable for other event types.

29. Event Response Status Code – Output status of the service response from the Kony Fabric

server.

30. Event Meta Data – Any metadata sent as part of the events data. Typically this is applicable for

event type error, exception, crash, and custom.

31. Event TimeStamp_Local - Timestampwhen the service request was received in the timestamp

set in a user's profile in themanage cloud portal.

32. Event TimeStamp_UTC - Timestamp of request in UTC.

33. Event Network Type - Mobile Network vs Wifi (networktype) - indicates the type of network during

the time of the crash. Valid values – mobilenetwork and wifi.

l Subrequests (For Cloud only)

1. Subrequest Environment guid - GUID of the environment.

2. Subrequest Application Name - Name of the application.

3. Subrequest Application Version - Version of the application.

4. Subrequest Application Type - Type of the application. For example, Native and SPA.

5. Subrequest Channel - Channel of application. For example, Mobile and Tablet.

6. Subrequest DeviceModel - Model of the client device.

7. Subrequest DeviceID - Unique ID of the device for the application.



8. Subrequest OS Version - Version of the client device's OS.

9. Subrequest Platform - Application platform. For example, iOS and Android.

10. Subrequest Parent Service ID

11. Subrequest Service ID

12. Subrequest TimeStamp_Local – Timestamp of the request in the local time zone. The local time

zone is set in the user’s profile in Kony Fabric console.

13. Subrequest TimeStamp_UTC – Timestamp of the request in UTC.

14. Subrequest City - Obtained from IP for geolocationmapping. If this detail is not resolved from the

IP address, this field is not populated.

15. Subrequest Country - Obtained from IP for geolocationmapping. If this detail is not resolved from

the IP address, this field is not populated.

16. Subrequest Region - Obtained from IP for geolocationmapping. If this detail is not resolved from


17. Subrequest Zip - Obtained from IP for geolocationmapping. If this detail is not resolved from the


18. Subrequest Error Message – Contains any request message that is added by either platform code

or app developer to providemore information on error events.

19. Subrequest Error Stack Trace – Stack trace of error. Applicable for event types Error/Crash if the


20. Subrequest SDK Type - If the app is built using Kony Fabric SDK, this field indicates the type of

SDK such as iOS and PhoneGap.

21. Subrequest SDK Version - Version of the Kony Fabric SDK used in the client binary.

22. Subrequest Kony Fabric (MobileFabric) app name – Application name provided on creation of an


23. Subrequest Kony Fabric (MobileFabric) app guid – Application guid generated on the creation of an




24. Subrequest Parent Service Group - Parent service name of the service request for applications

defined from Kony Fabric console.

25. Subrequest Service Group - Integration service name of the service request for applications


26. Subrequest FormID - Request FormID.

27. Subrequest Integration service version header – Version of the integration service requested by


28. Subrequest Integration service version – Version of the integration service served by the

application server for a service request.

29. Subrequest Object name – Name of the object that is mapped in the service request. It is

applicable for services with object mapping.

30. Subrequest Object method – Type of the object method. For example, PUT and POST. It is


31. Subrequest Kony User ID - User ID of the end user using the app. Value has to be set using the


32. Subrequest Remote IP

33. Subrequest User Agent - User agent of the client device from a network call.

34. Subrequest Service Type - Type of Kony Fabric service of the application. The values include

Integration, Orchestration, andObject.

35. Subrequest Connection Type - The type of connector. For example, JSON and XML.

36. Subrequest Request Type - Type of request from the device. For example, Upload and Download.

37. Subrequest Request Bytes - Transaction request data in bytes.

38. Subrequest Response Bytes - Transaction response data in bytes.

39. Subrequest Sync Error - If an error occurs during a sync service call, the value of Subrequest

Sync Error is true. Otherwise, it is false.



40. Subrequest Sync Mode - Sync mode of the application. The values includeOnline andOffline.

41. Subrequest Session Category - Type of session whether interactive or non - interactive.

l Direct API Requests (For Cloud only)

1. API_Request Environment guid - GUID of the environment.

2. API_Request Application Name - Name of the application.

3. API_Request Service ID

4. API_Request TimeStamp_Local – Timestamp of the request in the local time zone. The local time

zone is set in the user’s profile in Kony Fabric console.

5. API_Request TimeStamp_UTC – Timestamp of the request in UTC.

6. API_Request City - Obtained from IP for geolocationmapping. If this detail is not resolved from


7. API_Request Country - Obtained from IP for geolocationmapping. If this detail is not resolved

from the IP address, this field is not populated.

8. API_Request Region - Obtained from IP for geolocationmapping. If this detail is not resolved from


9. API_Request Zip - Obtained from IP for geolocationmapping. If this detail is not resolved from the


10. API_Request Error Message – Contains any request message that is added by platform code or

app developer to providemore info on error events.

11. API_Request Error Stack Trace – Stack trace of error. It is applicable for event types Error/Crash

if the same is available for the type of error/Crash.

12. API_Request SDK Type - If the app is built using Kony Fabric SDK, this field will indicate the type

of SDK such as iOS and PhoneGap.

13. API_Request SDK Version - Version of the Kony Fabric SDK used in the client binary.



14. API_Request Kony Fabric (MobileFabric) app name– Application name provided on the creation of

an app in Kony Fabric console.

15. API_Request Kony Fabric (MobileFabric) app guid – Application guid generated on creation of an


16. API_Request Service Group - Integration service name of the service request for applications


17. API_Request FormID - Request FormID.

18. API_Request Integration service version header – Version of the integration service requested by


19. API_Request Integration service version – Version of the integration service served by the


20. API_Request Object name – Name of the object that is mapped in the service request. It is


21. API_Request Object method – Type of the object method. For example, PUT and POST. It is


22. API_Request Kony User ID - User ID of the end user using the app. Value has to be set using the


23. API_Request Remote IP

24. API_Request User Agent - User agent of the client device from a network call.

25. API_Request Service Type - Type of Kony Fabric service of the application. The values include


26. API_Request Connection Type - The type of connector. For example, JSON and XML.

27. API_Request Request Type - Type of request from the device. For example, Upload and

Download.

28. API_Request Request Bytes - Transaction request data in bytes.

29. API_Request Response Bytes - Transaction response data in bytes.



30. API_Request Sync Error - If any error occurs during a sync service call, the value of API_Request

Sync Error is true. Otherwise, it is false.

31. API_Request Sync Mode - Sync mode of the application. The values includeOnline andOffline.

32. API_Request Session Category - Type of session whether interactive or non - interactive.

l Direct API Subrequests (For Cloud only)

1. API_SubRequest Environment guid - GUID of the environment.

2. API_SubRequest Application Name - Name of the application.

3. API_SubRequest Parent Service ID

4. API_SubRequest Service ID

5. API_SubRequest TimeStamp_Local – Timestamp of the request in the local time zone. The local

time zone is set in the user’s profile in Kony Fabric console.

6. API_SubRequest TimeStamp_UTC – Timestamp of the request in UTC.

7. API_SubRequest City - Obtained from IP for geolocationmapping. This field is not populated if

this detail cannot be resolved from the IP address.

8. API_SubRequest Country - Obtained from IP for geolocationmapping. This field is not populated

if this detail cannot be resolved from the IP address.

9. API_SubRequest Region - Obtained from IP for geolocationmapping. This field is not populated if

this detail cannot be resolved from the IP address.

10. API_SubRequest Zip - Obtained from IP for geolocationmapping. This field is not populated if this


11. API_SubRequest Error Message – Contains any request message that is added by platform code

or app developer to providemore info on error events.

12. API_SubRequest Error Stack Trace – Stack trace of error. It is applicable for event types

Error/Crash if the same is available for the type of error/Crash.



13. API_SubRequest SDK Type - If the app is built using Kony Fabric SDK this will indicate the type

of SDK such as iOS and PhoneGap.

14. API_SubRequest SDK Version - Version of the Kony Fabric SDK used in the client binary.

15. API_SubRequest Kony Fabric (MobileFabric) app name – Application name provided on creation

of an app in Kony Fabric console.

16. API_SubRequest Kony Fabric (MobileFabric) app guid – Application guid generated on the

creation of an app in Kony Fabric console.

17. API_SubRequest Parent Service Group - Parent service name of the service request for

applications defined from Kony Fabric console.

18. API_SubRequest Service Group - Integration service name of the service request for applications


19. API_SubRequest FormID - Request FormID.

20. API_SubRequest Integration service version header – Version of the integration service requested

by application in the service request header.

21. API_SubRequest Integration service version – Version of the integration service served by the


22. API_SubRequest Object name – Name of the object that is mapped in the service request. It is


23. API_SubRequest Object method – Type of the object method. For example, PUT and POST. It is


24. API_SubRequest Kony User ID - User ID of the end user using the app. Value has to be set using

the setUserID API in the application.

25. API_SubRequest Remote IP

26. API_SubRequest User Agent - Type of Kony Fabric service of the application. The values include


27. API_SubRequest Service Type



28. API_SubRequest Connection Type - The type of connector. For example, JSON and XML.

29. API_SubRequest Request Type - Type of request from the device. For example, Upload and

Download.

30. API_SubRequest Request Bytes - Transaction request data in bytes.

31. API_SubRequest Response Bytes - Transaction response data in bytes.

32. API_SubRequest Sync Error - If any error occurs during a sync service call, the value of API_

SubRequest Sync Error is true. Otherwise, it is false.

33. API_SubRequest Sync Mode - Sync mode of the application. The values includeOnline and

Offline.

34. API_SubRequest Session Category - Type of session whether interactive or non - interactive.

Measures

l Sessions

1. Session HTTP Response Code

2. Session Response Status Code

3. Session Session Key

4. Session Total Duration

l Requests

1. Request HTTP Response Code – HTTP code of the service response obtained by the device.

2. Request Response Status Code – Output status of the service response from the Kony Fabric

server.

3. Request Session Key – Unique session identifier for application session data from session init

call.



4. Request Total Duration - Total time spent in Kony app services server for the service call, from

the time request was received by the server until the response was sent back to the device. Total

duration is equal to the sum of all the duration fields.

5. Request Internal Duration - Time spent by the service call in Kony App Services for internal

processing.

6. Request PostProcessor Duration - Time spent by the service call in Kony app services in custom

post-processing logic in the service.

7. Request PreProcessor Duration - Time spent by the service call in Kony app services in custom

pre-processing logic in the service.

8. Request Parse Duration - Time spent by the service call in Kony app services in parsing the

response from an external source.

9. Request External Duration - Time spent by the service call in Kony App Services for an external

call from Kony Server to the backend.

10. Request Total Duration - Total time spent in Kony app services server for the service call, from



11. Request Response Status Code

12. Request HTTP Response Code – HTTP code of the service response obtained by the device.

13. Request Object mapping duration (request) – Time taken tomap the object detail into service

request by Kony app services.

14. Request Object mapping duration (response) – Time taken tomap the object detail into service

response by Kony app services.

15. Request Request_Key

16. Request session_key

17. Request Total Records Synced (For Cloud only) - Total number of records that are either

downloaded or uploaded during a sync service call.



18. Request Request Data Processing Duration (For Cloud only) - Time taken to parse the data and

convert to JSON for a request.

19. Request Response Data Processing Duration (For Cloud only) -Time taken to parse the data and

convert to JSON for a response.

20. Request Custom-Conflict Duration (For Cloud only) - Time taken to execute built-in interceptor

logic for conflicts in milliseconds.

21. Request Conflict Count (For Cloud only) - Number of conflicts occurred during a sync service call.

l Events

1. Event Error Line – Line number in application code file where the error occurred. Applicable for

event types error/exception.

2. Event HTTP Response Code – HTTP code of the service response obtained by the device.

3. Event Response Time – Response time as viewed by the client device. That is the time since

service the request is sent from device to server and response obtained back in the device.

4. Event Session Key - Unique session identifier for the session in which the application event

occurred.

5. Event Request Key

6. Event Disk Memory Free - indicate freememory in the internal disk in MB.

7. Event Disk Memory Total - indicates total memory in the internal disk in MB.

8. Event SdMemory Free - indicates freememory available in SD card in MB.

9. Event SdMemory Total - indicates battery level during the time of the crash. This will be a number

indicator% available of battery.

10. Event Battery Charge Level - indicates battery level during the time of the crash. This will be a

number indicator% available of battery.

11. Event Memory Usage – RAM - indicates thememory used when the app crashes.

12. Event CPU Usage - indicates the% of CPU being used at the time of the crash.



13. Event Form Duration - The amount of time spent in a particular form inmilliseconds.

14. Event Load Duration - The amount of time taken inmilliseconds for an app to load.

15. Event Fore Duration - The amount of time inmilliseconds spent by an app in the foreground.

l Subrequests (For Cloud only)

1. Subrequest HTTP Response Code – HTTP code of the service response obtained by the device.

2. Subrequest Response Status Code – Output status of the service response from the Kony Fabric

server.

3. Subrequest Session Key – Unique session identifier for application session data from session init

call.

4. Subrequest Total Duration - Total time spent in Kony app services server for the service call, from



5. Subrequest Internal Duration - Time spent by the service call in Kony App Services for internal

processing.

6. Subrequest PostProcessor Duration - Time spent by the service call in Kony app services in

custom post-processing logic in the service.

7. Subrequest PreProcessor Duration - Time spent by the service call in Kony app services in

custom pre-processing logic in the service.

8. Subrequest Parse Duration - Time spent by the service call in Kony app services in parsing the

response from an external source.

9. Subrequest External Duration - Time spent by the service call in Kony App Services for an

external call from Kony Server to the backend.

10. Subrequest Total Duration - Total time spent in Kony app services server for the service call, from



11. Subrequest Response Status Code



12. Subrequest HTTP Response Code – HTTP code of the service response obtained by the device.

13. Subrequest Object mapping duration (request) – Time taken tomap the object detail into service

request by Kony app services.

14. Subrequest Object mapping duration (response) – Time taken tomap the object detail into service

response by Kony app services.

15. Subrequest Request_Key

16. Subrequest Total Records Synced - Total number of records that are either downloaded or

uploaded during a sync service call.

17. Subrequest Request Data Processing Duration - Time taken to parse the data and convert to

JSON for a request.

18. Subrequest Response Data Processing Duration - Time taken to parse the data and convert to

JSON for a response.

19. Subrequest Custom-Conflict Duration - Time taken to execute built-in interceptor logic for

conflicts in milliseconds.

20. Subrequest Conflict Count - Number of conflicts occurred during a sync service call.

l Direct API Requests (For Cloud only)

1. API_Request HTTP Response Code – HTTP code of the service response obtained by the

device.

2. API_Request Response Status Code – Output status of the service response from the Kony

Fabric server.

3. API_Request Total Duration - Total time spent in Kony app services server for the service call,

from the time request was received by the server until the response was sent back to the device.

Total duration is equal to the sum of all the duration fields.

4. API_Request Internal Duration - Time spent by the service call in Kony App Services for internal

processing.



5. API_Request PostProcessor Duration - Time

Date post:	22-May-2020
Category:	Documents
Upload:	others
View:	14 times
Download:	0 times

Custom Reporting Metrics, Reports, and Dashboard Guide€¦ · 1. RevisionHistory...

Documents