Custom clean URL Rules, how does this really work?

[r_weber]

I'm struggling with the clean URL rule for services. Haven't found a single working solution apart from using request naming rules (I don't want to use request naming rules if clean url rule feature exists).
Does someone have a clear explanation on how these regexes should look like?

From the example given in the UI I'd assume one defines capture groups in the regex and the capture groups would form the "new" url value.

Eg if my URL is:

/api/v3/domain/products/000840001903

and my "clean url regex" is 

(.*\/products?\/)[0-9]*(.*)

then I'd assume the clean url becomes:

/api/v3/domain/products/

 (which would be the concatenation of the capture groups?)

But instead of that I do get the whole URL replaced with "/"

The examples look similar, though all seem to only work for query parameters, not for URL paths.

Documentation with further examples on that feature is also missing and it seems lots of people have the same issue...

[andrew_knackste · Accepted solution]

Dynatrace is a bit... Unusual in the way it handles Regexes. In this scenario, it's removing all of the matched text in your regex.

Can you try this?

`(?<=\/products\/)\d+(?=\/)`

[r_weber]

Hi @andrew_knackste 

This is indeed a bit unusual and not really obvious 🙂 Thanks for sharing! The lookahead match works.

I'm just questioning the feature right now as it somehow overlaps with request naming rules and can't even be applied globally or via an API. Also it would be really useful if a "clean url rule" would have options to REPLACE the found string with a custom string like "<productid>" so that the user would know that something has been removed here.

This would be especially useful if you have a scenario where you remove multiple parts like: 

/api/v3/CAT-0432A/products/000840001903

 The result of one or multiple clean url rules would be

/api/v3/<category ID>/products/<product ID>/

I think I'll add an RFE for that.

[Julius_Loman]

Yes, it definitely overlaps with naming rules. I'm also missing the replacement feature as typically just removing parts may result into two different request types being joined. For example:

• /customers/delete
• /customers/123/delete

That's why I mostly try to use naming rules instead. For an example of how to cleanup such IDs globally across services, see my tip.