OCI Load Balancers are currently not supported by Discovery - is there any workaround?

Vivi Brasil
Kilo Sage

Hello, I know Oracle Cloud Infrastructure Load Balancers are currently not supported by Discovery (horizontal discovery). I would like to know please, if someone here has already created Patterns or customized other objects, to be able to discovery the OCI LBs.

 

I am asking it, because we have some Mapped Applications Services, which migrated from on-premise to OCI environment.

 

The Service Mapping Discovery (top-down discovery), worked well to update most of Maps, after the migration of the Applications, because the migrated Load Balancers are usually hosted in OCI, but they do not use OCI technology (they are WebLogic Load Balancers, among other technologies, hosted in OCI).

 

Only one Mapped Application Service, has migrated from NetScaler LB to a OCI LB, and the VIP Service (which is the Map Entry Point), is exactly this OCI LB. How the horizontal-discovery does not work anymore after the migration, the top-down discovery does not work as well.

 

I would think another option, should be: migrate this specific Mapped Application Service, to Tag-Based, but I was wondering if someone has experienced something similar with OCI.

 

Any help would be really appreciated! Thank you!
Vivi Brasil

1 ACCEPTED SOLUTION

AJ-TechTrek
Giga Sage
Giga Sage

Hi @Vivi Brasil ,

 

Answer in Short, Out-of-the-box, OCI Load Balancers aren’t discovered by ServiceNow. To support them you’ll need either:
* A custom discovery pattern using OCI APIs, or
* A tag-based service mapping approach as a workaround.
The most sustainable path is to implement a custom pattern that populates cmdb_ci_lb for OCI LBs, so both horizontal discovery and service mapping work seamlessly.

 

As per my understanding why It’s Not Working
* Horizontal Discovery (patterns): Out-of-the-box (OOB), ServiceNow Discovery doesn’t include patterns for OCI Load Balancers. So, when your CI is a VIP / LB, it won’t be identified automatically.
* Top-Down Service Mapping: When your entry point is the OCI LB, Service Mapping tries to resolve it via horizontal discovery — but since the LB isn’t discovered as a CI, the chain breaks.
* Result → You can’t map the application fully.

 

Options to solve This which might be helpful


1. Custom Discovery Pattern for OCI Load Balancer
* Create a custom pattern under Discovery Patterns (cmdb_ci_lb or cmdb_ci_load_balancer_virtual_server classes).


* Discovery Options:
* OCI REST APIs: Oracle provides public APIs to retrieve LB details (/20170115/loadBalancers endpoints).
* You can use Cloud Discovery → Custom Cloud Patterns → call OCI API with an integration user.
* Parse JSON → populate CI attributes like Name, IP, VIPs, listeners, backends, etc.
* Tie it to the cmdb_ci_lb or a custom subclass cmdb_ci_oci_lb.
This way, you extend horizontal discovery to include OCI LBs.

 

2. Extend Service Mapping (Top-Down)
* In the pattern for your service entry point, add a custom identification step that looks for your OCI LB CI (instead of the default NetScaler / F5 patterns).
* If you’ve created the LB CI via custom discovery (step 1), Service Mapping can link to it.

 

3. Tag-Based Service Mapping (as fallback)
* Like you mentioned, you can switch this application service to Tag-Based Mapping.
* If OCI resources are consistently tagged (app=XYZ, tier=frontend), you can use those to dynamically build service maps.
* Downside: you lose the flow-based accuracy, but it works as a quick fix.

 

4. Hybrid Approach
* Use custom integration (REST / MID Server) to fetch LB config from OCI, insert/update into CMDB as cmdb_ci_lb.
* Then augment Service Mapping to consume this CI → either as entry point or dependency.
* This keeps your map accurate without fully rewriting discovery logic.

 

Recommendation (Best Practice)
1. Short term: For the one service that broke, use Tag-Based Service Mapping so your business isn’t blocked.
2. Medium term: Build a custom OCI LB discovery pattern leveraging OCI APIs, so horizontal discovery can identify and classify them.
3. Long term: Standardize OCI tagging + extend Cloud Discovery for OCI across the org (LBs, Compute, DBaaS, etc.), aligning with CSDM and multi-cloud CMDB strategy.

 

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

View solution in original post

2 REPLIES 2

AJ-TechTrek
Giga Sage
Giga Sage

Hi @Vivi Brasil ,

 

Answer in Short, Out-of-the-box, OCI Load Balancers aren’t discovered by ServiceNow. To support them you’ll need either:
* A custom discovery pattern using OCI APIs, or
* A tag-based service mapping approach as a workaround.
The most sustainable path is to implement a custom pattern that populates cmdb_ci_lb for OCI LBs, so both horizontal discovery and service mapping work seamlessly.

 

As per my understanding why It’s Not Working
* Horizontal Discovery (patterns): Out-of-the-box (OOB), ServiceNow Discovery doesn’t include patterns for OCI Load Balancers. So, when your CI is a VIP / LB, it won’t be identified automatically.
* Top-Down Service Mapping: When your entry point is the OCI LB, Service Mapping tries to resolve it via horizontal discovery — but since the LB isn’t discovered as a CI, the chain breaks.
* Result → You can’t map the application fully.

 

Options to solve This which might be helpful


1. Custom Discovery Pattern for OCI Load Balancer
* Create a custom pattern under Discovery Patterns (cmdb_ci_lb or cmdb_ci_load_balancer_virtual_server classes).


* Discovery Options:
* OCI REST APIs: Oracle provides public APIs to retrieve LB details (/20170115/loadBalancers endpoints).
* You can use Cloud Discovery → Custom Cloud Patterns → call OCI API with an integration user.
* Parse JSON → populate CI attributes like Name, IP, VIPs, listeners, backends, etc.
* Tie it to the cmdb_ci_lb or a custom subclass cmdb_ci_oci_lb.
This way, you extend horizontal discovery to include OCI LBs.

 

2. Extend Service Mapping (Top-Down)
* In the pattern for your service entry point, add a custom identification step that looks for your OCI LB CI (instead of the default NetScaler / F5 patterns).
* If you’ve created the LB CI via custom discovery (step 1), Service Mapping can link to it.

 

3. Tag-Based Service Mapping (as fallback)
* Like you mentioned, you can switch this application service to Tag-Based Mapping.
* If OCI resources are consistently tagged (app=XYZ, tier=frontend), you can use those to dynamically build service maps.
* Downside: you lose the flow-based accuracy, but it works as a quick fix.

 

4. Hybrid Approach
* Use custom integration (REST / MID Server) to fetch LB config from OCI, insert/update into CMDB as cmdb_ci_lb.
* Then augment Service Mapping to consume this CI → either as entry point or dependency.
* This keeps your map accurate without fully rewriting discovery logic.

 

Recommendation (Best Practice)
1. Short term: For the one service that broke, use Tag-Based Service Mapping so your business isn’t blocked.
2. Medium term: Build a custom OCI LB discovery pattern leveraging OCI APIs, so horizontal discovery can identify and classify them.
3. Long term: Standardize OCI tagging + extend Cloud Discovery for OCI across the org (LBs, Compute, DBaaS, etc.), aligning with CSDM and multi-cloud CMDB strategy.

 

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025

Hi @AJ-TechTrek ,

 

Thank you so much for such an in depth answer. I really appreciate all your efforts to help me in this matter, thanks a lot for this very good explanation!

I am going to review these options with the customer, now I have the paths to work on it.

 

Best regards,
Vivi Brasil