Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Akila Amarasinghe
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : +94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Sanjeewa Malalgoda
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.

On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : +94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : +94713068779

blog :http://sanjeewamalalgoda.blogspot.com/




_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Chamalee De Silva
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Shazni Nazeer
Making only host and port dynamic may not be sufficient. Some one may need to change the backend service context path for the same API. If the endpoint contains a version number and a user may need to use the same API with another version of the backend. For testing purposes someone may also need to switch between http and https for the backend testing.

Thus, wouldn't it be good to make the entire backend URL to be dynamic rather than having parts of it be dynamic?

On Thu, Dec 7, 2017 at 10:14 AM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Nuwan Dias
In reply to this post by Chamalee De Silva
The problem we're trying to solve with this feature is to provide a recommended/OOTB method for api developers to design an API that can be migrated across environments. The problem in the workarounds we have suggested to different users so far are (assuming we set endpoint properties via system variables or property files)

1) API Developers have no way to define the system variables or add entries into the property file on the Gateway.
2) Setting system properties or modifying property files would require the Gateway to be restarted every time a new property/endpoint has been added.

The objective of experimenting with local entries was to decouple the API definition from the endpoint properties in a back-ward compatible way so that users won't have to migrate between version 2.1 and 2.2 of the product. But thinking on this again we can probably use <endpoint> types or even template endpoints without causing a migration impact too.

On Thu, Dec 7, 2017 at 9:44 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : +94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Nuwan Dias
In reply to this post by Shazni Nazeer
Its not just the host and port that dynamic, any part of the url, or the whole url itself can be made dynamic.

On Thu, Dec 7, 2017 at 10:36 PM, Shazni Nazeer <[hidden email]> wrote:
Making only host and port dynamic may not be sufficient. Some one may need to change the backend service context path for the same API. If the endpoint contains a version number and a user may need to use the same API with another version of the backend. For testing purposes someone may also need to switch between http and https for the backend testing.

Thus, wouldn't it be good to make the entire backend URL to be dynamic rather than having parts of it be dynamic?

On Thu, Dec 7, 2017 at 10:14 AM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : +94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Shazni Nazeer
+1. That way the user has the flexibility to change the endpoint as s/he needs it.

On Thu, Dec 7, 2017 at 11:21 AM, Nuwan Dias <[hidden email]> wrote:
Its not just the host and port that dynamic, any part of the url, or the whole url itself can be made dynamic.

On Thu, Dec 7, 2017 at 10:36 PM, Shazni Nazeer <[hidden email]> wrote:
Making only host and port dynamic may not be sufficient. Some one may need to change the backend service context path for the same API. If the endpoint contains a version number and a user may need to use the same API with another version of the backend. For testing purposes someone may also need to switch between http and https for the backend testing.

Thus, wouldn't it be good to make the entire backend URL to be dynamic rather than having parts of it be dynamic?

On Thu, Dec 7, 2017 at 10:14 AM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Rajkumar Rajaratnam
We handle this in ESB by storing backend endpoints in the registry and use the registry path in the API. The environment specific "endpoints" are externalized in this way. Just wondering why the same concept won't work for APIM?

As per my understanding of the proposed solution above, we are going to deploy different local entries (with different endpoints) in each environments. How it's different from storing different endpoints in registry (through a .car file may be) from a development or operational angle?

Thanks.

On Thu, Dec 7, 2017 at 11:27 AM, Shazni Nazeer <[hidden email]> wrote:
+1. That way the user has the flexibility to change the endpoint as s/he needs it.

On Thu, Dec 7, 2017 at 11:21 AM, Nuwan Dias <[hidden email]> wrote:
Its not just the host and port that dynamic, any part of the url, or the whole url itself can be made dynamic.

On Thu, Dec 7, 2017 at 10:36 PM, Shazni Nazeer <[hidden email]> wrote:
Making only host and port dynamic may not be sufficient. Some one may need to change the backend service context path for the same API. If the endpoint contains a version number and a user may need to use the same API with another version of the backend. For testing purposes someone may also need to switch between http and https for the backend testing.

Thus, wouldn't it be good to make the entire backend URL to be dynamic rather than having parts of it be dynamic?

On Thu, Dec 7, 2017 at 10:14 AM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: +1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Nuwan Dias
The Gateway does not have access to the registry. Nor to any other shared database used by API Manager. That's why the registry option won't work.

