This documentation is work in progress and will be released with the next WSO2 EI version.
Administration - Micro Integrator Profile - WSO2 Enterprise Integrator 6.x.x - WSO2 Documentation

All docs This doc
||
Skip to end of metadata
Go to start of metadata

The Micro Integrator profile of WSO2 Enterprise Integrator (WSO2 EI) is a container-friendly ESB to build your integrated enterprise. Before you start building your integration scenarios and running them on the Micro Integrator, you need to set up and configure the Micro Integrator according to your enterprise requirements. Once your system is up and running, you need to monitor its performance. See the following topics for more details.

Setting up the Micro Integrator

Listed below are the administration tasks that are required for settting up the Micro Integrator in our environment.

Upgrading from the previous Micro Integrator

If you are already using the Micro Integrator of WSO2 EI 6.3.0, you can migrate your system to WSO2 EI 6.4.0. Note that we always provide instructions on how to migrate from the immediately preceding version to this version.

Applying patches 

For information on updating WSO2 EI with the latest available patches (issued by WSO2) using the WSO2 Update Manager (WUM), see Getting Started with WUM in the WSO2 Administration Guide.

Clustering the Micro Integrator

.................

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.

Performance tunning

.................

Configuring users, roles, and permissions

......

Securing the Micro Integrator

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 ssLprotocol attribute is set to "TLS" by default. 
The following topics will guide you through the configuration options:

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. 

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:


Securing Passwords in Synapse Configurations

When you use the Micro Integrator or the ESB profile of WSO2 EI, it is also possible to encrypt passwords and other sensitive information in synapse configurations. See Encrypting Passwords in Synapse Configurations 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 the file-based registry

The H2 database-based registry is not available in the Micro Integrator profile. Instead, it has a file-system-based registry, which provides the same functionality. Thus, by default, the <EI_HOME>/wso2/micro-integrator/registry directory will act as the registry to store registry artifacts etc. This main registry directory will consist of the following sub registry directories.

  • Local: To store local artifacts of the product server that are not shared with the other products in the deployment.
  • Config: To store all product-specific artifacts that are shared between similar product instances.
  • Governance: To store all artifacts that re relevant to the governance of the product.

If you want to change the default locations of the Registry directories, uncomment and change the following configuration in the <EI_HOME>/wso2/microIntegrator/repository/deployment/server/synapse-config/default/directoryregistry.xml file.

<registry xmlns="http://ws.apache.org/ns/synapse" provider="org.wso2.carbon.mediation.registry.MicroIntegratorRegistry">
    <parameter name="cachableDuration">15000</parameter>
    <!--
        Uncomment below parameters (ConfigRegRoot, GovRegRoot, LocalRegRoot) to configure registry root paths
        Default : <EI_HOME>/wso2/micro-integrator/registry/{governance | config | local}
    -->
    <!--
    <parameter name="ConfigRegRoot">{Root directory path for configuration Registry}</parameter>
    <parameter name="GovRegRoot">{Root directory path for governance Registry}</parameter>
    <parameter name="LocalRegRoot">{Root directory path for local Registry}</parameter>
    -->
</registry>

Other administration tasks

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.

Monitoring the Micro Integrator

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.
  • No labels