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