On Thu, Dec 7, 2017 at 11:09 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
We handle this in ESB by storing backend endpoints in the registry and use the registry path in the API. The environment specific "endpoints" are externalized in this way. Just wondering why the same concept won't work for APIM?

As per my understanding of the proposed solution above, we are going to deploy different local entries (with different endpoints) in each environments. How it's different from storing different endpoints in registry (through a .car file may be) from a development or operational angle?

Thanks.

On Thu, Dec 7, 2017 at 11:27 AM, Shazni Nazeer <[hidden email]> wrote:
+1. That way the user has the flexibility to change the endpoint as s/he needs it.

On Thu, Dec 7, 2017 at 11:21 AM, Nuwan Dias <[hidden email]> wrote:
Its not just the host and port that dynamic, any part of the url, or the whole url itself can be made dynamic.

On Thu, Dec 7, 2017 at 10:36 PM, Shazni Nazeer <[hidden email]> wrote:
Making only host and port dynamic may not be sufficient. Some one may need to change the backend service context path for the same API. If the endpoint contains a version number and a user may need to use the same API with another version of the backend. For testing purposes someone may also need to switch between http and https for the backend testing.

Thus, wouldn't it be good to make the entire backend URL to be dynamic rather than having parts of it be dynamic?

On Thu, Dec 7, 2017 at 10:14 AM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : +94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Rajkumar Rajaratnam
Oh okay, that makes sense. But we contradict this when it comes to multi tenant deployment - Gateway should have access to registry. May be this is fixed or will be fixed in latest releases.

Also, just for my learning, shouldn't we deploy DBs at all in MZ?

On Thu, Dec 7, 2017 at 11:45 AM, Nuwan Dias <[hidden email]> wrote:
The Gateway does not have access to the registry. Nor to any other shared database used by API Manager. That's why the registry option won't work.

On Thu, Dec 7, 2017 at 11:09 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
We handle this in ESB by storing backend endpoints in the registry and use the registry path in the API. The environment specific "endpoints" are externalized in this way. Just wondering why the same concept won't work for APIM?

As per my understanding of the proposed solution above, we are going to deploy different local entries (with different endpoints) in each environments. How it's different from storing different endpoints in registry (through a .car file may be) from a development or operational angle?

Thanks.

On Thu, Dec 7, 2017 at 11:27 AM, Shazni Nazeer <[hidden email]> wrote:
+1. That way the user has the flexibility to change the endpoint as s/he needs it.

On Thu, Dec 7, 2017 at 11:21 AM, Nuwan Dias <[hidden email]> wrote:
Its not just the host and port that dynamic, any part of the url, or the whole url itself can be made dynamic.

On Thu, Dec 7, 2017 at 10:36 PM, Shazni Nazeer <[hidden email]> wrote:
Making only host and port dynamic may not be sufficient. Some one may need to change the backend service context path for the same API. If the endpoint contains a version number and a user may need to use the same API with another version of the backend. For testing purposes someone may also need to switch between http and https for the backend testing.

Thus, wouldn't it be good to make the entire backend URL to be dynamic rather than having parts of it be dynamic?

On Thu, Dec 7, 2017 at 10:14 AM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: +1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Rajkumar Rajaratnam


On Thu, Dec 7, 2017 at 12:31 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
Oh okay, that makes sense. But we contradict this when it comes to multi tenant deployment - Gateway should have access to registry. May be this is fixed or will be fixed in latest releases.

Also, just for my learning, shouldn't we deploy DBs at all in MZ?

​Sorry meant to ask in DMZ?​

On Thu, Dec 7, 2017 at 11:45 AM, Nuwan Dias <[hidden email]> wrote:
The Gateway does not have access to the registry. Nor to any other shared database used by API Manager. That's why the registry option won't work.

On Thu, Dec 7, 2017 at 11:09 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
We handle this in ESB by storing backend endpoints in the registry and use the registry path in the API. The environment specific "endpoints" are externalized in this way. Just wondering why the same concept won't work for APIM?

As per my understanding of the proposed solution above, we are going to deploy different local entries (with different endpoints) in each environments. How it's different from storing different endpoints in registry (through a .car file may be) from a development or operational angle?

Thanks.

On Thu, Dec 7, 2017 at 11:27 AM, Shazni Nazeer <[hidden email]> wrote:
+1. That way the user has the flexibility to change the endpoint as s/he needs it.

