Category: General Architecture

We conclude this series of blog posts by demonstrating how to take a set of feeds, and mash them up into a single RSS feed using RSSBus.

If you’ve been following this blog series, you’ll know that I was asked by my leadership to prove that RSSBus could generate a 360° view of a “contact” by (a) producing RSS feeds from disparate data sources such as databases, web services and Excel workbooks and (b) combining multiple feeds to produce a unified view of a data entity.  Our target architecture looks a bit like this:

In this post, I’ll show you how to mash up all those individual feeds, and also how to put a friendly HTML front end on the resulting RSS data.

Building the Aggregate Feed

First off, my new aggregate feed asks for two required parameters: first name and last name of the desired contact.

Next, I’m ready to call my first sub-feed.  Here, I set the input parameter required by the feed (“in.lastname”), and make a call to the existing feed.  Recall that this feed calls my “object registry service” which tells me every system that knows about this contact.  I’ve taken the values I get back, and put them into a “person” namespace.  The “call” block executes for each response value (e.g. if the user is in 5 systems, this block will execute 5 times), so I have a conditional statement (see red box) that looks to see which system is being returned, and setting a specific feed value based on that.

I set unique feed items for each system (e.g. “person:MarketingID”) so that I can later do a check to see if a particular item exists prior to calling the feed for that system.  See here that I do a “check” to see if “MarketingID” exists, and if so, I set the input parameter for that feed, and call that feed.

You may notice that I have “try … catch” blocks in the script.  Here I’m specifically catching “access denied” blocks and writing a note to the feed instead of just blowing up with a permission error.

Next, I called the other data feeds in the same manner as this one above.  That is, I checked to see if the system-specific attribute existed, and if so, called the feed corresponding to that system.   My “reference data” feed which serves up Microsoft Excel data returns a data node that holds the blog feed for the contact.  I took that value (if it exists) and then called the built-in RSSBus Feed Connector’s feedGet operation and passed in the URL of my contact’s blog feed.  This returns me whatever is served up by my contact’s external blog.

Neat.  So, now I have a single RSS feed that combines data from web services, Google web queries, Excel workbooks, SQL Server databases, and external blog feeds.  If I view this new, monster feed, I get a very denormalized, flat data set.

You can see (in red) that when data repeating occurred (for example, multiple contact “interactions”), the related values, such as which date goes with which location, isn’t immediately obvious.  Nonetheless, I have a feed that can be consumed in SharePoint, Microsoft Outlook 2007, Newsgator, or any of your favorite RSS readers.

Building a RSSBus HTML Template

How about presenting this data entity in a business-friendly HTML template instead of a scary XML file?  No problem.  RSSBus offers the concept of “templates” where you can design an HTML front end for the feed.

Much like an ASP.NET page, you can mix script and server side code in the HTML form.  Here, I call the mashup feed in my template, and begin processing the result set (from the “object registry service”).  Notice that I can use an enumeration to loop through, and print out, each of the systems that my contact resides in.  This enumeration (and being able to pull out the “_value” index) is a critical way to associate data elements that are part of a repeating result set.

To further drive that point home, consider the repeating set of “interactions” I have for each contact.  I might have a dozen sets of “interaction type + date + location” values that must be presented together in order to make sense.  Here you can see that I once again use an enumeration to  print out each date/type/location that are related.

The result?  I constructed a single “dashboard” that shows me the results of each feed as a different widget on the page.   For a sales rep about to visit a physician, this is a great way for them to get a holistic customer view made up of attributes from every system that knows anything about that customer.  This even includes a public web (Google) query and a feed from their personal, professional, or organization’s blog.  No need for our user to log into 6 different systems to get data, rather, I present my own little virtual data store.

Conclusion

In these four blog posts, I explained a common data visibility problem, and showed how RSSBus is one creative tool you can use to solve it.  I suspect that no organization has all their data in an RSS-ready format, so applications like RSSBus are a great example of adapter technology that makes data extraction and integration seamless.  Mashups are a powerful way to get a single real-time look at information that spans applications/systems/organizations and they enable users to make more informed decisions, faster.

Technorati Tags: RSSBus, Mashup

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

In the previous post, I laid out a data visibility problem and proposed using RSSBus to build an enterprise mashup that inflates a single data entity whose attributes reside in multiple disparate systems.

