Services in web applications

When the application is monitored by the Plumbr Browser Agent, service detection builds upon three components:

  • the URL at which the user was before the interaction
  • the interaction the user performed
  • the URL at which the user ended up after the interaction completed

monitoring web applications

In the example above, the user was viewing an invoice with the ID 123 and decided to pay the invoice by clicking the button Pay. The application processed the payment, after which the user remained at the same URL with the confirmation message that the invoice was paid successfully.

Plumbr identifies the service from this transaction as click “Pay” on /invoice/view/{1}. As seen from this example, all invoice payments carried out in the /invoice/view screen are grouped together under the same service.

Improving the service detection in web applications

There are known cases where out-of-the-box Plumbr configuration ends up with either services exposed via cryptic names. As a result you would see services similar to the following in Plumbr UI:

Key pressed on “div > list > filter > input#filter” at /user/search

This happens in situations where no human-readable elements were present to use as the identifier on the input field where the user performed the event. As a result of this, Plumbr used a fallback and exposed the DOM tree branch the event took place at. To replace this with a human-readable version, use “aria-label” attribute on such elements, so instead of

<input type="text"/>

you would use

<input type="text" aria-label="Name"/>

After this change, you would end up nicely formatted services with Key pressed on “Name” at /user/search for Plumbr. As a side effect, blind people also now have better access to the content of your site, as this is what the aria-label element was originally designed for.