WebSphere
Portal Express 7
Second Edition
Published January 2011
© Copyright IBM Corporation 1993, 2011
Second Edition
Published January 2011
© Copyright IBM Corporation 1993, 2011
In keeping with IBM's commitment to accessibility, this edition of the product documentation is accessible.
You can save a local copy of this document from your browser. Each browser has different menus and menu options. Consult the browser help if you need assistance saving the document locally.
If you would like to provide feedback about this document, then Submit Feedback.
IBM® WebSphere® Portal
Express consists of middleware
applications (called portlets), mashups, and development tools for
building and managing secure business-to-business (B2B), business-to-consumer
(B2C), and business-to-employee (B2E) portals. Web portals allow partners,
employees and customers to choose their user experience, with personalized
applications based on role, context, actions, location, preferences
and team collaboration needs. IBM WebSphere Portal
Express software provides a
composite application or business mashup framework and the advanced
tooling needed to build flexible, SOA-based solutions, as well as
the unmatched scalability required by any size organization.
The Content Accelerator and Enable offerings add IBM Lotus Web Content Management, document management, enterprise search and enhanced workflow capabilities and the Extend offering includes powerful collaborative features including team collaboration, electronic forms, instant messaging and presence awareness services to enhance portal effectiveness. Additional IBM accelerator offerings provide additional solutions that easily snap on to WebSphere Portal Express software and can reduce time to value, helping customers reduce the costs of deploying content, automating business processes, collaborating and more.
A portal is a Web site that provides users with a single point of access to Web-based resources by aggregating those resources in one place and by requiring that users log in only to the portal itself, and not to each portlet they use. WebSphere Portal Express can also deliver Web content to WAP-enabled devices, i-Mode phones, Smart phones, and to various Web browsers. In addition, the IBM Mobile Portal Accelerator multi-channel server and mobile device repository extends portal content dynamically to over 7000 mobile devices, with new updates and devices added as they reach the market.
As an administrator, you can customize WebSphere Portal Express to meet the needs of your organization, users, and user groups. You can adapt the look and feel of the portal to fit the standards of your organization and to customize page content for users and groups in accordance with business rules and user profiles. Users, such as business partners, customers, or employees, can further customize their own views of the portal. Users can add portlets to pages and arrange them as they want and control portlet color schemes. By aggregating portlets in one place and giving users the power to customize their own desktops, WebSphere Portal Express gives users a means for doing business efficiently and with high satisfaction.
Portlets are central to WebSphere Portal Express. As special reusable Java servlets that appear as defined regions on portal pages, portlets provide access to many different applications, services, and Web content. WebSphere Portal Express ships a rich set of standard portlets, including portlets for displaying syndicated content, transforming XML, and accessing search engines and Web pages. Portlets for accessing Lotus Notes®, IBM Lotus® Domino® and Extended Products, IBM Lotus Sametime®, IBM Lotus Quickr, IBM Lotus Connections, Microsoft Exchange, and instant messaging are included. Several third-party portlets are also available. Examples include Enterprise Resource Planning (ERP), Dashboards, Business Intelligence, Process Management, and Customer Relationship Management (CRM) portlets. In addition, WebSphere Portal Express ships an API that portlet developers can use to create custom portlets.
WebSphere Portal Express now includes the Lotus Mashup runtime so you can run widgets inside the portal and even create mashups that consist of both portlets and widgets. Widgets are highly interactive user interface components that are written in JavaScript. These widgets are typically very narrow in scope and can easily be created using a script-based language. Widgets can also be a solution for creating a mashup between different backend technologies like a Java EE-based portal server and a PHP-based server.
WebSphere is IBM's integration software platform. It includes the entire middleware infrastructure -- such as servers, services, and tools--needed to write, run, and monitor 24x7 industrial-strength, on demand Web applications and cross-platform, cross-product solutions. WebSphere provides reliable, flexible, and robust integration software.
WebSphere provides software for Service Oriented Architecture (SOA) environments that enables dynamic, interconnected business processes, and delivers highly effective application infrastructures for all business situations.
IBM WebSphere Application Server drives business agility by providing millions of developers and IT Architects with an innovative, performance-based foundation to build, reuse, run, integrate and manage Service Oriented Architecture (SOA) applications and services. From business critical and key enterprise-wide applications to the smallest departmental level applications, WebSphere Application Server offers the highest levels of reliability, availability, security and scalability.
For additional information about new features, main components, and what each component provides to the overall solution, explore the subtopics of this section.
The following topics provide additional overview information.
Learn what's new in IBM WebSphere Portal Express.
WebSphere Portal Express includes new features, such as virtualization and content tagging and rating, as well as enhancements on Page Builder and unified theme architecture, serviceability, migration and content management among others.
A new task has been added to aid in automated log collection for problem reports opened with IBM Support. This is in addition to the log gathering available in the ISA / ISA-lite support tools from IBM. The ConfigEngine task does not require the installation of any additional code in order to run the log collection.
There are now two Information portlets that are available. These portlets have the same function but the original was written with the IBM API and the new portlet was written with the JSR 286 API. The new portlet can render on both the client and server side while the original Information portlet can only render on the server side.
The configuration wizard has been improved to make it easier to configure WebSphere Portal Express security with an LDAP server. The new configuration wizard function now attempts to query the LDAP server to provide better defaults for the various questions that need to be answered in order to successfully do an LDAP security configuration.
You can now easily add a blog, blog library, or wiki to a page using the Add Content widget in the Page Builder theme. There are additional enhancements to globalization support through the utilization of new IBM Lotus Web Content Management API's.
To improve the "First Failure Data Capture" characteristics of WebSphere Portal Express for a class of problems around heap memory usage, WebSphere Portal Express install will by default activate verbose garbage collection in the WebSphere Portal Express JVMs. This is done by adding the appropriate settings to the JVM command line arguments for the WebSphere Portal Express JVM within WebSphere Application Server, to activate the support that is provided by the underlying JVM for writing statistics regarding Java heap garbage collection activity to a log.
In addition, on those platforms that support it, the "log rolling" capability is activated to try to balance capturing enough garbage collection history to be useful in debugging while conserving the amount of actual disk space used by the logs. In normal verbose garbage collection, the log could grow without bound. With the log rolling capability, the log is limited to a reasonable number of generations, where each generation contains a limited number of garbage collection cycle reports. Because WebSphere Portal Express is activating the support that is provided in the underlying JVM code, the details of how this support works are documented in the appropriate Java Diagnostics Guide.
This large allocation logging is activated by a JVM command line parameter registered for the Portal servers within WebSphere Application Server, and can be tuned or deactivated by editing or removing the appropriate strings within the WebSphere Application Server configuration. For example, the 10 MB threshold can be lowered to a smaller value if you suspect allocations that are "larger than expected but not 10 MB".
Message catalog has been updated so that any new messages added have more descriptive explanations and suggested user actions to aid in users and IBM Support problem determination procedures. In addition to the new entries, existing common error messages have been revamped to aid in problem determination.
Improved migration paths, now migrating from WebSphere Portal Express Version 6.1 is more like a software upgrade. Database schema changes between WebSphere Portal Express Version 6.1 and 7.0 are automatically processed. You can also perform in-place database upgrades.
The Page Builder theme is now the default theme. The Page Builder theme has evolved into a new unified architecture supporting portlets and widgets, as well as both server-side and client-side page aggregation. Themes can now be fully edited and managed directly via static HTML files stored in the WebDAV file store. Styles have been further optimized for performance and ease of customization by exploiting the latest CSS3 features for linear gradients, drop shadows and rounded corners.
Existing Page Builder features have been improved to support the new enhanced Client Side Aggregation architecture. The tab navigation widget, with drop-down menus, inline page creation and drag and drop page re-ordering now supports client-side page switching without a browser full page refresh. Content Search finds portlets and widgets to add to the page. Change Style supports and Change Layout support static CSS and layout templates stored and configured through WebDAV.
Impersonation allows a user, such as a support specialist, to access a user's workstation to test out a new page, portlet, and so forth, and see issues as they occur on the workstation. Before you can impersonate another user, you first must enable the impersonation feature and assign the Can Run As User role to the appropriate user.
Users can now tag or rate portal content and view the tags and ratings. This allows to better organize, categorize, and find portal content, including custom content, if it is available in the portal. For example, users can tag or rate books in an online bookstore.
WebSphere Portal now provides a single point of integration with workflow management systems, such as IBM WebSphere Process Server, through the Unified Task List. The Unified Task List is a portlet that aggregates tasks and activities from multiple systems in a visually appealing and highly configurable user interface. Portal users access the Unified Task List to view and claim pending tasks that they can complete to advance workflows.
The Unified Task List is available from the WebSphere Portal Business Solutions Catalog and offers out-of-box integration with WebSphere Process Server. However, you can customize the Unified Task List to suit your business needs by creating unique tasks providers, or services, that access, retrieve, and format tasks from any workflow management system.
Virtualization technology can be used to mass-replicate identical operating systems installed and configured with WebSphere Portal Express. VMware is fully supported in this version of WebSphere Portal Express.
WebSphere Portal 7 includes more documentation improvements based on feedback from customers. Our most exciting change is our transition to publishing the documentation in the WebSphere Portal Family wiki.
The wiki offers advantages to the information center. You can comment on or edit topics when you detect an issue or see room for improvement. In the past, you have been able to submit feedback forms to IBM. Many customers have taken the time to submit those forms, providing excellent feedback. As a result, the documentation has been updated and improved. The new wiki delivery format means that other customers benefit from that feedback faster.
Anyone can browse the documentation on the wiki. However to edit or comment on the content, you must log on to the wiki using a Lotus developerWorks ID. If you already have a Lotus developerWorks ID, your are ready to log on and add comments or edit. If you do not have a Lotus developerWorks ID, you can quickly register and get started.
The screen capture highlights features you should know about when using the documentation.
| Number | Description |
|---|---|
| 1 | The breadcrumb helps you orient yourself and quickly know which documentation you are reading. |
| 2 | Advanced Search opens a new screen where you can limit your search to a specific category. For example, you can limit your search to only topics in the IBM WebSphere Portal Express 7 Documentation. You can select multiple categories or a single category. Use advanced search to find exact phrases, search titles only, look for whole words only, and take advantage of Boolean expressions in your search. After you search for a term or phrase, you can modify your selections and parameters and further refine your search results. |
| 3 | The Translate page feature uses machine translation to translate all the content on the fly. Unlike many machine translation servers, this translation server uses crowd sourcing. If you detect an inaccurate, awkward, or confusing translation, you can correct it. Your correction is added to the translation server and will be used for the next time the content is translated. |
| 4 | IBM still provide quality translated content. Access documentation translated by IBM translation centers using the IBM Translated Documentation section of the navigation. |
| 5 | Use these links to quickly see the original version of the topic you are looking at. |
| 6 | Highlighting in the navigation helps you know where the current topic is in relation to other topics in the content. |
Descriptions, examples, and default values for properties have been added back to the documentation. Find properties file documentation.
If you want to set up a site that relies heavily on Web Content Management, see the IBM Lotus Web Content Management documentation. This new documentation set combines what you must know about WebSphere Portal and Lotus Web Content Management to set up a site.
The starting point for information is the product documentation. Previously the product documentation was delivered using an information center framework For WebSphere Portal 7.0, the product documentation is delivered in the WebSphere Portal Family wiki. There are still other sites and resources available to you when working with WebSphere Portal, but this consolidation is intended to make finding information easier. It is also intended to drive improvements into the content and let the community edit and comment on the documentation. Knowing where to look for information can save you time and money. Learn more about primary and secondary resources for WebSphere Portal and Lotus Web Content Management documentation and supplemental content.
There are two primary sources for content: the WebSphere Portal Family wiki and WebSphere Portal Support site. An excellent secondary source is developerWorks, where you can find examples and tutorial-based articles.
The product documentation delivered in the wiki (on the Product Documentation tab) is developed by IBM to help you take advantage of features based on expected usage patterns. You can contribute to the content to reflect your experience with the product. The wiki content accessed from the Home tab is developed by the community, both inside and outside of IBM. The intent is to share experiences with the product and based on actual usage patterns and use cases. The Support content is developed by IBM Support to help you avoid and diagnose issues with the intent of being as responsive as possible.
IBM WebSphere Portal Express provides users a consistent view of portal applications and allows users to define specific sets of applications that are presented in a single context. Depending on the requesting device, the rendering of this application set has to vary to fulfill the requirements of the device.
The tasks of the aggregation, which are repeated with each request coming from the device, are:
WebSphere Portal Express also provides the ability to create a custom navigation model, which includes such features as:
Another aspect of the versatile framework is the ability to personalize a user's portal experience, using "content spots" that render subscribed content based on the user and user's role in the portal.
Customizing the user's experience is one of the main goals of IBM WebSphere Portal Express. User and administrative portlets are provided for customizing content and the look and layout of pages.
Users can have one or more custom pages and access each one through a different page. A page can contain a group of pages that is organized for a specific purpose. Each page can have a different set of portlets. Depending on authorizations, users can change the look and feel of their pages by using skins and page layouts. Also, page navigation hierarchy is tree-based, allowing any depth of nested pages.
The user or an administrator can set up the contents of each page. Administrators can specify that certain portlets be required, so that users are unable to move them or to remove them from the pages. Each page can have its own color scheme and column layout.
An administrator can grant or revoke access to customize a page or portion of a page to other administrators or users. The administrator can determine user's rights to modify a page. Administrators can control the edit authority that other administrators have on a page and its contents. This is designed to help organizations enforce policies and consistency, and create region specific portals with some centrally managed content. This control is best explained through an example.
The first administrator can determine that a page will have three columns and not allow the column layout to be modified by any other administrators. A second administrator with lesser access cannot modify the column layout but can add portlets to these columns. The following figure shows a page split into three columns. Administrators can add portlets to these columns.
The second administrator adds a stock portlet to column one and a company news portlet to column two. This administrator wants these portlets to be available to everyone and does not want them to be removed. However, the administrator can add portlets to the columns. Therefore, the portlets are locked and cannot be removed by other administrators with lesser access. The following figure shows an example of how cascading authorization from one administrator to another would look.
WebSphere Portal Express uses html, cascading style sheets, images, and other standard web design artifacts to define the look of pages. Java Server Pages (JSP) and other server-side dynamic techniques can also be used to help define the look of a site. You can add or modify elements to control visual aspects of WebSphere Portal Express, perhaps to add company-specific brand elements or to achieve a different color scheme and visual style. The system for defining color themes and skins supports multiple skins per theme, additional branding elements, navigation styles, and dynamic, browser-independent cascading style sheets.
You can apply skins and themes to a page, not only to the overall product. You can apply different skins individually to portlets as well, so that the appearance of a portal can be fine-tuned to meet any user need. By using a different theme for each page, a single installation can give the appearance of supporting many virtual portals.
You can change all visual elements of WebSphere Portal Express, including the masthead, the navigation areas, graphics, portlet title areas, and style sheets, to give WebSphere Portal Express a custom look. You can use standard file formats, such as JPEG, GIF, CSS, and JSP files, to define the look and layout.
The structure of the component installation folder contains folders named "skin" and "theme," with folders "html," "wml," and "chtml." These folders contain most of the files that are used for defining the basic structure of the home page, its color schemes, and portlet decorations. Portal designers can copy these folders and modify their contents to create a custom look and feel. The theme administration portlet registers the new files.
You can change the placement of individual portlets on a page by using the drag-and-drop feature. To rearrange a portlet on a page, click the title bar of the portlet and then drag the portlet to a new location on the page. You can also add portlets to the page for quick and easy page customization by dragging portlets from the Portlet Palette to the page.
The system of page templates, themes, skins, and portlet rendering is fully enabled for internationalization and accessibility by people with disabilities. For globally accessible portals, WebSphere Portal Express searches for and selects the proper JSP pages, based on the target browser and its settings for language and country.
IBM WebSphere Portal Express comes with pre-built, sample Internet and Intranet Web sites that you can explore to learn about authoring and managing different types of content, or use as a template to streamline development of your own portal. You can also use the New Site Wizard to generate your own portal site.
The sample Intranet and Internet sites are automatically deployed when you install WebSphere Portal Express.
Use the Intranet site template as a starting point for creating your own employee site. Home, Work, and Resources pages come seeded with placeholder content that you can use as is or customize. Easy to use list portlets let you organize and manage announcements, news, events, FAQs, and links.
Use the Internet site template to get a jumpstart on building a Web site where customers can learn about product offerings, marketing promotions, and company news.
More content samples are available on the IBM WebSphere Portal Express Business Solutions Catalog.
Use the New Site Wizard to generate your own site – without needing any portal development skills or assistance from an administrator. Just select a site template from the available samples, choose the look and feel you want, and then let the wizard do the rest.
The wizard automatically creates new sites as virtual portals; however, administrators and developers can extend the wizard to create any type of portal site. Portal developers can also enhance the New Site Wizard by creating custom site templates, and then adding them to the wizard.
Download the New Site Wizard from the IBM WebSphere Portal Express Business Solutions Catalog. Package contents include the portlet .war (Web Application Archive) file, supporting files and directories, and detailed instructions in a .pdf file. After deploying the wizard, you need to add the portlet to a page that users can access. For more information, see the .pdf file that comes with the wizard.
Portlets are a central part of IBM WebSphere Portal Express. Portlets are small applications that are independently developed, deployed, managed, and displayed. Administrators and users compose personalized pages by choosing and arranging portlets, resulting in customized Web pages.
WebSphere Portal Express ships a rich set of standard portlets. For the most up-to-date information about portlets, including the latest portlets that are available for download, visit the IBM WebSphere Portal Business Solutions Catalog. Or, refer to Developing portlets for information on creating custom portlets.
Portlets are more than simple views of existing Web content. A portlet is a complete application, following a standard model-view-controller design. Portlets have multiple states and view modes, plus event and messaging capabilities.
Portlets run inside the application server, similar to the way a servlet runs on an application server, but are aggregated to a complete Web page by the WebSphere Portal server. The portlet container provides a run-time environment where portlets are instantiated, used, and finally destroyed. Portlets rely on the WebSphere Portal Express infrastructure to access user profile information, participate in window and action events, communicate with other portlets, access remote content, look up credentials, and store persistent data.
Generally, portlets are administered more dynamically than servlets. For example, portlet applications consisting of several portlets can be installed or removed while the WebSphere Portal component is running. The settings and access rights of a portlet can be changed by an administrator while WebSphere Portal is running, even in a production environment.
Portlet modes allow a portlet to display a different user interface, depending on the task that is required of the portlet. A portlet has several modes of display that can be invoked by icons on the portlet title bar: View, Help, Edit, Configure, and Edit Shared Settings.
A portlet is initially displayed in View mode. As the user interacts with the portlet, the portlet can display a sequence of view states, such as forms and responses, error messages, and other application-specific states. Help mode provides user assistance. Edit mode lets the user change portlet settings. For example, a weather portlet might provide an Edit page for users to specify location. Users must be logged in to WebSphere Portal Express to access Edit mode. Configure mode changes the default look of the portlet for all portlet instances and Edit Shared Settings changes the look of the portlet on a specific page.
Each portlet mode can be displayed in normal, maximized, or minimized state. When a portlet is maximized, it is displayed in the entire body of a page, replacing the view of other portlets. When a portlet is minimized, by default, only the portlet title bar is displayed on the page.
The Java Portlet Specification addresses the requirements of aggregation, personalization, presentation, and security for portlets running in a portal environment. WebSphere Portal Express supports both portlet standards JSR 168 and JSR 286. For more information about the standard portlet API, refer to the topic about the Standard portlet API.
WebSphere Portal Express allows portlets to communicate with each other. Portlet communication can be used to exchange data between portlets. This makes the portal easier to use.
The portal supports events as defined in the JSR 286 specification. It allows administrators to wire portlets by using the portal user interface.
For example, one portlet can display information about accounts, and a second portlet displays information about transactions that have occurred for one of the accounts over the last 30 days. To do this, the transactions portlet needs to obtain the appropriate account information when it displays the transaction details. This is accomplished by communication between the two portlets, using events as described in the JSR 286 specification. In this example, the account portlet defines a publishing event in its portlet descriptor. The transaction portlet defines this event as a processing event in its portlet descriptor. By using the portal user interface, you can now wire those two portlets together. After you did this, when the account portlet throws an event, the transaction portlet receives this event and can show information about the transactions of this account.
Portlet services are used to provide common functionality to portlets. Each portlet service has its own service specific interface for the functionality that it offers. WebSphere Portal Express supports portlet services for standard portlets. Standard portlets use a JNDI lookup to retrieve a PortletServiceHome object, which is used to retrieve a portlet service implementation. A portlet service can be invoked only by the code within a portlet. For more information about portlet services in the portal, refer to the topic about Portlet services.
Users can tag or rate portal content and view the tags and ratings. Tagging and rating allows users to better organize, categorize, and find portal content. This includes Web Content Management and custom content. For example, users can tag or rate books in an online bookstore.
A set of preinstalled Web content libraries are supplied to allow you to add blog and wiki features to your Web sites. Use blogs, blog libraries, and wikis to tap into the power of the community and to change the way you work.
Blogs are a great tool to use when you want to generate ideas around a single topic. You can use blogs for your own individual work or to gain feedback on a single concept from the larger team. Blog libraries take blogs to the next level. Rather than creating a blog per topic, you can use blog libraries to keep track of multiple topics in a centralized location. Wikis also provide you with another alternative for authoring content. Simple inline editing, including the insertion of images and links, makes authoring wikis quick and easy. You can also tag and rate blog and wiki content.
Blogs, blog libraries, and wikis use the template libraries provided by IBM Lotus Web Content Management. Each blog, blog library, and wiki has its own library. The page hierarchy that is provided for these components is the common one defined by the Web Content Management template libraries.
A portal provides access to content, data, and services that are located throughout the enterprise. These services include predefined connectors and portlets, and tools for creating additional connectors and portlets.
Enterprise resource planning (ERP) and customer relationship management (CRM) systems are excellent candidates for portlets because efficient, personalized access to these functions provides measurable return on your portal investment. IBM provides connectors to enterprise applications using the Java Connector Architecture (JCA).
JCA is a standard architecture for integrating Java 2 Enterprise Edition (J2EE) applications with enterprise information systems that are not relational databases. Each of these systems provides native APIs for identifying a function to call, specifying its input data, and processing its output data. The goal of the JCA is to provide an independent API for coding these functions.
JCA also defines a standard Service Provider Interface (SPI) for integrating the transaction, security, and connection management facilities of an application server with those of a transactional resource manager. Thus, JCA is a standards-based approach to managing connections, transactions, and secure access to enterprise application systems. IBM JCA connectors provide access to systems such as SAP, PeopleSoft, J.D. Edwards, Oracle Enterprise Edition, CICS, IMS, and Host-on-Demand. Leveraging its CrossWorlds acquisition, IBM plans to develop and integrate JCA connectors to many other systems.
Rational Application Developer provides a complete development and unit test environment for applications that use JCA connectors, Web services, and microflows. Rational Application Developer tools include support for Web Service Definition Language (WSDL), developer versions of the connectors, the Web Services Invocation Framework (WSIF), and the microflow engine.
Collaboration features in IBM WebSphere Portal Express are provided through the Domino and Extended Products Portlets. Domino and Extended Products are the Domino Enterprise server and IBM Lotus Sametime.
Portlets are the mechanism by which the Domino server products are fully integrated into WebSphere Portal Express. Domino and Extended Products Portlets provide an online directory with people awareness, and integrated tools for managing online meetings. All these collaboration features help people in your organization work together and share information online to achieve their business goals. A collaborative portal can improve your organization's responsiveness, innovation, competencies, and efficiency.
For information on supported versions of IBM Lotus Domino and IBM Lotus Sametime, see the WebSphere Portal Express detailed system requirements.
Examples of all the Domino and Extended Products Portlets are supplied on the Collaboration page and on the Messaging page. The portlets are installed with WebSphere Portal Express and deployed automatically, requiring of the administrator only a number of server and other configuration tasks before users can take advantage of a suite of integrated collaborative applications.
Domino and Extended Products Portlets include:
Users can view contact and other typical business card information for a registered user by displaying the Person card. The Person card is available through a wide range of portal components including Domino and Sametime integration, composite applications, personalization, and Web content authoring. To view the Person card, move the cursor over an active (underlined) person's name and then select Click for Person Card.
When Lotus Sametime is enabled in your portal configuration, users can work with the complete set of people awareness functionality, which includes instant messaging and application sharing through e-meetings. Person names appear aware - with a dynamic online status indicator. Click Profile to display full information about the person. Additional actions can include:
If you choose not to enable Lotus Sametime in your portal configuration, people awareness functionality is more limited. People's names appear as hyperlinks, but with no people awareness icon next to each name, and available actions on the Person card are limited to those that are native to WebSphere Portal Express.
Accessibility features help users who have a physical disability, such as restricted mobility or limited vision, to use software products successfully.
This version of IBM WebSphere Portal Express:
When appropriate, the documentation for specific product features contains additional information about accessibility.
See the IBM Human Ability and Accessibility Center for more information about the commitment that IBM has to accessibility:
Make a note of the features that were available in the previous versions of IBM WebSphere Portal Express but are no longer available in this version or in future versions.
As they become available, links to additional information will be provided to help you migrate away from deprecated features.
If you had been using CPP with Exchange, you can now use the Exchange portlets
If you had been using CPP with Domino, you can now use the iNotes portlet.
If you had been using RSS Portlet or IBM Feed Reader Portlet, you can now use IBM Syndicated Feed Portlet for WebSphere Portal Express. Alternatively, you can download the RSS portlet and IBM Feed Reader portlet from IBM WebSphere Portal Express Business Solutions Catalog.
If you had been using CPP with Exchange, you can now use the Exchange portlets
If you had been using CPP with Domino, you can now use the iNotes portlet.
IBM WebSphere Portal
Express provides
flexible deployment options ranging from proof-of-concept where you
can examine and test functionality to a highly available and scalable
production environment. Review the planning information to learn more
about hardware and software requirements, high availability, scalability,
supported topologies, and much more. Select your operating system
and then select the installation pattern that most reflects your business
needs.
Before installing IBM WebSphere Portal Express in a production environment, you need to assess your hardware and software needs, possible database configurations, security options, and LDAP server options. Skipping this important step can lead to unexpected results and costly delays.
Before installing IBM WebSphere Portal Express, review the hardware and software requirements to ensure you have the supported versions of prerequisite and corequisite software as well as the required hardware.
http://www.ibm.com/support/docview.wss?uid=swg27007791
Known issues and problems are centrally available on the support page. Links into the support knowledge base are integrated throughout the information center to make sure you have the most current information. Before you start the installation process, check the IBM Support site for the most current information about known limitations or issues. Use the following dynamic queries to find late breaking information about this release.
The following links will return the most current list of technotes for the identified area. If a technote has not been published for a given topic area, the link will not return any technotes and you will be instructed to refine your search.
You can also search the Support site directly from the information center. See the Search the IBM support Web site for a solution topic.
This support statement proposes a revision to the definition of "supported" and "unsupported" with respect to the various products of which IBM WebSphere Portal Express depends on for proper operation.
WebSphere Portal Express requires the use of several collateral products for its normal operations. In particular, it requires WebSphere Application Server, a database, a repository for user information (typically an LDAP), and other products depending on specific customer requirements.
During the testing of a new release, Development generally tests WebSphere Portal Express with a prescribed list of these collateral products. These products are designated as "Supported Products" in the documented hardware and software requirements for that release.
Because the list of "Supported Products" cannot reasonably describe all possible configurations that a customer may need to use, some customers have voiced concerns about the level of support that will be provided for configurations that are not specifically designated as "Supported." This document is intended to provide clarification of the level of support that can be generally expected for the current release with various combinations of dependent products.
There are three (3) categories of support for collateral products to WebSphere Portal Express. They are "Supported Products", "Newer Versions and Releases of Supported Products" and "Unsupported Products". The definition and support statement for each category follows:
Products in this category are supported as per the terms of your WebSphere Portal Express License Agreement. PMRs (Problem Management Records) will be accepted by IBM Support in accordance with the conditions of the WebSphere Portal Express License Agreement.
Products that fall into this category are typically newer releases or fix levels of a product already in the "Supported Product" category or a product that adheres to a standard API that WebSphere Portal Express supports (such as an LDAP server). Some specific examples might include a newer operating system fix level, a WebSphere Application Server (WAS) fix pack newer than the original "Supported "fix pack level, an IBM Java (JVM) fix pack, a new fix pack or release of DB2 or an updated LDAP server.
For products that fall into this category, support is as follows:
For IBM products, such as IBM Directory Server or Domino LDAP, IBM DB2, IBM JDKs (JVMs) and WebSphere Application Server, WebSphere Portal Express will fully support fix-pack, release and version updates that do not significantly change interfaces or other underlying support that WebSphere Portal Express depends on for its functionality. If and when a newer release of one of these products is shipped that WebSphere Portal Express cannot accommodate, that fact will be noted as described in the next section entitled "Unsupported Products". Note that in order for WebSphere Portal Express to support an update to a database or LDAP product, WebSphere Application Server must support that update as well.
For non-IBM products, the Support team will make a commercially reasonable effort to support products in this category. Support will accept problem reports (PMRs) for the appropriate releases using these untested products. If Support is able to recreate the reported problem using a "Supported" version of the product, we will attempt to fix the problem.
If Support is not able to recreate the problem with a "Supported" version of the product in question and is not able to resolve the problem on the untested version of the product in question, Support will look to the support organization for the product in question to provide resolution. Please note that varying degrees of customer involvement may be necessary to handle this process for non-IBM products.
If the support organization for the untested product in question is unable to resolve the problem, Support will deem that version, release or fix pack level of the untested product in question to now be an "Unsupported Product".
WebSphere Application Server has a similar support statement which can be found on the Web.
WebSphere Portal Express can be sensitive to changes in the underlying WebSphere Application Server. Upgrading to a new fix pack level of the application server is well tolerated and encouraged (such as from WebSphere Application Server version 7.0 to 7.0.x) as long as all required fixes for WebSphere Application Server are available as integrated into that fix pack or by applying an interim fix specifically for that maintenance level. However, upgrading from one version of WebSphere Application Server to the next (such as from 6.1 to 7.0) is quite problematic if not done within the context of a migration of versions and should never be attempted with an "in-place" system.
LDAP support spans two (2) categories:
Understanding character limitations for user IDs and passwords is important because they are used throughout the system to provide access and secure content. The character limitations provided here apply to the IBM WebSphere Portal Express administrator, IBM WebSphere Application Server administrator, database administrator, LDAP server administrator, and user IDs. Database and LDAP servers can have more restrictive limitations than provided here. Therefore you should check the database and LDAP server product documentation for restrictions. Failure to correctly define user IDs and passwords during the installation process can result in installation failure. In addition, your company may have more restrictive user ID and password requirements that you must also follow.
When a person signs up as a user or when an administrator enrolls a user, they must complete the user information form. On this form, do not enter characters that might not be supported. Regardless of what characters you are able to enter on the user information form, user ID and passwords are limited to the valid characters described here. You can specify other characters in the First Name and Last Name fields. If your company policy is more restrictive, you can provide that information to your users in the enrollment form help or as in-line help directly on the form.
The table below contains a list of the required fields on the user information form and the supported characters.
| User information | Valid characters | Unsupported characters |
|---|---|---|
| User ID | Note: The only supported characters
in IBM i are lower
case characters, upper case characters, numbers, and the underscore.
|
Only ASCII characters are allowed. Other restrictions: The user ID cannot contain
spaces; for example, user name. User IDs cannot be longer than 200 characters.
If
you enter any unsupported characters during the installation, you
will receive an error message that states which character is invalid.
For example, "The special character [@] was found in the administrative
user ID field. Enter the administrative user ID again."
Important: You will receive a different error message if you
enter any unsupported characters when creating users through the Manage
users and groups portlet.
|
| Password / Confirm password | Note: The only supported characters
in IBM i are lower
case characters, upper case characters, numbers, and the underscore.
|
Diacritics, such as the umlaut, and DBCS characters are not allowed. Other restrictions: The
password cannot contain spaces; for example, pass
word. Passwords
cannot be longer than 128 characters.
Attention: Login will fail if the password contains any unsupported
characters, including DBCS characters. This will happen even if a
user is successfully enrolled using a password containing DBCS characters.
If you enter any unsupported characters during the installation, you will receive an error message that states which character is invalid. For example, "The special character [@] was found in the password field. Enter the password again." |
| First Name | All characters | n/a |
| Last Name | All characters | n/a |
Each operating has unique preparation needs to ensure a successful installation. Before you continue with the installation wizard, make sure you have properly prepared your operating system and that you have all the required hardware and software prerequisites and corequisites.
Topology diagrams help you visualize different configurations that you can setup to support various user and system load requirements. The topology diagrams are representative of basic configurations.
The single server topology illustrates a simple installation for demonstration, trying the product out, or development environment purposes. The stand-alone topology illustrates a distributed configuration. Clustered topologies illustrate more robust and load intensive hardware configurations and Web Content Management topologies illustrate how different hardware configuration support various authoring and system load requirements. To increase capacity and availability, multiple portal servers can be clustered using IBM WebSphere Application Server Network Deployment, where the portals share a common configuration and load is distributed evenly across all cluster instances. The high availability and failover topology illustrates WebSphere Portal Express in a more complex production environment.
A single instance of IBM WebSphere Portal Express provides a fully functional application server and a Web site that is capable of serving a medium to small user community. Initially, a single instance is configured to use an internal database based on DB2 for data storage..
Single server deployments are ideal for development, test, demonstration and education, and, as mentioned, some small production sites. A single server, however, presents a single point of failure and must be converted to a cluster or server farm to improve its capacity, availability, and ability to recover from failure conditions.
As an optional configuration, which is not depicted in the graphic below, you can configure a Web server, with IBM WebSphere Application Server's HTTP plug-in, at the front of a typical server deployment for test or production use. The Web server provides the ability to serve static resources, such as images and style sheets, as well as a plug-in point for a corporate single sign-on (SSO) agent, in the event that WebSphere Portal Express will participate in a global SSO domain.
The following illustration displays a common topology for a single server environment. Only one server is needed. WebSphere Portal Express, WebSphere Application Server, and the database are all installed on the same server.
The stand-alone scenario is different from the single-server since the database server, LDAP server, and Web server software are installed on different physical servers than the IBM WebSphere Portal Express. This configuration enables you to distribute the software in your network and therefore distribute the processing load.
For a stand-alone configuration, you can use an existing, supported database in your network and an existing, supported LDAP directory. You can configure IBM WebSphere Portal Express to authenticate with the LDAP server. The following illustration displays a common topology for a stand-alone server. The HTTP server, (also referred to as Web server) is installed on a server in a protected network. The LDAP server and database server are also installed on different servers. WebSphere Portal Express and WebSphere Application Server are installed on the same server.
Since WebSphere Portal Express does not support cloning or clustering, the idle standby topology provides a failover configuration. In an idle standby configuration, two WebSphere Portal Express nodes are configured. If the primary node fails, incoming requests will be routed to the standby node.
The following topology diagram illustrates the configuration for the Renovations intranet. As you can see, an IP sprayer is used to direct incoming traffic to one of the two WebSphere Portal Express servers, Node A and Node B. Traffic is directed to Node B only if Node A is not responding. The WebSphere Portal Express servers represent a primary and secondary node in the cluster. They are both members of the same cluster cell. In addition to the WebSphere Portal Express nodes, there is an LDAP server and a Database server.
The following illustration displays a common topology for an idle standby configuration. There are two WebSphere Portal Express nodes on individual servers. Both nodes are members of the same cluster cell. The database and LDAP server software are all installed on individual servers too.
In this topology, the IP sprayer will route incoming requests to Node A, the primary node. If Node A is not responding, the IP sprayer will route incoming requests the Node B. Both of the WebSphere Portal Express nodes are configured to use the same database server and LDAP server.
In the topology the LDAP and database servers are not clustered, so they represent a single point of failure. The database and LDAP servers could be clustered to eliminate the single points of failure.
Organizations that only need a small Web site or intranet site could implement a single server topology for Web Content Management. In a single server configuration, authoring and delivery occur on the same server. This configuration is not recommended for organizations that need a larger Web site or intranet site.
The following topology diagram illustrates a single-server configuration for Web Content Management. A Web server routes incoming requests from browser clients. Web Content Management, WebSphere Portal, and WebSphere Application Server are installed on the same server. The LDAP server that stores authorized user information is installed on a dedicated server. The database that stores content is also installed an a dedicated server. Although this diagram does not illustrate a cluster configuration, the Web Content Management server could be clustered. Similarly the LDAP and database servers could be clustered for failover.
To use a Web Content Management system, you will need to deploy a set of Web Content Management environments within your overall WebSphere Portal system. Reviewing the Web Content Management environments help you understand what happens in each environment and how you may want to setup your physical severs. Web Content Management is installed using the WebSphere Portal installation user interface.
Each server or cluster in your web content system requires a separate data repository, but they would usually share the same LDAP. A Web Content Management system can be deployed in isolation or in parallel with a WebSphere Portal system.
The type of web content system you deploy is determined by the size of your web content system, the type of website being delivered and the number of users creating and viewing your web content.
An authoring environment is used to create and manage web content and is used by your content creators and website designers.
A standard authoring environment consists of a single authoring cluster that syndicates directly to either a staging or delivery environment. For example:
You can add a test environment to your authoring environment to enable you to perform user acceptance testing on your content management system and website. For example:
For example, if you have users located in different locations, it may be more efficient to install a local authoring environment at each location. Two-way syndication is used between all authoring environments with a centralized authoring environment to allow changes made at all remote locations to be visible to all users.
Decentralized authoring creates the risk of conflicting updates between authoring environments. To reduce the risk of conflicts, you can allocate different sites, or different sections of a site, to each authoring environment. You can also use different authoring environments for different user roles. For example, Content creators could use a different authoring environment than presentation template designers.
Access to each decentralized authoring environment is controlled using a combination of authoring portlet access controls and item security settings. For example, Only users requiring access to the local authoring environment would be granted access to the local authoring portlet. Users would be given "Read" access to all items, but only "Edit" access to items they are required to update.
This environment is used by your UAT testers and can be as simple as an individual UAT server where site and content updates can be tested before being syndicated to the delivery environment, or as complex as complete replica of your delivery environment where UAT can occur to both review site and content updates, and to test the performance of your delivery environment. It can also be used to accumulate changes from your authoring environment before syndicating your changes to your delivery environment in a single batch.
You can add a testing environment to your authoring environment to enable user acceptance testing to be performed on your content management system and your website:
You can perform system testing on a replica of your delivery environment before syndicating your changes to the live delivery environment:
A delivery environment is used to deliver content to your web site viewers.
You can pre-render a complete website into HTML and save it to disk. The pre-rendered site can then be used as your live site and displayed to users using either Web Content Management or a web server. You deploy a pre-rendered site when you are not using any WebSphere Portal features, such as portlets, and your content is static and is only updated periodically.
Users can access content displayed using the Web Content Management servlet. A servlet delivered website is used when you do not need to use any portlet-based features such as authoring tools.
Web content viewers are portlets that display content from a web content library as part of a portal page. If your presentation is simple, a single web content viewer can be sufficient, but you can also use multiple web content viewers to aggregate content from different libraries and provide a richer experience for your users. A local web content view portlet is used to display content within your web content delivery environment.
WSRP support in the JSR 286 web content viewer is used to display content on a remote WebSphere Portal server or cluster.
IBM WebSphere Portal Express comes with a special license that lets you install and deploy the product for a 60 day evaluation at no charge. If you subsequently purchase WebSphere Portal Express, a simple utility lets you convert the evaluation license to a full production license. Users who prefer to purchase and install WebSphere Portal Express directly, without the evaluation license, can do so without having to install or convert the evaluation license.
When you install WebSphere Portal Express under the terms of the 60-day evaluation license, individuals and teams can explore and use the site right away.
Each time you launch the site, the SystemOut log file records the number of days remaining in the evaluation license. The log file is located in wp_profile_root/logs/WebSphere_Portal.
To continue use after the evaluation license expires, you need to purchase WebSphere Portal Express. The purchased production software includes the files needed to convert the previously installed evaluation license to a full production license. Custom templates and data files that users created during the evaluation period are fully compatible with the production license, so no additional migration is required.
For purchasing information, contact your local IBM representative or authorized IBM Business Partner.
By default IBM WebSphere Portal Express uses the internal HTTP transport within IBM WebSphere Application Server to handle requests. However, because WebSphere Application Server also supports the use of an external Web server, you can access WebSphere Portal Express from your Web server. You can use a local Web server on the same machine as WebSphere Portal Express or you can use a remote Web server on a different machine. A remote Web server is typical for a production environment or other high-traffic configuration and is also typically placed in demilitarized zones (DMZ) outside a firewall to protect portal ports.
To enable communication between the Web server and WebSphere Application Server, a Web server plug-in is required. The Web server plug-in determines whether a request is handled by the Web server or by the application server. The plug-in can be installed into a Web server that is located either on the same machine as WebSphere Application Server or on a separate machine. The Web server plug-in uses an XML configuration file (plugin-cfg.xml) that contains settings that describe how to handle and pass on requests to the WebSphere Application Server made accessible through the plug-in.
In the WebSphere Application Server administrative console, the Web server is represented as a specific server type, and you can view or modify all of the configuration properties used in the plugin-cfg.xml file for the Web server plug-in from the administrative console.
i users: For detailed information on using an external Web server with your i system, see Selecting a Web server topology diagram and roadmap, in addition to the steps listed on this page.
By default WebSphere Portal Express is configured to be accessed through the internal HTTP port in WebSphere Application Server. For example, http://hostname.example.com:10039/wps/portal, where hostname.example.com is the fully qualified host name of the machine where WebSphere Portal is running and 10039 is the default transport port that is created by WebSphere Application Server; the port number may be different for your environment. The default host name and port used by WebSphere Portal Express are specified by the WpsHostName and WpsHostPort properties in the wkplc.properties file.
After configuring WebSphere Portal Express to use an external Web server, you will access the portal with the Web server host name and port (for example, 80). For stand-alone servers or vertical cluster members, you will be unable to access the portal using the WebSphere Portal Express host name and port (for example, 10039), unless there is a corresponding virtual host definition for port 10039 in the WebSphere Application Server configuration.
By default, IBM WebSphere Portal Express installs and uses IBM DB2 Universal Database™ Workgroup Server Edition. Installing with DB2 lets you quickly get WebSphere Portal Express installed and running in a production-level environment.
With appropriate tuning, other databases can provide performance gains. Other databases support vertical and horizontal clusters and cloning. Use multiple databases for high performance and availability.
When you choose to transfer data to another supported database, perform the database transfer before you use the portal extensively. Large amounts of data in the databases can cause the database transfer to fail if your Java heap size is not large enough. Because information is added to the databases as you use the portal, perform database transfer as soon as you realize that a high volume of data needs to be stored and failover is necessary. Transferring the database sooner rather than later avoids the problems typically caused by transferring a high volume of data at a later stage to the other supported databases, including not having adequate Java heap size.
If you are transferring from a database other than the default database, you will need to edit the wkplc_sourceDb.properties, wkplc_dbdomain and wkplc_dbtype.properties files to update the source database information as an additional step before attempting the database transfer functions.
There are two types of database users: database configuration users and database runtime users. Become familiar with the privileges required for each user type to work with the database domains of IBM WebSphere Portal Express and the commands for creating database configuration users and granting privileges.
The database administration user that is typically created when a database management system (DBMS) is installed is the database installation user or the database configuration user. The database configuration user is not necessarily the user that is created by default when the database management system is installed. The default user could be used as the database configuration user. The database configuration user is used by WebSphere Portal Express for configuration tasks and creates the database structure needed by WebSphere Portal Express. For example, the database configuration user can create database tables and indexes, perform database transfer, and often times has operating system privileges, depending on the database management system.
The database runtime user has fewer privileges than the database configuration user. The runtime user has runtime access to the data source of a database and can perform basic read and write operations on the data. Consider creating a dedicated runtime user for each database domain of WebSphere Portal Express. If you do not create runtime users, then WebSphere Portal Express uses the configuration user to connect to the databases at runtime.
The following table identifies the minimum privileges needed to correct function by the two types of database users: configuration users and runtime users. The privileges listed pertain to all WebSphere Portal Express database domains.
| Permission within the database domain | Release | Community | Customization | JCR | Feedback | Likeminds |
|---|---|---|---|---|---|---|
| Access to the database | Yes | Yes | Yes | Yes | Yes | Yes |
| Read on all tables | Yes | Yes | Yes | Yes | Yes | Yes |
| Write on all tables | Yes | Yes | Yes | Yes | Yes | Yes |
| Update on all tables | Yes | Yes | Yes | Yes | Yes | Yes |
| Delete on all tables | Yes | Yes | Yes | Yes | Yes | Yes |
| Create tables | No | No | No | Yes | No | No |
| Create indexes | No | No | No | Yes | No | No |
| Use of sequences | No | No | No | Yes | Yes | No |
| Permission within the database domain | Release | Community | Customization | JCR | Feedback | Likeminds |
|---|---|---|---|---|---|---|
| Access to the database | Yes | Yes | Yes | Yes | Yes | Yes |
| Read on all tables | Yes | Yes | Yes | Yes | Yes | Yes |
| Write on all tables | Yes | Yes | Yes | Yes | Yes | Yes |
| Update on all tables | Yes | Yes | Yes | Yes | Yes | Yes |
| Delete on all tables | Yes | Yes | Yes | Yes | Yes | Yes |
| Quota on disk to create new objects | Yes | Yes | Yes | Yes | Yes | Yes |
| Create table spaces | Yes | Yes | Yes | Yes | Yes | Yes |
| Drop table spaces | Yes | Yes | Yes | Yes | Yes | Yes |
| Create tables | Yes | Yes | Yes | Yes | Yes | Yes |
| Alter tables | Yes | Yes | Yes | Yes | Yes | Yes |
| Drop tables | Yes | Yes | Yes | Yes | Yes | Yes |
| Create indexes | Yes | Yes | Yes | Yes | Yes | Yes |
| Drop indexes | Yes | Yes | Yes | Yes | Yes | Yes |
| Create triggers | Yes | Yes | Yes | Yes | Yes | Yes |
| Drop triggers | Yes | Yes | Yes | Yes | Yes | Yes |
| Create sequences | No | No | No | Yes | Yes | No |
| Use of sequences | No | No | No | Yes | Yes | No |
| Create types | No | No | No | Yes | No | No |
| Drop types | No | No | No | Yes | No | No |
| Create views | No | No | No | Yes | No | No |
| Drop views | No | No | No | Yes | No | No |
Consider the database configuration options in relation to your IBM WebSphere Portal Express deployment scenario. The complexity of the network topology will increase as you scale from a proof-of-concept environment using IBM DB2 Universal Database Workgroup Server Edition to systems using vertical and horizontal cloning techniques.
WebSphere Portal Express data can be configured in a single store or organized into database domains to meet different availability requirements, depending on your deployment scenarios for proof-of-concept and production environments. The database domains provided by WebSphere Portal Express help you classify and distribute portal data. Each database domain can be placed on a separate database for efficient maintenance. Additionally, each domain can be placed on a separate database server system for maximum performance.
Database domains classify and help you determine how to distribute portal data. To maximize data availability, you can distribute portal data across multiple databases and, for some domains, share data between multiple lines of production. You can choose to transfer a single database domain or multiple domains.
Separation of data allows you to store each category of data in its own set of database tables or the file system. The sets of databases tables and schemas for portal resources are called database domains. Database domains support the storage and transfer of data by category, for example, Configuration, Release, Customization, Community, and IBM Java Content Repository (JCR). Separating your data allows you to share domains across multiple portals. You can also spread the different domains across different database types. For example, you can choose to leave LikeMinds data on your default database and move all other data to another database. The separation of the domains can be used to support production environments, where the production nodes are split into separate clusters. Each cluster can run independently, but share the same Community and Customization database domains, for example. Each of these clusters is called a line of production.
Preferences are kept in layers that are modifiable based on portlet modes. For example, there is one layer of default preferences defined by the portlet deployment descriptor. This layer is modifiable within the CONFIG mode supported by WebSphere Portal. In WebSphere Application Server, the values of the portlet deployment descriptor are read-only. WebSphere Portal provides one additional preference layer that enables portal administrators to specify different default values per portlet window. This capability is supported through the portlet mode EDIT_DEFAULTS, and applies to all who use the same portlet window. There is no such preference layer in WebSphere Application Server. Both products support the standard modes: VIEW, EDIT, and HELP. When a user customizes a portlet on a page in any standard mode, the user can change his personal portlet preferences. Default preferences on a per page or per portlet base cannot be set in any standard mode; you need to use custom portlet modes instead. Porltet preferences are stored in the customization domain when stored by users (typically in edit mode) on the entity level whereas when using configure mode, we're working on the portlet definition level and those are stored on the release level.
| Database domain | Sharable | Storage method |
|---|---|---|
| Release | no | database |
| Customization | yes | database |
| Community | yes | database |
| JCR | no | database |
| Feedback | yes | database |
| LikeMinds | yes | database |
For maintenance and staging purposes you can take a single line of production out of service while another line is still serving requests with the old data. After the first production line is updated and back in service again, the second line is updated using the same approach. Updates of data in the shared domain are critical because they influence the other production line.
The capacity of the entire environment should be greater than the intended use so that individual servers can be taken out of production without affecting application availability. To ensure that all of the system resources are available for the portal, production systems should be dedicated to the portal and should not run any other server software that is not related to the portal.
The VMM database feature makes it much simpler to use multiple repositories, since this capability is achieved through configuration, rather than development, with the use of the new VMM. In essence, this feature provides the ability to map entries from multiple individual user repositories into a single virtual repository. The federated repository consists of a single named realm, which is a set of independent user repositories. Each repository may be an entire external repository or, in the case of LDAP, a subtree within that repository. The root of each repository is mapped to a base entry within the federated repository, which is a starting point within the hierarchical namespace of the virtual realm.The Virtual Member Manager (VMM) databases for a full repository and for the property extension can be shared between lines of production. If the VMM databases are out of service, WebSphere Portal Express will not function.
If you are a database administrator, consider the database requirements for IBM WebSphere Portal Express.
When planning to transfer data to IBM DB2 Universal Database Enterprise Server Edition, you should consider the databases and user information, such as database names, what data is stored, and the database space needed. Some fix packs require steps prior to the transfer task to complete successfully.
The database names and users on this page are suggested values and provide consistency throughout the documentation. Replace these values with values in your environment. The database name cannot exceed eight characters and can only contain letters and numbers.
In a local database environment, WebSphere Portal Express and DB2 are installed on the same system.
As shown in Figure 2, when a JDBC type 2 connections is used, WebSphere Portal Express and DB2 Connect are installed on one system (the local system). The DB2 server is installed on a separate system (the remote system).
For JDBC type 4 connections, no DB2 Connect installation is required on the system that runs WebSphere Portal Express. As shown in Figure 3, the DB2 Universal JDBC driver that is supplied with DB2 is copied to this system. It is used within the Java Virtual Machine of WebSphere Portal Express and connects directly to the remote DB2 server.
When planning to transfer data to IBM DB2 Universal Database Enterprise Server Edition, you should consider the databases and user information, such as database names, what data is stored, and the database space needed. Some fix packs require steps prior to the transfer task to complete successfully.
The database names and users on this page are suggested values and provide consistency throughout the documentation. Replace these values with values in your environment. The database name cannot exceed eight characters and can only contain letters and numbers.
In a local database environment, WebSphere Portal Express and DB2 are installed on the same system.
As shown in Figure 2, when a JDBC type 2 connections is used, WebSphere Portal Express and DB2 Connect are installed on one system (the local system). The DB2 server is installed on a separate system (the remote system).
For JDBC type 4 connections, no DB2 Connect installation is required on the system that runs WebSphere Portal Express. As shown in Figure 3, the DB2 Universal JDBC driver that is supplied with DB2 is copied to this system. It is used within the Java Virtual Machine of WebSphere Portal Express and connects directly to the remote DB2 server.
When planning to transfer data to IBM DB2 for i, you should consider the databases and user information, such as database names, what data is stored, and the database space needed. Some fix packs require steps prior to the transfer task to complete successfully.
DB2 is integrated with i, but you must create the required databases and users and grant the proper privileges to those users. WebSphere Portal Express can create the databases for you.
The database names and users in this topic are suggested values and provide consistency throughout the documentation. Replace these values with values in your environment.
WebSphere Portal Express uses DB2 during installation, and supports configuration of DB2 for an IBM System i5 system.
The IBM DB2 for i database enables you to access and manage server data through an application or a user interface. In addition to providing access to and protection for your data, IBM DB2 Universal Database for i provides advanced functions, such as referential integrity and parallel database processing.
IBM DB2 for i is the relational database manager that is fully integrated on your i system. IBM DB2 for i also provides features such as triggers, stored procedures, and dynamic bitmapped indexing that serve a wide variety of application types. These applications range from traditional host-based applications to client/server solutions to business intelligence applications.
As an interface to IBM DB2 for i, the DB2 Query Manager and Structured Query Language (SQL) Development Kit for System i5 add an interactive query and report writing interface, and precompilers and tools to assist in writing SQL application programs in high-level programming languages. The SQL implementation for OS/400 allows you to define, manipulate, query, and control access to your i data. It works equally well with i files and SQL tables.
If you choose to use one database to hold all WebSphere Portal Express, Member Manager, and content publishing information, only one user profile is required. Additional user profiles are necessary only if using multiple i systems or separate databases are required.
When WebSphere Portal Express creates databases, it uses the database names that are specified in the wkplc_dbdomain.properties file, located in the UserData directory wp_profile_root/ConfigEngine/properties. It is possible to create up to six different databases by setting different values in the wkplc_dbdomain.properties file.
In a local database environment, WebSphere Portal Express and IBM DB2 for i can be accessed with either a Type 4 or Type 2 connection. Type 4 is the default and recommended connection.
In a remote database environment, WebSphere Portal Express connects directly to the DB2 server (JDBC Type 4 connection).
When planning to transfer data to IBM DB2 Universal Database for z/OS®, you should consider the databases and user information, such as database names, what data is stored, and the database space needed. Some fix packs require steps prior to the transfer task to complete successfully.
When planning to install DB2 for z/OS to use as the database for WebSphere Portal Express, consider the following:
-db2 display bufferpool(bp2) -db2 alter bufferpool(bp2) vpsize(15000)
The database names and users on this page are suggested values and provide consistency throughout the documentation. Replace these values with values in your environment. The database name cannot exceed eight characters and can only contain letters and numbers.
When planning to transfer data to Oracle, you should consider the databases and user information, such as database names, what data is stored, and the database space needed.
The database names and users in this topic are suggested values and provide consistency throughout the documentation. Replace these values with values in your environment.
When planning to transfer data to Oracle RAC, you should consider the databases and user information, such as database names, what data is stored, and the database space needed.
The database names and users in this topic are suggested values and provide consistency throughout the documentation. Replace these values with values in your environment.
The default tablespace size for Oracle RAC may need to be set to 1024MB with autoextend turned on for database transfer to be successful.
When planning to transfer data to SQL Server, you should consider the databases and user information, such as database names, what data is stored, and the database space needed.
The database names and users in this topic are suggested values and provide consistency throughout the documentation. Replace these values with values in your environment.
A user registry or repository authenticates a user and retrieves information about users and groups to perform security-related functions, including authentication and authorization.
Based on the federated repository, WebSphere Portal Express allows you to create a user base that can be federated over multiple repositories: LDAP, DB, and/or custom user registry. It also allows you to define additional attributes in a separate store if your corporate LDAP directory is read-only.
If you are using a federated repository, you must plan on where you want to store new users and groups. By default, new users and groups are stored in the default file repository. If using multiple LDAP user registries and/or database user registries, you must figure out which user registry you want to define as your default user registry where new users and groups are stored. After you add all user registries to your federated repository, you can run the wp-set-entitytypes task to set a specific user registry as the default location.
If you have an application that does not support the federated repository, you can switch to a standalone LDAP user registry or a standalone custom user registry.
IBM WebSphere Portal Express provides a variety of security configuration tasks. In the past, there was one task, which did not let you recover from errors or allow your user registry to meet your growing business needs. Now there are multiple tasks, which allow you to fine-tune your system to meet your business needs.
| Security option | Explanation |
|---|---|
| Standalone LDAP security | This option is a simple, single LDAP security option, which is similar to the LDAP security option provided in the past. With this option, you can create Virtual Portals with a single realm and store users and groups in a single LDAP server. |
| Federated security | This option is an evolved option to the standalone LDAP
user registry with single realm support option. With this option, you can
create Virtual Portals with multiple realms, you can use multiple repositories
(LDAP, database, custom), and you can add Application Groups to your system.
This option is good if you have to merge multiple LDAP servers into one cohesive
structure. Important: You must take special care that there are
no duplicate names between the various repositories. For example, if you installed
the product with a Portal Administrator of "wpsadmin", then the user "wpsadmin"
should not exist in the corporate LDAP server.
|
| Custom security | This option provides you with the ability to write a full controlled WebSphere Security environment by providing a Custom User Registry and a Custom Member Adapter for Virtual Member Manager (VMM). The abilities of this option will depend on your implementation. |
Out-of-the-box, WebSphere Portal Express is configured with the default federated repository with a built-in file repository. Therefore, you must run the wp-modify-ldap-security task to switch to a standalone LDAP user registry. In order to ensure that your LDAP user registry runs properly with WebSphere Portal, you must then adapt the attribute configuration to match the configured LDAP server and your business needs. After completing the steps for these tasks, your security is ready for production.
| Task | Explanation |
|---|---|
| Update the standalone LDAP user registry | You can update certain parameters such as your bind ID and password to fix issues with your LDAP user registry. |
| Property extension database; formerly known as the lookaside database | Choose this option to store additional attributes inside the VMM property extension instead of within the LDAP user registry. Some applications, such as Common Mail portlet and IBM Lotus Web Content Management use the property extension database to store additional attributes. After you enable the property extension database, you can add attributes to meet your business needs. |
| Create the entity type | Choose this option if you want to use an entity type that exists in WebSphere Portal Express but not within your LDAP user registry. This option creates the entity type in your user registry and adds the relative distinguished name (RDN) to map the entity type between WebSphere Portal Express and your user registry. |
| Update an existing entity type | Choose this option to update the default parent of an existing, single entity type; for example, if you deleted a repository and the entity type points to the deleted repository, you will need to update the information to point to a new repository. |
| Task | Description |
|---|---|
| Add a federated LDAP repository to the VMM configuration | Select this option to add an LDAP server to the federated repository. This task does not change the current security assignment; therefore, the administrative user defined during installation is still active. |
| Add a federated database repository to the VMM configuration | Select this option to add a database to the federated repository. This task does not change the current security assignment; therefore, the administrative user defined during installation is still active. |
| Add a federated custom user registry | Select this option to add a custom user registry that your company created to the federated repository. This task does not change the current security assignment; therefore, the administrative user defined during installation is still active. |
| Task | Description |
|---|---|
| Change the user registry where users and groups are stored | This task changes the default repository where new users and groups are stored. |
| Change WebSphere Application Server administrator | This task changes the WebSphere Application Server administrator user ID and password from what was defined during installation to the new user ID and password required for your clustered or standalone production environment. |
| Change WebSphere Portal Server administrator | This task changes the WebSphere Portal Express administrator user ID and password from what was defined during installation to the new user ID and password required for your clustered or standalone production environment. |
| Delete a federated repository from the VMM configuration | This task deleted the default file-based repository from your configuration. |
| Task | Description |
|---|---|
| Updating the federated LDAP user registry | Choose this option to update certain parameters such as your bind ID and password to fix issues with your LDAP user registry. |
| Updating the federated database user registry | Choose this option to update certain parameters such as the data source name, database URL, and database type to fix issues with your database user registry. |
| Create a new realm | Choose this option to create a realm, which is a group of users from one or more user registries that form a coherent group within WebSphere Portal Express. Realms allow flexible user management with various configuration options. A realm must be mapped to a Virtual Portal to allow the defined users to log in to the Virtual Portal. In a federated repository, you can create multiple realms. |
| Property extension database; formerly known as the lookaside database | Choose this option to store additional attributes inside the VMM property extension instead of within the LDAP user registry. Some applications, such as Common Mail portlet and IBM Lotus Web Content Management use the property extension database to store additional attributes. After you enable the property extension database, you can add attributes to meet your business needs. |
| Create the entity type | Choose this option if you want to use an entity type that exists in WebSphere Portal Express but not within your LDAP user registry. This option creates the entity type in your user registry and adds the relative distinguished name (RDN) to map the entity type between WebSphere Portal Express and your user registry. |
| Update an existing entity type | Choose this option to update the default parent of an existing, single entity type; for example, if you deleted a repository and the entity type points to the deleted repository, you will need to update the information to point to a new repository. |
IBM WebSphere Application Server includes the Virtual Member Manager (VMM), which IBM WebSphere Portal Express uses to access user and group information. VMM provides an interface that enables communication between WebSphere Portal Express and any repository, whether federated repositories, a stand-alone repository, or your own custom user registry.
The Virtual Member Manager (VMM) is an abstract component within the WebSphere Application Server infrastructure. As the following diagram illustrates, WebSphere Portal Express uses the Portal User Management Architecture (PUMA) System Programming Interface (SPI) to retrieve and set attributes on user objects. PUMA passes these requests to VMM, which then passes the requests on to a corresponding registry adaptor that connects VMM to the repository.
An out-of-box implementation of the UserRegistry interface that supports multiple repositories. To communicate with the federated repositories, both WebSphere Application Server and WebSphere Portal Express dispatch all operations to VMM.
An out-of-box implementation of the UserRegistry interface where a single LDAP directory is the repository. WebSphere Application Server communicates directly with the stand-alone LDAP. WebSphere Portal Express communicates with the stand-alone LDAP through VMM.
VMM offers a Service Provider Interface (SPI), wim.Repository, that enables communication with repositories. WebSphere Application Server uses this SPI to connect to federated repositories. WebSphere Portal Express uses this SPI to connect to all repositories, whether federated or stand-alone.
An implementation of the VMM SPI that enables VMM to connect to a specific repository, whether an LDAP directory, database, files, or other repository. Registry adaptors enable communication between WebSphere Portal Express and any repository.
A realm is a collection of users or groups from one or more branches of your repository tree. Those branches can be part of a single repository, for example an LDAP user registry, or it can be a combination of multiple user registries. A realm is then mapped to a Virtual Portal to allow the realm's user population to log in to the Virtual Portal. This functionality allows you to define areas within WebSphere Portal Express that only a limited set of users can access.
For example, if you are an international company with employees in Asia, Europe, USA, and Canada, you may have an application or information that only applies to a subset of these employees. You can create a subset of employees and create a Virtual Portal that contains the application or information for that realm. Users from one realm cannot access another realm unless they are also members of that realm. For example, the wpsadmin user will not be able to log in to a Virtual Portal unless the wpsadmin user is a member of the corresponding realm.
The Property extension, formerly known as the lookaside database, allows you to store additional user attributes into a database store without touching your backend user registry. You can use the Property Extension if your LDAP is read-only but you have a requirement that allows users to specify an additional attribute such as Timezone. You can store this additional attribute in the database store. You can also add additional attributes for an application if you cannot change your repository Schema. Property extension can be used with a federated repository, a stand-alone LDAP user registry, or a custom user registry.
IBM WebSphere Portal Express is licensed for use in a single server configuration and may not be used in either a cloned configuration or a clustered configuration except when implementing idle standby for the purpose of failover.
In an idle standby configuration a server is considered idle if it is used exclusively for administrative needs and to assist in a failover situation. WebSphere Portal Express is installed on the idle standby server, but it is not operational to service user transactions or to query workloads.
Implementing idle standby requires the purchase of a separate WebSphere Portal Express Idle Standby Part Number, in addition to licensing the primary server, regardless of whether your primary servers are currently licensed under the per User License Option or the per Processor Value Unit License Option.
The deployment scenario, Deploying WebSphere Portal Express for high availability using idle standby, in the WebSphere Portal Express wiki provides information about setting up an idle standby configuration.
There are multiple installation methods (silent, graphical user interface, and console) and sources (DVD or DVD images).
Select the appropriate installation method for your environment. You can use either a graphical interface program, console mode, or a response file for a silent installation.
Before installing IBM WebSphere Portal Express, choose the installation source location and method that best fit your environment. For example, you can install from the DVD-ROM or from a file system and you can install using the graphical interface program or perform a silent installation.
You can add the following parameters to your installation command to customize your installation to meet your business needs.
IBM WebSphere Portal Express provides flexible deployment options ranging from proof-of-concept where you can examine and test functionality to a highly available and scalable production environment.
Set up a stand-alone production environment after you have tested a single server environment and are ready to create a production environment. You can modify this environment to support remote databases and different security options.
Late breaking installation limitations and issues
After completing the installation remember
to tune the servers in your portal environment in order to achieve better
performance. The Base Portal Tuning scenarios in the IBM WebSphere Portal
Express and IBM Lotus Web Content Management Performance Tuning Guide
provides information about tuning the IBM WebSphere Application
Server, WebSphere Portal Express services, databases, directory
servers and more. View information on setting up your operating system for IBM WebSphere Portal Express. Other components might require additional steps; see the product documentation for the specific components you want to install for information.
WebSphere Portal Express can be installed locally or remotely using a Windows workstation.
IBM WebSphere Portal Express is installed as a single component, complete with an integrated database for storing information. This allows you to get WebSphere Portal Express up and running quickly for a proof of concept phase where you can immediately begin building and working with it. You can also expand your environment to include idle-standby, a remote database for easier management and better distributed processing load, and LDAP-based authentication.
WebSphere Portal detailed system requirementsBefore you start the WebSphere Application Server server, you need to configure the software license agreement to set the usage limit from the Proof of Entitlement (POE) or invoice; see Configuring software license information for details.
If you initially installed IBM WebSphere Portal Express using the evaluation license and then purchased the product, you can convert the installed evaluation license to a production license. You can do this at any time, before or after the evaluation license expires.
| Method | Steps |
|---|---|
| Setup CD | Perform the following steps to convert the evaluation
license using the setup CD:
|
| Configuration task | Perform the following steps to convert the evaluation
license using a configuration task:
|
To setup a remote IBM DB2 for i database, create user IDs and databases on a remote server. Tasks are provided to assist with creating the user IDs and the databases. Before you can use the tasks, you must modify properties files.
Learn how to modify the wkplc.properties, wkplc_dbdomain.properties, and wkplc_dbtype.properties files to work with your database. Modify these property files before running tasks to create databases, create users, or transfer data.
View information on setting up user profiles for IBM DB2 for i to work with WebSphere Portal Express.
A remote database resides on a different system than WebSphere Portal Express. When you use a remote server, you must manually create the databases that are required by WebSphere Portal Express.
For example, the default database and database library name for WebSphere Portal Express release domain is release.DbName=wpsdb. If you wanted to create this database library on a remote database, change the default value to release.DbName=hostname/wpsdb
View the steps to manually transfer data to the IBM DB2 Universal Database for i database you have set up. As an alternative to the manual database transfer procedure described here, you can use the configuration wizard to complete the database transfer task. However, you cannot specify all settings through the configuration wizard. For example, regardless of the method used to transfer data, you must run a configuration task to create JMS resources as described in this topic.
Before you begin:
Ensure that the following prerequisites are met:
After WebSphere Portal Express is configured to work with your database, test the database connection to ensure that it operates correctly.
To verify that WebSphere Portal Express is running from a browser, open the portal in a Web browser: http://hostname.yourco.com:port_number/wps/portal, where hostname.yourco.com is the fully qualified host name of the machine where WebSphere Portal Express is running and port_number is the transport port that is created by IBM WebSphere Application Server.
Verify the connection from a command line by completing the following steps:
For security reasons, you should not leave passwords in the wkplc_dbdomain.properties file. Edit the file prior to running a configuration task and insert the passwords that are needed for that task. After the task has run, delete all passwords from the file.
Alternatively, you can specify the password on the command line rather than update the wkplc_dbdomain.properties file. For example: ConfigEngine.sh -DPortalAdminPwd=password -DWasPassword=password validate-database
When installing WebSphere Portal Express, the passwords in the wkplc_dbdomain.properties file are automatically removed after configuration.
Install and configure the Web server plug-in, provided by IBM WebSphere Application Server, to set up your Web server to communicate with IBM WebSphere Portal Express.
Configure user registry security on IBM WebSphere Portal Express to protect your server from unauthorized users. You can configure a stand-alone LDAP user registry or you can add LDAP user registries and/or database user registries to the default federated repository. After configuring your user registry, you can add realms for Virtual Portals or a lookaside database to store attributes that cannot be stored in the LDAP user registry.
If you plan to use a Tivoli Directory Server as an LDAP user registry, you must install and set up the server so that it will communicate with IBM WebSphere Portal Express.
Choose between securing IBM WebSphere Portal Express with a standalone LDAP user registry or by adding LDAP user registries and/or database user registries to the default federated repository.
Depending on the type of data that is exchanged between IBM WebSphere Application Server, IBM WebSphere Portal Express, and your LDAP server, you can either configure your LDAP server over SSL or configure it to have direct access to IBM WebSphere Application Server and IBM WebSphere Portal Express.
Configure IBM WebSphere Portal Express to use a standalone LDAP user registry to store all user account information for authorization.
If you need to rerun the wp-modify-ldap-security task to change the LDAP repositories or because the task failed, you must choose a new name for the realm using the standalone.ldap.realm parameter or you can set ignoreDuplicateIDs=true in the wklpc.properties file, before rerunning the task.
Configure IBM WebSphere Portal Express to use a standalone LDAP user registry over SSL to store all user account information for secure authorization.
Add an LDAP user registry and/or a database user registry to the default federated repository to create seamless authentication within the repository.
Depending on the type of data that is exchanged between IBM WebSphere Application Server, IBM WebSphere Portal Express, and your LDAP server, you can either configure your LDAP server over SSL or configure it to have direct access to IBM WebSphere Application Server and IBM WebSphere Portal Express.
Add an LDAP user registry to the default federated repository to store user account information for authorization. You can add multiple LDAP user registries to the default federated repository although you can only add one LDAP server at a time. If IBM Lotus Domino will be one of your user registries in a multiple registry configuration and will share a realm with another user registry, ensure that the groups are stored in a hierarchical format in the Domino Directory as opposed to the default flat-naming structure. For example, the flat-naming convention is cn=groupName and the hierarchical format is cn=groupName,o=root. You must also ensure that the IDs that are unique between the default federated repository and the LDAP you are adding. For example, if the default federated repository contains an ID such as wpsadmin, this ID cannot exist in the LDAP you are adding.
Add an LDAP user registry over SSL to the default federated repository to store user account information for secure authorization. You can add multiple LDAP user registries to the default federated repository although you can only add one LDAP server at a time.
Add a database user registry to the default federated repository to store user account information for authentication and authorization. You can add multiple database user registries to the default federated repository although you can only add one database user registry at a time.
A realm is a group of users from one or more user registries that form a coherent group within IBM WebSphere Portal Express. Realms allow flexible user management with various configuration options. A realm must be mapped to a Virtual Portal to allow the defined users to log in to the Virtual Portal. When configuring realm support, you can perform these steps for each base entry that exists in your LDAP and/or database user registry to create multiple realm support.
In single server environments, you do not have to start or stop the WebSphere_Portal and server1 servers to complete the following steps. In clustered environments, you must stop all application servers on your system, including WebSphere_Portal, then start the nodeagent and deployment manager servers before you begin any of the following steps.
After installing IBM WebSphere Portal Express and configuring your LDAP user registries, you will need to adapt the attribute configuration to match the configured LDAP server(s) and your business needs. However, you do not need to perform these steps if you are using either a database user registry or the default federated file-based repository for out-of-box installations.
After installation, IBM WebSphere Portal Express has a predefined set of attributes for users and groups. Your LDAP server may have a different set of predefined user and group attributes. To ensure proper communication between WebSphere Portal Express and your LDAP server, you can configure additional attributes and flag existing attributes as required or unsupported on a per repository basis or for all configure repositories.
After installing IBM WebSphere Portal Express and configuring your LDAP user registries, you can query the defined attributes to see what attributes are flagged as unsupported or if the attribute is mapped to a different LDAP attribute.
The VMM is configured with a default attribute schema that might not be compatible with your LDAP server. If this is the case, extend the VMM attribute schema by adding new attributes that you can map between IBM WebSphere Portal Express and your user registry.
After you install and configure your LDAP user registry and after you query the defined attributes, you can map the attributes so they match the configured LDAP servers and your business needs.
Due to a Virtual Member Manager (VMM) limitation, there is currently no task to update an attribute. Therefore, if you added an attribute to your property extension database or when adapting attributes to match your LDAP server that were spelled incorrectly or already added due to migration, you must remove the attribute from the database. Use caution when performing these steps.
By default, WebSphere Portal Express is enabled for static groups. However, the Virtual Member Manager (VMM) allows users to be members of either static or dynamic groups. Static groups are those where a persistent binding exists between a group and its members. Dynamic groups are those where a search query is defined to retrieve the members of a group. If you have your LDAP server configured to use dynamic groups, complete the steps in this task for WebSphere Portal Express to use dynamic group queries when you setup your LDAP server.
The steps in this task use groupOfURLs as the object class for dynamic groups and memberURL as the dynamic membership attribute. The actual values for object classes and dynamic membership attributes can vary depending on your LDAP server. For this reason, you should export an LDIF file to verify the object classes and dynamic membership attributes. Either refer to your LDAP documentation or ask your LDAP administrator for instructions on exporting an LDIF file.
To configure WebSphere Portal Express to use dynamic groups, do the following:
Referrals redirect object requests from one LDAP server to another when objects do not exist or cannot be located in a particular directory tree. You should enable referrals if your environment has more than one user registry existing on multiple servers or domains.
Tuning the servers is important to the performance of your WebSphere Portal environment. WebSphere Portal is not tuned for a production environment out of the box, so to ensure optimal performance, review and complete the steps in the IBM WebSphere Portal Tuning Guide. Even if a tuning guide is not available for the current release of WebSphere Portal, the tuning guide for the previous product version should be used.
Set up your IBM WebSphere Portal Express environment as an idle standby configuration for the purpose of failover. Your idle standby cluster server is not operational to service user transactions or to query workloads. The idle standby cluster server becomes active only if the primary node fails.
Before creating your high availability production environment, you must prepare your database, your user registry, your deployment manager, and your remote Web server.
View information on setting up your operating system for IBM WebSphere Portal Express. Other components might require additional steps; see the product documentation for the specific components you want to install for information.
WebSphere Portal Express can be installed locally or remotely using a Windows workstation.
IBM WebSphere Portal Express provides a customized installation package (CIP) that includes IBM WebSphere Application Server Network Deployment and all required maintenance packages. Use the supplied discs to install WebSphere Application Server Network Deployment on a dedicated system.
IBM WebSphere Portal Express is installed as a single component, complete with an integrated database for storing information. This allows you to get WebSphere Portal Express up and running quickly for a proof of concept phase where you can immediately begin building and working with it. You can also expand your environment to include idle-standby, a remote database for easier management and better distributed processing load, and LDAP-based authentication.
Before you start the WebSphere Application Server server, you need to configure the software license agreement to set the usage limit from the Proof of Entitlement (POE) or invoice; see Configuring software license information for details.
To setup a remote IBM DB2 for i database, create user IDs and databases on a remote server. Tasks are provided to assist with creating the user IDs and the databases. Before you can use the tasks, you must modify properties files.
View the mandatory preparation tasks prior to creating databases that are required by WebSphere Portal.
View information on setting up user profiles for IBM DB2 for i to work with WebSphere Portal Express.
A remote database resides on a different system than WebSphere Portal Express. When you use a remote server, you must manually create the databases that are required by WebSphere Portal Express.
For example, the default database and database library name for WebSphere Portal Express release domain is release.DbName=wpsdb. If you wanted to create this database library on a remote database, change the default value to release.DbName=hostname/wpsdb
After installing IBM WebSphere Application Server Network Deployment and installing IBM WebSphere Portal Express on the primary node, you must configure the deployment manager.
After installing IBM WebSphere Portal Express on the primary node, configuring a remote database, and preparing the primary node to communicate with the Deployment Manager, you can create your idle standby cluster.
Install and configure the Web server plug-in, provided by IBM WebSphere Application Server, to set up your Web server to communicate with IBM WebSphere Portal Express.
Configure user registry security on IBM WebSphere Portal Express to protect your server from unauthorized users. You can configure a stand-alone LDAP user registry or you can add LDAP user registries and/or database user registries to the default federated repository. After configuring your user registry, you can add realms for Virtual Portals or a lookaside database to store attributes that cannot be stored in the LDAP user registry.
If you plan to use a Tivoli Directory Server as an LDAP user registry, you must install and set up the server so that it will communicate with IBM WebSphere Portal Express.
Choose between securing IBM WebSphere Portal Express with a standalone LDAP user registry or by adding LDAP user registries and/or database user registries to the default federated repository.
Depending on the type of data that is exchanged between IBM WebSphere Application Server, IBM WebSphere Portal Express, and your LDAP server, you can either configure your LDAP server over SSL or configure it to have direct access to IBM WebSphere Application Server and IBM WebSphere Portal Express.
Configure IBM WebSphere Portal Express to use a standalone LDAP user registry to store all user account information for authorization.
If you need to rerun the wp-modify-ldap-security task to change the LDAP repositories or because the task failed, you must choose a new name for the realm using the standalone.ldap.realm parameter or you can set ignoreDuplicateIDs=true in the wklpc.properties file, before rerunning the task.
Configure IBM WebSphere Portal Express to use a standalone LDAP user registry over SSL to store all user account information for secure authorization.
Add an LDAP user registry and/or a database user registry to the default federated repository to create seamless authentication within the repository.
Depending on the type of data that is exchanged between IBM WebSphere Application Server, IBM WebSphere Portal Express, and your LDAP server, you can either configure your LDAP server over SSL or configure it to have direct access to IBM WebSphere Application Server and IBM WebSphere Portal Express.
Add an LDAP user registry to the default federated repository to store user account information for authorization. You can add multiple LDAP user registries to the default federated repository although you can only add one LDAP server at a time. If IBM Lotus Domino will be one of your user registries in a multiple registry configuration and will share a realm with another user registry, ensure that the groups are stored in a hierarchical format in the Domino Directory as opposed to the default flat-naming structure. For example, the flat-naming convention is cn=groupName and the hierarchical format is cn=groupName,o=root. You must also ensure that the IDs that are unique between the default federated repository and the LDAP you are adding. For example, if the default federated repository contains an ID such as wpsadmin, this ID cannot exist in the LDAP you are adding.
Add an LDAP user registry over SSL to the default federated repository to store user account information for secure authorization. You can add multiple LDAP user registries to the default federated repository although you can only add one LDAP server at a time.
Add a database user registry to the default federated repository to store user account information for authentication and authorization. You can add multiple database user registries to the default federated repository although you can only add one database user registry at a time.
A realm is a group of users from one or more user registries that form a coherent group within IBM WebSphere Portal Express. Realms allow flexible user management with various configuration options. A realm must be mapped to a Virtual Portal to allow the defined users to log in to the Virtual Portal. When configuring realm support, you can perform these steps for each base entry that exists in your LDAP and/or database user registry to create multiple realm support.
In single server environments, you do not have to start or stop the WebSphere_Portal and server1 servers to complete the following steps. In clustered environments, you must stop all application servers on your system, including WebSphere_Portal, then start the nodeagent and deployment manager servers before you begin any of the following steps.
After installing IBM WebSphere Portal Express and configuring your LDAP user registries, you will need to adapt the attribute configuration to match the configured LDAP server(s) and your business needs. However, you do not need to perform these steps if you are using either a database user registry or the default federated file-based repository for out-of-box installations.
After installation, IBM WebSphere Portal Express has a predefined set of attributes for users and groups. Your LDAP server may have a different set of predefined user and group attributes. To ensure proper communication between WebSphere Portal Express and your LDAP server, you can configure additional attributes and flag existing attributes as required or unsupported on a per repository basis or for all configure repositories.
After installing IBM WebSphere Portal Express and configuring your LDAP user registries, you can query the defined attributes to see what attributes are flagged as unsupported or if the attribute is mapped to a different LDAP attribute.
The VMM is configured with a default attribute schema that might not be compatible with your LDAP server. If this is the case, extend the VMM attribute schema by adding new attributes that you can map between IBM WebSphere Portal Express and your user registry.
After you install and configure your LDAP user registry and after you query the defined attributes, you can map the attributes so they match the configured LDAP servers and your business needs.
Due to a Virtual Member Manager (VMM) limitation, there is currently no task to update an attribute. Therefore, if you added an attribute to your property extension database or when adapting attributes to match your LDAP server that were spelled incorrectly or already added due to migration, you must remove the attribute from the database. Use caution when performing these steps.