On Thu, Dec 7, 2017 at 11:21 AM, Nuwan Dias <[hidden email]> wrote:
Its not just the host and port that dynamic, any part of the url, or the whole url itself can be made dynamic.

On Thu, Dec 7, 2017 at 10:36 PM, Shazni Nazeer <[hidden email]> wrote:
Making only host and port dynamic may not be sufficient. Some one may need to change the backend service context path for the same API. If the endpoint contains a version number and a user may need to use the same API with another version of the backend. For testing purposes someone may also need to switch between http and https for the backend testing.

Thus, wouldn't it be good to make the entire backend URL to be dynamic rather than having parts of it be dynamic?

On Thu, Dec 7, 2017 at 10:14 AM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763



--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: +1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Nuwan Dias
Most API Management deployments are super-tenant only deployments which do not require Gateways having access to the Registry. The fact that registry access is required in multi-tenanted scenarios should not be used as an excuse to design a feature in such a way that it requires access to the registry from the Gateway IMO. Accessing the registry from the API runtime is also a costly operation in terms of performance, which is another major reason we should avoid it.

DBs aren't deployed in DMZs. Its unlikely anyone would deploy a database in a less secure zone.

On Fri, Dec 8, 2017 at 12:03 AM, Rajkumar Rajaratnam <[hidden email]> wrote:


On Thu, Dec 7, 2017 at 12:31 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
Oh okay, that makes sense. But we contradict this when it comes to multi tenant deployment - Gateway should have access to registry. May be this is fixed or will be fixed in latest releases.

Also, just for my learning, shouldn't we deploy DBs at all in MZ?

​Sorry meant to ask in DMZ?​

On Thu, Dec 7, 2017 at 11:45 AM, Nuwan Dias <[hidden email]> wrote:
The Gateway does not have access to the registry. Nor to any other shared database used by API Manager. That's why the registry option won't work.

On Thu, Dec 7, 2017 at 11:09 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
We handle this in ESB by storing backend endpoints in the registry and use the registry path in the API. The environment specific "endpoints" are externalized in this way. Just wondering why the same concept won't work for APIM?

As per my understanding of the proposed solution above, we are going to deploy different local entries (with different endpoints) in each environments. How it's different from storing different endpoints in registry (through a .car file may be) from a development or operational angle?

Thanks.

On Thu, Dec 7, 2017 at 11:27 AM, Shazni Nazeer <[hidden email]> wrote:
+1. That way the user has the flexibility to change the endpoint as s/he needs it.

On Thu, Dec 7, 2017 at 11:21 AM, Nuwan Dias <[hidden email]> wrote:
Its not just the host and port that dynamic, any part of the url, or the whole url itself can be made dynamic.

On Thu, Dec 7, 2017 at 10:36 PM, Shazni Nazeer <[hidden email]> wrote:
Making only host and port dynamic may not be sufficient. Some one may need to change the backend service context path for the same API. If the endpoint contains a version number and a user may need to use the same API with another version of the backend. For testing purposes someone may also need to switch between http and https for the backend testing.

Thus, wouldn't it be good to make the entire backend URL to be dynamic rather than having parts of it be dynamic?

On Thu, Dec 7, 2017 at 10:14 AM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763



--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : +94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Rajkumar Rajaratnam
Thanks for the explanation, agree with the points. 

On Thu, Dec 7, 2017 at 12:51 PM, Nuwan Dias <[hidden email]> wrote:
Most API Management deployments are super-tenant only deployments which do not require Gateways having access to the Registry. The fact that registry access is required in multi-tenanted scenarios should not be used as an excuse to design a feature in such a way that it requires access to the registry from the Gateway IMO. Accessing the registry from the API runtime is also a costly operation in terms of performance, which is another major reason we should avoid it.

DBs aren't deployed in DMZs. Its unlikely anyone would deploy a database in a less secure zone.

On Fri, Dec 8, 2017 at 12:03 AM, Rajkumar Rajaratnam <[hidden email]> wrote:


On Thu, Dec 7, 2017 at 12:31 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
Oh okay, that makes sense. But we contradict this when it comes to multi tenant deployment - Gateway should have access to registry. May be this is fixed or will be fixed in latest releases.

Also, just for my learning, shouldn't we deploy DBs at all in MZ?

​Sorry meant to ask in DMZ?​

