Use Google's Search Appliance "OneBox" modules to integrate enterprise search functionality with your ERP.

The concept behind enterprise search functionality is fairly simple. As the name suggests, the goal of implementing enterprise search is to give you a means by which you can search for information that, theoretically at least, exists anywhere throughout your enterprise. This might, for example, be information held in a Microsoft Word document or an Adobe PDF file located somewhere on your corporate LAN or intranet. The real challenge with implementing an enterprise search application is attempting to include information stored in your organization's ERP application. In this article, we'll explore what it takes to implement enterprise search functionality with your ERP.

What Is Enterprise Search Anyway?

I'll avoid the temptation to make a Captain Kirk joke here and get right into it. At its most basic level, enterprise search is no different from the popular Internet search tools you're probably familiar with. Enterprise search tools give you the ability to identify information within your enterprise to be indexed and made available for later access. This information can be stored within documents on shared network drives as well as within corporate email systems like Microsoft Exchange or Lotus Notes. If you've ever done a file search in Microsoft Windows, you've worked with a very simple version of enterprise search. For example, if you know you have a document on your desktop computer that discusses a specific project, but you're not sure what the name of the document is or where it's stored on your hard drive, you can execute a search within Windows that will look for specific text within a document itself.

Enterprise search tools simplify this process by building indexes to make the process of later retrieving the information faster and easier for the user. But without the ability to include information from the core systems that we use to run our businesses, ultimately the value of enterprise search is somewhat limited. The ERP systems that we use to run every aspect of our business contain volumes of data--from customer names, addresses, and billing data, to process documentation for how to build a widget, what it costs, and how many were sold last year at what margin. Enabling users to easily locate this information via enterprise search will add significant value to your systems while making people work more efficiently and increasing their productivity.

Let Me "Google" That

A sure sign that a company has pierced the culture is when their name becomes synonymous with their product. Examples of this would be asking someone for a "Kleenex" or going to restaurant and ordering a "Coke." The same could be said of Google when it comes to search. The word "Google" has become synonymous with doing an Internet search for information on a topic. It only seems fitting then that we would examine implementing enterprise search with your ERP application using Google Search Appliance's OneBox approach.

Before we get to that, however, it's important to recognize that many ERP vendors today have their own enterprise search products that are built to work with their ERP applications. This is true with both Oracle and SAP, just to name a couple. It would seem obvious that you would want to implement your ERP vendor's enterprise search; however, that decision could hinge on what other enterprise search functionality you're hoping to achieve and whether or not your ERP vendor's enterprise search application supports all of your needs.

Having said that, let's assume that you've decided to implement a third-party product like Google Search Appliance. Let's review the process that would be involved in utilizing this type of product with your ERP application. Using Google's OneBox approach, we are able to integrate back-end ERP applications with a single search application via the creation of custom OneBox modules. Many application vendors have prebuilt OneBox modules to allow the integration of their applications with Google's Search Appliance. OneBox modules allow context-specific searches to be forwarded from the Google Search Appliance to another application API based on defined triggers. If you've ever done a Google search for a street address and been presented with a Google Maps option for that address, as shown below, you've already seen a OneBox module at work.

Figure 1: A Google search of a street address provides you with a map.  (Click images to enlarge.)

In the same way that Google recognizes that the information provided matches a street address, so can a custom OneBox module recognize that information provided is relevant to your ERP application and pass that information on to a Web service within your ERP to return those relevant results. Below is an illustration of how the data moves from the search request to retrieve the ERP data.

Figure 2: Data moves from the search request to retrieve the ERP data.

Note that the search content flows from the search client to the Google Search Appliance, which passes the search through the OneBox module to look for a "trigger" match. If such a match is found, the request is handed off to the associated OneBox provider, which handles the actual communication with the back-end ERP application data. The key to this is that you need to have some way to "hand off" the request from the OneBox module definition to the relevant information in your ERP. Below you'll see the contents of a sample OneBox module to link information to an inventory search application within "My ERP."  

<onebox type="external">
  <name>
    My ERP Inventory
  </name>
  <description>
    OneBox Module for My ERP Applications Inventory Reporting
  </description>
  <security userAuth="none"/>
  <trigger triggerType = "keyword">
     inventory|planning|ERP|stock|warehouse
  </trigger>
  <providerURL>
    http://myERPApp/inventorySearch/
  </provider>
  <resultsTemplate></resultsTemplate>
