cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Confirming Install for ServiceNow Ticket Closure

Could someone please help me understand how App Broker, when using ServiceNow as the front end, confirms software has been successfully installed and therefore closes the ServiceNow request/ticket? A customer is looking for details on how this works. 

(1) Solution

When ServiceNow submits a request to App Broker, the ServiceNow Request/RITM remain in an "open/pending" state, waiting for App Broker to update them according to the result of the deployment.  App Broker periodically queries SCCM for deployment status and then makes a SOAP call to ServiceNow to update the Request/RITM with the results of the deployment.

Checking Status in SCCM and Translating into App Broker Status Values - App Broker runs a few SQL queries against the SCCM database (depending on whether a package or application).  The resulting status is translated into "Success", "Failure", or "Pending" in App Broker status terms based on the configuration at the bottom of the Deployment System settings page (you'll find both status ID mappings and app enforcement state mappings).

Acting on the App Broker Status - If a "Success" status is received, that status is immediately updated in ServiceNow.  If a "Pending" status is received, App Broker continues to wait until the "wait timers" expire, at which point App Broker considers it a failure, since the status hasn't been updated in reasonable period of time.  If a "Failure" status is received, App Broker will wait until the "false failures" timer has expired before raising that failure to ServiceNow, since SCCM can retry on certain failures and may resolve itself.  This timer just allows time for SCCM to complete those retries and potentially change the status to "Success" before we (potentially incorrectly) update ServiceNow.

Updating the Status in ServiceNow - The above App Broker statuses are then mapped to ServiceNow Request and RITM state values based on the settings configured on the ServiceNow Integration settings page (see ServiceNow Requested Item State Mapping and ServiceNow Request State Mapping).  Normally, I suggest disabling the checkbox for "Update ServiceNow Request State", as you should really only be updating the RITM state and ServiceNow should automatically update the parent Request based on the state of all child RITM's.

Let me know if you need any more detail than this.

Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".

View solution in original post

(1) Reply

When ServiceNow submits a request to App Broker, the ServiceNow Request/RITM remain in an "open/pending" state, waiting for App Broker to update them according to the result of the deployment.  App Broker periodically queries SCCM for deployment status and then makes a SOAP call to ServiceNow to update the Request/RITM with the results of the deployment.

Checking Status in SCCM and Translating into App Broker Status Values - App Broker runs a few SQL queries against the SCCM database (depending on whether a package or application).  The resulting status is translated into "Success", "Failure", or "Pending" in App Broker status terms based on the configuration at the bottom of the Deployment System settings page (you'll find both status ID mappings and app enforcement state mappings).

Acting on the App Broker Status - If a "Success" status is received, that status is immediately updated in ServiceNow.  If a "Pending" status is received, App Broker continues to wait until the "wait timers" expire, at which point App Broker considers it a failure, since the status hasn't been updated in reasonable period of time.  If a "Failure" status is received, App Broker will wait until the "false failures" timer has expired before raising that failure to ServiceNow, since SCCM can retry on certain failures and may resolve itself.  This timer just allows time for SCCM to complete those retries and potentially change the status to "Success" before we (potentially incorrectly) update ServiceNow.

Updating the Status in ServiceNow - The above App Broker statuses are then mapped to ServiceNow Request and RITM state values based on the settings configured on the ServiceNow Integration settings page (see ServiceNow Requested Item State Mapping and ServiceNow Request State Mapping).  Normally, I suggest disabling the checkbox for "Update ServiceNow Request State", as you should really only be updating the RITM state and ServiceNow should automatically update the parent Request based on the state of all child RITM's.

Let me know if you need any more detail than this.

Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".