Progress will discontinue Telerik Platform on May 10th, 2018. Learn more

Debugging Business Logic Using the Portal

Debugging Business Logic Using the Portal

Telerik Platform has an integrated full-featured debugger for your Business Logic. This means that you can set breakpoints in your Business Logic files, watch expressions, browse stack traces, and have the debug experience you are already used to.

In the following paragraphs you will find more information about using the interactive Business Logic debugging feature.

To be able to debug Business Logic you need to start a debug session. Debug sessions are created per application and can be used to debug all the Business Logic resources for the given application.

Starting a debug session

You can start a debug session in the following ways.

Debug sessions are automatically destroyed if they stay idle for too long. Once a debug session is destroyed, you will need to start a new one explicitly before you can attach the debugger again.

Starting a Debug Session from the Telerik Platform Portal

On each Business Logic code explorer screen where debugging is supported, you will find a Debug button. Click Debug and select Start debugging to start a debugging session. A link to the debugger screen appears on the right. Click it to start the session.

Starting a debugging session from the UI portal

Starting a Debug Session through the Backend Services RESTful API

You can manage a debug session by making requests to the respective Backend Services RESTful API endpoints.

The endpoints are described in this article.

Connecting to a Debug Session

Connecting to a debug session is done from a client that supports the debugging protocol exposed by Telerik Platform.

From the Web Portal

Telerik Platform provides an integrated web UI for Business Logic debugging. Once you start a debug session, a unique, secure URL will appear in the top of the screen. Follow it to open the debug window for the current application.

From a Browser

When you start a debug session from the Backend Services RESTful API, the server will return a result object containing the URL of the debug session. Open it in one of the supported browsers and start debugging the Business Logic for your application.

The debugging is supported only if the debug window is opened in Chrome and Opera browsers.

File Navigator Structure

Once you have opened the debug window, head over to the top-left corner of the screen. Expand the navigator window from the arrow just under the Sources tab. Select the Sources child tab. The Business Logic files for an application that contain custom code will be presented as a file structure.

Here is some more information about the structure you will be presented with:

  • Application—this folder contains the global debug server adapter object.
  • CloudFunctions—this folder contains files named after the Cloud Functions defined in your application. Each file contains the body of the Cloud Function.
  • ContentTypes—this folder contains files named after the content types of your application. Each file contains the cloud code for a content type.

View of the debug window structure

Making Debug Requests

Custom Business Logic is executed as a result of an API request from a client. It is very important to understand that requests to the server are not automatically redirected to the debugging process. To debug the Business Logic for a request, you need to mark it for debugging by adding a X-Everlive-Debug: true header and following the standard notation for requests to the Backend Services RESTful API.

You can safely place breakpoints in your Business Logic. Those breakpoints will not be hit by normal requests from your existing users, only by requests explicitly marked for debugging.

Any changes that the debug requests make are persisted. For example, if a new item is created using a debug request, it is persisted in your application.

If you change the Business Logic in the portal editor while running a debug session, the session will be automatically recreated to load the changes. Your connection will be closed and you will have to reload the debug window.

Here are examples of how to mark the requests to the Backend Services RESTful API for Business Logic debugging.

$.ajax({
    url: 'https://api.everlive.com/v1/your-app-id/type-name',
    type: "GET",
    headers: {
        "X-Everlive-Debug": true
    },
    success: function (data) {
        alert(JSON.stringify(data));
    },
    error: function (error) {
        alert(JSON.stringify(error));
    }
});
var el = new Everlive('your-app-id');

var data = el.data('type-name');
data.withHeaders({
    "X-Everlive-Debug": true
}).get(null)
.then(function (data) {
        alert(JSON.stringify(data));
    },
    function (error) {
        alert(JSON.stringify(error));
    });
var el = new Everlive('your-app-id');

var dataSource = new kendo.data.DataSource({
    type: "everlive",
    transport: {
        typeName: "type-name",
        read: {
           headers: {
                "X-Everlive-Debug": true
            }
        }
    },
    // additional configuration
});
public async Task GetActivitesAsync(EverliveApp app)
{
    var activities = await app.WorkWith().Data<Activity>().Get().
        SetHeader("X-Everlive-Debug", "true").ExecuteAsync();
}
public ArrayList<Book> GetBooks(EverliveApp app) {
    RequestResult<ArrayList<Book>> requestResult = app.workWith().
                data(Book.class).
                getAll().beforeRequest(new GenericCallbackAction<Request>() {
            @Override
            public void invoke(Request request) {
                request.getHeaders().put("X-Everlive-Debug", "true");
            }
        }).executeSync();

    return requestResult.getSuccess() ? requestResult.getValue() : null;
}
Contact us: +1-888-365-2779
sales@telerik.com
Copyright © 2016-2017, Progress Software Corporation and/or its subsidiaries or affiliates. All rights reserved.