Boomerang (Integrations) - With a hook - Michael Domingo -->

Tuesday, April 23, 2019

Boomerang (Integrations) - With a hook

Our career site requires us to Geocode our numerous locations inside Workday. I've handled this process using several different methodologies (EIBs, manual), but after a recent acquisition we had our location count grow by > 500. Enter another boomerang integration!


Google's Maps API is a robust method of geocoding addresses.  Head on over to grab an API key. Look for the Get Started button in the upper right. Don't forget to read the documentation - as there's a cost if you make over a certain number of calls. Google allows for a generous monthly allowance. My .CLAR has a spot to add the key in the API call as an attribute. You can also find my report definition along with the .clar file. Don't forget to add the key!

The Integration - RaaS report, splitter, and first properties collection

The first thing we need to do is use a RaaS Workday Out to get the report details we need into some properties in studio. Next I split the message up by report entry, this allows us on the push side to submit each message to Google individually. Then, I grab the Location ID, address values, name, and a few other requirements like the location hierarchy assignments. Why? I learned when I did this via EIB those are the minimum requirements to put the location back into Workday. YMMV, be sure to find out what you need.

The Integration - URL Encoding and HTTP out

We're getting to where the rubber meets the road. After some experimentation, I learned that if the address is not URL encoded (i.e. - we replace the spaces with + in the URL), the call fails. I write the address to a variable using a write step and use to properly encode the URL. Then I submit the entire string to google.

The Maps API call
Finally, the response is written to the message.

The Integration - Writing the response and Extracting the Lat/Lon

After we write the response to the message, we use a new eval step to pull out the latitude and longitude values, and call a subroutine to finally build the Put_Location API call.

The Integration - Re-Writing the Location and Error Handling

Finally, we use a write step to build the API call, call the Put, and get the SOAP response. I used an error handler to catch and report whatever mess I made in my sandbox tenant. What could possibly go wrong? As it turns out, a lot. Firstly, Latitude and Longitude are limited to 6 decimal places of precision. I needed to reformat the output from the Maps API using a series of eval steps:
Formatting output to 6 decimal places

Originally I didn't account for Google not returning an address due to bad data. I needed to capture the first part of the response (the status node) add an MVEL Validation step to the output to ensure the response was OK. If not, I threw an error.

My original mediation (steps 8-10) became this...

Next Steps

Google's output includes a measure of precision of the location match. I may want to take that into account when geocoding, or at least log precision that is less than a perfect (Rooftop, in Google parlance) match.


Thanks for your comment.

+1 215 262 6635
Philadelphia, PA