What is the correct run order for OOTB SG-AWS Schedule Imports to resolve "Missing Dependency" error

String
Kilo Sage

3 weeks ago - last edited 3 weeks ago

Hello ,
 
I am implementing the out-of-the-box Service Graph Connector for AWS (SG-AWS) and repeatedly hitting "Missing Dependency" errors in the IRE logs for dependent CIs like cmdb_ci_nic and cmdb_ci_storage_volume.
The error indicates that the parent relationship is missing in the payload, even though my AWS IAM credentials pass the built-in diagnostic checks.
We have multiple scheduled data imports (SG-AWS-EC2-Instance, SG-AWS-ENI, SG-AWS-EBS-Volume, etc.).
 
attached the Scheduled Data Imports Order Screenshot1.png
 
My question is:
What is the mandatory or recommended sequential order to run these scheduled imports to guarantee that parent CIs are loaded into the CMDB before their respective child CIs, satisfying the CSDM rules and preventing this error?
 
 
Thank you!
0 Helpfuls
  • 590 Views
3 REPLIES 3

Matthew_13
Kilo Sage

3 weeks ago

@String  - 

This is a pretty common SG-AWS issue and it’s not your IAM setup.

In ServiceNow, child CIs (ENIs, EBS volumes)) will fail if their parent CIs don’t exist yet. If those imports run before EC2 instances, IRE throws the “Missing Dependency” error.

The fix I've used seems simple: run imports in order—accounts/VPCs → EC2 instances → then ENIs and volumes. Don’t schedule them all at the same time, and rerun the failed jobs once the parents are in place.

Thumbs up if this helps you; Thanks Kindly!

0 Helpfuls

String
Kilo Sage
In response to Matthew_13

3 weeks ago

Hi @Matthew_13 ,Thanks for your reply .

 

Iam bit worries to change the scheduled run order ,because we are using Out of the box set up and we have set time only SG-AWS-Organization and remaining has scheduled automatically(attached screenshot above ) .So if we change anything if may come under customization ?

0 Helpfuls

Matthew_13
Kilo Sage
In response to String

3 weeks ago

Totally understandable concern 🙂

You don’t need to worry;  changing the scheduled run order or timing is not considered customization.

You’re still using the OOTB setup, and you’re only adjusting when things run, not how they work. Since you’re not modifying any scripts or logic, this is treated as configuration, and it’s safe from an upgrade perspective.

In your case:

  • You’ve only set a specific time for SG-AWS-Organization

  • The rest are running on the automatically assigned schedule

  • Changing the run order or schedule just to manage dependencies is a normal and supported thing to do

It would only be considered customization if you were:

  • Changing the script of an OOTB scheduled job

  • Replacing it with a custom job

  • Altering the core logic

So as long as you’re just adjusting the schedule or order, you’re good. It’s also a good idea to document why you made the change, just for future reference.

 

Please mark Accepted Solution or give a Thumbs up if you found useful.

0 Helpfuls