How do I create an application service map with multiple tag service candidates?

[JeffE]

Hello, 

I am hoping there is a way to do this. I have an application that runs in AWS. We are currently in the process of standardizing our tagging but we still have different tags representing the same application. How do I relate multiple service candidates to the same application service instead of having each tag variant be it's own separate map? 

Example: 

AWS currently tagged with app1, app 1, app-1. All these tags represent the same application but it will currently create three separate tags based application services. 

Any help would be greatly appreciated. 

Thanks, 

Jeff

[James Hammond]

Hi @JeffE 

Sounds like a bit of a complicated situation, are you using the tag based mapping feature through Service Mapping?  If so, it would be good to see how the Tag Categories have been setup?

Tag Governance is one of the areas that is not always standardised, so it's good you're going through the process to standardise.

[JeffE]

Hi @James Hammond ,

I have two tag categories: Application and Environment. For Application, I have variations of the app tag, which include application, app, app-name. For Environment, I have variations such as env and environment. In the tag-based service family, I have the Application tag category one and the Environment tag category at two.

From the example above, these would all create separate service candidates even if the environment tag didn't have any variation:

Key	Value	Service candidate
app	app1	app1::prd
application	app 1	app 1::prd
app	app-1	app-1::prd

What would be nice is if I can create a service map and select multiple service candidates to populate the map instead of them being separate. If I go through and create a tag-based map by manually inputting the key-value pairs, that works to an extent, but I am limited to three key-value pairs.

I hope this helps explain it a little more.

Thanks,

Jeff

[dzmitryKon]

Hi,
i don't think what you are describing is available OOTB.  And from me experience violates 2 things:

1. The whole idea of Tag-Based Service Mapping is to map based on "unique combination of Unique values" based on your tag families. Where in your case different tag values "mean" the same service.
2. Secondary, its always better to fix/clear data first, to make it reliable, before trying to fix it at ServiceNow side. 

However, if its not feasible to clear/normalise data in a first place (which i would strongly recommend), i believe you can add custom "normalisation" process for your tags. By creating and maintaining in service now a table of "tag value families" which "do mean the same services" and on every tag insert/update/per-schedule to update all values from the family to the same value, or even better to set "common" value for "normalised app" tag, created directly in ServiceNow.

Sounds like light/non-impactfull customisation to update data before picked up by tag-based mapping. with the extra work to maintain this mapping as a part of change/new service onboarding. So i strongly recommend to push for data quality.

Alternatively you can always create a manual App service, combining app1::prd, app 1::prd, app-1::prd. Should be good enough for event management/impact assessment.

Thanks,
Dzmitry

[GavinNZ]

I strongly disagree with you. We need to ability to combine multiple versions of Tags into one Service Map.Service instance. This response is the standard ServiceNow reponse, "We do it this way so all of IT needs to change".

To standardise our tags will take:

1. Over 1-2 years to do it naturally (implemented as other changes happen) or
2. As a project with significant costs with our vendors and time for staff.
   1. I have designed a solution that might work below.
   2. Estimated 4 hours work in ServiceNow building a Business Rule, Decision Table, and a one-off Script to fix existing data. 
   3. 4 hours time (plus some change control) vs $X00,000 in consulting and vendor costs to change their pipelines, run deployments, update documentation, change automated test scripts, etc. 

We have:

1. discovery running across multiple cloud and on-premise platforms
2. Deployment pipelines using GITHUB, Ansible, Terraform
3. Vendors supported applications
4. Cloud only services with no CIs

We have better things to do than spending significant time and money so we will be designing a solution in ServiceNow to update the Tags as they are written. Probably a combination of a Business Rule and Decision Tables to standardise it in ServiceNow.

This was just an Idea when I started writing this response but I went to Copilot (the worst of the AI coders) to knock something up for this post to feel complete. Gut feel, 2 hours and this solution would be solid (unless it stuffs with Discovery in some way), maybe 4 hours for  rock solid the logging and dashboard. 

1. Business Rule on Table: cmdb_key_value
2. When: before insert & before update
3. env_standard_values allows the rule to complete without any lookups for TAGS we are not interested in - Don't slow down discovery.
4. Decision table would probably be called by ID, have not even looked into the API call yet
5. Decision table allows us to adapt as the IT beast outside of ServiceNow marches on, and we can look at the usage to monitor the natural standardisation.
6. Maybe some logging and a Dashboard is needed if Decision Tables do not have the logging. 

(function executeRule(current, gForm, gUser, gSNC) {
    // Step 0: Define standard environment values
    var env_standard_values = ['dev', 'test', 'uat', 'prod', 'DR'];

    // Step 1: Check if the key is 'env' or 'environment'
    var key = current.key.toLowerCase();
    if (key !== 'env' && key !== 'environment') {
        return; // Not an environment key, do nothing
    }

    // Step 2: Check if the value is already standard
    var value = current.value.toLowerCase();
    if (env_standard_values.indexOf(value) !== -1) {
        return; // Already standardized
    }

    // Step 3: Look up the decision table
    var dt = new GlideDecisionTable('tag_environment_standard_values');
    dt.setInput('value', current.value);
    var result = dt.evaluate();

    // Step 3.1: If a result is returned, update the value
    if (result && result.getAnswer()) {
        current.value = result.getAnswer();
    }

})(current, gForm, gUser, gSNC);