Product Administration

Note that WSO2 EI is shipped with a few changes to the general directory structure of WSO2 products. For information on these folder structure changes, go to Directory Structure of WSO2 Products in the WSO2 Administration Guide.

WSO2 Enterprise Integrator (WSO2 EI) consists of three main profiles: ESB profile, Business Process profile, and the Message Broker profile. See the introduction for more information. These profiles are separate runtimes that need to be configured and managed separately. If you are a product administrator, the following topics will provide an overview of the various administration tasks that are common to all profiles of WSO2 EI. Follow the links provided under each section for detailed instructions on each topic.

Upgrading from a previous release

WSO2 Enterprise Integrator is a comprehensive integration solution that includes the functionality that was previously encapsulated in WSO2 ESB, WSO2 DSS, WSO2 MB and WSO2 BPS. Therefore, you can upgrade to WSO2 EI 6.4.0 from each of those products.

See Upgrading from WSO2 Enterprise Service Bus for instructions on upgrading to WSO2 EI 6.4.0 from WSO2 ESB.
See Upgrading from WSO2 Business Process Server for instructions on upgrading to WSO2 EI 6.4.0 from WSO2 BPS.
See Upgrading from WSO2 Data Services Server for instructions on upgrading to WSO2 EI 6.4.0 from WSO2 DSS.
See Upgrading from WSO2 Message Broker for instructions on upgrading to WSO2 EI 6.4.0 from WSO2 MB.
See Upgrading from WSO2 EI 6.3.0 for instructions on upgrading to WSO2 EI 6.4.0 from the previous WSO2 EI version.

Clustering

When you cluster WSO2 EI, the three separate profiles (runtimes) included in WSO2 EI should be separately clustered according to your requirement. See the following topics for instructions on clustering each profile in WSO2 EI:

Production deployment guidelines

Changing the default databases

Each of the profiles in WSO2 EI contains an embedded H2 database (Carbon database), which is used for storing user management and registry data for that profile. Note that the Message Broker profile in WSO2 EI contains a default broker-specific database in addition to the Carbon database.

You can change the default database configurations in each of the EI profiles by setting up new physical databases, and updating the relevant configurations in each profile. We recommend the use of an industry-standard RDBMS such as Oracle, PostgreSQL, MySQL, MS SQL, etc. when you set up your production environment.

For information on setting up a new database for your profile, see Setting up the Physical Database in the WSO2 Administration Guide.

Add the database drivers to the <EI_HOME>/lib/ directory when setting up the database.
Once you set up a new database, you need to update the configurations in each profile of WSO2 EI. See Changing the Carbon Database for instructions.
If you are using the Message Broker profile, you can change the default broker-specific database in addition to the Carbon database. See Changing the Default Broker Database for instructions.
If you are using the Business Process profile, you can change the default BPEL/BPMN databases in addition to the Carbon database. See Changing the Default Databases for BPMN and BPEL for instructions.

Configuring users, roles and permissions

See the following topics in the WSO2 Administration Guide for instructions on configuring users, roles and defining permissions for each user.

Configuring the System Administrator	The admin user is the super tenant that will be able to manage all other users, roles and permissions in the system by using the management console of the product. Therefore, the user that should have admin permissions is required to be stored in the primary user store when you start the system for the first time. The documentation on setting up primary user stores will explain how to configure the administrator while configuring the user store. The information under this topic will explain the main configurations that are relevant to setting up the system administrator.
Configuring the Authorization Manager	According to the default configuration in WSO2 products, the users, roles and permissions are stored in the same repository (i.e., the default, embedded H2 database). However, you can change this configuration in such a way that the users and roles are stored in one repository (user store) and the permissions are stored in a separate repository. A user store can be a typical RDBMS, an LDAP or an external Active Directory. The repository that stores permissions should always be an RDBMS. The Authorization Manager configuration in the user-mgt.xml file connects the system to this RDBMS. The information under this topic will instruct you through setting up and configuring the Authorization Manager.
Configuring User Stores	The user management feature allows you to maintain multiple user stores for storing users and their roles. See the following topics for instructions: Configuring the Primary User Store Configuring a JDBC User Store Configuring a Read-Only LDAP User Store Configuring a Read-Write Active Directory User Store Configuring a Read-Write LDAP User Store Configuring Secondary User Stores Working with Properties of User Stores Writing a Custom User Store Manager
Managing Users, Roles and Permissions	Create new users, roles and assign permissions using the management console.

Configuring security

It is recommended to change the default security settings in each profile of WSO2 EI according to the requirements of your production environment. As all profiles in WSO2 EI are WSO2 servers built on top of the WSO2 Carbon Kernel, the main security configurations are inherited from the Carbon kernel. For instructions on configuring these main security settings, see the following topics in the WSO2 Product Administration Guide:

