I also think the first approach will be good. Regarding the migration i think all published APIs wont have any impact due to this migration. APIs in prototype state should be in prototype state after migrating. So if existing deployment migrated to 3.2.0 there will not be any changes in APIs and we will have set default values of the property accordingly. Then from there anyone should be able to utilize the above mentioned property and enable testing flag. That way migration will be easy. This property will be non mandatory parameter and if it available only we will have to render the test console in the publisher.
At the same time we will have to think about deploying unsecured API in gateway for testing purpose. So we will be able to use programmatically generated(something similar to what we used in throttle handler) WS policy to protect these APIs from common attacks. Thanks, sanjeewa. On Wed, Apr 22, 2020 at 9:49 AM Hasunie Adikari <[email protected]> wrote: > Hi Kasun, > > On Wed, Apr 22, 2020 at 9:17 AM Kasun Thennakoon <[email protected]> wrote: > >> Hi Hasunie, >> >> Out of the above three suggestions, I'm +1 to the 1st approach you have >> suggested, Where >> >> >> - Combination of *prototype *state and *enableStore=true*(API >> artifact property) will depict the *testing* state >> - *enableStore *property will control the visibility in the developer >> portal when the API is in prototyped state >> - this state and API filed update will happen only if they attempt to >> test the API >> - Testing will be allowed only in Created and Prototyped state, If in >> the created state change the LC to prototype and update the API field, If >> already in prototype update only the *enableStore *field >> >> >> As usual, he/she has to demote to the created state and initialize the >>> test. >> >> >> In the above case, where API is already in Published state and API >> creator wants to test the API, I think we should allow the action from the >> API testing page with the user's consent(I:e show a warning saying, API >> will be unpublished from the gateway/devportal , Do you like to continue ?) >> >> >> another point is, since we are adding a new field to API RXT we need to >> consider how to migrate APIs from previous versions. >> > We have a way to update the RXT field at runtime. For example [1]. We > did this for all newly added RXT fields. > > [1] https://github.com/wso2/product-apim/issues/3525 > >> >> @Sanjeewa Malalgoda <[email protected]> , @Nuwan Dias <[email protected]> >> please give your opinion on this >> >> Thanks >> ~KasunTe >> >> >> >> On Tue, Apr 21, 2020 at 4:17 PM Hasunie Adikari <[email protected]> wrote: >> >>> >>> Hi All, >>> >>> We have been working on a testing console for the API Publisher. The >>>> main intention of this feature is that the developer(creator, publisher) >>>> can make sure that the API is working as expected by performing functional >>>> tests before publishing to the dev portal. >>>> For example, test the mediation policies, check whether the API >>>> response comes from the expected back end, test the request parameters are >>>> compliant with the defined schema. >>>> >>>> By considering the functionalities, we decided to re-use the prototype >>>> life-cycle state. In fact, if a developer triggers a test, the particular >>>> API is deployed as a prototype and in addition to that, a new RXT field( >>>> *enableStore*) is set to false so that the specific testing API is >>>> restricted to the dev portal. Afterwards, if the API is either published or >>>> deployed as a prototype, the *enableStore *should be set to true. >>>> The APIsGet query should be changed as below. >>>> >>>> name=*&enableStore=true&lcState=(PUBLISHED OR PROTOTYPED) >>>> >>>> Furthermore, another concern is the lifecycle state that will show in >>>> the publisher lifecycle state diagram. So we came up with two approaches to >>>> show the state. >>>> >>> >>> Moreover, if an API is in a published state, we planned to restrict the >>> testing capability. As usual, he/she has to demote to the created state and >>> initialize the test. >>> Highly appreciate your insights on the following 2 approaches. >>> >>>> >>>> 1.i) Keep two subtypes of the prototype state like *prototype* >>>> and *prototype(testing)*. If it's a normal prototype(visible to >>>> store), it will be shown as a prototype. If the enableStore property is set >>>> to false and lcstate is a prototype, the state should be changed as the >>>> prototype(testing). The below diagram depicts the flow. >>>> >>> >>> >>> >>>> ii) Moreover, we can internally deploy the API as a prototype >>>> without intentionally saying this API is deployed as a prototype and keep >>>> the same state as created. Even though the lifecycle shows the API is in a >>>> created state, the synapse artefacts are created. This might be an issue >>>> as we can't clearly define our statuses. >>>> >>>> >>>> >>>> >>>> >>>> [image: console.png] >>>> >>>> 2. Create a pop-up window to carry on the tests functionalities. When >>>> a developer clicks on the testing pop up window, the API is deployed as a >>>> prototype and all the other details are hidden until the developer closes >>>> the window by finishing the testing phase. Once he/she closes the window, >>>> API should be automatically demoted to the created state and developer >>>> should be able to carry on his/her tasks without affecting the user >>>> experience. >>>> If we go ahead with this approach, we have to handle the clearing the >>>> artefacts with pinpoint accuracy otherwise it might lead to several issues >>>> at prod environments. >>>> >>>> If we can go with 1 i) approach, it would make a minor effect on the >>>> basic flow. Highly appreciate your suggestions and concerns regarding this. >>>> >>>> >>>> Regards, >>>> Hasunie >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> *Hasunie Adikari* >>>> Associate Technical Lead >>>> WSO2 Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> blog http://hasuniea.blogspot.com | https://medium.com/@Hasunie/ >>>> Mobile:+94713095876 >>>> >>>> >>> >>> -- >>> *Hasunie Adikari* >>> Associate Technical Lead >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> blog http://hasuniea.blogspot.com | https://medium.com/@Hasunie/ >>> Mobile:+94713095876 >>> >>> >> >> -- >> *Kasun Thennakoon* | Associate Technical Lead | WSO2 Inc. >> (m) +94 711661919 | (w) +94 11 214 5345 | (e) [email protected] >> GET INTEGRATION AGILE >> Integration Agility for Digitally Driven Business >> > > > -- > *Hasunie Adikari* > Associate Technical Lead > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > blog http://hasuniea.blogspot.com | https://medium.com/@Hasunie/ > Mobile:+94713095876 > > -- *Sanjeewa Malalgoda* Software Architect | Associate Director, Engineering - WSO2 Inc. (m) +94 712933253 | (e) [email protected] | (b) Blogger <http://sanjeewamalalgoda.blogspot.com>, Medium <https://medium.com/@sanjeewa190> GET INTEGRATION AGILE <https://wso2.com/signature> Integration Agility for Digitally Driven Business
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
