Understanding Azure Change Processing (ACP) for Cloud Discovery
Azure Change Processing (ACP) provides a near real-time method for updating the ServiceNow CMDB based on changes in the Azure environment and provides optimal performance when compared to Alert - driven discovery.
High-Level Architecture
The ACP process is divided into two distinct phases, each managed by a dedicated scheduled job:
Pull Phase (Scheduled Job: ACP Pull Changes) Queries the Azure Resource Graph API to identify changes that occurred within a specific timeframe and stores the raw JSON data in ServiceNow.
Process Phase (Scheduled Job: ACP Process Changes) Parses the raw data, maps it to CMDB attributes, and updates CI records.
Scoping Resource Types
The "brain" of the ACP process is the ACP Resource Type table (sn_itom_pattern_acp_supported_resource_types).
Defines which Azure resources (e.g., Virtual Machines, Disks, NICs) the system is permitted to track.
Contains the Azure Resource Graph Query used to fetch changes.
Note: For testing, I have set all types to false except virtualMachine.
Configuration & Setup
Enabling Azure Change Processing
To activate the ACP feature for a specific cloud account:
Navigate to All > Pattern Designer > Configure Azure Change Processing.
2. Select the desired Cloud Service Account
3. Click OK
4. Validate the confirmation message to ensure the integration is active.
Step-by-Step Execution Workflow
Phase 1: The Data Pull
Scheduled Job: ACP Pull Changes
1. Orchestration tracking: A record is created in Cloud Orchestrations (sn_cmp_order) to manage the outbound request.
The OrderFormData field contains the Instance Name, Credentials, and the specific Query used.
2. Order Status: A record is created to track this specific "pull" attempt. It links to the ACP Order Status (sn_itom_pattern_acp_order_status) and records the "Last Processed Time".
3. Raw Data Storage: For every changed resource found in Azure, a record is created in ACP Resource Changes (sn_itom_pattern_acp_resource_change) containing the Change Payload (the JSON snapshot of the change).
4. Resource Logging: A record is created in ACP Resource Status (sn_itom_pattern_acp_resource_status) for each resource ID to track whether the processing of this specific change was a success or failure.
Phase 2: The CMDB Update
Scheduled Job: ACP Process Changes
Queue Processing: The job identifies records in the ACP Resource Change (sn_itom_pattern_acp_resource_change) table that are in a "Ready" state.
Attribute Mapping: The system parses the JSON payload from ACP Resource Change and uses Response Mappings (sn_cmp_response_mapping) to translate Azure attributes (e.g., powerState) into ServiceNow CMDB fields.
Script of Response Mapping
getValue(global.JSON.parse(rawObject), sourceFieldValue);
function getValue(rawObject, sourceFieldValue) {
var vmState = rawObject.state;
//get only the state details
if (global.JSUtil.nil(vmState)) {
return 'terminated';
} else {
var length = "PowerState/".length;
vmState = vmState.substring(length, vmState.length);
}
switch (vmState) {
case 'starting':
return 'starting';
case 'running':
return 'on';
case 'stopping':
case 'deallocating':
return 'stopping';
case 'stopped':
case 'deallocated':
return 'off';
case 'deleted':
return 'terminated';
default:
return 'error';
}
}
I have stopped the TestVM, so the payload returns with "state":"PowerState/deallocated". The response mapping script processes it and returns "off".
Final Status Update: Upon completion, the corresponding record in ACP Resource Status (sn_itom_pattern_acp_resource_status) is updated to either Success or Failure.
To summarise all tables,
| Table Name | System Name | Description |
| ACP Resource Type | sn_itom_pattern_acp_supported_resource_types | Defines supported Azure resources and their Graph queries. |
| ACP Order Status | sn_itom_pattern_acp_order_status | Tracks the specific pull of the Query. |
| ACP Resource Changes | sn_itom_pattern_acp_resource_change | Stores the raw JSON payload received from Azure. |
| ACP Resource Status | sn_itom_pattern_acp_resource_status | Tracks whether a specific resource change was successfully processed into the CMDB. |
| Response Mappings | sn_cmp_response_mapping | Logic used to map Azure JSON keys to ServiceNow CMDB attributes. |
Key Advantages
No Webhooks: Unlike "Alert-Driven Discovery," ACP does not need a webhook for every subscription. It uses a single API (Resource Graph) that can look at the Management Group level.
Near Real-Time: By running every 5 minutes, your CMDB reflects "Retired" or "Off" states of VMs almost immediately, which is critical for cloud cost management.
Performance: It uses Response Mappings (direct data writing) rather than launching a "Heavy Discovery Pattern" for every tiny change, which prevents Azure from throttling your connection.
To test the payload received from Azure, you can copy the query defined for VirtualMachine in the ACP Resource Type table (sn_itom_pattern_acp_supported_resource_types) and run it in Azure Resource Graph Explorer to validate the output.
Azure Change Processing detects changes recorded by Azure Resource Graph change history.
It does NOT:
Detect changes that ARG does not capture
Replace full discovery entirely
Azure Change Processing should complement, not completely replace, periodic full cloud discovery to ensure the structural integrity of CMDB relationships.
Use Azure Change Processing + periodic full discovery.
If the above information helps you, kindly mark it as Helpful.
Regards,
Najmuddin
