Deploying WSRR from the administrative console

You can deploy WSRR to a cluster or to federated servers by using the wizard in the deployment manager administrative console.

Before you begin

You must have created a Service Registry deployment manager profile, or augmented an existing deployment manager profile to include WSRR. You must have created Service Registry custom profiles, or augmented existing custom profiles, for your managed nodes. You must create the WSRR database manually, see Creating the WSRR database from scripts you have created.

You can create the database before or after you create or augment the profile, and deploy WSRR, but note that the deployed WSRR application will not start until the database is created and configured.

You must stop the server on any nodes that you want to deploy WSRR to.

About this task

You run the deploy WSRR wizard from either the servers collection or clusters collection view in the deployment manager administrative console.

Procedure

  1. Open the administrative console for the deployment manager profile. On Windows systems, you can start the administrative console from the First Steps console, or from the Start menu. On UNIX or Linux systems, start a browser and enter the URL https://dmgr-hostname:port/ibm/console (you can find the port number in DMGR PROFILEROOT/logs/AboutThisProfile.txt).
  2. Select a collections page:
    • If you are deploying to a cluster, select Servers > Clusters > Websphere application server clusters
    • If you are deploying to federated servers, select Servers > Server Types > Websphere application servers
  3. In the collection view, select the cluster or the federated server that you want to deploy WSRR to.
  4. Select Deploy WSRR to start the wizard.
  5. In the Deployment Settings window specify whether you want to deploy both the WSRR application and the WSRR service integration bus to the selected cluster or server. Click Next. You can select just one of these components for deployment if you are deploying to a topology that has separate clusters or servers for applications and for messaging.
    Note: You must deploy both components in the cell before you complete your total deployment, or WSRR will not function.
    If you are deploying the WSRR application and the service integration bus to separate clusters, you must deploy the bus first, and then you can configure the application cluster.
  6. In the WSRR Instance Prefix window, optionally specify a string to prefix to the WSRR application context root, to its display name, and to other resources. You must specify an instance prefix if you are deploying more than one instance of WSRR in a single cell. Note that this prefix appears in the URL that you use to connect to WSRR. The URL becomes http(s)://host:port/prefixServiceRegistry, for example https:localhost:9443/01ServiceRegistry. Click Next.
  7. In the Database configuration window, specify details of the WSRR databases for the deployed instance. The databases are not created by the deploy WSRR wizard, you must create them manually. Here you specify details for connecting to the database.
    • Database type. Select the RDBMS you use to host the WSRR databases from the list.
    • JDBC classpath. Specify the classpath for your RDBMS. For example, C:\Program Files\IBM\SQLLIB\java is the default location for DB2 Universal database on Windows.
    • WSRR database name. The name specified when the WSRR database was created.
    • Activity logging database name. The name specified when the activity logging database was created.
    • Service integration bus database name. The name specified when the service integration bus database was created.
    Click Next.
  8. In the WSRR Database settings window, specify connection details for your WSRR database:
    • WSRR database user name. The user id to use when connecting to the database.
    • WSRR database password. The password for the user id.
    • Schema name. The schema name for the WSRR database.
    • Database server name. The name or IP address of the server that is hosting the database.
    • Server port. The port that the server uses for communication with the database.
    Click Next.
  9. In the Activity logging database settings window, specify connection details for your activity logging database:
    • Activity logging database user name. The user id to use when connecting to the database.
    • Activity logging database password. The password for the user id.
    • Schema name. The schema name for the activity logging database.
    • Database server name. The name or IP address of the server that is hosting the database.
    • Server port. The port that the server uses for communication with the database.
    Click Next.
  10. In the Service integration bus database settings window, specify connection details for your service integration bus database:
    • Service integration bus database user name. The user id to use when connecting to the database.
    • Service integration bus database password. The password for the user id.
    • Schema name. The schema name for the service integration bus database.
    • Database server name. The name or IP address of the server that is hosting the database.
    • Server port. The port that the server uses for communication with the database.
    Click Next.
  11. In the WSRR RunAs security role settings window, specify the user name and password for the RunAs user. You can specify the WebSphere Application Server administrator user ID and password. Click Next.
    Note: If the RunAs User ID password is later updated, you must open the WebSphere Administrator console and ensure that the password is also updated in the ServiceRegistry application. If the password for the WebSphere Application Server admin user, as is the default, is changed you must reset both the JMS User ID and RunAs User ID passwords too.
    Note: If you plan to use the scheduler framework, or any WSRR feature that uses the scheduler framework, the specified RunAs user must belong to either the Administrator or the Operator administrative user role in WebSphere® Application Server. The following features use the scheduler framework:
    • Promotion
    • Service Discovery
    • Policy Analytics
    • Subscription notifier
    • UDDI synchronization
    • Text search
    • Tivoli® CCMDB synchronization
    • ALE synchronization
  12. In the JMS User ID Configuration window, specify the user name and password used by JMS to access WSRR. You can specify the WebSphere Application Server administrator user ID and password. Click Next.
    Note: If the JMS User ID password is later updated, you must open the WebSphere Administrator console and ensure that the password is also updated in the ServiceRegistry application. If the password for the WebSphere Application Server admin user, as is the default, is changed you must reset both the JMS User ID and RunAs User ID passwords too.
  13. In the WSRR J2EE security role settings page, specify how to configure the J2EE security roles for WSRR. Click Next.
  14. In the summary page review the settings that you made for this deployment. Click Previous to go back and change anything you are not happy with. Otherwise, click Finish. WSRR is deployed to your cluster. This takes a number of minutes, and the page does not change until the deploy has finished.
  15. Save the changes after deployment has completed.