|
|
[an error occurred while processing this directive]
|
|
|
 |
introduction |
|
|
|
If you are reading this article you probably know something about the portal framework and have also heard about portal components. Components sound like something more concrete then they really are, they are more of a method for providing content to a portion of a portal page. A component can be simple set of HTML, such as a list of HTML links to other pages, or it can be very sophisticated and provide a seamless integration to third party applications. One can think of a component as providing a window or view into another system or application. Through this window the user may use the application, perhaps even without the user's knowledge, from within the portal page for an integrated user experience.
In working with SilverStream's Technology Partners and customers we are often asked, "how do we integrate our system into SilverStream's portal framework?" The short answer is by using components. There are a number of interesting and well-documented components (some stand-alone and some link to other applications) available with the portal framework so this article will not speak to these here. The coding for an integration type component is only slightly more complicated than the simpler stand-alone components. The architecture seems to challenge people the most until they work through the process of building one or two of these type components.
This article will answer the question of how to design and build a component for integration. It will describe without, drilling into the details, the architectures of this class of component. It will also provide three examples of components that have been developed to provide system integrations and point the reader to source code and associated white papers for further details.
|
|
|
|
|
|
Any portal component can produce either HTML or XML content for the target web page for display. A component can provide third party integration by making a request for the content from the third party application. This request for content may be a HTTP type request or as simple as reading files from a file server.
|
|
|
example integrations |
|
|
|
The following three examples will show different methods of integration techniques using portal components.
WebTrends Component Example
The first example, that integrates WebTrends, is one of the simplest of integrations. The WebTrends component is relatively simple as it displays the results of WebTrends tracking results that shows the web server's status. This component uses the technique of reading the content (an HTML page generated by WebTrends) from the file server's directory. The component after making a few modifications to the HTML then passes the content to the portal framework for processing and display within the web page.
Tidestone Component Example
This second example uses the Tidestone FormulaOne product, which is a Microsoft Excel compatible spreadsheet object that can display data. This integration uses a combination of techniques that include reading the file server directory for some of the content and then making servlet calls to the FormulaOne product that then servers data from a remote database for the rest of the content.
This component lists file directories and the reports in those directories as part of the content. When a portal user selects a directory item the component will re-read and display the appropriate directories and reports. This provides a Windows Explorer like functionality. When the user selects a report a servlet then makes a call to the FormulaOne product to display a spreadsheet in a separate browser. So this one component can serve up content with multiple links that cause different actions to occur. The diagram above shows the results of different selections.
Actuate Component Example
This third example discusses an integration with Actuate's eReporting Suite of products. This integration is fairly complex as it uses a number of techniques for accessing content from Actuate and displaying it to the user in a portal web page. An example web page with some of Actuate's content displayed is shown below.
This component retrieves XML from Actuate's report server by performing an HTTP request and then processes the XML with XSL to create HTML for final display on the web page (this is shown above). The component also displays web links that make direct calls to Actuate's report server, which in turn displays the actual reports in separate browser windows.
Let's start at a high-level view of this integration. The architecture of this integration is shown in the figure above. A web page displayed may contain several components and in this case one of the components (Actuate_ReportList) is displayed as a result of Actuate Report Server sending information by way of a web server to the application server that hosts the portal framework. The application server then processes the received content in the form of XML and, using XSLT stylesheets, displays the information as a section of HTML within the web page.
To drill-down a bit on the detail let's look at a single component, for example the Actuate_ReportList component. The component generation process is shown below from the point of view of the Java class called ReportList that is executed on the SilverStream Application Server. This process is shown in the diagram below.
|
|
|
conclusion |
|
|
|
After reading this article you should have a sense of the relative ease of using portal components to integrate with other products. The coding for an integration type component is not as difficult as it may at first seem. Understanding the architecture is the real challenge for most people and even that is manageable after working through the process of building one or two of these components. This article has described the process of designing and building this class of components by way of a few examples. The examples progressed from a simple file request to increasing complexity and sophistication. The web links below will provide the reader with additional in-depth information about these and other components along with the source code.
White Papers and Source Code for each of the components discussed:
|
|
|
|
|
|
Introduction
