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

Reply via email to