Hi @Jenifer our problem was that from weblogic version 12 on, the services discovered by Dynatrace were being splitted for each node of the weblogic cluster [the service should have been unique and not splitted].
In order to overcome this situation [in order to unite all the services for the same weblogic cluster] we adopted this solution that implies a tagging strategy:
1. we understood we had to gor for a Service Detection Api (rule) > in particular a Detection Rule for a service of type: "Full Web Request"
2. to do so we first had to create a token with the right permissions for Dynatrace Configuration API
3. to make the rule apply we had to find a common criterion to our use case:
> We decided to automatic tag all weblogic process group major than version 12 and the services on top of it.
> we then pushed the POST api that stated: for each service tagged with the "tag above" aggregate services based on property applicationID, contextRoot and serverName before the delimiter "_"
The final result pushed with the POST was a payload of this kind:
{
"type": "FULL_WEB_REQUEST",
"metadata": {
"configurationVersions": [
0
],
"clusterVersion": "1.xxxxxxxxx"
},
"managementZones": [],
"id": "11242ff0-b27a-42c2-9a9b-zxxxxxx",
"name": "SCRsdr",
"description": "Aggrega correttamente tutti i web request services esposti da weblogic ver > 11g",
"enabled": true,
"conditions": [
{
"attributeType": "PG_TAG",
"compareOperations": [
{
"type": "TAG",
"compareKeyOnly": false,
"tags": [
{
"context": "CONTEXTLESS",
"key": "wlstagsdr"
}
]
}
]
}
],
"applicationId": null,
"contextRoot": null,
"serverName": {
"transformations": [
{
"type": "BEFORE",
"delimiter": "_"
}
],
"valueOverride": null
}
}
Hope this can help you move one your issue,
Ps while the documentation is generally very clear on Dynatrace help, in this case [Service Detection API] we found it a little bit harder to read and apply.
Regards
