Set up request naming using request attributes

Within DESK, you can use request naming rules to adjust how your requests are tracked and to define business transactions in your customer-facing workflow that are critical to the success of your digital business. With such end-to-end tracing, DESK enables you to view and monitor important business transactions from end to end.

By using request attributes in combination with naming rules, you can capture even more context around your requests and use this additional detail to slice and dice your monitoring data.

Business transaction setup

The first step in setting up a business transaction for monitoring is to create request naming rules with conditions that define the business transaction.

1. Select Transactions & services from the navigation menu.

2. Select the service you want to configure.

3. Click the Browse (…) button.

4. Select Edit.

5. On the Service settings page, select the Request naming tab.

6. Click Add rule Within the Request naming rules section.

7. Define a set of conditions that represent the criteria of your business transaction. In this example, the first condition specifies that—to be considered part of the business transaction—the URL path must contain the string orange-booking. The second condition specifies that the request must be an HTTP method of type GET. The last condition specifies that the request must have the attribute easyTravel destination.

   

   You can use anything from request headers to code-level method argument values to identify specific requests. This example request attribute actually has multiple sources. In this context, the source doesn’t matter—what matters is the fact that this string was detected in the transaction.

   

   All requests that match the specified criteria will be named based on the defined naming pattern Booking.

Request attribute values

Once you’ve defined request naming rules for your business transaction, you may decide to include the value of a request attribute as part of the request name to create intuitive variant names for this request. Using the request attribute easyTravel destination, you can create variant requests for tracking purposes that represent each permutation of the respective request attribute—in this case, a variant request for each destination that’s booked by customers of easyTravel.

The result is that this rule no longer creates a single kind of request; it now creates a separate trackable request for each booked destination (see the list of request names at bottom of image below).

As you can see in the list of related PurePaths below, while the URLs are all the same, each request name includes a different destination-city attribute value.

By constructing your business transactions in this way for DESK monitoring, you can track all of your organization’s key business transactions at a highly granular level.

Advanced request naming

You can additionally create custom place holders that extract values from request attributes or URLs. The example below extracts the booking stage ({stage}) of the booking from the URL.

Using this place holder, the resulting list of request names appears as follows:

You can also combine the two naming approaches detailed above to create even more fine-grained request names. The rule example below defines a request naming pattern that includes both the booking stage ({stage}) and the destination attribute ({RequestAttribute:easyTravel destination}).

The resulting request list appears below. Now we get a separate request for each booking stage, plus further splits based on the destination attribute.

And, of course, as these are all standard requests, you can use them as sources for custom charts on your DESK dashboards. To create a custom chart based on a request, the request must first be marked as a key request.

Multi-tiered service analysis

The full value of setting up your business-critical requests in this way becomes apparent once you dig into the analysis that’s available for each individual request on the service level. To illustrate, let’s add another request naming rule that splits out the booking requests based on the attribute LoyaltyStatus.

This addition results in separate requests to this service based on loyalty status.

Now when we look at an individual PurePath, we can see how useful the two defined request attributes are. In this example, we see that a Booking to Miami Beach was performed by a customer who has Gold loyalty status. This was achieved by defining a request naming rule on the easyTravel Customer Frontend service that tracks bookings per destination and a separate request naming rule that tracks bookings on the backend BookingService based on loyalty status.

As you can see, request attributes give you absolute flexibility in identifying and naming your requests based on your business requirements. DESK tracks each request from end-to-end and tells you how all the requests are related

Multidimensional analysis

Because request naming rules produce distinct service requests, we have even further filtering options based on the attributes of the new requests that have been defined. In the example below, the destination breakdown is combined with Platinum loyalty status.

Of course, you can also leverage this functionality in combination with powerful hierarchical filtering. In this example, we analyze booking requests that are in the finish stage, with a destination of San Francisco, and loyalty status Platinum.

While this has been possible using request attributes alone, the request naming makes this approach even more powerful.

Impact on baselining, API, and analysis

Because request naming rules produce distinct service requests, each request is independently baselined and monitored for performance anomalies. The performance metrics captured for these requests are also separately accessible via the DESK timeseries API endpoint.