On Mon, Aug 15, 2016 at 5:16 PM, Sanjeewa Malalgoda <[email protected]> wrote:
> > > On Mon, Aug 15, 2016 at 5:15 PM, Sanjeewa Malalgoda <[email protected]> > wrote: > >> >> >> On Mon, Aug 15, 2016 at 4:30 PM, Harsha Kumara <[email protected]> wrote: >> >>> Hi All, >>> >>> The purpose of this feature is to enable the flexibility to manage own >>> endpoint configuration per API Manager deployment environment. >>> >>> *Problem* >>> >>> Typical API manager deployment contains multiple deployment environments >>> such as Development, QA, Pre-Production and Production. Hence some >>> deployments have unique API back-ends dedicated per each deployment >>> environment with unique endpoint configurations such as suspended error >>> codes, suspended duration and etc. So that APIs in Development environment >>> have back-end endpoint configuration unique to its environment which is >>> differ from the QA environment. So it's required to have a way to manage >>> endpoints per environment. >>> >>> *Existing Alternatives* >>> >>> Currently we are achieving this through parameterize API endpoints. As >>> discussed in[1], endpoint address is defined in parametirze way like http:// >>> {uri.var.host}/service1/backend. During run time, the parametrize >>> values will be replaced by the system inputs provide during the server >>> start up which is unique per environment. For example parameterize endpoint >>> address http://{uri.var.host}/service1/backend will be resolve to >>> http://dev.apim.org/service1/backend in Development environment and >>> will resolve to http://qa.apim.org/service1/backend in QA environment. >>> But endpoint can have advanced configurations suce as endpoint time outs, >>> suspended duration, suspended error codes and etc unique to each >>> environment. This alternative doesn't allow to keep a unique endpoint >>> configuration per environment. >>> >>> *Proposed Solution* >>> >>> The proposed solution contains a separate UI to define the API >>> endpoints. Users may defined API endpoints unique to the environment. When >>> creating a API, users either go with current way of defining a endpoint or >>> select a existing API Endpoint from the defined endpoints in the system. If >>> user select defined endpoint as API backend, then that endpoint name take >>> as a reference. When API is deploying to the gateway, endpoint >>> configuration for specified name will be fetched from the registry or >>> database and API artifact will generate with the configurations of >>> specified endpoint. >>> >>> APIs will be moved from one environment to other through the API Import >>> and Export APIs available in the API Manager. When API is exporting , API >>> Endpoint configuration will also included in exported archive. >>> >>> During API import, it will be initially go through all available >>> endpoints in the API imported environment to find whether specified API >>> Endpoint name is available in the system. If so import API will use >>> existing API Endpoint configuration to generate the API synapse artifact. >>> With this it will pick the endpoint definition unique to the environment. >>> If user specify import API with update action then it will use API endpoint >>> configuration comes with the exported API archive to update the API >>> endpoint available in API imported environment and generate the synapse >>> artifact. If specified API Endpoint configuration is not existed in the >>> environment, then API Import and Export tool will be use API endpoint >>> configuration comes with Exported API archive to generate the API synapse >>> artifact. >>> >>> Please share your thoughts and suggestions on the proposed approach. >>> >> Also we need to consider is type of these endpoint. We can have registry > endpoints and address endpoint(which resolve environment specific way while > deploying or invoking) both. > And other question is who can define these endpoints? Who can use them? We > need to come up with complete user story for this. > If some admin users define these endpoin(through admin dashboard)t and let > creator/publishers to use them then how we need to control endpoint sharing > etc. > Sometimes users do not need to expose all available endpoints to > everyone(API creator publisher). WDYT? > I'm currently looking at the possibility of using existing endpoint types in registry. Since we have several properties such as endpoint username, password, authentication type and etc we might need to have our own endpoint rxt configuration. As gateways not have access to the registry, we will need to generate the API synapse artifact with our endpoint configuration. We can use a role base model to control the visibility of defined endpoints. > Thanks, > sanjeewa. > >> [1] - http://wso2.com/library/articles/2016/03/article-architect >>> ing-a-multi-environment-api-manager-deployment-with-wso2-api-manager/ >>> >>> Thanks, >>> Harsha >>> >>> >>> >>> >>> >>> -- >>> Harsha Kumara >>> Software Engineer, WSO2 Inc. >>> Mobile: +94775505618 >>> Blog:harshcreationz.blogspot.com >>> >> >> >> >> -- >> >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/ >> <http://sanjeewamalalgoda.blogspot.com/> >> >> >> > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 > > <http://sanjeewamalalgoda.blogspot.com/>blog > :http://sanjeewamalalgoda.blogspot.com/ > <http://sanjeewamalalgoda.blogspot.com/> > > > -- Harsha Kumara Software Engineer, WSO2 Inc. Mobile: +94775505618 Blog:harshcreationz.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