Configuring Transport-Level Security	The transport level security protocol of the Tomcat server is configured in the `catalina-server.xml` file. Note that the ss`Lprotocol` attribute is set to "TLS" by default. The following topics will guide you through the configuration options: Disabling SSL Disabling weak ciphers Configuring the PassThrough transport
Using Asymmetric Encryption	WSO2 servers use asymmetric encryption by default for the purposes of authentication and data encryption. In asymmetric encryption, keystores (with key pairs and certificates) are created and stored for the product. It is possible to have multiple keystores so that the keys used for different use cases are kept unique. The following topics explain more details on keystores. Understanding keystores Setting up keystores for WSO2 products Default keystore settings in WSO2 products Managing keystores
Using Symmetric Encryption	You also have the option of switching to symmetric encryption for the EI profile. Using symmetric encryption means that a single key will be shared for encryption and decryption of information.
Enabling Java Security Manager	The Java Security Manager is used to define various security policies that prevent untrusted code from manipulating your system. Enabling the Java Security Manager for WSO2 products activates the Java permissions that are in the `sec.policy` file. You modify this file to change the Java security permissions as required.
Securing Passwords in Configuration Files	All WSO2 servers contain some configuration files with sensitive information such as passwords. Let's take a look at how such plain text passwords in configuration files can be secured using the Secure Vault implementation that is built into each server. The following topics will be covered under this section: Encrypting Passwords with Cipher Tool Resolving Encrypted Passwords Carbon Secure Vault Implementation When you use the ESB or Micro Integrator profiles of WSO2 EI, it is also possible to encrypt passwords and other sensitive information in synapse configurations. See Working with Passwords in the Integration Profile for instructions.
Resolving Hostname Verification	Hostname verification is enabled in WSO2 servers by default, which means that when a hostname is being accessed by a particular client, it will be verified against the hostname specified in the product's SSL certificate.

Configuring multitenancy

You can create multiple tenants in your EI profile so that you can maintain tenant isolation in a single server/cluster. For information on configuring multiple tenants for the profile, see Working with Multiple Tenants in the WSO2 Administration Guide.

Configuring the registry

A registry is a content store and a metadata repository for various artifacts such as services, WSDLs and configuration files. In WSO2 servers, all configurations pertaining to modules, logging, security, data sources and other service groups are stored in the registry by default. For information on setting up and configuring the registry for your server, see Working with the Registry in the WSO2 Administration Guide.

The local registry acts as a memory registry where you can store static content as a key-value pair, where the value could be a static entry such as a text string, XML code, or a URL. For information on local registry entries, see Working with Local Registry Entries.

Performance tuning

You can optimize the performance of the different profiles in WSO2 EI by using the most appropriate configurations. See Performance Tuning for instructions.

Changing the default ports

When you run multiple instances of the same profile or multiple clusters on the same server or virtual machines (VMs), you must change the default ports with an offset value to avoid port conflicts.

The ports used by all the profiles of WSO2 EI are listed here, along with the complete list of ports in all WSO2 products.
For instructions on configuring ports, see Changing the Default Ports in the WSO2 Administration Guide.

Configuring custom proxy paths

This feature is particularly useful when multiple WSO2 products (fronted by a proxy server) are hosted under the same domain name. By adding a custom proxy path you can host all products under a single domain and assign proxy paths for each product separately.

For instructions on configuring custom proxy paths, see Adding a Custom Proxy Path in the WSO2 Administration Guide.

Customizing error pages

You can make sure that sensitive information about the server is not revealed in error messages, by customizing the error pages in the servers.

For instructions, see Customizing Error Pages in the WSO2 Administration Guide.

Customizing the management console

All the profiles in WSO2 EI come with separate management consoles that can be used for configuring, monitoring, tuning, and maintaining the profiles. You can customize the look and feel of the management console for each profile.

See Customizing the Management Console for instructions on customizing the look and feel of the management console.

Monitoring

The following topics describe how to monitor the separate runtimes (profiles) in WSO2 EI:

Monitoring logs	A properly configured logging system is vital for identifying errors, security threats and usage patterns in your product server. For instructions on monitoring the server logs, see Monitoring Logs in the WSO2 Administration Guide.
Monitoring HTTP Access Logs	HTTP Requests/Responses are logged in the access log(s) and are helpful to monitor your application's usage activities, such as the persons who access it, how many hits it receives, what the errors are etc. For more information on access logs, go to HTTP Access Logging in the WSO2 Administration Guide.
Monitoring using WSO2 metrics	JVM Metrics allow you to monitor statistics of all the profiles of WSO2 EI using Java Metrics. For instructions on setting up and using Carbon metrics for monitoring, see Using WSO2 Metrics in the WSO2 Administration Guide.
JMX-based monitoring	For information on monitoring your server using JMX, see JMX-based monitoring in the WSO2 Administration Guide. For information on the various MBeans available for monitoring, see JMX Monitoring.
Monitoring TCP-based messages	You can view and monitor the messages passed along a TCP-based conversation using the TCPMon. For information on setting up and using TCPMon in your server, see Monitoring TCP-Based Messages in WSO2 Administration Guide.
Viewing handlers in message flows	Message flows provide graphical and textual views of the globally engaged handlers of the system at any point of time. The modules use the handlers to engage in different message flows at defined phases. You can observe the handlers invoked in each phase of each flow in real time.

Applying patches

For information on updating WSO2 EI with the latest available patches (issued by WSO2) using the WSO2 Update Manager (WUM), see /wiki/spaces/updates/pages/16318501.

Working with profile-specific administration tasks

See the following topics for information on administration tasks that are specific to WSO2 EI: