New features of WebSphere Portal 8.0: New Configuration Wizard Assistant

Background introduction to the WebSphere Portal Configuration Wizard

The Configuration Wizard in the WebSphere Portal has always been a favorite tool for users to help simplify the configuration process by manually modifying a large number of configuration parameters in the configuration file, and now just follow the configuration Wizard to fill in the simple information step-by-step. Basically, the Configuration Wizard simplifies the configuration process in several ways:

The configuration Wizard picks up all the relevant configuration parameters for this task for the tasks that the user is about to complete, and places them in different steps, grouped by the relationships between them. This avoids the need for users to determine which parameters are to be modified and which ones are irrelevant and should not be modified from the hundreds of configuration parameters. After using the Configuration Wizard, users will never have to worry about missing the required parameters.

The configuration Wizard filters the configuration parameters that are required to be filled in the next step, based on the information that the user fills out in the previous steps. For example, if a user chooses the target database type to be DB2 in the task of database migration, the next step will filter out the configuration parameters of the other database types without the user filling it out. Also, the Configuration Wizard provides default values and help information for each configuration parameter to make it easier for users to fill out.

Introduction to the Configuration Wizard's running environment

In the version prior to WebSphere Portal 8.0, the Configuration Wizard is a Java client program running on the server where the WebSphere portal resides, based on the InstallShield Installation Configuration Wizard, which primarily provides a database relocation Move and configure support for security tasks. In WebSphere Portal 8.0, the Configuration Wizard has a completely new upgrade, not only in the way it moves from Java client applications to Dojo based WEB applications, but also in terms of scalability, which can be greatly enriched by the configuration tasks covered. As we know, Web applications are naturally running on Web servers, and our configuration wizards are also running on WebSphere application server. One might see some doubt here, in common configuration tasks, it is often necessary to restart the WebSphere application server to make the modified configuration effective (for example, when configuring security for the WebSphere Portal, you need to restart WebSphere for new security to take effect). So at this point in time, our Configuration Wizard is not interrupted? The configuration tasks that we performed through the configuration Wizard were interrupted so that we couldn't do it, did we? Others may have other concerns that each WebSphere node in a clustered environment is managed by the Deployment Manager (Deployment Manager), and that each WebSphere's own management console is inaccessible, and then the Natural Configuration Wizard will not be able to access it. How do you deal with this situation?

For the above questions, let's look at the architecture of the Configuration Wizard. First, it is deployed on the WebSphere application server as an extension module for the Integrated Solution console (Integrated System console, abbreviated as "ISC"). Second, we created a proprietary profile for the Configuration Wizard in WebSphere, the name of the profile, called "Cw_profile." The operation of this profile and its security is completely independent, so configuration tasks such as changing the security of the WebSphere Portal do not affect the operation of this profile at all, and our configuration wizards are always running to complete a variety of configuration tasks. Finally, although the Configuration Wizard is deployed by default on the same machine as the WebSphere Portal, we can still deploy it to WebSphere or deployment Manager on other machines. In this way, we ensure that the Configuration Wizard is fully independent and unaffected by any other factors. Steps on how to deploy the configuration Wizard to another machine can be found in the information Center in WebSphere Portal 8.0, which is not discussed here.

Figure 1. Configuration Wizard in the integrated solution console

Three new features of the Configuration Wizard

In the New Configuration Wizard, the functionality included is significantly better than the previous version. In simple terms, it can be divided into three features: running the Configengine task from the Web interface, viewing the system log, workflow. The first two features can be seen as complements to existing configengine, and the final workflow functionality is the focus of the configuration Wizard. Let's take a look at what each piece of functionality contains.

Run the Configengine task from the Web interface

As we know, all configuration tasks in the WebSphere Portal are ultimately performed through the Configengine command-line tool, and all configuration tasks are ANT tasks based on Configengine. Typically, we are using a login to install a remote machine with the WebSphere Portal, which runs the Configengine task on the command line. Now that the Configuration Wizard has moved to the web side, running some simple configengine tasks can be submitted from the Web side with this feature of the Configuration wizard, eliminating the process of logging on to a remote machine.

Figure 2. Run the Configengine task from the Web interface

As can be seen from the above figure, it is very simple to run the Configengine task on the Web side, which mainly requires the user to provide the task name and the related attribute value that they want to run. This feature, in fact, provides an alternative to the way the command line runs, rather than inheriting the functionality of the Configuration Wizard in previous versions. The truly powerful wizard features are described in detail later in the Work Flow section.

As you can see in the previous illustration, we check the status of Configengine in the background before allowing the user to click on "Run Task now" because Configengine does not support concurrent multitasking, so we need to avoid the user submitting the task before discovering Configengine is already in a running state. If the current configengine is available, then the user can run the task immediately, and after the task is submitted, the page will show the progress of the background and the output in the log in real time until the task is finished running. There are two other options available here: Preferences settings and create scripts. Preference settings are mainly information that allows users to modify the default WebSphere Portal installation path, and to place temporary file paths. The "Create Script" provides a packaging feature that generates executable script files and property files and provides downloads for user-entered tasks and attribute values. Users can save these packaged files and simply run the executable script files when they need to run without having to re-enter these task names and attribute values. This feature can be used to delay the configuration task when the Configengine is locked in a state that cannot be run immediately, or if you want to reuse the scripts in the future.

It is to be noted that running the Configengine task from the Web side is limited to the Configuration Wizard installed on the same machine as the managed WebSphere Portal. This feature is not available if the Configuration Wizard is deployed on a different machine's WebSphere or Deployment Manager.