Hi Punnadi, If we implement the second approach, then we can list down only the Name and Description by retrieving from the database during the page load (Same as External APIs section).
Thanks. Mahendran Pirinthapan Software Engineer | WSO2 Inc. Mobile +94772378732. On Thu, Jun 18, 2015 at 9:29 AM, Punnadi Gunarathna <[email protected]> wrote: > Hi Pirin, > > +1 for second approach. So how will be the Enterprise API section will > look like? > > On Thu, Jun 18, 2015 at 8:44 AM, Dimuthu Leelarathne <[email protected]> > wrote: > >> >> >> On Wed, Jun 17, 2015 at 8:53 PM, Pirinthapan Mahendran < >> [email protected]> wrote: >> >>> Hi all, >>> >>> When implementing the above solution we are storing the information to >>> the runtime database when each resource is created. But when it comes to >>> the Enterprise APIs section, the actual API subscription is done in the API >>> Manager side. So we cannot store the subscribed API information to the >>> runtime database from AF side. >>> >>> We need to choose one of the following option to resolve this issue. >>> >>> 1. Keep the Enterprise APIs section as it is. But this will give an >>> inconsistent look to the APIs page (Because if we keep it as it is, this >>> will show all the details about the subscribed apis while External APIs >>> section is showing only the Name and Description). >>> >>> 2. We need to expose a service from AF to write the api information to >>> the database and call this service once the subscription is done from APIM >>> side by extending the SubscriptionCreationSimpleWorkflowExecutor. >>> >> >> +1 for second approach. Please run the UX through Dakshika/DanukaD >> >> thanks, >> dimuthu >> >> >>> >>> I kindly expect your thoughts and feedback on the above solutions. >>> >>> Thanks. >>> >>> >>> >>> Mahendran Pirinthapan >>> Software Engineer | WSO2 Inc. >>> Mobile +94772378732. >>> >>> On Wed, Jun 17, 2015 at 10:26 AM, Punnadi Gunarathna <[email protected]> >>> wrote: >>> >>>> Hi All, >>>> >>>> I also think adding a new column to AF_RESOURCE would add more >>>> consistency. But we shouldn't be biased to External_APIs while naming that >>>> column. We can put a generic name so that in future, if we get more details >>>> to any of these resources (datasource, external_apis etc), that can be >>>> saved in this column as a string which holds key value pairs. >>>> >>>> On Wed, Jun 17, 2015 at 8:52 AM, Dimuthu Leelarathne <[email protected] >>>> > wrote: >>>> >>>>> >>>>> >>>>> On Tue, Jun 16, 2015 at 7:52 PM, Pirinthapan Mahendran < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Dimuthu, >>>>>> >>>>>> On Tue, Jun 16, 2015 at 6:13 PM, Dimuthu Leelarathne < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Pirin, >>>>>>> >>>>>>> On Tue, Jun 16, 2015 at 3:30 PM, Pirinthapan Mahendran < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I am implementing the UX solution, proposed by Danushka, to improve >>>>>>>> the performance of Runtime configs page after removing the registry >>>>>>>> mounts. >>>>>>>> To implement this, I am saving the resource name and description to the >>>>>>>> existing runtime database (AF_RESOURCE) and showing these information >>>>>>>> in >>>>>>>> the Runtime configs overview page and other config pages (APIs page and >>>>>>>> Properties page). >>>>>>>> >>>>>>> >>>>>>> Isn't this already done 2.1.0 release. >>>>>>> >>>>>> >>>>>> In the current implementation we are storing only the database, >>>>>> datasource, database user and database template information to the >>>>>> runtime >>>>>> database. >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> In the existing overview page we are showing Name and >>>>>>>> Authentication for external APIs while all the other resource types are >>>>>>>> showing Name and Description. Now the problem is when we saving the >>>>>>>> external api information to the runtime database there is no column to >>>>>>>> save >>>>>>>> the authentication type. >>>>>>>> >>>>>>> >>>>>>> In the main overview page, for external APIs we need to show the >>>>>>> Name and Description only. But when we go into the APIs page we need to >>>>>>> show the authentication type. Hence you need to have the authentication >>>>>>> type stored somewhere. >>>>>>> >>>>>> >>>>>> The authentication type is stored in registry. We can load this to >>>>>> the APIs page when a user press the load values button as proposed by >>>>>> Danushka above. >>>>>> The problem is, in the current implementation of overview page, we >>>>>> are sowing Name and Authentication type for external apis. Not >>>>>> description. >>>>>> If we are going to change this to show the description instead of >>>>>> authentication type in the overview page, then we can use the existing >>>>>> runtime database without any issues. >>>>>> >>>>> >>>>> +1. This is what I meant. For the Main overview page no Auth type. But >>>>> for the API overview page we need it. Since we need it for API overview >>>>> page we need to keep it at our side in the DB. >>>>> >>>>> thanks, >>>>> dimuthu >>>>> >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Pirinthapan. >>>>>> >>>>>>> >>>>>>> >>>>>>>> To overcome this issue we can choose one of the following solution. >>>>>>>> >>>>>>>> 1. We can add another table AF_EXTERNAL_API and store >>>>>>>> authentication type there. >>>>>>>> >>>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> thanks, >>>>>>> dimuthu >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 1. We can stop showing authentication type without retrieving >>>>>>>> data from remote server. >>>>>>>> 2. We can add another column to the existing AF_RESOURCE table >>>>>>>> to store authentication type. >>>>>>>> 3. Add a description to external apis and show it in UI instead >>>>>>>> of authentication type (Currently there is no description to >>>>>>>> external apis). >>>>>>>> >>>>>>>> 1 & 3 will need data migration. 1 would be cleaner than 3. >>>>>>>> >>>>>>>> If we are going with 2, then it will show only the name of the >>>>>>>> external apis while others will show name and description. >>>>>>>> >>>>>>>> I kindly expect your thoughts on this issue. >>>>>>>> >>>>>>>> Thanks. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Mahendran Pirinthapan >>>>>>>> Software Engineer | WSO2 Inc. >>>>>>>> Mobile +94772378732. >>>>>>>> >>>>>>>> On Fri, Jun 12, 2015 at 1:01 PM, Pirinthapan Mahendran < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I am working on the above task. I will remove the registry mounts >>>>>>>>> for Dev, Test, Prod registries and implement the UX solution as >>>>>>>>> explained >>>>>>>>> by Danushka. >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Mahendran Pirinthapan >>>>>>>>> Software Engineer | WSO2 Inc. >>>>>>>>> Mobile +94772378732. >>>>>>>>> >>>>>>>>> On Wed, Jun 10, 2015 at 2:31 PM, Danushka Fernando < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi All >>>>>>>>>> >>>>>>>>>> Currently we are trying to improve the performance of the App >>>>>>>>>> Factory. While doing that we identified that having a lot of registry >>>>>>>>>> mounts (in AF case 3) might be an performance impact. These mounts >>>>>>>>>> are used >>>>>>>>>> to read runtime config values and when we want to add / update we are >>>>>>>>>> calling the remote service. >>>>>>>>>> >>>>>>>>>> Reason for this solution was that runtime config pages are really >>>>>>>>>> slow due to the service calls we are doing and also because these >>>>>>>>>> calls can >>>>>>>>>> fail it was a point of failure. So because of these mounts we are >>>>>>>>>> retrieving values without remote calls. >>>>>>>>>> >>>>>>>>>> But because of these mounts there could be an impact on other >>>>>>>>>> operations such as Load tenant registry, Load tenant, get artifacts, >>>>>>>>>> etc. >>>>>>>>>> >>>>>>>>>> So we thought about removing them and come up with an UX >>>>>>>>>> solution. We will get values from remote calls. But we won't >>>>>>>>>> retrieve them >>>>>>>>>> in every page load. There will be a button saying something like load >>>>>>>>>> values from remote server and we will do the service call only if >>>>>>>>>> that >>>>>>>>>> button is clicked. We will save the names of these runtime configs in >>>>>>>>>> runtime database and we will list down the names in the UI from the >>>>>>>>>> runtime >>>>>>>>>> database. >>>>>>>>>> And with the new Stratos / Private PaaS upgrade we will be moving >>>>>>>>>> towards the Metadata service, where other PaaS also have similar >>>>>>>>>> service. >>>>>>>>>> So after that we won’t be using these registries any way. So we are >>>>>>>>>> going >>>>>>>>>> to go ahead with the above solution to achieve better user >>>>>>>>>> experience, >>>>>>>>>> stability and performance. >>>>>>>>>> >>>>>>>>>> Thanks & Regards >>>>>>>>>> Danushka Fernando >>>>>>>>>> Senior Software Engineer >>>>>>>>>> WSO2 inc. http://wso2.com/ >>>>>>>>>> Mobile : +94716332729 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Architecture mailing list >>>>>>>>>> [email protected] >>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dimuthu Leelarathne >>>>>>> Director & Product Lead of App Factory >>>>>>> >>>>>>> WSO2, Inc. (http://wso2.com) >>>>>>> email: [email protected] >>>>>>> Mobile : 0773661935 >>>>>>> >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dimuthu Leelarathne >>>>> Director & Product Lead of App Factory >>>>> >>>>> WSO2, Inc. (http://wso2.com) >>>>> email: [email protected] >>>>> Mobile : 0773661935 >>>>> >>>>> Lean . Enterprise . Middleware >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Thanks and Regards, >>>> >>>> Punnadi Gunarathna >>>> Senior Software Engineer, >>>> WSO2, Inc.; http://wso2.com <http://wso2> >>>> Blog: http://hi-my-world.blogspot.com/ >>>> Tel : 94 11 214 5345 >>>> Fax :94 11 2145300 >>>> >>>> >>>> >>>> <http://lalajisureshika.blogspot.com/> >>>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Dimuthu Leelarathne >> Director & Product Lead of App Factory >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> Mobile : 0773661935 >> >> Lean . Enterprise . Middleware >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks and Regards, > > Punnadi Gunarathna > Senior Software Engineer, > WSO2, Inc.; http://wso2.com <http://wso2> > Blog: http://hi-my-world.blogspot.com/ > Tel : 94 11 214 5345 > Fax :94 11 2145300 > > > > <http://lalajisureshika.blogspot.com/> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
