On 13 October 2016 at 17:51, Rajith Roshan <[email protected]> wrote: > Hi, > > The current implementation keeps the data in a separate database. For now > life cycle component has its own data source. I think its better to read > the data source name from a configuration so the tables related to life > cycle operations can be populated in an existing database as well. For ex: > if the config specifies the AM _DB then these tables will be created in API > Manager database, without using separate database. >
Yes we need to be able to save LC information in the AM_DB itself, but the real requirement for doing this is to make sure that we can handle creating APIs in a transactional way. Having to deal with two databases(AM DB and Life Cycle DB) when creating an API means we cant make things transactional. For APIM we should be able to pass in the same DB connection for the AM_DB to the LC component. Then if an exception gets thrown we can role back without having to deal with half backed data getting saved in the DB. Can we get this done? > > Thanks! > Rajith > > On Mon, Oct 10, 2016 at 3:49 PM, Prasanna Dangalla <[email protected]> > wrote: > >> >> Hi Rajith, >> >> On Mon, Oct 10, 2016 at 3:30 PM, Rajith Roshan <[email protected]> wrote: >> >>> Hi, >>>> >>> please find the images below >>> >>>> On Mon, Oct 10, 2016 at 3:16 PM, Rajith Roshan <[email protected]> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Life cycle is an integral part in any product. Each SOA governance >>>>> related artifacts can have their own life cycle. Capabilities provided in >>>>> order to manage life cycles not only allow you to properly organize your >>>>> assets but also provides many extensibilities (For ex through custom >>>>> executors) >>>>> >>>>> RequirementCurrent API life cycle of API manager completely depends >>>>> on the life cycle implementation provided by the registry. Since we are >>>>> moving away from the registry concept we need a completely new life cycle >>>>> management framework which cater for life cycle management within API >>>>> Manager and should be able to ship with other products which require life >>>>> cycle management. >>>>> >>>>> Proposed SolutionThe basic idea is to completely decouple the life >>>>> cycle framework from the system to which its provide life cycle >>>>> capabilities. I.e the system which uses life cycle will not change the >>>>> behavior of the life cycle framework and only vice versa will be >>>>> applicable. The framework should exist independent of the asset type to >>>>> which it provides life cycle capability >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The mapping should be maintained by asset type in order to associate >>>>> with life cycle data. To be more specific in database schema level each >>>>> asset type should update their tables (add extra columns to maintain >>>>> mapping with life cycle data) in order to map life cycle data. >>>>> >>>>> The external systems which uses life cycle service should connect with >>>>> the service in order to have a unique life cycle id which is >>>>> generated by the service. This id should be stored in the external system >>>>> in order to maintain the mapping (Each asset should have its own life >>>>> cycle >>>>> id). On the other hand life cycle framework will also store this id in >>>>> order to provide all the life cycle related operations for a particular >>>>> asset. >>>>> >>>>> >>>>> >>>>> >>>>> Basically, we will be providing a class (ManagedLifecycle) with all >>>>> the required basic operations. Any asset which requires life cycle >>>>> management can extend this class. >>>>> Further this can be extended to support features like check list items >>>>> as well >>>>> Features supported >>>>> >>>>> - >>>>> >>>>> Custom Inputs - User should provide with the capability in order >>>>> to save custom values per each state, which can be passed to executors >>>>> . >>>>> - Executors - Which are custom classes executed during life cycle >>>>> state change operation >>>>> >>>>> >>>>> Please provide you valuable inputs. >>>>> >>>>> Thanks! >>>>> Rajith >>>>> >>>>> -- >>>>> Rajith Roshan >>>>> Software Engineer, WSO2 Inc. >>>>> Mobile: +94-72-642-8350 <%2B94-71-554-8430> >>>>> >>>> >>> >>> >>> -- >>> Rajith Roshan >>> Software Engineer, WSO2 Inc. >>> Mobile: +94-72-642-8350 <%2B94-71-554-8430> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> Since this proposed feature is running separately, are we keeping the db >> tables in a separate database? If so, we can separate them from products >> and bind them to the feature. IMHO it will be an advantage. >> >> Regards, >> >> *Prasanna Dangalla* >> Senior Software Engineer, WSO2, Inc.; http://wso2.com/ >> lean.enterprise.middleware >> >> >> *cell: +94 718 11 27 51* >> *twitter: @prasa77* >> >> > > > -- > Rajith Roshan > Software Engineer, WSO2 Inc. > Mobile: +94-72-642-8350 <%2B94-71-554-8430> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
