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):
‎Jan 11, 2021 10:46 AM
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....
‎Jan 12, 2021 08:10 AM
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....
‎Jan 12, 2021 08:10 AM
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.
‎Jan 15, 2021 07:51 PM