Governing External References Across Environments

Some artifacts must change based on the environment where the application is deployed. For example, when you deploy an ESB application to Dev, QA, and Production environments, the service endpoints are different in each of those environments, so you must update the proxy services accordingly with the relevant endpoint values.

This section provides information on how to manage and deploy artifacts across multiple environments. It focuses specifically on the management of endpoints in multiple environments. The endpoints are the environment dependent artifacts and are used as external references from within the proxy service (environment independent artifact) configuration. By doing this, the proxy service configuration does not need to be edited each time it is deployed in a different environment.

Understanding the Users

Users interacting with artifacts in each environment often have different roles and have access to different resources and tools. For example:

Developer: uses ESB Tooling to create services and Composite Applications (CApps) and push project artifacts to a source code repository, such as GitHub. Typically, the developer has no access to QA or Production resources.
DevOps or Operations team member: uses scripts and the WSO2 Management Console to pull the applications created by the developers from the source code repository and deploy them to the QA and Production environments. These users need to update the endpoints before they deploy in the different environments. Typically, they do not have ESB Tooling.

Best Practices for Migration

The following are the best practices that allow you to easily migrate applications across environments:

We recommend you create one Composite Application (CApp) for each deployment environment, namely HelloWorldDevResources and HelloWorldQAResources. This allows you to deploy and manage them separately. Additionally, you need to define a Composite Application for the application itself, i.e., the proxy service.
Whenever you create a proxy service use the endpoint as a reference name rather than defining it inline within the proxy service. This approach ensures that the proxy service can be deployed from one environment to another without having to do any environment specific configuration changes.
Ensure to use the same name for the endpoint across all environments.
Ensure the endpoint values are present and accurate in all environments prior to deploying an application using those endpoints. You can either manually edit the endpoint values prior to deploying the application, or make this an automatic part of your deployment process.

Maven Users

Maven can be used to build and deploy your artifacts across environments. When using Maven, you are also able to define the endpoints as variables and pass the URL value at the time of building the project.

Details on how you can assign endpoint values at the time of building is available at http://susinda.blogspot.ae/2017/01/wso2-esb-how-to-assign-endpoints-at.html.

In ESB Tooling, a Maven Multi Module(MMM) project is used to contain all the project information. For more information on Maven Multi Module projects, see http://www.sonatype.com/books/mvnex-book/reference/multimodule.html.

Sample Scenario

Let's take a look at the sample scenario:

A simple HelloWorld service that is shipped with WSO2 Application Server (WSO2 AS) is deployed in WSO2 AS, in both the Dev and QA environments.

This HelloWorld service is proxied through the ESB.
The Dev and QA endpoint values are stored as endpoints in the ESB and referenced to from the proxy service configuration.

WSO2 ESB Tooling is used to create the Composite Application projects containing WSO2 ESB artifacts (proxy service and endpoint definition) that are deployed in the ESB server.

Samples

The following samples are described in their respective sections:

Use a Pass-through Proxy Service in ESB to expose services hosted on WSO2 AS. Services as well as proxy services are deployed across Dev and QA environments. The endpoint value keeps changing for these environments and the endpoint values in WSO2 ESB need to change accordingly.
Use a Secure Proxy Service to Expose Services hosted on WSO2 AS. The endpoint values and the policies are stored in the registry and referenced by the proxy service.

Starting the Servers

Before you begin,

Go to http://wso2.com/products/enterprise-service-bus/, click DOWNLOAD to download the WSO2 ESB runtime ZIP file, and then extract the ZIP file.
The path to this folder will be referred to as <ESB_HOME>.
Go to http://wso2.com/products/enterprise-service-bus/ , click Tooling to select and download the relevant ESB tooling ZIP file, and then extract the ZIP file.
The path to this folder will be referred to as <TOOLING_HOME>.
Go to http://wso2.com/products/application-server/, click DOWNLOAD to download the WSO2 AS ZIP file, and then extract the ZIP file.
The path to this folder will be referred to as <AS_HOME>.

WSO2 ESB

Change the WSO2 ESB server instance for QA environment with the relevant port offsets as described in the table below:

(The default ports can be used for WSO2 ESB Dev environment)

Server	Port Offset
WSO2 ESB (Dev instance)	0
WSO2 ESB (QA instance)	1

You can change the port offset by editing the following property in <ESB_HOME>/repository/conf/carbon.xml file:

<Offset>1</Offset>

WSO2 AS

The HelloWorld service that is shipped in WSO2 AS needs to be build and deployed to the server. To do this,

In a command line terminal, navigate to <AS_HOME>/samples/HelloWorld and run the following command:
```
mvn clean install
```
You need to have maven installed to run the above command. For details, see Installation Prerequisites.
This will build and create the deployable HelloWord.aar file in <AS_HOME>/samples/HelloWorld/target directory.
Start the WSO2 AS instances for Dev and QA environments with the relevant port offsets as described in the table below:
Server Port Offset
WSO2 AS (Dev instance) 9
WSO2 AS (QA instance) 10
Start your WSO2 AS instance.
Open the management console in your WSO2 AS Dev instance and go to Services -> Add -> AAR Service. Click on Choose File and select the HelloWorld.aar file you created in Step 1 above and click Upload. Do the same for your WSO2 AS QA instance. The HelloWorld service is now hosted in your WSO2 AS instances and can be viewed by navigating to Services -> List.

Your server instances for Dev and QA environments are now ready and you can build and deploy the artifacts in them.