SmartComponent Library Telemetry Service


The Telemetry Service of the SmartComponent Library provides insights into the utilization of the AppServer backend of a SmartComponent Library application, regardless if the backend is used by Web-, GUI-, REST-, SOAP- or open-client applications.

Per request the telemetry service writes down request details including the runtime, user and domain, service interface used and the actual service component (Business Entity) and method called into.

The Telemetry Data can be consumed by various applications. We are working on an integration of the Telemetry Data into the ProTop database monitoring service and portal (


Activate and Deactivate Procedures

The Telemetry Service relies on the AppServers Activate and Deactivate procedures as a central place for initializing the request logging and finalizing the logging and the actual output.

So the AppServer configuration needs to include our Activate and Deactivate procedures, e.g.:

sessionActivateProc=Consultingwerk/Framework/Server/as_activate.p sessionDeactivateProc=Consultingwerk/Framework/Server/as_deactivate.p


The Telemetry Service requires services for the following two interfaces to be loaded:

  • Consultingwerk.Framework.Server.Telemetry.ITelemetryService

  • Consultingwerk.Framework.Server.Telemetry.ITelemetryOutputWriter

We provide the file Consultingwerk/Framework/Server/Telemetry/services_telemetry.xml that loads these two services with our default implementations.

The file Consultingwerk/Framework/Server/Telemetry/services_telemetry.xml can for instance be referenced from the loadServices section of the

"loadServices": [ "Consultingwerk/SmartComponentsDemo/Web2/demo_services.xml", "Consultingwerk/Framework/Server/Telemetry/services_telemetry.xml", "Consultingwerk/OERA/TableStatistics/services_request_monitor.xml", "Consultingwerk/OERA/RequestManager/services_request_manager.xml", "Consultingwerk/OERA/RestResource/services.xml", "Consultingwerk/BusinessEntityDesigner/Web/businessentitydesigner_services.xml"],

Telemetry configuration

The file telemetry.conf needs to be created in a folder contained in the PROPATH of the AppServer (e.g. ablapps/<ablappname>/openedge with content similar to this:

{ "detailLevel": 5, "outputDirectory": "../ablapps/smartpas_stream/telemetry", "fileNamePattern": "telemetry_${telemetry.instanceIdentifier}_${t.YYYY}${t.MM}${t.DD}_${t.H}${t.MMM}${t.SS}_${req.agent}_${req.session}.ndjson", "instanceIdentifier": "Consultingwerk42.smartpas_stream.124" }

Note, the outputDirectory needs to be created before starting the AppServer.

The detailLevel setting is currently not yet used but needs to be specified.

Based on the fileNamePattern the Telemetry Service is using the OpenEdge pattern resolver ( to build the file names used to write Telemetry data to. In addition to the logging tokens provided by Progress Software, we have added the telemetry.instanceIdentifier token.

The instanceIdentifier should be a unique identifier for an instance of the application backend.

Output File Format

The default ITelemetryOutputWriter implementation produces a single output file per AppServer session to avoid file locking conflicts. The files are written buffered in the NDJSON file format ( ).

The buffered nature improves the output performance drastically, however most likely cause that the last line in the output files appear to be incomplete until further output is written to the file or the AppServer session that the file belongs to is shut down.

NDJSON files contain a single JSON document per line. The complete NDJSON file however is not a valid JSON document.

We use the following attributes in the JSON file:

Attribute Name


Attribute Name



The unique identifier of the backend installation, matching the instanceIdentifier setting from the telemetry.conf file (see above)


The time the request has been started


The time the request has been finished


The runtime of the request in milliseconds


The authenticated user name


The domain name of the authenticated user


The service interface used, e.g. name of the Web Handler class or proSI…. procedure


The PASOE Adapter type


The PASOE agent process ID


The PASOE session ID


The request ID as appearing in the AppServer logfile


The version of OpenEdge


The HTTP URI of the request


The HTTP request method of the request


The name of the service component (e.g. Business Entity or Business Task invoked)


The name of the method executed in the service component


Request details, e.g. the queries property of a FetchDataRequest


Key identifying the request, typically composed of the abbreviated service name and service request or service interface


The runtime error message number when the request returned an error


The error messages returned to the client


The application error messages returned to the client


The stack trace of an error returned to the client

Not all properties will appear at any time.

Related Information