Brio.Portal is a member of the Brio One family of products that includes Brio.Enterprise (ad hoc business analysis), Brio.Report and Brio.Inform (management information). Brio is a longtime player in the business-intelligence and reporting arena, and that history shows in Brio.Portal's emphasis on and integration of these features. If you use Brio.Report, BrioQuery or Brio's SQR server, you'll want to look closely at Brio.Portal because it includes the hooks necessary to let you leverage your existing Brio technology. Of course, your Brio salesperson probably has passed on this hint already.
Features
Brio has concentrated on providing a portal framework that integrates well with its other products and furthers Brio's vision for enterprise reporting. Brio.Portal is designed to be the user's interface for managing and scheduling a variety of reporting agents that work in several types of data sources. From within the portal, users can dispatch agents to gather information, check on the agents' progress and view reports that contain information necessary for the users to do their jobs. Brio.Portal JobFactories -- agents that can execute any application and access back-end databases -- let users access data and have reports delivered right to their browsers whenever they need them. Rather than develop many components on its own, Brio has integrated technology from other vendors, including Autonomy's DRE and a Java-based API interface for access to the system from other applications.
Pulling disparate information together is one of the primary functions of an enterprise portal. Brio was wise to select DRE for this purpose. Unlike Coreport 3g, in which the DRE is included but poorly integrated, Brio.Portal integrates the engine well.
Brio.Portal includes a search engine that is limited to searching the content of the portal itself. If you want to crawl for content on the Web or on your corporate file systems and integrate that content into your portal, you'll need to purchase a separate product, Brio KnowledgeServer. That package integrates with Brio.Portal and includes two additional agents, CrawlServer and SearchServer. We can't think of any reason you'd want to implement an employee portal without adding this type of content, so plan to include KnowledgeServer in your budget as well.
Brio.Portal has no collaboration components, such as discussion groups or document management, so you'll need to look elsewhere to integrate threaded discussions into your portal. Connectors to syndicated feeds from iSyndicate are included.
The Brio.Portal API is a collection of Java language APIs and sample programs. The Brio.Portal API lets you access the capabilities of Brio.Portal from other programs and integrate existing enterprise data into Brio.Portal. Brio.Portal also includes a scripting language to help you automate repetitive tasks.
Architecture
Brio's multitier architecture comprises several service agents that sit in front of the portal database and file system. The One/WebClient is a Java servlet that, along with the Web server, sits at the first tier and presents the Brio.Portal interface to the end user. The WebClient passes requests from the user to the ServiceBroker, which coordinates client requests and service event notification among the third-tier service agents: NameServer, AuthenticationServer, Repository, EventServer and JobFactory.
Brio.Portal also requires at least one third-party RDBMS product, such as DB2, Informix, Microsoft SQL Server, Oracle or Sybase, to store metadata, configuration information, and user and group assignments. If you're already using one of these database products, plan to use it for Brio.Portal as well--less training, less overhead. If you'll be implementing a new RDBMS along with Brio.Portal, select your new RDBMS with an eye toward meeting your redundancy and failover needs. Remember: If the database is down, the portal is down.
Brio.Portal service agents are Java applications that run on Hewlett-Packard Co. HP-UX, IBM AIX, NT/2000 and Sun Microsystems Solaris hosts. Linux support is noticeably absent. WebClient is supported on the following Web server/Java servlet engine combinations on both Unix and NT/2000: Netscape with JRun 2.3.3, iPlanet with its native servlet engine or JRun 2.3.3, Apache with JRun 2.3.3 or JServ, and IBM HTTP Webserver with WebSphere, and IIS with JRun 2.3.3 or Jview on NT/2000 only.
Brio.Portal permits multiple instances of the One/WebClient, ServiceBroker, AuthenticationServer and JobFactory agents in a single portal domain. If you implement multiple instances of a service agent, the ServiceBroker will dispatch requests in a round-robin fashion to avoid overloading any single instance. If an agent fails, the ServiceBroker will direct requests to agents that are responding, thus providing a level of redundancy and failover. Agents can be spread among multiple machines to eliminate bottlenecks; however, Brio limits you to one NameServer, Repository agent and EventServer per domain. These limitations represent both single points of failure and potential bottlenecks.
Brio recommends at least three physical servers for an entry-level production system: one for the One/WebClient and Web server, a second for One/Administrator and a third for the service agents. The database can run on the service-agent machine, but as the size of the database increases and memory competition occurs, you'll probably want to move it to a separate box. During evaluation, you can run all these components on the same machine.
Management
Users can personalize their content via the browser, but system management requires a separate application. Most Brio.Portal management is accomplished using One/Administrator, a Java application that brokers access to One/Publisher for category and content management, One/User for user and group management, One/ Services to manage the service agents in a Brio.Portal domain, and One/ Scheduler for creating, scheduling and running jobs. If you want to brand the look and feel of your portal, however, you'll need to work directly with HTML template files, using Brio's unique template hierarchy within the file system.
We didn't like the disjointed feel of toggling from one application to another to manage the various aspects of Brio.Portal. Often, we found it hard to determine which application to use for a particular task. Brio did assure us that it is working on implementing One/Administrator as a browser-based application. This should be an improvement.
We used the One/Services module to delete, then create a new AuthenticationServer agent so we could point Brio.Portal at our Active Directory user database via LDAP for authentication. Neither we nor Brio's on-site representative could get this setup working, so we deleted the agent again and dropped back to creating a NT domain agent, pointing it at the domain emulated by our Active Directory setup. This setup worked as far as it went, but when we tried to add super-user rights to an existing domain user, that option was grayed out. Brio had no workaround for this problem.
Brio has verified corporate integration via LDAP to Netscape's Directory Server and Lotus Domino. Brio also reports that customers have integrated its LDAP driver and authentication server with Novell's NDS.
Brio.Portal 7.0, starts at $150,000 for up to 500 users, plus installation, consulting or maintenance. Brio Technology, (800) 879-2746, (408) 496-7400; fax (408) 496-7420. www.brio.com or sales@brio.com.