In Part I of our “Building Web Services with RapidConnect” series, I described how to create a simple Web Service using RapidConnect. To summarize, any RapidConnect action set results in having a new Web Service API method. The primary benefit is that as a user, you are limited only by imagination and available data in building powerful Web Services for your own use.
Several years ago, “Virtual Directory” technology was quite the buzzword. The problem was that organizations had multiple, separate directory services, but LDAP-capable applications and systems only supported a single directory. So, the first Virtual Directory products came about, which provided a single LDAP interface for applications that, on the backend, were talking with multiple directories. The applications were unaware of the backend complexities and saw the complicated environment as a simple, single directory service instance.
Since then, Virtual Directory technologies have expanded beyond LDAP. What we now want in this sort of middleware is to have a simple API endpoint for our applications that returns a single view of data, regardless of the number of systems involved. Due to its explosive growth, the de-facto interface from application to Virtual Directory has become web services, and based on what we learned in Part I - The Basics, we know we can provide such an interface. We also know that RapidConnect, thanks to our extensive library of adapters, is capable of connecting to and querying 1,000’s of systems. Therefore, RapidConnect is a terrific Virtual Directory solution!
Scenario
There are truly unlimited use cases, but I have to pick just one to demonstrate for you the “power” of a Virtual Directory example!
We have an application, and this application wants login audit data. Specifically, it wants to get audit data from the audit tables and user identity data, which can only come from Active Directory. So, we want to support a web services method similar to this:
This method, as with most RESTful web services, will return a JSON object containing the expected data relevant to login events:
The first step is to figure out how to query the audit tables for the relevant records.
The results of this query will look similar to this:
This gives us almost everything we need. What we are missing is the identity data related to the perpetrator (aka the person logging in). For this, we can tie the “perpetrator_id” in the audit log to the “idautoID” attribute in Active Directory. From there, we can query for the attributes to populate the perpetrator identity data.
Now, let’s build our new Virtual Directory method!
The “System Variables”, “Open Connections”, and “Close Connections” are standard.
The “Query” section is where we get all of our login audit events for the date requested.
The “Process” section iterates the audit events, creates Connect Record (“results”) of the audit data, and includes identity data we find for the perpetrators. If you follow the logic, this is a series of embedded Connect Records.
Finally, in the “Return” section, we convert our Connect Record to JSON and return those results to the client.
When running this action set from the browser, you’ll get results similar to this:
If we copy the result data into a JSON “beautifier” we’ll see our results are exactly as expected.
So, we now have a RESTful web service, which as we learned in Part I, can be called from any system. We have created a single point for application queries that involve multiple backend systems.
In later blogs, I’ll cover how we can call such web services with RapidConnect and properly deal with the raw (XML or JSON) data returned.
Comments