Hi, In current APIPublisher lifecycle UI, there are below two additional UI options showing.
1) When doing status changes from 'created' to 'published' of an API,there's a check-box showing "Propagate Changes to the API Gateway". I guess we can discard this with new lc UI changes as ,now there's a new UI block in 'Manage' wizard to focus on publishing to gateway environments thus this option will handle by manage wizard UI option. 2) When doing status changes from 'created' to 'published' of a* versioned AP*I,it's asking two additional options as "Deprecate Old Versions" and "Require Re-Subscription". For these type of checks we can do as check list items in registry lc. But here,this checklist items are specific only for versioned APIs. @Greg team- Is there a way to accomplish this requirement? On Thu, Sep 10, 2015 at 4:33 PM, Nuwan Dias <[email protected]> wrote: > +1 to option 1. I don't think there will be many states the lifecycle can > go to from a given state. And the buttons should show the demote actions as > well. Ex: If the API is in the "PUBLISHED" state, the possible state > transitions are "CREATED" (demote), "PROTOTYPED" (demote), "BLOCKED" and > "DEPRECATED". Therefore all these buttons should be displayed when the API > is in the published state. > > The default lifecycle xml should be in the file system of the product. And > it should get copied to the registry space of the super tenant on first > server startup. For tenants, it should get copied to the relevant tenant > space when the tenant gets loaded the first time. This way organisations > can change the default lifecycle states if necessary. > This requirement can be achieved by keeping the API lifecycle in APIM/repository/resources/lifecycles location.Then the lc config file will be copied to registry space of super tenant/tenants. > > The "PUBLISHED" state should be mandated. That should be the state the API > goes into when you go through the API publishing wizard and press on "Save > and Publish". > > We should also plan for a data migration strategy for people to migrate > from 1.9.x to 1.10.0. > > Thanks, > NuwanD. > Thanks; > > On Thu, Sep 10, 2015 at 3:38 PM, Lakshman Udayakantha <[email protected]> > wrote: > >> Hi, >> >> API Manager currently uses its own lifecycle implementation. It will >> limited to a defined set of lifecycle statuses. >> With API Manager 1.10.0, The plan is to move with registry life cycles. >> Currently API Publisher loads pre-defined list of statuses. This will be >> changed to load statues from registry. Registry manages lifecycle >> information in APILifeCycle.xml. After loading lifecycle status from >> registry, it will be able to add custom lifecycle status also to API >> Manager. >> >> Here are two suggestions raised to implement this in UI level, >> >> 1. We can add a label to show the status instead of drop down list and >> can show the event transitions as buttons. updated status will show on >> status label. Those visible status names will load from status ids in >> APILifeCycle.xml. According to the status, appropriate buttons will be >> loaded. Visible button status will be transition event in APILifeCycle.xml. >> >> As an example: >> >> when API is in Created status the only possible status transitions are >> "Promote" and "Publish" according to default APILifeCycle.xml. So buttons >> with those names will be visible as below picture depicted. >> >> >> ​Pros: Invalid transitions will not be selected from drop down list, >> Easier to implement rather replace with API Manager 2.0.0 publisher feature >> lifecycle UI (look option 2). >> Cons :User has no way to know the next status until user clicks the >> promote or demote buttons. As a solution for this we can load the button >> names for next status. But if there are huge number of next statuses it >> will be unfeasible to load all the button names. >> >> 2. This has already implemented in API Manager 2.0.0 feature for greg >> integration with D3js library. We can integrate that UI in API Manager >> 1.10.0 too by replacing current drop down menu and button set. >> Pros : This will give a clear picture to the user about status >> transition and nice looking interface, Invalid transitions will not be >> selected from drop down list. >> Cons : Since future UIs of API Manager will be the UI belongs to API >> Manager 2.0.0 feature set, recreating API Manager 2.0.0 lifecycle UI in API >> Manager 1.10.0 will be an additional effort. >> >> >> Thanks >> -- >> Lakshman Udayakantha >> WSO2 Inc. www.wso2.com >> lean.enterprise.middleware >> Mobile: *0711241005* >> >> > > > -- > Nuwan Dias > > Technical Lead - WSO2, Inc. http://wso2.com > email : [email protected] > Phone : +94 777 775 729 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Lalaji Sureshika WSO2, Inc.; http://wso2.com/ email: [email protected]; cell: +94 71 608 6811 blog: http://lalajisureshika.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