</onebox>
 

This sample defines a module that will be triggered when a user's search matches any of the keywords shown. The Google search appliance will hand off the query to the application identified in the providerURL portion of the module. Optionally, the security tag is used to control access to a given module. The reultsTemplate tag can be used to define a custom XSL template to display the results. The full text of the search query is passed to the application identified at the providerURL tag. This means that if a user did a search query for "inventory in stock for part ABC123," this full text would be passed to the client. As a result, the client application can return results relevant to the specific query--in this case, inventory reporting for the part number shown.

Note that the trigger type can be identified as a keyword search, as in this example; however, two additional options can also be specified. An "Always Trigger" trigger-type value identifies that the OneBox provider should always be given the opportunity to review the search and identify whether or not relevant results exist. The "Regular Expression" trigger type is used to define that the provider should be triggered when a defined regular expression is matched. An example of this type of search would be using Google to do conversions--that is, search an expression like "convert 12 miles to kilometers" and return a result as shown below:

Figure 3: A "Regular Expression" trigger recognizes the format of the search expression and launches a module to do the conversion.

Note that this is displayed in the same way that any other Google OneBox module would be displayed. The actual layout of the results provided by the OneBox provider is defined using an XSLT template, which is identified within the resultsTemplate tag in our earlier example. Below is a sample of what the XSLT template for this might look like;

<xsl:template>
   <table border="0" cellpadding="1" cellspacing="0">
     <tbody>
      <tr>
      <td colspan="2">
        <nobr>
          <a>
            <xsl:attribute name="href">
              <xsl:value-of select="title/urlLink"/>
            </xsl:attribute>
          <b>
            <xsl:value-of select="title/urlText"/>
          </b>
          </a>
        </nobr>
      </td>
      </tr>
      <tr>
      <td valign="top" width="40">
        <img>
          <xsl:attribute name="src">
             <xsl:value-of select="IMAGE_SOURCE"/>
          </xsl:attribute>
        </img>
      </td>
      <td valign="top" width="99%">
        <xsl:for-each select="MODULE_RESULT">
          <font size="-1">
          <b>
           <a>
             <xsl:attribute name="href">
               <xsl:value-of select="U"/>
             </xsl:attribute>
             <xsl:value-of select="Field[@name='partno']"/>
      <xsl:value-of select="Field[@name='partdesc']"/>
           </a>
          </b> - Wareohouse: <xsl:value-of select="Field[@name='whse']"/> -
                  <xsl:value-of select="Field[@name='onhand']"/> in stock.
          </font>
          <br/>
        </xsl:for-each>
      </td>
      </tr>
     </tbody>
   </table>
</xsl:template>

This example identifies data to be returned by the OneBox provider and defines how that information should be formatted within the search results display. Using our earlier example, if a user were to submit a search for "widget inventory," the OneBox module would be triggered because of the keyword match ("inventory") and would pass the entire search to the OneBox provider, which would in turn match the search term "widget" and provide relevant results using the XSL template shown above. These results might look like those shown below:

Figure 4: The results of your search are revealed!

Note that this example gives basic information at a glance, while providing a link to allow the user to obtain additional information from a specific provider. This simple example gives you an idea of all of the building blocks required to implement this type of functionality within your environment. The good news is that many application vendors already have OneBox modules available for use with their applications. In any case, using Google Search Appliance's OneBox functionality can get you on the road to using a single search to access information throughout your enterprise.

Mike Faust

• Email
• Site

Mike Faust is a senior consultant/analyst for Retail Technologies Corporation in Orlando, Florida. Mike is also the author of the books Active Server Pages Primer, The iSeries and AS/400 Programmer's Guide to Cool Things, JavaScript for the Business Developer, and SQL Built-in Functions and Stored Procedures. You can contact Mike at mikeffaust@yahoo.com.

---

MC Press books written by Mike Faust available now on the MC Press Bookstore.

		Active Server Pages Primer Learn how to make the most of ASP while creating a fully functional ASP "shopping cart" application. List Price $79.00 Now On Sale
		JavaScript for the Business Developer Learn how JavaScript can help you create dynamic business applications with Web browser interfaces. List Price $44.95 Now On Sale
		SQL Built-in Functions and Stored Procedures Unleash the full power of SQL with these highly useful tools. List Price $49.95 Now On Sale