If you are a product administrator, the following topics provide an overview of the tasks that you need to perform when working with WSO2 ESB to deploy, monitor, tune, and maintain an ESB.
Upgrading from a previous release
If you want to upgrade data and configurations from ESB 4.9.0 to ESB 5.0.0, see Upgrading from a Previous Release
Clustering WSO2 ESB
For information on how to set up a WSO2 ESB worker/manager separated cluster and how to configure a cluster with a third-party load balancer, see Clustered Deployment.
Changing the default database
By default, WSO2 products are shipped with an embedded H2 database, which is used for storing user management and registry data. We recommend the use of an industry-standard RDBMS such as Oracle, PostgreSQL, MySQL, MS SQL, etc. when you set up your production environment.You can change the default database configuration by setting up a new physical database, and then updating the configurations in the production server to connect to the new database.
For information on setting up and configuring databases, see Working with Databases in the WSO2 Administration Guide.
Configuring users, roles and permissions
The user management feature in WSO2 ESB allows you to create new users as well as to define the permission granted to each user. You can also configure the user stores that are used for storing data related to user management.
For information on how to configure user management, see Managing Users, Roles and Permissions in the WSO2 Administration Guide.
After you install WSO2 ESB, it is recommended to change the default security settings according to your production environment.
For information on configuring security in your server, see the following topics in the WSO2 Administration Guide.
- Configuring Transport-Level Security
- Using Asymmetric Encryption
- Using Symmetric Encryption
- Enabling Java Security Manager
- Securing Passwords in Configuration Files
- Resolving Hostname Verification
If your proxy service connects to a back-end server through a proxy server, you can enable Secure Socket Layer (SSL) tunneling through the proxy server, which prevents any intermediary proxy services from interfering with the communication. For information on this, see Enabling SSL Tunneling through a Proxy Server.
You can create multiple tenants in your product server, so that you can maintain tenant isolation in a single server/cluster. For information on configuring multiple tenants for your server, 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 products, 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.
You can optimize the performance of WSO2 ESB by configuring the ESB based on a set of recommendations from WSO2 experts.
For information on network and OS level performance tuning, Java Virtual Machine (JVM) level tuning, and WSO2 Carbon platform-level performance tuning recommendations, see Performance Tuning in the WSO2 Administration Guide.
For information on performance tuning recommendations that are specific to WSO2 ESB, see the WSO2 ESB Performance Tuning Guide.
Changing the default ports
When you run multiple WSO2 products, multiple instances of the same product, or multiple WSO2 product clusters on the same server or virtual machines (VMs), you must change their default ports with an offset value to avoid port conflicts.
For instructions on configuring posts, see Changing the Default Ports in the WSO2 Administration Guide.
Installing, uninstalling and managing product features
Each WSO2 product is a collection of reusable software units called features where a single feature is a list of components and/or other feature. By default, WSO2 ESB is shipped with the features that are required for your main use cases.
For information on installing new features, or removing/updating an existing feature, see Working with Features 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 your product.
For instructions, see Customizing Error Pages in the WSO2 Administration Guide.
Customizing the management console
Some of the WSO2 products, such as WSO2 ESB consist of a web user interface, which is known as the management console. This allows administrators to configure, monitor, tune, and maintain the product using a simple interface. You can customize the look and feel of the management console for your product.
For instructions, see Customizing the Management Console in the WSO2 Administration Guide.
Working with proxy servers
When using WSO2 ESB, there can be scenarios where you need to configure the ESB to route messages through a proxy server.
For information on how to work with proxy servers, see Working with Proxy Servers.
Using the Cloud Services Gateway(CSG)
When using the WSO2 ESB, there can be scenarios where you need to expose a private service to the public through a cooperate firewall. You can use the Cloud Services Gateway (CSG) component of the ESB for this purpose.
For information on how to work with the Cloud Services Gateway (CSG) component of the ESB , see Cloud Services Gateway (CSG).
Monitoring the server
WSO2 ESB provides a variety of options to monitor and manage the server runtime through a number of monitoring tools as well as via Java Management Extensions (JMX) monitoring. Results provided by these convenient yet powerful ESB monitoring mechanisms can be used to tune message flows, detect mediation faults, and track usage patterns.
The following topics describe how to monitor the ESB:
- 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: WSO2 ESB is shipped with JVM Metrics, which allows you to monitor statistics of your server 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.
- SNMP monitoring: Simple Network Management Protocol (SNMP) is an Internet-standard protocol for managing devices on IP networks. For information on how to configure SNMP in WSO2 ESB, see SNMP 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. For more information, see Viewing the Handlers in Message Flows.
For information on applying patches (issued by WSO2), see WSO2 Patch Application Process in the WSO2 Administration Guide.
Working with Composite Applications (C-Apps) and artifacts
For information on working with Composite Applications, see Working with Composite Applications in the WSO2 Administration Guide.