On Thu, Dec 7, 2017 at 11:45 AM, Nuwan Dias <[hidden email]> wrote:
The Gateway does not have access to the registry. Nor to any other shared database used by API Manager. That's why the registry option won't work.

On Thu, Dec 7, 2017 at 11:09 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
We handle this in ESB by storing backend endpoints in the registry and use the registry path in the API. The environment specific "endpoints" are externalized in this way. Just wondering why the same concept won't work for APIM?

As per my understanding of the proposed solution above, we are going to deploy different local entries (with different endpoints) in each environments. How it's different from storing different endpoints in registry (through a .car file may be) from a development or operational angle?

Thanks.

On Thu, Dec 7, 2017 at 11:27 AM, Shazni Nazeer <[hidden email]> wrote:
+1. That way the user has the flexibility to change the endpoint as s/he needs it.

On Thu, Dec 7, 2017 at 11:21 AM, Nuwan Dias <[hidden email]> wrote:
Its not just the host and port that dynamic, any part of the url, or the whole url itself can be made dynamic.

On Thu, Dec 7, 2017 at 10:36 PM, Shazni Nazeer <[hidden email]> wrote:
Making only host and port dynamic may not be sufficient. Some one may need to change the backend service context path for the same API. If the endpoint contains a version number and a user may need to use the same API with another version of the backend. For testing purposes someone may also need to switch between http and https for the backend testing.

Thus, wouldn't it be good to make the entire backend URL to be dynamic rather than having parts of it be dynamic?

On Thu, Dec 7, 2017 at 10:14 AM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763



--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: +1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Chamin Dias
Hi Akila,

What happens when the format of the dynamic url is different from each other (when migrating APIs to different environment)? Are we going to address that scenario?

Thanks.

On Fri, Dec 8, 2017 at 12:43 AM, Rajkumar Rajaratnam <[hidden email]> wrote:
Thanks for the explanation, agree with the points. 

On Thu, Dec 7, 2017 at 12:51 PM, Nuwan Dias <[hidden email]> wrote:
Most API Management deployments are super-tenant only deployments which do not require Gateways having access to the Registry. The fact that registry access is required in multi-tenanted scenarios should not be used as an excuse to design a feature in such a way that it requires access to the registry from the Gateway IMO. Accessing the registry from the API runtime is also a costly operation in terms of performance, which is another major reason we should avoid it.

DBs aren't deployed in DMZs. Its unlikely anyone would deploy a database in a less secure zone.

On Fri, Dec 8, 2017 at 12:03 AM, Rajkumar Rajaratnam <[hidden email]> wrote:


On Thu, Dec 7, 2017 at 12:31 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
Oh okay, that makes sense. But we contradict this when it comes to multi tenant deployment - Gateway should have access to registry. May be this is fixed or will be fixed in latest releases.

Also, just for my learning, shouldn't we deploy DBs at all in MZ?

​Sorry meant to ask in DMZ?​

On Thu, Dec 7, 2017 at 11:45 AM, Nuwan Dias <[hidden email]> wrote:
The Gateway does not have access to the registry. Nor to any other shared database used by API Manager. That's why the registry option won't work.

On Thu, Dec 7, 2017 at 11:09 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
We handle this in ESB by storing backend endpoints in the registry and use the registry path in the API. The environment specific "endpoints" are externalized in this way. Just wondering why the same concept won't work for APIM?

As per my understanding of the proposed solution above, we are going to deploy different local entries (with different endpoints) in each environments. How it's different from storing different endpoints in registry (through a .car file may be) from a development or operational angle?

Thanks.

On Thu, Dec 7, 2017 at 11:27 AM, Shazni Nazeer <[hidden email]> wrote:
+1. That way the user has the flexibility to change the endpoint as s/he needs it.

On Thu, Dec 7, 2017 at 11:21 AM, Nuwan Dias <[hidden email]> wrote:
Its not just the host and port that dynamic, any part of the url, or the whole url itself can be made dynamic.

On Thu, Dec 7, 2017 at 10:36 PM, Shazni Nazeer <[hidden email]> wrote:
Making only host and port dynamic may not be sufficient. Some one may need to change the backend service context path for the same API. If the endpoint contains a version number and a user may need to use the same API with another version of the backend. For testing purposes someone may also need to switch between http and https for the backend testing.

