_
_
For operations teams to effectively and efficiently support applications, a CMDB must be as complete and accurate as possible. This requires application teams to log into ServiceNow to ensure their Business Applications, Microservices (i.e., SDLC Components), and Application Services are defined and maintained. However, most application developers prefer to remain within their own toolset and don’t like the manual overhead of managing these entities directly in ServiceNow. This is where CSDM as Code (also called now.yaml) comes in; it allows application teams to dynamically register their Microservices and Application Services in the CMDB using YAML files in their source code repositories. By simply populating a YAML file, the relevant entities and relationships will be maintained in compliance with CSDM 4.0 - without application teams needing to know the intricacies of ServiceNow and CSDM terminology. It allows operations teams to gain improved visibility into application architectures and automatically generates Tag Based Service Maps.
CSDM as Code functions on an event-based trigger mechanism. Webhooks are configured for the repositories to call ServiceNow for commit push events (GitHub, Azure DevOps Repos, and GitLab are currently supported). When ServiceNow retrieves the webhook request, CSDM as Code performs validation on the filename path and branch to see if the file committed is a “now.yaml” file we care about (the valid filename paths and branches are configurable regex system properties in ServiceNow). If it passes those checks, CSDM as Code makes an API call back out to the SCM tool to get the actual contents of the YAML file. The YAML file is then processed with appropriate validations, the CMDB is updated accordingly, and the file committer receives a notification informing them of the processing result.
It is set up to allow organizations to structure their YAML files according to a schema that makes sense to them, with their own terminology. All that is required in ServiceNow is to ensure the YAML schema is modeled correctly, with the appropriate mappings and validation settings configured - CSDM as Code takes care of the rest. We refer to these configurations as CSDM as Code Entity Mappings and CSDM as Code Field Mappings, and seeded records come with each install to help you get started. This setup process ensures that CSDM as Code aligns with your organization's unique structure and terminology, making it a flexible and user-friendly solution.
As you can see above, the Entity and Field Mappings provide the flexibility to create your schema - it allows for nested entities and for you to name your own YAML Entities and YAML Keys. They also enforce your own validation rules, such as not allowing record creation for certain entities, failing the overall processing if records are not found, and the mandatoriness of keys. This flexibility ensures that CSDM as Code can adapt to your organization's specific needs and requirements. Three different types of field mappings are currently supported - Direct, Lookup, and Lookup on Nested Key. Direct mappings take the exact value defined for the key and set that as the value for the specified field in ServiceNow. The Lookup and Lookup on Nested Key allows for reference records to be mapped and set for the specified field in ServiceNow, without needing to know the internal sys_ids. The example YAML file below aligns with the mapping records above. Any of the entity and key names in the YAML file can be changed to anything, so long as they are also named the same thing in the mapping records in ServiceNow. Also, take note of the “tags” under “application_services” in the YAML file. These represent the tags that are expected to be found on the infrastructure that supports the microservice for the respective environment. This allows for automated Tag-Based Service Mapping - a user does not need to manually set up Tag-Based Service Families and map the Candidates in ServiceNow; it’s directly controlled via the YAML. It also allows for the Application Services to be created with the expected tag combinations even if those expected tags for the infrastructure don’t yet exist in the CMDB. When they do show up via Discovery or Service Graph Connectors, they will seamlessly be related to the correct Application Service. The below represents the Dependency View of the example YAML file, with the relationships downstream from the Production Application Service added via Tag-Based Service Mapping.
Request a trial of CSDM as Code today!