Before a mashup can be built, we actually need the source data in a ready-to-mashup format.   For the mashup I am building, my “contact” data resides in 3 different repositories:

• Database containing the interactions we’ve had with a particular contact
• Web service talking to a CRM system which holds core contact information
• Excel spreadsheet containing external reference data such as the contact’s public web page and blog

On top of this, my mashup will also return a Google result set based on the contact’s first and last name.  If available, I also want to retrieve the latest information from the contact’s personal blog (if they have one).

In this post, I will show how to create the feeds for the database, Excel spreadsheet, and Google query.

Building an Excel Feed

My first data source is an Excel spreadsheet.  The Excel Connector provided by RSSBus has a variety of operations that let you add rows to sheets, list worksheets in a workbook, create new workbooks, and get data out of an existing spreadsheet.

For our case, we used the excelGet operation that accepts the file path of the workbook, and which sheet to pull data from.  A simple test can be executed right from the connector page.

The result of this query (formatted in HTML) looks like this:

Notice how the Excel data comes back using an “excel” namespace prefix.

In my case, I don’t want to return the contents of the entire workbook, but rather, only the record for an individual contact.  So, from this Connector page, I can choose to create a feed out of my sample query, and then I can modify the RSBScript to filter my results, and, to put my result set into a different namespace than “excel.”

At the top of my new feed, I outline the title of the feed, and, create a new required input parameter named “contactid.”  Input parameters are passed to the feed via the querystring.

Next, I need to set the parameters needed by the Excel Connector.  You may recall that we set the parameters when we tested the Connector earlier.

Now comes the meat of the feed.  Here I “call” the Excel operation, do an “equals” check to see if the row in the spreadsheet is for the contact with the designated contact ID.  If I find such a row, then I create a new “myitem” entity and populate this hash with the values returned by the Connector and sitting in an “excel” namespace.  Finally, I “push” this item to the response stream.

So what does this completed feed look like?  Below you can see our feed item containing the nodes in a “reference” namespace.  I now have a valid RSS feed that monitors an Excel workbook.  Hooray for me!

Building a Database Feed

Now, let’s take an existing SQL Server database and return some results as RSS.  In my scenario, I have a table for all our contacts, and another table with all the interactions we’ve had with that customer (e.g. lunch, office visit, speaker invitation).  The RSSBus SQL Server Connector has a wide range of operations available which perform database inserts, updates, deletes, as well as stored procedure calls, and schema queries for tables, views and more.

This feed starts much the same as the last one with a title and description.  I’ve also added a required input parameter for the contact ID stored in the database.  Next I have to set the parameters (connection and query) needed by the sqlQuery operation.

Note that most connector operations have a wide range of optional parameters.  For the sqlQuery operation, these optional parameters include things like “maxrows” and “timeout.”

Now I need to call the operation.  Like the feed above, this feed takes things that come back in the “sql” namespace and put it into an “interactions” namespace.  Be aware that the “push” statement pushes EACH returned row as a separate feed item.

What does my response look like?  The image below shows how I returned three items in this feed; each represents a different interaction with this contact.

Now I have two feeds based on existing data repositories, and didn’t have to make a single change to those applications to support their RSS-ification.

Building a Google Feed

The final feed we’ll look at here is public internet search for our selected contact.  The Google search results should come back in an RSS format that can be consumed by my mashup feed.

My feed takes in two required parameters: “firstname” and “lastname.”   Next, I need the two critical parameters for the Google gSearchWeb operation.  I first must pass in a valid Google API token (you’ll need to acquire one), and, the search string.

Now I call the operation, and push each result out.

Neato.  I can call Google on the fly and make custom queries based on my contact.

What’s Next?

Here we saw how easy it is to build the RSSBus script necessary to expose RSS feeds from systems that don’t actually speak RSS.

Next, we’ll see how to work with new RSSBus SOAP connector to query our CRM system, AND, to query my “object registry service” which returns all the system primary keys related to my contact.  After that, we’ll see how to mash all these feeds up, and return a single “contact” entity to the RSS client.

Technorati Tags: RSSBus, Mashup