Thus, wouldn't it be good to make the entire backend URL to be dynamic rather than having parts of it be dynamic?

On Thu, Dec 7, 2017 at 10:14 AM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763



--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : 0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Nuwan Dias


On Fri, Dec 8, 2017 at 9:58 AM, Chamin Dias <[hidden email]> wrote:
Hi Akila,

What happens when the format of the dynamic url is different from each other (when migrating APIs to different environment)? Are we going to address that scenario?

Can you given an example? Are you saying the same API uses two different endpoint formats in two different environments? 

Thanks.

On Fri, Dec 8, 2017 at 12:43 AM, Rajkumar Rajaratnam <[hidden email]> wrote:
Thanks for the explanation, agree with the points. 

On Thu, Dec 7, 2017 at 12:51 PM, Nuwan Dias <[hidden email]> wrote:
Most API Management deployments are super-tenant only deployments which do not require Gateways having access to the Registry. The fact that registry access is required in multi-tenanted scenarios should not be used as an excuse to design a feature in such a way that it requires access to the registry from the Gateway IMO. Accessing the registry from the API runtime is also a costly operation in terms of performance, which is another major reason we should avoid it.

DBs aren't deployed in DMZs. Its unlikely anyone would deploy a database in a less secure zone.

On Fri, Dec 8, 2017 at 12:03 AM, Rajkumar Rajaratnam <[hidden email]> wrote:


On Thu, Dec 7, 2017 at 12:31 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
Oh okay, that makes sense. But we contradict this when it comes to multi tenant deployment - Gateway should have access to registry. May be this is fixed or will be fixed in latest releases.

Also, just for my learning, shouldn't we deploy DBs at all in MZ?

​Sorry meant to ask in DMZ?​

On Thu, Dec 7, 2017 at 11:45 AM, Nuwan Dias <[hidden email]> wrote:
The Gateway does not have access to the registry. Nor to any other shared database used by API Manager. That's why the registry option won't work.

On Thu, Dec 7, 2017 at 11:09 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
We handle this in ESB by storing backend endpoints in the registry and use the registry path in the API. The environment specific "endpoints" are externalized in this way. Just wondering why the same concept won't work for APIM?

As per my understanding of the proposed solution above, we are going to deploy different local entries (with different endpoints) in each environments. How it's different from storing different endpoints in registry (through a .car file may be) from a development or operational angle?

Thanks.

On Thu, Dec 7, 2017 at 11:27 AM, Shazni Nazeer <[hidden email]> wrote:
+1. That way the user has the flexibility to change the endpoint as s/he needs it.

On Thu, Dec 7, 2017 at 11:21 AM, Nuwan Dias <[hidden email]> wrote:
Its not just the host and port that dynamic, any part of the url, or the whole url itself can be made dynamic.

On Thu, Dec 7, 2017 at 10:36 PM, Shazni Nazeer <[hidden email]> wrote:
Making only host and port dynamic may not be sufficient. Some one may need to change the backend service context path for the same API. If the endpoint contains a version number and a user may need to use the same API with another version of the backend. For testing purposes someone may also need to switch between http and https for the backend testing.

Thus, wouldn't it be good to make the entire backend URL to be dynamic rather than having parts of it be dynamic?

On Thu, Dec 7, 2017 at 10:14 AM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763



--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : 0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : +94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Akila Amarasinghe
Hi Chamalee/ Shazni/ Chamin,

Chamalee, the endpoint details are kept in local entries. Yes, the user will have to define local entries per API. So the user will be able to enter the endpoint they want without restarting the server.

Shazni, when designing the API, the user should be able to parameterize the whole endpoint. In my mail, it is mentioned only host and port in the sample code. But in the developing feature, the user will be able to parameterize the whole endpoint. 

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : +94702178247

On Fri, Dec 8, 2017 at 10:25 AM, Nuwan Dias <[hidden email]> wrote:


On Fri, Dec 8, 2017 at 9:58 AM, Chamin Dias <[hidden email]> wrote:
Hi Akila,

What happens when the format of the dynamic url is different from each other (when migrating APIs to different environment)? Are we going to address that scenario?

Can you given an example? Are you saying the same API uses two different endpoint formats in two different environments? 

Thanks.

On Fri, Dec 8, 2017 at 12:43 AM, Rajkumar Rajaratnam <[hidden email]> wrote:
Thanks for the explanation, agree with the points. 

