Why do we consider it a new product? Well, because it’s tailored towards the trend of microservices, containerization and environments like Docker and Kubernetes. In other words, deployments that differs from a monolithic deployment like the WSO2 Enterprise Integrator 6.x.0 (and previous versions).
In this blog, we are going to look at the following aspects:
- Setting up the WSO2 Micro Integrator including analytics;
- Deploying two very simple proxies and an API to this environment;
- Invoking the proxies and API;
- Contrasting it to a regular deployment (that you would do on the WSO2 Enterprise Integrator).
We will deploy it to a regular virtual machine environment but also to the built-in WSO2 Micro Integrator that is part of Integration Studio. In a future blog, we’ll show how to deploy it to a Docker environment as well as well as MiniKube.
Installation
We will use the separate download for the WSO2 Micro Integrator rather than the WSO2 Enterprise Integrator (EI) 7.0.0. The reason is that we don’t need the Streaming Integrator that is bundled in WSO2 EI 7.0.0. Furthermore, we will not use the installer because it installs the product in a place where we don’t want it. We will simply download the binary (zip file) and work with that. We will also download the (analytics for) WSO2 Enterprise Integrator zip file, the WSO2 Micro Integrator command line tool, WSO2 Integration Studio 7.0.0 and the WSO2 Micro Integrator dashboard. This is a serious download since we’re downloading over 1.4 gigabyte of data. The reason why this is so big is that we’re downloading the WSO2 Enterprise Integrator (523 mb) because the analytics is part of their download and not available separately. WSO2 Integration Studio is another 772 megabytes. The WSO2 Micro Integrator itself together with the dashboard and the command line tool is only 200 megabytes.
I’ve put everything on the desktop and unzipped the files. This leaves me with a number of folders.
| Directory | Purpose |
| Integration Studio | Development environment |
| wso2mi-1.1.0 | WSO2 Micro Integrator |
| wso2mi-cli-1.1.0 | Command line interface |
| wso2mi-monitoring-dashboard-1.1.0 | Dashboard |
| wso2ei-6.6.0 | Analytics |
Configuration
In order to configure the WSO2 Micro Integrator, we need to make changes to the deployment.toml file. We will make a number of changes like:
- Connection to the analytics server;
- Exchange certificates between Micro integrator and the analytics component.
The WSO2 Micro Integrator uses the deployment.toml file as a central configuration file on top of the regular config files that are found in the conf directory. This mechanism is also found in the most recent versions of the WSO2 API Manager and the WSO2 Identity Server but not in the WSO2 Enterprise Integrator 6.6.0. The deployment.toml file will register the changes to the configuration and at startup these values will be written to the associated configuration files like carbon.xml, axis2.xml and others.
Open the deployment.toml file from [MI-HOME]/conf and add the following lines to enable analytics from the WSO2 Micro Integrator.
Starting WSO2 products
To try this out, we need to start the analytics server before we start the WSO2 Micro Integrator. This because of the fact that when we enable analytics we create a dependency on the analytics server. As soon as you start to micro integrator it will try to make a connection to the analytics server to prepare for data transmission.
We will now start the analytics server using the worker.sh command that can be found in the [EI-HOME]/wso2/analytics/bin directory. Furthermore, also start the dashboard of the Analytics Server as well. This is also done in the [EI-HOME]/wso2/analytics/bin directory using the sh dashboard.sh command. You will find the URL of the dashboard mentioned in the terminal, please right click and open the link. Login using admin / admin credentials.
The command to start the WSO2 Micro Integrator is sh micro-integrator.sh. However, we will wait until we have a car file that we can deploy before we start it.
Creating proxies
We will create two proxies and one API. Since we do not have a backend server or the echo service (that is available in WSO2 Enterprise Integrator 6.6.0) we will create a simple proxy that will get the system date and time and respond that back to the client. For the API we’ll call an online API service. We will not go into detail into the setup of the proxy or API.
The TellMe proxy simply retrieves the system date and time and creates a soap message that is given back to the client.<?xml version="1.0" encoding="UTF-8"?> <proxy name="TellMe" startOnLoad="true" transports="http https" xmlns="http://ws.apache.org/ns/synapse"> <target> <inSequence> <property expression="get-property("SYSTEM_DATE", "yyyy-MM-dd' Time 'HH:mm:ss.SSSXXX")" name="SYSTEM_DATE" scope="default" type="STRING"/> <log/> <payloadFactory media-type="xml"> <format> <time xmlns="">$1</time> </format> <args> <arg evaluator="xml" expression="$ctx:SYSTEM_DATE"/> </args> </payloadFactory> <respond/> </inSequence> <outSequence/> <faultSequence/> </target> </proxy>
For the API I am using the debounce.io API that is able to check if an email address seems legitimate. You need to sign in for this service and generate an API key to access it. The API itself is quite straightforward:
The API in the screenshot above is the key that you generate for use with debounce. The email address is the address you want to check.
https://api.debounce.io/v1/?api=XXXXXXXXXXXXX&email=jexip69755@p5mail.com. The XXX is a place holder for the API Key.
The response is something like this.{ "debounce": { "email": "jexip69755@p5mail.com", "code": "3", "role": "false", "free_email": "false", "result": "Invalid", "reason": "Disposable", "send_transactional": "0", "did_you_mean": "jexip69755@gmail.com" }, "success": "1", "balance": "99" }
The API is also simple:
<?xml version="1.0" encoding="UTF-8"?> <api context="/check" name="CheckEmail" xmlns="http://ws.apache.org/ns/synapse"> <resource methods="GET" uri-template="/{apikey}/{email}"> <inSequence> <log level="full"/> <send> <endpoint> <http method="get" statistics="enable" uri-template="https://api.debounce.io/v1/?api={uri.var.apikey}&email={uri.var.email}"> <suspendOnFailure> <initialDuration>-1</initialDuration><progressionFactor>-1</progressionFactor> <maximumDuration>0</maximumDuration> </suspendOnFailure> <markForSuspension><retriesBeforeSuspension>0</retriesBeforeSuspension> </markForSuspension> </http> </endpoint> </send> </inSequence> <outSequence> <send/> </outSequence> <faultSequence/> </resource> </api>
In this API we take the parameters from the API (apikey and email) and put them in the call to the debounce endpoint. We do need to keep in mind that an @ in a url will not work, so we substitute that for %40. The call looks like this in SoapUI.
We put the proxy and API in a Composite Application (C-App) and create a Car File that we’ll deploy to the Micro Integrator. Please download the Car file.
We will use the standalone WSO2 Micro Integrator. Car files are not hot deployable on the WSO2 Micro Integrator so we need to restart the product after putting the CAR in its deployment folder [MI_HOME/repository/deployment/server/carbonapps. When we do that we see the car files being picked up at startup. Now start the MI using the aforementioned command.
When we use the WSO2 Micro Integrator dashboard, we can see the proxy and api if the deployment was successful. The dashboard requires you to add security exception in the browser because of the self signed certificate. For example, direct the browser to https://localhost:9164/management and add the site if trusted. Otherwise you will not be able to login.
When we click on TellMe we see the source code, Endpoints and Proxy Details.
Now we need to invoke the Proxy and API a couple of times to see the Analytics in play. We will only show the Proxy invocations.
First of all, export the certificates from the KeyStore into the other client-truststore. Otherwise, there can’t be data transfer between the WSO2 Micro Integrator and Analytics. These commands will take care of that. Note that these are written for our specific training environment as far as the installation of the WSO2 products go.# Exporting Analytics certificate keytool - exportcert -alias wso2carbon -file /opt/wso2/Desktop/wso2analyticscert -keystore /opt/wso2/Desktop/wso2ei-6.6.0/wso2/analytics/resources/security/wso2carbon.jks -storepass wso2carbon # Exporting MI certificate keytool -exportcert -alias wso2carbon -file /opt/wso2/Desktop/wso2micert -keystore /opt/wso2/Desktop/wso2mi-1.1.0/repository/resources/security/wso2carbon.jks -storepass wso2carbon # Import MI certificate into Analytics truststore keytool -importcert -alias wso2analytics -file /opt/wso2/Desktop/wso2micert -keystore /opt/wso2/Desktop/wso2ei-6.6.0/wso2/analytics/resources/client-truststore.jks -trustcacerts -storepass wso2carbon -noprompt # Import Analytics certificate into MI truststore keytool -importcert -alias wso2mi -file /opt/wso2/Desktop/wso2analyticscert -keystore /opt/wso2/Desktop/wso2mi-1.1.0/repository/resources/security/client-truststore.jks -trustcacerts -storepass wso2carbon -noprompt
Invoke the proxy a number of times.
When logging in to the analytics server dashboard we can see the invocations.
Conclusion
As you can see, deployment of artifacts to the WSO2 Micro Integrator are partly similar to a regular WSO2 Enterprise Integrator and partly different. In a future blog we will deploy the same artifacts to a Docker environment, since that is also supported by Integration Studio.
Yenlo is the leading, global, multi-technology integration specialist in the field of API-management, Integration technology and Identity Management. Known for our strong focus on best-of-breed hybrid and cloud-based iPaaS technologies.
Yenlo is the product leader and multi-award winner in WSO2, Boomi, MuleSoft and Microsoft Azure technologies and offers best-of-breed solutions from multiple leading integration vendors.
