Hi Ishara, We can define endpoints for each apis using the above properties. For example, If there are two APIs (APIX and APIY), we could override the endpoints as following
-e APIX.v1.prod.endpoint.0="http://wso2.com"; <http://wso2.com/> -e APIY.v1.prod.endpoint.0="http://wso2.com"; <http://wso2.com/> On Tue, Jul 17, 2018 at 5:56 AM, Ishara Cooray <[email protected]> wrote: > Hi Chamila, > > How is this dynamic endpoint feature supported for a micron gateway that > is set up for multiple apis through an environment label? > > > Thanks & Regards, > Ishara Cooray > Senior Software Engineer > Mobile : +9477 262 9512 > WSO2, Inc. | http://wso2.com/ > Lean . Enterprise . Middleware > > On Thu, Jun 28, 2018 at 12:40 PM, Malintha Amarasinghe <[email protected] > > wrote: > >> Hi Chamila, >> >> A small suggestion for the implementation: I think this will be >> relatively easier if we define a function to get a particular config from >> env variable name (input 1) or from the default value (input 2) (if env >> variable is not defined). Then we can use this function name straight in >> the codegen templates. I think the function can be defined in the ballerina >> lib sources in the gateway core so that can be reused easily. >> >> Thanks! >> >> On Thu, Jun 28, 2018 at 12:18 PM, Chamila Adhikarinayake < >> [email protected]> wrote: >> >>> Hi All, >>> >>> I'm implementing a dynamic backend endpoint feature which will provide >>> users the capability to define dedicated backends for the same API. >>> >>> >>> >>> >>> >>> This feature is a bit similar to what we have in API Manager where we >>> define endpoints with variables and resolve it during the runtime (say we >>> set backend endpoint as http://{uri.var.host}:{uri.var.port}/apis/weather >>> and resolve them using system variables, etc). >>> >>> Similarly, We plan to provide a method to override the backend endpoint >>> uri from the API. But this method doesn't depend on whether the URL is >>> defined with template structure (with {uri.var.host}, etc). >>> >>> For example, If there is an API with TestAPI and version 1.0, we could >>> define *TestAPI-1.0.prod.**ep* , *TestAPI-1.0.sand.ep* as environment >>> variables, value in the TOML format or as command-line parameters and >>> override the existing related endpoint during the startup time. If the >>> properties are not provided, then we use endpoint defined in the API as the >>> default endpoint. >>> >>> This way, a user can start the micro-gateway with the default backend >>> endpoint or he can override it during the startup time. This will give the >>> capability to call dedicated endpoints for each environment >>> >>> Chamila. >>> >>> -- >>> Regards, >>> Chamila Adhikarinayake >>> WSO2, Inc. >>> Mobile - +94712346437 >>> Email - [email protected] >>> Blog - http://helpfromadhi.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Malintha Amarasinghe >> *WSO2, Inc. - lean | enterprise | middleware* >> http://wso2.com/ >> >> Mobile : +94 712383306 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > -- Regards, Chamila Adhikarinayake WSO2, Inc. Mobile - +94712346437 Email - [email protected] Blog - http://helpfromadhi.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