On Thu, Dec 7, 2017 at 12:51 PM, Nuwan Dias <[hidden email]> wrote:
Most API Management deployments are super-tenant only deployments which do not require Gateways having access to the Registry. The fact that registry access is required in multi-tenanted scenarios should not be used as an excuse to design a feature in such a way that it requires access to the registry from the Gateway IMO. Accessing the registry from the API runtime is also a costly operation in terms of performance, which is another major reason we should avoid it.

DBs aren't deployed in DMZs. Its unlikely anyone would deploy a database in a less secure zone.

On Fri, Dec 8, 2017 at 12:03 AM, Rajkumar Rajaratnam <[hidden email]> wrote:


On Thu, Dec 7, 2017 at 12:31 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
Oh okay, that makes sense. But we contradict this when it comes to multi tenant deployment - Gateway should have access to registry. May be this is fixed or will be fixed in latest releases.

Also, just for my learning, shouldn't we deploy DBs at all in MZ?

​Sorry meant to ask in DMZ?​

On Thu, Dec 7, 2017 at 11:45 AM, Nuwan Dias <[hidden email]> wrote:
The Gateway does not have access to the registry. Nor to any other shared database used by API Manager. That's why the registry option won't work.

On Thu, Dec 7, 2017 at 11:09 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
We handle this in ESB by storing backend endpoints in the registry and use the registry path in the API. The environment specific "endpoints" are externalized in this way. Just wondering why the same concept won't work for APIM?

As per my understanding of the proposed solution above, we are going to deploy different local entries (with different endpoints) in each environments. How it's different from storing different endpoints in registry (through a .car file may be) from a development or operational angle?

Thanks.

On Thu, Dec 7, 2017 at 11:27 AM, Shazni Nazeer <[hidden email]> wrote:
+1. That way the user has the flexibility to change the endpoint as s/he needs it.

On Thu, Dec 7, 2017 at 11:21 AM, Nuwan Dias <[hidden email]> wrote:
Its not just the host and port that dynamic, any part of the url, or the whole url itself can be made dynamic.

On Thu, Dec 7, 2017 at 10:36 PM, Shazni Nazeer <[hidden email]> wrote:
Making only host and port dynamic may not be sufficient. Some one may need to change the backend service context path for the same API. If the endpoint contains a version number and a user may need to use the same API with another version of the backend. For testing purposes someone may also need to switch between http and https for the backend testing.

Thus, wouldn't it be good to make the entire backend URL to be dynamic rather than having parts of it be dynamic?

On Thu, Dec 7, 2017 at 10:14 AM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763



--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Rajkumar Rajaratnam
Associate Technical Lead
Mobile: <a href="tel:(312)%20539-6763" value="+13125396763" target="_blank">+1 312 539 6763

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Chamin Dias
Mobile : 0716097455


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [APIM] [C4] [2.1.0] APIs with Dynamic Endpoints to enable Continuous Integration and Delivery

Akila Amarasinghe
Hi Chamin,

As I know, a single API has only one endpoint which is defined at the API design phase. IMO that endpoint is API specific. Can you explain the scenario more?

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : +94702178247

On Fri, Dec 8, 2017 at 10:52 AM, Akila Amarasinghe <[hidden email]> wrote:
Hi Chamalee/ Shazni/ Chamin,

Chamalee, the endpoint details are kept in local entries. Yes, the user will have to define local entries per API. So the user will be able to enter the endpoint they want without restarting the server.

Shazni, when designing the API, the user should be able to parameterize the whole endpoint. In my mail, it is mentioned only host and port in the sample code. But in the developing feature, the user will be able to parameterize the whole endpoint. 

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Fri, Dec 8, 2017 at 10:25 AM, Nuwan Dias <[hidden email]> wrote:


On Fri, Dec 8, 2017 at 9:58 AM, Chamin Dias <[hidden email]> wrote:
Hi Akila,

What happens when the format of the dynamic url is different from each other (when migrating APIs to different environment)? Are we going to address that scenario?

Can you given an example? Are you saying the same API uses two different endpoint formats in two different environments? 

Thanks.

On Fri, Dec 8, 2017 at 12:43 AM, Rajkumar Rajaratnam <[hidden email]> wrote:
Thanks for the explanation, agree with the points. 

