Skip to main content

Integrate WSO2 registry lifecycle with WSO2 API Manager 1.10



An API artifact has its own lifecycle to govern.A life-cycle contains set of states,actions happened during each state transitions and check list items before do a state transition.With previous APIM previous releases,we had a pre-defined lifecycle with pre-defined six states as ‘CREATED’,’PROTOTYPED’,’PUBLISHED’,’BLOCKED’,’DEPRECATED’,’RETIRED’ and pre-defined actions engaged with each state transitions  which cannot be extend or customize.There was a requirement came from many users,can’t they extend the default API lifecycle engaged with WSO2 API Manager as to add their defined state names,invoke their custom actions during state transitions [eg:send notifications at each transition],add custom checklist items before state transitions.
To achieve above,we decided to integrate WSO2 registry based lifecycle with APIManager.WSO2 registry based lifecycle provides a configurable way to define the lifecycle of an artifact which a user can easily extend.For more information ,refer http://wso2.com/library/tutorials/lifecycles-aspects-wso2-governance-registry/
From APIM 1.10 onwards the default API lifecycle has defined as a xml configuration which a user laterly can extend easily.Following is the default API lifecycle xml configuration shipped with AM 1.10 product and same can be download from here.You can find this from management console by navigating to Extenstions->Configure->Lifecycles left menu.
In above configuration,following are the important points.
  1. Lifecycle Name- APILifecycle
  2. Set of states -which are defined as   config elements.In default API lifecycle,it has six states as CREATED,PROTOTYPED,PUBLISHED,BLOCKED,DEPRECATED,RETIRED
  3. A list of checklist items to be satisfied-  
         When the API state is in ‘CREATED’ state and have multiple versions,we are checking two checklist items as ‘Deprecate Old Versions’ and ‘Require Re-subscriptions’.These check list items are defined as    configuration element.
    4.   State transition events -These events are to define from which state to which target state an API can be moved.These are defined as config elements in registry lifecycle. Below state transition chart explain clearly the state transition events in default API lifecycle.
w.png
    5.   Actions for each state transitions
         This is the important part.For each state transition,there has to be an action triggered which will execute during state transition.For example,when an API state change from ‘CREATED’ to ‘PUBLISHED’,from APIM side,there will be an execution happend as a relative synapse API xml element will be created and related API data will be saved in database.To happen that execution,developer has to define the execution for state transtion in above registry lifecycle configuration configuration.
With the above change,lifecycle tab in API Publisher UI has also changed.




On AM 1.10 APIPublisher,the lifecycle UI is showing the current state of an API and target events defined in API lifecycle for that state as buttons.Note this UI is dynamically generated based on defined API LifeCycle xml configuration [Previously this page is static].Thus if you customized the default API LifeCycle configuration included states,transition events or check list items,those changes will be rectified in the lifecycle tab of APIPublisher UI accordingly.
Extension points for the API Lifecycle

With the registry life-cycle integration,now a developer can changed the API lifecycle easily with modify the above mentioned APILifecycle xml configuration.Note he has to keep the lifecycle name as ‘APILifeCycle’ to engage it for an API by default.
He can define his own state names except ‘Published’ and ‘Prototyped’ states as those two two will be use from APIPublisher API creation wizard.He can change state transition events as per their environmental preference by changing APILifecycle accordingly.He can add custom checklist items for specific state transitions.
And also a developer can change the execution code for each state transitions.In default API lifecycle,we have used same execution class  called ‘org.wso2.carbon.apimgt.impl.executors.APIExecutor’
[https://github.com/wso2/carbon-apimgt/blob/release-1.10.x/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/executors/APIExecutor.java] for all the state transitions.But a developer can plug their own execution code with modifying the lifecycle configuration.For example,if he want to add notifications for a specific state  transition,then he can plug his own custom execution class for that particular state in APILifeCycle.
Once a developer changed states,events or checklist items,those will be rectified in APIPublisher life-cycle tab.
APIM 1.10 will be release by end quarter of 2015 and you'll able to try out these changes by the that release out.









Comments

Post a Comment

Popular posts from this blog

Convert an InputStream to XML

For that we can use DocumentBuilder class in java. By using the method parse(InputStream) ; A new DOM Document object will return. InputStream input; DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); DocumentBuilder parser = factory.newDocumentBuilder(); Document dc= parser.parse(input); In the above code segment,by using the created Document object,the corresponding XML file for the inputStream can be accessed. References: http://www.w3schools.com/dom/dom_intro.asp http:// download.oracle.com/javase/1.4.2/docs/api/javax/xml/parsers/DocumentBuilder.html
2 comments
Read more

CORS support from WSO2 API Manager 2.0.0

Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources  on a web page to be requested from another domain outside the domain from which the first restricted resource was served. For example, an HTML page of a web application served from http://domain-a.com makes an <img src >  request for a different domain as 'domain-b.com' to get an image via an API request.  For security reasons, browsers restrict cross-origin HTTP requests initiated from within scripts as in above example and only allows to make HTTP requests to its own domain. To avoid this limitation modern browsers have been used CORS standard to allow cross domain requests. Modern browsers use CORS in an API container - such as  XMLHttpRequest  or Fetch - to mitigate risks of cross-origin HTTP requests.Thing to  note is it's not only sufficient that the browsers handle client side of cross-origin sharing,but also the servers from which these resources getting need to handl
Post a Comment
Read more

[WSO2 AM] APIStore User Signup as an approval process

In previous versions of WSO2 APIManager before 1.6.0, it was allowed any user who's accessible the running APIStore come and register to the app.But there will be requirement like,without allowing any user to signup by him/her self alone,first get an approve by a privileged user and then allow to complete app registration.Same requirement can be apply to application creation and subscription creation as well.To fulfill that,we have introduced workflow extension support for  WSO2 APIManager  and you can find the introductory post on this feature from my previous blog post on " workflow-extentions-with-wso2-am-160 " . From this blog-post,I'll explain how to achieve simple workflow integration with default shipped resources with  WSO2 APIManager 1.6.0 and WSO2 Business Process Server 3.1.0 with targeting "user-signup" process. Steps First download the WSO2 APIManager 1.6.0[AM] binary pack from product download page . Extract it and navigate to
Post a Comment
Read more