Use-Cases for Upload API
JDisc Discovery has a new upload API using the importManager mutation in GraphQL. While the most common operation is to query data that has been discovered in a previous discovery run via a GraphQL query, the upload API mutation currently allows to add devices to the inventory from the outside of the JDisc server. Other types of objects will follow later. This can be helpful for a couple of use cases, of which we will look at a few.
Use Case 1: Add Devices for which there is no Discovery
While JDisc Discovery is able to discover most of the assets in a managed environment, it can still happen, that some assets are not known yet or there are other systems that manage these assets that are not yet integrated. One example of such a case is mobile devices that are usually in an enterprise context managed by a mobile device management (MDM) solution, such as Microsoft Intune.
JDisc Discovery does know smart phones and other mobile devices as device types already. So we can extract the information about the smartphone from the MDM solution using its API, for example in case of MS Intune the Graph API. This will include information such as the IMEI, ICCID, model and manufacturer of the device.
First we test this manually to see how the API is used, using the built-in GraphQL IDE in the JDisc Discovery web UI. This is an example inportManager mutation for a iPhone XR device and we see the adding has worked and no errors or warnings were returned:
Now we can translate this into a script, in this case we chose Python as programming language. The sample code can be found in the python example project on github:
https://github.com/jdisc/discovery-api-python-sample/blob/main/upload-device.py
The project also contains a sample device description in JSON format. You can test it by calling it
upload-device.py -u "account" -p "secret" -f sample-device.json
This would use the local server, in order to use a remote JDisc server use the -s option accordingly.
Use Case 2: Integration with other Discovery Solution
Large companies usually have a lot of different IT solutions in use in different areas. Suppose we have a department that has decided to use JDisc Discovery due to its speed, quality of discovery results and cost to aquire the software and operate the solution. Whereas the central IT department has decided to go for one of the big CMDB solutions with integrated discovery module for the enterprise IT. This could be products such as MicroFocus Universal Discovery (ex. HP Enterprise product), BMC Helix Discovery, ServiceNow Discovery or other. While these large integrated solutions will of course have additional cost and complexity added in order to operate them, that might not be a problem for the central IT, as they have lots of staff, maybe in India, you know the story.
Our department on the other side doesn’t have so much staff for the infrastructure and has decided to go for something small and inexpensive, which satisfies most of their needs. But from time to time there are some assets that they would need in their network inventory from the enterprise IT they use and therefore would like to get some data from the enterprise discovery solution into their system, which is JDisc Discovery.
Well, mostly the enterprise discovery solution will have some API available, mostly probably a larger set of RESTful APIs, although they might be harder to use, they typically exist. So what the department can do is, use this API to get the data of the assets they need and stuff it into the JDisc network inventory by means of the new GraphQL upload API. This could be done by a small script that is run scheduled from time to time as needed.
Use Case 3: JDisc Server Sync
In case a customer only has JDisc Discovery in use for discovery, it still can be, that there are multiple distributed environments with separate responsibilities and IT-technically separated by firewalls and network zones. In this case one usually installs a JDisc Discovery server in each of these zone, for example a cloud environment, the enterprise IT or in each branch office in order to avoid having to discovery via VPN connections. If that sounds familiar then you might guess that it would still, for ITSM processes, be very useful to have one central instance where one can do reporting and other activities on the discovered information from all assets in the whole company and not environment by environment.
Either the central database is a CMDB (see previous articles on i-doit), or one can use also a dedicated JDisc discovery server instance for thi spurpose. So a centrally running sync server would regularily poll all the other JDisc server services using the GraphQL query API on the one hand and upload that data to the central JDisc server service using the GraphQL upload API on the other hand. The sync script just needs to have a configuration file with the URLs and credentials of the remote JDisc servers.
Use Case 4: Home Office Discovery
Suppose JDisc Discovery discovers the complete enterprise and office IT with all the laptops and printers of all employees. Just that these devices are at the moment and maybe in the forseable future not in the office due to COVID-19. Also also in the future employees will spend a good part of their work time in the home office rather than on their work places. Of course one cannot install a JDisc discovery server in each home office, nor can one easily discover these remote parts of the enterprise network via the VPN easily. Discovery jobs usually run nightly and not during working hours in order to avoid disturbing normal operations and the anyhow fragile VPN connections should definitively be left in peace.
Nevertheless it is critical to have an up-to-date picture of the assets, the versions of OS and applications installed on these systems and collect some information that might be interesting for ISMS (information security management system) and ITAM (IT asset management) purposes. We cannot not discover these devices and capturing them the day the employee is in the office from time to time is not reliable enough.
Therefore what we could do is run a local script, deployed via endpoint management solution onto the endpoints (laptops of the employees in HO), that locally discovers the few thing that are interesting and then push these to the central JDisc discovery server service when the VPN connection is up. Locally this can be determined easily and tried until one gets through without the need to run a service on the endpoint for this purpose. Again, the GraphQL upload API serves as the endpoint that is contacted by the scripts, which could be written in Powershell on Windows or Python cross-platform, whatever the office equipment allows.
A sample script for such a local discovery using WMI using Powershell can be found in the JDisc github repository
https://github.com/jdisc/discovery-api-powershell
Such a script could simply be scheduled with the local Windows scheduler, run in the background and update the discovery database in the company IT.
Summary
We have seen that a small feature such as the new JDisc upload API as an extension to the existing JDisc GraphQL query API can enable a lot of useful use cases that do not require large investments in order to be solved pragmatically.
If you are especially interested in one of these use cases and think that JDisc should support this use case more out-of-the-box or have additional ideas what one could do with this feature, please let us know and talk to us.