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