Building Enterprise Mashups using RSSBus: Part III

In the first two posts of this series, I looked at how to aggregate data from multiple sources and mash them up into a single data entity that could be consumed by an RSS client.  In this post, I will show off the new SOAP Connector from RSSBus.

Earlier in this series, I talked about mashing up data residing in databases, Excel workbooks and existing web services.  In my scenario, I have an existing web service that returns a set of master data about our customers.  This includes contact details and which sales reps are assigned to this customer.  Let’s see how I can go about calling this service through RSSBus.

Building an SOAP Feed

First of all, let’s take a look at what parameters are available to the new RSSBus SOAP Connector.  The default properties that this connector needs are: URL, web method, and method URI (SOAP action).  However, there are a generous amount of additional, optional parameters such as parameter declaration, specific XML nodes to return, SOAP header, credentials, proxy server details and more.

At the beginning of my RSSBus *.rsb file (which generates the XML feed), I specify the name of the feed, and, call out a specific input parameter (“customerid”) that the feed will require.

Next, I set the properties that I want to pass to the connector.  Specifically, I identify the web service URL, method name, SOAP action, input parameter, and the place where I want to log all inbound requests and outbound responses.

Now I can get a bit fancy.  I can pull out a particular node of the response, and work just with that.  Here, I dig into the XML service response and indicate that I only want the “Customer” node to be included in the result stream.  After that, I call out a series of XPath statements that point to the individual target nodes within that “Customer” node.  So, the final result stream will only contain these target nodes.

Here I call the web method, and take the response values and put them into a new “cms” (“Customer Master System”) namespace with friendlier node names.  Note that the values returned by the SOAP connector are named after the XPath used to locate them.  For example, an XPath of “/Name/OrganizationName/FullName” would result in a SOAP Connector response element named “Name_OrganizationName_FullName.”  As you can imagine, the names for deep XPath statements could get quite unwieldy.

If I make a request to this feed, I get back a nice clean result set.

Now, I have one additional web service that I need to call from RSSBus.  If you recall from part I of this series, I need a way to know WHICH systems a particular contact resides in.  My company has a “object registry service” that stores contacts along with a pointer to the systems (and keys) that know something about that contact.  So, I can use this service to identify which feeds I need to call in order to get a complete picture of my contact.

This RSSBus script takes in the name of the contact to find, calls my ORS (“object registry service”) service, and returns the systems that this person resides in.  In the resulting feed below, you can see that the ORS service found three records for this contact, and provides the name of the system (and primary key identifier) for each one.

What’s Next?

We’re close now.  I have feeds for a database, Excel workbook, Google web query, and two SOAP queries.  All that remains is to create the single feed that mashes up these system feeds and returns the single data result.

Stay tuned for the exciting conclusion.

Technorati Tags: RSSBus, Mashup