cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Regex for both lower and upper case “L”

sandeep
Inactive

I've a BT created to capture every other call except 2 URI’s, corporateselfserve/services/dictionary and corporateselfserve/login, however its not working as expected.
By creating another BT Filter/Splitting measure that has a “not regex” property looking for these two URI’s and put it in the splitting section of the BT and remove the “Complete URI” measure, started to show some values.
I also noticed that noticed that while we are excluding “corporateselfserve/login” there are occasion results with “corporateselfserve/Login” so how can Is there way to tweak the regex for both lower and upper case “L”.

14 REPLIES 14

JamesKitson
Dynatrace Leader
Dynatrace Leader

I think this should be in the AppMon an UEM forum if someone with the ability can move this.

To answer your question it should be as simple as using something like:

(L|l)

In the regex. So it would be something like:

corporateselfserve\/(L|l)ogin

To capture either uppercase or lowercase. The pipe says to accept either character there.

James

corporateselfserve\/(L|l)ogin
Will it require both \/ aswel ??

Yes, that is just to escape the forward slash in the url. You can play with the regex if needed here: https://regex101.com/r/wBYU7M/1

I tried and implemented the corporateselfserve\/(L|l)ogin. However, its still splitting value as corporateselfserve/login.fcc

If there can be ",fcc" at the end you'll need to add that to the regex as well as an optional piece like:

corporateselfserve\/(L|l)ogin(\.fcc)?

https://regex101.com/r/wBYU7M/2

It will interpret it exactly as written so if there are any variances you'll need to reflect that in the regex. The not-recommended and inefficient route would be to just place a .* which matches anything at the end. But the more preceise you can be the happier the server will be.

I am sorry...My bad .. the BT is created to capture every other call except the said 2 URI’s

Can you try using the noted regex with the 'not regex' option?

michael_kopp
Dynatrace Pro
Dynatrace Pro

Using (L|l) actually captures a group that is either L or l. Better would be to use [Ll] which matches a single character that is either L or l. It is much faster and does not lead to a group.

so the regex would be:

corporateselfserve\/[Ll]ogin

Nice tip! I'm far from a regexpert.

sandeep
Inactive

Its still getting captured, As suggested, i tried both corporateselfserve\/(L|l)ogin and corporateselfserve\/[Ll]ogin

I wanted the BT to capture every other call except 2 URI’s, corporateselfserve/services/dictionary and corporateselfserve/login,

Firstly I think you'll need to escape all of those forward slashes in the first part. Also I would start by testing your regex in some online tool before applying it to make things easier. I wasn't aware you were trying to use to patterns in one regex filter which would work but is more complicated which is why I would confirm your pattern matches in a tool. If that ends up being too complicated I would split it into two filter measures to keep it simpler.

.*corporateselfserve\/services\/dictionary|.*corporateselfserve\/[lL]ogin 

should address the need indeed.

Additionally - build in Regex tester should also work to check if regex meets your needs.

Be careful with using .* though. That at the beginning means it has to go through everything just in case it finds a pattern that matches later on. If you can include more precise matches at the beginning the less processing it will take on the server. A few such regex won't be an issue but it will add up over time. If you look in the server logs it will tell you the most expensive regex that it is being asked to run.

Finest answer from the cost of regex processing viewpoint would be like

^\/corporateselfserve\/services\/dictionary|^\/corporateselfserve\/[lL]ogin

depending on how complete URIs really look like. With or without leading .* regex engine has to go through whole tested string to see if pattern is matched. Not placing leading .* does not prevent from it apparently!