On Thu, Dec 7, 2017 at 12:51 PM, Nuwan Dias <[hidden email]> wrote:
Most API Management deployments are super-tenant only deployments which do not require Gateways having access to the Registry. The fact that registry access is required in multi-tenanted scenarios should not be used as an excuse to design a feature in such a way that it requires access to the registry from the Gateway IMO. Accessing the registry from the API runtime is also a costly operation in terms of performance, which is another major reason we should avoid it.

DBs aren't deployed in DMZs. Its unlikely anyone would deploy a database in a less secure zone.

On Fri, Dec 8, 2017 at 12:03 AM, Rajkumar Rajaratnam <[hidden email]> wrote:


On Thu, Dec 7, 2017 at 12:31 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
Oh okay, that makes sense. But we contradict this when it comes to multi tenant deployment - Gateway should have access to registry. May be this is fixed or will be fixed in latest releases.

Also, just for my learning, shouldn't we deploy DBs at all in MZ?

​Sorry meant to ask in DMZ?​

On Thu, Dec 7, 2017 at 11:45 AM, Nuwan Dias <[hidden email]> wrote:
The Gateway does not have access to the registry. Nor to any other shared database used by API Manager. That's why the registry option won't work.

On Thu, Dec 7, 2017 at 11:09 PM, Rajkumar Rajaratnam <[hidden email]> wrote:
We handle this in ESB by storing backend endpoints in the registry and use the registry path in the API. The environment specific "endpoints" are externalized in this way. Just wondering why the same concept won't work for APIM?

As per my understanding of the proposed solution above, we are going to deploy different local entries (with different endpoints) in each environments. How it's different from storing different endpoints in registry (through a .car file may be) from a development or operational angle?

Thanks.

On Thu, Dec 7, 2017 at 11:27 AM, Shazni Nazeer <[hidden email]> wrote:
+1. That way the user has the flexibility to change the endpoint as s/he needs it.

On Thu, Dec 7, 2017 at 11:21 AM, Nuwan Dias <[hidden email]> wrote:
Its not just the host and port that dynamic, any part of the url, or the whole url itself can be made dynamic.

On Thu, Dec 7, 2017 at 10:36 PM, Shazni Nazeer <[hidden email]> wrote:
Making only host and port dynamic may not be sufficient. Some one may need to change the backend service context path for the same API. If the endpoint contains a version number and a user may need to use the same API with another version of the backend. For testing purposes someone may also need to switch between http and https for the backend testing.

Thus, wouldn't it be good to make the entire backend URL to be dynamic rather than having parts of it be dynamic?

On Thu, Dec 7, 2017 at 10:14 AM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila,

With the recent previous versions, we can use even the property mediators inside the global sequence to get the host and port as below and can avoid adding a class mediator.

<property name="uri.var.host" expression="get-property('system','host')" />
<property name="uri.var.port" expression="get-property('system','port')" />

And then we can start the API Manager with sh wso2server.sh -Dhost=abc.com -Dport=7234



So as I understand, 
what you are trying to do is avoid providing  this host and port in the server startup and obtain them from the local-entries.

If so, you will require to add details per API in local-entries and, changing this entry files (with hot deployment) gives the dynamic endpoint for the API.

I think it is better to have the host/port details in local-entries since if we want to change the dynamic endpoint provided at the startup, we need to restart the server and with this feature we can change the API endpoint without server restarts.





Thanks,
Chamalee





On Thu, Dec 7, 2017 at 8:41 PM, Sanjeewa Malalgoda <[hidden email]> wrote:
I don't get what we achieve with new implementation here. Are we trying to resolve problem of having custom class mediators. If that is the case then it's not mandatory. We can simply have sequence and use java script to read system property. So we will need sequence only to map parameterized attributes.

Are we migrating local entries along with API data. Can you explain this little bit.


On Thursday, December 7, 2017, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

Here's the mail with images,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.


Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Thu, Dec 7, 2017 at 4:43 PM, Chamalee De Silva <[hidden email]> wrote:
Hi Akila, 
The images are missing.
Please reattach by coping them.



Thanks,
Chamalee





On Thu, Dec 7, 2017 at 4:40 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.




Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to invoke. But the API will never connect with the back end of his region(region-2) as the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Current solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed which is applied to the APIs with more than one gateway. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. Following picture depicts this situation.



