We reviewed it but decided to write our own. Here's why.
- Requires the purchase of orchestration
- We had no requirement to initiate software installations from ServiceNow
- Only wanted hardware and software asset tracking
- Didn't like parts of the architecture
- No transform maps, instead that logic is hard coded
- No use of import set tables
- A new CMDB table called JAMF Computers. Preferred to put computers in the computer table, servers in the server table.
- Lacked centralized logging enabling an admin to troubleshoot.
- Duplicate hardcoded transform logic required updates in two places.
- Lacked support for uninstalled software being reflected in ServiceNow
- Not a great alignment to the Software Asset Management licenses and counters
- Typically Software Installation records have a Name, Publisher and Version, the paid for app puts the package name in JAMF in the Name field in ServiceNow.
- The App Store app approach works well for the orchestration use case.
- Assets stub records created through procurement had no reconciliation logic to not get a "duplicate" computer record created when the asset showed up in JAMF.
- Does not leverage the Identification and Reconciliation API.
We utilized the same Rest and Webhook API's the app store application uses. With the help an extremely knowledgeable JAMF admin we were able to add the Name, Publisher and Version information into the responses from JAMF. That person also added extension attributes to the JAMF response that help us track other useful information to facilitate Asset Management.
We're still monitoring performance as we haven't taken this to the production environment yet. The real time JAMF to ServiceNow webhook events are chatty, we're working to reduce the number of times per day JAMF updates ServiceNow.
Originally I wanted to design it more like the free SCCM integration using JDBC and scheduled jobs. We went with the Rest API's as a new database schema is rumored to be on the horizon for JAMF.