I’ve been a fan of RSSBus from /n software for some time. A few weeks ago our Executive Director / Chief Architect / Technology Overlord recently asked me to build a real, live enterprise mashup application to demonstrate for our IT leadership group. Our goal was to show that RSSBus could be used to quickly and efficiently aggregate data in compelling new ways.   In the next few posts, I’m going to walk through our use case, and how I built a solution to solve this.

Before getting into the “what” and “how”, I want to first say that the “how I built a solution” line above isn’t entirely true.  The folks at RSSBus actually built most of the solution for me, and all I did was tweak and customize it a bit.  If you ever get a chance to work with rock stars Ralph James, Amit Sharma or Tom Hearn, jump at it.  I’ll also note that I am working with a pre-release version 2.0 of RSSBus that has new features such as a SOAP connector.

The Problem

As with most large organizations, we have a multiple systems and repositories that contain different aspects of the same data entity.  A “contact” at my company has some attributes stored in our ERP system, some in custom built systems, and some more in COTS applications.  Maintaining a true system of record is difficult in our environment and trying to keep enterprise data repositories in sync is no small task.

Some questions I want answers to …

• How does a sales rep heading out on a physician visit get a full 360 degree view of the customer that shows EVERYTHING we know about this person?
• How do I allow people to be proactively notified of any changes to a given sales region or key contact?
• How do I easily accommodate new data sources (e.g. COTS application, public internet blog or website)?
• Where can I apply the appropriate security measures to make sure that sensitive contact details are only available for those allowed to see them?  For instance, sales folks may not be allowed to see what clinical trials a physician is participating in, while scientists are not allowed to see marketing activities that a physician has been involved with.

This category of problem can also extend to “complex event processing” scenarios where you want to be able to perform intelligent surveillance on related events that span systems.   However, the problem I’m addressing for us at this moment has to do with data aggregation, not event aggregation.

A Solution

One valid solution to this problem is to use XML feeds (RSS / Atom) from source systems and aggregate them to return a single, complete view of the target data entity.

Why XML feeds instead of a new database repository?  Our reasons include:

• Subscription model using XML feeds provides users with a great ability to discover, organize and monitor data that sits in multiple places
• Consumption experience NOT dictated by data generator as end users can choose to eat this data in their feed reader (e.g. Outlook 2007), Excel, SharePoint or custom application
• Provides a virtual, on-demand data aggregation with minimal changes needed in source systems
• The pub/sub nature of XML feeds gives users more “sensors” into key data elements in an organization and allows them to receive and act on data in a more timely fashion
• XML feeds allow an alternate level of service where a query does not have to return real time data or in an immediate fashion

Once I have a feed for each system that stores “contact” details, I want to mash them all up and return a single XML feed that shows an entity whose data comes from all types of data stores.

Now, how do I know which systems this “contact” exists in? At my company, we have a “object registry service” that our applications use to both publish and query enterprise objects.  For instance, we have CRM applications which send “insert” and “update” commands to this service when contact data has changed.  This service is responsible for performing data cleansing on inbound data, and matching inbound objects to existing objects.  The “Richard Seroter” contact inserted by System A should be matched to the “Richard L Seroter” that was already inserted by System B.  What this service stores is only enough information to perform this matching, and, the originating system and primary key.  So, the point is, I can query this service for “Richard Seroter”, and get back all records matching this query, AND, which system (and ID) stores information about this handsome character.

One other wrinkle.  Clearly, many (most?) COTS and custom applications do NOT offer RSS feeds for their underlying data.   So how do I go down this route of XML feeds with systems that don’t natively “talk” RSS? This is where RSSBus comes in.

What is RSSBus?

RSSBus is a lightweight, completely web-based platform for building and publishing XML feeds out of a wide variety of source systems.  It’s a service bus of sorts that takes advantage of the loose contract of RSS to expose and aggregate feeds into interesting business services.

RSSBus uses an impressive array of “connectors” to sources such as Amazon Web Services, PayPal, Microsoft CRM, MySQL databases, Federal Express, Twitter, FTP, LDAP, BizTalk Server and much more.  This means that you can create a feed out of a file directory, or use XML feeds to create new LDAP accounts.   Endless possibilities.

The RSSBus Administration Console can be used to browse connectors, and then use a visual wizard to prototype and generate XML feeds.  You also have full access to the robust RSBScript language which is actually used to generate the raw feeds and optionally, the RSBTemplates which present feed data in an HTML format.  It’s almost a misnomer to call the product RSSBus since data can be emitted not only as RSS, but also ATOM, XLS, CSV, JSON, HTML and SOAP.

