On Wed, Jul 17, 2013 at 5:30 PM, Nuwan Dias <nuw...@wso2.com> wrote: > On Wed, Jul 17, 2013 at 5:14 PM, Samisa Abeysinghe <sam...@wso2.com>wrote: > >> Is the design such that, if we want more than 2 environments, that can be >> facilitated? >> > > Yes, this can be facilitated. >
Where would that config go? Also, ideally, want to be able to use my own names in my setup rather than sandbox/prod say staging/live > > Another requirement which I missed to mention earlier is that we need to > have a control of the environments in which a given API will reside. For > example when an API is published, we need to say that it will initially be > deployed on the Sandbox Gateway only. Once the user is satisfied with it he > can promote it to Staging, Production, etc. > > Thanks, > NuwanD. > >> >> >> On Wed, Jul 17, 2013 at 3:02 PM, Nuwan Dias <nuw...@wso2.com> wrote: >> >>> Hi, >>> >>> This is regarding supporting multiple environments (production/sandbox) >>> for the API Gateway. Currently API Manager allows having two endpoints per >>> API. These are the production and sandbox endpoints. Although the sandbox >>> endpoint is supposed to be used for testing purposes, both production and >>> sandbox traffic is handled through a single Gateway. This can cause the >>> production Gateway be loaded with test traffic as well. >>> >>> This feature is to allow having two Gateway nodes (at least) for serving >>> production and sandbox traffic separately. Following is how it is supposed >>> to work. >>> >>> 1. When an API is published, it will be deployed on both the production >>> and sandbox Gateway nodes. >>> 2. The production Gateway will only serve production traffic and the >>> sandbox Gateway will only serve sandbox traffic. >>> 3. The Gateway will use the token type (production or sandbox) to >>> identify requests being received. >>> 4. The Token endpoint (/token) will remain same on both nodes. The token >>> being generated will depend on the type of consumer-key/consumer-secret >>> used. >>> 5. Both Gateway nodes will share a single APIMGT database. This is where >>> information related to APIs, Applications, Token, etc are stored. This will >>> be the same database as used by the publisher/store nodes. >>> >>> Currently an xml template is used for generating an API configuration >>> (synapse configuration). To allow the above mentioned feature to work, a >>> separate xml template will have to be maintained for each endpoint type >>> (production template and sandbox template). >>> >>> The api-manger.xml currently defines the location (url) of the Gateway. >>> A similar configuration will be introduced to define the location of the >>> sandbox Gateway. The API Store will display both endpoints accordingly. >>> >>> Thoughts/Suggestions welcome. >>> >>> Thanks, >>> NuwanD. >>> >>> -- >>> Nuwan Dias >>> >>> Senior Software Engineer - WSO2, Inc. http://wso2.com >>> email : nuw...@wso2.com >>> Phone : +94 777 775 729 >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Thanks, >> Samisa... >> >> Samisa Abeysinghe >> VP Engineering >> WSO2 Inc. >> http://wso2.com >> http://wso2.org >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Nuwan Dias > > Senior Software Engineer - WSO2, Inc. http://wso2.com > email : nuw...@wso2.com > Phone : +94 777 775 729 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
