WS1 UEM Event Notifications
Several years ago I gave a presentation at the old AirWatch Connect Conference about automating your AirWatch deployment. As AirWatch evolved into Workspace One UEM, there has been a big effort to imporove the API functionality of the tool, to make it easier to integrate into your existing enterprise apps, and bulild additional workflows. This post will focus on a particular feature in the UEM console - Event Notifications.
In this walkthough we will use a couple of services to build a workflow that when a device enrolls, an Event notification is fired to a web service, that will process the event, and respond by calling the UEM api for adding a device tag. In practice, this enroll+tag workflow probably isnt something that would be deployed in a production environmnet, but builds the foundation to easy expand on.
Event Notifications in Workspace One UEM allow the UEM console to send a notification of an event in the UEM console, such as a device enrollment, unenrollment, compliance status change, etc.. to another service via http methods.
The VMware documentation for this feature can he found here
As mentioned in the intro, we are going to be using several services to build our end to end service. What is cool about this, is that we will get some exposure to some pretty neat tech that I generally don't touch on a day to day basis - things like node.js, serverless, API scripting,
To follow this guide step by step we will need the follwing. If your just using this as a reference, adjust based on your development environment:
Admin Access to a Workspace One UEM console
a test device to enroll and unenroll in UEM
Create a pipedream account
Once we have those 3 things - were ready to build our workflow
The first thing we have to do is get logged into pipedream and create a new event source
Head over to pipedream.com and if you dont have an account already, hit Get Started, if you have an account log in.
In the code editor window, click save, and then click deploy to make this a live serverless app
What will happen now, is that if trigger our workflow, either by generating test data in the workflow editor or by sending a message to the URL, the node.js console log will output our Everything is awesome message.
Let’s verify that by clicking the Send Test Event button
After a moment, a test event will be generated, and our node.js script runs, and we see in the console log output our message - very cool!
Workspace One UEM configuration
Building our app
Now that we finished enrolling our device into our UEM console, an Event notification should have been fired and a message received in our pipedream app. Let’s head over there to check it out.
Open your pipedream window and look for the most recent time stamped event
in the HTTP Webhook trigger section, expand the sted.tigger.event section and then expand the body section. Since we selected to use JSON as the output, we get a nicely formatted message of all the information contained about the device we just enrolled - pretty neat! check it out and get familiar with the fields it shared.
OK So what are we looking at the first line is telling node to load the axios http library, this allows us to send a POST http method to our UEM endpoint
The next block is building the POST message, defining the method - “POST" - the URL to send the POST to.
Here we need to make our first update. In place of the "TagID" change it to be the actual tag ID we collected earlier.
For example, instead of being: https://as1.awmdm.com/API/mdm/tags/TagID/adddevices
it should say: https://as1.awmdm.com/API/mdm/tags/12345/adddevices
The data field what the UEM API is expecting to contain the deviceID values. Here we are using a variable to dynamically gather the DeviceID that the UEM console sent to us in the Event notification. This way it will work for all devices as they enroll.
Below that are the headers we want to include with our POST request - and you need to update with your values we collected earlier.
The UEM API expects a few things in the headers of our request:
the API key - defined as aw-tenant-code
Authentication - with node when we define the "auth:" value it will convert the UN/PW combination to base64 for us
Here !! I AM ADMITTEDLY FOLLOWING BAD PRACTICES !! - we are going to hardcode our API key, API user and password into our code. As this is educational at this point, I am OK with that, if this was anything more than that, there are much more secure ways to handle the credentials.
Copy the code upadated with your valies and replace the "Everything is awesome" code in our pipedream editor. Update the values we just reviewed - the TagId, API key, Username and Password
Look for any errors the code editor may flag - tip - sometimes quotation marks get a little mixed up
Save and deploy the code change
OK so quick recap, at this point we have configued UEM to send a notification from the UEM system to pipedream every-time a device enrolls. That notification contains a number of pieces of device information. Once the notification hits our pipedream endpoint, it moves into the node.js code and gets the deviceID of the device that just enrolled. Once it does that it sends a command back to the UEM console to apply the "pipedream" device tag to the device that just enrolled.
Let's test it out!
Start by deleting your test device from the UEM console.
Bring up your pipedream workflow
Enroll your device again and monitor the UEM console and pipedream console. You should see your device appear in the UEM console, a new event be logged in the pipedream console and if you refresh the uem device list view your tag will be applied.
OK so as I mentioned just adding a tag on enrollment alone probably isnt much value - but if you got more complex with your node application code, you could apply tags based on a bunch of different things, or differnt UEM events as well. Rather than pointing back at UEM maybe your node code goes to a totally different system! There are tons of options and I would love to hear what you come up with!