Why is RSSBus a good solution for my problem?  Some reasons include:

• Minimal programming needed to connect to a wide range of mixed platform technologies
• Strong ability to combine feeds into a single information source
• Deep scripting and function library for working with and formatting feed data
• Nice support for feed caching and feed security
• Can separate data (XML) from presentation logic

RSSBus is NOT a complete XML feed management solution by itself.  That is, RSSBus doesn’t have the full feed discovery and management that an Enterprise Server (NGES) from Newsgator is.  However, note that NGES now plays with RSSBus so that the powerful feeds generated by RSSBus can be managed by NGES.

What’s Next?

In the next set of posts, I’ll look at how I exposed individual RSS feeds from a mix of data sources including Microsoft Excel spreadsheets, databases, web services, and Google queries.  After that, I’ll show you how to mash up the individual feeds into a single entity.  Then, I MAY demonstrate how to apply security and caching aspects to the mashup.

Technorati Tags: RSSBus, Mashup

I’ve got SOA on the brain lately.  I’m in the process of writing a book on building service-oriented solutions using BizTalk Server 2006 R3 (due out right around the product release), and, trying to organize a service review board at my company.  Good times.

So what’s a “service review board”?  It’s a chance to look at services that have been deployed within our development environment and chat with the developer/architect about various design and deployment considerations.  In reality, it’s a way to move from “just a bunch of web services” (JBOWS) to an architecture that truly supports our stated service-oriented principles.  Now, clearly there are services that are meant to solve a specific purpose, and may not be appropriate for “enterprise” scale.  But, I would argue that the goal of any service is to be designed with principles of reuse in mind, even if service reuse never happens.

Who should attend such a review board besides the service developer?  I’d suggest the following representatives:

• Infrastructure.  Make sure that all deployment considerations have been taken into account such as a host server (dev/test/prod), required platforms and the like.
• Enterprise architecture.  Look at the service and compare that to other enterprise projects to see if there is overlap with existing services, or, the possibility to reuse the new service in an upcoming project.
• Data architecture.  Confirm best practices for the data being sent as part of service requests or responses.   Also, consider the data security and data privacy.
• Solution architecture.  Review software patterns used and ensure that the service has the appropriate security considerations and repository registration.

With that in mind, what questions do we want to ask to verify whether this service is enterprise-ready?

Infrastructure
Question	Answer
What is the technology platform that this service is built upon (e.g. Java, .NET)?
Do you have host servers identified for all deployment environments?
Are there any SLAs defined for this service as a result of non-functional requirements?
Have the appropriate service repository metadata elements been identified for this service?
Has this service been sufficiently load tested?
Security
Question	Answer
Has a security policy been identified?
Does this service use either transport-level security or message-based security, and if so, does it match corporate standards?
Have the appropriate directory accounts/groups been created and assigned?
Data
Question	Answer
What type of data is received by the service: document, event or function parameter?
Are the input/output types complex or simple types?
Were standard, cross-platform data types used?
Does this service use an enterprise shared entity as its input or output?
If the answer above is “no”, should the input/output parameter be considered for a new shared entity definition?
Is the input message self-contained?
Software Architecture
Question	Answer
Is this a data service, event service, or functional service?
Does it support both synchronous and asynchronous invocation?
Is the service an encapsulated, stand-alone entity?
Are service dependencies dynamically loaded or configurable?
Has the service been tested for cross-platform invocation?
Does this service use an transactions?
Can the service accept a flowed transaction?
Has a lifecycle versioning strategy been defined?
Is the interface SOAP, REST or POX based?
Do common functions like exception handling and logging use enterprise aspects?
Is the service contract coarse grained or fine grained?
Is the WSDL too complicated (e.g. numerous imports) to be consumed by BizTalk Server?
How are exceptions handled and thrown?
Does the service maintain any state?
Do the service namespace and operations have valid and understandable identifiers?

The goal of this is not to torture service developers, but rather to consider enterprise implications of new services being developed.  Did I miss anything, or include something that doesn’t matter to you?  I’d  love your thoughts on this.

Technorati Tags: SOA