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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