Here is the current way of doing this,
  • The user has to define the endpoint at the API design phase in following format, <https://{uri.var.host}:{uri.var.port}/...>
  • Configure the custom class mediator and place the sequence in <APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences folder.
  • In the server start, user has to enter the host and port in the following format as System Properties, <environment.host> and <environment.port>
    • eg : ./wso2server.sh -Denvironment.host=<ip_of_backend_environment> -Denvironment.port=<port_of_backend_environment>
The above functionality is achieved by hooking the global sequence using a custom class mediator. In the code, the System Properties are set to the messageContext. Here is a sample code,

import org.apache.synapse.MessageContext;
import org.apache.synapse.mediators.AbstractMediator;

public class EnvironmentResolver extends AbstractMediator {

    @Override
    public boolean mediate(MessageContext messageContext) {

        String host = System.getProperty("environment.host");
        String port = System.getProperty("environment.port");

        messageContext.setProperty("uri.var.host", host);
        messageContext.setProperty("uri.var.port", port);

        return true;
    }

    @Override
    public boolean isContentAware(){
        return false;
    }
}

Disadvantages of above process :
  • An exported API cannot be used in a different environment with a different back end URL.
  • The parameters has to be entered in server start as System Properties using this format, <environment.host> and <environment.port>
Proposed solution :

The proposed solution is to obtain the dynamic parts of the endpoint via a custom handler instead of a class mediator enabling the user to add the parameterized parts via local entries.
In this way, the things the user has to do are,
  1. Define the parameterized endpoint in the design phase of the API.
  2. Add local entry files into the <APIM_HOME>/repository/deployment/server/synapse-configs/default/local-entries folder.
  3. Invoke the API.
The values of the parameters are set to enter via local entries. So there is no entering the values in server start.

Appreciate any feedback and suggestions.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:41 PM, Nuwan Dias <[hidden email]> wrote:
Hi Akila,

The subject of the mail is not descriptive enough for the feature we're trying to develop. What we're actually trying to achieve here is the ability for an API to be moved across environments without having to change the Endpoint URL. Basically Dynamic Endpoints to Enable CI/CD for APIs.

Thanks,
NuwanD.

On Wed, Dec 6, 2017 at 5:26 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all, 

Sorry for the mistake. This is not the complete mail. The complete mail will be sent.

Thanks,

Akila Aroshana
Software Engineer (Intern)
WSO2

Mobile : <a href="tel:+94%2070%20217%208247" value="+94702178247" target="_blank">+94702178247

On Wed, Dec 6, 2017 at 5:22 PM, Akila Amarasinghe <[hidden email]> wrote:
Hi all,

WSO2 API manager currently provides the facility for the user to input a single endpoint to the API when designing it. So every time the API makes requests, the request is directed to the back end defined by the endpoint URL provided. Even if the API has multiple gateways, all the gateways directs the requests to the same back end of the defined URL as the following figure depicts.



Problem :

Assume a situation like this,

Person A designs an API with the endpoint <https://backend-region-1:8280> and works with it. Person B, which is in another region, <https://backend-region-2:8280> with the same back end database needs that API for some purpose. He deploys the API exported by Person A in the gateway of his region and try to use. But the API will never connect with the back end of his region. But in this situation, the API doesn't get connected with the back end of region-2. As the endpoint which the Person A entered is for region-1 back end only.

If an already designed API needs to be connected with a back end(same one) with a different endpoint(region) other than the already defined endpoint in the API, the API won't be able to connect with it. Simply, a designed API cannot be deployed in a region with a different back end URL (not a different back end).
 
Solution :

The proposed solution is to enter a dynamic endpoint at the time the API is designed. This endpoint should only be resolved at the run time so the API so the gateway would point a dedicated back end. This also applies when an API has more than one gateway.












--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729




--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942




--

Sanjeewa Malalgoda
WSO2 Inc.
Mobile : <a href="tel:+94%2071%20306%208779" value="+94713068779" target="_blank">+94713068779

blog :http://sanjeewamalalgoda.blogspot.com/






--
Thanks & Regards,

Chamalee De Silva

Software Engineer
WSO2 Inc. :http://wso2.com/

Office   :- <a href="tel:%2B94%2011%202145345" value="+94112145345" style="color:rgb(17,85,204)" target="_blank">+94 11 2145345
mobile  :- <a href="tel:%2B94%2077%202782039" value="+94772782039" style="color:rgb(17,85,204)" target="_blank">+94 71 4315942


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729