WSO2 Integration Cloud
Try WSO2 Cloud for Free
Sign in

All docs This doc
Expand all   Collapse all
Skip to end of metadata
Go to start of metadata

Here are the concepts and terminology you need to know to follow the tutorials.

Applications

You can deploy WSO2 ESB apps, WSO2 Data Services, Microservices, Jaggery apps, Java Web apps, and multiple other types of applications and services in WSO2 Integration Cloud.

For information about how to develop each application type and prepare them to be deployed in the Cloud, see App Development.

Runtimes

WSO2 Integration Cloud allows you to deploy multiple services in several different runtimes . If the runtime that you need is currently not available, you can request it from the WSO2 Cloud team. Go to the Integration Cloud and click the Support link at the top.

Cloud users

Users who register to WSO2 Cloud are automatically assigned to the tenant admin role of the organization that s/he creates. Tenant admins can invite other users to the Integration  CloudUsers role or the admin role in the Cloud. Both the IntegrationCloudUsers and the admin roles have privileges to access all functions of the Cloud.

Architecture

The WSO2 Integration Cloud is developed according to a container-based architecture. 

 Click to read more...

The following diagram illustrates the Integration Cloud's architecture:

  • Integration Cloud SaaS Application: Provides a web UI and a REST API for users to deploy their applications. The web UI is developed using Jaggery. It invokes the REST API, which in turn invokes the following backend components:
    • K8S Client (Kubernetes Client): Provides an interface to deploy applications in the Kubernetes cluster.

    • Docker Client:  Provides an interface to build images and push to the docker registry.

    • DAO:  Provides an interface to manipulate database operations to store metadata required for the Integration Cloud in the Integration   Cloud DB.

    • SOAP Client:  Invokes the WSO2 Storage Server's admin services to create databases and users.  

  • WSO2 Application Server:  Provides the hosting environment where the Integration Cloud SaaS application is deployed.
  • WSO2 Identity Server:  Provides identity management and SSO for the Integration Cloud SaaS application.
  • WSO2 Storage Server:  Provides RSS instances for users to store application data.
  • WSO2 Data Analytics Server:  Collects statistics published by the deployed applications and provides dashboards to users.  
  • Docker Registry:  Stores application images that are created using the deployable artifacts and runtimes.
  • Kubernetes:  Provides a runtime to deploy applications. Kubernetes namespaces provide tenant isolation. Applications are deployed per pod, per container. 
  • HAProxy: Allows users to access the applications deployed in the Integration Cloud.

Back to Top ^

Environment variables

You can use environment variables to change an application's internal configuration without changing its source code. It is recommended to use environment variables to set the values of dynamic properties  such as database connections details (e.g., database URL, username, and password), Log4j properties, system properties etc. 

For more infromation on environment variables, see Use environment variables.

Transports

WSO2 Integration Cloud has backend support for most of the common WSO2 ESB transports, including the Virtual File System (VFS) transport and MailTo transport. 

 Click to read more...

T he MailTo transport's  <transportSender>  properties have values set by default in the Cloud. If you want to change these default values, you can do so via the following environment variable names in the Cloud:

  • MAIL_SMTP_HOST
  • MAIL_SMTP_PORT
  • MAIL_SMTP_STARTTLS_ENABLE
  • MAIL_SMTP_AUTH
  • MAIL_SMTP_USER
  • MAIL_SMTP_PASSWORD
  • MAIL_SMTP_FROM

File InBound endpoints

An Inbound endpoint is a message entry point (source). Its behavior can be either polling or listening. It improves multi-tenancy and dynamic message source creation. The Integration Cloud has support for HTTP/S, and file Inbound endpoint types. For JMS, RabbitMQ, MQTT, Kafka, and custom Inbound endpoints, we recommend that you use custom Docker Images.  

For more information, see Working with Inbound Endpoints.

Tags

You can add tags to an application as a key/value pair. Using tags, you can define metadata about the application such as the application creator, creation date, version etc. 

 Click to read more...

Tags  do not affect the application's runtime. Also, you can search for applications using tags.

For example, if you add a tag as shown below,

adding a tag

you can

  • type "tag:" in the search area to retrieve all applications that have tags in them.
  • type "tag:creator" to retrieve all applications that have tags by the key name "creator".
  • type "tag:creator:Developer1" to retrieve all applications created by the user role named Developer1.

Application privacy

By default, an application you create in WSO2 Integration Cloud is public and accessible via the Internet. In  order to secure and limit access to your application, you can mark it private by opening the application and clicking its Settings menu.

For more information, see Change the application's privacy.

Container specifications

This defines the hardware specifications of the server in which you want your application to be deployed. The Integration Cloud provides pre-defined specifications with increasing amount of memory and CPU power.

When you select a specification for your runtime, it is recommended to select one that is above the requirements of your application to ensure that your application runs smoothly. You can also set runtime specifications for your application using the JAVA_OPTS environment variable, but that cannot override the container specification.

  • No labels