Api

Much of my work lately involves interacting with the Okta API. It is a well documented API for those familiar with RESTful API development in their language of choice. If that doesn’t describe you (yet) then hopefully this post will help those of you with some R programming knowledge.
Scenario: You want to find out which credential a particular Okta user profile is using when accessing a specfic Okta application and change a credential value (in this example ‘userName’) if the current value doesn’t match the desired value.

I finally had some time to revist and improve a past project. This example illustrates retrieving all Okta user profiles assigned to a given application in Okta. As outlined in my earlier post, Okta limits the number of records returned depending on the API request so follow their cursor based pagination URLs to return all records if the number exceeds the API limit.
There are many reasons why you might want to retrieve this data.

A client wanted an easy way to quickly view upcoming event lists for any of their G Suite domain’s Google Resource Calendars. I tried keeping the solution entirely within R by using the googleAuthR package but domain-wide delegated authentication didn’t work properly for me so I reverted to Python. Without too much anguish I wrote a working parameterized script that returns Google resource calendar event details based on resource calendar ID and event count script arguments.

Okta is a popular single sign-on (SSO) service provider that enables secure application connections. It has a well documented API I reference when creating client reports based on data in their Okta instances.
REST API endpoint services typically limit the number of records returned per call via pagination. Okta API pagination is cursor based and pagination links are included in the link headers of responses. This basic example uses the httr and jsonlite packages to illustrate getting all records via a particular Okta API GET request by retrieving, parsing and following the link header values.

Using recursive SQL common table expressions (CTE) to build corporate hierachy reports is well documented use case for SQL CTE’s. I leveraged a SQL CTE to build a Shiny data table report that returns a client’s top down hierarchy based on user selection of an employee ID. The Shiny app uses the squr and RODBC pacakges to call the SQL script.
That report was useful but you never really know what someone wants until they ask.

Google Data Studio is a basic, yet functional report building and dashboard service for when you don’t need or want the power of something like RStudio Shiny, Power BI or Tableau. It has many data connectors and is tightly integrated into Google’s authentication ecosystem. I recently used it to build a simple yet effective business intelligence dashboard report for a client that saved them significant annual spend on a content analytics service.