@Sajith, we already have those options you have mentioned in API Manager, if we are publishing a new version of an API either we can choose to make the users of the API to re-subscribe or we can automatically transfer over the subscriptions from the previous version.
On 22 July 2015 at 14:25, Sajith Ariyarathna <[email protected]> wrote: > Hi Uvindra, > > As pointed out by RuwanA, AppM had a similar problem when creating a new > version of a web app based on an existing version. In AppM, when > 'Publish'ing version *2.0.0* of web app *Foo* (which was created from > *Foo* version *1.0.0*), version *1.0.0* is 'Un-publish'ed (because only > one version of a web app is shown to end-users in the store) and subscriptions > from version *1.0.0* are moved to version *2.0.0*. This is not exactly > your situation in APIM, but you can see that subscriptions are moved to the > new version when it is 'Publish'ed. > > Suggestion: you should give the option to the Publisher to decide whether > to copy or move subscriptions to the new version. You can give 03 options, > "Copy Subscriptions to v2.0.0", "Move Subscriptions to v2.0.0" and "Do > Nothing". I believe it will improve the user experience for API Publisher. > > As suggested by RuwanA, keeping the 'parentID' in the asset or in the DB > will also help to maintain a version hierarchy and in future releases you > can use that data to do API grouping or to show a versioning tree. > > Thanks and Regards. > > > On Wed, Jul 22, 2015 at 1:00 PM, Ruwan Abeykoon <[email protected]> wrote: > >> Hi Uvindra, >> What if we keep the "parent" apiID in the asset itself, rather than in >> new DB column. (by adding the field to api.rxt) >> >> Cheers, >> Ruwan >> >> On Wed, Jul 22, 2015 at 12:44 PM, Uvindra Dias Jayasinha < >> [email protected]> wrote: >> >>> The correct way I can think of solving this is to store the apiID of the >>> version that is being copied from in the newly created api object so that >>> we can make the association later on when we are publishing the new api >>> version. >>> >>> This means we will need to add a new column to the AM_API table to store >>> this, hence Im trying to see if there is an alternative. >>> >>> >>> >>> On 22 July 2015 at 12:38, Uvindra Dias Jayasinha <[email protected]> >>> wrote: >>> >>>> Thanks for the suggestion Ruwan, but we are not on ES yet and wont be >>>> for sometime so we wont be able to exploit that feature. >>>> >>>> On 22 July 2015 at 12:32, Ruwan Abeykoon <[email protected]> wrote: >>>> >>>>> Hi Uvindra, >>>>> We are having same issue and being solved in AppM 1.1.0. We were >>>>> informed that ES 2.0 has grouping capability. So we may be exploit that to >>>>> correlate versions. We plan to back-port some ES 2.0 functions to ES 1 >>>>> branch to get this done. >>>>> >>>>> SajithAR working on this. >>>>> >>>>> Cheers, >>>>> Ruwan >>>>> >>>>> >>>>> On Wed, Jul 22, 2015 at 12:21 PM, Uvindra Dias Jayasinha < >>>>> [email protected]> wrote: >>>>> >>>>>> This applies to API Manager 1.9.0, but this is true for previous >>>>>> versions as well. When trying to fix the following ticket[1] I came >>>>>> across >>>>>> this scenario, >>>>>> >>>>>> 1. API named *"foo"* with versions *"1.0.0"* and *"2.0.0"* has >>>>>> existing subscriptions. >>>>>> 2. Create a new version of the same API *"3.0.0"* from *"2.0.0"*. >>>>>> 3. Publish API *"foo:3.0.0"* with the "Require Re-Subscription" >>>>>> option disabled. >>>>>> 4. What should happen is that the subscriptions of *"foo:2.0.0"* >>>>>> should be applied to *"foo:3.0.0" *automatically >>>>>> >>>>>> >>>>>> The problem is step *2 *and *3* above are separate so there is >>>>>> currently no association between *"foo:2.0.0"* and *"foo:3.0.0"*. >>>>>> >>>>>> So how do we determine which API version *"foo:3.0.0"* was created >>>>>> from so that we can transfer that APIs subscriptions at the time of >>>>>> publishing? >>>>>> >>>>>> Is there a way to do this without adding a new attribute to the newly >>>>>> created API to indicate whihc version it was copied from? >>>>>> >>>>>> [1] https://wso2.org/jira/browse/APIMANAGER-3971 >>>>>> -- >>>>>> Regards, >>>>>> Uvindra >>>>>> >>>>>> Mobile: 777733962 >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [email protected] >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Ruwan Abeykoon* >>>>> *Architect,* >>>>> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >>>>> *lean.enterprise.middleware.* >>>>> >>>>> email: [email protected] >>>>> phone:(+94) 777739736 >>>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Uvindra >>>> >>>> Mobile: 777733962 >>>> >>> >>> >>> >>> -- >>> Regards, >>> Uvindra >>> >>> Mobile: 777733962 >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> >> *Ruwan Abeykoon* >> *Architect,* >> *WSO2, Inc. http://wso2.com <http://wso2.com/> * >> *lean.enterprise.middleware.* >> >> email: [email protected] >> phone:(+94) 777739736 >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > Sajith Ariyarathna > Software Engineer; WSO2, Inc.; http://wso2.com/ > mobile: +94 77 6602284, +94 71 3951048 > -- Regards, Uvindra Mobile: 777733962
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
