App Broker and ServiceNow Clarification

[a_cutler2]

I'm hoping to get some clarification on a few things regarding the integration between App Broker and ServiceNow:

1. Is it the case that for a Catalog Item to sync with ServiceNow it has to have an SCCM package associated with it? If not, is that required for the status of the request to be updated in ServiceNow?

2. Also the customer in question would like to know what status updates occur in in ServiceNow the following scenarios (any details that can be provided would be helpful):

• AppBroker successfully installed the Software on machine through SCCM
• AppBroker cannot install the software as no package is available in SCCM
• No Licenses available

[CharlesW · Accepted solution]

Correct, in order to sync with ServiceNow, the catalog item must be a software catalog item, tied to an Application, Package, or Task Sequence. General catalog items do not sync.. My assumption is that App Broker requires a status in order to know when to close the Request/RITM, and a general catalog item will not provide this.. I suppose you could always work around this limitation by tying your catalog item to a dummy package, which really does nothing but return a success..

With regards to what's happening....

• Software successfully installed - App Broker sets the status on the request/RITM to closed_complete (both will be closed)
• Software package not available - This assumes that the package was still tied to the software catalog item, and that there was simply a problem with the package at a later time..  Ultimately, this will result in a failure in App Broker, either due to a lack of status, or a failure being returned by SCCM.. This will result in App Broker setting the status on the request to closed_incomplete (both will be closed)
• No licenses available - When requested through ServiceNow, the workflow will fail at the license check, so no request/RITM will be created.. As such, no request will be created in App Broker either.  

[jdempsey]

One correction to the reply from @CharlesW above.  For the "no license available" scenario, a Request and RITM will still be created in ServiceNow, because that's what triggers the workflow that checks for the license availability.  However, he is correct that the workflow will fail at the license check and will not submit a request to App Broker.  The default behavior of the sample workflow in ServiceNow will go to an "exception handling" branch that simply leaves the Request/RITM in an open state and sends an email notification to an administrator regarding the exception (though I don't know that a recipient is specified in that action by default, so it may be that no message gets sent unless the workflow gets updated to have a recipient).  Typically, when Flexera Services does an implementation of App Broker for ServiceNow, one of the things we modify in the workflow is the output of the license checks.  If a license is required and not available, we add some steps to create a catalog task and assign it to  the procurement team to go purchase a license.  Once procurement completes the purchase and closes the task, then the workflow can proceed to submit the request to App Broker for software installation.

With regard to general catalog items and ServiceNow, what Flexera Services does if the customer has a requirement to use general catalog items is to add a "dummy" package to them to make them into software catalog items.  Then we also add a custom variable to all catalog items to distinguish between software and general catalog items (e.g. ##Custom_CatalogType## = Software/General  OR  ##Custom_InstallationType## = Manual/Automatic).  Then we extend the schema of the x_fls_appportal_import_service table in ServiceNow to include a field where we can sync this custom variable value.  Once you have those custom values getting synced into the ServiceNow catalog items, you can include a new "if" block in the workflow just before the Submit Order action that will either submit the order (for software catalog items) or skip that step and perform some other action (for general catalog items).  Depending on the scenario, you might make it close the Request/RITM and go directly to the end of the workflow, or you might make it create another catalog task and assign it to some team to take further action before closing the ticket.