how do we get java spring boot information to SAM

[deepaas]

anybody implemented / customized the plugin/pattern  to get Java spring boot information into the SAM table?

[Abhishek Pal]

Hi deepaas,

I did not implemented this giving you some related info might be help full for you, this can be implemented, but I would first clarify what you mean by "Spring Boot information in SAM."

If you mean:

Software Installation [cmdb_sam_sw_install]

I would NOT directly insert Spring Boot records into that table using a Business Rule or custom script.

Spring Boot is different from software such as Microsoft Office, SQL Server, or a JDK. It is normally packaged as a framework/dependency inside the application's JAR/WAR rather than installed as a separate operating-system package.

For example, a Spring Boot executable JAR normally contains dependencies under:

BOOT-INF/lib/

So standard installed-software discovery may detect:

Java / JDK / JRE

but not necessarily identify the Spring Boot framework/version inside every application JAR.

I would use one of the following approaches.

Option 1 - File-Based Discovery / ACC

If you mainly need to discover which servers contain Spring Boot libraries, this is the first OOB capability I would evaluate.

ServiceNow File-Based Discovery can scan:

- Windows
- Linux
- macOS
- JAR files
- ZIP files

Current releases also support archive scanning inside JAR/ZIP files.

For ACC File-Based Discovery, archive scanning is controlled by:

sn_acc_vis_content.file_discovery.archive_scan_enabled = true

When enabled, ServiceNow can inspect the archive index and report files contained inside a JAR.

For a Spring Boot executable JAR, you could therefore potentially discover entries such as:

BOOT-INF/lib/spring-boot-3.x.x.jar

or other Spring libraries.

Check the results in:

File Information
[cmdb_file_information]

and, if the file cannot be matched:

Unidentified File Set
[cmdb_unidentified_file_set]

If SAM has matching file-signature/normalization content, the identified software can ultimately populate:

Software Installation
[cmdb_sam_sw_install]

Important:

Archive scanning reports metadata from the JAR archive. I would test this with your actual Spring Boot packaging before assuming it will produce a normalized Spring Boot Software Installation automatically.

Option 2 - Custom Discovery Pattern

If you specifically require:

Server
Application
Spring Boot version
Java version
Application JAR
Running process

then a custom Discovery Pattern is probably the better solution.

I would not create a pattern that simply searches the entire filesystem.

Instead:

Running Java process
-> Determine executable/application JAR
-> Inspect the application JAR
-> Determine whether it is Spring Boot
-> Extract Spring Boot version
-> Populate the discovered application information
-> Sync the discovered software into SAM

A Spring Boot application can be identified from its executable archive structure and dependencies, for example:

BOOT-INF/classes
BOOT-INF/lib

You can inspect the archive for a runtime library similar to:

spring-boot-<version>.jar

and extract the version.

For example:

spring-boot-3.5.2.jar

-> Product:
Spring Boot

-> Version:
3.5.2

Do the extraction through the Discovery Pattern/MID Server rather than through server-side ServiceNow scripts.

Then use ServiceNow's supported SAM Pattern integration.

Open:

Pattern Designer
-> Discovery Patterns
-> Your Spring Boot/Application Pattern

Then:

Pre/Post Processing
-> Sync Installed Software

Add the software that should be synchronized.

Also create a record in:

Software Installation Name Mapping
[cmdb_sam_sw_name_mapping]

Configure:

Class name:
The class name used by your Discovery Pattern

Publisher:
Use the publisher value that matches your SAM normalization/content strategy

Product:
Spring Boot

ServiceNow specifically supports this mechanism for extending additional Discovery patterns into:

Software Installation
[cmdb_sam_sw_install]

The resulting architecture becomes:

Server
-> Discovery
-> Java process
-> Spring Boot JAR detected
-> Version extracted
-> Application/CI discovered
-> Sync Installed Software
-> cmdb_sam_sw_install
-> Software Discovery Model
-> Normalization

This is much safer than directly inserting cmdb_sam_sw_install records.

Option 3 - Third-party discovery

If another tool already knows the Spring Boot inventory, for example:

- Tanium
- Flexera
- SCCM/MECM extension
- Custom scanner
- Application inventory platform

do not build duplicate Discovery logic unnecessarily.

ServiceNow supports third-party SAM discovery through the IRE integration mechanism.

The third-party source should provide at least:

Display name
Publisher
Version
Installed-on CI

and ServiceNow can create the corresponding Software Installation and Discovery Model through the supported SAM ingestion process.

Option 4 - SBOM, which may actually be the better solution

If the requirement is:

"Which applications use Spring Boot 2.x / 3.x?"

or:

"Which Spring Boot / Spring Framework libraries and versions exist inside our applications?"

I would not use cmdb_sam_sw_install as the primary data model.

Use ServiceNow Software Bill of Materials (SBOM).

SBOM is designed specifically for:

- Open-source libraries
- Third-party components
- Component versions
- Dependencies
- License information
- Vulnerabilities

You can generate CycloneDX or SPDX during the Java/Maven/Gradle build and ingest the SBOM into ServiceNow.

For example:

Spring Boot Application
-> Maven / Gradle build
-> CycloneDX / SPDX
-> ServiceNow SBOM
-> Spring Boot component
-> Spring Framework components
-> Versions
-> Dependency relationships
-> Vulnerability information

This is much more accurate for Spring Boot applications because one application can contain dozens or hundreds of Java dependencies.

Recommended decision:

Need Java/JDK installation inventory:
-> OOB Discovery / SAM

Need to detect Spring Boot on servers:
-> File-Based Discovery or custom Discovery Pattern

Need Spring Boot represented as a SAM installation:
-> Custom Discovery Pattern
-> Sync Installed Software
-> cmdb_sam_sw_name_mapping

Existing external inventory:
-> Third-party discovery + IRE

Need Spring Boot/library/component/version/vulnerability inventory:
-> SBOM

Personally, for Spring Boot I would use:

SAM
-> Java runtime licensing/inventory

SBOM
-> Spring Boot and Java dependency inventory

and only create a custom Spring Boot SAM pattern if there is a specific license/compliance/reporting requirement that requires Spring Boot to exist as a Software Installation.

I would also check the current ServiceNow Content Service before building the customization. If your discovered Spring Boot publisher/product/version does not normalize, confirm the expected normalization with ServiceNow Content before hard-coding product/publisher values.

Official references:

Software discovery:
https://www.servicenow.com/docs/r/it-asset-management/software-asset-management/sam-software-discove...

Customize Discovery Pattern for SAM:
https://www.servicenow.com/docs/r/it-service-management/software-asset-management-foundation-plugin/...

File-Based Discovery:
https://www.servicenow.com/docs/r/it-operations-management/agent-client-collector/file-based-discove...

Third-party SAM Discovery:
https://www.servicenow.com/docs/r/it-asset-management/software-asset-management/configure-third-part...

Software Bill of Materials:
https://www.servicenow.com/docs/r/security-management/sbom-core/sbom-landing.html

Hope this helps!

If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.

Kind Regards,
Abhishek Pal